API- und JSON-Überweisungen

Externe APIs

Externe APIs werden in Bankumgebungen aufgrund der strengen Sicherheitsanforderungen von Finanzinstituten auf Distanz zum Kernsystem und erst recht zum Hauptbuchsystem der Bank gehalten. Für diese indirekte Anbindung sprechen mehrere überzeugende Gründe, die allesamt dem Schutz sensibler Informationen und der Betriebsintegrität der Kernfunktionen der Bank dienen:

1. Isolierung sensibler Daten

Das Kernbankensystem enthält die sensibelsten und wesentlichsten Daten der Kunden und Prozesse einer Bank, etwa Aufzeichnungen und Finanzdaten der Kunden; das Hauptbuchsystem enthält sämtliche Kontostände und Transaktionsdaten. Eine direkte Anbindung des Kernbank- bzw. Hauptbuchsystems an externe Systeme über APIs könnte das Risiko von Datenschutzverletzungen und der Manipulation von Daten und Aufzeichnungen erheblich erhöhen. Indem Banken API-Interaktionen auf eine Zwischenschicht oder ein peripheres System beschränken, können sie den Datenzugriff kontrollieren und überwachen und unbeabsichtigte oder unbefugte Datenschutzverletzungen verhindern.

2. Minimierung der Angriffsflächen

Würde externen APIs eine direkte Verbindung zum Kernbankensystem oder zum Hauptbuchsystem gestattet, entstünde ein zusätzlicher Zugangspunkt, der die Angriffsfläche für böswillige Akteure vergrößert. Je mehr Verbindungspunkte unmittelbar zum Hauptbuch führen, desto höher ist das Risiko, dass Angreifer in das System eindringen. Indirekte Verbindungen, in der Regel über eine Middleware-Schicht oder ein API-Gateway, wirken als Schutzpuffer: Sie prüfen und filtern Zugriffsanfragen und bearbeiten sie in kontrollierter und überwachter Weise.

3. Erweiterte Zugriffskontrolle

Durch die Weiterleitung externer API-Übertragungen über eine zwischengeschaltete Ebene können Banken zusätzliche Zugriffskontrollmechanismen implementieren, darunter Ratenbegrenzung, Authentifizierung und Berechtigungsprüfungen. Dieses Zwischensystem validiert die Echtheit und Legitimität jeder Anfrage, bevor es geprüfte Daten oder Anweisungen an das Kernsystem innerhalb des internen Banksystems weiterleitet. Es setzt strikte Zugriffsrichtlinien durch und stellt sicher, dass nur geprüfte Anfragen vom Kernsystem an das Ledger-System weitergegeben werden.

4. Sicherstellung der Datenintegrität

Ein direkter Zugriff externer APIs könnte Risiken für die Datenintegrität bergen. Würden externe Systeme unmittelbar mit dem Hauptbuch interagieren, könnten bereits geringfügige Fehler oder unbeabsichtigte Interaktionen die Konsistenz und Richtigkeit der Daten beeinträchtigen. Ein zwischengeschaltetes System übernimmt die Validierung, übersetzt API-Anfragen und stellt sicher, dass sie korrekt und zulässig sind, bevor sie das Hauptbuch erreichen. Diese kontrollierte Interaktion ist unerlässlich, um die Stabilität und Verlässlichkeit der Finanzaufzeichnungen zu gewährleisten.

5. Aufsichtsrechtliche Compliance und Prüfung

Banken unterliegen strengen regulatorischen Rahmenwerken, die rigorose Sicherheitsmaßnahmen erfordern, insbesondere beim Datenzugriff und bei der Datenverarbeitung. Wenn externe API-Anfragen über ein indirektes, kontrolliertes System verarbeitet werden, vereinfacht dies die Einhaltung der Vorschriften, da eine klare Abgrenzung zwischen dem Hauptbuch und externen Systemen besteht. Dies ermöglicht eine detaillierte Protokollierung und Prüfung jeder Transaktion und stellt sicher, dass jede externe Interaktion vollständig nachvollziehbar und eindeutig zurechenbar ist, ohne sensible Hauptbuchdaten offenzulegen.

