I. Executive Summary

Die FNZ Bank SE (FNZ), ehemals ebase, und die Fondsdepot Bank GmbH (FDB) befinden sich in einer kritischen Phase, die von schwerwiegenden operationellen Mängeln, intensivem regulatorischem Druck durch die Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin) und signifikanten Risiken in ihrer komplexen IT-Landschaft geprägt ist. Insbesondere die Integration des Customer Relationship Management (CRM)-Systems Salesforce mit dem Kernbankensystem DIAMOS stellt eine erhebliche Herausforderung dar. Die Konvergenz dieser Faktoren hat zu erheblichen Störungen im Kundenservice geführt und wirft grundlegende Fragen zur Governance, zum Risikomanagement und zur Zukunftsfähigkeit der Institute auf, insbesondere im Kontext ihrer geplanten Geschäftsverschmelzung. Dieser Bericht analysiert umfassend die identifizierten Risiken in den Bereichen Betrieb, Regulierung, Technologie und Compliance und leitet daraus strategische Empfehlungen zur Risikominderung und Stabilisierung ab.

Die zentralen Ergebnisse der Analyse lassen sich wie folgt zusammenfassen:

• Gravierende organisatorische Mängel unter BaFin-Aufsicht: Nach Sonderprüfungen stellte die BaFin im April 2024 massive Mängel in der Geschäftsorganisation beider Institute fest, die gegen grundlegende Anforderungen des § 25a Kreditwesengesetz (KWG) verstoßen. Dies umfasst Defizite im Risikomanagement, in der IT-Governance und bei den personellen sowie technisch-organisatorischen Ressourcen. Die Einsetzung eines Sonderbeauftragten unterstreicht die Tiefe der Probleme und den Mangel an Vertrauen der Aufsicht in die interne Abhilfefähigkeit.1
• 
  
• Akute Krise im Kundenservice der Fondsdepot Bank: Ein erheblicher Rückstau bei der Bearbeitung von Wertpapieraufträgen und Kundenbeschwerden hat zu massiven Problemen für Kunden geführt. Diese operative Krise steht in direktem Zusammenhang mit Mängeln in den IT-Systemen und ineffizienten Prozessen, wie von der BaFin und verschiedenen Medien (u.a. Handelsblatt, IT-Finanzmagazin, Cash.Online, Frankenpost) berichtet wird.

• Hohes Ausführungsrisiko bei der Fusion: Die geplante Verschmelzung von FNZ und FDB, die strategisch auf die Konsolidierung des Geschäfts abzielt 10, birgt angesichts der bestehenden systemischen Schwächen erhebliche Risiken. Die Überwachung des Fusionsprozesses durch den BaFin-Sonderbeauftragten signalisiert die Besorgnis der Aufsicht, dass die Integration die Probleme verschärfen könnte.

• Signifikante technische Risiken der Salesforce-DIAMOS-Integration: Die Kopplung des Cloud-basierten CRM-Systems Salesforce mit dem Kernbankensystem DIAMOS stellt eine Hochrisiko-Umgebung dar. Potenzielle Schwachstellen umfassen Fehlkonfigurationen (insbesondere bei Zugriffsrechten), unzureichende API-Sicherheit, Mängel bei der Mandantentrennung und lückenhafte Überwachung. Vergangene Sicherheitsvorfälle bei Salesforce-Implementierungen in anderen Unternehmen verdeutlichen die realen Gefahren durch Konfigurationsfehler oder Malware.

• Compliance-Lücken bei Datenschutz und Outsourcing: Die Einhaltung der Datenschutz-Grundverordnung (DSGVO) sowie der strengen BaFin-Anforderungen an Cloud-Outsourcing (MaRisk AT 9, BAIT, DORA) ist kritisch. Die festgestellten Mängel und potenziellen Schattenprozesse deuten auf erhebliche Compliance-Risiken hin, die rechtliche, finanzielle und reputationsbezogene Konsequenzen nach sich ziehen können.27

Zusammenfassend lässt sich feststellen, dass FNZ und FDB mit systemischen Herausforderungen konfrontiert sind, die eine dringende und umfassende Sanierung erfordern. Dies betrifft die Bereiche Governance, operative Prozesse, IT-Infrastruktur und Compliance.

Die nachfolgende Analyse vertieft diese Punkte und mündet in konkreten strategischen Empfehlungen zur Bewältigung der Krise und zur Wiederherstellung einer stabilen und regelkonformen Geschäftsorganisation.

II. FNZ/FDB: Operationelle Herausforderungen und Regulatorischer Druck

A. BaFin-Intervention: Defizite, Anordnungen und Aufsicht

Die Intervention der BaFin im April 2024 markiert einen kritischen Wendepunkt für FNZ und FDB. Ausgelöst durch Sonderprüfungen gemäß § 44 KWG, offenbarte die Aufsicht "massive Mängel" in der Geschäftsorganisation beider Institute.1 Diese Feststellungen beziehen sich explizit auf die Nichterfüllung fundamentaler Anforderungen des § 25a KWG. Dieses Gesetz schreibt eine "ordnungsgemäße Geschäftsorganisation" vor, die insbesondere ein angemessenes und wirksames Risikomanagement, eine adäquate personelle und technisch-organisatorische Ausstattung sowie ein funktionierendes Beschwerdemanagement umfasst.

 Die Mängel deuten somit auf grundlegende Schwächen in der Steuerungs- und Kontrollstruktur der Banken hin.

Konkret bemängelte die BaFin, dass die IT-Systeme und -Prozesse, einschließlich des Auslagerungsmanagements (Outsourcing), nicht den Vorgaben des KWG entsprachen.

 Die Schwere und Dauer dieser IT-bezogenen Probleme wird dadurch unterstrichen, dass die BaFin bereits vor der öffentlichen Bekanntmachung im April die Eigenmittelanforderungen für beide Institute erhöht hatte.3 Diese vorgeschaltete Maßnahme signalisiert, dass frühere Aufforderungen zur Mängelbehebung offenbar nicht die gewünschte Wirkung zeigten und die Aufsicht die Risiken als so gravierend einschätzte, dass eine höhere Kapitalunterlegung zur Risikoabdeckung notwendig wurde. Die Abfolge der Ereignisse – erst erhöhte Kapitalanforderungen, dann die Einsetzung eines Sonderbeauftragten – lässt darauf schließen, dass der anfängliche regulatorische Druck nicht ausreichte, um eine adäquate Reaktion und Korrektur durch das Management von FNZ/FDB zu bewirken. Dies deutet auf tiefgreifende Probleme in der internen Governance oder mangelnde Fähigkeiten zur Problembehebung hin. Regulatorische Behörden eskalieren ihre Maßnahmen typischerweise; die Notwendigkeit eines Sonderbeauftragten impliziert, dass die BaFin das Vertrauen verloren hatte, dass die Banken die fundamentalen organisatorischen Mängel eigenständig und zeitnah beheben würden, selbst unter finanziellem Druck.

