Bank Stablecoin Architecture: 21-Bank USD Consortium vs Qivalis vs Stellar Pilot

For a decade, banks answered stablecoins with committees. In September 2026 they answered with three different pieces of infrastructure inside eight days: a 21-firm dollar consortium on September 1 to 2, a live U.S. Bank cross-border pilot on Stellar on September 9, and a public-Ethereum confirmation for the 37-bank Qivalis euro effort on September 8. They are often lumped together as “banks are launching stablecoins.” That framing hides the only thing an architect cares about: each one answers the questions of who issues, who holds reserves, which ledger settles, and who can freeze a balance in a different way.

This post treats bank stablecoin architecture as a design space with six axes and places the three efforts on it, using only what has been published. Where a chain, reserve model or governance rule is unpublished, I say so instead of guessing. It is systems analysis, not investment or legal advice.

What this covers: the design space and reference architecture, a side-by-side comparison of the three efforts, a deeper look at freeze and clawback mechanics and settlement finality, a decision matrix, failure modes, and a practical checklist for teams evaluating bank-issued tokens.

Non-advisory disclaimer: this article analyses system design and published announcements. It is not financial, investment, legal or compliance advice, and nothing here recommends buying, selling or issuing any asset.

Context and Background

Stablecoins grew up outside the banking perimeter. Fiat-backed tokens from non-bank issuers scaled on public chains, and Circle’s Arc L1 (covered in our separate write-up of its mainnet launch) is the latest example of a stablecoin issuer building its own settlement layer. Banks watched deposits, correspondent fees and payment relationships become contestable by an asset they did not issue. Our stablecoin payment infrastructure primer covers the incumbent architecture; this post covers the banks’ counter-move.

Two regulatory events shaped the timing. In the United States, the GENIUS Act was signed on July 18, 2025. According to a Greenberg Traurig summary, it takes effect on the earlier of January 18, 2027 or 120 days after federal regulators issue final rules. It requires one-to-one backing, bars issuers from paying yield to holders, and requires issuers to maintain the technological capability to comply with lawful orders to block, seize, freeze, burn or prevent transfer of outstanding stablecoins. Bank subsidiaries are among the eligible issuer types. That last requirement matters enormously for architecture, because it turns freeze and clawback from a product feature into a legal precondition.

In the European Union, MiCA (Regulation 2023/1114) already governs “e-money tokens”: euro-referenced tokens must be issued by a credit institution or an electronic money institution, be redeemable at par on request, and carry no interest. The companion Transfer of Funds Regulation (Regulation 2023/1113) has applied to crypto-asset transfers since December 30, 2024 and carries no de minimis threshold, so originator and beneficiary data must travel with transfers. Read the primary text on EUR-Lex rather than trusting summaries, including this one.

The three efforts also differ in maturity, which is the first thing to separate. The 21-firm consortium has announced a plan and a target date. Qivalis has a named legal entity, a chief executive, a technology vendor and an application pending with the Dutch central bank. U.S. Bank has an internally built platform and one completed live transaction. Comparing a plan, a licensing effort and a pilot is only fair if we compare designs, not readiness.

Finally, message formats matter. A token transfer is only one leg of a payment: the instruction, the reconciliation and the regulatory reporting still ride on structured data. Our guide to ISO 20022 migration and payments architecture explains why the data model is often the harder integration than the ledger.

What Each Effort Has Actually Published

Before comparing, here is the evidence base, graded by how firm it is.

The 21-firm USD consortium

The announcement, reported by multiple outlets as originating from a PR Newswire release, describes 21 firms planning a new company (name not yet chosen) to issue a one-to-one reserve-backed stablecoin or token on public blockchains for wholesale, institutional and retail use, including cross-border payments and digital-asset settlement. Company formation is targeted for the second half of 2026 and the USD launch for the first half of 2027, with other G7 currencies, euro first, to follow. The design is stated to align with the GENIUS Act and MiCA.

