The Banks Are Building The New Money Rail - 21 Institutions. One Stablecoin. A New Era of Financial Infrastructure.
Updated: 11 hours ago
Inside the Global Bank Stablecoin Project
Twenty-one financial institutions are preparing a shared digital dollar. The harder task is building the reserves, controls and payment connections that make it useful—and deciding who owns the business around it.
September 2, 2026 | Financial infrastructure | Reported analysis
The promise of a bank-backed stablecoin can be expressed in a few seconds: a dollar that moves across a blockchain at any hour. Delivering that promise requires decisions about institutions that work on different schedules, software that records different versions of a payment, and legal claims that do not become identical simply because their tokens trade at the same price.
On September 1, 2026, a group of 21 financial institutions committed to establishing a company in the second half of the year, subject to closing conditions, to support a stablecoin offering. It is targeting the first half of 2027 for market entry, beginning with a dollar product and prioritizing the euro in a subsequent expansion into other G7 currencies.
The group includes Bank of America, Citi, Goldman Sachs, Wells Fargo, Santander, Deutsche Bank, UBS and MUFG, alongside Fidelity Investments and WisdomTree. Its description as a group of financial institutions matters: this is a coalition that extends beyond deposit-taking banks. The proposed uses include cross-border payments and digital-asset settlement across institutional, wholesale and retail markets.
For the participants, the commercial attraction is understandable. A shared token could give their customers a common instrument for moving money between institutions and financial applications. Ownership of the issuer could also give members influence over the terms on which that money is distributed, redeemed and integrated into other services.
But a coalition is not yet a payment network. The decisive questions concern the work between the announcement and a dependable service: who owes the holder a dollar, who can authorize issuance, where the backing sits, and what happens when the recipient needs ordinary bank money on a Sunday.
What the announcement leaves unresolved
The September announcement leaves the company unnamed and does not specify a blockchain, token contract, custody provider, reserve allocation, fee schedule or redemption timetable. It expresses an intention to comply with the GENIUS Act and MiCA where applicable; it does not announce completed approvals.
Those omissions constrain what can responsibly be reported about implementation. Ethereum, Solana, Stellar, Chainlink, Fireblocks and other names frequently appear in discussions of institutional digital assets. None should be described as this consortium’s selected infrastructure on the strength of that announcement.
Existing products nevertheless provide a useful way to examine the engineering choices.
The examples below are documented implementations elsewhere in the industry. The payment walkthrough is illustrative, and the assessment of the consortium’s incentives is analysis rather than a claim about private negotiations.
This distinction also changes how the project should be judged. An announced launch date is a commercial target. A functioning service needs tested issuance and redemption, operational accountability, usable distribution and customers willing to put real payments through it repeatedly.
The legal claim behind the digital dollar
Bank money is already digital. A corporate treasurer does not need a blockchain to see a dollar balance on a screen or initiate an electronic payment. Tokenization changes how claims can be represented and transferred, and how software can coordinate their exchange.
The nature of the claim remains critical. A conventional deposit is a liability of the bank holding the account. A tokenized deposit preserves a bank-deposit claim in a different technological form. A reserve-backed stablecoin represents a claim under its issuer’s legal arrangements, supported by a portfolio intended to meet redemptions. The GENIUS Act expressly distinguishes payment stablecoins from deposits, including deposits recorded using distributed-ledger technology.
A transfer of a stablecoin therefore need not put a new deposit into the recipient’s bank account. It can deliver a token that the recipient holds, spends, sells or presents for redemption. Whether that token satisfies a commercial invoice depends on the payment terms agreed by the parties.
Central-bank money is another distinct claim. The Bank for International Settlements argues for a system in which tokenized commercial-bank money can settle against tokenized central-bank reserves. Its preference reflects a concern that privately issued instruments should retain dependable exchange at par and access to the liquidity arrangements supporting the monetary system. Stablecoins and tokenized deposits may perform similar tasks while retaining different funding and settlement structures.
For a customer, the practical inquiry starts with the issuer’s terms. Who is the debtor? Who may redeem directly? What happens if an intermediary fails? A familiar shareholder name does not answer those questions.
Following a payment from bank account to supplier
Consider an illustrative $1 million payment from an American importer to an overseas supplier. Assume the invoice permits dollar settlement and both sides have access to approved service providers. Fees are excluded from the example.
The importer first submits a payment instruction through its bank or treasury platform. The provider verifies the customer, checks the beneficiary and destination, and applies transaction limits. The interface may resemble an ordinary bank payment even if part of the route uses tokens.
The provider then obtains the stablecoins. It could use inventory already on hand, buy tokens from another holder, or arrange new issuance against funds received by the issuer. This distinction matters: purchasing existing tokens changes their ownership; it does not necessarily increase the issuer’s reserves or the total supply.
For new issuance, the operator must establish that the corresponding funds have arrived under its funding rules before releasing tokens. Minting is the creation of additional token units. Burning removes units from circulation. The procedures connecting these operations to bank receipts and payouts determine whether the digital supply remains properly backed.
Circle’s developer guide illustrates the separation. Its sample workflow links a bank account, obtains wire instructions, funds a Circle Mint account, sends USDC to an external address and initiates a bank payout for redemption. The guide uses simulated deposits in its sandbox; production funding requires an actual bank transfer. It also distinguishes a pending blockchain transfer from one completed after sufficient confirmations.
Once the importer’s provider sends the tokens, the supplier’s provider must recognize receipt under its own confirmation and compliance policies. The supplier may keep the stablecoin. If it wants a deposit instead, the provider must arrange redemption or buy the token and pay from its own cash inventory. A request for local currency also introduces a foreign-exchange trade.
That last step is easy to lose in a diagram. The blockchain can deliver a dollar token while the supplier is still waiting for usable euros, pesos or yen. Someone must supply that currency, quote an exchange rate and connect to the destination payment system.
Citi Ventures’ description of BVNK offers a concrete example of the surrounding infrastructure. BVNK provides APIs for embedded wallets and payments, connecting digital currencies with conventional banking routes. Its services include deposits, withdrawals, transfers and virtual accounts, with compliance integrated into the offering. Citi’s investment illustrates a bank’s interest in that infrastructure; it does not establish a BVNK appointment by the consortium.
The software that authorizes and records the money
At the center of a token system is code that records balances and governs permitted changes. On Ethereum-compatible networks, an ERC-20 token provides a widely used interface for transfers and balances. Institutional requirements usually extend beyond that interface.
Circle’s published EVM stablecoin contracts provide an instructive example. They include roles for minting, assigning minting allowances, pausing transfers and blocking specified addresses. A proxy structure allows the implementation to be upgraded. These are explicit administrative powers, divided among designated roles.
Each power solves a problem and creates a dependency. Limits on minting can restrict the damage from a compromised operator. A pause can contain an incident but interrupt customers. Upgrades allow repairs while making the upgrade authority part of the system’s trust model.
The relevant investigation therefore extends beyond whether the code has been audited. It asks who controls privileged accounts, how changes are approved, whether emergency authority is concentrated, and how customers learn that a contract has changed. A technically correct transfer can still occur under a governance arrangement customers would find unacceptable.
Around the contract sits the integration software. An application programming interface, or API, lets a bank’s systems request operations and retrieve status. Event notifications can tell downstream systems that a transfer progressed or failed. These interfaces need to connect a blockchain transaction with the customer instruction and accounting entry that caused it.
One particularly consequential implementation detail is duplicate prevention. If a network request times out, an application may retry it. A unique operation identifier can help ensure that a retry does not create a second payment. Circle’s example API requests use idempotency keys for several operations, illustrating this safeguard.
The broader operational requirement is reconciliation: matching customer balances, tokens, reserve movements and pending obligations. A shared ledger can reduce disagreements over a token’s history. It does not automatically reconcile the issuer’s banking records with every distributor’s customer ledger.
Custody determines who can actually spend
A blockchain wallet is an authorization mechanism. The security question is who can produce the cryptographic signature needed to move assets, and under what conditions.
Institutional wallet infrastructure can distribute signing responsibility. Fireblocks documents direct-custody wallets using a three-of-three multiparty-computation scheme. MPC allows participants holding separate secret shares to cooperate in signing, reducing dependence on one exposed signing secret. Its documentation also distinguishes that configuration from embedded-wallet arrangements.
Cryptography alone does not decide whether a payment should happen. A bank also needs rules governing authorized employees or services, approved destinations and exceptions. Fireblocks’ policy tools illustrate this separate control layer: they define permitted or blocked actions according to initiator, source, destination and conditions, with management through a console or API.
For the proposed consortium, an important design choice is how much control customers retain and how much they delegate. A corporate client may prefer bank-managed custody because it fits existing accountability and recovery arrangements. Another institution may require control over its own signing infrastructure.
Either model needs a recovery plan. The critical test is whether the organization can recover access after a failure without creating a shortcut that an attacker—or a dishonest insider—can exploit. A token network can remain online while a customer loses the ability to authorize a transaction.
Compliance remains an operating function
An address on a blockchain does not, by itself, establish the legal identity of its controller. Customer onboarding and verification therefore remain separate from the network’s ability to validate a signature.
Blockchain analytics adds another layer. Chainalysis describes its KYT product as a transaction-monitoring system with alerts for risky behavior and exposure to designated categories, including sanctioned entities. It supports configurable thresholds, investigation workflows and an API for connecting those signals to a firm’s systems.
Such information can inform a compliance decision; an alert is not a judicial finding. A payment service must determine what to do with an uncertain match, how to investigate it and who can release a held transaction. False positives impose costs on legitimate customers, while weak controls expose the service to unlawful activity.
Regulators are also translating stablecoin legislation into operational requirements. A June 22, 2026 joint proposal from FinCEN and federal banking agencies addresses customer-identification requirements for permitted payment stablecoin issuers. A proposed rule should be read as a proposal, rather than evidence that every implementation detail has been settled.
Privacy presents an additional implementation problem. An enterprise may want verifiable settlement without publicly exposing its suppliers, payment frequency or treasury balances. The consortium’s eventual design will need to explain what appears on a public ledger, what remains in controlled databases and which parties can connect the two.
Reserves require evidence outside the blockchain
An onchain balance proves what a particular ledger records. It does not independently establish the existence, availability or legal status of assets held by a bank or securities custodian.
Circle’s transparency disclosures show how one issuer approaches that gap. It reports reserve holdings and mint-and-burn flows weekly and provides monthly third-party assurance over reserve coverage. The company separately identifies the audit of its financial statements. Reserve assurance and a company-wide financial audit answer related but different questions.
For the bank consortium, the reserve policy will be one of the most revealing documents. A balance backed by immediately accessible cash has a different liquidity profile from one supported primarily by securities that must be sold or financed before paying redemptions. Both may qualify as backing, subject to the applicable rules, while creating different operational demands.
Oracle technology can connect external reserve information to blockchain software. An oracle is a mechanism for delivering information the contract cannot observe directly. Chainlink’s documentation, for example, describes reserve feeds drawing from third parties, custodians or issuer-hosted APIs. It explicitly identifies additional risks associated with self-reported data.
A suitably designed contract could use such information as one condition for permitting new issuance. That would still leave questions about update frequency, valuation, missing liabilities and what to do when the feed becomes unavailable. Publishing a number onchain does not make the underlying assets unencumbered or settle competing legal claims to them.
A price oracle performs a different task: reporting a market price. It can help a lending application value a stablecoin used as collateral. It does not itself maintain the peg. The economic support for a reserve-backed token depends on credible redemption and participants able to arbitrage price differences, subject to costs and access restrictions.
Around the clock transfers need around the clock liquidity
The distinction between transfer and redemption becomes most visible outside banking hours. Tokens already in circulation may continue to move while some of the services needed to turn them into account balances operate on a different timetable.
A provider can narrow that gap by holding cash and stablecoin inventory in advance. It may credit a customer before completing the corresponding treasury operation. This can make the customer experience faster, but it puts liquidity and counterparty exposure onto the provider’s balance sheet.
Deutsche Bank’s February 2026 discussion of digital assets identifies treasury management, just-in-time funding and cross-border payments as potential uses for stablecoins. It also highlights interoperability, regulatory clarity and integration with enterprise systems as barriers to wider use. Those constraints are especially relevant when a payment crosses currencies and jurisdictions.
An illustrative stress test exposes the issue. Suppose a provider holds $20 million of immediately available payout cash and receives $50 million of weekend redemption requests. The existence of additional reserve assets elsewhere does not explain how it meets the $30 million timing gap. It needs accessible liquidity, financing or a redemption process that makes the waiting period clear.
Continuous operation is not exclusive to blockchain. The Federal Reserve’s FedNow Service supports instant domestic payments around the clock. Its scope differs from a globally transferable token, but its existence means the stablecoin’s advantage must be demonstrated against contemporary payment options.
For customers, the useful metric is the time from a valid instruction to usable funds at the destination, including compliance checks and currency conversion. The network fee is similarly only one component of total cost. Custody, conversion spreads, payout charges and prefunding can determine whether the new route is cheaper.
What programmable settlement can change
The strongest use case may arise when the asset being bought and the money used to purchase it can interact within the same transaction environment.
Consider an illustrative purchase of a tokenized bond. In an atomic delivery-versus-payment transaction, the bond transfer and payment are conditional on each other: either both execute or neither does. This can reduce the risk that one party delivers while the other fails to pay.
The benefit depends on implementation. Both assets must be available, the parties must have permission to transact, and the software must enforce the exchange correctly. If a token represents an offchain security, the legal arrangements must also determine whether the onchain transfer changes recognized ownership.
Project Agorá, developed through the BIS Innovation Hub with public- and private-sector participants, provides evidence that the coordination can be tested. Its prototype combines tokenized deposits and central-bank reserves on a programmable platform for wholesale cross-border payments. The project describes atomic multicurrency settlement and workflow logic embedded in transactions.
Instant settlement also changes funding requirements. A participant that previously settled a net obligation later may need to obtain the full amount for an immediate transaction. Shortening the time a counterparty remains exposed can therefore increase the need for cash at the moment of execution. The BIS discusses the importance of liquidity and netting in evaluating tokenized financial infrastructure.
The practical opportunity is to redesign a specific workflow and measure its result. For a securities transaction, that means examining settlement failures and funding costs alongside speed. For automated treasury, it means deciding which actions software can initiate and which still require human approval.
One brand can still fragment across blockchains
A stablecoin issued on several networks does not automatically become a single pool of readily accessible liquidity. Holders on one chain may need a transfer mechanism to reach customers or applications on another.
Circle’s Cross-Chain Transfer Protocol demonstrates one approach. CCTP burns native USDC on a source chain, uses Circle’s offchain attestation service to sign a message, and enables minting on the destination after the message is verified. Its documentation distinguishes confirmation thresholds and explains replay prevention.
This avoids requiring the user to hold a third-party wrapped representation of USDC for that route, but it retains dependencies on contracts, chain operation and the attestation service. Burning on the source chain does not make the entire cross-chain journey one instantaneous transaction. The transfer still passes through intermediate states that must be monitored and recovered if interrupted.
The consortium will face a tradeoff between broad reach and operational complexity. Additional networks can reach more users while multiplying integrations, monitoring requirements and liquidity locations. A customer will need clarity on supported routes, transfer costs and which institution is responsible when a transfer stalls.
Moving from a pilot into production
A credible rollout would need to prove several things in sequence. This is an implementation assessment, not a disclosed consortium timetable.
The initial work is legal and operational: establish the issuer, identify permitted customers, document redemption rights and assign responsibility for reserves, custody and incidents.
That work defines what the software is allowed to do.
An integration environment would then let participating institutions test issuance, transfers and redemption without exposing customer funds. Circle’s sandbox demonstrates the usefulness of separating simulated funding from production banking instructions. Passing such tests establishes that a workflow can execute; it does not demonstrate that the service can manage real liquidity at scale.
Controlled transactions with real value would test the connections between the token system and the institutions surrounding it. Agorá’s July exercise, for example, covered operational, technical, governance and legal aspects as well as payment execution. Such testing is more informative when it includes exceptions and recovery, rather than only successful transfers.
Before broad distribution, a practical test program would examine a failed bank payout, a delayed chain confirmation, duplicate instructions, unavailable signers and a surge in redemptions. For each event, the operator needs to know the status of customer funds, the party responsible for recovery and what the customer sees.
That is the difference between demonstrating a token transfer and demonstrating a payment service. The latter requires the surrounding institutions to remain coordinated when a component fails.
The business beneath the token
The financial incentive is visible in an incumbent issuer’s accounts. Circle reported $668 million of reserve income for the second quarter of 2026 and $412 million of distribution, transaction and other costs. USDC circulation stood at $73.3 billion at quarter-end. The results show both the earning potential of reserve balances and the expense of distributing a widely used token.
For illustration, a stablecoin maintaining an average $10 billion reserve balance at a 3 percent annual gross yield would generate $300 million before costs, taxes and revenue sharing. That is arithmetic, not a forecast for the consortium. Lower rates would reduce the income generated by the same balance.
The implication is that member institutions could have several commercial objectives: earn a share of the issuing business, retain payment customers, distribute related custody services and support trading or treasury products. The division of those benefits may influence how enthusiastically each member promotes the token.
There is also a potential conflict with deposit gathering. If a customer converts a deposit into a stablecoin, its bank may lose that particular funding relationship. The system-wide outcome depends on where reserves go. Money held in reserve deposits can reappear at other banks; purchases of government securities alter the distribution of funding through a different route. A dollar entering a stablecoin does not mechanically imply a dollar disappearing from all bank deposits.
This makes the reserve and distribution agreements commercially consequential. Which banks receive reserve deposits? Which firms earn custody or asset-management fees? Are distributors rewarded for balances, payments or customer acquisition? The answers can reveal whether the structure encourages long-term customer use or expensive competition for idle balances.
Circle’s numbers also caution against treating gross reserve income as profit. Its reported distribution and transaction costs are substantial, and an entrant cannot assume that established acceptance and liquidity will transfer simply because its shareholders already have large banking franchises.
Regulation shapes the product itself
The GENIUS Act sets out a framework requiring at least one-to-one backing in specified reserve assets, a disclosed redemption policy and monthly reserve disclosures. It prohibits issuers from paying holders interest solely in connection with holding, using or retaining the payment stablecoin. It also prohibits representing payment stablecoins as federally insured or government-guaranteed. Bank ownership does not transform the token into an insured deposit.
The statute’s general effective-date mechanism is the earlier of 18 months after its July 18, 2025 enactment or 120 days after specified final implementing regulations. That mechanism is another reason to distinguish enacted legislation from a completed product authorization.
In the European Union, MiCA’s e-money-token framework addresses issuer authorization, disclosures and holder rights. Article 49 establishes a claim against the issuer and redemption at par on request; Article 50 prohibits interest from issuers and crypto-asset service providers in connection with those tokens. The rules also govern how customer funds are safeguarded and invested.
For a cross-border enterprise, compliance cannot be reduced to attaching two regulatory acronyms to a token. The operating structure must connect the appropriate issuing entity, reserve arrangements and customer rights in each market. A dollar denomination does not make every holder subject to the same legal regime or give every participant identical access.
The alternatives are already taking shape
Other institutional projects demonstrate that the future need not converge on a single form of tokenized money.
Société Générale-FORGE’s June 2025 announcement of USD CoinVertible named Ethereum and Solana as its intended networks and BNY as reserve custodian. It described the issuer’s electronic-money authorization and excluded U.S. persons from the offering. Those specifics show what implementation disclosure can look like: a chain choice, an identified reserve role and an explicit customer boundary. They do not establish that the 21-member consortium will follow the same design.
Swift is pursuing a different route. In July 2026, it said its blockchain-based ledger was ready for initial use, with 17 banks preparing to pilot live transactions. Its description is precise: an orchestration layer coordinates bank-issued tokenized deposits on banks’ own ledgers, allowing customer funds to move before final settlement through existing systems. That is a different architecture from paying with a common stablecoin issuer’s liability.
Agorá offers another comparison. The BIS reports that controlled real-value testing in July 2026 involved 28 financial institutions and central banks, with transactions totaling approximately CHF 800,000 across 17 scenarios. The exercise supports technical feasibility; the project describes a prototype, not a finished production service. Its inclusion of central-bank reserves gives it a different settlement foundation from a privately issued stablecoin.
Taken together, these projects suggest that institutions are testing multiple ways to connect programmable assets with money. The competition concerns customer reach, legal certainty and funding efficiency as much as blockchain performance. Several architectures could remain useful for different markets.
The evidence that will determine whether this works
The next substantive disclosures should make it possible to trace responsibility through the proposed service. An issuer’s identity and authorizations establish who owes the obligation. Reserve and redemption terms explain how that obligation is funded. Published technical details identify the network and the powers exercised over the token.
Commercial commitments will be just as revealing. Shareholder participation does not, by itself, establish that every member will integrate the product, make markets or route substantial customer payments through it. Named services, eligible customers and demonstrated production use would provide stronger evidence than another list of supporters.
A useful performance record would report actual customer-payment volumes separately from issuance, redemption and internal transfers. It would distinguish blockchain confirmation from final recipient availability, disclose conversion and payout costs, and show how the service behaves during a liquidity surge or operational interruption.
Governance deserves equal scrutiny. Members may disagree about admitting competitors, choosing custodians, changing fees or responding to sanctions orders. Customers need a service that can make necessary decisions promptly while preserving a clear record of authority and accountability. The shareholder agreement and operating rules will matter alongside the smart-contract audit.
The consortium’s opportunity is substantial if it can give businesses a dependable way to exchange a common digital dollar across institutions and applications. Its members can contribute established customer relationships and financial operations. Those advantages become valuable only when they are translated into a service that works at both ends of a transaction.
The test will arrive when a customer sends a payment outside normal banking hours and the recipient asks to use the proceeds. At that point, the reserve manager, wallet operator, compliance team and payout provider must perform as one service. The significance of the project will rest on how reliably they do so—and on whether the customer receives a better result at a competitive total cost.
Reporting note
This article is based on the original published piece and public institutional announcements, legislation, financial disclosures and technical documentation reviewed on September 2, 2026. It does not include original interviews or access to the consortium’s nonpublic plans. Illustrative payments and financial calculations are identified as examples. Named vendor technologies explain existing approaches and should not be read as confirmed consortium selections. Product and pilot claims are attributed to their issuing organizations.
Comments