Die von der BaFin angeordneten Maßnahmen sind weitreichend. Zentral ist die Bestellung eines Sonderbeauftragten, der die "zügige" Beseitigung der Mängel in der Geschäftsorganisation überwachen soll.1 Zusätzlich wurde der FDB explizit aufgegeben, den bestehenden Rückstau bei Kundenaufträgen und Beschwerden "unverzüglich" abzubauen.1 Diese Anordnung zielt auf die Einhaltung spezifischer Vorschriften des Wertpapierhandelsgesetzes (WpHG) ab, namentlich § 69 WpHG zur unverzüglichen Auftragsausführung und § 80 WpHG (in Verbindung mit Art. 26 der Delegierten Verordnung (EU) 2017/565) zur unverzüglichen Beschwerdebearbeitung.

Die explizite Nennung dieser Paragraphen unterstreicht, dass die BaFin die Probleme nicht nur als IT-Fehler, sondern als Verletzung Kernpflichten im Bankbetrieb und im Kundenschutz wertet.

Die Rolle des Sonderbeauftragten ist dabei doppelt angelegt:

 Er überwacht nicht nur die Behebung der festgestellten Mängel, sondern begleitet auch die geplante Geschäftsverschmelzung der beiden Institute.

 Seine Aufgabe ist es sicherzustellen, dass während dieses komplexen Integrationsprozesses die bankaufsichtlichen und verbraucherschützenden Pflichten kontinuierlich eingehalten werden. Dass die Aufsicht die Fusion unter eine solch intensive Beobachtung stellt, spiegelt die Besorgnis wider, dass der Integrationsprozess selbst die bestehenden Schwachstellen verschärfen oder neue Risiken schaffen könnte, wenn er nicht unter externer Kontrolle sorgfältig gemanagt wird. Fusionen sind inhärent komplex und risikobehaftet, insbesondere wenn sie die Integration von IT-Systemen und operativen Prozessen umfassen – Bereiche, in denen FNZ/FDB bereits vor der vollständigen Integration erhebliche Mängel aufwiesen. Die BaFin antizipiert offenbar, dass die Zusammenführung schwacher Systeme und Prozesse zu weiteren Ausfällen, erhöhtem Auftragsstau oder Compliance-Verstößen führen könnte. Der Sonderbeauftragte fungiert somit als Sicherungsmechanismus, um die Einhaltung regulatorischer Standards während dieser Hochrisikophase durchzusetzen. Die Institute haben den Maßnahmen der BaFin zugestimmt, wodurch die Bescheide seit dem 9. April 2024 bestandskräftig sind.

B. Krise im Kundenservice: Auftragsstau, Beschwerden und Ursachenforschung

Parallel zu den aufsichtsrechtlichen Feststellungen eskalierte bei der FDB eine Krise im Kundenservice, die sich in einer Häufung von Kundenbeschwerden manifestierte.1 Hauptauslöser waren laut BaFin und Medienberichten (Handelsblatt, IT-Finanzmagazin, Cash.Online, Frankenpost) zahlreiche unbearbeitete oder stark verzögert ausgeführte Wertpapieraufträge und -überträge.1 Diese operativen Ausfälle trafen Kunden direkt und führten zu erheblichem Unmut.

Bei der Ursachenforschung nennen die Quellen unterschiedliche Aspekte. Das IT-Finanzmagazin berichtete von einem "Rückstau in der Kundenbetreuung", der infolge erforderlicher Änderungen der Allgemeinen Geschäftsbedingungen (AGB) entstanden sei.

Die regionale Frankenpost hingegen stellte einen direkteren Zusammenhang zwischen den "häufigen Kundenbeschwerden und Mängeln im IT-System" und der Notwendigkeit der Einsetzung des BaFin-Sonderbeauftragten her. Während AGB-Änderungen zweifellos zusätzlichen Bearbeitungsaufwand verursachen können, erscheint diese Erklärung allein jedoch unzureichend, um die von der BaFin beschriebene Schwere und Dauer des Rückstands (unerledigte Aufträge, verzögerte Überträge) vollständig zu erklären. 

Banken führen routinemäßig AGB-Änderungen durch, ohne dass dies typischerweise zu einer Lähmung von Kernfunktionen wie der Wertpapierauftragsabwicklung über längere Zeiträume führt. Die expliziten BaFin-Feststellungen zu IT-Systemmängeln  und die Anordnung, spezifisch den Auftrags-Rückstand abzubauen , legen nahe, dass die AGB-Änderung eher als Belastungstest fungierte, der bereits fragile IT-Systeme oder unzureichende Prozesskapazitäten überforderte, anstatt die alleinige Ursache zu sein.

Auffällig ist die Diskrepanz zwischen den öffentlichen Äußerungen der Banken und der von Aufsicht und Medien dargestellten Realität. Sowohl FNZ als auch FDB betonten, dass die Abarbeitung der BaFin-Feststellungen "keinerlei Auswirkungen" auf Angebot, Services und Leistungserbringung für Partner und Kunden habe.

 Diese Darstellung steht im klaren Widerspruch zu den dokumentierten massiven Kundenbeschwerden und dem Auftragsstau. Eine solche Kommunikationsstrategie, die offensichtliche Probleme herunterspielt, birgt das Risiko, das Vertrauen von Kunden und insbesondere von Geschäftspartnern (wie Finanzvermittlern, die auf die Plattform angewiesen sind) weiter zu beschädigen, sobald das volle Ausmaß der Probleme bekannt wird.

Die Kundenbeschwerden sind dabei weit mehr als nur ein Reputationsproblem. Sie stellen potenzielle finanzielle Verluste für die Kunden dar (durch verzögerte Handelsausführungen zu möglicherweise ungünstigeren Kursen) und bedeuten gleichzeitig signifikante Compliance-Verstöße gegen Kernpflichten des WpHG (§ 69 zur unverzüglichen Ausführung).2 Dies hebt das Risiko über reine operative Unannehmlichkeiten hinaus auf eine Ebene mit potenziellen rechtlichen und finanziellen Konsequenzen für die Institute. 

Die BaFin hat folgerichtig nicht nur den unverzüglichen Abbau des Rückstands angeordnet, sondern auch, dass die Bank geeignete Maßnahmen treffen muss, um einen erneuten Rückstand zu vermeiden.1