Reporting names Bank of America, Capital One, Citi, Fidelity Investments, Goldman Sachs, PNC, Scotiabank, TD Bank Group, Wells Fargo and WisdomTree in North America; Santander, BBVA, Commerzbank, Crédit Agricole, Deutsche Bank, Lloyds, Rabobank and UBS in Europe; MUFG Bank; Sirius International Holding; and Standard Bank. Blockhead reports Boston Consulting Group and Brunswick Group as advisers and says the group grew from ten banks first reported in October 2025. Banking Dive’s list of participants and backers differs at the edges and also describes a separate “Open USD” effort with crypto-native and payments-network partners, so treat exact membership as fluid.

What is not published, per those reports: the company name, reserve composition, technical architecture, chain, distribution partners, and governance details such as who leads. I have found no primary document that names a chain. Any diagram of this consortium’s ledger layer is therefore a design hypothesis, and I label it as such below.

Qivalis

Qivalis B.V. is a Dutch company owned by a European bank consortium. Its own site describes a “fully regulated, 1:1-backed euro stablecoin,” states that it has applied to De Nederlandsche Bank for authorisation as an electronic money institution, and states plainly that it “is not yet authorised and does not currently issue electronic money.” Jan-Oliver Sell is chief executive. A PR Newswire release dated April 21, 2026 names Fireblocks as the technology platform, covering tokenisation, treasury, wallet infrastructure and compliance tooling, and lists twelve founding banks at that time (Banca Sella, BBVA, BNP Paribas, CaixaBank, Danske Bank, DekaBank, DZ BANK, ING, KBC, Raiffeisen Bank International, SEB, UniCredit).

Secondary reporting says membership reached 37 banks across 15 countries by May 2026, that the token will use the ERC-20F standard on public Ethereum, and that a September 8, 2026 statement confirmed Ethereum. I could verify the Fireblocks and license status from primary sources; the Ethereum and ERC-20F details rest on trade coverage, and one outlet itself notes that multi-chain deployment, distribution channels and the final operating model are unpublished. The target launch is the second half of 2026, contingent on approval, and no regulatory timeline has been published. Reports also disagree on the minimum share of reserves held as bank deposits (30% in some, 40% in another), so I treat that number as unverified.

The U.S. Bank pilot

This is the best-documented of the three because it is a first-party announcement. In a September 9, 2026 Business Wire release, U.S. Bank said it completed a live cross-border payment pilot using a U.S. dollar-backed stablecoin, USBDC, on the Stellar network, between U.S. Bank entities in North America and Europe. The pilot tested minting, payment, redemption, freezing and clawback, and ran on the bank’s internally developed Digital Asset Platform with the Stellar Development Foundation as a participant. CEO Gunjan Kedia was quoted on accelerating global cash management.

The release does not state the transaction amount, the custody arrangement for reserves, regulatory approvals obtained, fees, or a rollout timeline, and it does not name external clients. It is a proof of mechanics between affiliates, not a launched product.

Reference Architecture: The Six Axes of Bank Stablecoin Design

Every bank-issued token, whatever its branding, decomposes into the same blocks. The differences are in how each block is owned and which ones are shared.

Direct answer: Bank stablecoin architecture is a set of six design choices: issuance model, reserve custody, ledger choice, compliance controls, settlement finality, and interoperability. Consortium tokens share issuer, reserves and governance across many banks. Single-bank tokens keep them in-house. Public-chain tokens trade control for reach.

Figure 1: Reference model of a bank stablecoin architecture. The compliance layer sits on both the mint path and the token contract, which is what makes freeze and clawback possible.

Figure 1 shows the shared skeleton. An issuer entity holds one-to-one reserves and controls a mint and burn function. A token contract on some ledger represents balances. Holders redeem through the issuer, which burns tokens and pays out fiat. A compliance layer gates who can receive tokens and can act on the contract when a lawful order arrives. A supervisor oversees the issuer. Every design decision below is a choice about who operates each box.

