Comment on the Federal Reserve's GENIUS Act Proposal (R-1899): Build on the OCC Rule, Name Automated Systems, Clarify Tying for Software

Empty Set LLC appreciates the opportunity to comment on the Board’s proposal. We offer three suggestions, each built on text the Board or a peer regulator has already written.

Each suggestion works within the principles-based, technology-neutral approach the proposal takes. None adds a new reporting line or a new mandate.

Empty Set LLC is a Nevada company that builds financial infrastructure for a near-term reality: software agents that hold, move, and spend money on behalf of a person or business. Payment stablecoins have become a common settlement asset for these agents, which makes the Board’s rule part of the operating environment for this market.

This comment continues our participation in the GENIUS Act rulemakings. In March 2026, we commented to the OCC (Docket OCC-2025-0372, RIN 1557-AF41), the Federal Deposit Insurance Corporation (FDIC) (RIN 3064-AG20), and the National Credit Union Administration (Docket NCUA-2025-1335, RIN 3133-AF69) on how automated systems fit into stablecoin risk management. In September 2026, we commented to the Securities and Exchange Commission on transfer agent modernization (File No. S7-2026-30), addressing how software acting for a principal should fit into ownership records.

Since those filings, the OCC has finalized its rule.¹ The OCC chose “the principles-based and technology-neutral approach” to risk management and declined to set detailed requirements for particular technologies.² We support that choice. The suggestions below work within it.

Question 239 asks whether the Board should adopt any aspects of the OCC’s approach. The Act takes effect no later than January 18, 2027, and issuers under different regulators will share the same customers, wallets, and settlement networks. Matching text wherever the statute allows will reduce compliance cost and give the market one vocabulary. We suggest four points of alignment.

A. Holder means beneficial owner

Question 23 asks whether to define “payment stablecoin holder” by beneficial ownership or by control of keys. We support the OCC’s choice of beneficial ownership. A growing share of stablecoin balances will sit in wallets that a wallet provider or a software agent controls on a principal’s behalf. A key-control definition would treat the wallet operator as the holder. A beneficial-ownership definition keeps the holder’s redemption rights and priority with the person who owns the economic interest, whatever software stands in between.

B. Automated reserve management

Responding to a comment that asked about automated systems, including those executed by smart contracts, the OCC confirmed that issuers may run reserve management through automated systems as long as those systems meet the rule. A parallel sentence in the Board’s final preamble would give Board-supervised issuers the same certainty and keep the two frameworks aligned.

C. Machine-readable reporting forms

The Board joined the Financial Data Transparency Act joint data standards rule in June 2026.⁷ The proposal does not yet say how the weekly report under § 247.14(h), the quarterly report under § 247.14(i), or the monthly reserve composition template under § 247.11(d) will relate to those standards. The OCC has committed that its forms will be consistent with them.

A similar commitment from the Board would answer Question 246’s invitation to consider “automating aspects of reporting or oversight.” It would also serve Question 145’s goal of minimizing duplication, because an issuer that reports to more than one regulator could produce one structured data set. The public monthly composition report matters most here. Treasury tools, auditors, and automated agents that decide which stablecoin to accept will read that report, and a machine-readable version beside the PDF lets them read it reliably.

D. Service-provider monitoring

Proposed § 247.13(a)(5)(iii) asks issuers, “as appropriate,” to monitor third-party relationships “including by reviewing audits, summaries of test results, or other equivalent evaluations.” The OCC’s final § 15.13(a)(7)(iii) states the purpose of that monitoring, which is to confirm that service providers “have satisfied their obligations,” and makes the review of audits or equivalent evaluations part of it. Matching that wording costs little and gives examiners one standard across charters.

The proposal recognizes the risk directly. It notes that issuers “could be vulnerable to certain information technology and cybersecurity failures or attacks by artificial intelligence tools,” and that a 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 tools issuers use to defend against those risks have also changed. In April 2026, the Board, the FDIC, and the OCC replaced SR 11-7 with SR 26-2, revised guidance on model risk management. That guidance states:

“Generative AI and agentic AI models are novel and rapidly evolving. As such, they are not within the scope of this guidance. Nonetheless, a banking organization’s risk management and governance practices should guide the determination of appropriate governance and controls for any tools, processes, or systems not covered in this document.”⁹

We think the agencies made a sensible choice. The field is moving quickly, and model risk guidance written for statistical models fits these systems poorly. In our March comment to the OCC, we observed that SR 11-7 was not built for automated systems that act rather than inform. SR 26-2 now says so expressly, and it points institutions to their own risk management and governance practices.

For payment stablecoin issuers, the Board’s proposal already contains that governance home. Proposed § 247.13(b)(3)(iii) requires “evaluation, validation, and reporting processes to ensure that key information technology systems and controls, including smart contracts, are operating as intended.” We suggest one addition, shown in bold:

3. evaluation, validation, and reporting processes to ensure that key information technology systems and controls, including smart contracts and automated systems that can initiate the issuance, redemption, or transfer of payment stablecoins or the movement of reserve assets, are operating as intended;

This wording describes what a system can do, not how it works, so it stays technology-neutral. It covers today’s agentic tools and whatever replaces them. It adds no new program, because the inventory, validation, independent testing, and incident response elements of § 247.13(b)(3) already apply. It simply makes clear that systems outside SR 26-2’s scope still have a named place in the issuer’s program.