C. Historische Risikoindikatoren: Rechtliche Präzedenzfälle und Identitätsmissbrauch

Die aktuellen Schwierigkeiten bei FNZ/FDB könnten auch im Licht vergangener Ereignisse und Schwachstellen betrachtet werden. Ein relevanter rechtlicher Präzedenzfall datiert aus dem Jahr 2015. Damals leistete die FDB Schadensersatz an einen Rentner im Zusammenhang mit dem offenen Immobilienfonds "DEGI Europa".45 Der Vorwurf lautete, die Bank habe den Kunden pflichtwidrig nicht über die Aussetzung der Anteilsrücknahme des Fonds informiert und damit gegen Informationspflichten aus dem Depotvertrag verstoßen.46 Der Vergleich wurde auf Anregung des Oberlandesgerichts Bamberg geschlossen, was auf erheblichen juristischen Druck auf die Bank hindeutet.46 Obwohl dieser Fall zeitlich zurückliegt und einen anderen Sachverhalt betrifft, zeigt er eine historische Schwäche der FDB bei der Erfüllung grundlegender Pflichten gegenüber ihren Kunden – in diesem Fall der Informationspflicht. Diese historische Schwäche könnte eine Parallele zu den aktuellen Kommunikationsdefiziten und der mangelnden Transparenz bezüglich der operativen Probleme aufweisen. Beide Szenarien deuten auf ein potenzielles Muster unzureichender Kommunikation oder einer Vernachlässigung von Kundeninteressen hin, wenn auch in unterschiedlichen Kontexten.

Aktueller sind die Warnungen, die die FDB selbst vor betrügerischen Webseiten ausspricht. Unbekannte Täter nutzen Namen wie "FdCoin" oder "FdBank", um Anleger zu Investitionen in angebliche Krypto-Produkte zu verleiten. Die BaFin stellte 2025 klar, dass es sich hierbei um Identitätsmissbrauch handelt und diese Angebote in keiner Verbindung zur FDB (als Marke der FNZ Bank SE) stehen.47 Solche Vorfälle sind im Finanzsektor nicht ungewöhnlich, wie auch andere BaFin-Warnungen vor gefälschten Online-Banken oder Phishing-Schemata zeigen.49 Obwohl FNZ/FDB nicht Verursacher dieser Betrugsversuche sind, schädigen sie die Reputation der Marke durch Assoziation. Dieses "Hintergrundrauschen" durch Identitätsmissbrauch kann legitime Kunden, deren Vertrauen durch die operativen Probleme der Bank 1 möglicherweise bereits angeschlagen ist, anfälliger für Phishing oder Social Engineering machen. Kunden, die auf eine Lösung ihrer Probleme warten, könnten eher geneigt sein, auf betrügerische Kommunikation zu reagieren, die vorgibt, von der Bank zu stammen. Dies stellt ein indirektes Sicherheitsrisiko dar, das durch die operativen Mängel der Bank verstärkt wird.

Es ist anzumerken, dass über den DEGI Europa-Fall hinaus bisher keine weiteren öffentlich bekannten Klagen oder Strafanzeigen gegen FNZ oder FDB dokumentiert sind. Die verfügbaren Quellen zu Unternehmensinformationen oder Serviceleistungen 8 enthalten keine Hinweise auf weitere relevante Gerichtsverfahren.

III. Technische Tiefenanalyse: Risiken der Salesforce-DIAMOS-Integration

A. Salesforce-Sicherheitskontext: Lehren aus früheren Vorfällen

Die Integration zwischen dem Salesforce CRM und dem Kernbankensystem DIAMOS bildet eine zentrale Säule der IT-Infrastruktur von FNZ/FDB. Sie verbindet die kundennahen Prozesse im CRM mit den Kernfunktionen der Bank. Solche Integrationen, insbesondere zwischen einer Cloud-Plattform und einem On-Premise- oder gehosteten Kernsystem, bergen inhärente Risiken, die sorgfältig gemanagt werden müssen.

Um die spezifischen Risiken im FNZ/FDB-Kontext einzuordnen, ist ein Blick auf allgemeine Sicherheitsvorfälle im Salesforce-Ökosystem hilfreich. Diese zeigen, dass selbst Konfigurationsfehler gravierende Folgen haben können. Ein prägnantes Beispiel ist der Vorfall vom April 2023: Falsch konfigurierte Salesforce Community Sites (mittlerweile Experience Cloud) führten bei verschiedenen Organisationen, darunter Behörden, Kliniken und Banken, zur Exposition sensibler Daten. Namen, Adressen und sogar Sozialversicherungsnummern wurden öffentlich zugänglich, weil die Berechtigungen für Gastnutzer (unauthentifizierte Nutzer) zu weit gefasst waren.16

Ein weiterer relevanter Vorfall ereignete sich 2019 bei dem Unternehmen Hanna Andersson. Malware infizierte eine Instanz der Salesforce Commerce Cloud, die das Unternehmen nutzte. Diese Schadsoftware war in der Lage, Kreditkartendaten von Kunden während des Bezahlvorgangs abzugreifen und zu stehlen.17 Dieser Fall unterstreicht, dass auch die von Salesforce bereitgestellte Plattforminfrastruktur zum Ziel von Angriffen werden kann, insbesondere an den Schnittstellen zu externen Systemen oder über kompromittierte Drittanbieterkomponenten.

Die Relevanz dieser Vorfälle für FNZ/FDB liegt auf der Hand: Sie demonstrieren eindrücklich, dass Salesforce-Umgebungen, trotz der Sicherheitsmaßnahmen der Plattform selbst 60, anfällig für Fehlkonfigurationen durch den Kunden (insbesondere bei Gast- oder öffentlichen Zugängen) und für Malware sind, die integrierte Komponenten oder Schnittstellen angreift. Das wiederkehrende Muster bei größeren Salesforce-Datenlecks, wie dem Gastnutzer-Problem von 2023 16, ist häufig die Fehlkonfiguration durch den Kunden, nicht notwendigerweise eine Schwachstelle in der Salesforce-Kerninfrastruktur. Dies unterstreicht die hohe Verantwortung der internen IT-Governance und des technischen Know-hows bei FNZ/FDB, ihre spezifische Salesforce-Instanz sicher zu konfigurieren und zu betreiben. Salesforce operiert nach einem Modell der geteilten Verantwortung (Shared Responsibility Model) 22, bei dem Salesforce die Sicherheit der Cloud-Infrastruktur gewährleistet, der Kunde (hier FNZ/FDB) jedoch für die korrekte Konfiguration von Zugriffskontrollen, Nutzerberechtigungen und Anwendungseinstellungen verantwortlich ist. Angesichts der bereits von der BaFin festgestellten IT-Mängel bei FNZ/FDB 4 erscheint die Fähigkeit, eine komplexe Plattform wie Salesforce korrekt zu konfigurieren und zu warten, fraglich, was das Risiko ähnlicher Konfigurationsfehler erhöht. Der Fall Hanna Andersson 17 zeigt zudem, dass Schwachstellen nicht nur durch direkte Konfiguration, sondern auch an den Integrationspunkten entstehen können. Dies ist direkt relevant für die API-Kopplung zwischen Salesforce und DIAMOS, da diese Schnittstelle eine potenzielle Angriffsfläche darstellt, ähnlich der im Fall Hanna Andersson ausgenutzten Schwachstelle.

