Open-Banking-APIs
Open Banking: Kontodaten und Zahlungen über Bank-APIs
Kontoinformationen und Zahlungsauslösung über regulierte Bank-APIs und Aggregatoren, mit Umgang mit Einwilligungen und Tokens.
Blueprint
Seitwärts scrollen, um die ganze Zeichnung zu sehen.
Open Banking: Daten und Zahlungen mit Einwilligung des Kunden
Der Kunde erteilt seine Einwilligung, der Konnektor hält die Tokens, und jeder Aufruf bei der Bank wird autorisiert und protokolliert. Wenn eine Einwilligung abläuft oder zurückgezogen wird, fragt die App den Kunden erneut, statt stillschweigend zu scheitern.
- Primärer Ablauf
- Asynchron
- Fehlerpfad
Der Ablauf in 7 Schritten
Der Ablauf Schritt für Schritt
- Von Kunde nach Ihre App oder Plattform: Erteilt Einwilligung (primärer Ablauf).
- Von Ihre App oder Plattform nach Open-Banking-Konnektor: Konto- und Zahlungsanfragen, über REST/JSON (primärer Ablauf).
- Von Open-Banking-Konnektor nach Bank-APIs oder Aggregator: Autorisierte API-Aufrufe, über OAuth 2.0 · FAPI · REST (primärer Ablauf).
- Von Bank-APIs oder Aggregator nach Open-Banking-Konnektor: Salden, Transaktionen und Zahlungsstatus, über REST/JSON · webhook (asynchron).
- Von Open-Banking-Konnektor nach ERP oder Hauptbuch: Vereinheitlichte Transaktionen, über REST/JSON (primärer Ablauf).
- Von Bank-APIs oder Aggregator nach Open-Banking-Konnektor: Einwilligung abgelaufen oder zurückgezogen, über HTTP 401 · 403 (Fehlerpfad).
- Von Open-Banking-Konnektor nach Ihre App oder Plattform: Kunde um Erneuerung der Einwilligung gebeten (Fehlerpfad).
Überblick
Open Banking ermöglicht einer Anwendung, mit Einwilligung des Kunden Konten zu lesen und Zahlungen über regulierte Bank-APIs auszulösen. Es treibt Kontenaggregation, Bonitätsprüfungen im Kreditgeschäft, Pay-by-Bank-Checkouts und Treasury-Sichten über mehrere Banken.
Das Referenzdesign setzt einen Open-Banking-Konnektor zwischen Ihre Anwendung und die Banken, entweder direkt oder über einen lizenzierten Aggregator. Der Konnektor führt die Einwilligungsstrecke aus, hält die Tokens sicher, ruft die Bank-APIs nach Standards wie Berlin Group NextGenPSD2 oder dem UK Open Banking Standard auf und überführt die Daten jeder Bank in ein einheitliches Modell.
Eine Einwilligung ist nicht dauerhaft, und das Design plant damit. Läuft sie ab oder wird sie widerrufen, wird der Kunde um Erneuerung gebeten, statt dass die Anwendung stillschweigend Daten verliert. Jeder Aufruf ist autorisiert, protokolliert und an die Einwilligung gebunden, die ihn erlaubt hat.
So funktioniert der Ablauf
Der Kunde erteilt die Einwilligung
Der Kunde wählt seine Bank, sieht, was geteilt wird und wie lange, und authentifiziert sich bei der Bank, die zurück zu Ihrer Anwendung leitet.
Ihre Anwendung fragt an
Ihre Anwendung fordert Salden, Transaktionen oder eine Zahlung über die API des Konnektors an, nie direkt bei der Bank.
Der Konnektor ruft die Bank auf
Der Konnektor nutzt die gespeicherten Tokens für autorisierte Aufrufe der Bank-API oder des Aggregators und folgt dabei dem Sicherheitsprofil, das die Bank verlangt.
Daten und Status kommen zurück
Salden, Transaktionen und Zahlungsstatus kehren als Antworten oder Webhooks zurück, und der Konnektor normalisiert sie in ein Modell über alle Banken hinweg.
Die Daten nutzen
Normalisierte Transaktionen speisen Ihr Produkt, Ihre Risikomodelle oder Ihr ERP für Liquiditätslage und Abstimmung.
Wenn etwas fehlschlägt
Einwilligung läuft ab oder wird widerrufen
Die Bank lehnt den Aufruf ab. Der Konnektor markiert die Einwilligung als nicht mehr gültig, und Ihre Anwendung bittet den Kunden um Erneuerung und erklärt, warum.
Eine Zahlung wird abgelehnt
Status und Grund der Bank kommen über die API oder einen Webhook zurück, und der Kunde und Ihr Betriebsteam sehen das Ergebnis sofort.
Eine Bank begrenzt den Zugriff
Banken begrenzen, wie oft Daten ohne den Kunden abgerufen werden dürfen. Der Konnektor plant Aktualisierungen innerhalb dieser Grenzen und wartet ab, wenn eine Bank es signalisiert.
Eine Bank-API ist nicht erreichbar
Aufrufe werden mit wachsenden Abständen wiederholt, die letzten guten Daten mit ihrem Alter angezeigt und eine Warnung ausgelöst, wenn die Störung anhält.
Standards und Systeme
- Banking-Standards und -Kanäle
- PSD2
- Berlin Group NextGenPSD2
- UK Open Banking Standard
- FAPI
- Integration
- REST
- Webhooks
- Identität und Zugriff
- OAuth 2.0
- OpenID Connect
Fragen und Antworten
Sollten wir Banken direkt oder über einen Aggregator anbinden?
Ein Aggregator gibt Ihnen viele Banken über eine API und behandelt die Unterschiede jeder Bank, zu Kosten pro Aufruf oder Verbindung. Direkte Verbindungen geben mehr Kontrolle und eignen sich für wenige wichtige Banken. Viele Produkte beginnen mit einem Aggregator und ergänzen später direkte Verbindungen. Wir vergleichen die Optionen für die Banken und Länder, die Sie brauchen.
Brauchen wir eine Lizenz für Open Banking?
Kontoinformationen und Zahlungsauslösung sind in vielen Ländern regulierte Tätigkeiten. Entweder hält Ihr Unternehmen die Zulassung, oder Sie arbeiten über einen lizenzierten Anbieter, der sie hält. Was gilt, hängt von Ihrem Land und Anwendungsfall ab und sollte von Ihren Rechts- und Compliance-Beratern bestätigt werden. Wir bauen die Integration für den Weg, den Sie wählen.
Wie wird die Einwilligung des Kunden gehandhabt?
Der Kunde sieht, welche Daten zu welchem Zweck und für wie lange geteilt werden, und authentifiziert sich bei seiner eigenen Bank. Der Konnektor speichert Einwilligung und Tokens verschlüsselt, und jeder Aufruf ist an eine gültige Einwilligung gebunden. Kunden können die Einwilligung widerrufen, und der Konnektor ruft diese Bank dann nicht mehr für sie auf.
Welche Banken und Länder sind abgedeckt?
Die Abdeckung hängt von den Regeln der Region und den APIs der Banken ab. Die Europäische Union und das Vereinigte Königreich sind unter PSD2 und dem UK Open Banking Standard breit abgedeckt. Anderswo variiert die Abdeckung, und Aggregatoren füllen einige Lücken. Wir prüfen die Abdeckung für die Banken Ihrer Kunden, bevor Sie sich auf ein Design festlegen.
Ersetzt Open Banking Host-to-Host-Bankanbindungen?
Für die meisten Aufgaben im Unternehmens-Treasury nicht. Host-to-Host-Kanäle verarbeiten Massenzahlungsdateien und vollständige Auszüge für Ihre eigenen Konten. Open Banking eignet sich für kundennahe Produkte, Echtzeit-Salden und einzelne Zahlungen. Viele Unternehmen nutzen beides: Host-to-Host für ihre eigenen Zahlungsläufe und Open Banking für ihre Kunden.
Wie werden Open-Banking-Daten geschützt?
Tokens und Einwilligungsdatensätze sind im Ruhezustand verschlüsselt, nur der Konnektor kann sie nutzen, und jeder Aufruf wird mit der dahinterstehenden Einwilligung protokolliert. Wir erheben nur die Daten, die der Zweck braucht, und legen ihre Aufbewahrung fest. Datenschutzregeln wie die DSGVO gelten für diese Daten, und wir entwerfen mit Ihrem Datenschutzbeauftragten.
Beginnen Sie mit einem Gespräch, nicht mit einem Vertrag.
Sagen Sie uns, was Sie bauen, verbinden oder absichern möchten. Ein Architekt geht es mit Ihnen durch und empfiehlt dann, wo Sie beginnen sollten.
Wie es weitergeht
Terminabstimmung
Unser Team schreibt Ihnen, um einen Termin für das Gespräch zu vereinbaren.
Beratungsvorgespräch
Ein kostenlose 30-minütige Online-Vorberatung: Wir gehen Ihre Ziele, Systeme und Rahmenbedingungen durch.
Readiness-Review
In einer kostenlose 48-stündige Readiness-Review prüft ein Principal Architect Ihr Projekt gegen die 6-Punkte-Definition of Ready und empfiehlt den passenden Track.
Wahl des Tracks
Projekte mit klarem Leistungsumfang erhalten innerhalb von 3–5 Werktagen ein verbindliches Angebot. Projekte in der Konzeptphase starten im Blueprint Studio. Ein laufendes System, das ausfällt, nicht dokumentiert ist oder integriert werden muss, beginnt mit einer Diagnose von 1–2 Wochen. Blueprint Studio und Diagnose haben jeweils ein festes Honorar, das im Angebot genannt wird.