Wie JPMorgan Chase Data Contracts über 50+ Domains hinweg aufgebaut hat

2022 arbeitete JPMorgan Chase mit mehr als 50 eigenständigen Data Domains, von Retail Banking und Kreditkartenabwicklung bis zu Trading, Custody und Asset Management. Jede Domain hatte eigene Pipelines, Definitionen und informelle Absprachen zur Datenqualität angesammelt. Die Folge weiter unten in der Kette war absehbar: Ein Datenteam im Risikomanagement nutzte einen Datensatz aus dem Privatkundengeschäft und stellte Monate später fest, dass eine Felddefinition stillschweigend geändert worden war. Kein Contract regelte den Austausch. Kein Owner war verantwortlich. Solche Vorfälle kosteten die Engineering-Teams erhebliche Zeit für Nacharbeit und führten, materiell gewichtiger, zu Inkonsistenzen im regulatorischen Reporting, und das zu einem Zeitpunkt, an dem OCC und Fed ihre Erwartungen an 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.Vollständige Definition ansehen → und Auditierbarkeit verschärften.

Die damalige Chief Data and Analytics Officer der Bank, Teresa Heitsenrether, hatte in internen und externen Foren deutlich gemacht, dass Datenqualität in erster Linie kein Technologieproblem ist. Es ist ein Problem von Governance und Accountability. Diese Einordnung prägte alles Weitere.

Was JPMorgan Chase konkret getan hat

Die Bank formalisierte ein Data-Contract-Framework auf drei Ebenen: Domain Ownership, Spezifikation der Data Products und Service-Level-Agreements zwischen Produzenten und Konsumenten.

Auf Domain-Ebene wurde jeder der über 50 Domains ein namentlich benannter Executive Data Owner zugewiesen, typischerweise ein Managing Director mit P&L-Verantwortung für die jeweilige Geschäftslinie. Das war keine symbolische Ernennung. Die Owner mussten die kritischen Datenelemente ihrer Domain quartalsweise zertifizieren, ein Prozess, der direkt an die breitere Datenqualitäts-Scorecard der Bank gekoppelt war, die das Chief Data Office prüfte. Fielen die Qualitätswerte einer Domain unter den Schwellenwert, wirkte sich das auf die Ergebnisse des Operational Review des Owners aus.

Der Data Contract selbst war in der Lesart von JPMorgan eine strukturierte Vereinbarung zwischen einem produzierenden Team und jedem konsumierenden Team weiter unten in der Kette. Jeder Contract legte fest: das bei Abschluss gültige SchemaSchemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.Vollständige Definition ansehen → und die Felddefinitionen, die erwartete Refresh-Kadenz und Latenz, das SLA für Qualität (Vollständigkeit, Eindeutigkeit, Aktualität, gemessen an definierten Schwellenwerten), ein Versionierungsprotokoll mit 30 Tagen Vorlaufzeit vor jeder Breaking Change am Schema und einen Eskalationspfad, falls der Produzent die Bedingungen nicht erfüllte. Die Contracts lagen im internen 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.Vollständige Definition ansehen → der Bank, aufgebaut aus einer Kombination von Eigenentwicklungen und, auf verschiedenen Ebenen, Komponenten von Anbietern wie Collibra (ein Anbieter von Data-Governance-Software, Hinweis erforderlich: Collibra hat ein kommerzielles Interesse daran, diese Tooling-Kategorie als unverzichtbar zu positionieren).

Für Data Products, die über mehr als drei Domains hinweg genutzt wurden, führte die Bank eine Rolle „Data ProductData ProductA data asset managed like a product, with an owner, defined users, guaranteed quality, and measurable business value.Vollständige Definition ansehen → Owner“ ein, getrennt vom Executive Owner der Domain. Diese Person, typischerweise ein Senior Data Engineer oder Data Architect, war für die operative Gesundheit dieses spezifischen Produkts verantwortlich: Monitoring der SLA-Einhaltung, Pflege des Versionierungskalenders und Triage der von Konsumenten gemeldeten Probleme. Die Trennung von Executive Accountability und operativer Accountability war eine bewusste Entscheidung, um den Fehlermodus zu vermeiden, bei dem Senior Owner formal verantwortlich, praktisch aber nicht erreichbar sind, wenn um 2 Uhr nachts etwas ausfällt.

Die Bank investierte außerdem in Tooling, um die Überwachung der Contract-Einhaltung zu automatisieren. Statt sich darauf zu verlassen, dass Konsumenten Verstöße manuell melden, wurden Pipelines so instrumentiert, dass eingehende Daten bereits bei der Ingestion gegen das vertraglich vereinbarte Schema und die Qualitätsschwellen geprüft wurden. Verstöße lösten Alerts an den Data Product Owner des Produzenten und den Data StewardData StewardA business-side owner responsible for the quality, consistency and appropriate use of data in their domain.Vollständige Definition ansehen → des konsumierenden Teams aus, mit einem Lösungs-SLA von 48 Stunden vor Eskalation.