B. Architektonische Schwachstellen: Datentrennung und API-Sicherheit

Die Multi-Tenant-Architektur von Cloud-CRM-Systemen wie Salesforce stellt eine besondere Herausforderung dar. Obwohl solche Systeme darauf ausgelegt sind, die Daten verschiedener Mandanten (Kunden oder Organisationseinheiten) durch logische Partitionierung (oft mittels eindeutiger Organisations-IDs oder Datenbank-Identifikatoren) strikt zu trennen, können Fehler in dieser Trennung zu Datenlecks zwischen Mandanten führen.61 Im Finanzsektor, wo höchste Vertraulichkeit geboten ist, stellt dies ein enormes Risiko dar, das von der BaFin mit großer Wahrscheinlichkeit genau geprüft wird. Die Kombination aus der Multi-Tenant-Architektur von Salesforce und der Integration mit einem Kernbankensystem (DIAMOS) schafft ein einzigartiges und erhöhtes Risikoprofil. Ein Fehler bei der Datentrennung innerhalb von Salesforce könnte potenziell nicht nur CRM-Daten offenlegen, sondern indirekt auch sensible Finanzdaten, die über die Integration verknüpft sind. Ein solcher Vorfall wäre weitaus kritischer als in einem nicht-bankbezogenen Kontext, da er potenziell Wege zu Kernfinanzinformationen öffnen könnte.

Von zentraler Bedeutung ist die Sicherheit der API-Schnittstelle (Application Programming Interface) zwischen Salesforce und DIAMOS. Jeder API-Endpunkt stellt ein potenzielles Einfallstor für Angreifer dar. Essenzielle Sicherheitsmaßnahmen sind unabdingbar:

• Verschlüsselung: Die Datenübertragung muss zwingend über SSL/TLS (mindestens Version 1.2) verschlüsselt erfolgen.33
• Authentifizierung & Autorisierung: Strikte Zugriffskontrollen sind erforderlich. OAuth 2.0 wird als Standard empfohlen, um API-Anfragen zu autorisieren, ohne Benutzerdaten direkt zu übertragen.67 Jede API-Interaktion muss robust authentifiziert und autorisiert werden.69
• Netzwerksicherheit: Der Einsatz von Firewalls und/oder API-Gateways zur Filterung und Kontrolle des API-Traffics ist notwendig.68 IP-Whitelisting kann den Zugriff auf bekannte, vertrauenswürdige Adressen beschränken.67 Wie Noltic treffend formuliert: "eine schlecht gesicherte API könnte sensible Finanzdaten Angreifern offenlegen".

Darüber hinaus sollten fortgeschrittene Praktiken zur API-Sicherheit implementiert werden. Dazu gehören Rate Limiting, um Brute-Force-Angriffe oder Denial-of-Service-Attacken durch übermäßige Anfragen zu verhindern, sowie die Anwendung von Zero-Trust-Prinzipien.20 Letzteres bedeutet, dass kein implizites Vertrauen zwischen Systemen besteht und jede Anfrage einzeln verifiziert wird. Eine schwache API-Sicherheit birgt nicht nur das Risiko der Datenexposition aus Salesforce heraus. Sie könnte es Angreifern potenziell ermöglichen, manipulierte Daten oder betrügerische Befehle in das Kernbankensystem DIAMOS einzuschleusen. APIs erlauben typischerweise eine Zwei-Wege-Kommunikation.68 Wenn die API zwischen Salesforce und DIAMOS keine angemessene Authentifizierung, Autorisierung und Eingabevalidierung aufweist, könnte ein Angreifer, der über Salesforce Zugang erlangt, potenziell schädliche Anfragen an DIAMOS senden. Dies könnte Versuche umfassen, Kontodaten zu ändern, nicht autorisierte Transaktionen auszulösen oder Kernbankprozesse zu stören, wodurch die CRM-Integration zu einem Angriffsvektor gegen das Herzstück der Bank wird.

C. Lücken bei Überwachung, Auditierung und Zugriffskontrolle

Eine lückenlose Überwachung und Auditierbarkeit aller relevanten Vorgänge ist für die Sicherheit und Compliance unerlässlich. Salesforce bietet hierfür die Funktion "Event Monitoring", mit der eine Vielzahl von Ereignissen wie Logins, API-Aufrufe, Datenexporte, Datensatzänderungen und mehr protokolliert werden können.33 Diese Protokolldaten sind entscheidend für die Nachvollziehbarkeit von Aktionen und die Aufklärung von Sicherheitsvorfällen.

Es ist von entscheidender Bedeutung, diese Salesforce-Ereignisprotokolle in ein zentrales Security Information and Event Management (SIEM)-System einzuspeisen.33 Dies ermöglicht die Korrelation von Ereignissen aus verschiedenen Quellen, die automatisierte Analyse auf verdächtige Muster und die frühzeitige Alarmierung bei Anomalien oder potenziellen unbefugten Zugriffen. Eine zentrale Anforderung ist dabei, dass alle relevanten Aktionen, insbesondere die Datenübertragungen zwischen Salesforce und DIAMOS über die API, umfassend und lückenlos protokolliert werden. Hierbei sind jedoch potenzielle Einschränkungen zu beachten: Event Monitoring ist möglicherweise eine kostenpflichtige Zusatzfunktion oder erfordert spezifische Abonnements.84 Nicht alle denkbaren Ereignisse sind eventuell standardmäßig abgedeckt, und die Aufbewahrungsdauer der Protokolle innerhalb von Salesforce kann begrenzt sein, was eine externe Speicherung und Archivierung (z.B. im SIEM) notwendig macht.33 Salesforce Shield erweitert zwar mit dem "Field Audit Trail" die Nachverfolgung von Datenänderungen über längere Zeiträume, erfasst jedoch keine Änderungen an Metadaten (wie z.B. Änderungen an Workflows oder Berechtigungseinstellungen).82 Eine unzureichende Protokollierung oder Überwachung des API-Verkehrs zwischen Salesforce und DIAMOS schafft einen kritischen blinden Fleck. Im Falle eines Sicherheitsvorfalls über diese Schnittstelle könnte das Fehlen detaillierter Protokolle die Bestimmung des Umfangs des Vorfalls, die Identifizierung der Angreiferaktionen oder die Erfüllung regulatorischer Meldepflichten (z.B. die 72-Stunden-Frist der DSGVO 37) unmöglich machen.

