Affiliate Payout Compliance in iGaming: 5 Crypto Must-Haves

Five artifact groups have to be on file before you send an affiliate a single Satoshi: verified KYB and beneficial ownership records; sanctions, PEP and adverse media screening results; wallet and address risk screening; a signed contract with a documented source-of-payment record; tax residency and withholding data.

Miss one and the payout is indefensible the moment somebody asks about it. Two supervisory regimes collide on affiliate commissions. AML treats your affiliate as a counterparty receiving value from a licensed gambling operator.

Tax and accounting treat the same payment as a deductible marketing expense that has to be substantiated line by line. Settling in crypto removes neither obligation. It changes the evidence format, and it bolts on a blockchain-analytics layer that examiners now expect to see documented rather than described.

Most operators find the gap the hard way. A license renewal lands, or a bank starts a periodic review, or an external auditor asks for the affiliate file. What exists is a Google Sheet of wallet addresses, a few PDF invoices with inconsistent numbering, and a Telegram thread where someone called Dave promised the ownership docs "next week." That was fourteen months ago. Dave has been paid €340,000 since.

This piece sets out the file that should exist before the first commission moves, in the order the controls should be built.

Operational guidance, not legal or tax advice. Confirm obligations with counsel in every licensing jurisdiction you touch.

Why does paying an affiliate in crypto raise the compliance bar?

An affiliate commission is an outbound payment from a regulated entity to a commercial counterparty. Route it through a bank and the correspondent does part of your screening for free, then hands you a durable record you didn't have to build. Route it on-chain and you inherit both jobs.

Four factors compound the exposure.

Affiliate networks are structurally opaque. Sub-affiliates, media buyers and traffic brokers sit behind the contracting entity, and the contracting entity often has no commercial reason to tell you who they are.

Crypto payouts are irreversible. There is no recall, no chargeback, no correspondent to phone at 9am. Pre-transaction controls carry the entire weight that post-transaction remedies would otherwise share.

Supervisory attention on gambling marketing spend has climbed at the same time as attention on virtual asset transfers. You are standing where two enforcement priorities overlap.

And then there's the one nobody plans for: traceability runs both ways.

Give an affiliate a payout from your treasury wallet and you have handed them a permanent window into it. They can see the balance. They can see every other payment that wallet has made, when, in what size, and to which clusters.

A sophisticated counterparty, or a journalist, or a competitor who bought a blockchain-analytics seat for $200 a month, can reconstruct your affiliate cost base, spot which programmes you pay in what volume, and identify any address in your history that has since been flagged.

If your marketing treasury has ever touched a mixer, a sanctioned cluster, or an exchange that later got designated, that history is public and permanent. Fiat payments don't do this. Your bank statement is not a shared ledger.

Which means treasury hygiene stops being an internal housekeeping matter and becomes a counterparty-facing disclosure. Segregate. Rotate. Screen your own outbound history the way you screen theirs. I have seen a de-risking bank pull an operator's public treasury address history and ask, in writing, about a single 2021 transaction the operator's own finance team had forgotten existed.

The obligation isn't new. The evidence burden moved onto you.

The failure modes that actually cause the damage

Before the control list, the failure list. These are the patterns that show up in enforcement notices, banking exit letters and license conditions, and they are worth naming because a control designed against a named failure mode is testable.

Undisclosed beneficial owners. The contracting entity looks fine. A UK limited company, filed accounts, tidy website. Behind it sits a nominee shareholder service, and behind that a person who is either sanctioned, a PEP, or an ex-employee of your own commercial team taking a cut on both sides.

You paid value to someone you never identified. That's the finding, and it's usually accompanied by a question about why your onboarding accepted the applicant's own word on ownership rather than a registry extract.

Shell entities. Registered three weeks before the affiliate agreement. No operating address. No staff. A website with stock photography and 400 words of AI-generated content. The entity exists to receive money and nothing else, which makes the commission payment a transfer with no demonstrable commercial substance. Tax authorities challenge the deduction; the MLRO struggles to explain the arrangement.

Commission funnelled to prohibited or blocked markets. This one is the quiet killer. The affiliate is legitimate, the entity is real, the ownership is clear. But 30% of the traffic they send you originates from a market where you hold no license, or one your license explicitly blocks, and you are paying commission on players you should never have accepted.

The commission payment is now evidence of the underlying breach. Worse: the payment file documents your own knowledge of where the traffic came from, because you paid on the basis of geo-tagged performance data.

Payment diversion through address change. Affiliate email gets compromised. A new wallet address arrives in a plausible thread. Finance pays it. The affiliate chases the missing commission four weeks later. You are out the money and you have an incident to report.

Screening theatre. The alert fired. Somebody cleared it. Nobody wrote down why. On paper this is indistinguishable from never screening at all, and reviewers treat it that way.

What must exist in the affiliate KYB onboarding file?

Affiliate KYB onboarding for casino and sportsbook programmes should match the standard you'd apply to any commercial counterparty receiving material recurring payments. Not a lighter marketing-department version of it.

