Die APIs der Deutschen Banken: inkonsistente Transaktionsformate, instabil plus langsame Antwortzeiten
Nordigen
Als Reaktion auf den im November veröffentlichten Artikel über PSD2-Tests für deutsche Bank-APIs hat das europäische Open-Banking-Unternehmen Nordigen seine eigenen Erfahrungen mit Verbindungen in Deutschland mitgeteilt. Nachdem das Unternehmen rund 1200 Verbindungen in Deutschland geschaffen habe, ist es auf mehrere Herausforderungen gestoßen, wenn es um die Integration von Bank-APIs geht. Der Erfahrungsbericht und Kommentar
von Jake Sebastian-Jones, CTO bei Nordigen
Im Großen-PSD2-Test vom November (hier) wurden die Erfahrungen mit sieben Bank-APIs ausgewertet, und auch aus den Erfahrungen von Nordigen (Website) lässt sich schließen, dass eine große Herausforderung darin besteht, dass es für offene Bank-APIs keinen einheitlichen Entwicklungsstandard gibt.Im Rahmen der PSD2 gibt es die technischen Regulierungsstandards, die eher vage sind und die wichtigsten Punkte für den Zugang wie den Umfang und die Zugangszeiträume definieren. Die Berlin Group ist ein von einer Gruppe von Banken geschaffener Standard, der bereits sehr genau definiert, wie Open Banking implementiert werden sollte und welche spezifischen Datenpunkte sie zurückgeben sollten.
Die Banken können sich entscheiden, dem Standard zu folgen, müssen es aber nicht.”
Und selbst wenn die Banken einen Standard befolgen, gibt es teilweise keine Maßnahmen oder eine Behörde, die dies durchsetzen könnte. Dies führt zu uneinheitlichen Transaktionsformaten und erfordert erhebliche Ressourcen und Fachkenntnisse für die Arbeit mit API-Daten.
Hinzu kommt, dass instabile Verbindungen und langsame Reaktionszeiten der Banken die Erfahrung unangenehm machen und Raum für Verbesserungen lassen.
Die Transaktionsformate
PSD2 ist eine europäische Richtlinie für elektronische Zahlungsdienste, die darauf abzielt, den Zahlungsverkehr in Europa sicherer zu machen, Innovationen zu fördern und Bankdienstleistungen bei der Anpassung an neue Technologien zu unterstützen, indem Bankdaten über APIs verfügbar gemacht werden. Da die Richtlinie für alle gelten soll, sind die Empfehlungen für Datenformate absichtlich allgemein gehalten, wobei nur sehr wenige Datenfelder obligatorisch und die übrigen Datenfelder optional sind. Bei einigen dieser Felder handelt es sich um einfache Textfelder mit einer bestimmten Größe, einige sollen einer bestimmten Struktur folgen, während andere einen Wert aus einer bestimmten, genau definierten Liste haben sollten.
In Wirklichkeit behandeln viele Banken den Standard nur als Empfehlung, was bedeutet, dass beim Abrufen von Daten aus APIs viel Zeit darauf verwendet wird, herauszufinden, ob ein “FeldX” in der Antwort der Bank wirklich das “FeldX” im Standard ist.”
Datenformate sind ein weiteres Beispiel für abweichende Daten, z. B. erwartet der Standard, dass ein bestimmtes Feld ein Datum ist, aber die eingehenden Daten enthalten “datetime”. Transaktionsbeträge werden ebenfalls in verschiedenen Formaten angegeben, z. B. basiert das Vorzeichen des Transaktionsbetrages darauf, ob der “Gläubiger” oder “Schuldner” irgendwo in den Transaktionsdaten vorhanden ist, während der Standard verlangt, dass er ein expliziter Teil des Betrages ist. Die Art des Saldos (eine standardisierte Liste zulässiger Werte) wird oft als willkürlicher Wert zurückgegeben; dies erfordert mehrere Gespräche mit der technischen Supportabteilung der Bank, um die Zuordnung zwischen der Sichtweise der Bank und dem Standard zu klären.
Die Existenz mehrerer “konkurrierender” Standards ist ebenfalls nicht hilfreich. Ein Beispiel dafür ist MT940, ein im SWIFT-Netzwerk verwendeter Standard. Es handelt sich um einen weit verbreiteten Standard, der sich jedoch erheblich vom Open-Banking-Standard unterscheidet.”
Ein Vergleich der Unterschiede zwischen MT940 und Berlin Group ist nachstehend zu sehen:
MT940 Standard :20:STARTUMS :25:50010700/0002095885 :28C:00084/001 :60F:C200301EUR631505,4 :61:2003010301D445,12NMSC0111343372200 //D11139HMUC727220 :86:004?00LASTSCHRIFT/ABBUCH. AUFTRAG?1020004?20LEASING 114021 MWST 19P?21KFZ LKW K-BV 111 20.05.11?22.RATE 374,05+71,07 445,12?3070120700?3101281100278?32BANK LEASING GMBH :62F:C200301EUR633518,47 :64:C200301EUR220613,39
Berlin Group Standard
{
"bookingDate": "2020-03-01",
"transactionAmount": {
"amount": "445,12",
"currency": "EUR"
},
"creditorName": "BANK LEASING GMBH",
"additionalInformation": "LASTSCHRIFT/ABBUCH. AUFTRAG",
"proprietaryBankTransactionCode": "MSC"
}
Diese Probleme sind technisch nicht schwierig, aber sie erschweren die Bereitstellung einheitlicher, homogener Daten für unsere Kunden mehr, als es sein könnte und sollte.”
Unstabile API Verbindungen
Entgegen der landläufigen Meinung, dass “eine Bank der Inbegriff von Stabilität ist”, haben die Entwickler von Nordigen festgestellt, dass viele PSD2-Implementierungen in deutschen Banken Stabilitätsprobleme aufweisen. Diese Probleme liegen in der technischen Infrastruktur der APIs begründet und verursachen Reibungsverluste für die Nutzer.
Die häufigsten Probleme sind unangekündigte Wartungsarbeiten auf Bankenseite und die technischen Probleme, die manchmal bei der Umsetzung der PSD2 auf Bankenseite auftreten – schließlich ist dies auch für sie eine relativ neue Sache.”
Das wirkt sich auf das Nutzererlebnis während der gesamten User Journey aus. Ein Beispiel: Es gibt ein Problem auf der Bankenseite der Lösung, und der Mechanismus zur Aktualisierung der Token ist eine Zeit lang nicht verfügbar. Wenn das passiert, während die Kunden der Bank ihre Systeme nutzen, ist das zwar ärgerlich, aber kein Beinbruch – man kann sich nicht anmelden, “wir entschuldigen uns für die Unannehmlichkeiten” und versuchen es in 5 Minuten erneut.
Jake Sebastian-Jones ist CTO bei Nordigen (Website), das nach eigenen Angaben mehr als 2000 API-Verbindungen zu europäischen Banken herstellt. Sebastian-Jones ist Experte für Open Banking und algorithmischem Handel. Er war bereits Softwareentwickler bei IBM, Supercomputing Researcher bei Pawsey, Senior Software Engineer bei Dolby Laboratories und Entwickler bei Optiver. 2018 kam Jake als Entwicklungsleiter zu Nordigen und wurde 2019 CTO von Nordigen.Für andere Marktteilnehmer, die Screen Scraping einsetzen und die Anmeldedaten des Endnutzers speichern, um sich in dessen Namen jederzeit – hoffentlich innerhalb des vereinbarten Zeitfensters – bei der Bank anmelden zu können, mag dies kein Problem darstellen, für Nordigen ist dies jedoch ein inakzeptables Sicherheitsproblem, das mit Kosten verbunden ist.
Die Entwicklung einer Finanzlösung auf der Grundlage einer instabilen API ist eine Herausforderung. Wenn die API einer Bank instabil ist, kann das System eines Drittanbieters, der direkt darauf aufbaut, für diese Bank ausfallen. Die Folge sind Reibungsverluste und Unzufriedenheit der Kunden mit der Lösung.”
Langsame Reaktionszeiten von Banken
Obwohl die Dokumentation größtenteils leicht zu lesen ist, sind der Support und die Reaktionszeit der deutschen Banken selbst nicht immer ideal. Wenn Open-Banking-Integrationen erstellt werden, können verschiedene Probleme und Fragen auftauchen, wie z. B. Probleme mit der API-Stabilität oder mit der Datenzuordnung, die nur von den Banken selbst gelöst und beantwortet werden können. In Deutschland können die Antwortzeiten sehr langsam sein, wobei einige Banken auf E-Mails, die von Nordigen vor bis zu drei Monaten verschickt wurden, noch nicht geantwortet haben. Diese Herausforderung verzögert oder verhindert in einigen Fällen sogar den Integrationsprozess. Es schafft auch Probleme für die Kunden des Integrators, die ihren Nutzern keinen hochwertigen Service bieten können.
Selbst die Gewinner der API-Testumfrage lassen manchmal “den Ball fallen”. Einige bemerkenswerte Beispiele: Die Targo Bank wird als gut bewertet, und der Integrationsprozess war in der Tat vergleichsweise einfach, aber ihr Support-Team scheint überlastet zu sein – die Reaktionszeiten sind gelinde gesagt unterdurchschnittlich. Wir haben mehr als einen Monat lang versucht, mit der Deutschen Bank Kontakt aufzunehmen, nur um schließlich zu erfahren, dass das Problem “auf ihrer Seite nicht reproduzierbar ist”. Auch einige andere große Unternehmen könnten ihren “Support” verbessern.
Wir erwarten keine sofortige Antwort, aber eine Antwort innerhalb von ein oder zwei Wochen wäre schon angemessen.”
Es sind nicht nur deutsche Banken
Es muss erwähnt werden, dass viele dieser Probleme bei der Integration von Banken nicht nur in Deutschland auftreten.”
Es muss erwähnt werden, dass viele dieser Probleme bei der Integration von Banken nicht nur in Deutschland auftreten.”
Insgesamt ist Nordigen auf eine Vielzahl von Hindernissen gestoßen, die nicht mit den regulatorischen Anforderungen übereinstimmen.
Polnische Banken zum Beispiel folgen ihrer eigenen Version der PSD2-Implementierung, der “Polish API“. Angeblich gibt es dafür Gründe, aber auch hier ist der Preis eine komplexere Umsetzung ohne spürbare Vorteile.
Mehrere Banken in Spanien, darunter auch einige Großbanken, sind ebenfalls dafür berüchtigt, dass sie sich mit der Bearbeitung von Support-Tickets im Zusammenhang mit der PSD2 Zeit lassen.”
Außerdem sind viele Antworten entweder zu vage oder erfordern zusätzliche Schritte. In einigen Fällen haben die Banken zusätzliche Unterlagen und Registrierungen verlangt, um den Integrationsprozess zu erleichtern, und in anderen Fällen haben sie behauptet, dass sie die Genehmigung anderer Parteien benötigen, um voranzukommen. So teilte eine Bank Nordigen mit, nachdem sie weitere Informationen für die Integration angefordert hatte, dass ihr Managementteam eine Vorbesprechung abhalten müsse, bevor sie die Integration genehmigen könne.
Auch wenn diese Herausforderungen weder mit den regulatorischen Anforderungen noch mit PSD2 in Einklang stehen, verzögern sie den Integrationsprozess doch massiv, ohne dass die Unternehmen etwas dagegen unternehmen können.
Glücklicherweise ist nicht alles schlecht, und es gibt viele gute Beispiele von Banken in Europa mit stabilen APIs und strukturierten Daten, von denen andere Banken hoffentlich lernen können.”
Einige bemerkenswerte Beispiele aus Deutschland sind die HVB (einfache Integration und angemessene Reaktionszeiten des Supports) und die TargoBank, trotz ihrer langsameren Supportzeiten. N26 ist in Bezug auf die Stabilität der API nicht der Gewinner, aber die Probleme sind in der Regel von kurzer Dauer und können behoben werden, und die Integration war unkompliziert.
Warum sind diese Probleme so weit verbreitet?
Über die Ursachen dieser unnötigen Reibung können wir nur spekulieren. Eine mögliche Ursache ist, dass die Banken die Kosten für den Aufbau konformer APIs übernehmen und den Zugang zu den Daten kostenlos zur Verfügung stellen müssen. Wenn die Bank darin keinen Geschäftsnutzen sieht, wird sie es auf die lange Bank schieben, und die für PSD2 bereitgestellten Ressourcen werden so gering wie möglich gehalten.
Einige Banken argumentieren, dass die Einführung von Open Banking zu langsam ist und dass eine Bezahlschranke für die über APIs bereitgestellten Daten die Einführung beschleunigen würde, indem sie zusätzliche Anreize schafft. In Wirklichkeit erhöht dieses Modell nur die Komplexität des Prozesses und wird die gleichen Probleme hervorrufen, mit denen die Vereinigten Staaten derzeit mit ihren Banken konfrontiert sind, wo Unternehmen, die als Zwischenhändler fungieren, für das Funktionieren von Open Banking erforderlich sind.
Die Finanzwelt verändert sich, und Open Banking wird bleiben.”
Wir bei Nordigen glauben, dass selbst große Finanzinstitute, die es gewohnt sind, ihre Geschäfte auf die alte Art und Weise abzuwickeln, davon profitieren werden, wenn sie diese Tatsache akzeptieren, sie annehmen und einen Weg finden, ihren Kunden neue, innovative Produkte anzubieten, selbst wenn zusätzliche Kosten für die Implementierung und Unterstützung der erforderlichen Infrastruktur anfallen.
Wir sehen, dass sich Open Banking durchsetzt. Es gibt viele, viele Banken, die offen für Innovationen sind, und sie bewegen sich vorwärts.Jake Sebastian-Jones, CTO Nordigen
Sie finden diesen Artikel im Internet auf der Website:
https://itfm.link/131619
Schreiben Sie einen Kommentar