Ein weiterer kritischer Punkt ist die Verwaltung der Multi-Faktor-Authentifizierung (MFA). Salesforce schreibt die Nutzung von MFA für interaktive Logins vertraglich vor.73 Allerdings gibt es notwendige Ausnahmen, insbesondere für technische Benutzerkonten, die für Systemintegrationen (wie die Salesforce-DIAMOS-Kopplung) verwendet werden. Diesen Konten kann die Berechtigung "Multi-Faktor-Authentifizierung für ausgenommene Benutzer umgehen" ("Waive Multi-Factor Authentication for Exempt Users") zugewiesen werden.79 Während technisch notwendig 73, stellt jede solche Ausnahme ein potenzielles Sicherheitsrisiko dar. Eine unsachgemäße oder zu weitreichende Vergabe dieser Berechtigung erhöht das Risiko eines unbefugten Zugriffs erheblich.73 Diese MFA-Ausnahmen bilden eine potenzielle Schwachstelle, die kompensatorische Kontrollen erfordert. Wird das ausgenommene Integrationskonto selbst kompromittiert (z.B. durch gestohlene API-Schlüssel oder OAuth-Tokens 69), bietet MFA keinen Schutz für diesen spezifischen Angriffsvektor. Dies unterstreicht die immense Bedeutung der API-Sicherheit, der Überwachung und des Prinzips der geringsten Rechtevergabe (Least Privilege) gerade für diese ausgenommenen Konten, da MFA hier als Sicherheitsnetz entfällt.

Die Risiken unsachgemäßer Zugriffskontrollen werden durch den Salesforce-Datenleck-Vorfall von 2023 verdeutlicht, der auf fehlkonfigurierte Richtlinien für Gastnutzer zurückzuführen war.22 Gastnutzer sind unauthentifizierte Besucher von öffentlichen Salesforce-Seiten (z.B. über Experience Cloud). Ihre Berechtigungen müssen extrem restriktiv sein. Fehlkonfigurationen, wie die Gewährung von zu weitreichendem Objektzugriff, API-Zugriff oder der Berechtigung "Alle Benutzer anzeigen", können zu massiven Datenexpositionen führen.22 Eine sorgfältige Überprüfung und Härtung der Gastnutzerprofile und -berechtigungen ist daher unerlässlich. Eine schlecht verwaltete Gastnutzer-Konfiguration in Kombination mit der DIAMOS-Integration könnte potenziell sogar unauthentifizierten externen Nutzern indirekte Wege eröffnen, um Daten einzusehen oder sogar zu manipulieren, die letztlich aus dem Kernbankensystem stammen oder dorthin fließen – abhängig davon, wie die Integration Daten über Salesforce-Objekte bereitstellt, auf die Gastnutzer fälschlicherweise Zugriff haben.

D. Prozessintegrität und Risiken durch Schatten-IT

Ein oft unterschätztes Risiko in komplexen IT-Umgebungen sind "Schattenprozesse" oder "Schatten-IT". Darunter versteht man inoffizielle Arbeitsabläufe und Werkzeuge (wie z.B. Excel-Tabellen, private E-Mail-Konten, nicht genehmigte Cloud-Dienste), die Mitarbeiter nutzen, wenn die offiziellen Systeme und Prozesse – wie die Salesforce-DIAMOS-Integration – fehlschlagen, zu langsam oder unzureichend sind.

Im Bankenumfeld sind die Risiken von Schattenprozessen besonders hoch 93:

• Mangelnde Kontrolle: Diese Prozesse laufen außerhalb der formalen Kontrollmechanismen der Bank ab.
• Dateninkonsistenzen: Manuelle Übertragungen oder separate Listen führen zu Abweichungen zwischen Salesforce, DIAMOS und den inoffiziellen Aufzeichnungen.
• Fehleranfälligkeit: Manuelle Eingaben und Bearbeitungen erhöhen das Risiko von Fehlern.
• Compliance-Verstöße: Die Nichteinhaltung von Datenschutzvorgaben (DSGVO), Aufbewahrungspflichten oder bankaufsichtlichen Anforderungen (MaRisk/BAIT) an dokumentierte und prüffähige Prozesse ist wahrscheinlich.
• Sicherheitslücken: Sensible Kunden- oder Transaktionsdaten könnten unsicher in lokalen Dateien oder ungeschützten Cloud-Speichern abgelegt werden. ProcessMaker fasst zusammen: Schattenprozesse "führen zu Ineffizienzen und bergen Sicherheits- und Compliance-Risiken".

Die Verbindung zur aktuellen Situation bei FNZ/FDB ist offensichtlich: Angesichts der berichteten massiven operativen Rückstände und IT-Probleme 1 ist es hoch wahrscheinlich, dass Mitarbeiter auf Schattenprozesse zurückgegriffen haben, um die Flut an Kundenaufträgen oder Beschwerden irgendwie zu bewältigen. Dies dürfte die Probleme bei der Datenintegrität und Compliance weiter verschärft haben. Das Entstehen solcher Schattenprozesse, getrieben durch Ausfälle oder Mängel in der Salesforce-DIAMOS-Integration oder verbundenen Systemen, untergräbt direkt die angestrebten Vorteile der CRM-Implementierung (Effizienz, Datenkonsistenz, zentrale Sicht) und schafft versteckte operative Risiken, die für Management und Prüfer schwer nachvollziehbar sind. Sie führen zu Datenfragmentierung, Prozessineffizienzen und fehlenden Audit-Trails, was den eigentlichen Zweck des CRM konterkariert. Insbesondere die manuelle Handhabung von Finanzdaten (z.B. Auftragsdetails in Excel) in Schattenprozessen erhöht das Risiko von DSGVO-Verstößen (unkontrollierte Speicherung/Zugriff auf personenbezogene Daten 27) und verletzt die BaFin-Anforderungen an prüffähige, kontrollierte Prozesse (MaRisk/BAIT 39).

IV. Compliance und Governance im Cloud-Outsourcing

A. Datenschutzkonformität: DSGVO im Salesforce-Kontext

