Wie können Finanzinstitute und FinTechs neue Technologien am besten einführen und gleichzeitig den Vorgaben und Gesetzen der Europäischen Union (EU) entsprechen?
In seinem ersten Beitrag beschreibt der Autor, Open Banking-Berater und Trainer, Jon Scheele welche Ansätze man braucht um Cybersicherheit in Partnerschaften zwischen Finanzinstituten und FinTechs zu integrieren. Sein zweiter Artikel beleuchtet die Auswirkungen der rechtlichen Rahmenbedingungen in der EU auf Cybersicherheit nach der Open-Banking-Ära und welche Rolle sichere APIs dabei spielen.
In diesem Beitrag sehen wir uns die Referenzarchitektur von APIs für Open Banking genauer an. Und wir beschäftigen uns damit wie Finanzinstitute und FinTechs innerhalb dieser Architektur Daten sicher austauschen können. Im Zusammenspiel mit den bereits beschriebenen Autorisierungsabläufen haben Finanzinstitute und FinTechs die Möglichkeit ihre Daten sicher und im Einklang mit den EU-Gesetzen zu versenden und zu teilen.
Ziel dieser Referenzarchitektur ist es, Finanzinstituten Komponenten für eine widerstandsfähige Infrastruktur aufzuzeigen um:
- die Wahrscheinlichkeit eines erfolgreichen Cyberangriffs zu senken,
- für eine reibungslose und schnelle Wiederherstellung zu sorgen und
- damit Partner, Regulatoren und andere Beteiligte koordiniert auf einen Angriff antworten (und das Problem lösen) können.
Anforderungen an Cybersicherheit
In Teil 1 werden die folgenden Cybersicherheitsaktivitäten für Finanzinstitute (FIs), die eine Open Banking-Initiative einführen, zur Pflicht:
- Kunden authentifizieren,
- Zustimmung (Autorisierung) von Kunden, um Daten mit Drittanbietern (Third Party Provider (TPP)) zu teilen,
- Zustimmung für Auditzwecke erfassen,
- Kunden die Möglichkeit bieten ihre Zustimmung zu wiederrufen,
- Partner und deren Sicherheitslevel prüfen,
- Partnern sicheren Zugriff auf Kundeninformationen bieten (und nur auf die Informationen, für die der Kunde die Erlaubnis gegeben hat)
Technische Regulierungsstandards für starke Kundenauthentifizierung (RTS SCA)
In Teil 1 haben wir die Authentifizierungs- und Autorisierungsabläufe für Finanzinstitute beschrieben, mit denen sie die Zustimmung von Kunden einholen, bevor deren Daten an Drittanbieter für Zahlungsdienste (TPPs) weitergegeben werden. Wir haben Teilschritte gezeigt, um Abläufe unter OAuth2.0 und OpenID Connect zu ermöglichen.
Ab September 2019 treten zusätzliche Anforderungen in Kraft. In den Technischen Regulierungsstandards für starke Kundenauthentifizierung und Common and Secure Open Standards für Kommunikation (kurz oft als RTS SCA bezeichnet) wird festgelegt, dass Account Servicing Payment Service Provider (ASPSP) Authentifizierungsmechanismen entweder mit dem Interface eines Drittanbieters umsetzen oder die eigene Bankapplikation entsprechend modifizieren müssen.
Es gibt drei Hauptansätze bei denen Authentifizierung und Autorisierung des Kunden über ein eigenes Interface passiert:
- Weiterleitung: der Kunde wird von FinTech-Seite oder vom Bezahldienst der Drittanbieteranwendung an den Autorisierungsserver der Bank weitergeleitet und nach Abschluss zurück zum Client des FinTechs.
- Einbettung: die Authentifizierungsdaten des Kunden werden zwischen FinTech und Finanzinstitut über das Interface ausgetauscht. Der Kunde kann seine Zustimmung zur Transaktion über den Client des FinTechs geben.
- Auskoppelung (oder eine Kombination daraus): die Bank fragt die Zahlungsautorisierung des Kunden zum Beispiel über eine bestimmte Handyapp ab oder über eine andere Applikation oder ein Gerät je nach dem, welches Onlinebanking-Frontend verwendet wird.
Das Finanzinstitut sollte die Methode auswählen, die am besten zu den Authentifizierungsvorgängen passt, die man dem Kunden auf dem eigenen Online- Kundeninterface anbietet.
Anwendung- und Transport-Layer gemäß PSD2 RTS SCA sichern
Wenn die Authentifizierung und Autorisierung des Kunden (ein ‚Zahlungsdienstnutzer‘ oder auch PSU im PSD2-Jargon genannt) gestärkt wird, führt das zwangsläufig zu einem höheren Sicherheitslevel. So wird sichergestellt, dass die Nachrichten zwischen FinTechs oder Drittanbietern von Zahlungsdiensten und Finanzinstituten (ein Account Servicing Payment Service Provider, kurz ASPSP in PSD2) tatsächlich das sind, was sie vorgeben zu sein.
Der NextGen PSD2 Framework der Berlin Group beschreibt ein API ‚Access-to-Accounts‘ (XS2A) Interface. Der Rahmenplan besteht aus einem Anwendungs-Layer und einem Transport-Layer.
- Das Anwendungs-Layer besteht aus den Dienstbestimmungen für den Account selbst und Datenmodellen für Haupt- und Nebendienstleistungen.
- Das Transport-Layer umfasst das Erstellen von Nachrichten und den Nachrichtenaustausch.
Auf der Ebene des Anwendungs-Layers nutzt man qualifizierte Zertifikate für elektronische Siegel, um Daten und Dokumente, die von einem Zahlungsdienstanbieter stammen (also etwa FinTech oder Finanzinstitut), zu identifizieren. Ein Siegel bestätigt die Authentizität des Dokuments oder der Daten. Es versichert dem Empfänger, dass das Dokument oder die Daten wirklich von diesem Zahlungsdienstanbieter kommen, und nicht abgeändert wurden. Qualifizierte Zertifikate werden von einem Qualified Trust Service Provider (QTSP) gemäß den eIDAS-Verordnungen ausgestellt. Das Zertifikat gibt an für welche Rollen das FinTech autorisiert ist und zeigt die von einer National Competent Authority (NCA) ausgestellte Autorisierungsnummer.
Auf der Ebene des Transport-Layers sichert eine TLS-Verbindung die Kommunikation zwischen FinTech und Finanzinstitut ab. Gemäß der PSD2 Technischen Regulierungsstandards (RTS) braucht man für die Websiteauthentifizierung ein qualifiziertes Zertifikat ausgestellt von einem QTSP. Gleiches gilt für die eIDAS-Verordnung.
Eine Referenzarchitektur für ASPSPs und TPPs
Für eine erfolgreiche Integration werden braucht man Komponenten sowohl vom Finanzinstitut als auch vom betreffenden FinTech:
Der Kunde nutzt ein Webinterface oder eine Clientanwendung, die vom FinTech bereitgestellt wird.
Das FinTech bietet seine Dienste an über:
- einen Webserver, der die Clientapplikation für den Kunden hostet,
- einen Identitätsserver, um Kunden zu authentifizieren und
- einen Signing-Server, um das qualifizierte PSD2-Zertifikat von einem Qualified Trust Service Provider anzufragen.
Das Finanzinstitut bietet dem FinTech-Zugang an indem es:
- seine Dienste über ein Access-to-Accounts (XS2A) Interface per API Gateway freigibt,
- mit dem qualifizierten PSD2-Zertifikat die Identität und Integrität des FinTechs und dessen Nachrichten prüft,
- Kundenzustimmung einholt, um Informationen über den Autorisierungsserver zu teilen und
- den Zugriff auf Kundeninformationen aus dem Ressourcenserver bereitstellt.
Der Qualifizierte Vertrauensdiensteanbieter (QVDA) bietet Sicherheit für die Partnerschaft zwischen dem Finanzinstitut und dem FinTech durch:
- die Bestätigung, dass das FinTech sich bei der zuständigen Behörde im EU-Mitgliedsland des FinTechs registriert hat,
- die Bereitstellung eines qualifizierten Zertifikats, wenn das vom FinTech verlangt wird,
- die Bereitstellung eines qualifizierten Zertifikats mit allen notwendigen PSD2-Daten und
- den Rückruf von Zertifikaten auf Anfrage – ausgehend vom FinTech oder auch der National Competent Authority.
Die Referenzarchitektur auf Open Banking- Partnerschaften anwenden
Die vorgestellte Referenzarchitektur bietet Hilfestellung für eine sichere Interoperabilität. So können Finanzdienstleister (FinTechs und Finanzinstitute gemeinsam) ihr Leistungsversprechen an ihre Kunden erweitern. Der Erfolg hängt davon ab, ob sie:
- Partner anziehen und sie mehr Auswahl bieten, die wiederum die Benutzerzufriedenheit verbessert;
- es dem Kunden leicht machen, seine Zustimmung auf sichere Art und Weise zu geben (oder zu wiederrufen), damit vertrauliche Informationen mit Partnern und Drittanbietern geteilt werden dürfen und
- sicherstellen, dass alle Beteiligten über starke Maßnahmen zur Cybersicherheit verfügen um Kundeninformationen zu schützen.
In seinem nächsten Beitrag beschäftigt sich der Autor mit Implementierungsoptionen der verschiedenen Komponenten der Referenzarchitektur gemäß den PSD2 Technischen Regulierungsstandards (RTS).
Für weitere Informationen zu PSD2 und SCA, einschließlich des Zeitplans, klicken Sie auf diese Infografik des European Payments Councils – PSD2 Explained.
Das Pro und Contra von Blockchain-Technologie in Banking und Vermögensverwaltung
Übersichtlich, intuitiv und sicher: Online-Banking-Nutzer sind zufrieden
Deutschland auf dem Weg zur digitalen Republik: Apps, Online Banking, Smartphone und Co.