US Banking Regulators Just Drafted the Stablecoin Security Playbook. AI Attacks Have Their Own Footnote.

The first draft of the GENIUS Act stablecoin rules landed in late September, and the part that matters most to security teams is easy to miss. The Federal Reserve announced its proposal on September 24, 2026 and published it in the Federal Register on September 29 (doc 2026-19860), a document running roughly 826,000 characters. Buried under proposed Section 247.13(b) is a complete information security program requirement for stablecoin issuers, written element by element into rule text, with board approval and a named security officer built in.

The same section does something else no Federal Register stablecoin text has done before. The Fed states, in its own words, that issuers could be attacked by AI tools, and it footnotes a Wall Street Journal story about machine-scale bug hunting to make the point. One of the proposal’s example failure scenarios is an AI-caused breach that mints coins with no new reserves behind them.

If your company is building toward a Permitted Payment Stablecoin Issuer (PPSI) registration, or you sell infrastructure to someone who is, this proposal is the first concrete picture of what an issuer’s security operation is expected to look like under federal law. Nothing in it binds anyone yet. The window to shape it closes November 30, 2026, and one adjacent Treasury comment window closes a good deal sooner than that.

What proposed Section 247.13(b) would actually require

Start with the sentence the whole thing rests on. Under proposed Section 247.13(b)(1), a Board-supervised PPSI "would be required to implement a comprehensive written information security risk and control framework, including a program that assesses and manages information technology and information security risks." Board-supervised here means issuers whose primary federal regulator is the Fed. The OCC’s own counterpart proposal, published in March 2026, carries essentially the same language for OCC-jurisdiction issuers, which tells you this is cross-agency direction, not one agency’s drafting quirk.

Governance comes next. Under proposed (b)(2), "the board of directors of a Board-supervised PPSI, or an appropriate board committee, must approve the Board-supervised PPSI’s information technology and security program," and that oversight includes "the appointment of a qualified Information Technology and Security Officer," assigning specific responsibility for program implementation, and review of program-related reports. A regulator is proposing to require a name on the door. Not a committee, not a function: a person the board appoints and hears from.

Then the five elements. Under proposed (b)(3), the program "must include":

1. an inventory and classification of assets, processes, and sensitivity of data;
2. controls supporting and safeguarding sensitive information and processes;
3. evaluation, validation, and reporting processes to ensure that key information technology systems and controls, including smart contracts, are operating as intended;
4. periodic independent testing; and
5. a comprehensive and effective incident identification and assessment process and incident response program.

Note what sits inside element three: smart contracts, named directly in rule text as systems whose operation must be validated. The proposal then widens the aperture. Its words: "When identifying the key information technology systems to be addressed in the program, a Board-supervised PPSI would be expected to consider all technologies on which it relies. This includes systems operated by the Board-supervised PPSI and its vendors, such as smart contracts. It also includes key information technology systems such as the blockchains on which its payment stablecoins circulate."

All technologies. Your systems, your vendors’ systems, and the chains themselves. The Board would expect each relevant system addressed "based on the materiality of the risks the system poses," and the program "must ensure that Board-supervised PPSIs are well positioned to protect against the unique cybersecurity risks presented by digital assets." There is proportionality too: "A Board-supervised PPSI’s information technology program should be tailored to its size and complexity and the nature, scope, and risk of its activities." A forty-person issuer is not being asked to build a Wall Street org chart. It is being asked to prove all five elements operate.

The two AI sentences

Here is the passage, verbatim, from the proposal’s discussion of the program requirement:

"Board-supervised PPSIs could be vulnerable to certain information technology and cybersecurity failures or attacks by artificial intelligence tools that are rapidly developing capabilities that allow them to detect and exploit weaknesses in websites and online portals."

And the failure scenario the Fed spells out immediately after:

"...many stablecoins rely on smart contracts to control minting and burning. A security breach involving such a smart contract or caused by an artificial intelligence tool could lead to the unauthorized minting of new coins without the receipt of additional reserve assets."

