EU vs US: Navigating Regulatory Expectations
When the Regulator Calls First, You Have Already Lost I launched a fintech product in the US and the UK on the same day in 2017. It felt like a milestone. Two major markets, simultaneous entry, the kind of thing I put in an investor update with some pride. What I did not fully appreciate at the time was that I had not launched one product into two markets. I had launched two entirely different regulatory relationships, and I only understood that after one of them had already gone wrong. The US engagement started with a detailed inquiry. A user complaint had reached the regulator before my proactive risk framework had reached anyone. The product was live, customers were onboarding, and the first substantive conversation I had with a US regulator was reactive. I was explaining myself rather than introducing myself. The tone of that distinction matters more than most founders realise until they are sitting in it. The UK experience was almost the inverse. I had pre-application meetings, scenario testing, and a structured review of my risk framework before a single customer had touched the product. The FCA wanted to understand how I thought before they watched how I behaved. At the time, I found the process slow and occasionally bureaucratic. In hindsight, I would have paid for it. The Moment I Realised I Was Already Behind Here is the part I do not often tell. By the time I understood that my US launch was already out of compliance – not catastrophically, but materially – I had been operating for several weeks. The product had passed my internal review. It had passed legal. I had built a risk framework I was genuinely proud of. What I had not done was map my compliance assumptions against US-specific regulatory philosophy, because I had made the mistake of assuming that a well-built product with strong internal governance would translate cleanly across jurisdictions. It did not. The first user complaint was not about the product. It was about a data handling notice. A feature that no customer had meaningfully used – and that most of my team had forgotten was even in the product – had a data retention disclosure that did not meet state-level requirements in one US market. The regulator’s first question to me was not about my business model, my risk controls, or my financial standing. It was about my data retention policy for a feature my customers had ignored. I had spent months perfecting the user experience. The regulator’s opening question was about a disclosure buried in a settings page. There is a lesson in that irony that I have never fully stopped finding uncomfortable. Three Things I Now Understand That I Did Not Then The rules are not the philosophy. Every jurisdiction has rules. What determines how those rules are applied – the timing of engagement, the tolerance for ambiguity, the willingness to work through uncertainty with me – is the philosophy sitting underneath them. The US regulatory model, particularly in financial services, operates on a philosophy of permissiveness with enforcement backstop. I am broadly allowed to innovate, and the system corrects through action after the fact. The EU and UK model is built on a philosophy of pre-emptive assurance. The regulator wants confidence before I build momentum, not accountability after I have it. Neither philosophy is superior. But confusing one for the other is where serious exposure lives. Proactive engagement is not a soft skill in the EU – it is a market entry strategy. The assumption most founders carry into European regulatory engagement is that more rules mean slower progress. The opposite is often true. Because EU and UK regulators expect pre-engagement, they are structurally set up to give it to me. The FCA’s innovation pathways, the sandbox frameworks, the pre-application guidance – these exist because the philosophy demands proactive dialogue. If I use them properly, I arrive at launch with documented regulatory alignment rather than undisclosed risk. That is not a slower path to market. That is a cleaner one. The regulator does not surprise me. I surprise myself. This is the thing I keep coming back to. In both markets, the regulator behaved exactly as their published guidance, their public speeches, and their prior enforcement actions would have predicted. I was the one who had not read the signals correctly. I had read the rules. I had not read the character of the institution. Those are different things, and the gap between them is where most cross-border regulatory failure actually happens. What This Means If You Are Building Across Jurisdictions Now If I am running a fintech, a GRC platform, or any regulated product across more than one geography, the question is not whether I have legal coverage in each market. The question is whether the person responsible for regulatory strategy in each market has genuine fluency in how that regulator thinks, not just what it requires. Rules can be read by a good lawyer. Philosophy has to be learned through proximity – through pre-meetings, through sandbox engagement, through understanding what a regulator has said in its last five public consultations and why. The organisations I have seen handle multi-jurisdictional launches well share one common trait: they treat regulatory engagement as a relationship to be built before it is needed, not a process to be managed after something goes wrong. That requires time, and it requires the kind of senior attention that often gets deprioritised in favour of product and commercial priorities. I have made that deprioritisation myself. I am not exempt from the lesson. It also requires the kind of honest internal culture where the compliance team feels genuinely empowered to raise a concern before launch, not after. That is a different conversation – one I have written about elsewhere – but it is inseparable from this one. The Closing Thought Two regulators, one product, entirely different outcomes – and the difference had nothing to do with the quality of what
Operational Resilience Beyond DORA: 2026 Perspectives
Operational Resilience Is Not a Document. It Is a Data Problem. DORA is already law. Most institutions are still working out whether they can actually comply with it. That distinction matters. There is a wide gulf between an organisation that has spent eighteen months building a compliance framework and one that can answer the questions the framework exists to answer. The first is visible. The second is rare. The gap between them is not a regulatory problem, it is an infrastructural one the industry has quietly avoided for years. The March 2026 Information Register submission is about to make that avoidance very loud. — The Room That Went Quiet Early in 2025, I sat with the CRO of a mid-sized financial institution. DORA had just become enforceable. Her team had done what looked, by any reasonable standard, like serious work. Eighteen months of it. Policy documents. Risk registers. Governance structures. Third-party mapping. They had the architecture of compliance. It was genuinely impressive, the kind of work that gets presented well in a board pack. Then someone in the room asked about the March 2026 Information Register submission. The room went quiet. Not the polite quiet of people organising their thoughts. The other kind, where everyone is doing rapid mental arithmetic and arriving at the same uncomfortable answer. The data needed to populate that register simply did not exist in a usable form. It was distributed across systems that did not talk to each other, owned by teams with different definitions of the same terms, stored in formats that made aggregation a manual project measured in weeks, not hours. Eighteen months of compliance work. The underlying data layer: untouched. I have been in enough of these rooms to know this silence is not unique to that institution. I have seen versions of it in London, in Dubai, in Mumbai. Different organisations, different regulators, identical pause. What struck me that day was not the gap itself, I had expected to find gaps. It was the specific shape of it. The team had built compliance theatre. Beautifully documented. Operationally hollow. — Three Things That Conversation Made Undeniable **The first is that most institutions confuse documentation with readiness.** This is not laziness or incompetence. It is a rational response to how compliance has historically been evaluated. Regulators asked for evidence of frameworks. Organisations produced frameworks. The feedback loop rewarded paperwork. DORA has changed the question being asked. The Information Register is not a document, it is a live query run against your actual data architecture. You cannot write your way to a passing grade. The data either exists in a coherent, mappable form, or it does not. **The second is that this is the same problem wearing different clothes.** The broken data layer that cannot support an Information Register submission is the same broken data layer that cannot support AI or ML initiatives. When organisations talk about data readiness for artificial intelligence, and the conversation comes up constantly now, they often frame it as a new investment required for new capabilities. In most cases, it is neither new nor optional. It is a pre-existing infrastructure deficit that AI ambitions have simply made impossible to defer. I wrote about the adjacent problem, the way third-party data creates hidden exposure, in an earlier piece on [rethinking third-party risk](https://lakshvaswani.com/when-partners-become-liabilities-rethinking-third-party-risk/). The pattern is the same: the problem is not the risk you can see. It is the one your data architecture cannot tell you about. **The third is the one the industry least wants to hear.** Operational resilience frameworks that rest on poor data infrastructure are not frameworks. They are documents waiting to embarrass you. The scenario matters here: a genuine operational disruption, a regulatory examination, a cyber incident requiring rapid forensics. All of them require the same thing, accurate, accessible, well-governed data about your critical functions, your dependencies, and your recovery pathways. If that data does not exist in a usable form under normal conditions, it will not materialise under pressure. I have written previously about [the human side of cyber risk](https://lakshvaswani.com/when-firewalls-fail-the-human-side-of-cyber-risk/) and the way institutional confidence about resilience tends to collapse precisely when it is tested. Data readiness is the structural version of that same overconfidence. — What This Means for the Institutions Still Building If your organisation is in the cohort that has the framework but not the data infrastructure to support it, and based on everything I am seeing, that is most of the industry, the path forward has a specific sequence. The Information Register deadline is the forcing function, but treating it as a one-time submission exercise would be a significant mistake. The register is a symptom question. The actual question it is asking is whether your data governance, your system architecture, and your critical function mapping are coherent enough to produce a reliable, auditable output on demand. Answering yes in 2026 and reverting to fragmentation in 2027 solves nothing. Continuous readiness cannot be delegated to a project team that convenes before a regulatory deadline. It has to be owned at the top, funded accordingly, and treated as a permanent operational capability, not an event. This also has direct implications for AI ambitions. Boards and executive committees increasingly want to understand when and how they can deploy AI and ML across risk and compliance functions. The honest answer is that those capabilities will perform in direct proportion to the quality of the data they run on. Closing the data preparedness gap is not a precondition for AI, it is the work itself. — The institutions that come out of the DORA era in the strongest position will not be the ones with the most sophisticated frameworks. They will be the ones that quietly fixed their data infrastructure while everyone else was still formatting governance documents. A resilience framework that relies on data you cannot actually produce is not a framework. It is a liability you have not invoiced yet.