Wie die Schweiz die besten API Standards bauen kann

Am 13. Januar 2018 trat die zweite Zahlungsdiensterichtlinie (PSD2) in Kraft. Damit müssen Banken unter anderem ihre Systeme für Drittanbieter öffnen und Schnittstellen schaffen. Diese ermöglichen es ihnen, Zahlungen aus dem Kundenkonto auszulösen, Kontoinformationen abzurufen und die Verfügbarkeit eines bestimmten Betrags auf dem Konto zu überprüfen.

Die Richtlinie lässt jedoch die detaillierte Ausgestaltung der technischen Schnittstellen (zum Beispiel Application Programming Interface, API) offen, mit denen Drittanbieter die Verbindungen zu Banken herstellen können. Die kürzlich am 13. März 2018 im EU-Amtsblatt veröffentlichten Regulatory Technical Standards (RTS) zur starken Kundenauthentifizierung spezifiziert nur technische Rahmenbedingungen, aber keinen Schnittstellenstandard.

Kräfte bündeln für sinnvolle Standards

Eine API-Standardisierung würde für ein pan-europäisches Ökosystem sehr dienlich sein, doch der europäische Regulator hat dieses Thema dem Markt überlassen. Der Markt kann hier seine Kräfte bündeln und sinnvolle Standards setzen. Um diese Lücke zu schliessen, hat unter anderen die Berlin Group – bestehend aus fast 40 Banken, Verbänden und Zahlungsdienstleistern aus der gesamten EU – ein gemeinsames API-Framework namens „NextGenPSD2“ für die PSD2-Anwendungsfälle definiert. Ähnliche Initiativen wurden auch in Polen (PolishAPI), Slowenien, Frankreich (STET) eingeleitet.

Vor der PSD2 wurde in Grossbritannien mit der Open Banking Regulierung der Wettbewerbsbehörde (Competition and Market Authority, CMA) die Open Banking Implementation Entity (OBIE) mit der damit einhergehenden API-Standardisierung und den wichtigsten Anwendungsfällen Zahlungsauslösung und Kontoinformation Anfang 2018 etabliert.

Hierzu zeigt mein Gastbeitrag auf MoneyToday vom November 2017 noch einmal einen Vergleich des NextGenPSD2-API-Framework Version 0.99 der Berlin Group und der Open Banking UK API-Standard 1.1.0 auf.

Die neueste Version 1.0 von NextGenPSD2 wurde am 8. Februar 2018 veröffentlicht. Insofern macht es durchaus Sinn, die wichtigsten Änderungen und somit erste Empfehlungen für Banken herauszuarbeiten.

Von Version 0.99 zu Version 1.0: Unterschiede

Im Folgenden die wichtigsten Änderungen, die zwischen Version 0.99 und 1.0 des NextGenPSD2-API-Frameworks bestehen:

• Anwendungsfälle für Zahlungen: Während die vorherige Version nur eine einmalige Zahlungsauslösung unterstützte, wickelt die neueste Version zusätzlich die Einreichung von zukunftsdatierten Zahlungen und Daueraufträgen für wiederkehrende Zahlungen ab.
• Datenstruktur und Formate für die Zahlungsauslösung: Die vorherige Version erlaubte die Einreichung einer Einzelzahlung in JSON und eine in JSON gekapselte pain.001 und pain.002 (ISO20022 XML). Die neueste Version ermöglicht jetzt zusätzlich zu einer Einzelzahlung mehrere Zahlungen in einer einzigen Zahlungsauslösung (Massenzahlung). Hierfür wird die starke Kundenauthentifizierung einmal für alle Transaktionen in einem Durchlauf in JSON oder pain.001 und pain.002 angewendet. Daueraufträge können als JSON oder Kombination von pain.001 und JSON (multipart) eingereicht werden.
• Datenfelder: Die neueste Version enthält geänderte Feldnamen gemäss bekannten internationalen Namenskonventionen. Teilweise wurden Namenskonventionen für Felder und Attribute aus dem ISO20022-Standard übernommen, beispielsweise beruhen die Statusattribute für den Kontostand auf ISO20022. Open Banking UK hingegen verlässt sich vollständig auf ISO20022-Attribute.
• Erweiterte Datenfelder: Banken können zusätzliche Datenfelder in die Nachrichten einfügen, diese müssen jedoch zunächst der Berlin Group zur Genehmigung vorgelegt werden. Diese zusätzlichen Felder müssen anschliessend in der API-Spezifikation der Bank dokumentiert werden.
• Währungen: Zusätzlich zum Euro ermöglicht die neueste Version Konten mit mehreren Währungen, die von der Berlin Group als eine Sammlung verschiedener Unterkonten definiert werden und mit derselben IBAN adressiert sind. Die Unterkonten können durch die unterschiedlichen Währungskennungen innerhalb der IBAN eindeutig unterschieden werden.

