Who Owns AML in a White-Label Crypto Payment Gateway?

In a white-label crypto payment gateway deal, the provider typically owns wallet infrastructure, blockchain analytics, custody or noncustodial rails, and settlement mechanics.

The operator almost always remains legally responsible for player KYC, source-of-funds checks, license conditions, transaction monitoring outcomes and all reporting to its gaming regulator and FIU.

What does "white label" actually mean in a crypto payment gateway context?

A white-label crypto payment gateway is a payment stack somebody else built, hosts and maintains, wearing your brand. You license the technology. You do not license the provider's regulatory standing, and nobody has ever managed to.

That distinction is where compliance committees come unstuck. The commercial conversation is about branding, coverage, fees and settlement speed.

The regulatory conversation is about who picks up the phone when a gaming regulator traces a 40,000 USDT deposit to an address clustered with a sanctioned exchange.

That call comes to you.

White labelling moves engineering effort, key management, node infrastructure and chain-screening capability off your roadmap and onto the provider's. Useful. It moves nothing attached to your Curaçao, Malta, Isle of Man, Anjouan or Tobique authorisation, and nothing attached to the national or state rules in the markets you actually serve.

Two adjacent terms get used loosely, so be precise in your paperwork. White label crypto payment gateway software is the licensed technology: wallet layer, screening integrations, settlement logic.

White label crypto payment gateway development is the build and customisation work, including your branded deposit flow and the API glue. Neither phrase describes a transfer of regulatory liability. If a sales deck implies otherwise, that is a finding, not a feature.

The compliance perimeter has three layers, and only one is for sale

Most bad allocation arguments happen because both sides are talking about "compliance" as if it were one thing. Split it into three layers and the negotiation gets much shorter.

Layer 1 — Payment infrastructure

Wallets, keys, address generation, confirmation thresholds, chain reorg handling, on-chain screening, Travel Rule messaging plumbing, settlement execution. This is the layer a provider genuinely sells, and a good one is far better at it than your in-house team will ever be.

Layer 2 — The player relationship

Who this person is, whether you're allowed to serve them, where their money came from, what their behaviour looks like over ninety days, whether their deposit pattern belongs in a monitoring alert. This layer is yours. Always. A provider can supply tooling into it. It cannot own it, because it has no contract with your player and no licence to serve them.

Layer 3 — Regulatory reporting

SARs to your FIU, key event notifications, regulatory returns, responses to information requests, audit production. Yours entirely. There is no version of this deal where a payment vendor files on your behalf.

Layer 1 is procurement. Layers 2 and 3 are governance. Vendors sell Layer 1 and let you assume Layers 2 and 3 came free in the box. They didn't.

Which obligations does the provider genuinely absorb?

There's a real set here, and being clear about it stops you over-building internally and paying twice for the same control.

Wallet infrastructure and key management

Address generation, key custody or non-custodial signing architecture, hot and cold segregation, and the operational security wrapped around all of it. Where the provider holds keys, it carries the technical burden and usually the licensing burden for custody.

Blockchain analytics and address screening

Providers plug in chain-analysis vendors and screen inbound and outbound addresses against sanctions lists, darknet markets, mixers, high-risk exchanges and known fraud clusters. They produce the risk score. They do not decide what your business does about it.

Travel Rule messaging infrastructure

Where the provider is a regulated VASP, it may carry the technical obligation to send and receive originator and beneficiary data on qualifying transfers. Get it in writing: is the provider the obligated entity on your flows, or just the pipe carrying the message?

Chain and network integrity

Reorg handling, confirmation thresholds, memo and tag validation, stablecoin contract verification (the number of near-identical USDT contracts on some chains is its own small horror story), rejection of unsupported assets.

Provider-side entity compliance

The provider's own AML programme, its registrations, its onboarding of you as a merchant, its internal audit. Its responsibility to run. Your responsibility to inspect.

Settlement execution and reconciliation data

The provider generates the transaction ledger, settlement records and exportable evidence. Producing that evidence to a regulator four years later is on you.

Which obligations remain legally yours, no matter what the contract says?

These survive any commercial arrangement. Regulators treat them as non-delegable in substance even when a third party does the mechanics.