Axis 1: Issuance model

There are three patterns in this comparison. In a single-bank model (U.S. Bank’s USBDC), one regulated institution is issuer, reserve holder and compliance owner. Liability sits on one balance sheet and accountability is unambiguous, but reach is limited to that bank’s clients unless others accept the token.

In a shared-entity model (Qivalis, and the 21-firm plan), member banks capitalise a new legal entity that issues the token. Qivalis chose a Dutch electronic money institution rather than a bank, which fits MiCA’s issuer options and lets the consortium own one regulated perimeter instead of 37. The 21-firm group announced a new company without disclosing its licence type. Under the GENIUS Act, eligible issuers include bank subsidiaries, federally qualified nonbank issuers and state-qualified issuers, so the choice among them is material and, as of the reporting I could find, unannounced.

The trade-off is governance. A single issuer answers to one board. A consortium entity must agree on onboarding rules, fee splits, sanctions posture and incident response among competitors. Shared entities also inherit a network-effect problem: banks are asked to distribute a token whose economics they partly cede to a peer.

Axis 2: Reserve custody and economics

All three describe one-to-one backing. What differs is who holds the assets and what earns the yield. Reserves are typically a mix of central bank balances, deposits at credit institutions and short-dated government securities, but composition is unpublished for the 21-firm plan and for USBDC. MiCA prescribes a minimum share of e-money-token funds held as deposits at credit institutions and requires the rest in low-risk, highly liquid assets, so Qivalis’s reserve profile is at least partly determined by statute. Check Article 54 of the regulation for the exact percentages.

The economics are the quiet driver. Purely as an illustration: if a token had $1 billion outstanding and reserves earned 4% a year, gross reserve income would be about $40 million annually before costs. Both GENIUS and MiCA prohibit paying interest to holders, so that income accrues to the issuer, and in a consortium to whoever owns the issuing company. How it is split is exactly the kind of governance detail nobody has published. It also explains why a bank might build a token that cannibalises some of its own deposit funding: Bank of America’s chief executive was quoted by Banking Dive estimating that a large fraction of deposits could migrate, which is a reason to own the token rather than watch a competitor’s.

Axis 3: Ledger choice

The three efforts land in different places. U.S. Bank chose Stellar, a public, permissionless network whose protocol has native issuer controls. Qivalis is reported to use public Ethereum with a permissioned token standard layered on top. The 21-firm plan says only “public blockchains,” plural, without naming any. All three are public-chain designs, which is itself notable: none is proposing a private bank-only ledger. The token is permissioned even though the network is not, which we examine next.

The Compliance Layer: Where Public Chains Become Bank-Grade

A bank cannot issue a token that any anonymous address can hold and move without screening. Public chains solve this at the token layer, not the network layer.

Stellar: issuer flags built into the protocol

Stellar assets are issued by an account, and holders opt in with a trustline. The issuer can set flags on the account. According to Stellar’s developer documentation, AUTH_REQUIRED means the issuer must approve an account before it can hold the asset. AUTH_REVOCABLE lets the issuer revoke that authorisation, which freezes the asset: transfers and trading stop and open orders are cancelled. AUTH_CLAWBACK_ENABLED lets the issuer take back and burn the asset, applies only to trustlines created after the flag is set, and requires AUTH_REVOCABLE to be set too. AUTH_IMMUTABLE locks the flags permanently, which a bank issuer would never choose.

This means US Bank’s freeze and clawback tests exercise native protocol features rather than custom contract code. That is a real advantage: the control logic is part of the ledger’s own audited rules and behaves identically across wallets and exchanges. The cost is coarseness. Flags are account-wide policy for one asset, and the logic for who may hold the token still lives in the issuer’s off-chain onboarding system. The chain enforces the switch, not the decision.

Ethereum: token-contract controls

