Banken investieren Milliarden in ihre IT-Sicherheit. Firewalls werden gehärtet, Systeme segmentiert, Zugriffe kontrolliert. Und dennoch steigen die Schäden durch Cyberkriminalität weiter. In Deutschland zuletzt auf 289 Milliarden Euro pro Jahr laut Bitkom.

Der Grund ist strukturell: Angriffe richten sich zunehmend nicht mehr gegen einzelne Institutionen, sondern gegen die Verbindungen zwischen ihnen. APIs, Drittanbieter, integrierte Services – genau dort, wo Daten fließen und Verantwortung geteilt wird. Der Angriff auf die Krypto-Börse Bybit Anfang 2025 hat das exemplarisch gezeigt. Nicht die Plattform selbst wurde kompromittiert, sondern die Benutzeroberfläche eines angebundenen Dienstleisters. Ein einzelnes schwaches Glied reichte aus, um einen Schaden von rund 1,5 Milliarden US-Dollar zu verursachen.

Die neue Realität: Angriffe zielen auf Verbindungen, nicht auf Systeme

Wie tief diese Verwundbarkeit reicht, zeigt ein zweiter Vorfall, der erst Ende März 2026 bekannt wurde: Angreifer kompromittierten den Maintainer-Account des npm-Pakets axios, einer der populärsten HTTP-Bibliotheken in der JavaScript-Welt mit über 100 Millionen wöchentlichen Downloads. Über manipulierte Versionen schleusten sie eine Backdoor ein, die Windows, macOS und Linux gleichermaßen befällt. Der Einstiegspunkt war kein technischer Exploit, sondern Social Engineering gegen eine einzelne Person: Die zum Maintainer-Account hinterlegte E-Mail-Adresse wurde unbemerkt auf einen Angreifer-Account umgestellt. Google Threat Intelligence schreibt den Angriff der nordkoreanischen Gruppe UNC1069 zu. Der Fall zeigt: Selbst wer seine eigene Infrastruktur perfekt absichert, importiert mit jedem Open-Source-Paket potenzielle Schwachstellen aus Quellen, über die er keinerlei direkte Kontrolle hat. Die Angriffsfläche endet längst nicht mehr beim eigenen Code, sondern reicht bis tief in Build-Pipelines und Dependency-Bäume hinein.

Für API-basierte Finanzinfrastrukturen ist das ein systemisches Risiko. Sicherheit lässt sich nicht mehr isoliert denken. Sie ist eine Eigenschaft des gesamten Ökosystems. In vernetzten Finanzsystemen entsteht sie – oder scheitert – an den Schnittstellen. Genau an diesem Punkt setzt wealthAPI an. Als BaFin-regulierter Kontoinformationsdienst aggregieren und verarbeiten wir täglich Finanzdaten von tausenden Banken und Brokern. Für uns ist Sicherheit kein nachgelagerter Prozess und kein einzelnes Feature. Sie ist eine Architekturentscheidung. Und zwar bewusst dort getroffen, wo wir die Kontrolle abgeben müssen: an den Schnittstellen zu Dritten.

Dieser Artikel zeigt, wie wir diese Perspektive in konkrete Systeme, Prozesse und Standards übersetzen – von der ISO 27001-Zertifizierung bis zum Umgang mit Third-Party-Risiken in einer zunehmend vernetzten Finanzwelt.

Warum klassische Sicherheitsansätze nicht mehr ausreichen

Neue Qualität der Angriffe

Angriffe haben sich qualitativ verändert: KI-gestütztes Phishing ist personalisiert und kaum noch erkennbar, staatlich unterstützte Gruppen operieren auf Enterprise-Niveau und Ransomware entwickelt sich vom lauten Angriff zum stillen Datendiebstahl. Das Ziel ist nicht mehr die Störung von Systemen, sondern die unbemerkte Kompromittierung von Datenströmen.

Open Banking vergrößert die Angriffsfläche