Player identification and verification

Your licence conditions set the triggers, the acceptable documents, the thresholds. A provider can bolt on a KYC module. Your MLRO still owns the acceptance decision and the audit trail behind it.

Source of funds and source of wealth

Crypto makes this harder, and pretending otherwise is how operators get findings. A clean chain-analysis score tells you the address isn't on a list.

It tells you nothing about where a player earning €38,000 a year found €90,000 in Tether. For escalated players, your team still has to establish provenance and write it down.

Customer risk rating and enhanced due diligence

Risk scoring is a licensee function. Chain risk is one input, sitting alongside geography, product, deposit velocity, session behaviour and PEP status.

Transaction monitoring outcomes and escalation

The provider may flag. You triage, investigate, decide, record. An unactioned flag is worse than no flag at all, because it documents that you knew and did nothing.

Suspicious activity reporting

Filing to your FIU, plus any parallel notification to your gaming regulator. No provider files for your player base, and any that offers to should be asked, slowly, on what legal basis.

Sanctions, PEP and geo-restriction compliance at the player level

Blocking a prohibited jurisdiction is a licence condition. Provider-side IP or address controls support it. They do not discharge it.

Responsible gambling interaction with crypto flows

Deposit limits, self-exclusion enforcement, affordability triggers. All must apply to crypto rails exactly as they apply to a Visa deposit. Regulators now test this on purpose, because early crypto integrations routinely bypassed the RG engine entirely.

Record retention and regulator production

Transaction-level evidence, for the full retention period in your licence, including long after the provider relationship ends.

Outsourcing governance

Documented due diligence, ongoing oversight, an exit plan, and in several jurisdictions notification or prior approval for material outsourcing. A payment gateway is material. Assume so until your regulator tells you otherwise in writing.

Who is the merchant of record, and why does nobody in crypto ask?

In card acquiring, merchant of record is a defined role with plumbing behind it. Somebody holds the MID. Somebody's name appears on the cardholder statement.

Somebody eats the chargeback, answers to the scheme rules, and signs the acquiring agreement. The role is assigned because Visa and Mastercard force it to be assigned.

Crypto has no scheme. No chargebacks, no representment window, no Core Rules document telling you who the merchant is. So the question simply doesn't get asked in most gateway negotiations, and the role goes undocumented while remaining entirely real.

It's real because a regulator, a bank, an auditor or an angry player will eventually ask a version of this: who received this money, and who owes this balance?

Custodial vs non-custodial changes the answer

Non-custodial flow. Player sends USDT to an address controlled by your entity. Funds hit your wallet. You credit the player balance. You are the merchant of record, unambiguously, and the provider is a software vendor that never touched the money. Clean story, easy to evidence on-chain, easy to explain to an auditor in one sentence.

Custodial omnibus flow. Player sends USDT to the provider's pooled wallet. The provider's internal ledger says the funds are yours. On-chain, the funds are the provider's.

Now you have two entities that can each claim to have "received" the deposit, and the commercial narrative (provider as payment processor) sits awkwardly next to the regulatory one (you hold the player contract and the balance liability).

The provider is acting as agent or custodian, not as the merchant, but unless the contract says that explicitly you're relying on a shared assumption during an examination.

Worth being blunt about the failure mode: some providers position themselves as taking receipt as principal, which sounds reassuring until you realise your player-funds segregation narrative, your licence's requirement to hold player balances, and the provider's own regulatory permissions now have to be reconciled by someone.

Usually your MLRO, at speed, in an email thread with a regulator.

Who faces the regulator when a deposit is challenged?

You do. Every time.

Take a concrete one. A player disputes a 12,000 USDT deposit, claiming account takeover. Or the FIU sends an information request naming a wallet address that touched your platform.

Or your acquiring bank on the fiat side asks why a €500,000 monthly settlement is arriving from an entity nobody at the bank has heard of. In each case the gaming regulator's counterparty is the licensee.

The provider is a witness at best, a contractual respondent at worst.

Mor contract language to insist on

• A clause naming the merchant of record for each flow, in each jurisdiction, in plain language. Not implied by a payments annex.

