Treasury's proposed AML and sanctions rule for stablecoin issuers reads like a compliance document. Read it again as an architect, and it's a system design specification — one that quietly moves the hardest decisions from the legal team to the platform team.
On April 8, FinCEN and OFAC jointly proposed the rules implementing the GENIUS Act's AML/CFT and sanctions requirements for permitted payment stablecoin issuers. Mayer Brown's legal analysis is the right starting point if you want the regulatory mechanics. Our interest is narrower and different: which decisions in this rule end up on an architect's desk, not a compliance officer's, and which ones are easier to get wrong than they look. Comments are due June 9, with a 12-month implementation window once the rule is final — short by enterprise standards, especially for anything touching smart contract design.
The Primary/Secondary Market Split Is a System Boundary
Four things worth pulling out of the proposal:
The primary/secondary market split is a system boundary, not a legal distinction — and most existing stablecoin architectures don't draw it cleanly.
The rule formally separates "monitoring" from "control," but the technical capability to freeze and reject transactions on the secondary market is mandatory. That's a control plane requirement on an open system.
"No formal monitoring duty" on the secondary market doesn't mean no exposure. Whatever your blockchain analytics surface, you may be expected to act on. Telemetry choices become legal exposure choices.
For bank-affiliated issuers, the SAR-sharing coordination provision is a data architecture question wearing compliance clothing.
The boundary between primary and secondary is now a real interface
The rule treats primary market activity — issuance, redemption, direct customer relationships — as the place where bank-style obligations apply: customer due diligence, beneficial ownership, ongoing monitoring, SAR filing. Secondary market activity, where users move tokens among themselves via smart contracts, is largely scoped out of monitoring and reporting.
That sounds clean until you try to draw it in a system. A stablecoin issuer's platform has to know, with regulatory-grade precision, when a transaction is "primary" (a formal account relationship, full CDD obligations attach) versus "secondary" (smart contract interaction, different rules). Most issuers today have systems that blur this — onboarding flows, custody integrations, and token contracts that weren't designed with this boundary as a load-bearing concept. Retrofitting it means revisiting identity, account state, and event taxonomy across every system that touches the token. It's not impossible; it's just expensive when it wasn't planned for.
Control Without Monitoring: The Harder Architectural Problem
The most consequential line in the rule, for technical leaders, is the one that separates two things people usually conflate. PPSIs do not have to monitor secondary market activity. They do have to maintain the technical capability to block, freeze, and reject impermissible transactions on the secondary market, and to comply with lawful orders.
Translated: you must be able to act without being required to watch. That's a control plane on a permissionless system, and it forces design decisions that smart contract engineers and platform architects will recognize as genuinely hard. Freeze functions in the token contract, with appropriate access control. Key management and governance for who can invoke them. Upgradeability paths that don't undermine the security guarantees of the contract itself. Cross-chain consistency if the token is deployed on more than one network. Audit trails that satisfy a regulator without leaking operational detail to adversaries.
None of these are new problems in isolation. What's new is that the regulatory expectation now assumes they're solved, and the 12-month clock starts when the rule is final.
Telemetry Creates Exposure When Monitoring Isn't Required
The rule's logic on the secondary market contains a subtle trap. There's no obligation to monitor — but if your existing infrastructure (blockchain analytics, on-chain screening, sanctions tooling) surfaces suspicious activity, the safe harbor and the implicit expectation both push toward voluntary reporting. And the same tooling that gives you sanctions screening capability tends, by default, to give you visibility into a lot more.
This makes the choice of what to instrument, what to retain, and what to ingest into systems with retention obligations a meaningful architectural decision with downstream legal consequences. Architects who have lived through GDPR or HIPAA data minimization debates will recognize the pattern: collecting less is sometimes the safer posture, and the default vendor configuration is rarely the right one. The decision of which blockchain analytics signals flow into your compliance data lake — and which stay in operational systems — is going to matter more than it sounds.
For bank-affiliated issuers, this is an enterprise data problem
The proposal lets a parent insured depository institution and its PPSI subsidiary file SARs on each other's behalf and share underlying documentation within the corporate structure. On paper, this is a coordination convenience. In practice, it's a data architecture decision with consequences that compound.
Consolidating PPSI signals into the parent's enterprise AML platform means PPSI-specific risks — on-chain behaviors, smart contract events, blockchain-attributed addresses — have to be modeled in a system that wasn't designed for them. Keeping them separate means duplicate infrastructure and a coordination layer between platforms. Neither path is obviously right; both have real costs. The decision is one that gets made, often implicitly, by whoever owns the integration backlog. It deserves to be made deliberately, by someone with a view across both environments.
What This Means If You're Tracking the Space
The honest read is that the rule is not yet final, and several of its hardest questions — including foreign issuer treatment, the definition of "account" for lawful order purposes, and any limited secondary market reporting — are explicitly open for comment until June 9. The architecture decisions it implies, though, don't change much based on how those questions land. The primary/secondary boundary will need to be drawn. The freeze-and-control plane will need to exist. The telemetry posture will need to be deliberate. The data flows between PPSI and parent will need to be designed, not inherited.
For Architects, CIOs, and CTOs at institutions considering this space, the work worth doing now isn't compliance program drafting. It's mapping the rule against your current and intended architecture and finding the joints where regulatory intent and system design don't yet meet. Those joints are where the 12-month implementation window will get spent, and they're where the cost of getting it wrong will live for a long time after that.
The lawyers will tell you what the rule says. The harder question — what it means for the systems you're going to have to build, integrate, or unwind — is one technical leaders should be asking now, while the spec is still movin
The honest read is that the rule is not yet final, and several of its hardest questions — including foreign issuer treatment, the definition of "account" for lawful order purposes, and any limited secondary market reporting — are explicitly open for comment until June 9. The architecture decisions it implies, though, don't change much based on how those questions land. The primary/secondary boundary will need to be drawn. The freeze-and-control plane will need to exist. The telemetry posture will need to be deliberate. The data flows between PPSI and parent will need to be designed, not inherited.
For Architects, CIOs, and CTOs at institutions considering this space, the work worth doing now isn't compliance program drafting. It's mapping the rule against your current and intended architecture and finding the joints where regulatory intent and system design don't yet meet. Those joints are where the 12-month implementation window will get spent, and they're where the cost of getting it wrong will live for a long time after that.
The lawyers will tell you what the rule says. The harder question — what it means for the systems you're going to have to build, integrate, or unwind — is one technical leaders should be asking now, while the spec is still movin