Ethereum’s base layer has no issuer flags. Controls live in the token contract. The ERC-20F label attached to Qivalis in press coverage describes an ERC-20 variant with access controls, upgradeability and allowlist or denylist checks in the contract. I could not find a public specification for it from the consortium, so treat the name as reported, not verified. The general pattern is well established: transfer functions consult a compliance registry, privileged roles can pause, block or burn, and an upgradeable proxy lets the issuer patch behaviour.

Contract-level controls are more flexible than Stellar flags, since arbitrary rules can be coded, but they move risk into software: a mis-scoped admin role, a compromised key, or a buggy upgrade can freeze the wrong balances or open a hole. Key management for those privileged roles is exactly the service Fireblocks is positioned to provide for Qivalis.

Comparing the control planes

Figure 2: The three efforts side by side. Solid links show published relationships; the shared settlement layer is public chains in all three, though only Stellar and (reportedly) Ethereum are named. The 21-firm ledger choice is unpublished.

Figure 2 places the three efforts on a common canvas. Notice what is drawn as concrete and what is not: U.S. Bank has a named platform and a named chain; Qivalis has a named vendor and a reported chain plus a pending licence; the consortium has only a company and a date. The diagram is deliberately lopsided because the evidence is.

Deeper Analysis: The Lifecycle, Finality and Interoperability

Mint, pay, redeem, freeze: one lifecycle, four control points

U.S. Bank’s pilot list (mint, pay, redeem, freeze, clawback) is a good template for any bank-issued token, because each verb maps to a control point with its own failure modes.

Figure 3: Lifecycle of a bank-issued stablecoin. Compliance acts at mint, at transfer eligibility, and on lawful orders; redemption burns tokens and releases fiat at par.

Mint. The client funds fiat, the bank runs KYC and sanctions checks, and only then does the mint controller create tokens to a screened wallet. The critical invariant is that tokens outstanding never exceed reserves, so the mint path needs reconciliation against the bank’s core ledger in near real time. That is a classic ledger-matching problem, and the design patterns in our reconciliation engine architecture guide apply directly: the on-chain supply is one side, the reserve account balance is the other, and breaks must be investigated the same day.

Pay. A transfer between two allowlisted wallets is a ledger event. What surprises many architects is that the payment leg is the easiest part. The hard parts are eligibility (is the receiving wallet allowed to hold the token?) and information (which identity data accompanies the transfer?).

Redeem. MiCA requires euro e-money tokens to be redeemable at par on request. Qivalis materials describe 24/7 redemption, per trade coverage. Redemption at par is a liquidity promise: the issuer must be able to convert reserves to cash on demand. If reserves sit in term deposits or securities, the redemption path needs a liquidity buffer, which is why reserve composition rules exist.

Freeze and clawback. These are different powers. A freeze prevents movement while preserving the balance, and is reversible. A clawback removes the balance from a holder and burns or reassigns it, which is irreversible and legally heavier. On Stellar, freezing is revocation of trustline authorisation; clawback is a separate operation that requires the clawback flag set at trustline creation. The GENIUS Act’s language covers both, listing block, seize, freeze, burn and prevent transfer.

Illustrative cost math: correspondent leg versus token leg

The business case for bank tokens in cross-border treasury rests on removing intermediary hops and cutoff delays. The following is an illustrative model, not a published benchmark from any of the three efforts. Assume a multinational moves $10 million a week between a U.S. entity and a European subsidiary.

Over a correspondent path, suppose a 0.10% all-in cost (FX spread, correspondent and beneficiary-bank fees, a working assumption) and a one-to-two-day value delay. That is $10,000 per transfer, or about $520,000 per year at 52 transfers, plus one to two days of float on $10 million. At an assumed 4% cost of funds, a two-day float costs roughly $10 million times 4% times 2/365, about $2,200 per transfer.

