Es ist aktuell gross in Mode neue Schnittstellenstandards fürs Open Banking zu entwickeln. Neben dem Swiss Open Finance API ist hierzulande mit Sicherheit die Swiss Corporate API Initiative unter der Leitung von SIX erwähnenswert. Analog den Vorgaben der zweiten Europäischen Payments Service Directive (PSD2), stehen Funktionalitäten für den Zugriff auf‘s Konto und die Zahlungsauslösung durch Dritte im Fokus.
Man könnte sich fragen, weshalb die Schweiz einen eigenen Standard entwickelt, wo doch in Europa mit den Spezifikationen der Berlin Group oder dem UK API Standard bereits fixfertige Standards auf dem Tisch liegen würden. Das ist aber ein anderes Thema. Dieser Blog befasst sich vielmehr mit der Frage, wie denn diese Open Banking Schnittstellen im Vergleich zu EBICS stehen.
Zunächst müsste sicherlich erwähnt werden, dass EBICS bereits heute den Zugriff auf Konten und die Auslösungen von Zahlungen ermöglicht. Dies ist Multibanking und gibt es auch in Form von Apps auf portablen Geräten. Es erfüllt die Vorgaben der PSD2 jedoch nicht in dem Sinne, dass über die Schnittstelle dieselben Informationen des Kunden wie im Onlinebanking zur Verfügung stehen.
Die Bezüge der Konto-Daten erfolgen über strukturierte Rapporte mittels Datenstandards wie SWIFT FIN oder ISO 20022. Dasselbe gilt für die Zahlungsauslösung. EBICS ist als Protokoll asynchron ausgelegt und der Austausch von Daten erfolgt in der Regel über Dateien. Typischerweise positionieren Banken EBICS im Umfeld von mittleren bis grösseren Firmenkunden, welche teilweise sehr grosse Volumen verarbeiten lassen (z.B. Rentenzahlungen des Bundes mit mehreren tausend Aufträgen).
Das auf Volumen und Performance optimierte EBICS-Protokoll unterscheidet sich in erster Linie genau in diesem Punkt von den gängigen Open Banking API Standards. Dazu kommt sicherlich die weite Verbreitung in Europa als Standard im Corporate Banking und Interbanking plus die standardisierte verteilte elektronische Unterschrift. EBICS wird nicht zuletzt auch als Standard für SEPA Instant Payments als Zugang zum RT1-System der EBA eingesetzt.
Im Gegensatz dazu bietet das Swiss Corporate API bewusst nur einen reduzierten Datenumfang an, welcher auf den bekannten Schweizer Implementation Guidelines für pain.001 basiert. Optionale Elemente sind jedoch nur da vorhanden, wo sie wirklich gebraucht werden. Komplexe Zahlungsinstruktionen sind nicht vorgesehen. Die Einfachheit nach dem Motto ”so viel wie nötig, so wenig wie möglich“ steht klar im Fokus.
Eine weitere Besonderheit der API ist die zentrale Rolle der SIX als Vermittlungsstelle. Die Software-Hersteller schliessen ihre Produkte an eine einzige Schnittstelle bei der SIX an, welche dann das Routing an die verschiedenen Banken (und weitere Funktionen) übernimmt. Im gleichen Sinn benötigen auch die Banken nur einen Zugang zur SIX-Plattform, um sämtliche Software-Anbieter bedienen zu können.
Für Banken wie auch für Softwarehersteller stellt sich eigentlich nicht die Frage, ob sie den einen oder anderen Standard ihren Kunden anbieten sollen. Je nach Situation kann einmal die eine Option, ein andermal die andere Option eine optimale Lösung darstellen. Es wird auch Kunden geben, die parallel beide Standards verwenden. Tendenziell wird sich die Swiss Corporate API im Retailgeschäft und im unteren KMU-Segment durchsetzen (sofern das Projekt ein Erfolg wird) und EBICS wird sich weiterhin bei den Firmenkunden als Europäischer Multibanking-Standard durchsetzen.
Fazit: Es gibt (zu) viele Open Banking API Initiativen (teilweise haben Banken sogar eigene APIs), was eine grössere Verbreitung in der Schweiz behindert (Europa nicht einmal eingerechnet). Die Swiss Corporate API hat gute Chancen ein Erfolg zu werden, da sie breit in der Bankenlandschaft abgestützt ist und den Support der hiesigen Grossbanken geniesst. Zudem ist sie klar positioniert: Einfach, schnell und schnörkellos soll sie werden, trotzdem die verschiedenen Zahlungsarten abdecken können und für Software-Hersteller einfach zu implementieren. Diese wurden denn auch bei der Spezifikation der API mit einbezogen, eine Vorgehensweise, welche wir klar begrüssen.
EBICS bleibt als Protokoll weiterhin relevant und wird sich insbesondere im Vergleich zur Alternative SWIFT FileAct aus Kosten- und Backup-Überlegungen weiterhin ausbreiten.
Für Sie gebloggt haben Carsten Miehling und Rolf Zumsteg
0 Kommentare:
Kommentar veröffentlichen