We have spent the past six months in conversations with payments companies: acquirers, PSPs, processors, partners across geographies. At events, in partner meetings, in one-on-ones with risk teams. One pattern is unmistakable. Compliance is the first question. Especially from established card acquirers. Very often, it is the question that decides whether the conversation moves forward at all.
Why does compliance decide every conversation with established acquirers?
Two obligations sit underneath that.
The legal obligation. Your licence as an acquirer is specific. It spells out exactly what payments you're allowed to process, what data you can hold, and what checks you have to run. If a new payment method needs you to do something outside that, say, hold a type of asset you're not authorised to hold, or screen users in a way your licence doesn't cover, you can't plug it in. It's not a preference. It's a hard legal line.
The moral obligation. You sit in the middle of the chain. Your merchants trust you to only pass clean transactions through. Consumers trust the whole system because they trust you. If a bad transaction slips through on a new rail, that trust breaks, and the fallout lands on your merchants and your scheme relationship, not on whichever payment method let it through.
Other questions matter too. Every acquirer evaluating a new rail is also weighing:
- Operational fit. Will this reconcile and settle like the APMs already in the stack?
- Merchant outcomes. Will merchants adopt it?
- Liability. Who owns what obligation across the chain?
- Risk-committee legibility. Can this be explained in the language my controls framework already speaks?
- Commercial model. Does the economic case hold?
All of those are relevant. But compliance sits upstream. If the method cannot fit inside the programme the institution already runs, the rest of the conversation never happens.
That is why we start here.
Why does the data-layer question come first?
Three obligations drive the question.
Travel Rule
Under MiCA and the Transfer of Funds Regulation in the EU, and equivalent regimes in the UK, Switzerland, and Singapore, intermediaries have to exchange originator and beneficiary data on qualifying transfers. The FATF sets the global standard.
Sanctions screening
Wallet addresses, identity attributes, and IPs have to be screened against OFAC, UK HMT, and EU Consolidated lists before a transaction executes.
Data protection
GDPR and equivalent regimes govern how any of that data is collected, stored, shared, and retained.
Most crypto payment methods were designed as crypto-native products and retrofitted later for regulated distribution. The result is a parallel compliance surface the acquirer has to absorb: new controls, new logs, new data classes, new reporting lines. That model does not clear a risk committee.
WalletConnect Pay was built the other way round. The compliance and data layer was designed first, and it maps to the obligations above using formats regulated institutions already operate.
What information does WalletConnect Pay collect?
Three fields, captured once, before the checkout experience begins, inside the user's own wallet:
- Full legal name
- Date of birth
- Place of birth
Two additional data points are captured at each transaction: the user's wallet address, provided by the wallet connection, and the IP address.
That is the complete set.
What does this mean in practice? The user enters three fields once, inside their wallet, before any checkout begins. Every future payment reuses that data automatically. At checkout, the method also picks up the wallet address and IP for that session. Nothing else is collected.
The important frame for an acquirer: this is Travel Rule originator data. The same class a correspondent bank already attaches to a wire transfer under FATF Recommendation 16. Not a new data category. A familiar one, surfaced through a new rail.
For the field-by-field mapping to each jurisdiction's variant, and the technical walkthrough of how the data flows to regulated partners at settlement, see our recent policy paper on self-custodial wallets in regulated financial flows.
What does the acquirer see, and what stays with WalletConnect Pay?
The split is deliberate.
The fields that flow to the acquirer are the fields existing compliance and reconciliation systems already parse. The fields that stay inside WalletConnect Pay are the ones the institution does not need to hold to discharge its obligations.
Behind the scenes:
- Pre-execution screening runs at wallet connection against OFAC, UK HMT, and EU Consolidated lists. Lists refresh multiple times a day.
- Every screening event is retained per record-keeping requirements.
- Data protection, security, and audit controls align with the standards regulated institutions already operate against.
The policy paper carries the full technical walkthrough.
What makes this different from other crypto payment methods? Most were designed crypto-native and retrofitted for regulated distribution. That leaves the acquirer absorbing a parallel compliance surface. WalletConnect Pay was built the other way round: the data and compliance layer came first, and maps to obligations acquirers already discharge today.
Where does WalletConnect Pay stop?
The method is explicit about what it does not do:
- No full retail-buyer KYC
- No identity document verification or AML risk scoring
- No ongoing transaction monitoring
- No custody, transmission, or conversion of assets
Those responsibilities stay with the entities licensed to perform them: the settlement partner, the offramp provider, the wallet, and the acquirer itself. WalletConnect Pay provides a front-line control that plugs into the existing compliance surface. It does not replace it, and it does not ask the acquirer to take on any new obligation.
How does this map to controls acquirers already run?
A short translation, for the risk committee:
- Travel Rule originator data ≈ FATF Recommendation 16 wire-transfer data.
- Pre-execution sanctions screening at wallet connection ≈ sanctions screening embedded in card authorisation.
- Audit log per screening event ≈ transaction-level audit trails acquirers already maintain.
The data class, the screening pattern, and the audit trail each map to controls already in production.
One operational note worth flagging, because it matters for the merchant book: data collection happens once, at wallet setup, not at every checkout. That puts WalletConnect Pay's conversion profile closer to card-on-file than to a typical crypto payment flow.
- Returning users skip straight to confirmation.
- First-time users spend roughly two minutes inside their own wallet. Once.
Where is the rest of the industry heading?
Our recent WalletConnect policy paper makes the case that compliance for self-custodial wallets belongs at the regulated interface, not at the wallet itself. It draws on:
- FATF's 2025 Targeted Update on stablecoins and unhosted wallets
- MiCA and the EU Transfer of Funds Regulation
- EBA's 2024 guidance on unhosted wallets
- The GENIUS Act, passed in the US in July 2025
Every one of those frameworks points the same way: compliance obligations sit with the regulated intermediary, and the technical tools now exist for that intermediary to discharge them without excluding self-custodial wallets from the flow.
Live examples are already in production:
- Circle operates on-chain freeze and blacklist controls on USDC and EURC at the request of law enforcement.
- Mastercard Crypto Credentials anchors a reusable, KYC-verified identity credential to a wallet address. Live for peer-to-peer transactions in Latin America since May 2024 and expanding across networks.
- LEI and vLEI credentials extend the same logic to corporate counterparties.
WalletConnect Pay sits inside that trajectory. The compliance architecture described here is one instance of a direction the industry and the regulatory consensus are already moving toward.
How do you add WalletConnect Pay?
It's an API integration, structured the same way your team already integrates any APM.
ame APM pattern, wired to a new rail.
What should acquirers take from this?
- The data the method collects fits the programme already in place. Travel Rule and sanctions obligations are discharged in formats existing compliance and reconciliation systems already parse. No new data class. No new reporting line.
- Responsibilities are cleanly separated. WalletConnect Pay runs pre-execution screening and Travel Rule data transmission. The acquirer, the settlement partner, and the wallet keep the obligations they are already licensed to hold. Nothing crosses the line.
- The rail is routable, reconcilable, and reportable through systems already in production. No parallel compliance surface. Nothing the risk committee has to approve and monitor from scratch.
For wider regulatory context, download the recent policy paper. For integration specifications, sandbox access, or a commercial conversation, speak to the team.