Entity layer

• Certificate of incorporation or equivalent registry extract, dated within a defined freshness window

• Registered address and operating address, where these differ

• Company registration number, verified against the source registry rather than accepted from the applicant

• Evidence of trading activity: website ownership, traffic sources, media assets

• Any gambling-adjacent licenses or registrations the affiliate holds, where its jurisdiction requires them

Ownership and control layer

• Ownership structure chart to natural persons, with percentage holdings

• Identification documents for each beneficial owner above the threshold set by your license conditions

• Directors and any person exercising control by other means

• Declaration of any relationship to the operator's own directors, shareholders or employees. Related-party affiliate arrangements attract disproportionate scrutiny, and rightly so.

Individual affiliates

Where the counterparty is a natural person rather than an entity, substitute identity verification, proof of address and self-employment status evidence. Don't file individual affiliates under "low risk" reflexively. The absence of a corporate wrapper removes a layer of documentation, not a layer of risk.

Risk classification

Assign a documented risk rating at onboarding. Drive it, at minimum, from jurisdiction of incorporation, jurisdiction of beneficial owners, ownership opacity, expected monthly commission volume, payout asset, traffic source type, and market mix. Those last two get skipped constantly and they're often the most predictive inputs you have.

An unrated affiliate file is a finding waiting to be written.

Tiering: what each risk band actually triggers

A rating that doesn't change your behaviour is decoration. Here's the tier structure I'd defend in a review, with traffic source and market mix carrying real weight.

Two notes on using this.

First, tiers move. An affiliate that starts in Tier 1 and begins buying Spanish-language push traffic has moved, and your file should show the date it moved and who decided.

Second, tier changes should be reversible only upward-to-downward with evidence. Downgrading someone from Tier 3 to Tier 2 because they've been paid without incident for six months is a decision that needs a name attached to it.

Re-verification triggers: the named list

Periodic refresh cycles catch drift. They don't catch events. You need both, and the event list should be written into policy so nobody has to exercise judgement about whether something counts.

Re-verify the full file when any of these fire:

1. Volume spike. Commission in a single period exceeds the rolling three-month average by a defined multiple. Pick a number, 200% works as a starting point, and make it automatic.

2. New market entry. Traffic appears from a territory not previously in the affiliate's declared mix. This should be a system alert, not a monthly-report observation.

3. Ownership change. Any change to shareholders, directors, or persons exercising control. Contractual notification duty on the affiliate, plus your own registry monitoring, because the contractual duty gets ignored.

4. Wallet or payout address change. Treated as a full re-verification event, not an admin update.

5. Adverse media hit on the entity, any owner, or any disclosed sub-affiliate.

6. New sanctions or PEP match from a list update, including a fuzzy match you previously cleared.

7. Structure change. New intermediate holding company, new trust, migration of domicile.

8. Traffic method change. Affiliate moves from SEO to paid, or adds a sub-affiliate network.

9. Payment behaviour change. Requests to split a payout across multiple addresses, sudden preference for a different asset, or a request to pay a third party.

10. Chargeback, bonus abuse or fraud clustering traced to that affiliate's player cohort.

11. License or regulatory action against the affiliate in its own jurisdiction.

12. Dormancy then reactivation. An affiliate that sends nothing for six months and then sends volume needs looking at again. Domains change hands.

Log the trigger, the date, what you re-verified, and the outcome. A trigger list with no evidence of firing is worse than no list at all, because it documents a control you demonstrably didn't run.

How should sanctions, PEP and adverse media screening be structured for crypto payouts?

Three distinct screening events. Reviewers will ask which one produced which record, and they'll ask in that order.

Screen against the consolidated lists applicable to every jurisdiction you touch. Your licensing jurisdiction. Your banking jurisdiction. The affiliate's jurisdiction.

Any list your correspondent institution imposes contractually, which is frequently broader than the statutory minimum and buried in an appendix nobody read. These sets don't align.

Asserting that one list governs is not a defensible position, and I've watched it fail in a room.

PEP screening

Applies to beneficial owners and directors. A PEP match is rarely a prohibition. It's a trigger for enhanced due diligence and senior approval. Document the decision, the approver and the rationale. A cleared match with no written rationale reads exactly like an unscreened counterparty, because from the outside it is one.

Adverse media screening

This is its own category, and it gets folded into sanctions screening far too often by operators who assume their vendor's "one search, all lists" button covers it. It usually doesn't, or it covers it thinly.

Adverse media asks a different question. Not "is this person designated" but "has this person been publicly connected to conduct that would change my view of the relationship."

Fraud allegations. Unlicensed gambling operations. A regulatory action in another sector. A conviction that never made it onto a list. Litigation over affiliate commission theft, which is more common than the industry admits.

Scope it properly:

• Search the entity, every UBO, every director, and any disclosed sub-affiliate at the point of onboarding