6. Verringerung systemischer Risiken

Würden externe APIs direkt mit dem Hauptbuchsystem verbunden, könnte jede Schwachstelle oder jeder Exploit innerhalb dieser APIs unmittelbar die zentralen Finanzaufzeichnungen des Instituts beeinträchtigen. Ein indirekter Zugriff trägt dazu bei, Risiken einzudämmen und zu mindern, indem er die Isolierung des Hauptbuchs im Fall einer Sicherheitsverletzung oder eines Systemausfalls in der externen API ermöglicht. Durch die indirekte Anbindung stellen Banken sicher, dass kritische Systeme sicher, betriebsfähig und widerstandsfähig bleiben, selbst wenn bei externen Systemen Störungen auftreten.

Kurz gefasst

Das indirekte Anbindungsmodell mit Middleware oder API-Gateway stellt sicher, dass das Hauptbuch der Bank gegenüber potenziellen Bedrohungen durch externe Verbindungen abgeschirmt bleibt und dennoch ein sicherer, kontrollierter Datenaustausch mit autorisierten Dritten möglich ist. Diese mehrschichtige Sicherheitsarchitektur wahrt die Vertraulichkeit, Integrität und Verfügbarkeit der Daten und entspricht bewährten Verfahren der Cybersicherheit sowie den aufsichtsrechtlichen Standards.

Banking-APIs besser verstehen

Banking-APIs fungieren als Vermittler, die Drittentwicklern und Unternehmen den Zugriff auf Bankfunktionen und Bankdaten auf sichere und kontrollierte Weise ermöglichen. Dieser Zugang ist entscheidend für die Entwicklung von Anwendungen, die unmittelbar mit den Systemen einer Bank interagieren können, und ermöglicht so eine Vielzahl von Finanzdienstleistungen, ohne dass das Rad neu erfunden werden muss.

Das breite Spektrum der Banking-API-Typen

Banking-APIs lassen sich grob in vier Haupttypen einteilen, die jeweils unterschiedlichen Zwecken dienen und verschiedene finanzielle Anforderungen abdecken:

1. Core-Banking-APIs: Diese APIs konzentrieren sich auf grundlegende Bankgeschäfte wie Einlagen, Kreditvergabe und grenzüberschreitende Transaktionen von KMU. Durch den Zugang zu diesen wesentlichen Diensten ermöglichen Core-Banking-APIs Fintech-Anwendungen, traditionelle Bankfunktionen reibungslos einzubinden.
2. Plug-&-Play-APIs: Diese auf Finanzprozesse wie Handel und Buchhaltung zugeschnittenen APIs umfassen auch Authentifizierungsdienste über OAuth. Sie lassen sich leicht in bestehende Systeme integrieren und ermöglichen so eine rasche Einführung und Umsetzung.
3. APIs für Karten, Wallets und Überweisungen: Diese Kategorie umfasst Kartenausgabe, Wallets, Mehrwährungsgeschäfte und Betrugsüberwachung, häufig bereitgestellt mit Software-Entwicklungskits (SDKs). Sie sind unverzichtbar für Anwendungen, die Zahlungen, Währungsumtausch und die Absicherung von Transaktionen abwickeln.
4. Acquiring-APIs: Diese auf die Zahlungsakzeptanz ausgerichteten APIs ermöglichen mobile Zahlungen, Near Field Communication (NFC)-Lösungen, Online-Kartenakzeptanz und mehr. Sie spielen eine wesentliche Rolle bei der Erweiterung der Wege, auf denen Unternehmen Zahlungen akzeptieren können.

REST und SOAP: Architekturstile bei Bank-APIs

Im Banking-API-Bereich herrschen zwei wesentliche Kommunikationsparadigmen vor:

• REST (Representational State Transfer) ist ein Architekturstil: zustandslose Anfragen und Antworten über HTTP, in der Regel mit JSON als Datenformat. Er ist schlank, gut skalierbar und dominiert moderne Open-Banking-Schnittstellen.
• SOAP (Simple Object Access Protocol) hingegen ist ein formales, XML-basiertes Protokoll mit integrierten Standards für Sicherheit (WS-Security) und Fehlerbehandlung, das in älteren Kernbankensystem-Integrationen weiterhin verbreitet ist.

