Eine PSD2 Open Banking API ist die Schnittstelle, über die Banken registrierten Drittanbietern Zugriff auf Zahlungskonten geben: Kontostände und Umsätze lesen (AIS), Zahlungen auslösen (PIS) und Deckung prüfen (Funds Confirmation). Im deutschsprachigen Raum ist dafür der Standard NextGenPSD2 der Berlin Group verbreitet. Für das Produktdesign zählen zwei Regeln mehr als jede Spezifikation: Ohne aktive Nutzeranfrage darf ein Kontoinformationsdienst in der Regel höchstens viermal in 24 Stunden abrufen, und spätestens nach 180 Tagen muss sich der Nutzer erneut stark authentifizieren (RTS 2018/389, geändert durch Delegierte Verordnung 2022/2360).
Was die PSD2 vorschreibt – und was sie offenlässt
Die Zahlungsdiensterichtlinie (EU) 2015/2366 regelt, *dass* Drittanbieter auf Konten zugreifen dürfen. Ein technisches Format schreibt sie nicht vor. Kein JSON-Schema, kein Endpunkt, kein Auth-Verfahren steht im Gesetzestext. Diese Lücke haben Branchenstandards gefüllt – in Deutschland vor allem NextGenPSD2, in Großbritannien die Open-Banking-Spezifikationen, in Frankreich STET.
Für Entwickler heißt das: Wer „die PSD2-API“ sucht, findet sie nicht. Es gibt pro Bank eine Implementierung eines Standards, mit eigenen Abweichungen, eigener Sandbox und eigener Dokumentation.
Drei Dienste, drei Zugriffsarten
| Dienst | Kürzel | Was die API liefert | Rechtsgrundlage (PSD2) |
|---|---|---|---|
| Kontoinformationsdienst | AIS | Kontoliste, Salden, Umsätze | Art. 67 |
| Zahlungsauslösedienst | PIS | Überweisung anlegen und Status abfragen | Art. 66 |
| Bestätigung der Deckung | PIIS / CBPII | Ja/Nein, ob ein Betrag verfügbar ist | Art. 65 |
Die meisten Web-Apps im Mittelstand brauchen nur AIS: ein Haushaltsbuch, ein Liquiditäts-Dashboard, ein Abgleich offener Rechnungen. PIS kommt dazu, sobald die App selbst Zahlungen anstoßen soll – das verschiebt Haftungs- und Sicherheitsfragen deutlich.
Dediziertes Interface statt Screen Scraping
Die technischen Regulierungsstandards (RTS 2018/389) verlangen von kontoführenden Banken eine Zugangsschnittstelle, deren technische Spezifikation sie Drittanbietern kostenlos dokumentieren und für die sie eine Testumgebung bereitstellen (Art. 30). Für den Ausfall der Schnittstelle sieht Art. 33 Notfallmaßnahmen vor. Drittanbieter weisen sich nach Art. 34 mit qualifizierten eIDAS-Zertifikaten aus (Siegelzertifikat oder Website-Zertifikat) – in der Praxis ein QWAC für die TLS-Verbindung und je nach Bank zusätzlich ein QSealC zum Signieren der Requests.
Ein Kontoabruf über NextGenPSD2 in vier Schritten
Der Ablauf ist bei NextGenPSD2-Banken ähnlich, die Details nicht. Diese Sequenz zeigt den AIS-Fall.
1. Consent anlegen
Der Drittanbieter beschreibt, worauf er zugreifen will und wie oft:
POST /v1/consents
X-Request-ID: 6f1c2a0e-8b1d-4b6e-9f3a-2c7d1e5a4b90
PSU-IP-Address: 203.0.113.10
TPP-Redirect-URI: https://app.example.de/bank/callback
{
"access": {
"accounts": [{ "iban": "DE02120300000000202051" }],
"balances": [{ "iban": "DE02120300000000202051" }],
"transactions": [{ "iban": "DE02120300000000202051" }]
},
"recurringIndicator": true,
"validUntil": "2027-06-28",
"frequencyPerDay": 4,
"combinedServiceIndicator": false
}Die Antwort enthält eine consentId, den Status received und einen Link zur starken Kundenauthentifizierung (SCA).
2. SCA durchführen: Redirect, Decoupled oder Embedded
Bei Redirect springt der Nutzer zur Bank und kommt über die TPP-Redirect-URI zurück. Bei Decoupled bestätigt er in der Banking-App auf dem Handy, während die eigene App den Status pollt. Embedded führt die TAN-Eingabe durch die Oberfläche des Drittanbieters – mit dem meisten UI-Aufwand. Welche Verfahren eine Bank anbietet, steht in ihrem Implementation Guide. Davon hängt ab, wie viele Bildschirme die Consent-Strecke im Frontend braucht.
3. Konten, Salden und Umsätze lesen
Nach erfolgreicher SCA wechselt der Consent auf valid. Danach laufen Abrufe mit dem Header Consent-ID:
GET /v1/accounts
GET /v1/accounts/{account-id}/balances
GET /v1/accounts/{account-id}/transactions?bookingStatus=booked&dateFrom=2026-10-014. Consent-Status überwachen
GET /v1/consents/{consentId}/status liefert valid, expired, revokedByPsu oder terminatedByTpp. Diesen Status speichert die App als eigenes Feld am Bankkonto – nicht als Fehlermeldung im Log.
180 Tage und vier Abrufe: die Grenzen, die das Produkt formen
Läuft der Abruf über einen Kontoinformationsdienst, darf die Bank nach Art. 10a der RTS keine erneute SCA verlangen, solange die letzte Authentifizierung über diesen Dienst höchstens 180 Tage zurückliegt – es sei denn, sie hat objektiv begründete und belegte Hinweise auf unbefugten oder betrügerischen Zugriff. Diese Regel hat die Delegierte Verordnung 2022/2360 mit Wirkung ab 25. Juli 2023 eingeführt; zuvor lag die Frist bei 90 Tagen und war für die Bank nur eine Kann-Ausnahme. Unabhängig davon begrenzt Art. 36 Abs. 5 der RTS Abrufe ohne aktive Nutzeranfrage auf vier pro 24 Stunden, sofern Drittanbieter und Bank mit Zustimmung des Nutzers keine höhere Frequenz vereinbart haben. Ein Klick auf „Aktualisieren“ durch den Nutzer fällt nicht unter diese Grenze.
Rechenbeispiel: Consents, die zwischen den Jahren auslaufen
Wer im Sommer Nutzer gewonnen hat, bekommt die Rechnung im Dezember:
| SCA erteilt am | + 180 Tage | Erinnerung 14 Tage vorher |
|---|---|---|
| 01.07.2026 | 28.12.2026 | 14.12.2026 |
| 10.07.2026 | 06.01.2027 | 23.12.2026 |
| 15.07.2026 | 11.01.2027 | 28.12.2026 |
Genau in diesem Fenster sind viele Nutzer im Urlaub, prüfen keine Mails und öffnen die App nur gelegentlich. Läuft der Consent ab, steht im Dashboard ein eingefrorener Kontostand – und die Jahresabschluss-Auswertung im Januar hat eine Lücke. Ob eine Bank den Tag der Erteilung mitzählt, ist zwischen Implementierungen nicht einheitlich; ein Puffer von zwei bis drei Tagen fängt das ab.
Entscheidungsregel: Alle Consents mit Ablauf zwischen dem 20. Dezember und dem 10. Januar bekommen die Re-Authentifizierung schon in der ersten Dezemberhälfte angeboten – in der App, nicht nur per Mail.
Sync-Takt planen
Vier Hintergrundabrufe in 24 Stunden ergeben gleichmäßig verteilt einen Abstand von sechs Stunden. Über einen Monat mit 31 Tagen sind das höchstens 124 automatische Abrufe pro Zugriffsart. Ob eine Bank pro Konto, pro Endpunkt oder pro Consent zählt, steht wiederum in ihrer Doku. Praktisch heißt das: Salden und Umsätze im selben Lauf holen, Ergebnisse cachen und die Oberfläche aus dem Cache bedienen. Das Muster ähnelt der Cache-Logik einer Wetter-API-Integration in Next.js – nur dass hier das Kontingent rechtlich gedeckelt ist, nicht vom Anbieter.
Ein Detail, das beim ersten Sync zählt: Die SCA-Ausnahme der RTS (Art. 10 und 10a) deckt nur den Saldo und Umsätze der letzten 90 Tage. Eine längere Historie liefern manche Banken nur direkt nach einer frischen Authentifizierung. Den Erstimport deshalb unmittelbar nach der SCA starten.
Direkt anbinden oder über einen Aggregator?
Wer selbst als Kontoinformationsdienst auf Bankschnittstellen zugreift, braucht nach Art. 33 der Richtlinie (EU) 2015/2366 zwar keine volle Zahlungsinstitutserlaubnis, muss aber im öffentlichen Register eingetragen sein; in Deutschland verlangt § 34 ZAG dafür eine Registrierung durch die BaFin. Für die meisten Web-Apps ohne eigene Registrierung bleibt damit ein lizenzierter Aggregator, der Consent-Strecke und Bankanbindungen stellt. Ob ein konkretes Geschäftsmodell eine eigene Erlaubnis braucht, klärt eine Rechtsberatung, nicht der Entwickler.
Die folgenden Stunden sind Planungswerte aus meinen Kalkulationen für Next.js-Projekte, keine Marktdaten:
| Baustein | Über Aggregator | Direkt (erste Bank, NextGenPSD2) |
|---|---|---|
| Consent- und SCA-Strecke im Frontend | 12–20 h | 30–50 h |
| Zertifikate (QWAC/QSealC), mTLS, Signatur | – | 16–24 h |
| Sync-Job, Cache, Rate-Limit-Handling | 16–24 h | 20–30 h |
| Datenmodell, Dubletten, Buchungsstatus | 16–30 h | 16–30 h |
| Re-Consent-Strecke und Erinnerungen | 8–12 h | 8–12 h |
| Fehlerfälle, Sandbox-Tests | 12–20 h | 20–40 h |
| Summe | 64–106 h | 110–186 h |
Jede weitere Bank kostet im direkten Weg zusätzlich 20–40 Stunden für Abweichungen vom Standard. Ab etwa drei zusätzlichen Banken erreicht allein dieser Posten die Größenordnung der gesamten Aggregator-Integration. Die Gebühren des Aggregators stehen dem gegenüber und gehören vor der Entscheidung aus dessen aktueller Preisliste in die Rechnung. Wie sich DSGVO- und PSD2-Anforderungen dabei überlagern, habe ich im Beitrag Aufwand DSGVO und PSD2 Banking im Vergleich aufgeschlüsselt.
Was in PSD2-Projekten typischerweise schiefgeht
- Abgelaufener Consent wird als Fehler behandelt. Ein
401oderexpiredlandet im Error-Tracking, der Nutzer sieht nichts. Richtig ist ein sichtbarer Zustand am Konto mit einem Button „Zugang erneuern“. - Vorgemerkte Umsätze erzeugen Dubletten. Eine Buchung erscheint erst als
pending, später alsbooked– teils mit anderer Referenz. Ohne Abgleich über Betrag, Datum und Gegenkonto steht derselbe Einkauf zweimal im Haushaltsbuch. - Saldotypen werden verwechselt.
closingBooked,interimAvailableundexpectedliefern unterschiedliche Zahlen. Welcher Saldo im Dashboard erscheint, gehört als bewusste Entscheidung in die Spezifikation. - Die Sandbox wird für die Wahrheit gehalten. Testdaten sind sauber, Produktionsdaten haben leere Verwendungszwecke, Umlaute in falscher Kodierung und Gegenkonten ohne Namen. Für die Abnahme mindestens ein echtes Konto einplanen.
- Zu viele Daten werden gespeichert. Wer nur Kategorien und Monatssummen anzeigt, braucht keine vollständigen Gegenkonto-IBANs dauerhaft in der Datenbank. Datensparsamkeit ist hier auch weniger Angriffsfläche.
Der letzte Punkt entscheidet sich früh: Welche Felder aus der Bank-API dauerhaft in PostgreSQL landen, legt das Datenmodell in der ersten Woche fest – danach wird es teuer, das zu ändern.
Häufige Fragen
Ist die PSD2 Open Banking API für Drittanbieter kostenlos?
Die RTS verlangen, dass Banken die Dokumentation ihrer Schnittstelle kostenlos bereitstellen (Art. 30 der RTS 2018/389). Wer über einen Aggregator anbindet, zahlt dessen Gebühren; die stehen in der jeweiligen Preisliste und sollten vor Projektstart in die Kalkulation.
Brauche ich für eine reine Lese-App einen eigenen Bankvertrag?
Für den regulierten Zugriff nicht: Nach Art. 67 Abs. 4 der Richtlinie (EU) 2015/2366 hängt der Kontoinformationsdienst nicht von einem Vertrag mit der kontoführenden Bank ab. Grundlage sind die ausdrückliche Zustimmung des Kontoinhabers (Art. 67 Abs. 2) und die Registrierung des zugreifenden Dienstes. Ob die eigene App selbst registriert sein muss oder ein Aggregator diese Rolle übernimmt, hängt vom Geschäftsmodell ab und gehört vor dem Festpreis geklärt.
Gilt das auch nach PSD3?
Die EU hat als Nachfolger eine neue Zahlungsdiensterichtlinie (PSD3) und eine direkt geltende Zahlungsdiensteverordnung (PSR) ausgehandelt. Bis diese Regeln anwendbar werden, gelten PSD2, ZAG und die RTS wie oben beschrieben. Wer heute eine Bankanbindung plant, sollte vor Projektstart prüfen, ob die neuen Texte im Amtsblatt veröffentlicht sind und ab wann sie gelten.
Für ein Projekt mit Bankdaten, das im Januar live gehen soll, ist der nächste Schritt eine Liste der Zielbanken mit ihren unterstützten SCA-Verfahren – sie bestimmt mehr über den Aufwand als jede andere Frage im Erstgespräch.