Data mesh represents a fundamental shift in how large organisations think about data ownership. Where the centralised data warehouse model concentrated data ingestion, transformation, and governance in a single platform team, data mesh distributes that responsibility to the domain teams that understand their data best. The central platform team provides the infrastructure on which domain teams build their products, and enforces the computational governance standards that all products must meet.
Why Regulated Firms Struggle with Data Mesh
The data mesh model challenges regulated organisations at a structural level. BCBS 239 holds banks to central accountability for risk data aggregation. HIPAA's covered entity structure places accountability for PHI protection with the organisation as a whole. SOX ITGC requires that changes to financially significant systems go through centralised change management review. These regulatory structures were designed for centralised IT governance models. Implementing data mesh without addressing the regulatory accountability mismatch creates compliance exposure even when the technical architecture is correct.
The resolution is federated computational governance: a governance model where the platform enforces standards automatically rather than a central team enforcing them manually. The platform requires that every data product registers in the data catalog, passes automated data quality checks at deployment, carries mandatory metadata, and implements access controls according to the platform's security model before it can be used by other domains. The domain team retains ownership; the platform enforces accountability. This is an organisational contract that must be established before domain teams start building data products.
The Data Product Contract for Regulated Domains
A data product in a regulated data mesh must satisfy a richer contract than in an unregulated environment. Healthcare data products must declare their PHI content, their BAA coverage, and their minimum necessary access justification. Financial data products must declare their BCBS 239 data criticality classification and their lineage to source systems. Any data product carrying personal data under GDPR must declare its lawful basis for processing and its retention period.
These declarations are not documentation for human review. They are machine-readable metadata registered in the data catalog and evaluated by the platform's automated governance checks at deployment time. A domain team that attempts to publish a data product containing PHI without the required BAA coverage metadata receives a platform-level rejection, not a finding in the next audit cycle. The shift from detective to preventive governance is the key benefit of computational governance for regulated firms.
Lineage Across Domain Boundaries
Data lineage in a data mesh requires tracing transformation paths that cross domain boundaries. A credit risk model data product in the risk domain may consume a loan origination data product from the lending domain, which was itself built from raw transaction data ingested by the operations domain. BCBS 239 Principle 2 requires that this lineage be traceable end-to-end. OpenLineage, the open standard for data lineage metadata, provides the protocol for emitting lineage events from each transformation step regardless of which domain team built it and which tooling they used.
The regulated firm implementing data mesh must require OpenLineage instrumentation as part of the data product contract. A data product that cannot emit OpenLineage events fails the platform's governance check. This creates an incentive for domain teams to choose tooling that supports OpenLineage natively rather than requiring custom integration work.
Access Control Federation
In a centralised data warehouse, access control is implemented and audited in a single place. In a data mesh, access control is federated. Each domain team implements access controls for their data products, using the platform's security primitives. For regulated data, this federation creates audit complexity: demonstrating that access to PHI or personally identifying financial data is appropriately controlled requires inspecting access policies across every domain.
The solution is a centralised policy registry that domain teams write to and auditors read from. Every access policy is registered centrally, even if the enforcement is distributed. The platform enforces that no data product is accessible without a registered access policy, and the central registry provides the audit surface that a HIPAA privacy officer or SOX auditor needs. Apache Ranger, OPA with a central policy store, or Databricks Unity Catalog with multi-workspace governance all implement variants of this pattern.
Organisational Prerequisites
Data mesh governance in regulated firms fails more often at the organisational level than the technical level. Domain teams that lack data engineering skills cannot build and operate data products to the platform standard. Domain data owners who lack governance training cannot make the classification and access control decisions the platform requires from them. The central platform team must invest in domain team enablement: embedded data engineering support during initial data product build cycles, governance training for data owners, and clear escalation paths for classification decisions that domain teams cannot make unilaterally. The regulated data mesh is an organisational transformation with a technology implementation attached.
The engineering behind this article is available as a service.
We have done this work — not advised on it, not reviewed documentation about it. If the problem in this article is your problem, the first call is with a senior engineer who has solved it.