Wo ist der API-Standard, der ein pan-europäisches Ökosystem ermöglicht?

Aktuell gibt es in der EU Bemühungen zu einer harmonisierten Interpretation der PSD2, der RTS und der API-Frage – beispielsweise die hier genannten PSD2-API-Standardisierungs-Initiativen und sogar eine Initiative für standardisierte Leistungskennzahlen bezüglich API-Verfügbarkeit und Leistung. Letztere wird von der API Evaluation Working Group des Euro Retail Payments Board für Zahlungsinitiierungsdienste (ERPB on PIS) definiert.

Trotz der vorhandenen offenen Fragen können Banken zumindest jetzt ihren API-Standard selbst definieren. Dabei stellt sich die Frage, welchen Standard Banken nehmen sollen, falls sie sich für die Berlin Group entscheiden? NextGenPSD2 ist ein API-Baukasten mit dem ein bankeigener API Standard gebaut werden kann. Doch ein Berlin Group API-Standard gleicht dabei nicht einem anderen Berlin Group API-Standard.

Wesentliche Designaspekte

Es gibt mehrere Optionen, die mit den folgenden Hauptaspekten des API Designs zusammengestellt werden können:

• Datenstruktur und Formate für die Zahlungsauslösung: vollständiger JSON, ISO20022-XML (pain.001 und pain.002)
• Zahlungsauslösungsmodus: Einzel- und Massenzahlungen
• Datenstruktur und Formate für Kontoinformationen: vollständige JSON, ISO20022-XML (camt.052, camt.053, camt.054) oder sogar SWIFT MT940, MT941, MT942
• Verfahren für die starke Kundenauthentifikation (SCA): Redirect, Embedded, Decoupled
• Verfahren für den Consent: OAuth2 als Prestep oder volles OAuth2 für OAuth2-basierte SCA-Verfahren

Die obigen wesentlichen Designaspekte können zu unterschiedlichen API-Standards kombiniert werden. Unterschiedliche Standards führen zu einer fragmentierten API-Landschaft in Europa. Banken sollten die Best Practices im API-Design befolgen. Nichts spricht gegen einen API-Standard, der mehrere Optionen zulässt, aber mindestens sollte er die folgenden Punkte umfassen:

• REST-API mit JSON (vollständiges JSON-Format) für Zahlungsauslösung und Kontoinformationen unter Verwendung von standardisierten ISO20022-Namenskonventionen für Attribut
• Einzelzahlung (mit allen relevanten Zahlungsverkehrsprodukten – zum Beispiel SEPA SCT)
• SCA-Verfahren «embedded» und mit einem vollständigem OAuth2-basierten SCA-Verfahren
• Nur notwendige Datenfelder für wesentliche Kundensegmente (Retail und mindestens KMU-Firmenkunden)

Bis zum 14. September 2019 müssen EU-Banken RTS-konform sein und sogar sechs Monate vor der Markteinführung APIs zum Testen bereitstellen. APIs, die den Best Practice-Prinzipien folgen, sind für eine vollumfängliche künftige Open Banking-Strategie über die PSD2 hinaus von entscheidender Bedeutung.

Auch die Schweiz standardisiert zielstrebig

PSD2 ist zwar rechtlich nicht relevant für die Schweiz, allerdings wirft die EU-Regulierung ihre Schatten voraus und führt auch hierzulande zu API-Standardisierungs-Initiativen für die Anwendungsfälle wie Zahlungsauslösung oder Kontoinformationen.

Bekannte API-Standardisierungs-Initiativen in diesem Zusammenhang: unter anderen von der Swiss Finance Startups (SFS), der Swiss Fintech Innovations (SFTI) und die API-Initiative der SIX.

Die Schweiz sollte nachziehen

Der Schweizer Markt kann auf zeitraubende Diskussionen über das Für und Wider bestimmter Designentscheidungen verzichten und direkt auf Ergebnisse von europäischen API-Standards zurückzugreifen und eine für Schweizer Bedürfnisse abgestimmte Version etablieren.

Ausserdem sollte darauf geachtet werden, dass sich die Standards untereinander wenig unterscheiden, um einer Fragmentierung entgegenzuwirken und die Nutzer der APIs – zum Beispiel die Drittanbieter – miteinzubeziehen.

Die Zeit läuft, es sind noch knapp 17 Monate bis die RTS am 14. September 2019 in Kraft tritt und die EU in Sachen Banken-APIs zum Global Player wird – die Schweiz sollte nachziehen und ihre Wettbewerbsfähigkeit auf diesem Feld ausbauen.