Banks Push FDIC to Make Stablecoin Issuers Own Wallet Screening

Any engineer who has built a sanctions screening pipeline knows the ugly truth: the control loop only works if you can see the transaction before it settles. Stablecoins settle in seconds across borders, and the FDIC just spent a comment cycle discovering that its supervised banks cannot see most of what needs screening. The comments filed last week make that gap explicit, and the operational fallout lands squarely on issuer engineering teams.

The Problem

The FDIC proposed rulemaking pulls FinCEN and OFAC obligations inside its own supervisory framework for permitted payment stablecoin issuers affiliated with state nonmember banks and state savings associations. As PYMNTS.com reported, the comment period closed Tuesday August 4, 2026, and the responses share a common message: banks support regulated stablecoin issuance, but they refuse to be the party on the hook for wallet activity they cannot observe.

The Independent Community Bankers of America drew the line hard. A community bank holding reserve or operating accounts should monitor its own customers, accounts and transactions. It should not police secondary-market transfers, wallet-level activity or product-specific risks outside its control. Blockchain analytics, wallet screening and stablecoin-specific transaction monitoring, the ICBA argued, belong to the issuer.

That sounds tidy on a slide. It is not tidy in production. A stablecoin issuer typically has a direct view of mint and burn events. Everything in between happens on public chains, through exchanges, custodians and wallet apps the issuer has no contractual relationship with. The ICBA still wants issuers to identify, block, freeze or reject prohibited activity, and to account for mixers, wallet obfuscation, chain-hopping, sanctioned jurisdictions and transfers that cross between on-chain and off-chain systems. Periodic sanctions list screening, the letter said, is not enough.

International Bancshares Corp. added a broader concern. Strong AML and sanctions standards are necessary, but the proposal only touches one component of stablecoin risk. Fraud, consumer harm, sanctions evasion, deposit displacement and wider instability are not solved by bolting existing compliance rules onto a new product.

Commenters also flagged that overlapping FDIC, FinCEN and OFAC oversight could slow decisions even as the underlying rails move value across borders in seconds. From production incidents I've seen at fintechs with multi-regulator exposure, that latency gap is where fraud losses actually accumulate. The rulebook assumes human review time the settlement system does not offer.

Options on the Table

Three distinct compliance architectures fall out of the comment letters, and they lead to very different engineering roadmaps.

Option one: issuer as full-stack watcher. This is the ICBA position. The issuer owns blockchain analytics, wallet screening, transaction monitoring, contingency procedures for redemption, alert threshold documentation, false positive and false negative assessment, and preservation of investigation records. Reserve banks stick to monitoring their own direct customer, which is the issuer entity. Clean lines, but it puts every issuer in the position of building or buying a chain-analytics stack that rivals what Chainalysis and TRM sell to enforcement. Small issuers cannot carry that overhead. That is two engineers worth of headcount before you even write a rule.

Option two: shared secondary-market obligations. This is the Bank Policy Institute and The Clearing House position in their joint letter. The proposed framework, they argued, leaves a gap once payment stablecoins move beyond the issuer into the secondary market. Exchanges, custodians, digital asset service providers and other intermediaries facilitating secondary-market transactions should also face clearer AML and sanctions obligations. Otherwise banks remain responsible for risks created by activity they cannot see.

This one is engineering-honest. Whoever holds the customer relationship performs the screening. It also requires the FDIC to coordinate with venues it does not directly supervise, which is politically harder than writing rules for its own banks. The SEC's ongoing turf overlap with crypto intermediaries shows how quickly that coordination stalls.

Option three: design-time accountability. Buried in the ICBA letter is the sharpest sentence in the entire comment record: if a PPSI designs a product that can move value across wallets, platforms or jurisdictions faster than its sanctions controls can operate, that design choice should not become a basis for reduced accountability. Translated to engineering language: you do not get to ship an ERC-20 that hops L2s in under a second and then plead that OFAC screening runs on a nightly batch.

My take: option three is the only one that survives contact with real settlement latency. Options one and two argue about who cleans up. Option three forces product design to match control speed, which is the actual engineering constraint.

What Crypto and DeFi Should Actually Do

Issuer engineering teams reading the comment record should stop treating compliance as a downstream concern and pull it into protocol design. The ICBA letter effectively demands real-time sanctions enforcement, not periodic list refreshes. That means the freeze function, the blocklist oracle, the mint/burn authority and the redemption identification workflow need to be first-class components, not afterthoughts.

Concretely, three moves are worth making now. First, instrument mint and burn against a live sanctions feed rather than a nightly job, and log every decision with the alert threshold that triggered it. The ICBA specifically called for documented thresholds, false positive and false negative assessment, and preserved investigation records. That is an audit trail requirement, not a nice-to-have.

Second, build the redemption identification path before you need it. The BPI and Clearing House letter highlighted the scenario where a holder acquires stablecoins through an exchange without any direct issuer relationship, then walks up for cash when that exchange fails or suspends withdrawals. The issuer must identify and screen someone it has never served, at potentially large volume. If your KYC onboarding assumes a happy-path account creation flow, it will collapse under a redemption run.

Third, treat third-party vendors as extensions of your compliance perimeter. The ICBA was explicit: outsourcing identity checks, screening or monitoring does not relieve the issuer of accountability. Whatever analytics provider or KYC vendor sits in your stack, their SLAs, coverage lists and escalation procedures now flow through to your regulator relationship.

The uncomfortable read: most stablecoin issuers I've watched treat blocklist management as a governance ticket, not a latency-critical service. That mindset does not survive the framework the FDIC is heading toward.

Gotchas and Edge Cases

The redemption run scenario deserves a full failure-mode analysis. When an exchange freezes withdrawals, redemption requests hit the issuer in a spike, from wallets that have no prior relationship. Your identity verification vendor rate limits. Your sanctions screening API rate limits. Your customer support queue explodes. The ICBA urged the FDIC to require contingency procedures covering identification, sanctions screening, suspicious activity escalation, staffing, liquidity and communications. Read that list as a runbook you should be drafting today.

Chain-hopping is the second landmine. The ICBA explicitly named mixers, wallet obfuscation, chain-hopping and on-chain to off-chain transfers as things issuers must account for. If your token deploys across multiple L2s and bridges, your monitoring needs to reconcile addresses across those environments in near real time. Analytics vendors vary widely in coverage here. Test before you sign.

Third gotcha: the FDIC must notify FinCEN at least 30 days before certain supervisory or enforcement actions. That coordination window sounds procedural, but it means the effective regulator on any specific incident may not be clear until after your legal team has already responded. Build incident response plans that assume multi-agency involvement.

Finally, the ICBA opposed exemptions unless they provide equivalent transparency, traceability and enforcement value. Any pitch from a vendor promising a lightweight compliance carve-out for your product should be treated as legal risk, not a shortcut.

Key Takeaways

• Banks told the FDIC clearly: reserve-account providers watch the issuer, the issuer watches the wallets. Build your stack around that split.
• Sanctions controls must operate at settlement speed. Periodic list screening will not meet the standard the ICBA is pushing for.
• Redemption is the stress test. If a holder you have never served can walk up for cash during an exchange failure, you need an identification and screening workflow that scales under spike load.
• Third-party outsourcing does not transfer accountability. Vendor due diligence, alert threshold documentation and investigation record retention are now issuer-owned artifacts.
• Product design decisions that outrun your compliance controls are, per the ICBA, not a defense. Match protocol capability to control latency, or shrink the capability.