Als ich mich im Jahr 2019 zum ersten Mal mit dem Thema Bankintegration befasste, ergab meine Suche nur wenig über die offizielle Dokumentation hinaus. Spulen Sie vier Jahre zurück, und eine ähnliche Suche bei einem Drink in einer örtlichen Bar führte immer noch nicht zu fruchtbaren Ergebnissen. In diesem Moment kam mir die Idee, eine Reihe von Artikeln über unsere Erfahrungen mit der Integration von Banken bei Circit - in der wir unsere Benutzerszenarien, gewonnenen Erkenntnisse und unser Wissen teilen.
Der anfängliche Schwerpunkt dieser Artikel wird sich um unsere Nutzung von Bankintegrationen drehen, wobei wir die Herausforderungen, auf die wir gestoßen sind, die Entwicklung unserer Produkte und unsere Erfahrungen aus erster Hand erläutern werden. Nachfolgende Veröffentlichungen werden sich mit praktischen Aspekten wie Zertifikatsmanagement, Signaturvalidierung, Autorisierungsverfahren, Onboarding-Protokollen und den Feinheiten der Einhaltung gesetzlicher Vorschriften befassen.
Innerhalb unseres Unternehmens verfügen wir über mehrere Produkte zur Nutzung von Banktransaktionsdaten, eines davon ist Geprüfte Transaktionen. Im Wesentlichen bieten wir bei Prüfungen einen beschleunigten Zugang zu den Bankdaten unserer Kunden. Mit über 2.300 aktiven Integrationen, die traditionelle Banken, Fintech-Startups, Krypto-Wallets und mehr umfassen, arbeitet Circit unter der Aufsicht der FCA in Großbritannien und der CBI in Irland. Als Anbieter von Kontoinformationsdiensten (Account Information Service, AIS) bietet Circit lediglich einen Lesezugriff ohne Finanztransaktionen.
Einer der mühsamsten Aspekte bei der Entwicklung unserer Lösungen ist zweifellos der Integrationsprozess.
Obwohl die Welt der Technologie auf dem Weg zur Vereinheitlichung ist, sind wir noch weit davon entfernt, und hier ist der Grund dafür:
Es gibt mehrere Rahmenwerke: CDR, PSD2, SX2A, STET und viele andere, wobei jede Bank und manchmal sogar einzelne Filialen unabhängig voneinander entscheiden, welchen Rahmen sie nutzen und ob sie ihn überhaupt nutzen wollen.
Lokale Aufsichtsbehörden haben oft ihre eigenen Anforderungen an lokale Bankstellen, die viele Auswirkungen haben können, von Einschränkungen bei den bereitgestellten Daten bis hin zu Autorisierungs- und Authentifizierungsmethoden.
Verschiedene Banken befinden sich in unterschiedlichen Stadien der Umsetzung der Innovation, haben oft alte Systeme hinter einer schicken Schnittstelle oder alle Arten von Frankenstein-Systemen, seien Sie nicht überrascht, wenn der gleiche Endpunkt je nach Szenario json oder xml zurückgeben kann.
Obwohl die Technikwelt eine Vereinheitlichung anstrebt, behindern mehrere Faktoren diesen Fortschritt:
- Mehrere Rahmenwerke: Es gibt zahlreiche Rahmenwerke wie CDR, PSD2, SX2A, STET, die von den Banken oder sogar einzelnen Filialen unabhängig voneinander gewählt werden. Dies führt zu einer Fragmentierung und Inkonsistenz bei den Ansätzen zur Datenverarbeitung und den Sicherheitsmaßnahmen.
- Regulatorische Vielfalt: Lokale Regulierungsbehörden stellen unterschiedliche Anforderungen an Bankstellen, von Datenbeschränkungen bis hin zu Genehmigungs- und Authentifizierungsmethoden. Dies führt zu zusätzlicher Komplexität und abweichenden Praktiken in den verschiedenen Regionen.
- Vielfältige Bankinfrastruktur: Banken arbeiten mit unterschiedlichen Infrastrukturen, die von veralteten Systemen, die durch moderne Schnittstellen verdeckt sind, bis hin zu komplexen hybriden Systemen reichen. Folglich können die Endpunkte Daten in unterschiedlichen Formaten (z. B. JSON oder XML) zurückgeben, was die Integrationsbemühungen erschwert.
Diese Herausforderungen machen deutlich, dass standardisierte Verfahren und Interoperabilität im Bankensektor erforderlich sind, um reibungslosere Abläufe zu ermöglichen und die Sicherheitsmaßnahmen zu verbessern.
Das Fehlen globaler Standards im Bankensektor führt dazu, dass die Banken unabhängige Entscheidungen treffen, die oft von den Branchentrends abweichen. Dieser Mangel an Einheitlichkeit hat uns vor allem in der Anfangsphase, als unser Wissen und unsere Erfahrung noch begrenzt waren, vor große Herausforderungen gestellt. Im Folgenden finden Sie einige der Annahmen, die wir getroffen haben, und die Lehren, die wir daraus gezogen haben:
- Britische Auslegung der PSD2: Wir gingen davon aus, dass die Integration mit Banken mit der britischen Auslegung der PSD2 übereinstimmen würde. Dies führte jedoch zu einer fehlerhaften Integration vieler Domänenzustände, einer falschen Terminologieanpassung und einem Domänenmodell, das auf einer fehlerhaften Umsetzung der Richtlinie basiert.
- Einheitliche Umsetzung des Rahmenwerks: Wir gingen davon aus, dass alle Banken, die ein bestimmtes Framework verwenden, dieses auf dieselbe Weise implementieren würden. In Wirklichkeit führte die Flexibilität der Frameworks zu unterschiedlichen Implementierungsoptionen, die nach der ersten Integration zu einem erheblichen Refactoring-Aufwand führten.
- Konsistente Datenbereitstellung: Wir erwarteten, dass alle Banken vertragsgemäß die gleichen Daten bereitstellen würden. Es kam jedoch zu Diskrepanzen, die auf regulatorische Einschränkungen, kommerzielle Motive oder Anreize zur Nutzung kostenpflichtiger APIs zurückzuführen waren und unsere Integrationsbemühungen erschwerten.
- Einheitliche Bereichsterminologie: Wir gingen davon aus, dass die Fachterminologie von allen Banken einheitlich interpretiert würde. Es traten jedoch Unstimmigkeiten auf, wie z.B. unterschiedliche Auslegungen von Bilanzarten.
- Komplexität der Autorisierung: Die Autorisierung erwies sich als ein schwieriger Aspekt der Integration, da sie zusätzliche Client-Einstellungen erforderte, die oft nicht intuitiv waren. Anfänglich konzentrierten wir uns auf die OAuth2-Autorisierung, entdeckten aber später über 20 verschiedene Autorisierungsmethoden.
- Transaktionsumfang: Wir haben den Umfang der Transaktionen unterschätzt, was zu einer suboptimalen Wahl der Datenspeicherung führte. Was wir ursprünglich als mehrere tausend Transaktionen pro Konto mit 14-stelligen Beträgen erwartet hatten, entpuppte sich als Millionen von Transaktionen mit wesentlich höheren Beträgen.
- Maßgeschneiderte Banklösungen: Entgegen unseren Erwartungen handelte es sich bei über 50 % der Integrationen um eigene Lösungen der Finanzinstitute und nicht um standardisierte Frameworks.
Jede dieser Annahmen führte zu Herausforderungen, die wir erfolgreich meisterten. Ein evolutionärer Ansatz für die Lösungsentwicklung und eine anpassungsfähige Architektur trugen maßgeblich zur Überwindung dieser Hürden bei.
Zusammenfassend lässt sich sagen, dass die Navigation durch die komplizierte Landschaft der Bankenintegration eine Reise voller Herausforderungen, Lektionen und Entwicklungen war. Wenn wir über unsere Erfahrungen nachdenken, wird deutlich, dass der Weg zur Vereinheitlichung im Bankensektor lang und kurvenreich ist, aber nicht ohne Belohnungen. Durch einen evolutionären Ansatz bei der Lösungsentwicklung haben wir Rückschläge in Chancen für Wachstum und Innovation verwandelt.
Mit Blick auf die Zukunft sind wir weiterhin bestrebt, unsere Einsichten, Erfahrungen und technischen Erkenntnisse mit der gesamten Gemeinschaft zu teilen. Durch Zusammenarbeit, Anpassungsfähigkeit und ein gemeinsames Engagement für Spitzenleistungen können wir die vor uns liegenden Hürden überwinden und den Weg zu einem einheitlicheren und effizienteren Ökosystem im Bankwesen ebnen.
Wir danken Ihnen, dass Sie uns auf dieser Reise begleitet haben, und freuen uns darauf, gemeinsam das nächste Kapitel aufzuschlagen.