The footnote behind the first sentence (footnote 61) cites Robert McMillan and Chip Cutter’s April 13, 2026 Wall Street Journal story, "AI Is Finding Bugs That Hackers Can Exploit. Get Ready for Bugmageddon." I am taking the Fed’s footnote at face value here and doing something deliberate with it: the claims in that news story are the Fed’s sourcing, not mine, and this article does not re-assert them. What matters is the regulator’s judgment. A US banking agency looked at attacker-side AI capability and decided it belonged in the threat model of a proposed rule, with a concrete failure mode attached.

That reframes what AI risk means for this audience. Most of what gets written about AI in financial services deals with the models companies use: governance of their own tools, their own copilots, their own agents. Useful subject, different discipline. This proposal is about the other side of the ledger: adversaries using AI to find and exploit weaknesses in the issuer’s perimeter, with minting integrity as the target. If the rule lands anywhere close to as drafted, stablecoin issuer information security stops being a best-effort discipline and becomes an examinable program, and AI-aware threat monitoring is part of what the program is expected to cover. We keep an AI governance practice aimed at exactly this collision of AI capability and regulated financial infrastructure, since the attacker-side and defender-side obligations now rhyme on both pages.

The minting sentence deserves its own minute. The Fed did not frame the scenario as data loss or even as fraud in the conventional sense. It framed the breach as unauthorized creation of money without reserves. That is why this requirement lives in the risk-management section, next to reserves and redemption, rather than in a technical appendix. For security leaders, it hands you the board-level argument you have probably been missing: the program protects the integrity of issuance itself.

The clock, stated precisely

The timing question trips people up, so here is the statute’s own language, quoted from the proposal:

"The GENIUS Act’s effective date is the earlier of 18 months after the enactment date (July 18, 2025) or 120 days after the primary Federal payment stablecoin regulators issue any final regulations implementing the Act."

Eighteen months after July 18, 2025 is January 18, 2027. So the GENIUS Act effective date question comes down to this: the Act takes effect on the earlier of that January date or 120 days after final regs. As of this writing on October 5, 2026, no final rule from the Fed, OCC, or Treasury implementing the Act’s security requirements appears in the Federal Register. What January 18, 2027 is: the outside date on which the Act takes effect absent earlier final regs. What it is not: a deadline for the rulebook to be finished, and not a compliance date issuers can mark on a calendar. The comment stages are part of the schedule now.

The windows, per document. Treasury’s August 18 NPRM covering issuance, offer, and sale of payment stablecoins (doc 2026-16796) takes comments "on or before October 19, 2026," which is fourteen days from this writing. The Fed’s two September 29 proposals accept comments through November 30, 2026, fifty-six days out. Comment letters written now land while the final security rulebook is still wet cement.

Does comment-stage status change anything about what you should build? It changes the certainty, not the lead time. Proposals get reshaped; thresholds move. But the five-element architecture appears independently in both the Fed and OCC drafts, and the kind of program both describe takes quarters to stand up: framework writing, control implementation, validation evidence, testing cadence, board reporting. Waiting for final text means building under a deadline instead of building ahead of one.

Five documents, not one

One week of rulemaking produced a stack of documents that blur together in coverage. They are different instruments:

The Fed implementation proposal (2026-19860). The Federal Reserve’s rules implementing its responsibilities under the GENIUS Act for Board-supervised PPSIs. Contains proposed Section 247.13 and its security program. This article’s subject.

The Fed subsidiary-application proposal (2026-19899). Application procedures for a Board-supervised insured depository institution seeking approval for a subsidiary to issue payment stablecoins. Process, forms, not security controls. Relevant if your bank parent is weighing the subsidiary path.

Treasury’s issuance NPRM (2026-16796, published August 18). Covers the Act’s Section 3 prohibitions and limitations on who may issue, offer, and sell payment stablecoins. A different subject entirely from security programs, and the one with the imminent comment deadline.

Treasury’s interim final rule (2026-19966, published September 30). This one is final now, an interim final rule with a comment request. Be precise about its reach: it adopts procedural regulations and forms for the Stablecoin Certification Review Committee, which reviews state certifications. Committee procedure, not issuer security programs.

