Data platform modernization in fintech and insurance means moving from a legacy warehouse and per-system silos to a governed cloud platform where regulatory reporting, risk calculation and AI read the same curated data under one set of controls. It is not a core system replacement, and not a lift-and-shift of yesterday's ETL onto rented infrastructure. Three forces put it on the 2026 agenda for European institutions. The first is regulatory: the Digital Operational Resilience Act, Regulation (EU) 2022/2554, has applied since 17 January 2025 to 20 types of financial entity and to their ICT providers. The others are the cost of change inside a fragmented estate, and AI programmes that cannot pass a model risk review while the data underneath them stays ungoverned. For most CDOs the open question is no longer whether to modernize but in which sequence: which domain moves first, and how supervisory reporting keeps running while it does.
What Data Platform Modernization Means in Financial Services
The definition is architectural rather than commercial: four layers move together. Ingestion lands data from core banking, policy administration, claims and market feeds without a hand-built extract per consumer. Storage holds raw and curated data in one place instead of a copy per department. Governance carries lineage, quality rules and access control across the estate, not per tool. Serving feeds supervisory returns, risk engines, dashboards and models from the same curated tables.
The business case rests on one outcome: a single version of a figure that the supervisor and the model both see. Institutions rarely miss a reporting deadline because a legacy warehouse was slow. They miss it because the same exposure is calculated in several systems, and reconciling the answers takes longer than producing them. Those systems met their requirements for years; what changed is the marginal cost of each new requirement landing on top. Bringing the work under one enterprise data management model is what institutions are really buying when they fund data platform modernization.
Why 2026 Is Different: DORA Changed the Business Case
DORA does not tell anyone to modernize a data platform. It requires financial entities to manage ICT risk, report major incidents, test operational resilience, control third-party ICT dependencies and share threat information, and it places critical ICT providers under European oversight. Each obligation is an operational question answered repeatedly, on evidence, across every system holding customer or supervisory data.
That recurring proof is where a fragmented estate gets expensive. Tracing a supervisory figure back to source across separate systems is a project; inside one governed platform it is a query. The business case for data platform modernization has shifted with it. Compute and licence savings now matter less than the falling cost of demonstrating control, quarter after quarter.
| DORA pillar | Question you answer repeatedly | Platform capability that makes it cheap |
|---|---|---|
| ICT risk management | Which systems hold which data, and what stops if one fails? | Assets, dependencies and owners in one catalogue |
| Major incident reporting | What was affected, and which submitted figures are wrong? | Lineage from source system to reported number |
| Resilience testing | Can you rehearse failure without disturbing live reporting? | Environments and data sets reproducible on demand |
| Third-party ICT risk | What happens if a provider stops serving you? | Open formats and a documented exit path per domain |
| Information sharing | Can you share threat data without leaking customer data? | Classification and access control that travel with the data |
| Oversight of critical providers | Where is your dependency concentrated? | Provider exposure visible per domain, not per invoice |
Nothing in that column is an instruction to buy technology, and a well-run legacy estate can satisfy every pillar with documented manual process. The argument for modernizing is economic: manual proof gets dearer with each new obligation, provider and reconstructed incident.
The Legacy Trap: What ECB Supervision Data Shows
Supervisors publish enough data to test the intuition. In its supervisory newsletter of 19 February 2025, ECB Banking Supervision reported that outsourcing had risen from 6.8% to 7.2% of administrative costs at significant institutions under its supervision, with ICT accounting for 47% of outsourcing spend. Cloud spending averaged around EUR 57 million per institution in 2024 against EUR 50.2 million in 2023, a rise of 13.5%. Rising cloud spend is the least interesting number in the set.
Concentration is the finding that belongs in an architecture review. The same newsletter puts half of the entire outsourcing budget of those institutions with just 30 providers. The share of critical functions considered hard or impossible to substitute moved from 80% to 82%, and 95% of those would be hard to bring back in-house. Critical ICT services delivered from outside the EU rose from 22% to 27%, mainly the United Kingdom, the United States and India.
Data platform modernization in banking and insurance therefore carries a criterion beyond performance and cost: whether the institution could change its mind later. Curated data in open formats, transformation logic in portable code, and a documented exit path per domain cost more to build and far less to defend in a supervisory dialogue. A legacy data platform migration that swaps one irreversible dependency for a newer one has relocated the risk and left it in place.
Target Architecture: Lakehouse, Unified Governance, Real-Time Serving
A target architecture for data platform modernization in financial services converges on one shape: open storage formats holding a raw and a curated layer, with one governance layer applying lineage, classification and access control across both. Serving paths then feed a batch supervisory return and a real-time fraud decision from the same tables. Databricks published blueprints for this pattern in June 2022, drawn from its work with more than 600 financial services customers at that point, with two quickstarts worth knowing: Waterbear, packaging enterprise data models of the kind regulatory reporting consumes, and Tempo, a time-series library for tick data.
The engine underneath is a separate and reversible decision, provided curated data stays in an open format and logic stays in code. We set out the trade-offs in our comparison of Databricks vs Snowflake; a regulated buyer should add one criterion, which option still lets you leave.
A lakehouse is the right default for mixed workloads: claims documents, streaming payment events, model training data and regulatory tables sharing one set of definitions. For an insurer running monthly actuarial cycles and a stable set of SQL models, careful data warehouse design on a managed warehouse beats a rebuild nobody asked for.
Migration Sequencing: Modernize Without Breaking Regulatory Reporting
The first question in a regulated migration is not technical: which supervisory submissions, actuarial cycles and finance closes depend on the systems you are about to touch, and where those dates sit in the calendar. So the first deliverable is an inventory of reporting flows: every return, its source systems, its transformation logic, its sign-off owner and its deadline.
Parallel running comes next, and budgets underestimate it. Both platforms produce the same figures from the same inputs for at least one full reporting cycle, differences are reconciled to an agreed tolerance, and the person who signs the return approves the switch. Only then does a domain cut over, one at a time, keeping the blast radius inside a scope somebody owns.
The anti-pattern is a big-bang cutover timed to a reporting deadline because a licence expires or a data centre contract ends. Where those dates are immovable, extend the old platform rather than compress the parallel run; a month of duplicated infrastructure costs less than one restated submission. Sequencing is the part of data platform modernization where cloud migration services earn or lose their fee, and a partner quoting a date before reading your reporting calendar has not seen the real constraint.
Build, Buy or Hybrid: Where a Delivery Partner Fits
Build versus buy rarely has one answer across a whole platform. In financial services the split follows differentiation: logic that encodes how you price risk or detect fraud belongs in code your team owns, while connectors, schedulers, catalogues and monitoring are commodity, and building them in-house buys maintenance rather than advantage. The criteria sit in our note on build vs buy data platform; in a regulated institution, the test is whether a supervisor would ever ask you to explain the component.
Hybrid is where most data platform modernization programmes land: bought platform, bought connectors, built domain logic, built controls. A delivery partner belongs where your team cannot staff the pace the calendar demands: target architecture, migration and reconciliation around the parallel run. Judge the offer on two questions: who owns the transformation code and documentation when the engagement ends, and what your team can run unaided six months later. A partner whose model depends on being permanently resident reproduces the concentration risk you just spent a programme reducing.
Governance First: The Foundation for AI in Finance
Most institutions now have an AI roadmap and many stall in the same place. A model that prices, scores or triages inside a regulated firm has to answer where its training data came from, who approved that use, which customers may be included and how an outcome is explained months later. Those are lineage, access control and data quality questions, and no model layer answers them retrospectively. We made that case in data governance for AI; it bites hardest in finance, where model risk management arrived long before generative AI did.
Data platform modernization and the AI roadmap are one programme with two budget lines. The governed platform that makes DORA evidence cheap to produce is the platform that makes an AI use case approvable. If you are weighing the sequence for your own estate, talk to our data platform engineers about a reporting-flow inventory before committing to a target architecture.
Frequently Asked Questions
Does DORA require replacing legacy data systems?
No. Regulation (EU) 2022/2554 sets obligations for ICT risk management, incident reporting, resilience testing and third-party risk, and it names no technology. A legacy estate can meet them, provided it produces the evidence on demand and inside the reporting deadlines. Modernization is how institutions make that evidence cheap and repeatable.
How long does data platform modernization take in a regulated firm?
Scope follows the number of reporting flows, not the volume of data. A single domain with one supervisory return behind it commonly moves in a quarter or two, much of that parallel running. A full estate across several banking or insurance lines is a multi-year programme, tracked by domains cut over instead of percentage complete.
Should a fintech choose a lakehouse or a classic data warehouse?
Match the choice to the workload. Streaming payment or claims events, semi-structured documents and model training data favour a lakehouse; a stable set of SQL reporting and actuarial models runs cheaply on a managed warehouse. Either way, hold the data in an open storage format so the engine can change later without another migration.
How do you keep regulatory reporting running during migration?
Run both platforms in parallel for a full reporting cycle, reconcile the figures to a tolerance agreed with the person who signs the return, and cut over one domain at a time outside its reporting window. Keep the old platform able to produce a submission until the new one has completed a cycle unaided. Reporting flows belong in the first phase of the plan, not in final testing.
.webp)