• An express statement of whether the provider acts as principal or agent on receipt of player funds, and whether it takes title to those funds at any point.

• Confirmation that the operator holds the contractual relationship with the player and the liability for the player balance.

• Who appears in player-facing receipts, confirmations and support flows, and whose name shows on the settlement address.

• Refund and reversal mechanics: who initiates a return to an originating address, who bears the network fee, and how the return is documented.

• An assistance obligation with a deadline, so provider support has to help you answer a regulatory information request within days rather than "when the ticket is triaged".

If the provider resists writing this down, the ambiguity is doing work for someone. Not you.

Where does the provider's own licence cover the flow, and where does it stop?

This is the boundary most operators guess at. Don't guess.

A provider's VASP, CASP or MSB registration covers the provider's regulated activity. Typically: custody of client crypto, exchange between crypto and fiat, transfer of crypto on behalf of clients, and Travel Rule obligations where the provider sits as originating or beneficiary institution on a qualifying transfer.

If the provider converts your USDT to EUR and wires it, that leg is inside its permission and it is the regulated entity for that leg.

It does not cover the following, ever. Your acceptance of a deposit as a gambling stake. Your player onboarding. Your CDD, EDD and ongoing monitoring under the AML law that applies to gambling operators in your jurisdiction.

Your reporting. Your licence conditions on payment methods, player funds and responsible gambling. A VASP permission is a financial-services authorisation. It has nothing to say about whether you were allowed to take that player's bet.

And there's a third case people miss. A genuinely non-custodial software provider may fall outside VASP and CASP scope altogether, because it never holds keys, never takes possession and never executes transfers on your behalf.

That's not a red flag.

It changes your diligence, though: you are assessing a software vendor's security, uptime, code integrity and screening vendor contracts, not a regulated financial counterparty's capital and safeguarding. Different questionnaire, different evidence pack, different exit plan.

One more practical consequence. If funds settle to your wallet in stablecoin and you off-ramp through your own exchange or OTC desk, that off-ramp counterparty is the regulated leg in your flow, and it needs its own due diligence file.

Plenty of operators diligence the gateway thoroughly and their off-ramp barely at all. The bank asking awkward questions about incoming fiat will find that gap before you do.

Does the licensing answer change by jurisdiction? yes, substantially

The responsibility split above holds everywhere. The paperwork, thresholds and appetite for crypto vary a lot.

EU and MiCA-style regimes

Under MiCA, your provider may need CASP authorisation for custody or exchange activity, and the EU Transfer of Funds Regulation applies Travel Rule data requirements to crypto transfers with no de minimis threshold.

None of that touches your gambling AML obligations, which flow from the AMLD framework as implemented locally. A Malta licensee cannot point at a CASP's authorisation to satisfy the MGA's expectations on source of funds or player-funds handling.

Two perimeters, two evidence files, and the MGA will look at yours.

United Kingdom

The FCA cryptoasset registration regime governs the provider side.

Your side is the LCCP, and the Gambling Commission's position is straightforward: crypto can be a payment method, but the licensee carries full responsibility for source of funds, customer interaction and the absence of anonymity.

Cryptoasset exposure belongs in your money laundering and terrorist financing risk assessment explicitly, and reviewers will ask to see how you got comfortable with a specific chain and a specific provider.

Offshore gaming licences

Curaçao's LOK regime, Anjouan, Tobique, Costa Rica. Regulator maturity and inspection frequency vary widely, and Curaçao in particular has tightened materially.

Two things to hold on to. First, licence conditions on payment-partner due diligence and player-funds handling still exist and are increasingly examined.

Second, even where a regulator doesn't test you, your banking, EMI or PSP partners absolutely will, and their questionnaire will be harder than the regulator's.

United States

Handle with real care. Crypto deposits in regulated state markets are effectively off the table without specific approval; New Jersey's DGE, Michigan's MGCB and Pennsylvania's PGCB all vet payment methods and vendors, and vendor registration is a live requirement rather than a formality.

On the financial side, a provider touching US persons is looking at FinCEN MSB registration plus state money transmitter analysis. If your restricted-market controls are supposed to keep US traffic out, the credibility of those controls is the entire compliance story.