Was uns als Branche besonders betrifft: API-basierte Geschäftsmodelle und Open-Banking-Integrationen erweitern die Angriffsfläche erheblich. Fintechs verfügen heute über eine breitere und fragmentiertere Datenbasis als viele klassische Banken – und gleichzeitig oft über weniger ausgereifte Sicherheitsstrukturen. Das führt zu einem strukturellen Ungleichgewicht: maximale Datenverfügbarkeit bei gleichzeitig erhöhter Angriffsfläche.

Vincent Haupert, promovierter Informatiker, Ex-Hacker und Gründer von Yaxi, der vor zehn Jahren durch das Aufdecken von Schwachstellen bei N26 bekannt wurde, brachte es kürzlich im FinanceFWD Podcast auf den Punkt: Viele Fintechs hätten in Sachen Sicherheit kaum dazugelernt. Begrenzte Budgets und andere Prioritäten stünden dem entgegen. Genau diese Lücke ist kein operatives Problem, sondern ein strukturelles. Und es lässt sich nicht durch einzelne Maßnahmen schließen, sondern nur durch Architektur.

Regulatorischer Druck als Katalysator

Auch die Regulierer haben reagiert. Seit Januar 2025 gilt der Digital Operational Resilience Act (DORA), der die BaFin zum zentralen Melde-Hub für IKT-Vorfälle im gesamten Finanzsektor macht. Neben Banken und Zahlungsdienstleistern müssen nun auch Versicherer und Wertpapierfirmen IKT-Vorfälle melden. 

Zudem haben EZB und BaFin für 2026 gezielte Überprüfungen und bedrohungsgeleitete Penetrationstests angekündigt. Schwächen in der IT-Governance oder beim Management von Drittanbieterrisiken gelten als schwerwiegende Compliance-Verstöße. Und mit der kommenden Financial Data Access (FiDA) Regulierung werden die Anforderungen an den Schutz von Finanzdaten nochmals verschärft und auf neue Datentypen ausgeweitet.

Unser Fundament: Sicherheit von Tag eins

Als ich im April 2024 erstmals ausführlichen über die Cybersicherheit bei wealthAPI schrieb, formulierte ich die ISO 27001-Zertifizierung als konkretes Ziel. Heute, knapp zwei Jahre später, haben wir dieses Ziel erreicht. Der Weg dorthin hat unsere gesamte Sicherheitsarchitektur auf ein neues Level gehoben. 

Doch die Grundprinzipien, die uns seit der Gründung leiten, sind dieselben geblieben. Sicherheit war bei wealthAPI nie ein nachträgliches Add-on, sondern von Anfang an Bestandteil der DNA. Die ISO 27001-Zertifizierung war dabei weder Selbstzweck noch reines Compliance-Projekt. Vielmehr war sie ein Mittel zur Systematisierung und Härtung unserer Architektur.

Was Sicherheit in der Praxis bedeutet

1. Qualität als erste Verteidigungslinie

Viele Sicherheitsprobleme entstehen durch interne Schwachstellen im Code. Um höchste Code-Qualität mit agilen Release-Zyklen zu vereinbaren, setzen wir von Beginn an auf testgetriebene Entwicklung (TDD). Die Applikation wird bei jeder noch so kleinen Änderung vollumfänglich und vollautomatisch getestet. Hinzu kommen verbindliche Peer Reviews nach dem 4-Augen-Prinzip für sämtliche Codeänderungen. Kein Code gelangt in die Produktivumgebung, ohne dass mindestens ein:e andere:r Entwickler:in ihn geprüft hat. Ergänzend nutzen wir KI-gestützte Analysen, um Muster, Anomalien und potenzielle Schwachstellen in komplexen Codeabhängigkeiten frühzeitig zu erkennen. Diese Systeme erweitern klassische statische Analysen, ersetzen aber keine menschliche Prüfung.

2. Infrastruktur: Standardisierung statt Eigenbau

Wir haben uns bewusst für standardisierte, gehärtete Cloud-Infrastruktur in der Google Cloud Frankfurt entschieden, statt eigene Systeme zu betreiben. Nicht weil Eigenlösungen per se unsicher sind, sondern weil standardisierte Plattformen kontinuierlich auf einem Niveau gehärtet werden, das intern kaum wirtschaftlich erreichbar ist.

