Anti-money-laundering rules were written for institutions that move money, and a fintech that moves stablecoins is one of those institutions in a growing number of jurisdictions. The obligations that follow are mostly familiar ones: know who the customer is, keep a record of what moved, and send identifying information along with the transfer. What changes with stablecoins is where the data lives and how hard it is to assemble, not what the rule asks for.
This post describes what several of those rules say, in the text of the instruments themselves. It does not say whether any of them applies to a particular business, which depends on facts about the business that no article can supply.
The duty attaches to the institution
Read almost any of these frameworks and the pattern is the same: the obligation is imposed on a defined category of person, and the asset is incidental. Brazil's anti-money-laundering statute, Law 9.613 of March 3, 1998, lists in its Article 10 the duties of the persons it covers, beginning with identifying customers and maintaining an up-to-date record of them. Its Article 10, II requires a record of every transaction above the limit set by the competent authority, and in the wording given by Law 14.478 of December 21, 2022 that duty names virtual assets alongside national currency, foreign currency and securities.
The practical reading of that amendment is worth being precise about. It did not create a new regime for stablecoins. It extended an existing record-keeping duty so that the same obligation covers the same activity performed with a different instrument. A business that already knew how to keep those records has a data problem rather than a policy problem.
What record keeping means when the record is split
A single cross-border payment produces records in at least three places: your own system, your provider's, and the blockchain. The obligation is to be able to produce a complete account of the transaction, and a complete account is one where those three can be joined.
That is why the reference you attach at creation matters as much for compliance as it does for accounting. A transaction that carries your own order or payroll identifier can be reconstructed from either end. A transaction identified only by an amount and a date can be reconstructed by a human, slowly, and only while the people who remember the flow still work there.
The same logic applies to the counterparty. A record that a payment went to an account number satisfies less than a record that it went to a named, verified party whose identifying data you already hold, and the second is what an examiner asking about a specific payment is trying to reach.
The travel rule in the words it is actually written in
The rule most often discussed in the abstract has a concrete form in United States regulation. Under 31 CFR 1010.410(f), for a transmittal of funds of 3,000 dollars or more, the transmittor's financial institution must include in the transmittal order the transmittor's name, the transmittor's account number if the order is made from an account, the transmittor's address, the amount, the execution date, and the identity of the recipient's financial institution, and must retain the items it receives.
Two things follow from reading the actual text. The first is that the threshold is a number, not a principle, and other jurisdictions set it elsewhere, which is why an international flow can be subject to different thresholds on each leg. The second is that the rule describes a list of fields travelling with a payment instruction, which is an engineering specification as much as a legal one. How the same obligation appears in other frameworks is set out in guidelines for the travel rule.
For a payments business, the useful question is not whether the rule applies in the abstract. It is which entity in your flow is the transmittor's institution, because that is the party the field list is imposed on, and the answer changes with the structure you chose.
Onboarding is where most of the work lives
Identification is the obligation that consumes the most product surface, and it is the one users experience. For a company, this is KYB (know your business, the verification of a company and its owners), and for an individual it is KYC (know your customer, the verification of an individual). The company case is the harder one because ownership is a graph: a company owned by another company owned by a fund is verified by walking up that structure until natural persons appear.
Two design decisions determine whether this costs you customers. Ask for documents in the order a person can actually supply them, rather than collecting the full list up front. And treat the middle state as a real state, because verification produces a yes, a no, and a request for one more document. An RFI (request for information, a compliance hold that asks for a document before a transaction clears) that arrives in your system as structured data can be shown to the customer with the specific document named. One that arrives as an email becomes a support ticket.
What the verification actually covers is in what KYB is, and the shape of the flow around it is in onboarding business users.
Monitoring does not end at onboarding
Identification is a point in time and the duty is continuous. Ownership changes, sanctions lists change, and a customer whose declared business was software consulting starts sending payouts that look like a remittance operation. The obligations in these frameworks generally include keeping customer records current and reporting transactions that meet defined criteria, which means a periodic review rather than a one-time check.
The part that surprises product teams is that the monitoring has to be able to explain itself. A rule that stops a payment and cannot say which attribute triggered it produces an operations queue that no one can clear, and the pressure to widen the rule until the queue empties is the failure mode that follows.
My position on this is stricter than what the rules require, and it is a position rather than a reading of any instrument: a control that a support agent cannot explain to the customer in one sentence is a control that will be quietly disabled within a year. The reason is organisational rather than technical. Nobody switches it off deliberately; the threshold gets raised once under pressure, then again, and the audit finds a rule that fires on nothing. I would rather ship a narrower control that survives contact with an operations team than a broad one that does not.
When a fintech should not build this in-house
If the regulated activity belongs to a provider you are integrating with, building a parallel verification stack duplicates work and creates two answers to the same question about a customer. The cost is not the build, it is the divergence: a customer approved in your system and rejected in theirs is a support conversation nobody can win.
It is also the wrong investment when you operate in one country and expect to stay there. The case for owning this layer grows with the number of jurisdictions whose requirements differ, and a single-market business is buying flexibility it will not use. Which jurisdictions a business can actually onboard in is listed on the supported countries page, and that list is the practical constraint long before any framework is.
And it is the wrong project for a team that cannot staff the operations side. Verification generates decisions that a human has to make, every day, including weekends if your payouts run then. Software that routes those decisions to nobody is worse than no software.
How this sits in a payments integration
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, 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.
Verification is part of the object model rather than a service beside it. A customer is created and verified before its wallets are enabled for use, so the compliance state and the ability to transact are the same fact rather than two systems that have to agree. Company ownership is expressed by nesting shareholders, which is what lets a structure with intermediate holding companies be represented instead of flattened.
Requests for additional information arrive as events carrying the customer they concern, so they can be surfaced inside your own product in your customer's language rather than handled over email. Every transaction accepts your own reference and returns it on each response and event, which is what makes the join between your records and ours a property of the data rather than a reconstruction. How the pieces compose across countries is in global payments.
None of that answers whether your own business needs its own registration somewhere. That question belongs to your counsel, and a provider's position does not transfer to a customer.
Methodology and sources
Law 9.613 of March 3, 1998 was read on September 24, 2026 in the consolidated text published by the Presidency of the Republic, and the wording of Article 10, II quoted here is the one in force, given by Law 14.478 of December 21, 2022. Earlier wordings of the same provision remain visible in that document, which is a reason to read the article rather than search for a phrase.
31 CFR 1010.410 was read on September 24, 2026 in the current text served by the eCFR, and the field list and the 3,000 dollar threshold are the ones stated in paragraph (f) of that section.
Statements about continuous monitoring and periodic review describe the general shape of these frameworks rather than a single instrument, and no norm number is attached to them for that reason. This post describes what rules say. It does not advise on whether they apply to a given business, and it is not a substitute for counsel in the relevant jurisdiction.
Verified on September 25, 2026. Operational context, not legal, tax, or investment advice. Law 9.613/1998 (Article 10) checked against planalto.gov.br on September 24, 2026. 31 CFR 1010.410 checked against ecfr.gov on September 24, 2026.
Cover photo: the blowup on Unsplash.
Do anti-money-laundering rules apply to stablecoin payments?
They apply to the institutions that provide the service, in the jurisdictions that have brought virtual asset activity inside their existing frameworks. Brazil did this by amending the record-keeping duty in Law 9.613 to name virtual assets, which extended an existing obligation rather than creating a separate regime.
What is the travel rule threshold?
In United States regulation it is a transmittal of funds of 3,000 dollars or more, at which point a defined list of identifying fields must travel with the transmittal order. Other jurisdictions set their own threshold, so a cross-border flow can face different numbers on different legs.
Does a fintech need its own registration to move stablecoins?
That depends on which entity performs which activity and where, and it is a question for counsel rather than for a provider. The structural decision that most affects the answer is whether your platform holds and moves money for third parties or whether a licensed provider does, which is worth settling before the build rather than after.
What is the difference between KYB and KYC here?
KYC verifies a natural person, and KYB verifies a legal entity together with the people who own and control it. The second is harder because ownership can be nested through other companies and funds, so the verification walks the structure until it reaches natural persons.
