Independent AML audit: what the review covers when settlement runs in stablecoins

An independent AML audit is the periodic review that tests whether an anti money laundering programme actually works. It is not an examination. A regulator does not run it. The institution commissions it, and then has to live with what it finds. For an institution that has started settling cross border payments in stablecoins, the review is also the first honest read on whether the new rail went inside the old controls or beside them. This is what it covers, who may perform it, and what the file must show.

What is an independent AML audit, and who requires one?

It is a test of the programme, not of a person. The reviewer takes the written policy, the risk assessment and the controls, then checks whether each one is designed properly and operating as described.

The requirement is old and it is explicit. In the United States, section 1022.210 of title 31 of the Code of Federal Regulations requires a money service business to maintain an anti money laundering programme, and lists independent review as one of its four elements, alongside internal controls, a designated compliance officer and training.

Credit unions and banks arrive by a different route. Section 748.2 of title 12 of the Code of Federal Regulations requires a federally insured credit union to maintain a Bank Secrecy Act compliance programme that includes independent testing for compliance. The FFIEC BSA/AML Examination Manual sets out what examiners expect that testing to look like.

Outside the United States the wording changes and the expectation does not. Article 8 of Directive (EU) 2015/849, the fourth anti money laundering directive, calls for an independent audit function to test internal policies, controls and procedures where appropriate to the size and nature of the business. FATF Recommendation 18 asks financial institutions for an independent audit function to test the system.

So the question is never whether to run one. It is how wide, how often, and by whom.

How often does the review have to happen?

Less prescriptively than most teams assume, and that is the trap.

The US money service business rule sets no frequency. It asks for a programme reasonably designed for the risk the business carries. That makes frequency a risk decision you have to defend. Annual is the common practice. Annual is not the rule.

Canada is explicit. The Proceeds of Crime (Money Laundering) and Terrorist Financing Regulations require a review of the compliance programme at least every two years, as FINTRAC's compliance programme guidance states. That review covers the policies and procedures, the risk assessment and the training programme.

Risk, not the calendar, should pull the date forward. A new corridor, settlement asset, chain, payout partner or first stablecoin leg each changes the risk profile. Each is a reason to review sooner, and a reason the next reviewer will ask why you did not.

What does independence actually mean here?

It means the reviewer does not own the thing being reviewed.

The tester can be internal audit, an external firm or another qualified party. What they cannot be is the compliance officer, anyone reporting to that officer, or anyone who designed or operates those controls. The FFIEC BSA/AML Examination Manual is direct on the point: staff who perform the testing should not be involved in the compliance function they are testing.

Two consequences follow. A small institution with no internal audit function has to buy that independence, and it is a cost of the programme rather than a nice to have. Independence also has a reporting half: findings go to the board or a board committee, not only to the officer who has to fix them.

An independent AML audit that reports only to the person responsible for the programme is not independent. It is a self assessment with a longer invoice.

What should an independent AML audit scope cover when settlement runs in stablecoins?

Everything the old scope covered, plus the parts of the payment that now happen on a public ledger.

The familiar scope still stands. The risk assessment, read against the business as it is today. Customer due diligence and the business onboarding file. Transaction monitoring rules, their tuning and the disposition of alerts. Sanctions and politically exposed person screening, including list versions and match settings. Reporting, both suspicious activity and large value reporting. Training, record keeping, and the governance above all of it.

The settlement leg adds a short list to ask for by name.

Wallet and counterparty screening before release, not only at onboarding. Travel Rule data: whether the originator and beneficiary information required under FATF Recommendation 16 is actually transmitted, in IVMS101 or an equivalent, and what the institution does when a counterparty cannot receive it. FATF's June 2025 Targeted Update on virtual assets and virtual asset service providers continues to report uneven implementation across jurisdictions, so that fallback is part of the control, not an edge case.

Then the operational joins. Whether a transfer on the ledger reconciles to the instruction in the books, by transaction hash and UETR. Which confirmation depth the institution treats as final, and who decided it. Whether a blocked or high risk address is caught before funds move or only after. How a held, returned or frozen payment is recorded, and whether the message trail matches the ledger trail.

That last item is where new programmes are thinnest. The payment message and the chain are two records of one event. A reviewer should be able to pick a payment at random and tie them together.

How do you run the review, step by step?

Scope first, sampling second, evidence throughout.

• Agree the scope and the period in writing, including the corridors, chains and settlement assets in use. An undocumented scope becomes an argument later.
• Pull the risk assessment and read it against reality. If it does not mention the rail you went live on, that is a finding before any testing starts.
• Sample by risk rather than convenience. Take cases from each corridor, payout partner and settlement chain, and include the exceptions: held payments, returns, escalations and closed accounts.
• Test design and operation separately. A rule can be written correctly and switched off. Ask for the production configuration, not the policy document.
• Walk one payment end to end, from onboarding file to instruction, screening, settlement on chain, payout and record. Note every point where a person had to intervene.
• Rate each finding by risk, then give it an owner and a date. A finding with no owner is a sentence, not a corrective action.
• Report to the board or its committee, with management's response attached rather than merged into the text.
• Track remediation to closure and re test the fix. An open finding carried into the next review is itself a governance finding.

What must the findings and the remediation record show?

That somebody acted, and when.

Examiners rarely object to a review that found problems. They object to a review that found nothing, and to findings with no closure. The file should hold the engagement scope, the basis for the tester's independence, the sample and why it was chosen, the testing performed, each finding with a risk rating, management's response, the owner, the due date and evidence that the fix works.

Keep it as long as the record rules demand. In the United States, section 1010.430 of title 31 of the Code of Federal Regulations requires records under the Bank Secrecy Act to be retained for five years.

One item is missed often enough to name. If the review changed a threshold, a rule or a procedure, that change needs a dated record and an approver. Otherwise the next reviewer meets a configuration the last report never described.

What usually goes wrong?

The failures repeat, which is the good news: a repeating failure can be designed out.

A scope copied from last year, so the new settlement rail is never tested. A reviewer who is independent on the engagement letter and not in practice. A sample drawn from clean, high volume activity, which tests throughput rather than control. Testing the policy instead of production, so a disabled rule passes. No exception sampling, so the cases that expose the weakest controls are the cases nobody reads. And a report that stops at the compliance officer.

The cheapest fixes are the least technical. Write the scope before the engagement. Insist on the production configuration. Sample the exceptions.

Where StableNet fits

StableNet, built by SpendTheBits, is a cross border B2B payment and settlement platform for banks, credit unions, licensed money service businesses, exchange houses and remittance fintechs. It settles in regulated stablecoins on public blockchains, in minutes, with on chain auditability, which lets a reviewer tie a payment in the books to a transfer on the ledger. It is ISO 20022 native, producing pacs.008 customer credit transfers, pacs.009 interbank legs, pacs.002 status reports and pacs.004 returns under a head.001 envelope, tracked end to end by UETR, so the message trail and the ledger trail share one reference. Compliance is built in: KYB and KYC onboarding, KYT, sanctions and PEP screening, FATF Travel Rule data in IVMS101, a compliance workbench and a tamper evident audit trail, which is the evidence set a review asks for rather than a report assembled afterwards. Universal Compliance Control, the SpendTheBits submission named a finalist in the Swift Hackathon 2026 Technical Challenge, applies the same idea to settlement itself: an off chain compliance oracle issues one signed attestation and on chain gates enforce it identically across chains, so no valid attestation means no settlement. SpendTheBits is a Bank of Canada registered payment service provider.