Crypto Travel Rule iGaming Ops: Platform or PSP?

Two controls, two vendors, and a gap between them nobody bills you for. Your casino platform decides whether a player gets a session. Your crypto payment provider decides whether an address gets paid.

That's the split.

Account-level and IP-level blocking? Platform side.

Sanctioned-address screening and Travel Rule data on the way out? Payment side.

Here's the bit that stings for crypto Travel Rule iGaming operators: you can outsource execution ten different ways, but the licence stays in your drawer. When a supervisor drafts an enforcement notice, they type the licensee's name at the top.

Not your vendor's. Never your vendor's.

Why does nobody answer this question until the audit lands?

Because you own the licence risk and none of the code. And no vendor in the chain has any reason to volunteer scope they weren't paid for.

Look at how a turnkey, white label or aggregator-fed setup is actually assembled. The platform provider ships a lobby, a wallet ledger, a cashier iframe and a session model.

The payment provider ships a deposit-address service and a payout API. Read both contracts back to back and you will rarely find "restricted jurisdiction" and "sanctioned address" in the same document, let alone the same clause. So each party quietly assumes the other one is covering the seam.

The result is a control that exists in your architecture diagram and nowhere in production.

Two failure modes hide in that seam. Both worth naming out loud, because both show up in enforcement notices with depressing regularity.

Failure mode one: You accept play from a restricted jurisdiction

A player registers with a clean document, logs in over a VPN from a prohibited market, funds with USDT and plays for four months.

Nobody bounced the session, because the platform's VPN detection was off by default and the blocked-country list hadn't been touched since onboarding.

Your payment provider saw a valid session token and did precisely what it was contracted to do: it created an address.

Failure mode two: You pay out to a sanctioned address

A withdrawal clears in eleven seconds to a destination sitting on an OFAC list, or one hop from a mixer, because screening was an optional feature nobody switched on and the platform's payout endpoint had no hook to hold funds anyway.

On-chain, that's finished.

No chargeback window. No acquirer to phone.

In fiat, a card scheme papered over some of this for you. An issuer BIN carried a country. A decline handed you a free second line of defence. Crypto strips all of it out. A wallet address has no nationality, no issuer, and nobody waiting to say no on your behalf.

Which is why this article keeps two questions apart, when operators habitually mash them together: where is the player (a platform and identity problem) and where did this money come from or go (a payment and chain-analytics problem). Different vendors. Different enforcement points. Different logs. Different clauses.

Who owns geo-blocking, you or your casino platform provider?

Your platform executes it. You own it. That distinction is the entire section.

In nearly every stack, IP geo-location, VPN and proxy detection, country-of-registration blocks and the hard rule that stops a flagged account from opening a game session all run inside the platform layer.

What's left for the operator is hardly trivial: deciding the blocked-country list, keeping it current when a market closes, testing that the rules actually fire, and being able to prove on a Tuesday afternoon that they fired on a specific date eight months ago.

Stop thinking of geo-blocking as a switch. It's at least four separate controls, usually configured on four different screens, sometimes by different teams, and they fail independently of each other:

1. Registration-time country block. Refuses account creation from a prohibited jurisdiction.

2. Login and session-time IP checks. Catches the compliantly registered player who has since travelled, or who bought a VPN subscription.

3. KYC document-country consistency. Flags a passport, address and IP that don't agree.

4. Session-level content blocks. Stops specific game types or bonus mechanics that are restricted in a market where you are otherwise licensed.

Make your provider demo each of these separately in a test environment. "The geo module is on" is not a demonstration. It's a sentence.

The layer most stacks handle badly: detection quality

Basic IP lookup is easy to defeat and everybody knows it.

The interesting question is whether your provider does ASN-level detection: flagging traffic that originates from autonomous systems belonging to commercial VPN operators, hosting companies and data centres, rather than residential ISPs.

A player connecting to your casino from an AWS or Hetzner ASN is not sitting on a sofa in Hamburg. That signal is cheap to collect and, in my experience, switched off more often than not.

If your platform's detection is weak, you have a real option.

Put a specialist geo vendor in front of, or alongside, the platform and make that vendor the owner of Layer 2. I've seen several operators run exactly this way, with a third-party geo and device-intelligence service scoring the session and the platform enforcing the verdict. It costs more.