Over a bank-token path between two accounts at the same bank, network fees are fractions of a cent on public chains and the float can shrink to minutes, so the residual costs are the bank’s own pricing, on-ramp and off-ramp conversion, and compliance operations. If the bank prices at 0.02%, the fee falls to $2,000 per transfer. The point of the exercise is the sensitivity, not the answer: the saving depends on the bank’s pricing and on whether the client can hold and use the token rather than convert immediately. A pilot between two entities of the same bank, as U.S. Bank ran, removes precisely the external-counterparty hops that dominate real cost, so it cannot by itself validate these savings.

Settlement finality is a ledger property, and it differs

“Instant settlement” hides three different meanings. Technical finality is when the ledger will not reorganise the transaction. Legal finality is when the law treats the transfer as irrevocable, which depends on the applicable settlement-finality rules and contract terms. Operational finality is when the bank has posted the movement to its own books and will release funds.

Technically, Stellar closes ledgers in roughly five seconds and its consensus protocol gives deterministic finality once a ledger closes, according to its documentation. Ethereum proposes blocks every 12 seconds, and its proof-of-stake economic finality typically takes about two epochs, roughly 13 minutes, though many applications act on earlier confirmations at higher risk. For a $10 million treasury transfer between banks, waiting for economic finality is cheap insurance; for retail payments it is not. Neither chain’s technical finality answers the legal question, and none of the three efforts has published its finality rules. That gap belongs on every diligence list.

Also note the paradox of freeze and clawback: a token that can be reversed by the issuer is not final in the sense a central bank reserve transfer is final. Issuers manage this by restricting clawback to lawful orders and publishing policy, but counterparties must price the residual risk.

Interoperability: between tokens, chains and messaging

Interoperability has three layers. At the token layer, will one bank’s token trade one-for-one with another’s? A 21-firm consortium token is designed to solve exactly this by pooling issuers into one liability. Qivalis does the same for euro. A single-bank token like USBDC needs bilateral acceptance or conversion to reach peers. At the chain layer, a token on Stellar and a token on Ethereum cannot interact without a bridge or an exchange path, and bridges concentrate risk. At the messaging layer, payment instructions and statements still flow as ISO 20022 messages, and the token movement must be mapped to them for reconciliation and reporting.

Figure 4: Where the token rail sits in the payment flow. The instruction is still structured data; screening and travel-rule information attach at the wallet step; both rails converge on reconciliation against the core ledger.

Figure 4 makes the practical point: a bank token does not replace the payment stack, it replaces one rail inside it. Structured remittance data, screening and reconciliation remain. Teams that treat the token as a drop-in for the whole stack discover that the surrounding systems, not the chain, set the project timeline.

Travel rule and wallet screening

The FATF travel rule (Recommendation 16) requires originator and beneficiary information to accompany transfers between regulated institutions. In the EU, Regulation 2023/1113 implements it for crypto-asset transfers, including transfers involving self-hosted wallets above EUR 1,000 that need extra verification. For a token designed for wholesale and retail use on public chains, the compliance engineering questions are concrete. How does the issuer bind an on-chain address to a verified customer? What happens when a holder transfers to an unhosted wallet? Does the token contract refuse transfers to non-allowlisted addresses (a closed model) or allow them and monitor after the fact (an open model)?

An allowlist model, which the Qivalis reporting describes, supports stricter control and simpler travel-rule compliance but limits composability with the wider DeFi ecosystem. An open model maximises reach and pushes monitoring and denylist enforcement to the issuer. The 21-firm plan’s stated intention to serve wholesale, institutional and retail use on public chains suggests this design tension will be live, but no rule has been published.

Decision Matrix

The matrix below compares the three efforts on the six axes plus maturity. Cells state what is published; “unpublished” means I found no primary source and that the reporting I reviewed says the same.