Sweeping point: the further offshore your licence, the more of the diligence burden lands on you rather than being imposed on you. That's not freedom. That's unsupervised risk.

How should the responsibility split be documented?

One authoritative map. Agreed by both parties, referenced in the contract, reviewed annually, owned by a named person.

The table is deliberately blunt. All the nuance lives in the prose below it, which is the part your legal committee should actually read.

"Acts on results" is the most argued-over cell in practice. The provider hands you a risk score and a suggested threshold. Your job is to define in policy what each score triggers: auto-reject, hold for review, escalate to MLRO, freeze pending EDD, or file.

If the provider's default thresholds are sitting in production without your explicit written sign-off, you have adopted a vendor's risk appetite by accident, and you'll discover its shape during an inspection.

"No" for the provider on KYC doesn't mean the provider can't run verification steps. Many do, through embedded vendors. It means the provider performs a service while you keep the obligation.

Which is exactly why your contract must guarantee access to the underlying artefacts — document images, liveness results, database check responses, timestamps — and not just a green tick in a dashboard.

Clauses to insist on:

• Named allocation of each obligation, by flow.

• Data access and export rights in machine-readable form.

• Audit and inspection rights, including your regulator's right to inspect.

• Sub-processor disclosure plus advance change notification.

• Breach and incident notification windows measured in hours, not "promptly".

• Retention of your transaction data for your licence's full retention period.

• Assistance obligations during a regulatory enquiry, with response deadlines.

• An exit clause guaranteeing full historical data extraction on termination.

• Merchant-of-record and principal/agent language, per the section above.

• Change control on the provider's restricted-country list.

If you're weighing a crypto payment gateway white label arrangement against building in-house, that clause list is the real comparison. Not the feature grid.

For a working example of how these clauses read when the provider is built specifically for licensed gaming, look at a crypto payment gateway built for licensed operators and check its allocation language line by line against the list above.

See how LightningPay structures operator deals — including the responsibility map and evidence clauses your compliance committee will ask for.

Screening: where the provider's stack ends and yours begins

Two screening universes exist in a crypto gaming flow, and they screen different objects.

The wallet address. Chain analytics look at the address, its cluster, its counterparties and its history. Sanctions exposure here means an address appears on an OFAC SDN entry, or sits one hop from a mixer, or belongs to a cluster attributed to a sanctioned exchange.

The player record. Name, date of birth, nationality, residence, ID document. Sanctions and PEP screening here means matching a human being against SDN, UN, EU, HMT and national lists, plus PEP and adverse-media databases, with fuzzy matching and a documented false-positive process.

These do not substitute for each other, and treating them as interchangeable is one of the most common design faults I see. A clean address tells you nothing about whether the depositor is a sanctioned individual using a fresh wallet funded from a compliant exchange.

A clean player record tells you nothing about whether the funds arrived from a darknet cluster. You need both, and you need to run PEP screening on the player record specifically, because chain analytics has no concept of a deputy finance minister.

Duplicate versus complementary screening

Providers screen. You screen. Left alone, this produces two failure modes at once: gaps and double work.

Fix it with a screening matrix before go-live. For each control, write down who runs it, on what object, against which lists, at what frequency, and who reviews the hits.

• Inbound address screening: provider, at deposit, pre-credit.

• Outbound address screening: provider, at withdrawal request.

• Player sanctions and PEP screening: you, at onboarding and on a defined rescreen cycle, with ongoing list-change monitoring.

• Adverse media: you.

• Behavioural transaction monitoring across products, not just deposits: you.

• Travel Rule counterparty data: whoever is the obligated institution, confirmed in writing.

Then check the list coverage overlaps. If your provider screens against OFAC and UN but your licence expects EU and HMT too, that's a gap nobody owns. If both of you are paying for the same adverse-media feed and reviewing the same alerts twice, that's budget you could spend on an extra analyst.

Chain analytics is a supplement, not a substitute

Design principle, and I'd put it in your policy verbatim: blockchain analytics supplements customer due diligence. It never replaces it.

