AML audit readiness means being able to show an examiner or a bank partner, from stored records alone, that your anti-money-laundering controls exist, ran as written, and produced decisions a stranger can follow. For a stablecoin payments business that is a customer file, a reason for each monitoring rule, a dossier for each alert, plus reports filed on time.
We covered the program itself in stablecoin AML compliance for fintechs. This post starts after it exists, with what you hand over when someone tests it.
What do examiners and bank partners ask to see?
They ask for artifacts, not explanations. A good policy proves nothing until real cases match it.
Evidence a reviewer asks for, and where it usually comes from.
Evidence item | What the reviewer checks | Where it comes from |
Written AML policy and risk assessment | Current, approved, and matches what the system does | You |
Customer file (KYB or KYC) | Identity, owners, documents, review date, who approved | Provider verification record plus your onboarding log |
Customer risk rating method | Factors, who can override, what triggers a refresh | You |
Rule inventory with rationale | Each monitoring rule tied to a risk and a customer segment | You |
Tuning and change log | What changed, tested how, approved by whom | You |
Alert dossier | Alert, evidence reviewed, reviewer, decision, dates | You, plus the provider's review of its own holds |
Reporting records | Detection date, decision date and filing date for each report | You |
Sanctions and wallet screening results | Which lists, which dates, what matched | Provider output for its flows, yours for flows you run |
Transaction history with counterparty and purpose | Every payment in the sample, rebuilt end to end | Provider API plus your ledger |
Independent testing and management reporting | Scope matched to risk, findings tracked to closure | You |
Retention and retrieval | Records kept for the required period and produced on request | You |
Seven of the eleven rows say "you" with no qualifier. The regulated business assembles and owns the file. A partner bank adds one question: do your controls cover the flows it carries for you?
KYB (know your business, the verification of a company and its owners) has the most documents behind it, and what KYB is lists them. The KYB onboarding flow shows how to collect them.
At Lumx, the customer file starts inside the API. A business customer submits formation documents, documents from the representative and from every owner above 25%, transactional information on source of funds and expected volume, and proof of address issued in the last 90 days. The customer record then shows a verification status and, on a rejection, the reason.
The records a provider can hand you and the ones it cannot
A provider that runs verification and monitoring creates records about its own decisions, not yours: why you set a threshold, who reviewed an alert on your side, whether you filed a report. Reviewers do not accept "our vendor handles it" for those. In Brazil the rule is written down: Circular 3.978, Article 44, bars covered institutions from hiring third parties to run the alert analysis and from running it abroad, so the dossier has to come from the institution itself (support services stay allowed). It binds only institutions the circular covers.
If the provider decided, ask for the data behind it in a form you can store, such as status changes with timestamps. If you decided, the record lives in your systems, linked to the provider's identifiers so the two halves join.
Lumx documents what it exposes for that join. Each customer carries a status (NOT_STARTED, UNDER_VERIFICATION, APPROVED, an RFI (request for information) state or FINAL_REJECTION), and webhooks announce every change with a unique event id. KYC (know your customer, the verification of an individual) runs through Sumsub and KYT (know your transaction, the screening of transaction flows) through Chainalysis, which covers blockchain activity only; fiat legs are monitored with Lumx's own systems plus the oversight of its banking partners. Storing the webhook stream in your own system is what turns those states into your audit trail.
How long do you keep records, and when must you report?
The table covers the two regimes whose text we could read directly on November 1, 2026. Both apply to defined categories of institution, so the first question is always whether your business is one.
Reporting clocks and retention in two regimes, from the primary text.
Item | United States (money services business) | Brazil (institutions the BCB authorizes) |
Source | 31 CFR 1022.320 and 1010.430 | Circular BCB 3.978 of January 23, 2020 |
Report | Suspicious activity report for a transaction of at least USD 2,000 that is suspected to involve illegal funds, evasion or no apparent lawful purpose | Report to COAF (Brazil's financial intelligence unit) of suspicious operations |
Clock | 30 calendar days after initial detection | Monitoring selection within 45 days of the operation, analysis within 45 days of selection, report by the next business day after the decision |
Decision record | Copy of each report and supporting documents | A dossier for every analysis, whether or not a report follows |
Retention | Five years from filing the report, five years for other records | At least ten years for customer information, transaction records and the dossier (Circular 3.978, Article 67) |
The US 30-day clock starts at detection, so the alert date and the decision date both belong in the case file. And Brazil requires the dossier even when no report follows, so a closed alert still needs its reasoning on record.
Circular 3.978 addresses institutions authorized to operate by the Central Bank of Brazil (BCB). Virtual asset providers now have their own authorization regime in Resolutions BCB 519, 520 and 521 of 2025. Law-firm summaries say Resolution 520 requires AML controls and a responsible director, but the BCB database served us no readable text, so whether the circular's rules reach a given provider is a question for counsel. Brazil's rules for stablecoins in 2026 covers the licensing side, and FinCEN registration for stablecoin businesses covers the US side.
Mexico sits outside the table on purpose: on November 1, 2026 none of the hosts we tried served the federal law, so this post gives no Mexican number. Confirm the Mexican retention and reporting periods with counsel before you build a file for Mexican flows. Mexico's rules under the CNBV covers the framework. Guidelines for the travel rule lists the sender fields by jurisdiction.
Lumx exposes every transaction through the API, one by one or as a list, with its type and amounts, its status and a declared purpose, and each completed transaction carries a receipt. Because the API returns each transaction, you can copy the history into your own store and keep it for whatever retention period your regime sets. For the rest of the file, Lumx offers a CSV export of transactions, account statements, fee statements and an audit trail, and produces logs on request.
Why every monitoring rule needs a written reason
An examiner who finds a rule that fires at a given amount asks why that amount, and "the vendor set it" does not answer. FinCEN's October 2025 SAR FAQs say the extent and parameters of account and transaction monitoring should be commensurate with the money laundering and terrorist financing risk of the specific institution, considering its products, its locations and its customer base. Brazil's circular, Article 62, requires a written effectiveness assessment each year, based on December 31 and delivered to management by March 31, naming the tests and who ran them.
Keep three artifacts per monitoring rule: the risk it answers, the threshold and why it sits there, and the last change with its approver.
In the United States, 31 CFR 1022.210 requires an independent review whose scope matches the risk, and the reviewer cannot be the designated compliance officer.
On Lumx, flagged on-ramps and off-ramps are held for review by Lumx's own transaction monitoring, and compliance contacts the customer on its usual channel for the sender and receiver relationship, the purpose and the expected outcome. The rules a customer runs over its own users stay in the customer's inventory.
Rebuild a closed alert before the examiner does
I recommend starting readiness work from the end. Take three closed alerts, one customer file and one reporting decision, and rebuild each from stored records alone, with nobody allowed to explain anything from memory. I prefer this to rewriting the policy first, because a policy can be edited in an afternoon while a missing record cannot be recreated, and the examiner will test the second. If a record lives only in someone's head or an email thread, I count it as missing.
The exercise produces a ranked list. Records that rebuild go in the index, and the rest head the plan below, ordered by closeness to a filing clock. On Lumx, the customer half of the file comes from the customer record and its status webhooks, and the payment half comes from the transactions API with its purpose and receipt.
When leaning on your provider is the wrong audit plan
A provider's controls cover the parties the provider can see. When your structure routes money for people the provider never onboarded, its screening has nothing to work with, and the audit file has a hole. Avoid one customer collecting for several underlying businesses, or sub-balances that track other parties' money.
The test is one question per transaction: whose money is it, and whose business does it pay for? If either answer names an entity your provider has not onboarded, the provider's file cannot answer for it, and your own file will be asked to. No provider document stands in for the independent review.
Lumx states the visibility rule in its documentation: accounts cannot process payments for any party whose identity or activity Lumx cannot see, and every transaction ties to an onboarded customer acting for itself. Marketplaces onboard each seller as a customer. Structures that look layered need written approval from Lumx compliance before they run.
What a Lumx integration leaves in the audit file
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.
For audit purposes the useful part is how much of the evidence is structured data. A customer cannot transact until approved, so the verification outcome and the ability to move money are one fact. Every on-ramp and off-ramp carries a purpose (trade transactions, professional services and similar codes), and each off-ramp lands on a destination whose holder relationship is declared when it is created, so the file shows who was paid and in what capacity.
Limits are part of the record too: each customer has limits by transaction type, readable with used and remaining amounts, and a payment past a limit is rejected with TRANSACTION_LIMIT_EXCEEDED. When more evidence is needed, an RFI arrives at the customer, account or transaction level. A customer RFI comes as a customer.rfi webhook, and a transaction RFI comes from Lumx compliance with a 24-hour window.
Every SWIFT payout in USD returns a UETR and an MT103 confirmation, and every transfer carries a per-rail reference, so your ledger joins to the payment. Global payments shows how the pieces fit, the supported countries and coverage page pages list jurisdictions and rails, and the operator map shows who else works in this market. For automated checks, see compliance agents for cross-border payments.
The filing duty sits with the regulated customer. Lumx supplies the transaction history, verification states and event stream that the customer cites in its own report file. Lumx files for its own flows too: in Brazil it identifies external transfers and reports them to COAF, and in Colombia the reports to the UIAF belong to its banking partner.
A 30-day plan before the review
Week one, inventory: list every control the policy claims, its owner and the record that proves it, using the table above as the index.
Week two, gap review: compare the policy with what the system does, and flag rules with no rationale, rule changes with no approval and cases with no closure reason.
Week three, test: rebuild a sample of closed alerts and one customer file from records alone, and run known patterns, such as payments split under a threshold, through monitoring.
Week four, repairs: close the gaps nearest a filing clock first, update the policy to match reality, and log every change with an approver and a date.
Methodology and sources
31 CFR 1022.320, 1022.210 and 1010.430 were read on November 1, 2026 in the text served by Cornell's Legal Information Institute, and FinCEN's SAR FAQs of October 2025 on fincen.gov. Circular BCB 3.978 of January 23, 2020 in the PDF served by the BCB's normative database. Circular 3.978 was read through Article 67, including Article 44. The Mexican federal law could not be read, so no Mexican figure appears. Resolutions BCB 519 to 521 are linked to their official source but were not read in full; our description of them comes from law-firm summaries. No Colombian regime is covered.
Lumx statements come from the Lumx documentation pages on identity verification, limits, requests for information, nested payments, supported countries, destinations, transactions and webhooks, read on November 1, 2026.
Verified on November 1, 2026. Operational context, not legal, tax, or investment advice. 31 CFR 1022.320, 1022.210 and 1010.430 checked against law.cornell.edu on November 1, 2026. FinCEN SAR FAQs of October 2025 checked against fincen.gov on November 1, 2026. Circular BCB 3.978/2020 checked against normativos.bcb.gov.br on November 1, 2026.
Cover photo: Bjørn-Magnus Kristiansen on Unsplash.
What is AML audit readiness for a stablecoin payments business?
It is the ability to show, from stored records, that your anti-money-laundering controls exist, ran as written, and left decisions someone else can follow. In practice that means a customer file, a reason for each rule, a dossier for each alert, plus report records. Lumx provides the verification states, event stream and transaction history that feed that file, and the program and its judgments stay with the customer.
How long must AML records be kept?
In the United States a money services business keeps a copy of each suspicious activity report and its supporting documents for five years from filing, and other records under the Bank Secrecy Act of 1970 for five years. For institutions covered by Brazil's Circular BCB 3.978, customer information, transaction records and the analysis dossier are kept for at least ten years.
When does a suspicious activity report have to be filed?
For a US money services business, no later than 30 calendar days after initial detection of the facts, for transactions of at least USD 2,000 that meet the criteria in 31 CFR 1022.320. Under Brazil's circular, the report goes to COAF by the next business day after the decision to report, and that decision comes from an analysis that must finish within 45 days of selection. The filing duty sits with the regulated customer, and Lumx supplies the transaction history, verification states and event stream the customer cites in its own report file.
Can my provider's KYB and monitoring replace my own AML program?
No. A provider's controls cover the parties it can see and the decisions it made, and in Brazil Circular 3.978, Article 44, bars covered institutions from outsourcing the alert analysis. Your rules, your alert decisions, your independent review and your filings are yours to document. Lumx runs KYB, KYC through Sumsub and KYT through Chainalysis for the customers and flows it carries, and ties every transaction to an onboarded customer.
How do I prove that transaction monitoring works?
Show the rule inventory with a reason for each rule, the change log with before and after alert counts, a sample of closed alerts rebuilt from records, and the independent review that tested them. Lumx holds flagged transactions for compliance review and asks the customer about the relationship, the purpose and the expected outcome, and the evidence for your own rules stays in your inventory.
