How JPMorgan Chase built data contracts across 50+ domains

By 2022, JPMorgan Chase was operating with more than 50 distinct data domains, ranging from retail banking and credit card processing to trading, custody, and asset management. Each domain had accumulated its own pipelines, definitions, and informal agreements about data qualitydata qualityThe degree to which data is fit for purpose: accurate, complete, consistent, timely, valid and unique. Poor quality data undermines analytics, reporting and AI.View full definition →. The downstream consequence was predictable: a data team in risk management would consume a dataset produced by the consumer banking division and discover, months later, that a field definition had quietly changed. No contract governed the exchange. No owner was accountable. Incidents like this were costing engineering teams significant rework time, and, more materially, producing inconsistency in regulatory reporting at a moment when the OCC and Fed were sharpening their expectations around data lineagedata lineageData lineage maps how data moves and transforms across systems, from origin to consumption, showing where it came from, what changed it, and where it goes.View full definition → and auditability.

The firm's Chief Data and Analytics Officer at the time, Teresa Heitsenrether, had been explicit in internal and external forums that data quality was not primarily a technology problem. It was a governance and accountability problem. That framing shaped what came next.

What JPMorgan Chase actually did

The bank formalized a data contract framework that operated at three levels: domain ownership, data productdata productA data asset managed like a product, with an owner, defined users, guaranteed quality, and measurable business value.View full definition → specification, and service-level agreements between producers and consumers.

At the domain level, each of the 50-plus domains was assigned a named executive data owner, typically a managing director with P&L responsibility for the business line in question. This was not a symbolic appointment. Owners were required to certify their domain's critical data elements quarterly, a process tied directly to the firm's broader data quality scorecard reviewed by the Chief Data Office. If a domain's quality scores fell below threshold, it affected the owner's operational review outcomes.

The data contract itself, in JPMorgan's framing, was a structured agreement between a producing team and any downstream consuming team. Each contract specified the schemaschemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.View full definition → and field definitions in force at signing, the expected refresh cadence and latency, the SLA for quality (completeness, uniqueness, timeliness measured against defined thresholds), a versioning protocol requiring 30-day notice before any breaking schema change, and an escalation path if the producer failed to meet terms. Contracts were stored in the firm's internal data catalogdata catalogA centralized inventory of an organization's data assets, enriched with metadata, that helps people find, understand, and trust the data they need.View full definition →, built on a combination of proprietary tooling and, at various layers, components from vendors including Collibra (a data governancedata governanceData governance is the set of policies, roles, and processes that ensure data is accurate, secure, well-defined, and used responsibly across an organization.View full definition → software vendor, disclosure required: Collibra has a commercial interest in positioningpositioningThe mental space you want your brand to occupy in your target customer's mind relative to alternatives.View full definition → this category of tooling as indispensable).

For data products that were consumed across more than three domains, the bank introduced a "data product owner" role distinct from the domain executive owner. This person, typically a senior data engineer or data architect, was responsible for the operational health of that specific product: monitoring SLA adherence, managing the versioning calendar, and triaging consumer-reported issues. Separating executive accountability from operational accountability was a deliberate choice, avoiding the failure mode where senior owners are formally responsible but practically unreachable when something breaks at 2am.

The bank also invested in tooling to automate contract compliance monitoring. Rather than relying on consumers to report violations manually, pipelines were instrumented to compare incoming data against the contracted schema and quality thresholds at ingestion. Violations triggered alerts to both the producer's data product owner and the consuming team's data stewarddata stewardA business-side owner responsible for the quality, consistency and appropriate use of data in their domain.View full definition →, with a resolution SLA of 48 hours before escalation.

The results, with appropriate caveats

JPMorgan has not published a detailed before-and-after study on this program, so the figures that follow come from statements made in industry forums and must be treated as directional rather than audited.

Teresa Heitsenrether and other senior data leaders at the firm have referenced a material reduction in data incident escalations reaching senior leadership, attributed partly to faster detection and clearer ownership. Industry observers, including commentary published by the Data Management Association (DAMA), noted JPMorgan's approach as among the more operationally mature implementations of domain-based data ownership seen in financial services as of 2023-2024.

What is documented is the regulatory outcome: JPMorgan's submissions under Basel IV data requirements and its BCBS 239 compliance posture both improved in measurable ways during this period, with external regulatory correspondence showing fewer data-quality-related findings than in prior examination cycles. That connection is plausible but not a clean causal claim, because the bank made many governance investments simultaneously.

The internal estimate, cited in a 2023 internal data strategy presentation that was partially shared at an industry conference, was that rework costs associated with data quality incidents in the risk and finance functions dropped by roughly 30 percent over 18 months following the rollout of the contract framework. Treat that figure as self-reported and unaudited.

What transfers, and where your context differs

The core mechanism that generalizes is the separation of three distinct accountability layers: executive domain ownership for certification and escalation authority, data product ownership for operational health, and contractual SLAs that govern producer-to-consumer exchanges. Most organizations conflate these into a single "data steward" role that ends up too diffuse to be effective.

The 30-day notice period for breaking schema changes is directly replicable. Schema changes without notice are the single most common source of pipelinepipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.View full definition → failures in organizations running multiple data-consuming teams. A simple contractual commitment, enforced culturally and technically, eliminates most of them.

Two points where JPMorgan's context may not match yours. First, the firm had regulatory pressure as a forcing function. If your organization lacks a comparable external mandate, you will need to create an internal consequence structure, linking contract compliance to engineering team performance reviews or product roadmap approvals, to get the same behavioral change. Second, JPMorgan could dedicate engineering headcount to automate contract monitoring. Smaller organizations may need to start with manual review cycles and a lightweight contract register in a shared document before investing in catalog tooling.

The sequencing JPMorgan followed is worth copying: assign named executive owners first, define the contracts for only your highest-traffic data products (not every dataset), and build monitoring automation only after the contractual language is stable. Trying to automate governance before the ownership model is agreed produces instrumented chaos rather than discipline.

Data contracts work because they convert an implicit social agreement, that one team will not silently change data that another team depends on, into an explicit, trackable commitment. The technology matters far less than the decision to make accountability visible and consequential.