Für eine Bank ist PSD2 der Moment, in dem Systeme, die jahrelang für den geschlossenen Betrieb gebaut wurden, sich plötzlich über APIs zur Welt öffnen müssen. Die Richtlinie verlangt von der Bank, Kontodaten und die Zahlungsauslösung lizenzierten Dritten zugänglich zu machen, und Open Banking macht daraus mehr als eine Rechtspflicht: eine echte Verschiebung in der Architektur. Für einen Chief Digital Officer, einen Architekten oder einen IT-Leiter heißt das eines: PSD2 ist ein Technologieprojekt und nicht nur eine Compliance-Übung.
Nach unserer Erfahrung liegt die Schwierigkeit nicht darin, die Richtlinie zu verstehen, sondern sie in sichere, stabile und wartbare APIs zu übersetzen - in einer Umgebung, in der Bankenkern, Anti-Fraud-Systeme und regulatorische Anforderungen gleichzeitig laufen. Wir haben in diesem Feld keine öffentliche Referenz, und wir tun nicht so, als wäre es anders. Wir tun etwas anderes, und darin sind wir stark: Wir stellen die Menschen, die es bauen - Engineers mit Erfahrung in Bankintegrationen und Plattform-Delivery, eingebunden in Ihr Team als Team-Verstärkung oder als dediziertes Team.
Was sind PSD2 und Open Banking, und wozu zwingen sie eine Bank?
PSD2 ist die EU-Zahlungsdiensterichtlinie, die den Markt für neue Akteure öffnet und Banken zur Zusammenarbeit mit ihnen verpflichtet. Open Banking ist das umfassendere Phänomen, das daraus erwächst: Die Bank hört auf, ein geschlossenes Silo zu sein, und wird zum Anbieter von Diensten über Schnittstellen.
In der Praxis zwingt die Richtlinie eine Bank zu mehrerem auf einmal:
- Kontozugriff (AIS) und Zahlungsauslösung (PIS), bereitgestellt für Dritte,
- starke Kundenauthentifizierung (SCA) überall dort, wo das Risiko es verlangt,
- eine sichere, dokumentierte Schnittstelle für Dritte, ausgerichtet an einem gewählten Standard,
- eine Testumgebung und Registrierung, damit externe Anbieter sich anbinden können.
Das ist keine einmalige Änderung in einem einzelnen System, sondern eine neue Schicht, die Sie neben dem Rest der Bank pflegen und weiterentwickeln müssen.
Wie stellen Sie APIs für Dritte bereit (AIS/PIS)?
Im Kern der Bereitschaft stehen zwei Arten von Diensten. AIS (Account Information Service) erlaubt einem Dritten, mit Einwilligung des Kunden Konto- und Transaktionsdaten zu lesen. PIS (Payment Initiation Service) erlaubt ihm, eine Zahlung direkt vom Konto des Kunden auszulösen, ohne Karte dazwischen.
Diese Schnittstellen zu bauen heißt mehr, als einen Endpunkt freizuschalten. Wir entwerfen sie so, dass sie echten Verkehr von vielen Parteien gleichzeitig tragen, mit einem klaren Vertrag und ohne die Quellsysteme zu überlasten. Wir binden die API-Schicht über stabile Integrationen an den Bankenkern an, ergänzen Rate Limiting und Versionierung und stellen das Ganze auf den Standard, den die Bank gewählt hat - damit nicht jede neue Anbindung eines Dritten den Umbau des Fundaments verlangt.
Wie funktioniert starke Authentifizierung (SCA) im Kontext von APIs?
Starke Kundenauthentifizierung (SCA) ist die Anforderung, die Identität mit mindestens zwei unabhängigen Faktoren zu bestätigen: etwas, das der Kunde weiß, etwas, das er besitzt, und etwas, das er ist. In der API-Welt entscheidet SCA darüber, ob die Öffnung der Bank sicher bleibt oder zu einer Tür für Missbrauch wird.
Die Herausforderung besteht darin, SCA in API-Abläufe einzuweben, ohne das Kundenerlebnis zu zerstören. Wir setzen sie aus mehreren Teilen zusammen:
- Redirects und Tokens, die die Sitzung des Kunden mit der Anfrage des Dritten verbinden,
- Umgang mit SCA-Ausnahmen dort, wo die Regulierung sie zulässt (z. B. niedrige Beträge, vertrauenswürdige Empfänger),
- Bindung der Einwilligung an die Authentifizierung, damit der Kunde weiß, wozu er zustimmt,
- Abstimmung mit Anti-Fraud-Systemen, die das Transaktionsrisiko im Hintergrund bewerten.
Eine gut entworfene SCA schützt Bank und Kunde, ohne jede Operation in eine Geduldsprobe zu verwandeln.
Wie gehen Sie mit Sicherheit und Kundeneinwilligung um?
Die Öffnung der Bank über APIs schiebt die Vertrauensgrenze nach außen, deshalb wird die Verwaltung von Einwilligungen zu einer eigenen Komponente und nicht zu einer Fußnote. Der Kunde muss wissen, wem er für wie lange Zugriff gewährt, und ihn jederzeit widerrufen können, während die Bank diesen Zustand festhält, durchsetzt und prüfbar macht.
Wir betrachten hier mehrere Schichten zugleich: Verschlüsselung und Zertifikate in der Kommunikation mit Dritten, ein Einwilligungsregister, das an einen konkreten Datenumfang gebunden ist, einen vollständigen Audit-Trail jedes Zugriffs und ein Monitoring, das ungewöhnliche Verkehrsmuster erkennt. Sicherheit im Open Banking ist kein einzelnes Feature, sondern eine Eigenschaft der gesamten Architektur - und so behandeln wir sie von der ersten Codezeile des Projekts an.
Wie entwerfen und steuern Sie die API-Architektur?
Das technische Herz von PSD2 ist die Schicht zwischen der Außenwelt und dem Inneren der Bank. Sie wird meist um ein API-Gateway herum gebaut, mit einer durchgängigen Steuerung des Lebenszyklus der Schnittstellen.
Wir setzen diese Schicht aus Teilen zusammen, die zusammenspielen müssen:
- einem API-Gateway als Eintrittspunkt für Authentifizierung und Rate Limiting,
- Microservices, die Anfragen in Operationen in den Systemen der Bank übersetzen,
- einem Developer-Portal mit Dokumentation und Testumgebung (Sandbox),
- Monitoring und Observability, um Verkehr, Fehler und Performance in Echtzeit zu sehen.
Dieses Fundament hält die APIs unter Kontrolle, während die Zahl der angebundenen Parteien wächst.
Warum ist Open Banking eine Chance und nicht nur eine Pflicht?
Die meisten Banken starten mit Compliance, doch dort stehenzubleiben verschenkt das Potenzial. Dieselbe Infrastruktur, die Sie für die Pflicht bauen, öffnet den Weg zu Banking as a Service und neuen Erlösmodellen.
Mit soliden, gut gesteuerten APIs kann eine Bank tiefer gehen: Partnern Dienste über Schnittstellen anbieten, Zahlungen in Apps Dritter einbetten, eigene Fintech-Produkte auf ihrer Plattform bauen. Das ist die entscheidende Verschiebung im Denken - die Investition in APIs hört auf, Compliance-Kosten zu sein, und wird zum Produktfundament. Deshalb lohnt es, die Architektur von Anfang an mit Blick auf diese zweite Stufe zu entwerfen, auch wenn die Regulierung den Anstoß gibt.
Welche Kompetenzen stellen wir für ein PSD2-Projekt bereit?
Für ein solches Projekt reicht ein Profil nicht aus. Wir besetzen die Rollen rund um die konkrete Arbeit, nicht „auf Vorrat”:
- Lösungsarchitekten, die Integrationen in den Bankenkern und API-Muster verstehen,
- Backend-Entwickler (z. B. Java, .NET), die AIS/PIS-Dienste und die SCA-Logik bauen,
- DevOps- / Plattformspezialisten, die API-Gateway, Umgebungen und Pipelines aufsetzen,
- Security-Engineers, die Verschlüsselung, Einwilligungen und Audit verantworten.
Erfahrung in Plattform-Delivery und Bankintegrationen behandeln wir als Eintrittsbedingung, nicht als Bonus.
Wie schnell kann ein Team in ein Bankprojekt einsteigen?
Tempo kann hier entscheidend sein, denn regulatorische Fristen verhandeln nicht. Unsere Besetzung schließen wir üblicherweise in etwa drei Wochen ab; nur bei außergewöhnlichen Anforderungen dehnt es sich auf zwei Monate. Als Nearshore-Partner aus Polen arbeiten wir in einer nahen Zeitzone, sodass Engineers ohne langen Anlauf in Ihren Arbeitsrhythmus, Ihre Code-Reviews und Ihre Termine einsteigen. In einer Bankumgebung rechnen wir Zeit für Sicherheitsprozesse und Zugänge dazu - und planen sie ehrlich ein.
Wie machen wir das bei RITS?
Wir tun es als Nearshore-Partner aus Polen, der Ihr Team mit Menschen verstärkt und nicht mit Folien. In PSD2 und Open Banking ist unsere Rolle konkret:
- wir besetzen die Rollen Architektur, Backend, DevOps und Security, passend zu Ihrem Stack,
- wir bauen die API-Schicht und die Integrationen unter der Steuerung und nach den Standards Ihrer Bank,
- wir bringen Plattform- und Integrationserfahrung ein, ohne Einführungen anderer als unsere auszugeben,
- wir prüfen die Kompetenzen vor dem Start, denn eine Bank lässt keinen Raum für Vermutungen.
Meist arbeiten wir als Team-Verstärkung oder dediziertes Team, und wo ein abgeschlossener Umfang nötig ist, als Individualsoftware-Projekt, geliefert von unserem Team.
Wo beginnen Sie mit der Vorbereitung auf PSD2 und Open Banking?
Beginnen Sie mit einer Frage: welche Dienste (AIS, PIS, SCA) und in welchem Standard Sie zuerst bereitstellen müssen und wie sich das an Ihren Bankenkern anschließt. Diese Antwort legt die API-Architektur, die Sicherheitsanforderungen und die Rollen im Team fest. Erst danach lohnt die Entscheidung über ein Kooperationsmodell - die Unterschiede haben wir in unserem Artikel zu IT-Kooperationsmodellen beschrieben.
Sie bereiten eine Bank auf PSD2 und Open Banking vor? Sprechen wir darüber - wir finden die Engineers und die Architektur, die es gemeinsam mit Ihnen bauen.