Federal Reserve GENIUS Act Proposal: IT Security Standards

Video transcript

The Fed's GENIUS Act proposal would make stablecoin issuers validate smart contracts, test independently and manage private keys. Comments are due November 30, 2026.

Proposed section 247.13 requires a board-approved IT and security program. It must include an asset and data inventory, controls over sensitive information, validation of smart contracts, periodic independent testing, and incident response.

The Board's example risk is unauthorized minting. A smart contract breach, or an attack by an AI tool, could mint coins with no reserve assets behind them.

Material systems need rigorous independent testing at regular intervals. Think security reviews and invariant tests for token contracts, signer and recovery reviews for key systems, and pentests for minting APIs and cloud.

Keys need management, backup and recovery. Inventory every key that can mint, burn or upgrade, require a quorum, and run a dated recovery test. Vendors that write mint code, hold keys or monitor chains are covered third parties.

The OCC's final rule has an almost identical program, plus program adjustments and notice of unauthorized access, including to private keys. If you are building now, plan to the OCC version.

Guardian audits mint, burn and role logic, reviews key custody, and pentests the offchain path to the same assets. Read the full article, or talk to Guardian at guardian.security.

On September 29, 2026, the Federal Reserve Board proposed GENIUS Act standards for the issuers it supervises (Docket R-1899). Comments close on November 30, 2026.

The proposal names smart contracts as key IT systems and requires private key management, backup and recovery.

The OCC's final rule, with an almost identical IT program, is already published. Banks planning a Fed-supervised issuer can still shape the Fed's version.

This article explains the technical and security side of proposed 12 CFR 247.13. It is not legal advice; confirm how it applies to you with counsel.

Who It Covers

The proposal (91 FR 61580) adds a new 12 CFR part 247. Its IT and security standards apply to a "Board-supervised PPSI" (permitted payment stablecoin issuer).

The preamble says the term includes two groups:

• subsidiaries of insured State member banks that the Board has approved to issue
• uninsured State-chartered depository institutions that are State-qualified issuers and have moved to the Board's framework

Under § 247.13(c), a bank subsidiary is deemed to comply if it participates in its parent's enterprise-wide risk management framework. That framework must align with appendix D-1 to 12 CFR part 208.

What the Program Must Include

Proposed § 247.13(b) requires a written, board-approved program, tailored to the issuer's size, complexity and risk. The board must appoint a qualified Information Technology and Security Officer.