It adds an integration. It also gives you your own logs, your own tuning and your own evidence trail, independent of a provider who may be in no hurry to fix a false-negative rate.

Whichever route you take, get concrete answers before you sign. Four questions, in writing:

• Is VPN and proxy detection on by default for our brand, or does it need to be enabled per market?

• Does detection include ASN and data-centre attribution, or is it IP-country lookup only?

• Who tunes the thresholds, us or you, and what is the change process when we get a wave of false positives from corporate networks?

• What exactly is logged on a block event? Timestamp, IP, resolved country, ASN, rule ID, decision, session ID? Can we export it, and for how long do you keep it?

If the answer to the last one is a shrug, you've just found your first missing clause.

Change velocity is where operators actually get burned

A market closes overnight. A new prohibition, a payment ban, a licence condition tightened with two days' notice. Only one number matters then: the gap between your instruction and enforcement in production.

Put that lead time in the platform agreement in hours. Demand logs with an effective timestamp. "We updated it" with no timestamp isn't evidence any supervisor will accept, and you're the one who'll be standing there without it.

Where do restricted-jurisdiction crypto deposits actually get stopped?

Before the cashier opens. Not on the blockchain.

This is the single most common misunderstanding in crypto-enabled iGaming. Operators assume the payment provider filters out prohibited markets. In reality the payment provider receives an authenticated session or an API call from your platform, and mints an address for it.

If your platform allowed the session, the address exists. That's the whole logic. There is no step five.

There's no country field in a Bitcoin or stablecoin transfer.

Chain analytics can sometimes infer geography sideways: an inbound deposit arriving from an exchange that only serves one market tells you something.

But that's a risk signal, and it lands after the money has already moved. Anything you intend to rely on as a hard prohibition has to be enforced upstream of address generation.

Two hooks belong in the contract rather than in your assumptions.

"No session, no address." Your payment provider should reject any deposit-address request that doesn't carry a valid, jurisdiction-cleared session token issued by the platform. That one rule turns your PSP from a blind address factory into a second gate.

A cashier-level deposit block. Re-check IP and jurisdiction the moment the cashier loads, not just at login. Players travel. Sessions live for hours. A player who registered compliantly in Lisbon may be depositing from a market you have no right to serve, and the cashier is the last cheap place to catch it.

Neither of these exists by default in most stacks. If it isn't in a clause, it belongs to nobody.

What does the crypto travel rule mean for iGaming operators in practice?

Originator and beneficiary data has to travel with a transfer between regulated counterparties. Somebody in your stack has to send it, receive it, and store it in a form you can produce later.

The rule descends from FATF Recommendation 16, and transposition is a patchwork. The EU applies it to crypto-asset transfers with no de minimis threshold at all. Several other regimes set a USD or EUR 1,000 equivalent floor.

Some haven't implemented it in any meaningful way yet. Which version bites you depends on your licence, your establishment, and where your payment provider is regulated.

Underneath all that sits a structural question: is your operation itself a VASP, or a customer of one? Most licensed casinos are not registered virtual asset service providers.

They hold gambling licences and touch crypto through a regulated payment provider that carries the VASP obligation. That answer determines who transmits the data. It does not get you out of being asked, by a gambling regulator or an AML supervisor, to produce the records for one specific withdrawal from March.

Confirm your classification with licence counsel. Nothing here is legal advice.

Deposits and withdrawals are not symmetrical, and the difference matters

Say it plainly, because vendors rarely will: the obligation bites hardest on payouts.

On a deposit, you're the receiving side. The counterparty VASP is the one obliged to send originator data with the transfer, and your job is to receive it, check it against the player and the address, and hold onto it. Sometimes it never arrives at all, because the sender sits on a different messaging network, or on none.

On a withdrawal, you're the sending side, or your provider is on your behalf. That's where collection, verification and transmission duties land. That's where a missing self-declaration on an unhosted-wallet transfer becomes a defect with your name on it.

And that's where a receiving exchange can park your player's funds for a week pending data it never got. Nine out of ten Travel Rule headaches in iGaming are payout headaches.

