TL;DR: Stablecoin AML compliance moved from policy to draft rule on April 10, 2026, when FinCEN and OFAC proposed treating permitted payment stablecoin issuers as financial institutions under the Bank Secrecy Act. Comments closed June 9. The proposal mandates a written AML/CFT program and a statutory sanctions compliance program. Both have to be evidenced, not just maintained.
Once the April 2026 FinCEN and OFAC proposal takes hold, a payment stablecoin issuer is treated as a regulated financial institution, and stablecoin AML compliance stops being a policy question and becomes an operational one: proving the anti-money-laundering and sanctions program actually ran on the right transactions. A written program on file is not the same as evidence it fired. Orochi Network's zkDatabase lets an issuer show that evidence without exposing customer data.
Key Takeaways:
- Stablecoin AML compliance now sits inside the Bank Secrecy Act after the April 10, 2026 FinCEN and OFAC proposal treating issuers as financial institutions.
- The rule mandates a written AML/CFT program and a dedicated sanctions compliance program, with the comment window having closed June 9, 2026.
- Earlier GENIUS Act rulemaking focused on reserves and redemption; this proposal is about screening, monitoring, and recordkeeping.
- An examiner does not just ask whether a program exists. They ask for evidence it was applied to specific customers and flows.
- Cryptographic verification lets an issuer prove screening and monitoring controls fired without publishing the customer graph.
What does stablecoin AML compliance require under the GENIUS Act?
Stablecoin AML compliance under the GENIUS Act requires permitted payment stablecoin issuers to operate as financial institutions under the Bank Secrecy Act, with a written anti-money-laundering program and sanctions controls. On April 10, 2026, FinCEN and OFAC published a joint notice of proposed rulemaking that would treat these issuers as Bank Secrecy Act institutions, with the comment period closing June 9, 2026. The proposal carves issuers out of the money services business category and gives them a stand-alone framework tailored to stablecoin issuance.
This is a different obligation from the reserve and redemption rules that came earlier. Reserve proof asks whether the backing is there. The illicit-finance framework asks a separate question: did the issuer screen its customers, monitor its flows, and keep records that an examiner can inspect. For a sense of how the reserve side developed, see how the
GENIUS Act made banks prove reserves.
This rule is about screening and recordkeeping, not reserves
The FinCEN and OFAC proposal targets the controls around money movement, not the balance sheet behind the token. It would require customer due diligence, transaction monitoring, suspicious activity reporting, and sanctions screening as program obligations. The sanctions piece is notable because it is the first time such a compliance program would be mandated for issuers in statute rather than enforced after the fact.
Each of those controls produces evidence. A screening decision, a monitoring alert, a due-diligence file, a filing. The program is only as credible as the issuer's ability to show that data maps to the actual customers and transactions they claim to cover. The earlier rulemaking on
GENIUS Act redemption operations created a similar operational evidence burden on the treasury side; this proposal extends it to the compliance desk.
An examiner asks for evidence the control fired, not a policy document
A written AML program satisfies the paperwork test. It does not answer the examiner's real question, which is whether the control was applied to a specific customer or flow on a specific date. The gap between having a policy and proving it ran is where enforcement risk concentrates.
Consider a sanctions screening obligation. An issuer can hold a polished policy describing how every mint and redemption is checked against the OFAC SDN list. Under examination, the question becomes narrower: show that this transaction, on this date, was screened, and that the result was acted on. Answering that today usually means pulling logs from internal systems and asking the examiner to trust both the logs and the systems that produced them.
Each AML and sanctions control produces evidence; the open question is whether the issuer can prove the control fired on the right data without exposing the customer behind it.
The issuer that can produce that evidence on demand, and let the examiner verify it independently, is in a stronger position than one reconstructing it under pressure.
Proving the program ran is a data-provenance problem
Showing an AML or sanctions control fired on the correct data, while keeping customer identities and transaction details private, is a data-provenance problem more than a reporting problem. The issuer has to bind a control decision to the exact data it acted on, in a way a third party can check later without re-running the whole pipeline.
This is the same tension that runs through
AML and KYC without mass surveillance: the obligation to demonstrate screening collides with the duty to protect personal data. Publishing customer-level data to prove diligence would create a privacy violation while solving a compliance one. The workable path proves the condition and keeps the data private.
Where does verifiable data fit in stablecoin AML compliance?
Verifiable data lets a stablecoin issuer prove that a screening or monitoring control was applied to a given set of data, without disclosing the data itself. The issuer generates a cryptographic proof at the source, and an examiner or counterparty verifies the proof rather than trusting an internal log.
zkDatabase, the Verifiable Database built by Orochi Network, applies to this in a concrete way. An issuer can prove that every mint and redemption in a period passed sanctions screening, that monitoring rules evaluated the actual transaction set, or that due-diligence data exists for a customer base, while the personal data stays off any public ledger. The mechanism is selective disclosure, the same one detailed in
privacy-preserving compliance and in work on
decentralized identity for financial institutions.
The boundary matters here. zkDatabase does not make a suspicious-activity determination, file a report, or replace the compliance officer's judgment. It can help support the evidence layer underneath those decisions by proving that the controls ran on the data they were supposed to. That is a narrower claim than compliance, and a more defensible one.
Conclusion
Stablecoin AML compliance is no longer a question of whether issuers will be regulated for illicit finance. The FinCEN and OFAC proposal answers that, and the comment window has already closed. What remains open is operational: can an issuer prove its screening, monitoring, and recordkeeping controls were applied to the right data, on demand, without turning customer privacy into collateral damage. Verifiable Data Infrastructure does not write the AML program. It gives the issuer a way to prove the program ran when an examiner asks.
Book an Advisory Call
Talk through where verifiable proof fits into your stablecoin AML and sanctions evidence workflow.
FAQ
What does stablecoin AML compliance require after the FinCEN rule?
Stablecoin AML compliance requires permitted payment stablecoin issuers to operate as Bank Secrecy Act financial institutions, with a written AML/CFT program and a sanctions compliance program. The FinCEN and OFAC proposal published April 10, 2026 sets out customer due diligence, transaction monitoring, suspicious activity reporting, and sanctions screening as program obligations, with the comment window having closed June 9, 2026.
How is this different from the GENIUS Act reserve rules?
The reserve and redemption rules address the backing behind the token and the issuer's ability to redeem on time. The FinCEN and OFAC proposal addresses the controls around money movement: screening customers, monitoring transactions, and keeping records of both. An issuer can be fully reserved and still fail an examination of its anti-money-laundering and sanctions program.
What evidence does an examiner expect for AML controls?
An examiner expects evidence that a specific control was applied to a specific customer or transaction, not just a policy describing the control. For sanctions screening, that means showing a given mint or redemption was checked and the result acted on. Reconstructing this from internal logs asks the examiner to trust both the logs and the systems behind them.
Can an issuer prove screening happened without exposing customer data?
Yes. An issuer can generate a cryptographic proof that a screening or monitoring control ran on a defined set of data, then share the proof instead of the data. zkDatabase produces this kind of verifiable evidence so an examiner checks the result independently, while customer identities and transaction details stay private.