Innerhalb der Google Cloud verwenden wir eine gekapselte Infrastruktur: Alle Komponenten laufen in einem eigenen Virtual Private Network (VPC) und sind von außen nicht sichtbar. Unsere Backups sind mit Data-at-Rest-Encryption verschlüsselt, besonders sensible Daten wie Login-Daten sind innerhalb dieser Gesamtverschlüsselung nochmals separat verschlüsselt. Darüber hinaus trennen wir konsequent zwischen sensitiven und weniger sensitiven Systemen.

Diese Netzwerksegmentierung bietet Defense-in-Depth: Selbst wenn eine Komponente kompromittiert wird, bleiben andere Systeme geschützt.

3. Datenklassifizierung: Wissen, was man schützt

In einem schnell wachsenden Fintech werden regelmäßig neue Systeme, Datenbanken und Services hinzugefügt. Die Übersicht über alle Assets zu behalten und konsistent zu klassifizieren, ist nicht trivial. Wir arbeiten mit einer dreistufigen Datenklassifizierung: 

• Confidential umfasst Username und Banking-Informationen, Transaktionsdaten im SEPA-Format, Wertpapier-Positionen und erkannte Verträge. 
• Restricted beinhaltet den Finanzdatenmaster wie Aktienkurse und Fondsprofile, Spending-Kategorisierungen sowie interne Policies. 
• Public bezieht sich auf Marketing-Materialien, Produktbeschreibungen und externe Policies.

Entscheidend ist weniger die Kategorisierung selbst als ihre konsequente Umsetzung: Jedes System wird automatisiert erfasst, klassifiziert und einem klaren Data Owner zugeordnet. Datenklassifizierung ist dabei kein einmaliger Prozess, sondern ein kontinuierlicher Abgleich mit der Realität – insbesondere wenn durch die bevorstehende FiDA-Regulierung neue Datentypen hinzukommen.

4. Zugriff: Konsequentes Least-Privilege-Prinzip

In einem API-basierten Geschäftsmodell ist Zugriffskontrolle ein zentraler Risikofaktor. Wir haben eine mehrschichtige Access-Control-Strategie implementiert, die auf einem formalisierten Target Operating Model (TOM) basiert. Das TOM operationalisiert das Need-to-Know-Prinzip durch ein striktes Rollenmodell: Role-Based Access Control (RBAC) statt individueller Nutzerberechtigungen, Multi-Factor Authentication (MFA) für alle produktiven Systeme, zeitlich begrenzte und auditierte Zugänge für hochsensible Operationen sowie zentrales API-Key-Management über ein dediziertes Secrets-Management-System, in dem Secrets und API-Keys niemals im Code oder in Repositories gespeichert werden.

Zugriffsrechte sind bei uns immer an aktuelle Rollen gebunden. Wenn Mitarbeiter:innen die Abteilung wechseln, ändern sich die Rechte automatisch. Historisch gewachsene Berechtigungen existieren nicht. Quartalsweise Reviews stellen zusätzlich sicher, dass keine „Zombie-Accounts“ bestehen bleiben. Die Formalisierung durch das TOM hat uns geholfen, aus einem anfänglich eher impliziten Need-to-Know ein messbares, auditfähiges System zu machen.

5. Incident Response: Reaktionsfähigkeit statt Illusion von Sicherheit

Vollständige Sicherheit gibt es nicht. Entscheidend ist, wie schnell und strukturiert auf Vorfälle reagiert wird. Unser Incident Response Plan basiert auf vier Severity-Levels: 

• P0 (Critical) umfasst aktiv ausgenutzte Schwachstellen mit sofortiger Eskalation.
• P1 (High) bezeichnet wahrscheinliche Bedrohungen, etwa einen verlorenen Laptop ohne Verschlüsselung oder Malware-Verdacht. 
• P2 und P3 (Medium/Low) decken Verdachtsfälle ab, die strukturiert über unser Ticket-System untersucht werden. 

