Data Mesh vs. Centralized Data Lake

When a banking group operates across multiple subsidiaries and jurisdictions, "where does the data live" stops being an infrastructure question and becomes an organizational one. I've built both centralized data platforms and domain-oriented ones for banking clients, and the honest answer is that the architecture diagram is the easy part. The hard part is deciding who owns what, and how far you're willing to let governance bend to accommodate local regulatory reality. 

The Centralized Data Lake: One Model, One Set of Rules 

The centralized lake is the default most engineering teams reach for first, and for good reason. One ingestion layer, one schema registry, one access control model, one place for auditors to look. For a single-entity bank operating in a single jurisdiction, this is close to optimal. 

The trouble starts when a second subsidiary joins the picture — especially one operating under a different regulator, a different data residency requirement, or a different core banking platform. In practice, I've seen this play out as a Java-based ingestion pipeline that started clean and became a maze of jurisdiction-specific branching logic: conditional transformations for GDPR versus a non-EU subsidiary's local privacy law, separate retention policies encoded as configuration flags scattered across the codebase, and access control lists that grew from role-based to a tangle of exceptions. 

The technical debt here is real, but the deeper problem is organizational. A central data engineering team becomes the bottleneck for every subsidiary's reporting requirement, every new product launch, every regulatory change. Ownership of data quality gets diffuse — the central team doesn't understand the semantics of a Polish subsidiary's loan origination data as well as the team that built the system, but they're the ones responsible for the pipeline that moves it. 

Data Mesh: Distributing Ownership, Not Just Compute 

Data mesh proposes something structurally different: each subsidiary (or business domain) owns its data as a product, exposes it through well-defined interfaces, and is accountable for its quality and documentation. The platform team's job shifts from owning pipelines to owning the self-service infrastructure that lets domain teams build and expose their own data products responsibly. 

From an implementation standpoint, this means domain teams — say, the team responsible for the Romanian subsidiary's payments data — own their own service layer, define their own schemas, and publish data products with documented contracts. If you're working in Java, this typically means each domain exposes data through a service with a clearly versioned API and schema (Avro or Protobuf work well here), rather than dumping raw tables into a shared lake for someone else to interpret. 

The governance model changes accordingly. Instead of one team enforcing one set of rules across every jurisdiction, you get federated computational governance: global standards (encryption at rest, audit logging, PII classification taxonomy) enforced consistently through shared libraries and platform tooling, while domain-specific rules (what counts as sensitive data under a given jurisdiction's law, retention periods, consent models) are implemented by the teams closest to that regulatory context. In my experience, encoding the global standards as a shared Java library that every domain service depends on is far more maintainable than trying to encode every jurisdiction's exceptions into one central pipeline. 

The Governance Trade-off 

This is where the real decision lives. Centralization gives you a single, auditable source of truth — which matters enormously when a regulator or an internal audit function wants to trace how a number was calculated. A mesh architecture makes that traceability harder by default: you now need lineage tracking across independently-owned data products, and you need every domain team to actually meet the platform's contract standards, not just claim to. 

For a banking group where subsidiaries operate under materially different regulatory regimes — think a group with entities under both EU frameworks like GDPR and DORA, and a non-EU jurisdiction with its own banking secrecy or data localization rules — a purely centralized model forces awkward compromises. Either the central pipeline becomes the accumulation point for every jurisdiction's special case, or the group ends up building shadow pipelines per subsidiary anyway, which defeats the purpose of centralizing in the first place. I've watched this happen: a "centralized" lake that, three years in, had effectively re-fragmented into subsidiary-specific ingestion paths, just without the ownership clarity a mesh would have given it from the start. 

The Latency Trade-off 

Latency considerations often get less attention than governance in these discussions, but they matter operationally. A centralized lake typically batches or streams data into one location before it's queryable — which introduces a lag between an event occurring at a subsidiary and that event being visible group-wide. For regulatory reporting with daily or weekly cadences, this is fine. For fraud detection or liquidity monitoring across entities, it can be a real problem. 

A mesh architecture, when domain data products are exposed as real-time APIs or event streams rather than batch exports, can reduce this lag — a group-level fraud detection service can query or subscribe to each subsidiary's payments data product directly, rather than waiting for a nightly batch job. The trade-off is consistency: querying five independently-owned, independently-versioned data products in real time is harder to reason about than querying one well-modeled central schema, and Java teams building these consumers need to handle schema evolution and version compatibility carefully — this is a real engineering cost, not a footnote. 

What Actually Determines the Right Fit 

In practice, the decision comes down to a few concrete factors: How many distinct regulatory regimes does the group actually operate under? A group with two EU subsidiaries under near-identical frameworks has much less pressure toward a mesh than one spanning EU and non-EU jurisdictions. How mature and how large are the subsidiary engineering teams? Data mesh only works if domain teams are capable of owning a data product end-to-end — for a subsidiary with a two-person engineering team, that ownership model is unrealistic, and a centralized approach with subsidiary-specific configuration may genuinely be the better answer. 

There isn't a universally correct answer here, and any partner who claims otherwise without understanding your group's regulatory footprint and team structure is giving you a template, not an assessment. The right starting point is an honest inventory of where your governance requirements genuinely diverge across entities, and where they don't — because the answer to that question, more than any architectural preference, is what should decide this.