How do you scale data ownership across 100 teams without descending into chaos? Monzo, the UK-based digital bank, has cracked that code. They recently rebuilt their data platform, moving away from a centralized model toward what they call a “meshy” approach. The early results are staggering: a roughly 40% cut in warehouse costs and a 25% improvement in data delivery speed. The secret lies in their specific implementation of a governed data mesh. Let’s break down the five distinct strategies they used to pull this off.
The Three Principles That Guide Monzo’s Governed Data Mesh
Before writing a single line of dbt code, Monzo’s analytics engineers established a clear philosophical foundation. Antonia Badarau, Irina Mugford, and Massimo Frangiamore defined three core principles that now anchor their entire architecture. First, enforce clear standards across the board. Second, formalize data sharing through explicit interfaces. Third, rely on automation and CI checks rather than manual reviews.
These ideas are the bedrock of their entire platform. Many companies claim to value standards, but Monzo wired them directly into their CI pipeline. Mateusz Ulas, founder of Expeditious Software, observed that “treating data interfaces as first-class code is still weirdly rare.” Most organizations rely on documentation and hope. Monzo decided to automate governance at every step.
This foundation directly supports a governed data mesh, where distributed ownership teams can operate independently without sacrificing quality. Let’s look at the specific mechanisms they built on top of this foundation.
Secret Number 1: A Four-Layer Data Architecture Blueprint
Monzo structured its data into four distinct modeling layers. This is the concrete blueprint that any team can study and adapt. It creates clear boundaries and reduces redundant recomputation across the warehouse.
Automated Landing Models
Raw events are flattened automatically at this level. The goal is low latency and high volume ingestion. Teams do not transform data here; they simply capture it in a structured format.
Generated Normalized Models
Entities are represented with full history at this stage. Critically, these models are generated automatically via a tool called Modelgen. This removes human error from the normalization process and ensures consistency across the 12,000-plus dbt models in the warehouse.
Logical Models
Business logic is applied in this layer. Teams combine entities from the normalized layer to create meaningful business concepts. This is where the real analytical value begins to take shape.
Presentation Models
These models are tailored specifically for downstream use cases. Dashboards, reports, APIs, and machine learning pipelines consume data from this layer. The separation ensures that changes to raw structures do not break end-user facing queries.
This layered architecture is a core component of their governed data mesh. It provides a clear home for every dataset and prevents the chaotic sprawl that often plagues large dbt projects.
Secret Number 2: Modelgen – Automating Model Creation
Imagine a data engineer who sees team-owned models growing chaotically. They need a governance template that scales. Monzo built exactly that with Modelgen, an internal command-line tool.
Modelgen generates SQL and YAML models from a simple object definition. It enforces naming conventions, documentation requirements, and metadata fields automatically. No more guessing games about what a model contains or who owns it. The tool bakes governance into the creation process itself.
This is a direct solution to the chaos of thousands of manually written dbt models. When every model is generated from the same template, consistency becomes automatic. Teams gain autonomy because the tool handles the boilerplate. They can focus on business logic instead of infrastructure plumbing.
The tool also supports the governed data mesh by ensuring that every new model meets minimum quality standards from day one. There is no period of “cleaning up later” because the standards are enforced at generation time.
Secret Number 3: CI-Enforced Validation Checks for Every Model
Monzo requires every single model to pass a battery of automated checks before it can be merged. This is where the rubber meets the road for quality assurance. Luke Briscoe, Engineering Director at Monzo, noted that “scaling data in any fast-growing organisation isn’t easy, never mind a bank.”
What Does the CI Pipeline Check Exactly?
Each model must define a unique key. It must include freshness tests that validate data recency. Models must run incrementally by default rather than performing full refreshes. Each model must declare an owning team. Documentation must be complete. Naming conventions must follow strict patterns. Metadata conventions are validated automatically.
You may also enjoy reading: Apache Kafka Engine: 7 Beginner Tips.
These checks answer a critical question: “What automated CI checks should I implement for data model changes?” The answer is comprehensive and specific. By automating these checks, Monzo removed the bottleneck of manual code review. Teams can ship changes quickly because the machine verifies quality.
This mechanism is essential for any governed data mesh. It provides the centralized quality standard that enables distributed ownership. Teams know that if their model passes CI, it meets the organizational standard.
Secret Number 4: Formalized Cross-Team Data Interfaces
Breaking changes are the number one fear for teams moving to a mesh architecture. Monzo solved this with explicit interface models. Instead of teams directly querying each other’s raw models, they must use declared interfaces.
How can explicit interfaces prevent breaking changes in cross-team data dependencies? Monzo’s approach treats interfaces as contracts. Changes to internal models do not break downstream consumers as long as the interface contract is honored. This reduces redundant queries and prevents the dependency hell that plagues many decentralized data systems.
The migration introduced hundreds of these governed interfaces across the warehouse. They act as clear boundaries between domains. Teams can evolve their internal models freely without fear of breaking someone else’s dashboard or report.
This formalization is a hallmark of a mature governed data mesh. It moves data sharing from a “hope it works” model to a “contractually guaranteed” model.
Secret Number 5: Distributed Ownership with Centralized Guardrails
This is the final piece of the puzzle. Each of Monzo’s over 100 teams owns and maintains its own data models. However, this ownership is not absolute. It is supported by the automated guardrails we have discussed.
Consider someone leading a data platform team that is moving from a monolithic warehouse to a mesh architecture. The interplay between ownership and control is the defining characteristic of a successful governed data mesh. Monzo balances these forces beautifully. Teams have autonomy over their domain, but they must operate within the established framework of standards, interfaces, and CI checks.
The initial results speak volumes. Monzo is roughly 30 percent through a company-wide migration to these approaches. Even at this early stage, they have seen about a 40 percent reduction in warehouse costs and roughly 25 percent faster landing times in some domains. They reversed warehouse cost growth even as the number of models and teams exploded.
Suhail Patel presented at QCon London about Monzo’s developer platform, which ships hundreds of changes to production every day. This velocity is possible because the guardrails are automated. Teams trust the system because the system enforces quality.
Monzo’s journey is a masterclass in balancing autonomy with governance. By treating infrastructure as code and interfaces as contracts, they have built a data system that can scale with their ambitions. The roadmap is still long, but the foundation is solid. For any organization looking to implement a governed data mesh, Monzo’s five secrets provide a valuable, actionable blueprint.
