The central data warehouse was never primarily a technology decision. It was an organisational decision: one team owns all the data, controls all the schemas, builds all the pipelines, and becomes the bottleneck for every data access request from every other team. In a bank, that team is the data integration group. They know the data structures deeply; they know almost nothing about the business rules that make the data meaningful. The payments team does. The accounts team does. The KYC team does. They just cannot get to their own data without raising a ticket.
A data mesh is the decision to reverse that model. The payments team owns the payments data product. They define what a PaymentSettled event means, which fields it carries, and what the SLA is for consumers who depend on it. They own the schema. They own the on-call. They are accountable when downstream consumers break because the schema changed without notice. The shift is not technological — the technology is Kafka topics and Avro schemas, which both architectures use — it is a question of who has the authority, the accountability, and the budget to maintain the data contract.
The reason most data mesh programmes in financial services fail is not that the technology is wrong. It is that the organisation migrated the labels without migrating the accountability. The integration team was renamed “platform team.” The domain teams were told they now own their data. Nobody changed the on-call rotation, the schema review process, the data quality SLA, or the budget for the engineers who would maintain the producers. A data mesh without transferred accountability is a central integration hub with a different marketing message.
The regulatory angle
In a Saudi bank regulated by SAMA and subject to the Personal Data Protection Law, a data mesh has a regulatory dimension that does not exist in an unregulated organisation. In the central integration model, the data integration team is the data processor for most customer data flows: they move the data, they classify it, they enforce the retention policies. In a data mesh, every domain team that publishes a data product containing personal data becomes a data controller under PDPL. They are not just processing the data on behalf of a central function; they are making decisions about how the data is collected, what it is used for, who can access it, and how long it is retained.
SAMA’s data residency requirements do not become more complex in a data mesh; they become more distributed. In the central model, you enforce residency once: all data stays within the integration platform, which runs on Saudi infrastructure. In a data mesh, every domain team that publishes a Kafka topic must understand that the topic must reside on Saudi infrastructure, that the Schema Registry that validates the schema must reside on Saudi infrastructure, and that consumer ACL grants to applications outside the regulatory perimeter are prohibited without SAMA approval. Enforcement cannot rely on the domain teams remembering this individually. It must be built into the mesh platform: topic creation policies that reject non-compliant configurations, automated ACL auditing that flags cross-perimeter grants, and schema validation that enforces PDPL classification metadata in every Avro schema.
Federated governance in a regulated context does not mean every domain team governs independently. It means governance is enforced by the platform, so domain teams cannot publish non-compliant data products even accidentally.
The examination implication is significant. If SAMA requests a data lineage trace for a specific customer’s data — which teams touched it, which systems processed it, which consumers received it — the central integration model produces a single audit trail from a single team. The data mesh must produce an equivalent audit trail assembled from the access logs, consumer ACL records, and schema registry subjects across multiple domain teams. That audit capability must be built before the first production data product goes live, not retrofitted when the examination request arrives.
The business trade-off
A well-executed data mesh accelerates cross-domain data sharing. The payments team can publish a PaymentSettled event and the fraud detection team can consume it within milliseconds, without a change request to the integration team, without a six-week pipeline build, and without a schema negotiated between two teams that neither of them understands as well as the payments team does. The open banking programme can access account balance data in near-real-time without a batch extract job. The analyst who needs to join payment and customer data can do so by subscribing to two topics that are already production-quality, rather than requesting two separate warehouse extracts and joining them in Excel.
The same shift that creates that acceleration also creates a new category of operational risk. In the central integration model, a breaking schema change requires a change request to the integration team, which reviews the downstream impact and coordinates the migration. In a data mesh, the payments team can publish a new schema version directly. If they remove a field without following the deprecation process, every consumer that relied on that field silently starts receiving incomplete data. At scale, the number of consumers of a mature data product can be dozens. A single schema change that bypasses the deprecation window does not break one downstream system; it breaks all of them simultaneously.
This is not an argument against data mesh. It is an argument that the schema governance and deprecation policy is not a technical nicety — it is a business continuity control. A data mesh that enforces schema BACKWARD compatibility through the Schema Registry, that requires a documented deprecation period before removing any field, and that notifies all registered consumers before a breaking change is published, provides the acceleration without the fragility. A data mesh that treats schema governance as bureaucracy to be minimised will eventually produce a major incident when the fifteenth consumer of a critical data product breaks simultaneously.
What leadership must own
Four specific commitments are required before a data mesh programme can succeed in a regulated bank, and all four must come from executive leadership, not from the platform team.
The first is domain ownership mapping. Before the first Kafka topic is created, there must be a documented decision about which team owns each domain, which data products that domain is accountable for, and which leader is personally accountable for the data quality SLA of that domain’s products. “The payments team owns payments data” is not a sufficient decision. The accountability must be named to a specific VP or department head who will be responsible when a SAMA examination asks about data quality in the payments domain.
The second is data product SLA accountability. Every data product has a freshness SLA (how quickly a source event becomes a domain event), a completeness SLA (what fraction of source events produce a published event), and a schema validity SLA (what fraction of published messages conform to the registered schema). These SLAs must be formally adopted by the domain team, monitored on a platform dashboard, and reportable to governance on a monthly basis. A domain team that has never agreed to an SLA has no accountability for meeting one.
The third is federated governance budget. The governance function in a data mesh is not a rubber stamp. It maintains the data product catalogue, audits consumer ACL grants, enforces PDPL classification in schemas, manages the SAMA residency compliance posture across all topics, and reviews the data lineage audit trail. This is a non-trivial ongoing function. If the governance budget does not exist as a separate line item, it will be absorbed by the platform team, which already has too many competing priorities, and governance will be the first thing to slip.
The fourth is data mesh platform team investment. The promise of self-serve infrastructure is that domain teams can publish data products without platform team involvement. The reality is that self-serve infrastructure must be built first. The Kafka cluster, the Schema Registry, the ACL management tooling, the data product catalogue, the producer and consumer libraries, the monitoring dashboards, and the governance automation — all of this is platform infrastructure that must exist and be maintained before any domain team can self-serve against it. The platform team that builds and operates this infrastructure is not a cost centre. It is the foundation that makes the entire model economically viable. Under-investing in it produces the worst possible outcome: a data mesh that promises domain autonomy and delivers neither the autonomy nor the governance.
For the engineering depth behind these decisions — domain decomposition, Avro schema contracts, Kafka ACL configuration, Kafka Streams cross-domain joins, Flink SQL for multi-domain aggregation, PDPL classification in schema metadata, and the SAMA data residency implementation — see the companion Lab article: Data Synchronisation: Event-Driven Data Mesh Patterns.