Your BSA Program Wasn't Built for 24/7 Settlement. Here's What Breaks.

I've been thinking about this since the OCC published its GENIUS Act NPRM last month. The proposed rule covers operational, compliance, and information technology risk management standards for stablecoin issuers, including Bank Secrecy Act and sanctions compliance. A separate rulemaking for AML/OFAC is coming. But here's what keeps nagging at me: most of the conversation is about whether stablecoins should fall under the BSA. Almost nobody is talking about what happens to existing BSA infrastructure when they do.

Because the infrastructure breaks. Not in dramatic ways. In quiet, architectural ways that won't show up until the first examination cycle after implementation.

I've identified five specific things that stop working when you move from batch settlement to always-on stablecoin rails. If you're a BSA officer at a bank or fintech entering stablecoin operations, these are the conversations you should be having with your technology team right now.

Alert queues assume business-hours human review

This is the most obvious one, and somehow it still catches people off guard.

Your transaction monitoring system generates alerts. Those alerts sit in a queue. A BSA analyst reviews them, usually during business hours, usually Monday through Friday. The analyst investigates, dispositions, escalates if needed. On traditional rails, this works fine. ACH batches settle overnight. Wires have cutoff times. The window between "alert generated" and "transaction finalized" is measured in hours, sometimes days. You can intercept before finality.

On stablecoin rails, that window is measured in seconds. A USDC transfer on Base confirms in about two seconds. By the time your alert queue renders the row, the money has already arrived. By the time your analyst opens the alert Monday morning, that USDC has been moved three more times, bridged to a different chain, and swapped for a different token.

There's something uncomfortable about alerts sitting in a queue for 48 hours while money moves at 2 AM on a Saturday. The fundamental model changes from "review before settlement" to "detect and document in real time." That's not a process change. That's an architecture change. Your transaction monitoring system was designed around the assumption that humans are in the loop before finality. On stablecoin rails, they aren't.

The question for your compliance technology team: can your monitoring system generate and act on alerts within seconds, not hours? If the answer is no, you need to think about what "monitoring" even means when settlement is instantaneous and irreversible.

SAR filing timelines collide with transaction velocity

FinCEN expects SARs filed within 30 days of detection. Seems straightforward. But "detection" is doing a lot of work in that sentence.

Detection assumes a human noticed something. An analyst reviewed an alert, identified suspicious activity, and the 30-day clock started. That model works when your alert queue generates a manageable number of alerts during business hours and a human dispositions each one.

Now picture a weekend on stablecoin rails. Your automated system flags 200 transactions between Friday evening and Monday morning. 14 of them have characteristics that would warrant a SAR. When does the 30-day clock start? When the system generated the alert? When the analyst first viewed it? When the analyst completed the investigation and determined it was suspicious?

These are genuinely different dates, and different institutions are interpreting it differently. Some start the clock at system detection. Others start at analyst review. A few are trying to use the investigation completion date. The regulatory guidance doesn't draw a clear line here, because it was written for a world where human detection and system detection happened roughly at the same time.

I don't know the right answer. I genuinely don't think there is one yet. But I do know that if your stablecoin operations generate 200 alerts over a weekend and you're using the "analyst first viewed it" interpretation, you've just created a backlog that pushes some of those SARs dangerously close to the 30-day line. And the examiner will ask about the ones that came in late.

CTR aggregation across chains has no standard

The BSA's $10,000 Currency Transaction Report threshold applies to aggregate transactions by the same person in the same day. Straightforward when all transactions flow through one system. Less straightforward when they flow through multiple blockchains.

Here's a concrete scenario. A customer sends $6,000 USDC on Base at 10 AM. That afternoon, the same customer sends $5,000 USDC on Ethereum. Total for the day: $11,000. That triggers a CTR.

But your monitoring system treats Base and Ethereum as separate data sources. It sees two sub-threshold transactions. It never generates the CTR. The examiner will construct this scenario from your on-chain data, because the blockchain is public. You'll be explaining why your system didn't catch it.

Multi-chain aggregation sounds simple. "Just aggregate across chains." In practice, it requires solving identity resolution across chains (is the same person behind both wallets?), timestamp normalization (different chains have different block times), and real-time data ingestion from multiple RPC endpoints. Most compliance monitoring systems were built to ingest from one data source. Adding a second chain doubles the complexity. Adding eight does not multiply by eight. It compounds.

