MiCA (Regulation (EU) 2023/1114) is fully applicable, and the transitional period for existing providers ended by 1 July 2026 at the latest. DORA (Regulation (EU) 2022/2554) has applied since 17 January 2025. For a bank that wants to offer digital assets to its retail clients, the two regulations need to be read together: the first defines which services it may provide and on what terms; the second, how it must manage the technology and the providers that make those services possible.
The context has shifted quickly. Eight of the twenty largest banks in Europe already operate with digital assets, compared with two at the start of 2025. At the same time, according to The Financial Grid 2026, a survey of 638 executives, 88% of financial institutions have committed budget for digital assets, yet only 16% have reached production. Much of that gap is explained by regulatory and operational questions rather than by the technology itself.
What MiCA means for a credit institution
MiCA sets a common framework for crypto-assets that are not financial instruments. For a bank, the starting point is Article 60: a credit institution may provide crypto-asset services by notifying its competent authority, without obtaining a separate authorisation as a crypto-asset service provider (CASP). The notification must include, among other elements, the programme of operations, internal control mechanisms, risk management, the business continuity plan, ICT and security arrangements, and anti-money laundering procedures.
The services a bank typically considers are custody and administration of crypto-assets on behalf of clients, reception and transmission of orders, execution of orders, and exchange of crypto-assets for funds. Each service carries its own requirements, but some are common to all:
- Custody and safeguarding: segregation of client assets from the bank’s own, per-client position records and a documented custody policy. The bank is liable to the client for the loss of assets resulting from incidents attributable to it.
- Conflicts of interest, complaints handling and client information, including disclosure of risks and costs.
- Anti-money laundering and the travel rule: since 30 December 2024, Regulation (EU) 2023/1113 requires crypto-asset transfers to carry information on the originator and the beneficiary.
A crypto-asset white paper, by contrast, is the responsibility of the offeror or of whoever seeks its admission to the market, not of the bank that distributes it.
Stablecoins and e-money tokens
MiCA regulates e-money tokens (EMTs), which reference a single official currency, and asset-referenced tokens. For a bank that wants its clients to hold balances or pay with stablecoins, the practical point is to work with tokens issued in compliance with MiCA by authorised issuers, and to apply to their custody and transfers the same controls as for any other crypto-asset.
What falls outside MiCA
MiCA excludes from its scope crypto-assets that qualify as financial instruments. Tokenised stocks and other tokenised securities remain subject to MiFID II, with its obligations on client categorisation, suitability or appropriateness, product governance and best execution. The DLT Pilot Regime (Regulation (EU) 2022/858) also exists for DLT-based market infrastructures.
In practice, a bank offering both crypto-assets and tokenised securities will be working under two distinct regulatory frameworks on a single technical infrastructure. It is therefore advisable to classify each asset before adding it to the catalogue and to document the reasoning, since the legal qualification determines which obligations apply in each case.
DORA and reliance on technology providers
DORA is not specific to digital assets, but it shapes any project that depends on third-party technology. Its requirements fall into four areas:
- ICT risk management, with a documented framework approved by the management body and reviewed regularly.
- Classification and reporting of major ICT-related incidents to the competent authority within the set deadlines.
- Digital operational resilience testing, which for the most significant institutions includes advanced threat-led penetration testing.
- ICT third-party risk, with a register of information covering all contractual arrangements and minimum clauses in contracts.
The last area has the greatest bearing on a digital assets project. Contracts must describe services precisely, state where data is processed and stored, guarantee access, inspection and audit rights for the institution and its supervisor, and provide for termination rights. Where the service supports critical or important functions, the institution also needs documented and tested exit strategies that allow it to change provider or bring the service in-house without disrupting its business.
Why it matters where the infrastructure runs
A closed external service does not prevent DORA compliance, but it forces the institution to demonstrate from a distance many things it does not directly control. When the infrastructure is deployed inside the bank and under its control, several obligations become easier to evidence:
- Audit and access: systems run on the bank’s own infrastructure, so its teams and its supervisor can inspect them without depending on third parties.
- Data residency: client data stays within environments the bank has already approved.
- Exit strategy: keys sit in the bank’s HSMs and the infrastructure runs on its systems, so ending the relationship with the provider does not mean migrating assets or rebuilding custody.
- Incidents and testing: monitoring, reporting and resilience testing fit into the processes the bank already applies to the rest of its systems.
Whoever develops and operates the software remains an ICT third-party provider, and the contract must still include the DORA clauses. What changes is the perimeter: operational control, keys and data never leave the institution.
A checklist to get started
Before launching a digital assets service, a bank should have answers to the following:
- Which crypto-asset services it will provide, and whether the Article 60 notification is ready with all the required documentation.
- Which assets in the catalogue are crypto-assets under MiCA and which are financial instruments under MiFID II.
- Which custody and wallet model it will use, individual or omnibus, and how positions are segregated and reconciled.
- Where client keys are generated and held, and who can sign transactions.
- How the travel rule is applied to transfers.
- Which stablecoins it will accept, and how it verifies that they comply with MiCA.
- Which ICT providers are involved, whether they appear in the register of information and whether their contracts include the DORA clauses and an exit strategy.
- How incidents are detected, classified and reported, and how the resilience of the service is tested.
At Finhattan we work with banks within this framework: a senior engineering team that deploys and operates the infrastructure inside each institution, with keys in its HSMs and under its licences. The approach is set out in security and control and the solution.
Going through this checklist with compliance, risk and technology teams is usually the most useful first step. To test it against a specific case, the starting point is our contact page.