The friction is real and specific. Counterparty VASPs are not all on the same messaging network. Unhosted wallet withdrawals require a self-declaration of ownership under some regimes and not others.

A receiving exchange may hold funds indefinitely rather than bounce them back. So specify it in the contract: which networks your provider is connected to, what happens when a counterparty is unreachable, who talks to the player when a payout stalls, and how long the data is retained on your behalf.

Ready to pressure-test this against a live setup? See how LightningPay handles screening at the cashier layer before you sign the next renewal.

Who performs sanctioned wallet screening on deposits and withdrawals?

The payment provider, because it's the only party in the stack that ever holds the address.

Your platform sees a balance and a payout instruction. It doesn't see the destination address, its cluster attribution, its exposure to mixers or darknet markets, or whether it turned up on an OFAC or UK OFSI listing last Thursday.

Screening has to happen where the address is known: at deposit-address monitoring, and above all in the seconds before a payout is broadcast.

Contract deposit screening and withdrawal screening separately. Different risks, different remedies.

An inbound deposit from a high-risk source is a decision about crediting, quarantining or returning funds, and returning crypto to a sanctioned or unattributed source can itself be a breach in some regimes.

An outbound payout to a listed address is a potential sanctions violation you cannot reverse once it's on chain. Pre-payout, or pointless.

The flagged-withdrawal workflow, in order

Most operators can describe screening. Far fewer can describe what happens in the ninety minutes after a hit. Write this sequence into your procedures and your provider agreement, in this order:

1. Hold. The payout is stopped inside the payout call itself, before funds leave treasury. Not queued. Not flagged for review after broadcast. Held. The player sees a pending state, and your support team sees a reason code rather than a mystery.

2. Escalate. The hit routes to a named human, with a clock on it. Your MLRO or nominated officer gets the address, the match reason, the list source, the confidence level and the player's KYC record in one place. Vague "risk high" scores with no attribution burn the first hour of a very short deadline.

3. Freeze. If the match holds up, freeze the related activity: the payout, the wallet, the account, and any linked accounts sharing a device, address or funding source. On some stablecoins the issuer can freeze at the address level, which occasionally gives law enforcement a recovery route. Bitcoin gives you nothing.

4. Report. File with the competent authority inside the statutory window, which starts running from when you knew or should have known. Preserve the full record: screening result, list version, decision, decision-maker, timestamps, Travel Rule payload.

Then ask the harder question. Can your current stack even execute step one? On most third-party platforms the honest answer is no, because the hold has to live in the payment layer and nobody built it there.

Want to see what it looks like when the cashier and payout layer are designed for gambling flows instead of retrofitted onto them? Our page on crypto payment solutions built for online casinos sets out where each of these controls physically attaches.

One more variable changes your options: asset choice. Major stablecoin issuers retain the technical ability to freeze balances at specific addresses. Bitcoin has no such mechanism, so a mistaken payout is final. Gone. That's one of the trade-offs between Bitcoin and stablecoins for iGaming operators worth weighing before you standardise on either.

Control ownership at a glance

The two rows operators most often get wrong

Cashier-level deposit block. Almost everyone assumes this one belongs to the payment provider. Almost everyone is wrong. The PSP sits downstream of the decision.

It receives a session token and mints an address; it has no view of the player's registration country, documents or IP history unless you contractually force that token to carry a jurisdiction verdict.

I once watched an operator discover mid-audit that its "PSP-level geo controls" amounted to a hopeful assumption and nothing else.

The fix is unglamorous: a written "no session, no address" rule, a re-check at cashier load, and a test case in your quarterly control review that tries to fund an account over a VPN from a prohibited market and expects to fail.

Audit log retention. This row has no single owner, which is exactly why it gets dropped. Your platform keeps geo enforcement logs for as long as its default retention policy says, which might be 90 days.

Your PSP keeps screening results and Travel Rule payloads on its own schedule. Neither of them keeps your composite record, and neither is under any duty to outlive your contract term.

Your retention obligation sits with the licensee and typically runs five years or more. So pin down retention periods per vendor in writing, export on a schedule rather than on request, and store the exports somewhere you control.

The rest of the table hides plenty of nuance too. Ownership shifts with the model. Some aggregators subcontract the cashier entirely.

