The GENIUS Act: What It Resolves, and What It Does Not

Commercial banks and large payment service providers now have federal clarity on payment stablecoin issuance. The GENIUS Act, enacted in July 2025, establishes a defined framework: permitted issuer categories, 1:1 reserve requirements in high-quality liquid assets, segregated accounts, no rehypothecation, monthly reserve certification. For institutions that have been waiting for regulatory certainty before committing resources, that clarity is genuine and significant.

However, legal clarity and operational readiness are not the same thing. The questions the GENIUS Act resolves are important. The questions it does not resolve are the ones that will determine whether your issuance programme actually works.

What the Act establishes

The reserve structure is well-defined. Reserves must be held in cash, bank deposits, Treasury bills with maturities under 93 days, or similar federal instruments. They must be segregated. They cannot be rehypothecated except in narrow, defined scenarios. Monthly audits and certifications are required from the point of approval.

For institutions already operating at this level of treasury discipline, the reserve framework is familiar territory. A regulated bank holding 1:1 reserves in liquid instruments is not a novel concept. It is essentially a fully reserved deposit model applied to on-chain liabilities.

One constraint worth noting explicitly: the Act prohibits payment stablecoins from paying yield or interest to holders. For banks evaluating stablecoin deposit products that offer a return to customers, this distinction matters since such products fall outside the payment stablecoin framework and remain governed by existing deposit product regulation. The infrastructure considerations in this piece apply specifically to non-yield-bearing payment stablecoins.

The Act also permits national banks to issue through subsidiaries with parent regulator approval. For institutions structuring issuance this way, the signing infrastructure question extends to the parent-subsidiary relationship: how key ownership and signing governance are structured across entities, and whether the subsidiary operates its own infrastructure or inherits it from the parent. These are decisions that need to be resolved before the infrastructure is selected, not after.

The question the reserve framework does not answer

The reserve framework governs what backs your stablecoin, with little direction on how your stablecoin is operated.

Every mint event, every redemption, every reserve transfer requires an on-chain transaction. That transaction requires a cryptographic signature. The infrastructure that produces that signature - along with who controls it, where it runs, what governance sits above it - is where most institutions have done the least work.

Consider the operational sequence for a single commercial client minting $50 million of stablecoins. A request is initiated. It must be authorised by someone with the appropriate internal mandate. That authorisation may require a second approval above a threshold. The signing infrastructure executes the on-chain transaction. The core banking system records a corresponding liability. The reserve account is updated. A full audit trail is produced.

Strip away the on-chain element, and this is a standard treasury operation. The difference is that the execution layer (the signing of the on-chain transaction) is a form of custody infrastructure that most banks have not operated before. Who owns it, how it is governed, and where it runs are not configuration questions; they are institutional infrastructure decisions.

What your examiner will ask

OCC examiners approaching stablecoin infrastructure are likely to apply the same framework they use for any critical banking system. The proposed rulemaking under 12 CFR 15 addresses activities, risk management, audits, and custody in sequence. The implied examination priorities are reasonably foreseeable, even where formal examination procedures have not yet been published. As a result, the questions your infrastructure must be able to answer include the following.

Who owns the keys? Most MPC wallet providers retain one or more key shares and operate the infrastructure that manages them. In practice, this means the provider participates in every signing decision. If they are unavailable - for any reason: technical failure, a sanctions decision, a contractual dispute - you cannot sign. For a bank whose stablecoin represents a liability to depositors, that dependency is an overbearing third party dependency risk that requires documentation, governance, and a tested contingency. "We rely on their SLA" is not a satisfactory answer to an examiner.

Where does the infrastructure run? A pure SaaS custody model places your signing operations on a third party's infrastructure. For institutions with data residency requirements, internal security standards, or regulators who want to inspect infrastructure directly, this creates a structural problem that a vendor's compliance documentation does not resolve. Signing infrastructure that operates within your own environment - your cloud, co-hosted, or on-premises - is a different category of answer.

Can you demonstrate control over who initiates, approves, and executes? The approval policy governing who can mint, what amounts require escalation, and which counterparties are pre-approved for transfers must be formally enforced by the signing infrastructure itself. A spreadsheet or a manual process running alongside the technology is not a control. Examiners will treat it accordingly.

