Warum bestehen Datensilos und Qualitätsprobleme trotz Milliardeninvestitionen in Modernisierung weiter?
- Regulatorischer Druck, M&A-Komplexität und Autonomie der Geschäftsbereiche schaffen Silos, die nie vollständig integriert werden.
- Unabhängige Daten-Transformationen führen zu einem fragmentierten Gesamtbild, auch wenn jedes Silo „technisch korrekt“ ist.
- Fortschritt entsteht durch regulatorische Anwendungsfälle als Treiber – zuerst kritische Anforderungen lösen, dann die Infrastruktur wiederverwenden.
- Erfolg braucht föderierte Verantwortung: Fachbereiche sichern ihre Datenqualität, IT integriert, Governance setzt Standards.
- Setzen Sie auf schrittweise Integration – Punkt-zu-Punkt-Mappings mit klaren Regeln statt jahrelanger MDM-Projekte.
- Datenprobleme sind organisatorische Herausforderungen mit technischen Lösungen, nicht nur technische Probleme mit besseren Tools.
- Ziel ist nicht die Eliminierung von Silos, sondern frühes Erkennen und systematische Behebung, bevor Audits oder Strafen drohen.
Trotz Milliarden-Investitionen in die Datenmodernisierung bestehen Datensilos und Qualitätsprobleme in nahezu jedem Finanzinstitut fort. Jeder weiß, dass diese Probleme existieren. Risikoausschüsse diskutieren sie. Prüfer markieren sie. Und dennoch bleiben sie bestehen.
Die Frage ist nicht, ob diese Probleme existieren, sondern warum sie immer wieder auftreten.
Die Grundursachen, die niemand zugeben möchte
Traditionelle Erklärungen machen „Altsysteme" oder „fehlende Data Governance" verantwortlich, aber das verkennt tieferliegende organisatorische Dynamiken.
Datensilos entstehen aus drei strukturellen Gegebenheiten. Erstens schafft regulatorischer Druck sie. Compliance-Teams, die mit knappen BCBS 239- oder Solvency II-Fristen konfrontiert sind, können nicht darauf warten, dass die IT die perfekte Lösung baut, also erstellen sie ihre eigenen Data Marts. Zweitens verschärft M&A-Aktivität das Problem. Übernommene Unternehmen bringen mehrere Systeme mit, die wir „irgendwann migrieren werden". Irgendwann kommt nie. Drittens bedeutet die Autonomie der Geschäftsbereiche, dass verschiedene Abteilungen als Fürstentümer mit eigenen Definitionen grundlegender Konzepte wie „Kunde" operieren.
Datenqualitätsprobleme entstehen aus ähnlichen Dynamiken. Wenn Teams Daten unabhängig extrahieren und ihre eigenen Transformationen anwenden, sind Inkonsistenzen unvermeidlich. Die Daten sind in jedem Silo technisch korrekt, aber die unternehmensweite Sicht ist fragmentiert.
Was tatsächlich funktioniert (Es ist kein weiterer Governance-Ausschuss)
Erfolgreiche Ansätze teilen drei Merkmale:
Beginnen Sie mit regulatorischen Anwendungsfällen als treibende Kraft. Wählen Sie eine risikoreiche Anforderung (z.B. Stresstests, gesetzliche Berichterstattung oder AML-Überwachung) und lösen Sie diese. Diese Anwendungsfälle haben die Unterstützung der Geschäftsleitung und klare Fristen. Sobald Sie die Leitungen für regulatorische Berichterstattung gebaut haben, nutzen Sie sie für Analysen wieder.
Setzen Sie auf föderierte Verantwortlichkeit. Das zentralisierte Modell eines „einzigen Data-Warehouse-Teams" scheitert in komplexen Institutionen. Geschäftsbereiche sollten für ihre Datenqualität verantwortlich sein, IT stellt die Integrationsplattform bereit, und eine schlanke Governance-Funktion setzt Standards und löst Konflikte.
Verfolgen Sie einen inkrementellen Integrationsansatz. Statt dreijähriger MDM-Implementierungen bauen Sie Punkt-zu-Punkt-Integrationen mit klar definierten Verträgen. Bilden Sie Daten von einem System auf ein anderes mit expliziten Regeln ab, dokumentieren Sie es, testen Sie es, und machen Sie dann weiter. Es ist weniger elegant, liefert aber tatsächlich Wert.
Der entscheidende Erfolgsfaktor: Behandeln Sie Datenprobleme als organisatorische Probleme, die technische Lösungen erfordern, nicht als technische Probleme, die bessere Tools benötigen.
Von Reaktion zu Prävention
Die besten Finanzinstitute eliminieren diese Probleme nicht vollständig, sondern sie erkennen sie früh mit systematischen Ansätzen zur Lösung.
Nächste Woche veröffentlichen wir eine praktische Checkliste, die Sie bei der Planung von Datenprojekten in regulierten Umgebungen verwenden können. Sie deckt kritische Fragen rund um Datenherkunft, regulatorische Anforderungen, Stakeholder-Abstimmung und technische Integration ab, die den Projekterfolg bestimmen. Datensilos und Qualitätsprobleme werden immer in gewissem Maße existieren. Das Ziel ist nicht Perfektion. Es geht darum, Mechanismen zu haben, um diese Probleme zu identifizieren und zu lösen, bevor sie zu Prüfungsfeststellungen oder regulatorischen Strafen werden.
Why Data Silos and Data Quality Issues Keep Plaguing Companies (And What Actually Works to Fix Them)
Why do data silos and quality issues persist despite massive investments in modernization?
- Regulatory pressure, M&A complexity, and business unit autonomy create silos that never fully integrate.
- Independent data transformations across teams fracture the enterprise view, even when each silo is “technically correct.”
- Real progress comes from regulatory use cases as forcing functions—solving high-stakes requirements first, then reusing the pipelines.
- Success requires federated ownership: business domains manage their data quality, IT provides integration, governance sets standards.
- Adopt incremental integration—point-to-point mappings with explicit rules—rather than chasing “perfect” multi-year MDM projects.
- Treat data challenges as organizational problems needing technical solutions, not just technical problems needing better tools.
- The goal isn’t eliminating silos, but catching issues early with systematic mechanisms before they trigger audits or penalties.
Despite billions invested in data modernization, data silos and quality problems persist in nearly every financial institution. Everyone knows these issues exist. Risk committees discuss them. Auditors flag them. And yet they continue.
The question isn't whether these problems exist, but why they keep happening.
The Root Causes Nobody Wants to Admit
Traditional explanations blame "legacy systems" or "lack of data governance," but that misses deeper organizational dynamics.
Data silos emerge from three structural realities. First, regulatory pressure creates them. Compliance teams facing tight BCBS 239 or Solvency II deadlines can't wait for IT to build the perfect solution, so they build their own marts. Second, M&A activity compounds the problem. Acquired entities bring multiple systems that "we'll migrate eventually." Eventually never comes. Third, business unit autonomy means different divisions operate as fiefdoms with their own definitions of basic concepts like "customer".
Data quality issues stem from similar dynamics. When teams extract data independently and apply their own transformations, inconsistencies are inevitable. The data is technically correct in each silo, but the enterprise view is fractured.
What Actually Works (It's Not Another Governance Committee)
Successful approaches share three characteristics:
Start with regulatory use cases as forcing functions. Pick one high-stakes requirement(e.g. stress testing, statutory reporting, or AML monitoring) and solve for that. These use cases have executive sponsorship and clear deadlines. Once you've built the pipes for regulatory reporting, reuse them for analytics.
Embrace federated ownership. The centralized "single data warehouse team" model fails in complex institutions. Business domains should own their data quality, IT provides the integration platform, and a lightweight governance function sets standards and resolves conflicts.
Take an incremental integration approach. Instead of three-year MDM implementations, build point-to-point integrations with well-defined contracts. Map data from one system to another with explicit rules, document it, test it, then move on. It's less elegant but actually delivers value.
The critical success factor: treat data issues as organizational problems requiring technical solutions, not technical problems requiring better tools.
From Reaction to Prevention
The best financial institutions don't eliminate these problems entirely, rather they catch them early with systematic approaches to resolution.
Next week, we're releasing a practical checklist that you can use when scoping data projects in regulated environments. It covers critical questions around data lineage, regulatory requirements, stakeholder alignment, and technical integration that determine project success. Data silos and quality issues will always exist to some degree. The goal isn't perfection. It's having mechanisms to identify and resolve these issues before they become audit findings or regulatory penalties.
Quellen / Sources:
- A. Tavakoli, Holger Harreis, Kayvaun Rowshankish, and S. Reddin, “BCBS 239 2.0 resurgence: Strengthening risk management and decision making,” McKinsey & Company, Dec. 06, 2024. https://www.mckinsey.com/capabilities/risk-and-resilience/our-insights/bcbs-239-2-0-resurgence-strengthening-risk-management-and-decision-making
- Deloitte, “BCBS 239: Achieving Compliance and Enhancing Risk Data Aggregation and Reporting”, 2017. Available: https://www2.deloitte.com/content/dam/Deloitte/ie/Documents/Risk/ie-risk-Deloitte-BCBS-239-Article-2017.pdf
- O. Team, “BCBS 239 Compliance Through Practical Data Governance Use Cases,” Ovaledge.com, Apr. 22, 2025. https://www.ovaledge.com/blog/bcbs-239-compliance-via-data-governance
- Wikipedia Contributors, “Data mesh,” Wikipedia, Mar. 07, 2025. https://en.wikipedia.org/wiki/Data_mesh
- R. K. Kanji, “Federated Data Governance Framework for Ensuring Quality-Assured Data Sharing and Integration in Hybrid Cloud-Based Data Warehouse Ecosystems through Advanced ETL/ELT Techniques,” International Journal of Computer Techniques, 2021. Accessed: 2025. [Online]. Available: https://ijctjournal.org/wp-content/uploads/2025/06/Federated-Data-Governance-Framework-for-Hybrid-Cloud-Based-Data-Warehouse-Ecosystems.pdf
- “Data Mesh: Definition, Importance, Key Principles, and Benefits,” Denodo, 2025. https://www.denodo.com/en/glossary/data-mesh-definition-importance-principles-benefits (accessed Nov. 26, 2025).
- J. Caserta, J.-B. Dubois, M. Roggendorf, N. Srinidhi, and M. Roth, “Demystifying data mesh | McKinsey,” www.mckinsey.com, Jun. 08, 2023. https://www.mckinsey.com/capabilities/quantumblack/our-insights/demystifying-data-mesh
- T. van Eijk, I. Kumara, D. Di Nucci, D. A. Tamburri, and W.-J. van den Heuvel, “Architectural Design Decisions for Self-Serve Data Platforms in Data Meshes,” arXiv.org, 2024. https://arxiv.org/abs/2402.04681
- N. Dulam, K. Reddy Gade, and V. Gosukonda, “Data Mesh and Data Governance: Finding the Balance,” Journal of AI-Assisted Scientific Discovery, Dec. 1AD. Available: https://www.scienceacadpress.com/index.php/jaasd/article/view/230
- S. Nguyen, “Data Management and the Four Principles of Data Mesh,” Dreamfactory.com, Oct. 2024. https://blog.dreamfactory.com/data-management-and-the-four-principles-of-data-mesh (accessed Nov. 26, 2025).
- Financial IT, “Why Banks Need Powerful, Agile Data Preparation Solutions for Accurate and Timely Regulatory Reporting,” Financial IT, 2025. https://financialit.net/news/banking/why-banks-need-powerful-agile-data-preparation-solutions-accurate-and-timely-0 (accessed Nov. 26, 2025).
- J. Bode, N. Kühl, D. Kreuzberger, S. Hirschl, and C. Holtmann, “Data Mesh: Best Practices to Avoid the Data Mess,” Jun. 2024. Accessed: Nov. 26, 2025. [Online]. Available: https://arxiv.org/pdf/2302.01713
Kommentar schreiben