Die Verarbeitung von Kundendaten in Salesforce unterliegt uneingeschränkt den Bestimmungen der Datenschutz-Grundverordnung (DSGVO). Dies impliziert die Einhaltung zentraler Grundsätze wie Rechtmäßigkeit der Verarbeitung, Zweckbindung, Datenminimierung, Richtigkeit, Speicherbegrenzung, Integrität und Vertraulichkeit sowie die Gewährleistung der Betroffenenrechte (Auskunft, Berichtigung, Löschung, Einschränkung der Verarbeitung, Datenübertragbarkeit, Widerspruch).27

Für den Einsatz von Salesforce im Bankenumfeld ergeben sich spezifische DSGVO-Anforderungen:

• Auftragsverarbeitungsvertrag (AVV): Ein formaler AVV zwischen FNZ/FDB als Verantwortlichem und Salesforce als Auftragsverarbeiter ist zwingend erforderlich. Ebenso müssen AVVs mit Drittanbietern von AppExchange-Anwendungen geschlossen werden, die personenbezogene Daten verarbeiten.27 Salesforce stellt hierfür einen Standard-AVV (Data Processing Addendum - DPA) bereit.27
• Zugriffskontrolle (Need-to-Know): Die Implementierung des Prinzips der geringsten Rechtevergabe ("Least Privilege") über Salesforce-Profile, Berechtigungssätze und Rollenhierarchien ist essenziell, um die Vertraulichkeit und Integrität der Daten gemäß DSGVO Art. 32 zu gewährleisten.27 Schlechte Zugriffskontrolle war bereits Gegenstand hoher DSGVO-Strafen.27
• AppExchange-Anwendungen: Jede genutzte AppExchange-App, die personenbezogene Daten verarbeitet (eine hohe Verbreitung wird berichtet 27), muss sorgfältig auf DSGVO-Konformität geprüft werden. Dies umfasst die Bewertung der Sicherheitsstandards des Anbieters (ISO 27001 wird als positives Signal genannt 27), den Abschluss von AVVs, die Prüfung potenzieller Datentransfers außerhalb der EU und die Analyse der Datenaufbewahrungspraktiken.27 Diese Prüfungspflicht gilt auch für Testversionen. Die Nutzung zahlreicher Apps kompliziert die Compliance erheblich und schafft eine potenzielle "versteckte" Ebene von Datenverarbeitungsaktivitäten und Drittparteirisiken.
• Privacy by Design: Datenschutzprinzipien müssen von Beginn an in die Konfiguration und Weiterentwicklung von Salesforce integriert werden. Dazu gehören Datenminimierung (nur notwendige Daten erheben), Mechanismen zur Einwilligungseinholung und -verwaltung (Salesforce bietet hierfür das "Individual"-Objekt 38), technische und organisatorische Sicherheitsmaßnahmen sowie die Durchführung von Datenschutz-Folgenabschätzungen (DSFAs) bei risikoreichen Verarbeitungen.27 Die Tatsache, dass FNZ/FDB nun mit gravierenden operativen und Compliance-Problemen konfrontiert ist 1, legt nahe, dass "Privacy by Design" bei der ursprünglichen Implementierung oder späteren Änderungen möglicherweise vernachlässigt wurde. Die nachträgliche Integration von Datenschutzprinzipien ist weitaus schwieriger und fehleranfälliger.
• Internationale Datentransfers: Der Einsatz eines globalen Cloud-Anbieters wie Salesforce impliziert potenziell internationale Datentransfers. Die Einhaltung der DSGVO erfordert hierfür geeignete Transfermechanismen (z.B. Standardvertragsklauseln (SCCs), Angemessenheitsbeschlüsse), die im AVV geregelt sein müssen.34 Salesforce adressiert die globale GDPR-Compliance.35
• Datenaufbewahrung und Löschung: Es müssen klare Richtlinien und technische Prozesse etabliert werden, um Daten in Salesforce nur so lange wie nötig aufzubewahren und Löschanfragen von Betroffenen fristgerecht nachzukommen.27

Angesichts der festgestellten operativen Probleme und der wahrscheinlichen Existenz von Schattenprozessen bestehen für FNZ/FDB erhebliche DSGVO-Compliance-Risiken. Dazu zählen die unkontrollierte Verarbeitung personenbezogener Daten, die Nichteinhaltung von Fristen bei Betroffenenanfragen oder unzureichende technische und organisatorische Maßnahmen zum Schutz der Daten.

B. Regulatorische Anforderungen an Cloud-Services: BaFin MaRisk, BAIT und DORA

Der Einsatz von Cloud-Diensten wie Salesforce für bankbetriebliche Funktionen stellt eine Auslagerung dar und unterliegt strengen regulatorischen Anforderungen der BaFin. Maßgeblich sind hier die Mindestanforderungen an das Risikomanagement (MaRisk), insbesondere das Modul AT 9 (Auslagerung), sowie die Bankaufsichtlichen Anforderungen an die IT (BAIT).39

Die zentralen MaRisk AT 9 / BAIT-Anforderungen für das Cloud-Outsourcing der Salesforce-DIAMOS-Integration umfassen:

• Risikoanalyse und Wesentlichkeit: Vor der Auslagerung ist eine Risikoanalyse durchzuführen, um festzustellen, ob es sich um eine "wesentliche" Auslagerung handelt.39 Angesichts der zentralen Rolle eines CRM-Systems, das mit dem Kernbanksystem verbunden ist, ist von einer Wesentlichkeit auszugehen.
• Vertragliche Anforderungen: Es sind umfassende Auslagerungsverträge erforderlich, die u.a. die zu erbringenden Leistungen, Weisungsrechte, Datenschutz- und Sicherheitsanforderungen, Kündigungsregelungen, Unterstützung bei der Exit-Strategie sowie umfassende Prüfungsrechte für die Bank, deren Prüfer und die BaFin festlegen.30 Die BaFin betont dabei uneingeschränkte Prüfungsrechte, was oft im Widerspruch zu Standardverträgen von Cloud-Anbietern steht und sorgfältige Verhandlungen erfordert.42 Die Akzeptanz von Zertifizierungen (z.B. SOC 2, ISO 27001 63) oder Pool-Prüfungen 42 kann eine praktische Lösung sein, erfordert aber eine gründliche Validierung durch die Bank.
• Laufende Überwachung: Die Leistung und Sicherheit des Cloud-Anbieters (Salesforce) müssen kontinuierlich überwacht werden.30
• Exit-Strategie: Eine dokumentierte und plausible Exit-Strategie ist vorgeschrieben, die sicherstellt, dass die Bank die ausgelagerten Funktionen und Daten ohne Beeinträchtigung kritischer Prozesse zurückverlagern oder zu einem anderen Anbieter migrieren kann.30
• Sorgfalt bei der Anbieterauswahl: Die Bank muss sicherstellen, dass der Dienstleister (Salesforce) die qualitativen Anforderungen erfüllt und die Prozesse sicher und effektiv handhaben kann.39
• Verantwortung der Geschäftsleitung: Die Gesamtverantwortung für die ausgelagerten Prozesse verbleibt trotz Auslagerung uneingeschränkt bei der Geschäftsleitung der Bank.30

