Regulated stablecoins are no longer a matter confined to the crypto ecosystem. With MiCA fully applicable, institutions operating in the European Union have a clear framework to distribute, accept and, in the case of credit institutions, issue e-money tokens. The relevant question for a bank is no longer whether stablecoins exist, but what they add to its day-to-day operations and what they require in return.
This article approaches the question from an operational standpoint: what a regulated stablecoin actually is, which capabilities it adds to the bank, what changes in its processes and what stays the same.
What a regulated stablecoin is
Regulation (EU) 2023/1114, known as MiCA, distinguishes two categories of stable tokens. E-money tokens (EMTs) reference a single official currency, while asset-referenced tokens reference a basket of assets or currencies. For banking operations, the first category is the relevant one.
An EMT can only be issued by a credit institution or an e-money institution. The holder has a right of redemption at par, at any time, against the issuer. The reserves backing the token are the issuer’s responsibility and are subject to requirements on composition, safekeeping and supervision.
In practice, an EMT is electronic money circulating on a blockchain network. It keeps the nominal value of the currency it represents, but it is transferred and settled with the properties of a digital asset: a shared record, continuous availability and the ability to programme conditions on its movement.
What it brings to the bank’s operations
The value of regulated stablecoins for a bank does not lie in replacing its accounts, but in adding a settlement medium with different properties.
Continuous settlement and transfers between clients
A stablecoin transfer settles on the network as soon as it is confirmed, without depending on cut-off times or clearing cycles. For transfers between the bank’s own clients, this allows 24/7 availability with immediate settlement and a verifiable record of every movement.
Liquidity for investing in tokenised assets
When the bank offers its clients investment in digital assets or tokenised stocks, the stablecoin acts as the cash leg on the same network. The client can convert from their own currency, invest and recover liquidity without leaving the institution’s perimeter, and delivery versus payment is resolved in a single operation.
Programmability
The conditions of a movement can be encoded: payments conditional on an event, staged releases, limits per counterparty or automatic flows between treasury accounts. The business logic remains the bank’s; the network executes what the bank has defined.
Treasury and preparation for markets that settle on-chain
For treasury, holding liquidity in stablecoins reduces friction when operating with instruments that settle on-chain. As more assets are issued and settled in tokenised form, having the cash leg on the same infrastructure stops being optional.
What changes for the bank
Adopting regulated stablecoins introduces new processes that are best designed from the outset.
- Conversion flows. The client keeps operating in their own currency. The bank needs a conversion process between the client’s account and the stablecoin, with prices, limits and a record of every conversion.
- Reserves. If the bank distributes or accepts a third party’s EMT, the reserves are the issuer’s responsibility. The bank must assess the issuer, its authorisation and its redemption capacity, as it would any counterparty.
- Travel rule. Since 30 December 2024, Regulation (EU) 2023/1113 requires crypto-asset transfers to be accompanied by information on the originator and the beneficiary.
- Anti-money laundering and monitoring. On-chain operations must be integrated into the bank’s transaction monitoring systems, including analysis of source and destination addresses.
- Accounting treatment. The bank must define how it records stablecoin positions, conversions and network fees.
- Limits. Amounts per operation, per client and per period, defined by the bank and applied before each operation is executed.
What does not change
The client relationship remains the bank’s, under its brand and from its own app. Client identification relies on the KYC the institution has already performed; no parallel identity is created. The client’s currency accounts continue to exist and remain their main reference. The service is provided under the bank’s licences, and client data stays within the institution.
If the infrastructure forces the bank to duplicate client identity, move data outside the institution or operate under someone else’s brand, the bank gives up control it should keep.
Risks and controls
The risks are well understood and manageable if the controls are designed before going into production.
- Issuer risk. It depends on the soundness of the issuer and the quality of its reserves. It is mitigated through due diligence, exposure limits and contingency plans for a redemption event.
- Operational and custody risk. The keys controlling the funds must sit in the bank’s HSMs, physical or in its cloud, with signing policies and segregation of duties. Regulation (EU) 2022/2554 (DORA), applicable since 17 January 2025, also requires structured management of technology and third-party risk.
- Reconciliation risk. The network record, the internal ledger and the core banking system must agree. Defined thresholds and an exceptions process with clear owners are needed.
- Compliance risk. Travel rule, sanctions and monitoring must be applied automatically and before execution, not as an after-the-fact review.
- Network risk. Congestion, variable fees or failed transactions must be covered in operational processes.
Checklist for the bank
- Define the initial use case: transfers between clients, liquidity for investing in tokenised assets, or treasury.
- Select the regulated stablecoins to be distributed or accepted and assess their issuers.
- Design the conversion flow between the client’s currency and the stablecoin, with prices and limits.
- Integrate the travel rule and transaction monitoring into existing systems.
- Establish key custody in the bank’s HSMs and the associated signing policies.
- Define the accounting model and the data the accounting team needs.
- Set reconciliation thresholds and the exceptions process.
- Validate all of the above in a proof of concept before widening the scope.
The value of stablecoins for a bank depends less on the network technology than on the quality of its integration with the institution’s processes. At Finhattan we deploy and operate this infrastructure inside each bank, with keys in its HSMs and under its licences; the approach is described in how we work and security and control.
For institutions assessing this step, an early technical conversation, through contact, usually clarifies the scope of a first proof of concept.