Jeder Level hat definierte Eskalationspfade, Kommunikationskanäle und Post-Mortem-Prozesse. Der Fokus liegt aber nicht auf der Vermeidung jedes Vorfalls, sondern auf der Fähigkeit, Auswirkungen schnell zu begrenzen und systematisch daraus zu lernen. Quartalsweise Incident-Response-Übungen unter realistischen Bedingungen sind dabei kein formaler Prozess, sondern ein zentraler Bestandteil unserer Sicherheitsstrategie.

6. Third-Party-Risiken als systemisches Thema

Die größte Schwachstelle in vernetzten Systemen liegt häufig außerhalb der eigenen Organisation. Der Bybit-Fall hat der gesamten Branche vor Augen geführt, wie schnell ein kompromittierter Dienstleister zum eigenen Problem wird.

Wir haben deshalb einen strukturierten Third-Party-Management-Prozess etabliert: Vor der Einbindung eines neuen Dienstleisters führen wir eine Sicherheitsbewertung durch. Anbieter, die Confidential- oder Restricted-Daten verarbeiten, müssen nachweisen, dass sie unsere Sicherheitsstandards erfüllen – idealerweise durch eine eigene ISO 27001-Zertifizierung. Datenschutz- und Sicherheitsanforderungen sind fester Bestandteil aller Verträge, inklusive Audit-Rechte und Incident-Notification-Pflichten. Vendor-Risiken werden nicht nur bei Vertragsabschluss bewertet, sondern regelmäßig re-evaluiert.

Die zentrale Erkenntnis: Sicherheit endet nicht an der eigenen Systemgrenze. In vernetzten Systemen liegt das größte Risiko oft genau dort, wo Kontrolle abgegeben wird: bei Drittanbietern, Schnittstellen und Abhängigkeiten.

Sicherheitskultur: Der entscheidende Faktor

Technologie allein reicht nicht aus. Der größte Erfolgsfaktor für unser Informationssicherheits-Managementsystem (ISMS) war die Schaffung einer Sicherheitskultur, die von allen Mitarbeiter:innen getragen wird. Vier Prinzipien prägen unseren Ansatz:

1. Sicherheit beginnt in der Organisation. Selbst die beste Sicherheitsarchitektur ist wirkungslos, wenn diejenigen, die damit interagieren, nicht über die notwendigen Qualifikationen verfügen. Alle Mitarbeiter:innen durchlaufen beim Onboarding und dann jährlich ein Security-Awareness-Training – von Phishing-Erkennung bis zu sicheren Passwort-Praktiken. Unsere Clear-Desk/Clear-Screen-Policy sorgt dafür, dass mobile Geräte nach fünf Minuten automatisch gesperrt werden. Ein verbindlicher Code of Conduct definiert klare Erwartungen an das online und offline Verhalten aller Mitarbeiter:innen.
2. Organisation bestimmt Sicherheit. Bei uns gibt es keine historischen Zugriffsrechte, sondern nur aktuelle Rollenprofile. Diese organisatorische Disziplin ist Voraussetzung dafür, dass technische Sicherheitsmaßnahmen überhaupt greifen können. Quartalsweise Access Reviews sind ein unverzichtbares Werkzeug gegen schleichende Rechteausweitung.
3. Security by Design. Die Berücksichtigung des Sicherheitsaspekts ist von entscheidender Bedeutung im Service-Design – und zwar von der ersten Zeile Code an. Jedes neue Feature, jeder neue Service wird bei wealthAPI von Anfang an mit Sicherheit im Fokus entwickelt. Das gilt für die Architektur ebenso wie für das Datenmodell und die API-Schnittstellen.
4. Früherkennung statt Perfektion. Menschen machen Fehler. Systeme sind deshalb darauf ausgelegt, Fehler früh sichtbar zu machen und ihre Auswirkungen zu begrenzen. Wir setzen auf mehrschichtige Kontrollen, automatisierte Alarme und eine Kultur, in der das Melden von Fehlern als Chance zur Verbesserung gesehen wird. Ergänzt wird dies durch den systematischen KI-Einsatz in der Code-Prüfung, der als zusätzliches Sicherheitsnetz fungiert.

