Who does what: compliance roles in a crypto payout flow

Teams building crypto-to-local-currency products usually start with the routing problem and reach the compliance question late. That ordering is backwards, because the compliance structure determines what the software is allowed to do. This article maps the responsibilities without giving legal advice — the specifics vary by jurisdiction, and a qualified adviser in each market is not optional.

Three questions that define your regulatory position

1. 1Do you hold or control customer funds at any point, in crypto or fiat?
2. 2Do you accept value from one person and make it available to a different person?
3. 3Do you exchange between crypto and fiat as a business activity?

A yes to any of these generally places an entity inside a regulated category — money transmission, payment services, or virtual asset service provision, depending on the market. A product designed so that all three answers are no, with licensed partners performing those functions, sits in a materially different position. Neither structure is better in the abstract; they are different businesses with different obligations, capital requirements and timelines.

The responsibility map

Technology platform (orchestrator)

• Builds unsigned transactions and hands them to the user's wallet for signature.
• Requests quotes, selects routes, and presents fees and rates transparently before commitment.
• Verifies on-chain deposits independently and records them.
• Maintains the payment state machine, event log, ledger and receipts.
• Passes the customer to a licensed partner's identity flow and stores only what it needs to reference the outcome.
• Provides status, reporting and support tooling.

Licensed institution (settlement and payout partner)

• Holds customer funds, in stablecoin or fiat.
• Performs customer due diligence: identity verification, document checks, and where required source-of-funds enquiry.
• Runs sanctions and politically-exposed-person screening at onboarding and on an ongoing basis.
• Monitors transactions for suspicious activity and files reports where obliged.
• Initiates fiat payments over domestic rails and owns the relationship with the banks providing that access.
• Handles regulatory reporting and examinations in each market.

Blockchain analytics: a shared responsibility

Crypto introduces a compliance dimension traditional payments do not have: the provenance of an incoming on-chain transfer. Payout institutions increasingly require screening of the depositing address against sanctioned entities, mixers and known illicit clusters. Practically, this means the orchestrator often integrates blockchain analytics even though the payout partner owns the ultimate decision — because it is cheaper to decline a deposit before conversion than to unwind one afterwards.

Two design implications follow. First, screening must happen before the conversion leg, not after. Second, your state machine needs a first-class "declined for compliance reasons" path with a defined return process, because on-chain funds you cannot pay out must go somewhere.

Data protection sits alongside, not inside, financial compliance

Identity verification produces sensitive personal data: government documents, biometric templates, addresses. The obligations attached to it come from data protection law, not payments law, and they are separate. The safest architectural choice for an orchestrator is to never hold it — let the verification provider or licensed partner collect it directly, and store only a reference and a status. If you do hold any of it, minimise, encrypt, define a retention period, restrict access by role and log every access.

What to build before a partner is in place

Waiting for a licensed partner before writing any compliance-adjacent code wastes the wait. The following can all be built, tested and demonstrated in advance, and each one shortens the integration later.

• A verification status model with the states a real provider will return: not started, pending, information requested, approved, rejected, expired.
• Blocking logic that prevents the flow from advancing without an approved status, tested against every state.
• An operator review interface with an audit log of who approved or rejected what, and when.
• Screening hooks positioned before the conversion leg, with a decline-and-return path.
• Role-based access control and row-level security on every table holding customer data.
• Retention and deletion routines, so a data subject request is a procedure rather than a project.

Say what is real

The commercially tempting move — describing a simulated flow in the present tense — is the one that destroys credibility fastest, with users, partners and regulators alike. A clear capability status on every claim costs nothing and is the strongest trust signal an early product has.

LamportPay is structured as a technology platform. It does not custody funds, does not perform real identity verification, does not convert to fiat and does not transmit money to third parties. The identity and payout steps in the product are simulations, labelled as such, and exist so the architecture and operator tooling can be evaluated ahead of a regulated payout infrastructure partner being in place. The live components are the wallet connection and a strictly limited SOL-to-USDC swap whose output returns to the user's own wallet.