The GENIUS Act also requires stablecoin issuers to produce monthly reserve attestations by third-party auditors, covering the amount and composition of reserves and the total number of outstanding stablecoin payments. That's the issuer's problem. But the CTR aggregation problem is yours, and there is no industry standard for how to solve it across chains.

Sanctions screening timing becomes a legal question

On traditional rails, you screen before you send. You check the beneficiary against the SDN list, get a clear result, execute the wire. If the beneficiary was added to the list an hour after your screen, you have a defensible position: you screened, they weren't listed, you sent.

On stablecoin rails, many systems operate in what I'd call "post-send" mode. The transfer executes, then the system screens. This is common because stablecoin transfers are initiated programmatically, often by automated systems that prioritize latency. The screening happens after finality.

Now the interesting question. OFAC added a wallet to the SDN list at 2:00 PM. Your system last synced the SDN list at 1:00 PM. Your agent sent USDC to that wallet at 2:15 PM. You screened at 2:16 PM using your 1:00 PM list. Clean result. But the wallet was sanctioned at 2:00 PM.

OFAC operates under a strict liability framework. Intent doesn't matter. If you transacted with a sanctioned entity, you violated the sanctions. The question is whether you had reason to know. Your defense depends entirely on the timing: when you synced your list, when the transaction executed, when you screened.

For traditional rails with settlement delays, this rarely matters. The gap between list update and settlement is measured in hours. For stablecoin rails with instant finality, the gap between list update and screening can be the difference between a defensible position and a violation. I don't think the legal community has fully worked through what OFAC strict liability means when transactions are irreversible and settle in seconds. This is a conversation compliance teams should be having with counsel now, not after the first enforcement action.

Record retention changes when records are digital-native

BSA requires five years of record retention. For traditional wires, the record is a SWIFT message, an internal memo, maybe some emails. These records live in systems designed for record-keeping: document management platforms, archival databases, compliance systems with audit trails.

For stablecoin transactions, the record has two parts. The on-chain data: the transaction hash, the block, the addresses, the amount. This data is immutable. Nobody can modify it. And the off-chain data: whatever your systems logged about why the transaction happened, what checks you ran, what decisions your team (or your agents) made.

The on-chain data is fine. The off-chain data is the problem.

Your internal logs live in a database. Anyone with database access can modify them. Your alert dispositions live in a case management system. Your SAR narratives live in a filing system. Five years from now, when an examiner reviews a stablecoin transaction from today, they'll look at the on-chain record (immutable) and your internal records (mutable). The question they will eventually ask: how do you prove your internal records match what happened on-chain, and that they haven't been modified since the transaction?

This is a new integrity question. For traditional payments, the institutional controls around record-keeping (access controls, separation of duties, audit logs on the audit logs) provided sufficient confidence. For stablecoin transactions, the existence of an immutable on-chain reference creates a higher bar. Your internal records need to demonstrably correspond to the on-chain reality, and you need to prove that correspondence hasn't been tampered with.

I think this is the sleeper issue. It won't come up in the first examination cycle. It will come up in the second or third, when examiners get comfortable pulling on-chain data and comparing it to institutional records. The institutions that have thought about record integrity for digital-native transactions will have a good answer. The ones that haven't will be scrambling to explain why their logs don't quite match the chain.

What this means

None of these problems are unsolvable. All of them require architectural thinking, not just process changes. If your BSA program was built for batch settlement with business-hours review, you can't bolt on stablecoin compliance by adding a new transaction type to your existing monitoring system. The assumptions that system was built on don't hold.

The GENIUS Act implementing regulations are expected in July 2026, with prohibitions effective November 2026. That's not a lot of time to rethink the architecture of a BSA program. But the institutions that start now, that identify these five pressure points and begin designing around them, will be in a fundamentally different position than the ones that treat stablecoin compliance as a configuration change to their existing stack.

If you're a BSA officer reading this, bring it to your next compliance committee meeting. Ask your technology team about alert latency, cross-chain aggregation, SDN list sync frequency, and record integrity. The answers will tell you how much architectural work sits between where you are today and where you need to be by November.

Vinay Narayan is the founder of Legaci Labs. He holds a patent on tamper-evident digest chains for agent audit trails.