The Conventional Wisdom
Regulators want you to slow down. When Klaus Löber, chair of the CCP supervisory committee at Esma, announced that cloud and AI adoption won't soften regulatory expectations for clearing houses, the compliance community nodded in agreement. The message felt familiar: new technology equals new risk, which demands stricter oversight and more documentation before you move forward.
This view has become a compliance reflex. Your team hears "heightened scrutiny of third-party risk" and immediately adds another vendor questionnaire to the stack. You're told that operational resilience means proving you can operate without the cloud provider, which defeats the purpose of cloud migration. The implicit message: treat cloud and AI as liabilities to be contained, not capabilities to be governed.
Why We Disagree
Esma's position conflates technology adoption with risk creation. That's backwards. Cloud services and AI don't inherently increase operational risk in clearing operations. Poorly governed legacy systems running on aging infrastructure in proprietary data centers create far more operational resilience exposure than a well-architected cloud deployment with contractual SLAs and geographic redundancy.
The regulatory stance treats third-party risk as a binary problem: you either own the infrastructure or you accept uncontrollable vendor risk. But modern cloud contracts give you more operational control than you had with traditional outsourcing. You can specify data residency, demand encryption standards, require audit rights, and test failover procedures on a schedule you control. Your clearing house doesn't lose governance authority when you move to cloud infrastructure. You gain transparency into failure modes that were opaque in the data center era.
The real issue isn't whether regulators will "soften" their expectations. It's whether those expectations reflect how operational resilience actually works in 2025. If your regulator demands that you can operate independently of your cloud provider within hours, they're asking for a recovery capability that's technically impossible and financially wasteful. No clearing house maintains a parallel on-premises infrastructure capable of processing live trades. That's not resilience planning; it's regulatory theater.
The Evidence
Look at what Esma's framework actually requires under EMIR and the CCP Recovery and Resolution Regulation. You need documented risk governance, operational continuity plans, and the ability to maintain critical functions under stress. None of these requirements specify technology choices. They specify outcomes.
A cloud-based clearing system can meet these outcomes more effectively than legacy infrastructure:
Risk Governance: Cloud providers document their control environments through SOC 2 Type II reports and ISO/IEC 27001 certifications. You get third-party validation of security controls that most internal IT teams can't match. Your vendor due diligence becomes more rigorous, not less, because you're reviewing audited evidence instead of trusting internal IT assertions.
Operational Continuity: Multi-region cloud deployments give you geographic redundancy that's prohibitively expensive to build on-premises. When you architect for cloud-native resilience, you're testing failover between regions monthly, not annually. Your recovery time objectives improve because the infrastructure supports rapid redeployment.
Critical Function Maintenance: Cloud services include built-in monitoring, automated scaling, and incident response capabilities that exceed what most clearing houses can staff internally. You're not outsourcing operational resilience; you're accessing operational capabilities that didn't exist in the data center model.
The gap isn't between regulatory expectations and cloud capabilities. It's between regulatory expectations and how compliance teams interpret them. When Löber says expectations won't change, he's not saying you can't use cloud services. He's saying you still need to demonstrate governance, resilience, and risk management. Those demonstrations look different in cloud environments, but they're often stronger.
What to Do Instead
Stop treating cloud migration as a compliance concession you need to negotiate. Start treating it as a risk management upgrade that requires new validation approaches.
Reframe Your Vendor Risk Assessment: Don't ask whether your cloud provider is "safe enough" to use. Ask whether their control environment exceeds your current infrastructure's documented capabilities. If you can't produce SOC 2 evidence for your existing data center operations, you're running higher third-party risk right now with your facilities management vendor, hardware suppliers, and network providers.
Document Operational Resilience Gains: Map your current recovery time objectives against what you can achieve with multi-region cloud architecture. If cloud deployment improves your RTO from 24 hours to 2 hours, that's not a regulatory compromise. That's a resilience improvement you should be highlighting in your EMIR disclosures.
Separate AI Governance from Cloud Governance: Esma lumped these together, but they're distinct risk domains. Your cloud infrastructure decisions involve vendor concentration risk and data residency requirements. Your AI model decisions involve model risk management, validation evidence, and performance monitoring. Don't let cloud migration debates stall your AI governance framework.
Build Contractual Resilience: Your cloud service agreements should specify audit rights, data portability standards, and exit assistance obligations. These aren't optional terms; they're how you demonstrate operational resilience to supervisors. If your provider won't commit to structured exit support, you have a legitimate third-party risk concern. If they will, you've addressed the regulator's core worry.
When the Conventional Wisdom Is Right
Esma's caution makes sense in one scenario: when you're using cloud or AI adoption as an excuse to skip governance work.
If your clearing house migrates to cloud infrastructure without updating your business continuity plans, you've created new risk. If you deploy AI models for margin calculation without validation evidence and ongoing performance monitoring, you're gambling with operational integrity. If you assume that your cloud provider's security controls eliminate your own security obligations, you've misunderstood the shared responsibility model.
The regulatory stance is correct when it pushes back against governance gaps disguised as innovation. When a CCP says "we're moving to the cloud" but can't explain their data recovery procedures, incident escalation protocols, or vendor exit strategy, that's not modernization. That's negligence with better marketing.
Löber's message matters most for clearing houses that treat compliance as a checklist rather than a capability. If you're migrating to cloud because your competitors did, without understanding how it changes your operational risk profile, you should slow down. The regulator is right to maintain expectations.
But if you're migrating because cloud architecture genuinely improves your resilience, reduces your infrastructure risk, and gives you better control visibility, then Esma's expectations aren't a barrier. They're a validation framework you can meet more effectively than you did with legacy systems.
The question isn't whether regulators will soften their stance. It's whether your compliance team will update their mental model of what good risk governance looks like in 2025.
