Der Berlin-Group-Standard: wie eine deutsche Bank ihre Konten öffnet
Die Berlin Group beschreibt sich als europäische Initiative für Interoperabilitätsstandards und Harmonisierung im Zahlungsverkehr, und ihr NextGenPSD2-Framework ist die API-Spezifikation, die die meisten deutschen Banken für Open Banking umsetzen. PSD2 verlangte von Banken eine offene Schnittstelle, sagte aber nicht, wie sie aussehen soll, der Markt brauchte also eine Spezifikation, sonst hätte jede Bank eine eigene erfunden.
Diese Seite liegt unter Open Banking in Deutschland, wo der Standard benannt wird und steht, wozu er dient. Hier geht es um die Spezifikationsebene: die drei Dienstegruppen, das Consent-Modell, die drei Authentifizierungswege und die unangenehme Tatsache, dass zwei Banken mit demselben Standard trotzdem unterschiedlichen Code brauchen.
Wer die Berlin Group ist und was sie veröffentlicht
Die Berlin Group ist ein Branchengremium aus Banken, Zentralbanken, Zahlungsverbänden, Zahlverfahren und Interbanken-Prozessoren im SEPA-Raum, organisiert in Taskforces mit Arbeitsgruppen für API-Experten, Geschäftsbewertung und Marktkommunikation. Sie ist keine Aufsicht und erteilt keine Lizenzen. Ihr Ergebnis sind Spezifikationen, und eine Bank setzt sie um, weil der Markt es erwartet, nicht weil eine Behörde es anordnete.
Jedes Framework besteht aus drei Dokumentarten, alle frei unter einer Creative-Commons-Lizenz: Operational Rules beschreiben die Leistung, das logische Datenmodell und die Prozessabläufe als B2B-Schnittstelle, Implementation Guidelines spezifizieren die Schnittstellen technisch mit den XML- und JSON-Schemata, und OpenAPI-Dateien erlauben die Codegenerierung. Wer nur die Guidelines liest, verpasst die Prozessregeln, und wer nur die Regeln liest, baut eine Schnittstelle, die niemand aufrufen kann.
NextGenPSD2 und die drei Dienstegruppen
NextGenPSD2 deckt genau die drei Kontozugangsdienste, die PSD2 schuf. Der Kontoinformationsdienst, AIS, liest Salden und Umsätze für einen Dritten, den der Kunde autorisiert hat. Der Zahlungsauslösedienst, PIS, startet eine Zahlung vom Kundenkonto. Die Deckungsbestätigung, geschrieben als PIIS oder CAF, beantwortet die Ja-Nein-Frage, ob ein Betrag gedeckt ist, was ein Kartenemittent vor der Autorisierung nutzt.
Die Spezifikation ist REST mit JSON-Nachrichten, gesichert über OAuth 2.0 und OpenID Connect, und sie wuchs über ihre Versionen weit über das Minimum: Fremdwährungskonten, Daueraufträge, periodische Zahlungen und bessere Fehlerbehandlung. Der Standard-Tracker von Fiskil zählt etwa dreißig Länder mit Umsetzung, und deshalb bekommt ein Anbieter mit deutschem Code den größten Teil Europas mit.
Das Consent-Modell und die drei Authentifizierungswege
Der Consent ist eine Ressource in der API, kein Häkchen. Ein Dritter erzeugt ein Consent-Objekt mit Umfang und Dauer, der Kunde autorisiert es bei der Bank, und jeder spätere Aufruf verweist darauf. Ein Consent hat Lebensdauer und Umfang, und die Bank setzt beides durch, weshalb ein abgelaufener Consent einen Fehler erzeugt und keine stillschweigend leere Antwort.
Die starke Kundenauthentifizierung läuft auf drei Wegen, und der Standard trägt alle drei. Beim Redirect geht der Kunde auf die Seite oder in die App der Bank und kommt danach zurück. Beim Decoupled-Weg gibt der Kunde in der Bank-App auf einem anderen Gerät frei, während die Sitzung wartet. Beim Embedded-Weg laufen die Authentifizierungsdaten durch die API selbst. Was eine Bank anbietet, entscheidet über das Gefühl im Checkout, und starke Kundenauthentifizierung behandelt die Regeln dahinter.
Warum zwei Banken verschiedenen Code brauchen
Eine Spezifikation lässt Wahlmöglichkeiten, und jede Bank, die anders wählt, macht Integrationsarbeit für den Anbieter. Welcher Authentifizierungsweg angeboten wird. Welche optionalen Felder gefüllt sind. Wie lange ein Consent ohne erneute Freigabe lebt. Welche Fehlercodes für denselben Fehler kommen. Ob Sammelzahlungen unterstützt werden und in welchem Format. Keines davon verstößt gegen den Standard, und jedes davon bricht eine naive Integration.
Das ist der kaufmännische Grund für Aggregatoren. Wer sich direkt mit einigen hundert deutschen Instituten verbindet, pflegt einige hundert Eigenheiten, und ein Anbieter verkauft die Abstraktion darüber. Jede Bank betreibt außerdem eine Sandbox für Tests vor dem Produktivzugang, und Sandbox-Verhalten ist nicht immer Produktivverhalten, und genau dort rutschen die meisten Integrationstermine.
Das openFinance-Framework jenseits von PSD2
Das openFinance API Framework der Berlin Group baut auf den Technologie- und Infrastrukturinvestitionen von NextGenPSD2 auf und fügt standardisierte Erweiterungen jenseits des PSD2-Regulierungsrahmens hinzu, damit Bankkunden ihre Konten für kommerzielle Premium-Leistungen und angereicherte Daten erreichen, so die Gruppe selbst. Es deckt mehr Datenquellen und mehr Kontoarten als PSD2 verlangt: Sparen, Kredite und Anlagen neben dem Zahlungskonto.
Auf der Zahlungsseite sind die Erweiterungen die Leistungen, die Anbieter immer wollten und PSD2 nie gab: Deckung sperren oder reservieren, eine Zahlung terminieren, pay-by-loan mit integriertem Verbraucherkredit, ein SEPA-Lastschriftmandat einrichten. Das Framework liefert die technische Form, das SPAA-Verfahren die kommerziellen Bedingungen. Beide sind zur gemeinsamen Nutzung gedacht, und die Berlin Group veröffentlicht einen Arbeitsplan für die geplanten Leistungen.
Was FIDA darauf legen würde
FIDA, die EU-Verordnung über den Zugang zu Finanzdaten, würde den Pflichtzugang weit über das Zahlungskonto hinaus führen, auf Hypotheken, Spareinlagen, Anlagen, Versicherungen, Altersvorsorge und Daten zur Kreditwürdigkeit, und sie würde Unternehmen zur Mitgliedschaft in Datenzugangssystemen verpflichten, die Standards und Vergütung setzen. Das ist eine viel breitere Fläche als NextGenPSD2.
Für eine deutsche Bank zählt die Reihenfolge mehr als das Detail. Wer NextGenPSD2 sauber umgesetzt hat, besitzt die Consent-Mechanik, die Authentifizierung und die Praxis im API-Betrieb. FIDA käme mit weiteren Datenbereichen und einem Berechtigungs-Dashboard, und openFinance ist das Angebot der Berlin Group, die Spezifikation dieser Systeme zu werden. Wer eine halbfertige PSD2-Schnittstelle hat, trifft FIDA aus schlechterer Position.
Was ist der Berlin-Group-Standard?
Der Berlin-Group-Standard, genauer das NextGenPSD2 Access to Account Framework, ist eine freie API-Spezifikation für die drei PSD2-Dienste: Kontoinformation, Zahlungsauslösung und Deckungsbestätigung. Er definiert REST- und JSON-Schnittstellen, ein Consent-Modell und drei Wege zur starken Kundenauthentifizierung und wird von Banken in rund dreißig Ländern umgesetzt.
Ist der Berlin-Group-Standard verpflichtend?
Nein. PSD2 verpflichtet eine Bank zu einer Zugangsschnittstelle, schreibt aber keine Spezifikation vor. Die Berlin Group ist eine Brancheninitiative, keine Aufsicht, und ihre Dokumente sind freiwillig. Der Standard dominiert in Deutschland und großen Teilen Kontinentaleuropas, weil der Markt darauf zulief, und das wirkt praktisch wie eine Pflicht, ohne rechtlich eine zu sein.
Der Berlin-Group-Standard und Finance Loop
Finance Loop ist der Ort, an dem die Bankteams mit einer XS2A-Schnittstelle auf die Anbieter treffen, die einige hundert davon konsumieren, und genau dieses Gespräch bringt zutage, was eine Spezifikation offenließ. Finance Loop ist der Treffpunkt für Payment in Deutschland, mit Meetups und Konferenzen zu Open Banking, Echtzeitüberweisung und Regulierung. Finance Loop führt diese Termine im Veranstaltungskalender.
Finance Loop ist ein Experten-Netzwerk mit dem Ziel, neue Technologien in der Finanzbranche in die Anwendung zu bringen, etwa KI, Tokenisierung, Stablecoins und DeFi. Finance Loop hilft seinen Mitgliedern, Wissen und persönliche Netzwerke in diesen Feldern aufzubauen: Investment & Digital Assets, Payments & digitales Geld, digitale Infrastruktur & Souveränität sowie Risk & Compliance.