Attribution is probabilistic. Coverage varies by chain and by vendor. New addresses have no history at all, which is precisely why anyone with something to hide uses them.

A 92-out-of-100 clean score on a freshly funded Tron address is not evidence of legitimate wealth; it's evidence of an absence of data.

Any control framework that lets a chain score close out a source-of-funds question is going to fail its first serious examination, and the finding will be about your framework, not your vendor.

Geo-blocking and restricted markets: three control layers, one evidence file

Restricted-market controls are where crypto flows quietly break the model, because a wallet has no billing address and no issuing-country BIN. Build the control in three layers and document all three.

Layer 1 — IP and device. Geo-IP blocking on registration, login and deposit. VPN, proxy and Tor detection. Hosting-provider ASN blocking, because commercial VPN traffic mostly originates in data centres, not homes. Cheap, testable, and the first thing a regulator asks to see.

Layer 2 — Wallet and on-chain origin. Chain analytics can often attribute the sending address to a named exchange or service, and that service has a jurisdiction. A deposit arriving from a US-based exchange account, credited to a player who registered as Brazilian, is a signal worth a hold even when the address risk score is spotless. Use it as intelligence rather than an automatic block, and define which cases escalate.

Layer 3 — Payment and account level. Blocking asset and network combinations you don't want. Blocking deposit acceptance for accounts flagged with restricted residency. Blocking withdrawals to addresses attributed to services in prohibited markets. This layer catches what the IP check misses, and it's the layer most operators haven't built.

Your prohibited list is not the provider's restricted list

They overlap. They are not the same document, and conflating them causes real breaches.

The provider's restricted list protects the provider. Expect the comprehensively sanctioned jurisdictions plus wherever the provider lacks permissions, often including the US and sometimes the UK.

Your prohibited list comes from your licence conditions, your local-licensing strategy and your legal advice. A Curaçao operator might need to exclude the Netherlands, the US, the UK, France, Australia and Ontario. An MGA licensee excludes any market where local licensing is required and it doesn't hold one.

Operate the union of both lists, in one versioned document, with an owner and effective dates. Then add change control in the contract: if the provider adds three countries to its own list next Tuesday, somebody on your side has to be told before players start seeing failed deposits, and if the provider removes a country, that must never silently open a market you're not licensed for.

Document the control layer, because that's what gets tested

Regulators don't test your intent. They test the control, and then they test your evidence that the control worked.

Keep a folder that contains:

• The current restricted-jurisdiction list, versioned, with the licence condition or legal basis cited per country.

• The mapping of each list entry to the technical controls enforcing it.

• Block logs: attempted registrations, logins and deposits rejected by country and reason code.

• Quarterly negative testing. Attempt access from a blocked geography, screenshot the block, log the date and the tester. Ten minutes of work that answers an entire line of questioning.

• Change history, with who approved each change and when it went live.

Vpns and mismatches: decide the rules now, not in the incident

Mismatch scenarios are routine, not exotic. IP in Germany, ID document Brazilian, deposit funded from a US exchange. Your policy needs a pre-agreed answer for each pattern.

Write down: which mismatches trigger review versus automatic block; what happens to a session where VPN use is detected mid-play (several jurisdictions treat continued play through a detected VPN as a licence breach, so "we noticed and did nothing" is the worst option); how a player evidences genuine residence; and crucially, what happens to funds already received from a prohibited market.

Usually that means a documented return to the originating address with the network fee handled per contract, not a quiet credit and a hope.

One rule I'd make non-negotiable: never let a commercial conversation reopen a blocked market. If the answer changes, it changes through legal advice and a documented list update, with a date and a signature.

Why does the custody model change who carries the compliance risk?

Custody is the single structural variable that most changes your exposure, and it gets skimmed over in evaluations because it sounds like a plumbing detail.

In a custodial omnibus model, player deposits land in the provider's pooled wallets. Your funds sit commingled with other merchants' until settlement. Three consequences follow.

First, recovering your funds depends on the provider's solvency and the accuracy of its internal ledger.

Second, the provider's custody licensing status becomes a live component of your own regulatory position; if that licence is challenged, restricted or withdrawn, your player funds are inside the perimeter.