Beide Paradigmen bieten jeweils eigene Vorteile; die Wahl zwischen ihnen richtet sich nach den spezifischen Anforderungen der jeweils umzusetzenden Bankdienstleistung.

Banking-APIs stehen an der Spitze der digitalen Transformation des Finanzsektors und bilden eine Brücke zwischen traditionellen Bankdienstleistungen und innovativen Fintech-Lösungen. Indem Banken diese technologischen Fortschritte nutzen, können sie nicht nur ihre betriebliche Effizienz und ihren Kundenservice verbessern, sondern auch in einer zunehmend digitalen Welt wettbewerbsfähig bleiben. Mit der weiteren Entwicklung der Finanzbranche wird der strategische Einsatz von Banking-APIs zweifellos eine entscheidende Rolle bei der Gestaltung ihrer Zukunft spielen.

Die API-basierte Kommunikation steigert die Effizienz des Bankbetriebs, da sie eine strukturierte Interaktion zwischen Systemen ermöglicht. APIs stellen jedoch keine eigenständigen Zahlungsmechanismen dar. Über eine API übermittelte Daten, einschließlich JSON-formatierter Anfragen und Antworten, stellen Transaktionsanweisungen oder Systemkommunikation dar, nicht jedoch eine Abwicklung (Settlement).

Die Ausführung jeder über eine API veranlassten Überweisung bleibt von zugelassenen Finanzinstituten und anerkannter Zahlungsinfrastruktur abhängig. Das Vorliegen einer API-Antwort oder strukturierter Datenausgabe bestätigt für sich genommen nicht, dass Gelder überwiesen wurden.

JSON in API-basierten Bankumgebungen

In der modernen Bankinfrastruktur dient JSON als standardisiertes Datenformat in API-Kommunikationsschichten. Seine Rolle ist rein technischer Natur: Es strukturiert und überträgt Informationen zwischen Systemen. Es führt keine Transaktionen aus, hält keinen Wert und ersetzt keine institutionellen Prozesse.

Im API-basierten Bankgeschäft wird JSON typischerweise zur Kodierung von Zahlungsanweisungen, Kontodaten, Transaktionsmetadaten und Systemantworten in einem Format verwendet, das sowohl maschinenlesbar als auch plattformübergreifend interoperabel ist. Dadurch können externe Anwendungen, Kundenschnittstellen und interne Banksysteme in einer kontrollierten Umgebung effizient miteinander kommunizieren.

Wird eine Zahlung über eine API ausgelöst, kann die Anweisung im JSON-Format übermittelt werden. Die eigentliche Überweisung der Gelder wird jedoch von der Bank separat über etablierte Zahlungsinfrastrukturen wie SWIFT, SEPA, RTGS oder andere anerkannte Abwicklungssysteme ausgeführt. JSON übermittelt lediglich die Anweisung; es führt die Überweisung nicht durch.

Funktionale Rolle bei API-Transaktionen

In der Praxis dient JSON als Schnittstellenschicht zwischen clientseitigen Anwendungen und der Bankinfrastruktur. Eine typische API-Anfrage kann strukturierte Felder wie Absenderidentifikation, Begünstigtendaten, Kontonummern, Währung, Betrag und Transaktionsreferenzen enthalten. Diese Daten werden vom empfangenden System validiert und verarbeitet, das anschließend entscheidet, ob die Transaktion fortgeführt werden kann.

Nach der Validierung gelangt die Anweisung in die interne Verarbeitungsumgebung der Bank, in der Compliance-Prüfungen, Risikokontrollen und Autorisierungsverfahren angewandt werden. Erst nach diesen Schritten wird die Transaktion an den jeweiligen Abwicklungskanal weitergeleitet.

JSON ist daher nur eine Komponente innerhalb eines umfassenderen Transaktionslebenszyklus. Es ersetzt nicht:

• institutionelle Autorisierung
• Compliance-Prüfung
• Validierung auf Kontoebene
• Clearing- und Abwicklungsprozesse

Trennung von Daten und Abwicklung