Axis	21-firm USD consortium	Qivalis euro effort	U.S. Bank USBDC pilot
Status (Sept 2026)	Announced plan; company to form H2 2026; USD launch targeted H1 2027	Legal entity exists; EMI application pending at DNB; launch targeted H2 2026, contingent	Live pilot completed, announced Sept 9, 2026
Issuance model	New shared company, name and licence type unpublished	Shared Dutch B.V. seeking EMI licence; 37 banks reported	Single bank, internal Digital Asset Platform
Reserves and custody	1:1 stated; composition and custodian unpublished	1:1 stated; MiCA deposit and liquid-asset rules apply; some figures disputed in reports	Custody not stated
Chain	“Public blockchains”, none named	Public Ethereum reported; Fireblocks platform confirmed	Stellar, confirmed
Compliance controls	Bank-grade compliance stated; freeze design unpublished; GENIUS-aligned by claim	Allowlist and denylist in token reported; Fireblocks screening tools	Mint, redeem, freeze and clawback tested
Travel rule and reporting	Unpublished	MiCA and TFR apply; specifics unpublished	Unpublished
Settlement finality	Unpublished	Ethereum characteristics apply; legal finality unpublished	Stellar ledger finality; legal terms unpublished
Interoperability	One pooled token across banks intended; G7 currencies later	Pooled euro token across many banks	Bilateral unless others adopt
Main open risk	Governance among competitors; no architecture disclosed	Authorisation timing; chain and standard specifics rest on secondary reports	Scale beyond intra-bank flows

Three patterns emerge. First, the only entry with confirmed control-plane tests is the smallest. Second, both consortium efforts choose pooled liability for network effect, and both have to solve governance that a single bank does not. Third, every entry defers legal-finality and travel-rule details, which is where production timelines will actually be decided.

Trade-offs, Gotchas, and What Goes Wrong

Pooled issuers concentrate a single point of failure. One shared token means one reserve pool and one redemption promise. A run on redemptions, an operational error in the mint controller, or a sanctions incident at one member bank can hit all holders. Ring-fencing rules, member liability terms and a redemption waterfall are governance documents nobody has published for any of the efforts.

Freeze power is a security surface. Any key that can freeze or claw back is a target. On Stellar, the issuer account’s signing thresholds are the control; on Ethereum, it is the admin roles and upgrade keys. Multi-party approval, hardware-backed keys and separation of duties matter more than the choice of chain. A compromised clawback key is a theft mechanism.

Legal conflict across jurisdictions. The 21-firm plan targets both GENIUS and MiCA compliance. Those regimes differ on issuer types, reserve rules and sanctions expectations. A single token trying to satisfy both may end up as jurisdiction-specific instances, which breaks the fungibility argument for pooling.

The pilot-to-production gap. An intra-bank transfer avoids counterparty onboarding, cross-entity sanctions screening, dispute handling, tax reporting and customer support. U.S. Bank’s own list of what is not disclosed (amount, custody, approvals, fees, rollout) is the honest inventory of that gap.

Deposit cannibalisation. Banks that issue tokens redeemable for deposits may accelerate the outflow they fear. Design choices that make tokens attractive as payment instruments (fast, programmable, always on) also make them attractive as savings substitutes, which is why yield prohibitions exist. Banks will manage this through limits and pricing, not architecture alone.

Ledger dependency. A bank that issues on a public chain depends on validators, client software and, for Ethereum, layer-two or bridge infrastructure it does not control. Chain halts, forks and congestion are operational risks that a private ledger would not carry. This is the price of reach.

Vendor concentration. Qivalis leans on Fireblocks for engine, custody and screening. That is a rational build-versus-buy decision, and it concentrates operational risk in one vendor unless exit paths and key escrow are contractually defined.

Practical Recommendations

This section is about engineering diligence, not investment or policy advice. If you are evaluating, integrating with, or designing a bank-issued token, treat the following as a checklist derived from the analysis above.

Start by classifying the token you are looking at: single-bank or pooled, permissioned or open at the token layer, and which legal perimeter (bank, EMI, or nonbank issuer) it lives in. Most confusion in this space comes from mixing those categories.