Some white label agreements make the licence holder, not you, the configuring party. And a handful of payment providers will only screen if you explicitly turn it on and pay for it. Check your own contracts. Market norms are not a defence.

How does LightningPay screen inside the payout call itself?

LightningPay runs sanctioned-address and risk screening inside the payout API call. Every withdrawal gets checked, then cleared or held, before funds leave treasury, with VASP counterparty data captured on the same request.

No separate batch job to schedule. No nightly reconciliation window where an unscreened payout slips out. No second system to keep in sync with the first.

That design choice comes straight from the constraint this article opened with. On a third-party platform, you cannot patch the withdrawal endpoint. You cannot inject a screening step into someone else's payout flow.

You cannot force a hold state into a ledger you don't control. You cannot retro-fit Travel Rule field capture into a cashier you didn't build. If screening doesn't live in the payment layer, it isn't a control. It's a paragraph in a policy document, which is a very different thing.

Capturing counterparty data on the same request also solves an evidence problem that only surfaces later. When a supervisor asks about one withdrawal from fourteen months ago, the screening result, the decision, the decision-maker, the timestamp and the beneficiary data come back as a single record.

Not three CSV exports from three vendors, two of whom have changed account managers since.

Which clauses should you demand, and from whom?

Demand three things, from the party that actually performs the control: execution, evidence, speed.

From your platform provider:

• A blocked-jurisdiction configuration that you own and can change.

• A maximum implementation lead time for list changes, expressed in hours.

• Immutable enforcement logs with effective timestamps, exportable, with a stated retention period.

• VPN and proxy detection on by default, with ASN-level attribution and a documented tuning process.

• A "no session, no deposit address" rule, plus a jurisdiction re-check at cashier load.

• A right to audit and to run your own test cases on request, in a real environment.

From your payment provider:

• Pre-payout screening as standard, not as an upsell or a toggle.

• Named screening data sources and list-update frequency.

• Travel Rule network connectivity, listed by name, and a stated fallback when a counterparty is unreachable.

• Retention periods and hit-notification SLAs with a clock on them.

• Exportable per-transaction evidence packs an auditor can read without a translation layer.

Three clauses go missing again and again. Each one costs money later.

A notification obligation with a deadline. How fast are you told about a sanctions hit, a held payout, a failed Travel Rule exchange? Your own reporting clocks run from when you knew or should have known. A vendor sitting on a hit for three days is spending your statutory window.

Data portability on exit. Switch providers and the screening records, Travel Rule payloads and enforcement logs come with you, in a usable format. The retention duty stays with the licensee whether or not the vendor relationship does.

The right to bring your own vendor, with no platform veto. Nobody asks for this clause. Everybody eventually wants it. Reserve, in writing, the right to integrate a third-party geo and device-intelligence provider, or your own crypto payment provider, without the platform withholding consent, slapping on a punitive integration fee, or slow-walking the API work for six months.

Platform providers love bundling the cashier and the geo module, because that's sticky revenue. If their false-negative rate becomes your licence condition, you need to be able to move. A consent clause you never negotiated is how you end up married to a control you don't trust.

Keep this exercise separate from your broader AML programme design. Who writes the business risk assessment, who acts as nominated officer, what triggers enhanced due diligence: different map, different owners. This one is narrowly about two technical controls and where they physically execute.

Final thoughts

Here's the uncomfortable shape of the model. Enforcement is distributed across parties who hold no licence. Accountability sits with one party that cannot deploy code.

No vendor relationship fixes that. No friendlier account manager fixes it either.

You fix it in contract design, by turning every control into three concrete things: a named owner, a measurable lead time, and an exportable log you can hand to a supervisor without a follow-up request.

Operators who treat platform and PSP agreements as evidence-supply contracts end up with a defensible position when the questions start. Operators who treat compliance as a checkbox on a feature comparison find the gap during an audit, which is the most expensive possible moment to find anything.

One test before your next renewal. For every control in this article, can you name the clause, the log and the lead time? Everywhere the answer is no, that's your work list.

Talk to the LightningPay team about the payment-layer half of it, and take the same list to your licence counsel, because how these obligations bite is jurisdiction-dependent and this article is not legal advice.