The OCC proposal (2026-04089, published March 2026). The OCC-jurisdiction counterpart. Its proposed Section 15.13(b) would require OCC-supervised issuers to implement a comprehensive written information security risk and control framework, with board approval, a qualified Information Technology and Security Officer, and the same five program elements. Two agencies drafting the same architecture months apart is the clearest available signal of where the final rules land.

The issuer build list

If you are preparing for PPSI registration, the five elements translate into an ordinary security roadmap wearing exam-grade clothes. In order:

The inventory comes first because everything else leans on it: the assets, the processes, the sensitivity of the data, and for an issuer that means the systems that can create or destroy coins and the reserve arrangements behind them. In practice, the inventory is the artifact everyone is sure already exists until someone asks to see it. Next, the controls that safeguard those sensitive processes: access management around mint and burn, key custody, change control over contract deployments, segregation of duties between the people who can move reserves and the people who can move code.

Third, validation of key systems including smart contracts, with reporting. The proposed rule text says the point is to make sure key systems and controls "are operating as intended," which is an evidence problem as much as an engineering one: what was tested, by whom, against what, reported to whom. Fourth, periodic independent testing, where "independent" is doing real work: testing done by people who did not build or operate the thing, on a cadence you can prove. Fifth, incident identification and response, and for an issuer the scenarios have a particular shape: unauthorized or erroneous minting and burning, a material failure in an underlying blockchain (the proposal notes one could undermine an issuer’s ability to identify the rightful holders of its coins for redemption), and a breach at a vendor sitting inside your program scope.

The policy itself is usually not the difficult part. Proving the controls operate consistently, quarter after quarter, with reports a board can actually use, is where programs succeed or fail. That is the work the named Information Technology and Security Officer signs up for, and it is most of what a fractional CISO runs day to day. If you want help standing that program up ahead of a final rule, the broader risk and compliance practice covers the buildout from gap assessment to board reporting.

If you sell to issuers

Read the scope sentences again from the vendor chair. Customer programs must cover "systems operated by the Board-supervised PPSI and its vendors, such as smart contracts." Custody providers, smart-contract development teams, treasury and reserve management tooling, chain infrastructure: your systems are inside your customer’s program scope, and the same proposal puts program-related reports in front of their boards. Exam-grade expectations propagate down the chain through exactly one mechanism, diligence, so expect the questions to get better rather than fewer.

The evidence to have ready is specific: an asset inventory you can produce on request, control documentation that maps to what the customer’s framework asks, validation and testing results rather than assurances, and an incident response runbook with named roles and timelines. If a board will review your customer’s program, your evidence ends up in that pack. Vendors whose files are boring win. The vendor side of this story runs in parallel with the banks’ own proposed third-party risk overhaul, which we covered separately with a different buyer in mind.

What to do with fourteen days and fifty-six

If you issue or intend to:

1. Run a gap assessment against the five elements this month, not next quarter. Where is the written framework, who is the accountable officer candidate, what does the board receive today?
2. Build or refresh the inventory first, classified, and include vendor systems and the chains you depend on. It feeds every other element.
3. Write down your smart-contract validation story: what testing exists, who signs it, what cadence, who sees the results.
4. Schedule independent testing. Cadence and independence are the two things the proposed text emphasizes, and both take lead time to arrange.
5. Stand up issuer-specific incident scenarios: unauthorized mint or burn, chain disruption, vendor breach. Then decide who is the Information Technology and Security Officer, because proposed (b)(2) wants a name.
6. Decide on comment letters before the windows close: November 30 for the Fed proposal, and if some element does not fit mid-market operations, say so in writing now rather than negotiating with a final rule later.

If you are the vendor: assemble the four-part evidence pack, align your public claims with what a customer program can actually cite, and get ahead of the diligence wave instead of meeting it cold.

The build this proposal describes, inventory, controls, validation, independent testing, and incident response, stretched across your own systems, your vendors, and the blockchains you depend on, is bread-and-butter security program work. The GENIUS Act stablecoin rules just wrote it down and put a clock on it. If you are racing that clock and want an experienced operator’s hands on the build, start with our digital assets security practice, or the broader cybersecurity risk and compliance work behind it. For a direct conversation about your specific posture, the contact page is the fastest route.