Next, ask for the control plane in writing. Who holds the freeze and clawback keys? What is the approval quorum? What events trigger use, and how are affected holders notified? Do the controls exist in protocol flags or in contract code, and who audited that logic?

Then test finality and reversibility assumptions against your own risk model, including the legal finality of transfers and the possibility of issuer-initiated reversals.

Finally, plan the surrounding stack. Data mapping to ISO 20022, reconciliation between on-chain supply and reserve balances, and travel-rule data exchange usually consume more calendar time than the chain integration.

• Confirm issuer type, licence status and supervisor before any integration.
• Obtain the reserve composition policy and redemption terms, including cutoffs and liquidity buffers.
• Map the freeze, clawback and pause powers to named roles and keys.
• Define which finality (technical, legal, operational) your process waits for.
• Verify how originator and beneficiary data travels with each transfer.
• Build same-day reconciliation between token supply and reserve accounts.
• Document exit paths for vendor and chain dependencies.
• Re-read primary announcements before each planning cycle; these efforts change monthly.

Frequently Asked Questions

What is the 21-bank stablecoin consortium?

It is a group of 21 firms, reported in early September 2026, planning a new company to issue a one-to-one reserve-backed USD stablecoin on public blockchains for wholesale, institutional and retail use. Formation is targeted for the second half of 2026 and launch for the first half of 2027, with other G7 currencies to follow. The company name, chain, reserve composition and governance are not yet published.

How is Qivalis different from the US consortium?

Qivalis is a euro effort with a Dutch legal entity, Qivalis B.V., an electronic money institution application pending at De Nederlandsche Bank, Fireblocks as technology platform, and a reported 37 member banks across 15 countries. The US consortium has announced a plan but no legal entity, licence or technology details. Qivalis says it is not yet authorised and cannot issue electronic money until it is.

What did the U.S. Bank Stellar pilot prove?

It demonstrated, in a live cross-border transaction between U.S. Bank entities in North America and Europe, that USBDC could be minted, paid, redeemed, frozen and clawed back on Stellar using the bank’s internal Digital Asset Platform. It did not disclose amounts, custody, approvals or external clients, so it validates mechanics between affiliates, not commercial readiness or third-party settlement.

How do freeze and clawback work on Stellar?

Stellar issuers set account flags. Authorisation-required and authorisation-revocable let the issuer approve holders and freeze balances by revoking trustline authorisation. Clawback-enabled lets the issuer take back and burn the asset on trustlines created after the flag is set, and it requires the revocable flag. These are protocol-level features, so behaviour does not depend on custom contract code.

Why do banks put stablecoins on public blockchains?

Public chains offer reach, existing wallet and exchange infrastructure, and neutral settlement between institutions that do not share a private ledger. Banks then add permissioning at the token layer through allowlists, issuer flags and screening. The trade-off is dependence on validators and network conditions that a bank does not control, plus the need to enforce compliance without controlling who runs nodes.

Is a bank-issued stablecoin the same as a tokenized deposit?

Not necessarily. A tokenized deposit is a claim on the bank as a deposit, with deposit protections and treatment. A stablecoin under GENIUS or MiCA is a regulated payment instrument backed by reserves, with rules that generally bar interest. The efforts discussed here are described as stablecoins, but the legal characterisation of each token depends on its final structure, which has not been published in full.

Further Reading

• Stablecoin payment infrastructure in 2026: the non-bank baseline these bank efforts respond to.
• ISO 20022 migration and payments architecture: the messaging layer that sits above any token rail.
• RWA tokenization architecture: shared design patterns for regulated tokens with transfer restrictions.
• Reconciliation engine architecture for payments: matching on-chain supply against reserve balances.
• U.S. Bank’s USBDC announcement: the primary release for the pilot.
• Qivalis official site: licence status and consortium description.
• Stellar documentation on controlling asset access: authorisation and clawback flags.

By Riju — about