Die Ergebnisse, mit den nötigen Einschränkungen

JPMorgan hat keine detaillierte Vorher-Nachher-Studie zu diesem Programm veröffentlicht. Die folgenden Zahlen stammen daher aus Aussagen in Branchenforen und sind als Richtungsangaben zu behandeln, nicht als geprüfte Werte.

Teresa Heitsenrether und andere Senior Data Leader der Bank haben von einem deutlichen Rückgang der Datenvorfälle gesprochen, die bis zur Führungsebene eskalieren, zurückgeführt teils auf schnellere Erkennung, teils auf klarere Ownership. Branchenbeobachter, darunter Kommentare der Data Management Association (DAMA), führten den Ansatz von JPMorgan als eine der operativ ausgereifteren Umsetzungen domänenbasierter Data Ownership an, die man in Financial Services in den Jahren 2023-2024 gesehen hat.

Dokumentiert ist das regulatorische Ergebnis: Die Meldungen von JPMorgan unter den Datenanforderungen von Basel IV und die BCBS-239-Compliance-Position verbesserten sich in diesem Zeitraum messbar, und die externe Korrespondenz mit den Aufsichtsbehörden weist weniger Feststellungen zur Datenqualität aus als in früheren Prüfzyklen. Dieser Zusammenhang ist plausibel, aber keine saubere Kausalaussage, weil die Bank viele Governance-Investitionen parallel getätigt hat.

Die interne Schätzung, zitiert aus einer internen Datenstrategie-Präsentation von 2023, die teilweise auf einer Branchenkonferenz geteilt wurde, lautete: Die Kosten für Nacharbeit infolge von Datenqualitätsvorfällen in den Funktionen Risk und Finance sanken in den 18 Monaten nach dem Rollout des Contract-Frameworks um rund 30 Prozent. Behandeln Sie diese Zahl als selbst berichtet und ungeprüft.

Was übertragbar ist und wo sich Ihr Kontext unterscheidet

Der Kernmechanismus, der sich verallgemeinern lässt, ist die Trennung von drei Accountability-Ebenen: Executive Domain Ownership für Zertifizierung und Eskalationsbefugnis, Data Product Ownership für die operative Gesundheit und vertragliche SLAs, die den Austausch zwischen Produzent und Konsument regeln. Die meisten Organisationen werfen das in einer einzigen Rolle „Data Steward“ zusammen, die am Ende zu diffus ist, um zu wirken.

Die 30-tägige Vorlaufzeit für Breaking Changes am Schema lässt sich unmittelbar übernehmen. Schema-Änderungen ohne Vorankündigung sind die häufigste einzelne Ursache für PipelinePipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.Vollständige Definition ansehen →-Ausfälle in Organisationen mit mehreren datenkonsumierenden Teams. Eine einfache vertragliche Zusage, kulturell und technisch durchgesetzt, beseitigt die meisten davon.

Zwei Punkte, an denen der Kontext von JPMorgan nicht zu Ihrem passen muss. Erstens hatte die Bank regulatorischen Druck als treibende Kraft. Fehlt Ihrer Organisation ein vergleichbares externes Mandat, müssen Sie eine interne Konsequenzstruktur schaffen, also die Contract-Einhaltung an die Performance Reviews der Engineering-Teams oder an die Freigabe von Produkt-Roadmaps koppeln, um die gleiche Verhaltensänderung zu erreichen. Zweitens konnte JPMorgan Engineering-Kapazität dafür bereitstellen, das Contract-Monitoring zu automatisieren. Kleinere Organisationen müssen vielleicht mit manuellen Review-Zyklen und einem schlanken Contract-Register in einem gemeinsamen Dokument starten, bevor sie in Catalog-Tooling investieren.

Die Reihenfolge, die JPMorgan gewählt hat, lohnt das Kopieren: zuerst namentliche Executive Owner benennen, dann Contracts nur für die Data Products mit dem höchsten Traffic definieren (nicht für jeden Datensatz), und Monitoring-Automatisierung erst aufbauen, wenn die Vertragssprache stabil ist. Governance zu automatisieren, bevor das Ownership-Modell abgestimmt ist, erzeugt instrumentiertes Chaos statt Disziplin.

Data Contracts funktionieren, weil sie eine implizite soziale Vereinbarung, nämlich dass ein Team Daten nicht stillschweigend ändert, von denen ein anderes Team abhängt, in eine explizite, nachverfolgbare Zusage überführen. Die Technologie zählt weit weniger als die Entscheidung, Accountability sichtbar und folgenreich zu machen.