What does the audit trail show? Monthly reserve certification is the floor the Act sets. Examiners will expect operational records for every signing event, every access change, every approval and rejection. If your infrastructure cannot produce this at a level your compliance team can work with, it was not built for a regulated institution.

The workflow design questions most teams have not resolved

Beyond the examiner checklist, there are operational design questions that require answers before go-live. The mint and burn authorisation model needs to be defined explicitly. Who can initiate a mint request? At what threshold does a second approval apply? What is the procedure when the primary authorising officer is unavailable? These policies need to be codified in the signing infrastructure before you are live and not discovered when the first large redemption request arrives.

The integration between on-chain execution and core banking is not automatic. When a stablecoin is minted, a liability is created. When it is redeemed, the liability is extinguished. The reconciliation between on-chain state, wallet software state, and core banking records must be designed, tested, and governed. What happens in the event of a failed transaction, a network-level anomaly, or a signing failure mid-operation needs to have a documented answer.

For institutions considering multi-chain issuance, or still evaluating which chain best suits their operational and regulatory profile, the signing infrastructure must govern operations consistently across chains, with a unified audit trail and approval policies that apply regardless of which network the stablecoin runs on. The chain selection decision and the signing infrastructure decision are not independent of each other. In short, your control plane should be consistent, and the blockchains you work with can be swapped in or out of it.

Emergency procedures matter more than most teams anticipate at the design stage. If a fraudulent mint is identified, the ability to act quickly with the right authorisation, on the right timeline is an operational requirement. It is worth noting that the capacity to freeze or burn tokens in an emergency depends partly on whether the stablecoin's smart contract incorporates those controls at the token level; this is a design decision that intersects with the signing infrastructure question and should be resolved at the outset, not discovered under pressure. Banks have documented emergency procedures for every other critical system. The stablecoin signing layer needs the same.

The timeline is shorter than it looks

Final implementing rules were due from regulators by July 18, 2026. The compliance effective date follows 120 days after rules are issued — placing it around November 2026, with a January 2027 outside date.

Working backwards from that window for a commercial bank or large PSP: vendor selection and contract negotiation typically requires several months at a regulated institution. Implementation and integration of signing infrastructure, depending on scope, could also take a few months for a production deployment. Internal security review, compliance sign-off, and testing add another six to eight weeks.

The arithmetic is uncomfortable. Adding realistic ranges for each stage, institutions that have not yet selected their infrastructure have little to no margin against a November 2026 deadline. The January 2027 outside date provides some relief but only if regulators are delayed in issuing final rules, and that is not a procurement strategy.

This is not a reason to rush into a poor decision either. It is a reason to start a properly structured evaluation now rather than after the final rules land.

A practical starting point

There are two distinct positions from which an institution might be reading this.

The first is having already identified gaps. Possibly in an existing provider, in the current signing infrastructure, or in the governance model sitting above it and needing to understand quickly whether an alternative resolves them. For those institutions, the most direct route is evaluation. Sign up to Cordial's risk-free self-service trial access, here, and configure a wallet structure that reflects your operating model, apply your approval policies, and run test transactions against real infrastructure. If the architecture does not fit your requirements, you will know quickly. If it does, you have the basis for a more structured conversation and you have avoided wasting weeks of time testing the viability assumption.

The second position is for those earlier in the journey. A commercial bank working through GENIUS Act readiness is unlikely to evaluate signing infrastructure through a self-service trial before the vendor has established credibility with their security, compliance, and technology teams. That procurement motion is longer, and appropriately so. For those institutions, the right starting point is a direct conversation to understand the deployment architecture, reviewing the SOC2 Type II documentation, and establishing whether the infrastructure model aligns with internal requirements before any hands-on evaluation begins. You can start your conversation with Cordial today by booking a meeting here.

Both paths lead to the same question: does this infrastructure meet your requirements. The difference is the order in which you answer it.

Cordial is SOC2 Type II certified, supports deployment on your own infrastructure - cloud-hosted in a Trusted Execution Environment, co-hosted, or on-premises - and gives the issuing institution full ownership of all MPC key shares if desired. In on-premises and co-hosted deployments, the signing infrastructure runs entirely within the institution's own environment. In the cloud-hosted TEE option, the execution environment is cryptographically isolated from the cloud operator (including Cordial Systems) by design. Cordial can provide a deployment that works with your target operating model and with clearly understood lines of responsibility and no surprises.