Compliance in a stablecoin API is split between three parties. The provider owns the regulated checks: it verifies and screens each customer, monitors transactions and holds flagged ones. Your company owns the data it sends, its answers to a hold, and its own licensing and reporting. The rails, the bank partner and the blockchain, add controls but take over neither.
A Head of Payments who signs an API contract asks one question: "so who is on the hook?" The honest answer is a table with three owners and fifteen rows, and the rows you assume belong to the provider are the ones that bite. The AML program guide covers how to build the program itself and is not repeated here.
Who owns each compliance task in a stablecoin API?
The provider owns the checks that need a regulated entity and a view of every party. Your company owns the inputs, the answers and anything tied to its own status. The rails, meaning the banking partner and the blockchain, own a narrower set of checks of their own.
Responsibility for each compliance task, by owner. The split is typical; your contract and your jurisdiction set the real one.
Task | API provider | Your company | Rails (bank partner, blockchain) |
Decide what data and documents are required | Sets the list per customer type | Follows it | Bank partner may add its own requirements |
Collect data from your users | Provides the endpoints and the form | Collects it accurately and sends it | None |
Terms of service acceptance | Publishes the terms, blocks verification until accepted | Gets each customer to accept | None |
Identity checks (KYC, KYB) | Runs them and decides | Passes data and documents through | None |
Sanctions and wallet screening | Screens customers, destinations and transactions | Does not onboard parties it knows are sanctioned | Bank partner may apply its own screening on the fiat leg |
Transaction monitoring (KYT, know your transaction) | Monitors and puts flagged payments on hold | Stays reachable when a payment is held | Bank partner may apply its own controls on the fiat leg |
Answering a hold | Asks, reviews and releases or refunds | Answers with the real purpose and relationship | None |
Suspicious activity reports | Depends on the regime that applies to the provider | Raises concerns through the provider's channel; own duties depend on your status | Depends on the bank partner's regime |
Transaction limits | Sets them by verification tier | Checks remaining headroom before it sends | None |
Parties behind your customers | Requires each one to be visible | Onboards each one, or does not pool them | None |
Holding the money between steps | Custody of the wallet and the balance | Keeps its own ledger of what it owes users | Bank partner holds fiat balances |
Your own licence or registration | Not its job | Yours to assess with counsel | None |
Reports to your own regulator | Not its job | Yours | None |
Travel Rule duties of your own business | Not decided by the API | Decided by your regime and counsel | None |
Finality of the transfer | Executes it | Decides whether to send | Network confirms it, with no concept of identity |
On Lumx, the first rows are handled in the API: the customer object carries the requirements and the verification status, and the checks run before the customer can transact (identity verification in the docs).
Why the API provider carries KYC, KYB and screening
The provider carries identity checks because it is the one party that sees every customer, so a single standard applies to all of them.
For an individual, the check is KYC (know your customer, the verification of an individual). For a company it is KYB (know your business, the verification of a company and its owners), which covers the company's formation documents and each representative, owner or shareholder above a threshold. The KYB explainer covers what a company has to show, and the KYB onboarding flow covers the screens that collect it.
What stays on your side is the quality of what you send. A name that differs between the ID and the ownership chart becomes a rejection, and the rejection lands on your support queue. Sanctions work the same way: the provider screens, and you avoid onboarding people you already know are on a list. The US Treasury's Sanctions Compliance Guidance for the Virtual Currency Industry, published in October 2021, tells the sector to run a risk-based program, and notes that screening only direct customers can miss the people behind them.
On Lumx, every customer accepts the terms of service first, and until they do the verification link is withheld. KYC runs through Sumsub. Lumx targets one business day for KYB (effective November 2026), and a customer moves through UNDER_VERIFICATION to APPROVED, RFI (request for information, a compliance request for a correction or document, on a customer, an account or a transaction) or FINAL_REJECTION (identity verification in the docs).
Where transaction monitoring and holds sit
Monitoring sits with the provider because it needs a view across customers: a pattern that looks normal inside one company's data can look odd across many. When a payment is flagged, the provider pauses it and asks questions.
The usual questions are the relationship between sender and receiver and the purpose of the payment. Your company's part is being reachable and answering with the real reason. A hold on a Travel Rule data gap is a related case, covered in the Travel Rule hold-or-return workflow. Payouts that fail for other reasons are covered in why stablecoin payouts get rejected.
On Lumx, on-ramps and off-ramps flagged by transaction monitoring are put on hold pending review. Chainalysis KYT covers blockchain activity only, for every type of wallet, including funds received from an external address; fiat legs are monitored with Lumx's own systems and the oversight of its banking partners, and the rules themselves are internal compliance policy. Compliance reviews the flagged transaction and, if it is not a false positive, contacts you by email or Slack with the details. If you do not respond within 24 hours, the transaction may be refunded to the sender (Request for Information in the docs). The 24-hour window applies to every transaction. A limit-increase request is not a transaction RFI, unless approving a transaction depends on it. A customer in review gets a customer.rfi webhook, and a virtual account gets account.rfi. Customer RFIs reach the API only for documents so far: an open question about how the business works still comes by email or Slack. Lumx plans an RFI API for accounts by the end of 2026 and one for transactions between the end of 2026 and the first quarter of 2027.
Which regulated party sits behind a stablecoin API
The regulated party is the one that receives, stores or transmits the money, and the label depends on the country. In the US, FinCEN's guidance FIN-2019-G001 of May 9, 2019 treats a hosted wallet provider, one that holds value on behalf of account holders, as an account-based money transmitter, with the AML program duties that come with that. Elsewhere the equivalent is a VASP (virtual asset service provider, the FATF term), mapped in the VASP explainer.
Lumx has applied for SPSAV authorization (Sociedade Prestadora de Serviços de Ativos Virtuais, the company type authorized by the Central Bank of Brazil) and operates in the transition regime under BCB Resolution 520/2025, Article 88, and it is a FinCEN-registered MSB (money services business, the FinCEN registration category). Lumx is not a bank. In the EU and the UK, EUR and GBP run through a banking partner, not a Lumx licence, and UK customers are onboarded by reverse solicitation. On the reporting side, in Brazil Lumx identifies external transfers and reports them to COAF, and in Colombia the reports to the UIAF are the banking partner's. The supported countries page lists the countries Lumx supports.
What stays with your company however good the API is
Four jobs never move to the provider: the data you collect, the answers you give, your own licence, and your own reports. The last two depend on what your company is, not on which API you picked.
The Travel Rule is the legal duty that surprises teams. Whether your business has its own depends on its status and the countries involved, and the global Travel Rule guidelines explain how the rule is built.
I recommend naming one person on your side who owns the compliance channel with the provider, with a deputy, before the first transaction goes live. I would put the provider's hold notices in a mailbox that a person reads on weekends, because a 24-hour window does not stop for them. And I would write down, in one page, which of the table's rows your company owns, because the day a hold arrives is the wrong day to find out that nobody does.
On Lumx, the customer sends accurate data, registers each destination with the right holder relationship, and answers compliance requests (identity verification, Request for Information and nested payments in the docs).
Who is liable when a check fails, and what should the contract say?
The contract, and the regime that applies to each party, decide who answers for a missed check or a fine. Ask counsel, and read the clauses before the first hold.
Ask the provider to put four things in writing:
Hold handling: How fast a held payment is reviewed, who contacts whom, on which channel, and how long you have to answer.
Rejection and refund rules: What happens to the money if you do not answer, and who bears a refund's cost.
Prohibited categories: Which businesses are refused or need extra review, and how you hear of changes.
Structures outside the standard flow: Whether a nested setup is allowed, and who approves it.
On Lumx, compliance contacts you by email or Slack on a hold, and a transaction left unanswered for 24 hours may be refunded to the sender (Request for Information in the docs). The standard contract covers the sequence for returning funds on exit, the export of history and addresses, and a liability cap. A structure that looks nested needs written pre-approval from Lumx compliance, and the prohibited business activities page lists what is refused.
Why every payer and payee has to be visible
A provider cannot check a party it cannot see, so it requires every payer and payee to be an onboarded customer acting with its own funds. Funds that belong to someone else, invoices that name another entity, or one account collecting for several businesses are the signs of nesting.
One question settles most cases: whose money is it, and whose business does it pay for? If either answer is a party the provider has not onboarded, the flow is nested. The fix is to onboard each seller, employer or end user as its own customer.
On Lumx, each customer gets a custodial wallet provisioned with the customer and enabled once it reaches APPROVED, and a named virtual account where an account is needed (custodial wallets and named virtual accounts). Each payout debits the customer's own wallet to a destination registered under that customer, with a holder relationship such as SELF or SUPPLIER (destinations in the docs), or goes to another onboarded customer. Transaction limits sit on top, and an overage fails with TRANSACTION_LIMIT_EXCEEDED (transaction limits in the docs).
When a stablecoin API is the wrong place to look for compliance cover
An API is the wrong cover when a team assumes the contract moves a duty it cannot move. Two cases stand out. If your product takes possession of money for others, you may need your own authorization, because a provider's authorization does not extend to you. And if your customers are in a business the provider prohibits, a refusal after launch is expensive, so check the public list before the build.
On Lumx, the prohibited business activities page lists what needs enhanced due diligence and what is refused, and the nested payments page covers pooled structures, where a structure that looks nested needs written pre-approval from Lumx compliance.
What this looks like on Lumx, from onboarding to a hold
Lumx is stablecoin payments infrastructure for businesses that move money between Latin America and the rest of the world: one API to collect, hold, convert, and pay out in BRL, MXN, COP, USD, EUR, and GBP or in USDC and USDT, over local rails such as PIX, SPEI, PSE, Bre-B, ACH, FEDWIRE, SEPA, and Faster Payments, with SWIFT and on-behalf-of payments and collections (POBO and COBO) in USD, EUR, and GBP, plus named virtual accounts, custodial wallets, and KYB/KYC built in.
The platform creates a customer, collects the terms acceptance, submits data and documents, and waits for customer.approved. A customer that needs a correction gets customer.rfi, and the platform resubmits. Once approved, the wallet opens, destinations are registered, and payments flow within limits.
Methodology and sources
US Treasury OFAC, Sanctions Compliance Guidance for the Virtual Currency Industry, read in full on November 1, 2026 (published October 2021). FinCEN, FIN-2019-G001, Application of FinCEN's Regulations to Certain Business Models Involving Convertible Virtual Currencies, May 9, 2019, section 4.2.1 on hosted wallet providers, read on November 1, 2026.
BCB Resolution 520/2025 is cited by number and article only, for Lumx's own standing. The FATF page blocks automated access, so the VASP definition is cited by name.
Lumx behavior read on November 1, 2026 from identity verification, Request for Information, nested payments, transaction limits, destinations and prohibited business activities at docs.lumx.io.
Verified on November 1, 2026. Operational context, not legal, tax, or investment advice.
Cover photo: Alexander Gluschenko on Unsplash.
Who owns compliance in a stablecoin API?
The provider owns identity checks, sanctions screening, transaction monitoring and holds, because it is the regulated party moving the money. Your company owns the data it sends, the answers it gives to a hold, and its own licence and reporting duties. On Lumx, KYB, the verification of each destination and the conversion from stablecoin to local currency run inside the API, and the customer answers compliance requests when a transaction is held.
Do I still need to run KYC if the API provider does?
You collect the data and the provider verifies it, so you build no identity check of your own. You stay responsible for accuracy and for getting each customer to accept the terms. On Lumx, a customer cannot transact until verification reaches APPROVED, and a name or document that does not match comes back as an RFI to correct.
What happens when a stablecoin transaction is put on hold?
The provider pauses it, asks about the relationship between the parties and the purpose, then releases or refunds it. On Lumx, flagged on-ramps and off-ramps are held for review, compliance contacts you by email or Slack, and a transaction left unanswered for 24 hours may be refunded to the sender.
Does using a stablecoin API mean I do not need my own licence?
Not automatically. The provider's regime applies to the provider. Whether your product needs one depends on whether you take possession of money for others, which a lawyer should check. On Lumx, compliance and conversion run inside the API, and whether your own product needs an authorization is a question for your counsel.
Who is liable if the provider's check fails or a fine lands?
The contract and the regime that applies to each party decide it, so get hold handling and refund rules in writing. On Lumx, compliance contacts you by email or Slack on a hold, a transaction unanswered for 24 hours may be refunded to the sender, and a structure that looks nested needs written pre-approval from Lumx compliance.