Third, on-chain records show provider-controlled addresses rather than yours, which weakens your ability to independently evidence flows to an auditor or regulator without leaning on provider attestations.

In a non-custodial model, funds settle directly to wallets you control. The provider never takes possession. Your exposure to provider custody licensing narrows sharply, and your settlement evidence anchors to addresses registered in your own name.

Neither model erases an AML obligation. But custodial stacks a second category of risk on top, counterparty and licensing, and your legal committee should price that separately rather than folding it into the fee comparison.

How does lightningpay's non-custodial treasury model affect compliance ownership?

LightningPay runs a non-custodial treasury model. Player deposits settle straight into wallets the operator controls instead of pooling in a provider-held omnibus account.

Three concrete effects on compliance ownership.

It narrows your dependency on the provider's custody licensing status

Because LightningPay never takes possession of operator funds, questions about provider custody authorisation, safeguarding or fund segregation don't sit between you and your players' balances. Your outsourcing risk assessment shrinks, and the "what if the provider's registration gets challenged" scenario has a much shorter answer.

It ties settlement records to your own addresses

When a regulator or external auditor asks you to evidence a deposit chain, the on-chain trail ends at an address registered to your entity. You're not depending on a provider sub-ledger to prove funds reached you, and you're not asking an auditor to accept a vendor attestation in place of primary evidence.

It removes commingling from your reconciliation narrative

Segregation of player funds is a live licence condition in several gaming jurisdictions. Where deposits never enter a pooled provider account, architecture answers the segregation question instead of policy assurance.

It also settles the merchant-of-record question cleanly, since funds arrive at your address and you hold the player contract from end to end.

What it does not change: your MLRO still owns KYC, source of funds, PEP and sanctions screening on the player record, monitoring outcomes and reporting. Non-custodial architecture narrows risk. It transfers no obligation.

Questions to put to your gaming regulator before launch

Ask before you sign, not after go-live. Written answers, kept in the file. Most authorities respond faster than operators expect, and a five-line email from a regulator is worth more than fifty pages of internal comfort.

1. Do you classify a crypto payment gateway as material outsourcing, and does it require notification, prior approval, or neither?

2. Which specific documents do you want in the outsourcing file: due diligence pack, responsibility matrix, exit plan, business continuity assessment?

3. Do you expect the provider to hold a VASP, CASP or MSB registration, or is a non-custodial software provider acceptable, and on what conditions?

4. Are stablecoin deposits accepted under our licence, and are specific assets, chains or issuers restricted?

5. How should crypto deposits be treated for player-funds segregation and reporting purposes: at on-chain receipt, at credit, or at fiat conversion?

6. What is your expectation on source-of-funds evidence for crypto deposits specifically, and at what threshold does EDD become mandatory?

7. Do you require chain-analytics screening, and do you specify vendors, lists or minimum coverage?

8. Which sanctions lists must we screen against beyond the obvious, and how often must we rescreen the player base?

9. How must our restricted-jurisdiction controls be evidenced, and do you expect independent testing?

10. Is a change of payment provider a key event requiring notification, and what is the deadline?

11. What retention period applies to crypto transaction records, and will you accept provider-generated exports as primary evidence?

12. Are there reporting templates or key-event categories specific to crypto deposits we should be filing from day one?

Take the answers into the vendor negotiation. They'll change what you're willing to sign.

Final thoughts

White labelling a crypto gateway shifts the technical burden competently and permanently. It never shifts the licence, and no clause can make a provider the licensee for your players. So the quality of the deal is decided almost entirely by allocation and evidence clauses, not by dashboard polish or the number of chains supported.

Two architectural choices genuinely change your exposure rather than relocating it: custody structure, and whether the merchant-of-record position is written down or assumed. Everything else is either governance you have to do anyway, or a control you can buy.

Operators who build the responsibility map before signature find that regulator conversations turn into short documentary exercises. Operators who build it during an audit find out what retrospective allocation costs, usually in legal fees and licence conditions. Treat the map as a governance artefact you maintain quarterly, not a procurement document you file and forget.

Talk to the LightningPay team about your licence conditions before your compliance committee meets.