Berlin Group Standard

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. Die Berlin Group ist keine Aufsicht und erteilt keine Lizenzen. Das Ergebnis der Berlin Group 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 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.

Der Consent ist eine Ressource in der API: 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.

Eine Spezifikation lässt Wahlmöglichkeiten, und jede Bank, die anders wählt, macht Integrationsarbeit für den Anbieter. Unterschiede betreffen den Authentifizierungsweg, optionale Felder, die Gültigkeit eines Consents ohne erneute Freigabe, Fehlercodes sowie die Unterstützung und Formate von Sammelzahlungen. 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 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. Das openFinance-Framework deckt mehr Datenquellen und mehr Kontoarten als PSD2 verlangt: Sparen, Kredite und Anlagen neben dem Zahlungskonto.

Auf der Zahlungsseite umfassen die Erweiterungen Leistungen jenseits von PSD2: 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.

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.

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. Der Berlin-Group-Standard 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.

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.