We also suggest one sentence in the final preamble. It would confirm that the “equivalent evaluations” referenced in § 247.13(a)(5)(iii) include independent testing of automated systems a service provider supplies. Many issuers, especially smaller ones, will license these systems rather than build them. This answers Question 125’s concern about third-party risk without prescribing a method.

The tying prohibition in § 247.40 applies to every permitted payment stablecoin issuer, so the Board’s reading will shape the whole market. The proposal explains that the prohibition is narrower than section 106 of the Bank Holding Company Act Amendments of 1970. It reaches arrangements that place conditions on the availability of an issuer’s services, and price differences alone do not necessarily violate it.¹⁰ We agree with that reading.

Question 197 asks whether the Board should address “permitted or prohibited bundling of products and services.” A large share of that bundling will happen in software. Stablecoins increasingly reach customers through programmatic interfaces for issuance and redemption, developer toolkits, and wallets that automated agents operate. Public developer documentation for agent payment tools shows a consistent pattern. Prices default to a single dollar stablecoin. Some tools let a merchant accept other tokens with a configuration change. Some settlement paths support only one stablecoin.

None of these designs is a tie by itself. Clear examples now would help issuers build compliant products from the start and would reduce case-by-case exception requests under § 247.41(c). We suggest three clarifications.

A. Programmatic access is a service

Access to issuance and redemption interfaces, developer toolkits, and agent wallets offered by an issuer or its subsidiaries counts as “services” under § 247.40(a). If an issuer conditions that access on the customer buying an additional paid product, such as a paid custody tier, the statute reaches that condition, just as it would for the same condition imposed at a branch.

B. A default is not a condition when the customer has a meaningful option

The Board has a well-tested framework for this question. In its 2003 interpretation of section 106, the Board explained that an arrangement does not require a customer to buy a product when the customer has a “meaningful option” to satisfy the bank’s terms another way.¹¹ The same idea fits software. A default setting that selects the issuer’s own stablecoin is not a condition when the customer, or software acting for the customer, can change it at no cost and without losing access to the service.

C. Technical support for a single stablecoin is not an agreement

Section 4(a)(8)(A) also bars conditioning services on the customer’s agreement “to not obtain an additional product or service from a competitor.” Some tools work with only one stablecoin. We suggest the Board say that this design choice, by itself, is not such an agreement. The prohibition would apply where an issuer’s terms withdraw or degrade its services because the customer also uses a competitor’s product.

These examples summarize the reading we suggest:

Examples like these would answer Question 196, which asks whether the rule needs further clarification, without new rule text. They could appear in the final preamble or in later guidance. They would also inform the factors the Board weighs under Question 199 if it later considers exceptions.

1. Build on the OCC’s final rule. We suggest defining “payment stablecoin holder” as the beneficial owner, confirming that issuers may use automated reserve management that meets the rule, committing to reporting forms consistent with the FDTA joint data standards, and aligning service-provider monitoring with 12 CFR 15.13(a)(7).
2. Consider naming automated systems that model risk guidance now leaves out. We suggest adding “automated systems that can initiate the issuance, redemption, or transfer of payment stablecoins or the movement of reserve assets” to § 247.13(b)(3)(iii), and confirming in the preamble that “equivalent evaluations” include independent testing of vendor-supplied automated systems.
3. Consider clarifying how the tying prohibition applies to software. We suggest confirming that programmatic access is a service, applying the Board’s “meaningful option” framework to default settings, and stating that technical support for a single stablecoin is not by itself an agreement to avoid competitors.

We appreciate the Board’s careful work on this proposal and the clear questions it posed. We would welcome the chance to discuss any of these suggestions with Board staff.

Respectfully submitted,

Brice Love
Co-Founder & Managing Member
Empty Set LLC

1. Office of the Comptroller of the Currency, Implementing the Guiding and Establishing National Innovation for U.S. Stablecoins Act for the Issuance of Stablecoins by Entities Subject to the Jurisdiction of the Office of the Comptroller of the Currency, 91 FR 67000 (October 23, 2026).
2. Id. at 67075.
3. Id. at 67177.
4. Id. at 67044.
5. Id. at 67084.
6. Id. at 67182 (12 CFR 15.13(a)(7)).
7. Financial Data Transparency Act Joint Data Standards, 91 FR 38246 (June 25, 2026).
8. 91 FR 61610.
9. Board of Governors of the Federal Reserve System, FDIC, and OCC, Revised Guidance on Model Risk Management, SR 26-2 Attachment, n.3 (April 17, 2026), https://www.federalreserve.gov/supervisionreg/srletters/SR2602a1.pdf.
10. 91 FR 61636–37.
11. Anti-Tying Restrictions of Section 106 of the Bank Holding Company Act Amendments of 1970, 68 FR 52024, 52031 (August 29, 2003).

AI Disclosure

This comment was developed with the assistance of AI tools, including Claude (Anthropic) for research synthesis, drafting, and citation verification, and Gemini (Google) for supplementary research. All substantive positions, strategic judgments, and final editorial decisions are those of the human author. Research sources include the Board’s proposed rule (91 FR 61580), the OCC’s final rule (91 FR 67000), SR 26-2 and its attachment, the Financial Data Transparency Act joint data standards rule, the Board’s 2003 interpretation of section 106, the GENIUS Act (Pub. L. 119-27), and public developer documentation for agent payment tools. All specific claims and citations were independently checked against primary sources before inclusion.