Much of the MiCA conversation has focused on applications, authorisation packages and transition deadlines. That is understandable: getting authorised is a major milestone. But from a finance perspective, the harder phase often starts immediately afterwards.

Once a crypto-asset service provider is authorised, the question changes from “can we demonstrate that we have a framework?” to “can we operate that framework every day, at scale, with evidence?” MiCA requires authorised providers to continue meeting the conditions of their authorisation, which means governance, systems and controls cannot remain static documents produced for an application file.

Finance becomes part of the regulatory operating model

MiCA is not an accounting standard, but many of the controls required to run a compliant crypto business rely on finance-quality data: cash and asset positions, reconciliations, liquidity visibility, fee income, client balances, capital, expenses, intercompany flows and evidence that exceptions were investigated.

The finance function therefore needs to be designed into the operating model rather than brought in at month end to explain what happened.

Six areas to make operational

Month end is where weak operating models reveal themselves

Rapidly growing digital-asset businesses often discover that product systems, wallets, banking platforms, ledgers and accounting systems do not naturally produce one reconciled version of the truth. The problem is rarely solved by adding another spreadsheet.

A strong close process needs clear source-system ownership, controlled data extraction, documented valuation and cut-off rules, reconciliations between operational and accounting records, and a way to distinguish genuine accounting differences from unresolved operational breaks.

Regulation should not create a parallel finance universe

One of the most expensive mistakes is building regulatory reporting as a separate process beside management and statutory reporting. The same underlying balances then acquire different definitions, data owners and adjustment logic.

Where possible, the regulatory operating model should reuse controlled finance data and add clearly documented regulatory transformations. That reduces duplication and makes reconciliation between management, statutory and regulatory views much easier.

Authorisation is a control baseline, not a finish line

ESMA’s MiCA framework makes clear that authorised crypto-asset service providers are expected to continue meeting the conditions under which authorisation was granted. That means the real work is continuous: products change, transaction volumes grow, providers are replaced and organisational responsibilities move.

The finance framework has to change with them.

Operational finance commentary, not legal advice. MiCA interpretation should be confirmed with appropriate legal and compliance advisers. See ESMA’s MiCA single rulebook, including Article 59 on authorisation and ongoing conditions.

The Digital Operational Resilience Act has forced financial institutions to become much more explicit about ICT risk, critical providers, incident management and resilience. That is a positive development. It has also created a useful side effect: many firms are finally mapping the third parties on which important processes depend.

The danger is stopping the exercise too early.

A critical dependency does not become harmless simply because it is not an ICT service. A payment institution may depend on a safeguarding bank, payroll provider, local accountant, card scheme, external reconciliation process, specialist compliance provider, outsourced operations team or data supplier. A fast-growing fintech may have one person who knows how a recurring regulatory submission actually gets completed. None of those examples fits comfortably into a simplistic “technology vendor” box, yet failure can still interrupt operations, reporting, cash access or regulatory obligations.

Start with the process, not the supplier register

Supplier registers are useful, but they are usually organised around contracts and procurement. Operational resilience works better in the opposite direction. Start with a critical process and ask what has to work for that process to complete on time and correctly.

For finance, that might mean month-end close, daily client-money reconciliations, liquidity monitoring, payroll, regulatory reporting, settlement, treasury payments or access to bank accounts. The dependency map is often broader than expected once each process is followed end to end.

Five controls worth reviewing

Finance owns more of this than it sometimes realises

Third-party risk is often assigned to procurement, technology, compliance or operational resilience. But finance commonly owns or co-owns the business processes in which the consequences become visible: inaccessible cash, missing reconciliations, delayed reporting, incorrect payments, failed close activities or lack of evidence for an auditor or regulator.

That makes finance an important participant in resilience design, not merely a recipient of vendor questionnaires.

What good looks like

A strong framework does not require a huge governance industry. For a smaller regulated business, a concise process inventory, dependency map, owner matrix and periodic review can be more useful than an elaborate policy nobody uses.

The important point is that the organisation can explain which dependencies are genuinely critical, why they matter, who owns them, what is monitored and what happens if they fail.

DORA provides a strong reason to improve that discipline for ICT risk. The same thinking is worth applying to the rest of the operating model.

This article is operational finance commentary, not legal advice. Regulatory interpretation should be confirmed with the appropriate legal or compliance advisers. For background on DORA, see the European Commission’s digital operational resilience material and Regulation (EU) 2022/2554.