• Cover the affiliate's operating language, not just English. An affiliate running LATAM traffic with a clean English-language profile can have a substantial Portuguese-language press history.

• Define what constitutes a relevant hit in policy, so the person doing the search isn't inventing the standard on the day

• Set a refresh cycle by tier, and fire it on the trigger list above

• Record negative results. "Searched, nothing found, on this date, using these terms" is a finding-proof artifact. An empty folder isn't.

Ongoing monitoring matters more than the initial hit. Lists change. Ownership changes. Reputations change. Define the rescreening interval by risk rating, log every run including nil-result runs, and retain the screening configuration used, so a historical result can be reproduced two years from now when someone asks why you cleared a name that has since been designated.

What does wallet screening for affiliate payments actually involve?

Wallet screening is the control most often missing from otherwise mature files. It tests the destination address, not the person, and the two diverge more sharply than most teams expect.

Minimum scope before whitelisting an address:

• Attribution check. Is the address associated with a known service, exchange, mixer, sanctioned entity or darknet marketplace.

• Exposure analysis. Direct and indirect exposure to high-risk categories, expressed against your documented risk appetite. Not against a vendor's default settings, which you did not write and cannot defend.

• Address ownership confirmation. A signed message, a micro-transaction confirmation, or a written attestation on letterhead tying the address to the contracting entity.

• Asset and network confirmation. The exact asset and chain, recorded. Every treasury team has a story about USDT sent on the wrong network.

Risk bands and prescribed action

Screening produces a number. The number is useless without a pre-agreed response, because otherwise every alert becomes a negotiation between a finance clerk who wants to close the payment run and a compliance analyst who wants to go home.

Write the bands down. Approve them at committee. Then follow them.

Calibrate the numbers to your own vendor's scale and your own appetite. What matters is that the band exists, the action is prescribed, and nobody improvises at 4:50pm on a Friday.

Operational controls around the address

1. Maintain a whitelist. Payouts go only to addresses that have passed screening and been approved. No exceptions for "urgent."

2. Apply a cooling period after any address change, with re-verification through a channel independent of the request. Call the number you had on file before the request arrived. Affiliate email compromise is a recurring payment-diversion vector and it is not a hypothetical.

3. Rescreen whitelisted addresses on a defined cycle and before any unusually large payout.

4. Set escalation rules for a previously clean address that develops adverse exposure, including whether accrued commissions are held pending review. Decide this in policy, not in the moment.

5. Record every screening run with timestamp, tool configuration, result and reviewer.

Where an affiliate wants payment to a custodial exchange deposit address, attribution will resolve to the exchange, not the affiliate. Document that limitation in the file.

The exchange's own compliance programme is not a substitute for your control, and saying "well, Binance KYC'd them" in an RFI response will not land the way you hope.

Lightning and stablecoin nuances

Address-history screening is a model built for account-based and UTXO chains. Two rails break it, and the workarounds differ.

Lightning. There's no destination address to screen in the way analytics tools mean it. A payment resolves over a route of channels to a node. What you can capture and evidence: the node public key, the channel counterparty context, whether the receiving node is a known custodial service or a self-custodied node, the invoice, the preimage as proof of settlement, and the route where your implementation exposes it.

Screen the node ID against available datasets, screen the receiving service if it's custodial, and record the settlement proof.

Where an affiliate receives over Lightning into a custodial wallet, treat it like the exchange-deposit case: attribution resolves to the provider, so document the limitation and lean harder on entity-level KYB.

Lightning gives you faster settlement and cheaper fees on high-frequency, lower-value commission runs. It gives you less on-chain forensic surface. Both facts belong in your risk assessment, in writing.

Stablecoins. Address history matters, and so does something address history never shows you: the issuer. USDT, USDC and their peers sit behind a centralised issuer that can freeze balances at a specific address, sometimes within hours of a law-enforcement request, sometimes on its own initiative. Two consequences.

First, an address that screens clean today can be frozen tomorrow because of activity you had nothing to do with. If your affiliate's receiving address gets blacklisted after your payment lands, they will come to you claiming non-payment. Your contract needs to say that settlement is final on network confirmation and that issuer action against the recipient's address is the recipient's risk. Get that clause in before it matters.

Second, your own treasury is exposed to the same mechanism. Holding operating balances in a single issuer's token on a single address is a concentration risk that no amount of counterparty screening addresses. Spread it. Record the policy. And check whether your license conditions have anything to say about the composition of funds used for marketing spend, because several jurisdictions now do.

Record which chain, which issuer, which contract address. "We paid 40,000 USDT" is not a record. "We paid 40,000 USDT (Tether, TRC-20, contract THbVQp...) from treasury wallet TR9x... to whitelisted address TJm2..., tx hash 8f3c..., FX reference Coinbase spot 14:32:07 UTC" is.

Post-send monitoring, and why the score matters less than the outcome

Screening before you send is table stakes. Watching what happens after you send is where a mature programme separates itself, and almost nobody does it.