Banks’ Guide to Issuing Stablecoins

Issuing a stablecoin presents a complex operational challenge for banks, moving beyond high-level strategy to specific implementation details.

The first decision is which type of digital instrument the bank is issuing, because the regulatory treatment, balance sheet implications, and business model viability differ substantially across the options available under the EU’s Markets in Crypto-Assets (MiCA) framework.

An e-money token, or EMT, represents electronic money denominated in a single official currency and must be redeemable at par value. For a bank already authorised as a credit institution, MiCA provides a route to issue EMTs without a separate MiCA issuer authorisation, subject to the applicable requirements. An asset-referenced token brings a separate MiCA authorisation or approval process, depending on the issuer, and introduces a substantially different regulatory and reserve framework. A tokenised deposit sits outside MiCA, remaining a conventional deposit liability. Its transferability and wallet architecture depend on the underlying banking and ledger model.

These are meaningfully different instruments, and conflating them in the planning stage produces architecture decisions that require expensive revision later. The choice of instrument is therefore also a choice of balance-sheet architecture. A token is not simply a digital representation of money. It is a legal claim, with an issuer, a liability structure, redemption mechanism, and regulatory perimeter. Those decisions should precede the choice of ledger or blockchain.

For a large European bank seeking a transferable, euro-denominated digital instrument, an EMT is one logical starting point. The existing credit institution framework can support issuance, while the operational requirements can be integrated with existing treasury, compliance, and payments infrastructure.

Understanding regulatory obligations

EMT-issued tokens must meet specific MiCA obligations. For EMI-issued EMTs, safeguarding requirements constrain how the associated funds can be held and invested. For a credit institution issuing its own EMT, the balance-sheet and prudential treatment is different and must be designed explicitly. The distinction matters economically as well as operationally. EMT holders cannot receive interest or equivalent remuneration, so the economics must be built around the permitted banking and payment services surrounding the instrument.

An EMT that meets the MiCA criteria for significance brings additional supervisory and prudential requirements. Building the necessary reporting, governance, and liquidity capabilities from the outset is considerably cheaper than retrofitting the architecture after the token has become systemically important to the institution’s operations. Holders of EMTs have a statutory right to redeem at par value.

The bank must maintain sufficient liquidity to meet redemption demand, and this obligation needs to be incorporated explicitly into the bank’s liquidity, intraday liquidity, and stress-testing frameworks. Material operational and ICT incidents involving the token infrastructure need to be incorporated into the bank’s DORA incident-management and reporting framework, alongside cryptoasset-specific supervisory obligations. This extends incident management well beyond traditional IT monitoring and requires detection and classification mechanisms specific to on-chain events.

Blockchain infrastructure as a long-term decision

Blockchain infrastructure selection determines switching costs and interoperability for a decade or more, which can make deferring it or making it implicitly through vendor selection a costly mistake. For a bank prioritising validator control, predictable governance, and compatibility with existing EVM tooling, an EVM-compatible permissioned network is a plausible starting architecture, potentially with controlled connectivity to public networks. Either way, the choice should follow decisions around your liability, settlement, and interoperability requirements rather than precede them.

Governance structures matter as much as technology

The question of which legal entity issues the token is not a corporate technicality. It determines who bears the liability, who controls the minting authority, and who is accountable to regulators. Any bank distributing through subsidiaries or affiliated entities must formalise the issuer-distributor relationship and the regulatory responsibilities of each participant explicitly. Smart contract design should encode appropriate compliance controls directly. This includes address blocking for sanctions compliance, multi-signature mint and burn controls, configurable transfer restrictions, an emergency pause with clearly governed lifting authority, and a proxy upgrade pattern that allows regulatory changes to be reflected in contract logic without migrating token balances. The oracle architecture for continuous reserve or asset attestation becomes production-critical infrastructure rather than a reporting tool.

Blockchain transactions can settle within seconds, while sanctions list updates can be published with no advance notice. The architecture therefore calls for automated, near-real-time list ingestion, pre-transfer screening, and a documented escalation process for the window between a new designation and the blocklist update.

The operational infrastructure that determines success

The core banking integration is where most projects encounter their largest delays. Deposits or other qualifying funding events must trigger minting events on-chain; redemptions must trigger burns followed by outgoing payments. The bidirectional event stream between the core banking system and the blockchain node layer requires bespoke development and must handle orphaned transactions, double-entry mismatches, duplicate minting attempts, and failed burns, each of which can carry regulatory and operational implications.

The Travel Rule requires originator and beneficiary information to accompany in-scope cryptoasset transfers involving CASPs. Transfers involving self-hosted addresses above €1,000 bring additional ownership or control verification requirements. That information is typically exchanged through an off-chain Travel Rule messaging mechanism, requiring the bank to select a protocol, implement it, and manage counterparties operating on different standards. The reconciliation engine should continuously reconcile outstanding on-chain token balances to the corresponding issuer liability and, where applicable, safeguarded or reserve assets. Any divergence should trigger automated alerting and defined escalation procedures.

Where the strategic value lies

The ECB’s digital euro, with potential first issuance targeted for 2029, is the most significant strategic variable in any EUR digital-money planning. If distributed through commercial banks as currently envisioned, it will provide a public digital-money infrastructure for retail payments while allowing banks and payment providers to build services around it. That makes B2B and institutional settlement a potentially more defensible positioning for a bank-issued EMT.

A bank whose competitive strengths lie in institutional relationships, correspondent banking networks, or multi-currency settlement corridors may find more durable value in targeting those use cases than in building a retail payment product competing directly for the same customer interaction. The strategic question is which form of bank money belongs on which network, for which transaction, under whose liability, and with what controls. Banks should treat the regulatory, operational, and integration work as the primary exercise and the token as the output.