Zusätzlich gewinnt der Digital Operational Resilience Act (DORA - Verordnung (EU) 2022/2554) an Bedeutung, der bald EU-weit verbindlich wird. DORA stellt einen neuen, übergreifenden Rahmen für das Management von IKT-Risiken im Finanzsektor dar. Die aktualisierte BaFin-Orientierungshilfe zum Cloud-Outsourcing vom Februar 2024 nimmt explizit Bezug auf DORA und rät Banken dringend, dessen Anforderungen bereits jetzt bei der Gestaltung von Cloud-Verträgen zu berücksichtigen.30 DORA legt besonderen Fokus auf das IKT-Risikomanagement, die Meldung von IKT-Vorfällen, Resilienztests und das Management von Risiken durch Drittanbieter, insbesondere kritische IKT-Dienstleister wie Cloud-Plattformen.30 Auch Leitlinien der EZB unterstreichen diese Punkte.96 DORA verschärft insbesondere die Anforderungen an das Management von Konzentrationsrisiken und an Exit-Strategien.30 Für FNZ/FDB, die sich stark auf Salesforce (einen dominanten Anbieter) in Verbindung mit ihrem Kernsystem stützen, wird der Nachweis eines tragfähigen und getesteten Exit-Plans zu einer wesentlich kritischeren und potenziell schwierigeren regulatorischen Hürde.

Die BaFin-Orientierungshilfe von Februar 2024 hebt spezifische Herausforderungen hervor 30: die Notwendigkeit einer strategischen Analyse der "Cloud-Fähigkeit" der Auslagerung, die Sicherstellung adäquater Überwachungsmöglichkeiten, die Prüfung der Rückverlagerbarkeit, die Entwicklung interner Richtlinien für die Cloud-Nutzung (die Themen wie Compliance, Identitäts- und Rechtemanagement, Verschlüsselung und Schlüsselmanagement, Entwicklung und Betrieb, Schnittstellen, Steuerung von Subunternehmern und IT-Notfallmanagement abdecken) sowie die Bereitstellung ausreichender und qualifizierter personeller und finanzieller Ressourcen. Die Notwendigkeit von ausreichend fachkundigem Personal 30 zur Steuerung des Cloud-Outsourcings ist ein kritischer Punkt. Angesichts der von der BaFin bereits identifizierten IT-Mängel bei FNZ/FDB 4 könnte ein Mangel an interner Expertise im Management von Salesforce-Sicherheit, Compliance und Integration eine der Wurzeln der Probleme und ein Haupthindernis für die Sanierung sein.

C. Bewertung der Compliance- und Outsourcing-Management-Struktur von FNZ/FDB

Die Gesamtschau der BaFin-Feststellungen und der operativen Probleme zeichnet ein besorgniserregendes Bild der Compliance- und Outsourcing-Management-Struktur bei FNZ/FDB. Die Intervention der Aufsicht wegen Mängeln in der Geschäftsorganisation (§ 25a KWG) und spezifisch im IT-Bereich und Auslagerungsmanagement 1 belegt eindeutig Versäumnisse in diesen Bereichen. Der massive Auftragsstau und die Kundenbeschwerden deuten auf eine Nichteinhaltung operativer Vorschriften (WpHG § 69, § 80) hin 2, was wiederum auf Schwächen in den zugrundeliegenden, potenziell von Salesforce/DIAMOS abhängigen Prozessen schließen lässt.

Es ist anzunehmen, dass die Compliance-Dokumentation und -Praktiken erhebliche Lücken aufweisen. Die Risikoanalysen für das Salesforce-Outsourcing könnten unzureichend sein, die vertraglichen Vereinbarungen nicht vollständig den aktuellen MaRisk/DORA-Anforderungen entsprechen (insbesondere bezüglich Prüfungsrechten und Exit-Klauseln), die Überwachungsprozesse schwach und die internen Richtlinien sowie die Ressourcenausstattung ungenügend sein, wie es die BaFin-Leitlinien von 2024 fordern.30

Die wahrscheinliche Existenz von Schattenprozessen 93 verschärft die Compliance-Problematik weiter. Diese unkontrollierten Abläufe untergraben die Grundsätze der DSGVO und der MaRisk/BAIT, die transparente, kontrollierte und prüffähige Prozesse verlangen. Die Tatsache, dass ein externer Sonderbeauftragter eingesetzt werden musste 1, impliziert ein Versagen der internen Kontrollinstanzen. Entweder haben die internen Compliance- und Risikofunktionen (die "drei Verteidigungslinien") die Probleme nicht rechtzeitig erkannt oder eskaliert, oder das Management hat nicht adäquat auf interne Warnungen reagiert. Dies deutet auf einen Bruch in der internen Governance-Struktur hin.

Der laufende Fusionsprozess 2 stellt eine zusätzliche Belastung für die Compliance dar. Richtlinien, Prozesse, Risikobewertungen und potenziell auch die Salesforce-Konfiguration müssen für das fusionierte Institut harmonisiert und neu bewertet werden. Dies erfordert erhebliche Compliance-Ressourcen in einer Zeit, in der die Organisation bereits unter intensivem regulatorischem Druck und operativer Belastung steht, was das Risiko von Fehlern oder Verzögerungen bei der Erreichung der vollständigen Compliance für das neue Gesamtinstitut erhöht.

Tabelle 1: Zusammenfassung der BaFin-Feststellungen und Anordnungen (April 2024)

Feststellungskategorie

Spezifische Mängel (basierend auf Quellen)

BaFin-Anordnung

Rechtsgrundlage (Beispiele)

Ordnungsgemäße Geschäftsorganisation

Allgemeine Mängel in der Organisation, Risikomanagement, personelle/technische Ausstattung 1

Sicherstellung der ordnungsgemäßen Geschäftsorganisation überwacht durch Sonderbeauftragten 1

§ 25a KWG

IT-Systeme und -Prozesse

Erfüllen nicht die Vorgaben des KWG, Mängel im Auslagerungsmanagement 4

Mängelbeseitigung unter Aufsicht des Sonderbeauftragten 2; Erhöhte Eigenmittelanforderungen 3

§ 25a KWG, BAIT

Auftragsbearbeitung (FDB)

Zahlreiche unbearbeitete Wertpapieraufträge, verzögerte Überträge, Bearbeitungsrückstand 1

