Zusammenfassung – Angesichts steigender Oracle-Lizenzkosten, rückwirkender Audits und des Risikos der Herstellerbindung haben Banken Schwierigkeiten, ihren TCO und ihre Agilität zu optimieren, ohne Konformität und Transaktionsleistung zu gefährden.
MongoDB liefert ein flexibles JSON-Dokumentenmodell, verteilte Indizes und native Replikation, geeignet für die Konsolidierung der Kundenansicht, Echtzeit-Scoring, mobile Microservices und hochzuverlässige Analyse-Pipelines, alles in einem kontrollierten polyglotten Ökosystem.
Lösung: Einen gezielten 90-Tage-Piloten (Betrugserkennung oder Reporting) starten, um den ROI schnell zu prüfen, Lizenzkosten und Anbieterabhängigkeit zu senken und anschließend unter Einhaltung der FINMA- und GDPR-Konformität auszuweiten.
In einem Umfeld, in dem Banksysteme noch überwiegend auf historischen relationalen Datenbanken basieren und in dem die steigenden Oracle-Lizenzkosten sowie das Risiko eines Technologie-Lock-ins die IT-Abteilungen dazu drängen, Alternativen zu prüfen, bietet MongoDB als dokumentenorientierte NoSQL-Lösung einen Weg, die Gesamtkosten des Eigentums (TCO) zu senken, agiler zu werden und auf sich wandelnde Geschäftsanforderungen zu reagieren.
Dieser Artikel liefert einen strategischen Leitfaden für Entscheidungsträger im Bankenwesen (CIO/CTO, CDO, Risikocontrolling, COO). Er erläutert die Gründe für den Abschied von Oracle, das Funktionsprinzip von MongoDB, konkrete Anwendungsfälle, Limitierungen und empfohlene Architekturen. Zudem finden Sie eine 90-Tage-Roadmap für ein Pilotprojekt mit hohem ROI.
Warum man Oracle den Rücken kehren und MongoDB als Alternative in Betracht ziehen sollte
Die hohen Lizenzkosten und der von einigen traditionellen Anbietern erzwungene Vendor-Lock-in belasten das IT-Budget der Banken massiv. Regelmäßige kommerzielle Audits und die Komplexität der Verträge erhöhen das finanzielle und technische Risiko.
Der Einsatz einer skalierbaren Open-Source-Lösung wie MongoDB ermöglicht es, die TCO zu optimieren, flexible Strukturen zurückzugewinnen und die Abhängigkeit von einem einzigen Anbieter zu reduzieren.
Gesamtkosten des Eigentums (TCO) und hohe Lizenzgebühren
Banken betreiben häufig Hunderte Oracle-Server mit lizenzbasierten Gebühren pro Kern und sehr hohen jährlichen Supportkosten. Größere Versionsupgrades gehen oft mit zusätzlichen, pro Prozessor berechneten Aufwänden einher.
Die TCO umfasst nicht nur die anfänglichen Lizenzgebühren, sondern auch Wartungs-, Support- und Schulungskosten für Teams, die proprietäre und oft komplexe Funktionen beherrschen müssen.
Die teilweise oder vollständige Ablösung von Oracle durch eine modulare Open-Source-Lösung wie MongoDB bietet eine Alternative zu kernbasierten Preismodellen, mit einem Supportmodell, das sich an den tatsächlichen Bedürfnissen orientiert und einen kontrollierten Return on Investment ermöglicht.
Kommerzielle Audits und Lock-in-Risiken
Oracle-Audits, die im Finanzsektor häufig vorkommen, können rückwirkende Lizenzänderungen nach sich ziehen, die bei einem einzigen Vorfall mehrere Hunderttausend Schweizer Franken erreichen können.
Diese Audits üben permanenten Druck auf die IT-Teams aus, da sie fürchten, gegen Lizenz- und Auditklauseln eines etablierten Anbieters zu verstoßen.
Die Einführung von MongoDB mit seinem Open-Source-Engagement und einem Support durch Drittanbieter minimiert diese Risiken drastisch. Die Bank kann auf ein planbares Wartungsmodell umstellen und ihre Hosting-Optionen – On-Premise, Public-Cloud oder Private-Cloud – flexibel gestalten.
Beispiel einer Regionalbank und strukturelle Einsparungen
Eine Regionalbank mit mehreren Standorten hat einen Teil ihres internen Reporting-Modul von Oracle auf MongoDB migriert. Dabei ging es um die Konsolidierung von Kundendaten und die Berechnung von Liquiditätskennzahlen.
Das Projekt senkte die jährlichen Lizenz- und Supportkosten um 35 % und reduzierte die Komplexität der Testumgebungsverwaltung um 50 %, dank des schemalosen Ansatzes von MongoDB.
Dieses Beispiel zeigt, dass ein gezielt eingegrenzter Pilot mit klar definiertem Funktionsumfang schnell erhebliche Einsparungen und mehr technische Eigenständigkeit freisetzen kann.
Dokumentenmodell, JSON und MongoDB-Kultur
MongoDB basiert auf nativen JSON-Dokumenten, die eine flexible Schema-Struktur ermöglichen. Das erleichtert die Integration heterogener Daten und die schnelle Weiterentwicklung von Geschäftsmodellen. Entwickler können ohne aufwendige Migrationen iterieren.
Leistungsfähige Indexierung und integrierte Replikation garantieren hohe Performance und kontinuierliche Verfügbarkeit. Dieser Ansatz wandelt die Zusammenarbeit zwischen Entwicklern und Datenbankadministratoren in eine Partnerschaft mit Fokus auf Anwendungsperformance.
JSON-Dokumente für maximale Flexibilität
Jeder Datensatz ist ein JSON-Dokument, das verschachtelte Attribute, Arrays und Objekte enthalten kann. Entwickler passen das Schema bedarfsorientiert an, ohne relationale Tabellen zu definieren oder zu ändern.
Diese Flexibilität verhindert zeit- und ressourcenintensive Schema-Migrationen – ein entscheidender Vorteil in einer Branche mit stetig wachsenden regulatorischen Anforderungen. Weitere Informationen finden Sie in unserem Artikel zur Datenmodellierung.
Indexierung und verteilte Performance
MongoDB bietet einfache, zusammengesetzte, geospatiale und textuelle Indexe, die Abfragen auf beliebige Dokumentattribute beschleunigen. Die asynchrone Indexerstellung erfolgt ohne Unterbrechung des Dienstes.
Automatisches Sharding verteilt die Daten auf mehrere Knoten und ermöglicht eine lineare horizontale Skalierbarkeit, um wachsende Datenmengen und Lastspitzen abzufangen.
Lese- und Schreiboperationen profitieren von Replikation und Replica Sets, die hohe Verfügbarkeit sicherstellen und im Fehlerfall eine minimale Wiederanlaufzeit gewährleisten.
Einführung bei einem großen Finanzinstitut
Ein großes Finanzinstitut setzt MongoDB in mehreren Echtzeitanalyse- und Kunden-Scoring-Projekten ein. Die Umsetzung zeigte, dass MongoDB massive Datenströme verarbeiten kann und zugleich allen regulatorischen Anforderungen gerecht wird.
Dieser Anwendungsfall veranschaulicht, wie ein Institut den Einsatz einer NoSQL-Datenbank industrialisieren kann, um sein relationales Kernbanksystem zu ergänzen und reaktionsschnellere Mehrwertdienste anzubieten.
Er verdeutlicht auch, wie sich die Zusammenarbeit zwischen DBA und Entwicklern in Richtung DevOps entwickelt, bei der Deployments automatisiert und die Überwachung proaktiv gestaltet werden.
Edana: Strategischer Digitalpartner in der Schweiz
Wir begleiten Unternehmen und Organisationen bei ihrer digitalen Transformation.
Konkrete Anwendungsfälle für MongoDB im Bankwesen
MongoDB brilliert in Szenarien, die eine einheitliche Kundensicht, Echtzeitanalysen, eine nahtlose mobile und Omnichannel-Erfahrung sowie feingranulare Microservices erfordern. Diese Use Cases adressieren kritische Geschäftsanforderungen.
Scoring, Betrugserkennung und Marketing-Personalisierung profitieren vollumfänglich vom mächtigen Abfragemotor und den Streaming-Fähigkeiten der Plattform.
360-Grad-Kundensicht und Echtzeitanalysen
Durch die Zentralisierung aller Kundeninteraktionen (Transaktionen, Kommunikation, Logs) in einheitlichen Dokumenten ermöglicht MongoDB eine zugleich vollständige und aktuelle Sicht auf den Kunden.
Aggregationsabfragen auf diesen Dokumenten liefern nahezu in Echtzeit Kennzahlen zum Kundenverhalten, die unerlässlich sind, um Risikosegmente zu erkennen oder Cross-Selling-Potenziale zu identifizieren.
Der Aufbau einer kontinuierlichen Aggregations-Pipeline in Kombination mit einer Streaming-Engine erlaubt die sofortige Aktualisierung von Business-Dashboards, ohne die transaktionale Produktion zu beeinträchtigen. Mehr dazu in unserem Guide zur Data Pipeline.
Mobile, Omnichannel und Microservices
Mobile und Web-Applikationen nutzen die JSON-Dokumente direkt, um die Datentransformation zwischen Backend und Frontend zu minimieren. Kanalbezogene Microservices speichern und lesen dabei unabhängig Teile der Dokumente.
Diese entkoppelte Architektur verkürzt die Time-to-Market: Jede Produkt-Teams kann seine Microservices eigenständig ausrollen, ohne den Rest des Systems zu beeinflussen, und profitiert von kurzen Release-Zyklen. Erfahren Sie, wie Sie die Qualität einer mobilen App optimieren.
Scoring, Risiko und Betrugserkennung
Scoring- und Betrugserkennungsalgorithmen erfordern komplexe Berechnungen auf großen, oft heterogenen Datensätzen. MongoDB in Kombination mit einem verteilten Processing-Framework ermöglicht In-Memory-Berechnungen dieser Datenmengen.
Ein großer Versicherer hat in Echtzeit ein Kredit-Scoring-System auf Basis von MongoDB und Stream-Processing implementiert. Die Scores werden bei jeder Transaktion neu berechnet, was die Entscheidungsdauer um 40 % verkürzt hat. Mehr zur Integration von KI in unserem Artikel über KI und digitales Banking.
Governance, polyglotte Architektur und 90-Tage-Roadmap
Um Regulierungskonformität und Performance sicherzustellen, ist es entscheidend, Schema-Governance, Verschlüsselung und Auditierbarkeit einzurichten und MongoDB in ein polyglottes Technologie-Ökosystem einzubinden.
Eine 90-Tage-Roadmap, fokussiert auf einen geschäftskritischen Piloten, ein leichtgewichtiges Master Data Management und produktorientierte APIs, ermöglicht ein schnelles Proof of Concept und messbare ROI-KPIs.
Compliance, Sicherheit und Governance
KYC/AML-Vorgaben, die DSGVO und EBA-/FINMA-Standards erfordern Datenverschlüsselung im Ruhezustand und bei der Übertragung sowie fein abgestufte Zugriffssteuerung (RBAC). MongoDB Enterprise bietet diese Funktionen von Haus aus.
Schema-Versionierung erfolgt über Anwendungs-Migrationstools, die Änderungsnachverfolgung und Reproduzierbarkeit von Test- und Produktionsumgebungen gewährleisten.
Audit-Logs lassen sich auf CRUD-Operationen und administrative Befehle konfigurieren, um bei regulatorischen Prüfungen eine lückenlose Ereignisprotokollierung zu ermöglichen.
Polyglotte Architektur-Pattern
Ein gängiges Pattern kombiniert MongoDB für dokumentenbasierte und analytische Use Cases mit PostgreSQL oder einem anderen relationalen DBMS für komplexe Transaktionen und regulatorisches Reporting. Dieses eventgesteuerte Modell (Event-driven Architecture) sorgt für asynchrone und resiliente Verarbeitung.
90-Tage-Roadmap zur Implementierung
Tag 1–30 : Identifikation und Absteckung des Piloten (Betrugserkennung, Alerting, Scoring), Definition der geschäftlichen SLOs und Einrichtung eines leichten MDM für Kundenidentitäten. Dies entspricht der Discovery Phase.
Tag 31–60 : Entwicklung produktorientierter APIs, Integration von MongoDB und Konfiguration der Indexe, Deployment in nicht-kritischer Umgebung und erste Performance-Tests.
Tag 61–90 : Fachliche und technische Abnahme, Aufbau der Überwachung (Observability by Design), Erfassung der ROI-KPIs (Latenz, Erkennungsrate, Kosten pro Transaktion, NPS) und schrittweiser Rollout in die Produktion. Zur Vorbereitung Ihres Proof of Concept lesen Sie unseren POC-Guide KI.
Verwandeln Sie Ihre Daten in einen Wettbewerbsvorteil im Bankwesen
Die partielle oder vollständige Umstellung von einem relationalen DBMS auf MongoDB kann erhebliche Kosteneinsparungen, mehr Agilität und eine bessere Reaktionsfähigkeit auf Geschäftsanforderungen bringen – und das bei voller Einhaltung von Compliance- und Sicherheitsanforderungen.
Unser kontextbasierter Ansatz, der Open Source, modulare Architekturen und Vendor-Agnostizität in den Vordergrund stellt, hilft Ihnen, ein hybrides, widerstandsfähiges und skalierbares Ökosystem aufzubauen. Die Edana-Experten begleiten Sie von der Ist-Analyse bis zum produktiven Rollout und der Erfolgskontrolle.
Besprechen Sie Ihre Herausforderungen mit einem Edana-Experten







Ansichten: 7