Under (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.

Paragraphs (b)(4) to (b)(6) add business continuity, safeguards for nonpublic personal information, and safe handling of digital assets.

The scope is wide. The preamble says an issuer should "consider all technologies on which it relies," including vendor-operated systems "such as smart contracts" and the blockchains its coins circulate on.

The OCC's final rule (91 FR 67000, effective January 18, 2027) has an almost identical program. It adds monitoring and adjusting the program, and notice of unauthorized access to customer information, including a customer's private key.

The Fed asks in Question 126 whether to add similar requirements. If you are building now, plan to the OCC's fuller version.

Smart Contracts and Unauthorized Minting

The preamble explains why smart contracts are named: "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 same scenario shapes the proposed operational risk capital requirement in § 247.18. The Board notes that "the larger the unauthorized minting of payment stablecoins, the more likely it is to be detected".

That leans on detection. An issuer that cannot see its own mint events quickly is relying on someone else to catch the exploit.

What "operating as intended" should show

The rule does not define the evidence. For mint, burn and role logic, these artifacts trace to the running system:

• A role map: holder, threshold and timelock for every privileged role, read from the deployed contracts.
• Deployment verification: bytecode on each chain matched to the reviewed commit and configuration.
• Invariants tying minting to reserves, tested by fuzzing and rerun on every change.
• Monitoring of mint, burn, role and upgrade events on every chain, routed to someone who can pause.
• A tested freeze and burn path, since the Act requires the capability to comply with lawful orders.

Independent Testing by Materiality

Proposed § 247.13(b)(3)(iv) requires "periodic independent testing" without fixing a frequency or method.

Minimal-risk systems "would require fewer controls," the preamble says. Material ones need "rigorous independent testing at regular intervals".

The internal audit standard in § 247.13(a)(2) adds independent testing of internal controls and information systems, with documented findings and verified fixes.

A workable way to tier the testing:

Keys, Vendors and Continuity

Proposed § 247.13(b)(6) requires "appropriate measures to ensure secure handling of digital assets, including private key management, backup, and recovery".

The Board says § 247.13 is consistent with the July 14, 2025 joint statement on crypto-asset safekeeping. That statement flags secure key generation and planning for lost or compromised keys.

A key file that answers (b)(6) holds:

• every key and signer that can mint, burn, freeze, pause or upgrade, per chain
• the quorum design, so no one person acts alone
• ceremony records and the custodian or HSM behind each key
• a dated, performed recovery, and revocation steps for departing signers

Third parties count too. Under § 247.13(a)(5), the issuer must do due diligence, bind providers by contract to part 247 and monitor them.

The preamble's examples include providers that support mint and burn code, custody of private keys for smart contracts, and blockchain monitoring.

Proposed § 247.13(b)(4) requires continuity of critical functions, including testing with critical service providers. The preamble says issuers should have controls for operational issues with burning and minting.

Exercise an unreachable signer quorum, a halt on one chain, a monitoring outage and a compromised minter, each with a dated test.

What to Comment On

The Board asks commenters to cite its question numbers. The technical ones:

• Question 126: whether § 247.13(b) should "expressly address risks relating to smart contracts, encryption, or any other technology or procedure".
• Question 126 also: requirements like those the OCC proposed on notice of unauthorized access and program adjustments.
• Question 127: standards for moving stablecoins across blockchains to meet redemptions.
• Question 129: risks from the blockchains coins circulate on.
• Question 130: IT risks of tokenized reserve assets.

File on the Board's proposals page at federalreserve.gov/apps/proposals (preferred), or email publiccomments@frb.gov with "Docket No. R-1899" in the subject line.

Comments are published without removing personal or business information, so leave out anything confidential.

For the wider picture, see our stablecoin regulation guide, the freeze requirements comparison and multichain deployment verification.

How Guardian Helps

Guardian works with institutions on the systems this proposal names. We design privileged roles, thresholds and key custody before they are built.

We audit what you deploy with competing manual and AI teams plus an invariant suite, and pentest the offchain path to the same assets.

Our regulatory compliance practice maps each artifact to the provision it answers. We are not a law firm; the legal reading stays with your counsel.

Frequently Asked Questions

Is the Federal Reserve GENIUS Act proposal final?

No. It is a notice of proposed rulemaking published September 29, 2026 (91 FR 61580, Docket R-1899). Comments must be received by November 30, 2026, and the Board can change the text before it adopts a final rule.

Does the proposal require a smart contract audit?

Not by name. It requires processes that confirm smart contracts operate as intended, and periodic independent testing that must be rigorous for material systems. An independent review of mint, burn and role logic is the most direct evidence of both.

How is the Fed proposal different from the OCC final rule?

The core program is the same. The OCC rule also requires monitoring and adjusting the program, and notice of unauthorized access to customer information, including a customer's private key. The Fed asks in Question 126 whether to add those.

Sources

• Federal Register: Implementing the Federal Reserve Board's Responsibilities Under the GENIUS Act, 91 FR 61580, proposed rule, Docket R-1899 (September 29, 2026)
• Federal Register: OCC final rule implementing the GENIUS Act, 91 FR 67000 (October 23, 2026)
• GovInfo: Public Law 119-27, Guiding and Establishing National Innovation for U.S. Stablecoins Act (July 18, 2025)
• Federal Reserve, FDIC and OCC: Crypto-Asset Safekeeping by Banking Organizations, joint statement (July 14, 2025)