Diese Prinzipien sind im Rahmen unseres ISMS formalisiert, aber vor allem im operativen Alltag verankert. Technische Maßnahmen schaffen Sicherheit, organisatorische Disziplin hält sie aufrecht.

Ausblick: Regulierung als Mindeststandard, nicht als Ziel

Mit der kommenden FiDA-Regulation steht die nächste große Welle regulatorischer Veränderungen bevor. FiDA wird die Anforderungen an Finanzdatenaggregation und -schutz nochmals verschärfen und weit über reine PSD2-Zahlungskontendaten hinausgehen: Wertpapiere, Kryptowährungen, Versicherungen und weitere Finanzprodukte werden erfasst.

Unsere ISO 27001-Zertifizierung ist ein entscheidender Baustein, um „FiDA-ready“ zu sein. Die durch das ISMS etablierten Prozesse decken bereits viele der erwarteten FiDA-Anforderungen ab. Unsere flexible Datenklassifizierung ist auf die Vielfalt der erweiterten Datentypen vorbereitet. Die granulare Dokumentation, wer wann auf welche Daten zugreift, bildet das Fundament für FiDA-konforme Consent-Management-Systeme. Und unsere etablierten Incident-Response-Prozesse ermöglichen uns, Sicherheitsvorfälle schnell zu erkennen, zu melden und zu beheben.

Auch DORA setzt als neuer Maßstab den Rahmen. Die BaFin als Melde-Hub für IKT-Vorfälle erhöht die Transparenzanforderungen für den gesamten Finanzsektor. Bedrohungsgeleitete Penetrationstests werden Pflicht. Durch unsere quartalsweisen Simulationsübungen und bestehenden Incident-Response-Prozesse sind wir hier gut gerüstet.

Gleichzeitig verstehen wir Regulierung nicht als Zielzustand, sondern als Rahmen. Der PDCA-Zyklus (Plan, Do, Check, Act) ist bei uns keine ISO-Floskel, sondern gelebte Praxis. Quartalsweise Risk Reviews, jährliche Policy Reviews, Lessons Learned aus jedem Sicherheitsvorfall – egal wie klein. Und ein Aspekt, der mir besonders am Herzen liegt: Sicherheit endet nicht an unserer Systemgrenze. Wir coachen unsere Kunden und Partner aktiv, um Mindestsicherheitsstandards zu gewährleisten. In einer vernetzten Datenökonomie, in der ein kompromittierter Drittanbieter zur eigenen Schwachstelle werden kann, ist Sicherheit eine Gemeinschaftsaufgabe.

Fazit: Sicherheit entsteht im System

Für API-basierte Finanzdienstleister wie wealthAPI ist Informationssicherheit keine isolierte Disziplin. Sie ist eine systemische Eigenschaft, die sich aus Architektur, Prozessen und dem Umgang mit Partnern ergibt.

Unsere Partner vertrauen uns ihre Finanzdaten an, weil wir nachweisbare Sicherheit bieten: durch BaFin-Regulierung, durch ISO 27001-Zertifizierung und durch eine Sicherheitskultur, die im täglichen Handeln sichtbar wird. In einer Welt, in der 64 Prozent der Topmanager im Finanzsektor Cyberangriffe als größte Herausforderung bis 2030 sehen, ist diese nachweisbare Sicherheit sowohl ein Wettbewerbsvorteil als auch eine Vertrauensfrage.

Die ISO 27001-Zertifizierung war dabei nicht das Ziel. Sie war der Startpunkt. Entscheidend ist die Fähigkeit, Sicherheit kontinuierlich weiterzuentwickeln und auf neue Bedrohungen zu reagieren. In einer vernetzten Finanzwelt gilt: Die Sicherheit eines Systems wird nicht an seiner stärksten Stelle gemessen, sondern an seiner schwächsten Verbindung.

Und genau diese Verbindungen sind es, die in modernen Finanzarchitekturen über Stabilität oder Risiko entscheiden.

Wer sich im Kontext von DORA, FiDA und API-basierten Geschäftsmodellen mit der Absicherung komplexer Datenflüsse auseinandersetzt, sollte Sicherheit nicht isoliert betrachten – sondern als Eigenschaft des gesamten Systems.