Three regulatory frameworks are landing simultaneously — namely MiCA, DORA and the EU AI Act, but there is no shared governance architecture that covers all three. Compliance leader and consultant Natalia Taft explores what this means for financial services firms.
I recently looked at an institution that spent 18 months stacking smart contract settlement, DeFi protocols and AI risk models on top of each other. From the outside, it was a success: Systems were running and revenue was climbing. But when a supervisor asked a simple question — which legal entity was actually responsible for an AI model routing assets through an unaudited protocol — nobody could answer cleanly.
Three different teams held pieces of the puzzle, but no one owned the end-to-end logic. The AI model had been validated at launch, but the underlying protocols had already been updated twice. Because the client-facing entity and the AI engine sat in different jurisdictions, visibility evaporated. This is the hidden cost of convergence: Everything looks under control until you realize your innovation speed has completely outrun your ability to govern it.
The regulatory collision
The frameworks are arriving, but they are arriving separately. MiCA now applies to crypto asset service providers (CASPs) across the EU, establishing licensing, custody and conduct requirements for the first time at continental scale. DORA has been in force since January 2025, requiring information and communications technology (ICT) risk management, incident reporting and third-party oversight, including for CASPs authorized under MiCA. The EU AI Act is phasing in risk-based obligations for high-risk AI systems: risk management, data governance, technical documentation, human oversight.
Each framework solves a specific problem, but none governs their convergence. A firm that tokenizes assets, offers protocol access and uses AI for client-facing decisions has to comply with all of them and build internal governance that connects them because the regulations do not. Meanwhile, the International Organization of Securities Commissions (IOSCO) DeFi recommendations push jurisdictions to identify responsible persons behind decentralized arrangements. Basel’s prudential framework for crypto asset exposures is pulling crypto risk into formal capital and disclosure requirements for internationally active banks. And FATF continues to note that identifying persons exercising control over DeFi remains an unresolved challenge. The supervisory perimeter is expanding from every direction at once.
Where governance actually breaks
Governance for convergent systems starts with what I call an activity map, a map of what the firm actually does. Which product, which client, which legal entity, which protocols, which models, which data sources, which third parties, where the assets sit and where the money moves. If you cannot draw that map, you cannot govern the activity. The NIST AI risk management framework organizes AI risk around four functions (govern, map, measure, manage) and that structure is a useful backbone. But it only works if data lineage is real. In AI and DeFi environments, data is the control environment.
If you cannot trace where the data came from, how it was transformed and what decision it fed, you cannot defend that decision to a supervisor. Then there has to be a stop mechanism, not an escalation path that terminates in a committee meeting — a real ability to pause a model, freeze a feature or restrict a protocol before the next trade clears. Most firms I work with can approve a product in weeks. Halting one under pressure takes far longer than it should.
Trustless does not mean unaccountable
The word “trustless” describes how a protocol settles transactions. It says nothing about the firm that connected its clients and custody infrastructure to that protocol.
The practical question is where your control points are. Where does the client enter the system? Who screens them? Which entity provides access? Where are assets held? Which smart contracts are touched? What happens when liquidity disappears, when the protocol is exploited, when a sanctions hit appears midstream? Who can stop everything and how fast?
I keep hearing firms argue that they do not control the protocol, as if that closes the question. A regulated firm may not control Ethereum, but it absolutely controls whether it routes clients, assets and regulated services through it. The US Treasury’s DeFi risk assessment made this point directly: The touchpoints between regulated firms and decentralized protocols create the accountability surface, regardless of the protocol’s own architecture. Due diligence, approved protocol lists, smart contract audits, wallet screening, sanctions controls, concentration limits and incident playbooks — none of this is optional; it is the cost of participation.
When AI operates inside the control perimeter
My rule: Nothing executes, moves assets, approves exposure or interacts with DeFi infrastructure until six things are answered. What data the model uses, exactly. How it behaves under stress and adversarial conditions. What it is permitted to do, written down, limited and enforced. Where the human intervention point sits. Whether we can reconstruct every decision after the fact. And how drift is monitored once the model is live, because models change as soon as data, markets and clients change.
Article 17 of the EU AI Act mandates quality management systems for providers of high-risk AI. SEC Rule 15c3-5, designed for traditional broker-dealer market access, already established the principle that automated access to markets requires documented pre-trade controls, supervisory procedures and clear system ownership. That principle only gets sharper when the automated system makes decisions about client money on decentralized infrastructure.
Validation cannot be a one-time sign-off. Firms that get this right version their models the way engineering versions code. Every new data source, every retraining cycle is a fresh approval event. If you cannot explain the model’s decision to a regulator, the model should not be making that decision.
And when a model or smart contract does fail, the remediation looks nothing like fixing a manual process. You are unpicking a system that may have scaled the error across every decision it made while it was live. The evidence trail, logs, inputs, outputs, model versions, code versions, deployment records, has to exist before the failure occurs. “The model did it” will not satisfy a supervisor. Instead they will ask who approved the model, how it was tested, what controls missed the failure and which clients were affected.
The 2027 prediction
Over the next two years, supervisory pressure will concentrate around custody and client asset protection, liquidity and concentration risk under stress, operational resilience across technology and blockchain disruptions, model accountability with real validation and human oversight and cross-border clarity on which legal entity owns which obligation. The FCA’s discussion paper DP25/1 is already signaling how the UK intends to bring crypto activity inside the perimeter. The direction is consistent globally, even where timelines diverge.
I believe by 2027, the defining question for any institution operating at this intersection will be whether it can demonstrate, in real time and after the fact, that every automated decision, asset movement and client exposure sat inside a controlled, explainable and accountable governance perimeter. Who approved the model. Who validated the data. Who tested the smart contract. Who had the authority to stop it.
Firms that close the gaps deliberately will shape what comes next. The rest will learn about it through enforcement.