Unverzüglicher Abbau des Rückstands, Maßnahmen zur Vermeidung erneuter Rückstände 1

§ 69 WpHG

Beschwerdemanagement (FDB)

Häufung von Kundenbeschwerden im Zusammenhang mit Auftragsstau 1

Unverzüglicher Abbau der Beschwerden 2

§ 80 WpHG, Art. 26 DelVO

Fusionsprozess (FNZ & FDB)

Risiko der Nichteinhaltung bankaufsichtlicher und verbraucherschützender Pflichten während der Fusion 2

Überwachung durch Sonderbeauftragten 2

Generelle Aufsichtspflichten

V. Synthese und Strategische Empfehlungen

A. Konsolidierte Systemische Risikosignale ("Red Flags")

Die Analyse der Situation bei FNZ und FDB offenbart nicht nur einzelne Problemfelder, sondern ein Geflecht aus miteinander verbundenen systemischen Schwächen, die sich gegenseitig verstärken. Die identifizierten Probleme in den Bereichen Governance, IT-Management, operative Ausführung und Compliance-Kultur bilden zusammenfassend folgende zentrale Risikosignale:

• Unzureichende IT-Governance & Risikomanagement: Dies wird durch die BaFin-Feststellungen zu IT-Mängeln und Fehlern im Auslagerungsmanagement 4, die wiederkehrenden operativen Probleme mit IT-Bezug 8 und die potenziellen Schwachstellen in der Salesforce-DIAMOS-Architektur deutlich belegt. Die Organisation scheint nicht über die notwendigen Strukturen und Prozesse zu verfügen, um ihre komplexe IT-Landschaft effektiv zu steuern und die damit verbundenen Risiken zu managen.
• Operative Instabilität & Prozessversagen: Die massiven Auftragsrückstände, verzögerten Überträge und die Flut an Kundenbeschwerden bei der FDB 1 sind klare Indikatoren dafür, dass Kernprozesse entweder grundlegend fehlerhaft konzipiert sind oder die bestehenden Systeme und Ressourcen die erforderliche Kapazität nicht bereitstellen können.
• Mangelhafte technische Kontrollen & Überwachung: Potenzielle Lücken in der Salesforce-Konfiguration (MFA-Ausnahmen, Gastnutzerzugriff), unzureichende API-Sicherheit an der Schnittstelle zu DIAMOS, mögliche Schwächen bei der Mandantentrennung und Defizite bei der Ereignisprotokollierung und -überwachung schaffen signifikante Sicherheits- und Compliance-Risiken.16
• Compliance-Defizite: Es besteht eine hohe Wahrscheinlichkeit der Nichteinhaltung der MaRisk AT 9 / BAIT-Anforderungen für Cloud-Auslagerungen.30 Ebenso sind Verstöße gegen die DSGVO wahrscheinlich, insbesondere durch potenzielle Schatten-IT und mangelnde Kontrolle über Datenverarbeitungsprozesse.33 Die Organisation scheint zudem unzureichend auf die kommenden DORA-Anforderungen vorbereitet zu sein.30
• Erhöhtes Risiko bei der Fusionsdurchführung: Der Versuch, eine komplexe Geschäftsverschmelzung inmitten einer regulatorischen Intervention und operativen Krise durchzuführen, erhöht das Risiko weiterer Fehler, Verzögerungen und eines Scheiterns der Integration erheblich.2
• Potenzielle Erosion von Vertrauen: Die Diskrepanz zwischen öffentlichen Beschwichtigungen 2 und der harten Realität der operativen Ausfälle 1, gepaart mit historischen Fällen von Pflichtverletzungen 46, birgt die Gefahr einer nachhaltigen Beschädigung der Beziehungen zu Kunden, Geschäftspartnern und der Aufsicht.

Diese Risikosignale deuten zusammengenommen auf eine mögliche organisatorische Kultur hin, die in der Vergangenheit möglicherweise Wachstum und strategische Initiativen (wie die Fusion) über die Sicherstellung fundamentaler operativer Stabilität, eines robusten Risikomanagements und strikter Compliance gestellt hat. Die Verfolgung einer signifikanten Akquisition (FDB durch FNZ 12) und die anschließende Fusionsplanung 10 fielen zeitlich mit dem Zusammenbruch grundlegender operativer Prozesse 1 und dem Versagen der IT-Governance 4 zusammen. Dies legt nahe, dass Managementaufmerksamkeit und Ressourcen möglicherweise zu Lasten der Aufrechterhaltung und Stärkung der Kernfähigkeiten und Kontrollen auf strategische Projekte gelenkt wurden.

Die systemische Natur der Probleme macht deutlich, dass punktuelle Korrekturen (wie die alleinige Abarbeitung des Auftragsstaus) nicht ausreichen werden. Eine nachhaltige Sanierung erfordert fundamentale Veränderungen in der Unternehmensführung, der Risikokultur, der IT-Architektur, im Prozessdesign und potenziell auch in der personellen Besetzung von Schlüsselpositionen. Die BaFin-Feststellungen zielen auf die "ordnungsgemäße Geschäftsorganisation" (§ 25a KWG) ab 1, ein Grundpfeiler, der Governance, Risiko, Ressourcen und Prozesse umfasst. Da die Probleme IT, Betrieb, Kundenservice und Compliance umspannen und technische Mängel zu operativen Ausfällen führen, die wiederum auf Governance-Schwächen zurückzuführen sind, ist ein ganzheitlicher Transformationsansatz unumgänglich.

B. Implikationen für Geschäftskontinuität und Zukunftsstrategie

Die festgestellte operative Instabilität und die IT-Schwächen stellen eine direkte Bedrohung für die Geschäftskontinuität (Business Continuity) dar. Die Unfähigkeit, Aufträge zuverlässig zu bearbeiten oder Kundeninteraktionen effektiv zu managen, beeinträchtigt das Kerngeschäft fundamental.

Die Krise wirkt sich auch massiv auf die Fusionsstrategie aus. Die Notwendigkeit, die Sanierung unter Aufsicht der BaFin durchzuführen, wird wahrscheinlich die Integrationszeitpläne verlängern, die Kosten erhöhen und die Realisierung geplanter Synergien erschweren oder verzögern. Die Aufsicht wird sicherstellen wollen, dass die Behebung der Mängel Priorität hat, bevor komplexe Integrationsschritte erfolgen.

Langfristig droht erheblicher Reputationsschaden. Insbesondere Geschäftspartner wie Finanzberater und Vermittler, die auf die Stabilität der FNZ/FDB-Plattform angewiesen sind (FNZ Bank als Nachfolgerin von ebase hat hier