Ein wiederkehrendes Missverständnis entsteht, wenn Datenübermittlung mit Geldbewegung gleichgesetzt wird. JSON kann als Datenformat eine Transaktion detailliert beschreiben, jedoch weder erzeugen noch abwickeln. Das Vorliegen einer JSON-Nutzlast stellt, unabhängig von ihrer scheinbaren Vollständigkeit, keinen Nachweis dafür dar, dass Gelder transferiert wurden.

Diese Unterscheidung ist sowohl in betrieblicher Hinsicht als auch im Risikokontext entscheidend. Eine wirksame Übertragung muss sich widerspiegeln in:

• das Hauptbuch des sendenden Instituts
• das Hauptbuch des empfangenden Instituts
• das zwischengeschaltete Abwicklungssystem, soweit anwendbar

Ohne diese Elemente hat unabhängig von jeder Datendarstellung keine Übertragung stattgefunden.

Integration von Banking-APIs

In regulierten Umgebungen wird JSON in der Regel in sichere API-Frameworks eingebettet. Diese Frameworks erzwingen Authentifizierung, Verschlüsselung und Zugriffskontrolle und stellen sicher, dass nur berechtigte Stellen Finanzdaten initiieren oder abrufen können.

Typische Anwendungsfälle sind:

• Zahlungsauslösung über Kundenschnittstellen
• Abruf von Transaktionshistorien
• Saldenabfragen
• Begünstigtenverwaltung
• Statusmeldungen in Echtzeit

Diese Funktionen steigern Effizienz und Interoperabilität, bleiben jedoch von der zugrunde liegenden Bankinfrastruktur abhängig.

Risikoaspekte

Da JSON für Menschen lesbar und leicht reproduzierbar ist, kann es außerhalb kontrollierter Umgebungen missbräuchlich verwendet werden. Ein JSON-Dokument lässt sich ohne Schwierigkeiten erstellen, verändern oder fälschen. Es kann daher nicht als eigenständiger Nachweis einer abgeschlossenen Transaktion dienen.

In der professionellen Bankpraxis stützt sich die Überprüfung stets auf institutionelle Aufzeichnungen und anerkannte Zahlungssysteme, nicht auf eigenständige Datendarstellungen.

Eine umfassendere Darstellung der mit Überweisungen verbundenen Risiken finden Sie unter: Transfer Risk Fraud Awareness

Institutionelle Einordnung

Im Rahmen der operativen Ausgestaltung von IFB ist JSON als technischer Standard für die API-Kommunikation anerkannt. Es ist weder als Zahlungsmechanismus noch als Abwicklungsmethode anerkannt.

Alle Transaktionen müssen, unabhängig davon, wie sie veranlasst werden, letztlich über regulierte Finanzinfrastruktur ausgeführt werden. JSON kann die Kommunikation erleichtern, verändert jedoch nicht die grundlegende Funktionsweise des Bankgeschäfts.

Gesamtposition

JSON steigert die Effizienz digitaler Bankschnittstellen, indem es einen strukturierten Datenaustausch ermöglicht. Sein Nutzen liegt in der Kommunikation, nicht in der Ausführung. Eine Währungsüberweisung bleibt eine Aufgabe von Kreditinstituten, regulierten Systemen und Abwicklungsprozessen. JSON ist ein Übertragungsweg für Informationen innerhalb dieser Struktur, kein Ersatz für sie.

Begriffe im Zusammenhang mit alternativen oder herkömmlichen Übertragungsmethoden sind im Kontext der Bankinfrastruktur auszulegen. Solche Begriffe können Kommunikationskanäle, interne Verarbeitungsmethoden oder historische Praktiken beschreiben, ersetzen jedoch nicht das Erfordernis regulierter Institute, anerkannter Zahlungssysteme und förmlicher Abwicklungsverfahren.

Jede Übertragung muss, unabhängig von der Bezeichnung, letztlich innerhalb des etablierten Finanzsystems verarbeitet, abgewickelt und abgestimmt werden.

Wenn Sie mehr darüber erfahren möchten, wie Sie Gelder oder Vermögenswerte auf Ihre Konten bei uns übertragen, wenden Sie sich bitte an Marie Mayer.