Umsetzungsvorschlag zur Schaffung eines Systems für den Austausch von Finanzdaten gemäß Art. 9-11 des FiDA-Verordnungsentwurfs der EU-Kommission

Von Manuel Wanner-Behr & Felix Baaken, beide Geschäftsführer bei BANKSapi Technology GmbH

Sie erfahren in diesem Beitrag:

• Die wesentlichen Regelungen des EU-Verordnungsentwurfs (VO-E) zum „Framework for Financial Data Access (FiDA)“.
• Was ein Financial Data Sharing Scheme (FDSS) ist.
• Welche Wertschöpfung ein Scheme für die Teilnehmer erbringt.
• Wie ein FDSS konkret in der Praxis aussehen kann.
• Wie Identifizierung, Authentifizierung und Autorisierung der Scheme-Teilnehmer erfolgen kann.

Vorwort

Liebe Leserin,
lieber Leser,

geht es Ihnen auch so? Sie fühlen sich durch die bereits zahlreichen Veröffentlichungen und Whitepapers rund um den Verordnungsentwurf (VO-E) „Framework for Financial Data Access (FIDA)“ der EU-Kommission vom 23.06.2023 und dem Sammelbegriff „Open Finance“ sowie den daraus resultierenden Chancen, Implikationen und Use Cases vorerst ausreichend aufgeklärt. Aber stellen sich die entscheidende Frage, wie der übergreifende Datenaustausch in der Praxis umgesetzt werden und später reibungslos vonstattengehen kann?

Diese Frage brannte uns ebenfalls eine ganze Weile unter den Nägeln: Das Brennen wurde intensiver, je mehr wir uns mit Branchenkennern insbesondere aus der Versicherungsszene unterhalten und ihre unterschiedlichen Sichtweisen, aber auch ihre Unsicherheiten kennengelernt haben. Als Dreh- und Angelpunkt der anstehenden Regulierung erscheint uns neben der Öffnung der Daten, das „System für den Austausch von Finanzdaten“ bzw. „Financial Data Sharing Scheme“, welches im Folgenden als „Scheme“ [skiːm] bezeichnet wird. Bislang konnten wir in keiner Verlautbarung ein einheitliches Verständnis von einem Scheme, welches die FiDA im Verordnungsentwurf konkret in den Artikeln 9 bis 11 (VO-E) verpflichtend fordert, erkennen. Aus diesem Grund haben wir uns daran gemacht, eine konzeptionelle Blaupause für ein Datenaustauschsystem zu entwickeln.

Alle bisherigen Ideen und Ausführungen zum FiDA-Themenkomplex sind wertvoll und hilfreich, weil sie die Zukunft mit Open Finance greifbarer machen und mit jedem Mal ein Stück mehr realistischer erscheinen lassen. Bitte verstehen Sie unsere Arbeit als Angebot und als Ergänzung zu den bisherigen Veröffentlichungen rund um FiDA und Open Finance.

Sie fragen sich vielleicht an dieser Stelle, was uns als BANKSapi Technology GmbH [ˈbæŋks əˈpi aɪ] qualifiziert, diesen Beitrag zu verfassen. Zunächst lassen Sie sich bitte von unserem Firmennamen nicht täuschen: wir verstehen uns als Connectivity Provider rund um Open Banking und Open Finance. Wir sind als reguliertes und lizenziertes Zahlungsinstitut nach dem Zahlungsdiensteaufsichtsgesetz (ZAG), welches der PSD2-Regulatorik entstammt, mit dem Datenaustausch im regulierten Umfeld zwischen verschiedenen Marktteilnehmern profund erfahren. Die „API-fizierung“ von datenbasierten Use Cases und der Orchestrierung von Schnittstellen, sogenannten Application Programming Interfaces (API) ist unser Brot- und Butter-Geschäft. Darüber hinaus bringen wir langjährige berufliche Erfahrungen aus dem Banking-, Payment- und Versicherungssektor, gepaart mit tiefgreifendem IT-Verständnis, mit.

Bitte sehen Sie es uns daher nach, dass wir in diesem Beitrag oft auf die Payment-Branche oder auf die Versicherungsbranche in unseren Beispielen und Veranschaulichungen verweisen. Mit besonderem Blick auf den Versicherungssektor, wo mit den BiPRO-Normen des gleichnamigen Brancheninstituts in Deutschland und mit der Free Insurance Data Initiative (FRIDA e.V.) als Treiber schon gute Voraussetzungen existieren und für die Sache eine förderliche Dynamik herrscht, wird sich zusätzlich ein hoher Digitalisierungsdruck auf die Versicherungsunternehmen ergeben – und das, wo noch immer der Digitalisierungsgrad bei den Gesellschaften unterschiedlich stark ausgeprägt ist. Das macht es nicht nur herausfordernd, sondern auch spannend.

Wir sind davon überzeugt, dass diese Verordnung mehr oder weniger gemäß dem diskutierten Entwurf vom neu konstituierten EU-Parlament angenommen und in Kraft treten wird, auch wenn mutmaßlich derzeit einige Markteilnehmer darauf hoffen und intervenieren, die geplante Regulatorik noch in letzter Minute auf EU-Ebene verhindern zu können. Wir haben Verständnis für die unterschiedlichen Einwände, die wir aus Gesprächen beispielsweise mit Versicherungsvorständen vernehmen konnten oder vermuten. Dennoch gebietet sich unseres Erachtens schon allein aus Kundensicht und dem Recht auf Datenauskunft (Artikel 15 DSGVO) sowie dem Recht auf Datenportabilität (Artikel 20 DSGVO) ein Handlungsdruck für die Öffnung der Finanzdatentöpfe.

Bevor Sie mit der Lektüre beginnen, möchten wir eine dringende Handlungsempfehlung schon einmal vorab aussprechen: aus unserer Sicht sollten sich die relevanten Player der Dateninhaber und Datennutzer, repräsentiert durch die bekannten Interessengruppen, schnellstmöglich zusammensetzen und Klarheit über das Vorgehen schaffen. Denn gerade für Dateninhaber ist eine hinreichende Sicherheit bzgl. der Scheme-Ausgestaltung und den nötigen Investitionen in die Anschlussfähigkeit enorm wichtig, da IT-Kapazitäten knapp sind und die IT-Projektportfolios meist von langer Hand geplant werden.

Auf den nachfolgenden Seiten werden wir uns vor allem auf die Herleitung einer Blaupause für ein FiDA-Scheme beschränken. Es werden weitere schlaue Köpfe nötig sein, um sämtliche Fragen geklärt, tiefer auf aufkommende Themen eingegangen zu sein und Herausforderungen bewältigt zu haben. Dieser Beitrag wirft sein Licht auf einen Teilaspekt der anstehenden Regulierung mit technischer Konnotation.

Unabhängig davon sind wir gespannt, was in der Zukunft auf uns zukommen wird. Wir glauben an eine neue Generation von kundenzentrierten Produkten und Dienstleistungen, neue Effizienzpotentiale in der Beratung und in Prozessen sowie neue innovative Geschäftsmodelle – gleichermaßen auf Seiten der Dateninhaber und Datennutzer.

Inhaltsverzeichnis:

1. Zusammenfassung
2. Einführung zu FiDA
3. Definition eines Schemes
4. FiDA-Anforderungen für Schemes und ihre Akteure
5. Wertschöpfung eines Schemes
6. Blaupause eines FiDA-Schemes
7. Identifizierung, Authentifizierung und Autorisierung von Kunden
8. Identifizierung, Authentifizierung und Autorisierung der Scheme-Teilnehmer (Dateninhaber und Datennutzer)
9. Vorbild PSD2: Learnings und Handeln des Regulators
10. Über BANKSapi
11. Die Autoren

1 Zusammenfassung

Der vorliegende Beitrag beleuchtet im Zusammenhang mit dem EU-Verordnungsentwurf zur FiDA das „System für den Austausch von Finanzdaten“, auch Scheme genannt. Wir leiten auf Basis des Legislativtextes zur FiDA und diversen Branchenbeispielen eine Blaupause für ein Scheme her, welches sich exemplarisch an die Versicherungsbranche orientiert. Wir schlagen schließlich mit einem konkreten Modell eine technische Konzeption des Schemes vor, wie der künftige Datenaustausch zwischen Dateninhabern und Datennutzern in effizienter Weise gelingen kann.

Die künftige FiDA-Regulierung (vrsl. 2027) sichert zugelassenen Datennutzern wie Finanzinstitute und künftig Finanzinformationsdienstleister das Recht zu, sofern sie die Zustimmung des Kunden nachweisen, auf Finanzdaten bei Dateninhabern (z.B. Banken, Versicherungsunternehmen, Wertpapierfirmen, Krypto-Verwahrstellen) zuzugreifen. Umgekehrt müssen Dateninhaber ihre Daten öffnen und sie Datennutzern in einem maschinenlesbaren Datenstandard zur Verfügung stellen, um für ihre Kunden auf Basis dieser Daten Finanzdienstleistungen oder sonstige Dienstleistungen erbringen zu können.

Dieser Fachbeitrag geht kurz auf den Kern und die Ziele des EU-Verordnungsentwurfs ein und baut über das generelle Konstrukt eines Schemes mit entsprechenden Beispielen aus anderen Branchen eine Brücke hin zu einer Blaupause für ein FiDA-Scheme (Financial Data Sharing Scheme – FDSS). Im Rahmen dessen werden Wertschöpfungsaspekte herausgearbeitet und mögliche Aufgaben eines Schemes erörtert. Wir beziehen im Zusammenhang mit dem regulierten Datenaustausch sogar weitere Dienstleister (später sogenannte „Service Provider“) mit ein, da sie aus unserer Sicht in der neuen „Datenfreizügigkeit“ das Wertschöpfungspotential rund um Finanzdaten signifikant erweitern werden. Die Herleitung gipfelt in einem Modell, das die Organisation des Datenaustauschs zwischen allen Akteuren aus einer eher technischen Sicht veranschaulicht.

Wir kommen zu dem Schluss, dass neben der Organisation eines Schemes aus Governance und technischen Gesichtspunkten, die technischen Standards für den Datenaustausch sowie das Rollen- und Rechtemanagement rund um Identität, Authentifizierung und Autorisierung von Kunden und Datennutzern die wesentlichen Herausforderungen bei der Umsetzung eines Financial Data Sharing Schemes sein werden. Aus diesem Grund raten wir zu einer zügigen Organisation eines Schemes unter Beteiligung aller relevanten Interessengruppen der jeweiligen Branche, um im Wettlauf gegen die Zeit die Oberhand zu behalten und für die Parteien Chancen aus der Regulatorik zu manifestieren.

Wir verwenden im Folgenden die männliche Form für einen vereinfachten Leserfluss, meinen aber einschließlich aller geschlechterspezifischen Bezeichnungen.

2 Einführung zu FiDA

Der Verordnungsvorschlag der EU für den Rahmen des Financial Data Access (FiDA) zielt darauf ab, die digitale Transformation im Finanzsektor zu fördern. Ziel ist es, die Nutzung und Schaffung datengetriebener Geschäftsmodelle zu ermöglichen und die Entwicklung von Open Finance, sprich das Konzept offener Daten im Finanzsektor sowie der Interoperabilität, zu beschleunigen. Darüber hinaus sollen Kunde eine effektivere Kontrolle über den Zugang zu ihren Daten und deren Austausch erhalten. Dieser Vorschlag, der am 23. Juni 2023 von der Europäischen Kommission veröffentlicht wurde, erweitert die datentechnischen Verpflichtungen aus der Open-Banking-Regulierung unter der Payment Service Directive 2 (kurz „PSD2“) auf nahezu alle Finanzdienstleistungsdaten.

Die Verordnung sieht vor, dass Kunden (natürliche und juristische Personen) ihre Daten mit Zustimmung an Dritte (Datennutzer oder auch „Data User“) weitergeben können. Diese Datennutzer können dann auf die Daten bei datenhaltenden Finanzinstituten (Dateninhaber oder auch „Data Holder“) zugreifen. Zu den erfassten Daten gehören gesetzlich vorgegebene Kategorien wie beispielsweise Informationen zu Hypotheken, Krediten, Sparen, Investitionen, Krypto-Assets und Versicherungen. Daten, die nicht in den Anwendungsbereich fallen werden, sind solche zur gesetzlichen Altersvorsorge, zur Kreditwürdigkeitsprüfung von Verbrauchern sowie zu Kranken- und Lebensversicherungen. Zahlungsverkehrsdaten bleiben weiterhin Bestandteil der PSD2 bzw. künftig der PSD3 und PSR. Artikel 2 VO-E listet in Absatz 2 eine ganze Reihe von verpflichteten Dateninhabern auf:  darunter u.a.  Kredit- und Zahlungsinstitute, Wertpapierfirmen und Versicherungsunternehmen, auch Ratingagenturen und Versicherungsvermittler.

Kernpunkte der Verordnung

Es wird, analog der PSD2, eine neue Kategorie von autorisierten Dienstleistern, die ausschließlich als Datennutzer fungieren, eingeführt. Diese sogenannten Financial Information Service Provider („FISP“ oder Deutsch „Finanzinformationsdienstleister“) dürfen Kundendaten bei Dateninhabern abfragen und nutzen, um Finanzinformationsdienste bereitzustellen. Hier ist die Parallele zur PSD2, die nur sogenannten „Zahlungsinstituten“ als Drittdienstleister den Zugang zu Kontoinformationsdaten erlaubt („Kontoinformationsdienstleister“), zu finden.  Es sollen hohe Anforderungen an die Informationssicherheit einschließlich dem Risikomanagement zu erfüllen sein.

Datennutzer können schließlich zugelassene Finanzinstitute, die selbst Dateninhaber sind, und Finanzinformationsdienstleister sein (vgl. Artikel 6 Abs. 1 VO-E). Dateninhaber müssen ein Dashboard bereitstellen, über das Kunden ihre Zustimmung zur Datenweitergabe verwalten und widerrufen können. Dieses Dashboard bietet eine Echtzeitansicht der erteilten Zugriffsberechtigungen. Kunden sind sowohl Verbraucher als auch Unternehmen, die Finanzdienstleistungen in Anspruch nehmen.

Es wird eine verpflichtende Mitgliedschaft für Dateninhaber und Datennutzer in Datenfreigabesystemen (Financial Data Sharing Schemes) vorgeschrieben, um den Datenaustausch zu regeln. Diese Systeme sollen technische Zugangsfragen einschließlich Daten- und Schnittstellenstandards, Haftungsfragen und die Höhe der Kompensationen durch die Mitglieder regeln. Im Gegensatz zur PSD2, wo kontoführende Zahlungsdienstleister Kontoinformationsdaten entgeltlos bereitstellen müssen, wird es mit der FiDA eine Möglichkeit geben, mit der Dateninhaber von Datennutzern ein angemessenes Entgelt verlangen können – dies soll gerade für Dateninhaber einen Anreiz schaffen, dieses Vorhaben zu unterstützen. Das Scheme soll einen Fokus auf Effizienz und auf technische Innovationen zum Finanzdatenaustausch legen.

Die Verordnung wird 24 Monate nach Beschluss durch das EU-Parlament und ihrem Inkrafttreten anwendbar sein. Gemäß einem scheinbar mehrheitsfähigen Diskussionsstand aus dem EU-Trilog-Verfahren (EU-Kommission, EU-Rat und EU-Parlament) von Juni 2025 ist ab dem Inkrafttreten mit einer schrittweisen Umsetzung für die unterschiedlichen Datenkategorien zu rechnen, sodass sich die jeweilige Stufe nach 24 Monaten (z.B. Verbraucherkreditverträge, Kfz-Haftpflichtversicherung), 36 Monaten (z.B. Anlagen in Finanzinstrumente, Altersvorsorgeprodukte) und 48 Monaten (alle übrigen Kundendaten) ab Beschluss entfalten würde. Betroffene Dateninhaber und -nutzer müssen innerhalb von 18, 30 bzw. 42 Monaten nach Inkrafttreten Mitglied im jeweils für sie zutreffenden Financial Data Sharing Schemes werden. Es ist zu erwarten, dass sich je Land und je Branche, z.B. Banken oder Versicherungen mindestens ein Scheme herausbilden wird, weil sowohl die unterschiedlichen Landessprachen, aber auch die teils völlig unterschiedlichen Datenkategorien dies allein schon begünstigen werden.

3 Definition eines Schemes

Was ist eigentlich ein „Scheme“? Bei der Begriffsabgrenzung fängt die Verwirrung bereits an, denn ein Scheme ist keinesfalls zweifelsfrei abgegrenzt. Ein Blick in artverwandte Industrien offenbart Einsichten: Im Zahlungsverkehr betreiben große US-Unternehmen die wohlbekannten Kreditkarten-Schemes wie VISA, Mastercard, American Express und weiteren Wettbewerbern. Neben der offensichtlichen Verwaltung des Standards werden im allgemeinen Gebrauch des Begriffes auch der Betrieb z.B. der Server und der operativen Prozesse, bspw. Dispute (Streitbeilegung) und Chargebacks (Rückerstattungen), damit verbunden. Zudem gibt ein solches Scheme einen Einblick in die Verwaltung der Scheme-Teilnehmer: Die Voraussetzungen zur Teilnahme am Scheme bzw. am Zahlungsverkehr sind für jeden Akteur zweifelsfrei geregelt. So muss sich ein Payment Service Provider (PSP), der Kreditkartenzahlungen über diese Schemes verarbeiten möchte, wie auch die anderen Teilnehmer, klaren Regelungen, wie z.B. der PCI-DSS, unterwerfen.

Mehrere Ähnlichkeitsgrade entfernt, im Automobilbereich gibt es ebenfalls bekannte Beispiele für Schemes: Die „Euro NCAP“ (European New Car Assessment Programme) ist eine Organisation, die Sicherheitsbewertungen für in Europa verkaufte Fahrzeuge erstellt. Das Scheme folgt, gesteuert von der gleichnamigen Organisation, den üblichen Definitionen eines Schemes: Es gibt einen Zweck (die Verbesserung der Fahrzeugsicherheit), eine klare Struktur, Regeln und Regularien, Teilnehmer (wie z.B. die Automobilhersteller), und einen klaren Nutzen für alle Teilnehmer, nämlich weniger Verkehrstote und -verletzte und ein größeres Bewusstsein und Vertrauen der Verbraucher in die Fahrzeugsicherheit. Zudem, und das ist wichtig, verwaltet das Scheme Ressourcen wie Prüfeinrichtungen, technisches Fachwissen und finanzielle Mittel von Mitgliedsorganisationen und Interessenvertretern, zur Durchführung der Bewertungen.

4 FiDA-Anforderungen für Schemes und ihre Akteure

Es ergeben sich aus der FiDA-Verordnung diverse Anforderungen an Schemes bzw. an die Akteure eines Schemes zum Datenaustausch. Einige wollen wir hier näher beleuchten, da sie wahlweise vom Scheme selbst oder seinen Akteuren abgebildet werden können. Die Auswahl zwischen den beiden Optionen wird sinnvollerweise vom Scheme getroffen.

Standards und Dokumentation

Eine der wichtigsten Aufgaben eines Schemes ist die Standardisierung und eindeutige Dokumentation der Schnittstelle(n). Dies umfasst die Harmonisierung der technischen und operativen Anforderungen, um Interoperabilität und Sicherheit zu gewährleisten.

Hierzu zählen neben der Modellierung der Daten und unterstützten Geschäftsvorfälle auch die Regelung der Authentifizierung, der Datenzugriffsrechte und -kontrolle und der zu verwendende Protokolle.

Dashboard

Nutzer sollen die Einsicht in ihre Daten feingranular über Datenschutz-Dashboards steuern können. Dies soll das Vertrauen der Kunden in den Datenaustausch stärken und ihnen ermöglichen, maßgeschneiderte Finanzprodukte und -dienstleistungen zu erhalten. Zudem soll es Transparenz schaffen und Nutzern die Kontrolle über ihre Daten erleichtern.

Dashboards sollen also die Informationen beinhalten und aktiv steuern lassen, wer wem welche Daten für welchen Zeitraum zur Verfügung stellen darf bzw. muss, also z.B.: „Die NeoInsurTech GmbH darf für einen Zeitraum von 7 Tagen auf bestimmte meiner persönlichen sowie alle meiner Vertragsdaten (meines Vertrags mit der Pfefferminzia AG) zugreifen, die von der Pfefferminzia AG gehalten werden“.

Rechte- und Rollenverwaltung

In jedem Scheme wird es mindestens Dateninhaber und Datennutzer geben, zusätzlich spielen Kunden eine Rolle. Aller Wahrscheinlichkeit nach lassen sich weitere Akteure wie nicht-regulierte, hinter den Datennutzern geschaltete Service Provider finden, die wie im PSD2-Ökosystem zwar selbst keine Lizenzhalter sind, aber dennoch ähnlich gelagerte Dienstleistungen zur Verfügung stellen. Diese wickeln erlaubnispflichtige Prozesse über den Lizenzinhaber ab. Das nicht erlaubnispflichtige Geschäft wird allerdings im Normalfall in einer grafischen Schnittstelle (Website oder App) direkt mit dem Kunden abgebildet.

Alle oder die meisten Akteure bzw. Rollen müssen verwaltet werden. Zwar ist davon auszugehen, dass Prozesse bei der Registrierung wie unter der PSD2 nicht manuell bzw. asynchron ablaufen dürfen, also ein Datennutzer sich im Vorfeld über einen ggf. Tage dauernden Prozess bei jedem Dateninhaber registrieren muss, aber auch eine automatische Registrierung z.B. eines FISP muss allein schon aus Abrechnungsgründen von einer handelnden Partei übernommen werden.

Ein Problemfall betrifft die Identifizierung des Endnutzers: Anders als z.B. im Bankenumfeld (Onlinebanking) gibt es in vielen von der FiDA betroffenen Industrien keine eindeutigen Nutzer-Identifikationsnummern oder -zeichenketten. Allein schon aus Gründen der geringeren Alltagsrelevanz werden sich Nutzer z.B. nur in seltenen Fällen im Onlineportal einer Versicherung bewegen, wenn ein solches denn überhaupt angeboten wird. Im Gewerbebereich bzw. im Unternehmenskontext gestaltet sich die Herausforderung vermutlich komplexer. Auch im Bereich von Ratingagenturen werden Kundenlogins eher weniger der gängigen Praxis entsprechen. Aus diesem Grund wird es notwendig sein, unterschiedliche Authentifizierungsmethoden zur Verfügung zu stellen, die dann aber jeweils einem eindeutigen Nutzer zuzuordnen sind. So könnte eine Nutzeridentifikation z.B. aus einem Tupel aus (Vor- und Nach-)Namen, Geburtsdatum und -ort bestehen, möglicherweise gestützt durch Ausweisdokumentennummern, Adressen und Telefonnummern, wobei diese Daten durch die zwar geringe, aber vorhandene, Volatilität für sich genommen zur Identifikation nicht ausreichen dürften.

Server und Betrieb

Theoretisch ist ein dezentraler Datenaustausch technisch kein Problem, in der Praxis wird sich eine zentral betriebene Infrastruktur aber bezahlt machen.

Eine zentrale Infrastruktur stellt sicher, dass bspw. in einem FDSS für die Versicherungsbranche alle teilnehmende Versicherungsunternehmen (Dateninhaber) die gleichen technischen und operativen Anforderungen erfüllen, wodurch die Interoperabilität und Konsistenz im Datenaustausch gewährleistet wird.

Nicht nur macht das eine zentrale Verwaltung von Zugriffsrechten erst möglich, auch werden ein Entziehen sowie die Anpassung der Zugriffsberechtigungen erheblich vereinfacht. Darüber hinaus gibt es prozessuale Vorteile: Die Verfügbarkeit und Qualität der Daten lassen sich einfacher sicherstellen. Die Komplexität der Begleichung von anfallenden Gebühren wird durch Zentralisierung erheblich reduziert (1:n statt n:n-Beziehung). Außerdem lassen sich Meinungsverschiedenheiten (Disputes) durch eine zentrale Stelle leichter beilegen, wenn die Daten revisionssicher über einen einheitlichen, von zentraler Stelle kontrollierten Kanal ausgetauscht wurden.

Der letzte Vorteil betrifft v.a. die Data User, wobei nicht außer Acht gelassen werden sollte, dass wie im PSD2-Umfeld die Data Holder in häufigen Fällen gleichzeitig Data User sein werden: Eine zentrale Infrastruktur anzusprechen vereinfacht die Integration der Schnittstelle erheblich.

Gebührenstruktur: Fee Clearing und Settlement

Die FiDA räumt im aktuellen Verordnungsentwurf und in den aktuellen Diskussionen Dateninhabern das Recht ein, von Datennutzern Nutzungsentgelte zu verlangen. Während das auf dem Papier eine faire Idee zu sein scheint, wird es in der Praxis enorme Herausforderungen im Buchhalterischen wie auch im Geldfluss bereithalten. Im Vorschlag ist die Rede von angemessenen Entgelten auf fixer wie auf „Pay-by-Call“-Basis und sollte sowohl transparent sein als auch die Kosten decken, die für die Bereitstellung der technischen Schnittstelle zum Austausch der angeforderten Daten anfallen.

Die transparente Festlegung der Entgelte wie optional auch das Cashflow-Management und die Registrierung und Deregistrierung der Scheme-Teilnehmer wird dabei in den Verantwortungsbereich des Schemes fallen. Da die Data Holder in häufigen Fällen gleichzeitig Data User sein werden, wird es zweckmäßig sein, die Entgelte in regelmäßigen Zeiträumen, z.B. monatlich, zu „clearen“, also die Ausgleichszahlungen zu berechnen, und möglicherweise auch gleich das „Settlement“, also das Leisten der Ausgleichszahlungen, zu managen und zu überwachen.

Haftung und Streitbeilegung

Wo Parteien interagieren, entstehen irgendwann Konflikte. Diese Konflikte müssen im Zweifelsfall von zentraler, neutraler Stelle gelöst werden. Auch hier hilft ein Blick über den Tellerrand: Die Anbieter der Kreditkarten-Schemes betreiben „dispute management and resolution“, also die Bearbeitung und Lösung von Konflikten beteiligter Scheme-Teilnehmer bzw. ihrer Kunden. Sowohl Haftungsfragen als auch die Prozesse zur Streitbeilegung müssen zweifelsfrei vom Scheme vorgegeben werden.

Weitere Prozesse

Bisher nicht beschriebene Prozesse beinhalten (ohne Anspruch auf Vollständigkeit) die Verwaltung, also auch Aufnahme- und Austrittsprozesse von direkt beteiligten Scheme-Teilnehmern, die Beantwortung von Audit-Fragen, die Weiterentwicklung des Schemes und zugehöriger Standards sowie Sammeln und Reporting von KPIs zu Performance, Sicherheit, Teilnehmern und weiteren Faktoren.

5 Wertschöpfung eines Schemes

Viele der oben genannten Aufgaben, Verantwortungsbereiche und Prozesse könnten wahlweise vom Scheme selbst als oder von den Teilnehmern erfüllt werden. Sogar ein von der FiDA gefordertes Dashboard zur Überwachung und Verwaltung von Zugriffsberechtigungen muss zwar zur Verfügung gestellt werden, dürfen je nach Auslegung der jeweiligen europäischen Aufsichtsbehörde aber ggf. fachlich und / oder technisch auch an das Scheme ausgelagert werden.

Es stellt sich also die Frage, welchen Teil der Wertschöpfung das Scheme selbst abbilden sollte und welche die Scheme-Teilnehmer. Betrachtet man den, wiederum anders als im Bankenumfeld, geringen Verbreitungsgrad von wirklich offenen Schnittstellen und Prozessen in den meisten von der FiDA betroffenen Industrien, ist davon auszugehen, dass ein Großteil der geforderten Prozesse aktuell noch nicht bestehen.

Insofern spielt vermutlich die Kostenbetrachtung eine größere Rolle: Ist es sinnvoll und wirtschaftlich, dass z.B. mehrere hundert Scheme-Teilnehmer eigene Dashboards entwickeln, die dann evtl. erst nach einigen Nachbesserungen den Anforderungen des Regulators entsprechen, oder nutzt man die Skaleneffekte, die eine zentrale Implementierung mit sich bringen würde? Die Beantwortung dieser Frage obliegt letztendlich dem Scheme und seinen Teilnehmern, dürfte aber in den meisten Fällen im Sinne der Wirtschaftlichkeit entschieden werden. Möglicherweise sind die Angebote des Schemes auch optional, es können, um beim oberen Beispiel zu bleiben, z.B. auch eigene Dashboards genutzt werden, oder man geht „auf Nummer sicher“ und setzt auf die Implementierung des übergeordneten Schemes.

6 Blaupause eines FiDA-Schemes

Zur Erläuterung der technischen Wirkungsweise eines Schemes bietet sich das „Four Corners Model“ aus Kartenzahlungen an. Darauf basierend haben wir schließlich die FiDA-Anforderungen in den Kontext der obenstehenden Ausführungen gesetzt, um ein auf ein FDSS adaptiertes Modell herzuleiten.

Zusammenspiel der Akteure

Eine Beispiel-Routine anhand eines Use Cases zur besseren Erläuterung findet sich im nächsten Abschnitt.

Das ermöglicht dem Scheme:

• Die Hoheit über den Standard und die Schnittstelle zu behalten
• Aufsicht über regulatorisch einwandfreie Umsetzung
• Identifizierung, Autorisierung und Authentifizierung zu steuern und die Zugriffsberechtigungen effektiv umzusetzen
• Sich eventuell unterscheidende Versionen des Standards auf eine Version zu normalisieren
• Zugriffszahlen, Settlement und Clearing zu verwalten
• KPIs nach außen und innen zur Verfügung zu stellen
• Erheblich schneller umsetzbare Weiterentwicklungen und Innovationen

Die Scheme-Teilnehmer profitieren ebenfalls:

• Sicherheit der regulatorisch einwandfreien Umsetzung
• Keine Verwaltung der Teilnehmer-Datenbanken notwendig, z.B. eine Liste von URLs, hinter denen die Server der Dateninhaber stehen
• Keine weitere Verifizierung des Kommunikationspartners notwendig (z.B. Prüfen der eIDAS-Zertifikate der Gegenseite)
• Normalisierung des API-Standards erspart auf beiden Seiten Umsetzungskosten
• Erhebliche Aufwandsersparnis bei Clearing und Settlement
• Zentrale Dashboards zur Verwaltung der Zugriffsberechtigungen

Nachteile der zentralen Kommunikation über ein Scheme:

• „Single-Point-of-Failure“, wie z.B. bei Kreditkarten-Schemes und Interbanken-Schemes ebenfalls. Dem wird begegnet durch Redundanz und Ausfallsicherheit sowie Fallbackplänen
• Zentraler Angriffspunkt für eventuelle Cyber-Angriffe

Beispiel-User-Story mit Prozessablauf

Das zuvor illustrierte Scheme lässt sich am besten anhand einer User Story entlang der Prozessschritte weiter veranschaulichen.

Da die Betreiberin der Vergleichswebsite („Service Provider“) keine Lizenz als Financial Information Service Provider (FISP) besitzt, muss sie einen Intermediär nutzen, der über die erforderliche FISP-Lizenz und die entsprechende Abrufinfrastruktur verfügt, um auf die Versicherungsdaten der bestehenden Wohngebäude-Police des Kunden zuzugreifen.

Start:

Kunde veranlasst Datenzugriff

• Der Kunde besucht das Online-Vergleichsportal und klickt auf „Jetzt Angebot einholen“, um alternative Angebote zu einer Wohngebäudeversicherung anzufordern.
• Für die Kalkulation alternativer Angebote und der Gegenüberstellung der Leistungen werden die Tarifdetails und sämtliche Leistungen der bestehenden Police benötigt. Damit diese nicht vom Kunden selbst eingegeben werden müssen und um die aktuellen Versicherungsdaten des Kunden als maschinenlesbaren Datensatz zu erhalten, bittet die Vergleichswebsite ihren technischen Intermediär (d.h. den Data User), den Zugriff auf die Kundendaten für sie zu initiieren und diese zu organisieren.
• In einem Browser-Fenster (in der Sphäre des lizenzierten Data Users) wählt der Kunde seine Versicherungsgesellschaft aus und gibt seine Zugangsdaten ein.

Schritt 1:

Erlaubnis zum Zugriff auf Kundendaten anfordern

• Der Data User sendet über das Scheme eine Anfrage an den Data Holder, dieser wiederum stellt die Anfrage an den Kunden.
• In dieser Anfrage bittet er ihn, den Datenzugriff zu genehmigen.

Schritt 2:

Autorisierung des Datenzugriffs über das Dashboard

• Der Kunde erhält den Antrag auf Datenzugang (technisch) über das Scheme.
• Er kann die Anfrage über ein sogenanntes Finanzdaten-Zugangsberechtigungs-Dashboard annehmen oder ablehnen.
• Außerdem kann er die spezifischen Datenkategorien (z. B. persönliche Daten, Versicherungstarif, Deckung usw.) auswählen, auf die der Data User Zugriff erhalten soll.

Schritt 3:

Bereitstellung der Kundendaten über API

• Sobald der Kunde den Zugriff genehmigt hat, wird ein Consent-Token generiert. Dieser Token dient als Nachweis dafür, dass der Kunde die Erlaubnis erteilt hat.
• Der Datennutzer sendet eine Datenabrufanfrage zusammen mit dem Consent-Token an den Data Holder.
• Der Data Holder sendet die Kundendaten an den Data User zurück. Die Kundendaten müssen zeitnah, kontinuierlich und in Echtzeit zur Verfügung gestellt werden. Außerdem müssen die Daten in einem allgemein akzeptierten Standard (z.B. JSON) geliefert werden.

Schritt 4:

Weiterleitung der Daten an Service Provider

Der Data User leitet die Kundendaten an den Betreiber des Vergleichsportals weiter.

Schritt 5:

Daten nutzen, um Service zu erbringen

• Das Vergleichsportal erhält die Kundendaten vom Data User (dem von ihm beauftragten Intermediär mit der nötigen FISP-Lizenz) und holt anhand dieser Daten Versicherungsangebote von mehreren Versicherungsanbietern ein.
• Wichtig zu beachten ist, dass der Service Provider (in diesem Fall das Vergleichsportal) nicht Teil des FiDA-Schemes ist.
• Das Vergleichsportal bereitet die empfangenen Bestandsdaten im Rahmen einer zur selbstständigen Entscheidungsfindung geeigneten Übersicht auf, sodass der Kunde die für ihn geeignete Versicherung auswählen kann.

Monetarisierung

• Für die Datenabfrage erhält der Data Holder vom Data User ein angemessenes Entgelt, das über das Scheme von allen Teilnehmern zuvor auf einer transparenten Kostenbasis und Maximalvergütung festgelegt wurde.
• Für den Betrieb der Infrastruktur sowie den zentralen Leistungen des Schemes enthält das Schema ebenfalls einen Teil des Entgelts, um die Infrastrukturkosten zu decken.
• Das Clearing und Fee Settlement übernimmt das Scheme als neutrale Instanz zentral, um es für alle Teilnehmer in effizienter, fairer und nachvollziehbarer Weise abzuwickeln.

Dieses Beispiel ist nur eines von unzähligen Use Cases, die durch die künftige Open Finance Welt möglich sein werden. Um im Versicherungskontext zu bleiben, wäre oben genanntes Vergleichsszenario ebenfalls über einen Versicherungsvermittler mittels eines Vergleichsrechners möglich, der auf diese Weise seinen Beratungsaufwand in signifikanter Weise reduzieren könnte.

Dashboard zur Verwaltung von Zugriffsberechtigungen

Der FiDA-Verordnungsentwurf sieht in Artikel 5 Abs. 3 lit. d)  in Verbindung mit Artikel 8 ein Dashboard für die Überwachung und Verwaltung von erteilten Datenzugriffsberechtigungen vor. Der Daten- und Funktionsumfang ist dort ebenfalls spezifiziert. Diese Regelung wurde im Kern aus dem Open Banking, welches für Zahlungskonten eine ähnliche Zugriffskontrolle kennt, übernommen – jedoch ermöglicht es Kunden künftig eine granularere Kontrolle über die freigegebenen Datenkategorien.

Ein Dashboard ist als webbasierte Konsole (grafische Benutzeroberfläche; im IT-Jargon GUI – Graphical User Interface genannt) zu verstehen. Dort sollen Kunden einen Überblick über alle Berechtigungen in Bezug auf den Zweck und die geteilten Daten erhalten und verwalten. Über das Dashboard sind sowohl die Erteilung neuer Berechtigung als auch der Widerruf von Berechtigungen vorgesehen. Widerruft ein Kunde eine Berechtigung, dann sollte der betroffene Datennutzer vom Dateninhaber in Echtzeit über den erfolgten Widerruf unterrichtet werden. Dies lässt sich effizient und sinnigerweise nur über standardisierte Schnittstellen abbilden.

Die nachstehenden Abbildungen illustrieren ein solches Dashboard mit dem künftig vorgeschriebenen Umfang und wie Kunden eine Freigabeanfrage bearbeiten. 

Um also die zwei generellen Use Cases „Berechtigungserteilung“ (Create) und „Berechtigungsverwaltung“ (Read, Update, Delete) gegenüber Kunden zu ermöglichen, sind demnach zwei Einsprung-Konstellationen erforderlich:

1.) Berechtigungserteilung:

Das Dashboard mit der entsprechenden Freigabeanfrage des Datennutzers muss vom Dateninhaber just in dem Moment, in dem der Kunde die Dienstleistung des Datennutzers bzw. Service Providers in Anspruch nehmen möchte, in leicht auffindbarer Weise dem Kunden zugänglich gemacht werden.

Um ein hohe Nutzerfreundlichkeit und damit auch Medienbruchfreiheit sicherzustellen sowie keine Hindernisse oder sonstige Hinderungsgründe zu erzeugen, sollte der Einsprung in das Dashboard direkt vom Datennutzer getriggert werden können, damit der Datennutzer den Kunden auf das Dashboard mit der Freigabeaufforderung nach der Nutzer-Authentifizierung leiten kann. Der Aufruf des Dashboards sollte in diesem Kontext attribuiert sein und ohne Umschweife direkt die initiierte Freigabeanfrage laden.

-> Einsprung aus dem Webangebot des Datennutzers (z.B. durch Redirect)

2.) Berechtigungsverwaltung:

In dieser Konstellation geht es um bereits erteilte Berechtigungen gegenüber Datennutzern. Im Rahmen der Berechtigungsverwaltung und Sicherstellung der Datensouveränität des Kunden müssen diese vier Vorgänge möglich sein:

• Überblick über alle Berechtigungen (Read)
• Erweiterung der Datenkategorien zu einer bestehenden Berechtigung (Update)
• Einschränkung der Datenkategorien zu einer bestehenden Berechtigung (Update)
• Widerruf einer Berechtigung – per sofort oder per definiertem Datum (Delete)

-> Einsprung innerhalb eines geschützten Bereichs des Dateninhabers (z.B. Kundenportal) per Funktionsaufruf

Muss dem inhaltlichen Umfang und den Vorgaben gemäß Artikel 8 dem FiDA-Verordnungsentwurf entsprechen

Muss vom Dateninhaber bereitgestellt werden und für Kunden in einer grafischen Nutzerschnittstelle leicht auffindbar sein, z.B. in einem Online-Portal des Dateninhabers

Muss ein Journal bzw. eine Aufzeichnung über erteilte, abgelaufene oder widerrufene Berechtigungen einschließlich der Datennutzer als Empfänger der Finanzdaten enthalten

Muss einheitlich und diskriminierungsfrei sein und die Gestaltung darf Kunden nicht davon abhalten, Berechtigungen zu erteilen oder dazu ermuntern, diese zu widerrufen

Kunden müssen in der Lage sein, ihre Berechtigungen in informierter und unparteiischer Weise verwalten zu können

Muss barrierefrei für den Kunden sein (s.a. Barrierefreiheitsstärkungsgesetz / European Accessibility Act)

Dashboard – Optionen der Umsetzung

Obwohl es sich beim Dashboard vordergründig zunächst nur um eine Frontend-Lösung handeln mag, muss im Hintergrund technisch deutlich mehr bedacht werden, um eine optimale Verzahnung innerhalb des FDS-Schemes mit den jeweiligen Dateninhabern und Einsprüngen sicherzustellen. Daher sind grundsätzlich die nachfolgenden Umsetzungsüberlegungen vom Scheme anzustellen:

1.) Dezentral:

Jeder Dateninhaber implementiert ein Dashboard vollständig in Eigenregie und nach eigener Interpretation und Fasson.

Vorteile:

• Direkte Einbettung in das Online-Angebot des Dateninhabers wahrt Technologiesouveränität

Nachteile:

• Dadurch könnte ein Wildfuchs unterschiedlicher Aufrufszenarien entstehen, die für Kunden zur Zumutung werden und Datennutzer in unzulässiger Weise benachteiligen (beeinträchtigte Anschlussfähigkeit der Einzellösungen)
• Hoher Umsetzungs- und Testaufwand für alle Scheme-Teilnehmer insbesondere im Hinblick auf Attribuierung und Kompatibilität
• Gefahr, dass Lösungen innerhalb des FDS-Schemes uneinheitlich realisiert werden, da das Dashboard von jedem Scheme-Teilnehmer anders interpretiert wird. Darunter leidet die Nutzerfreundlichkeit und der Umstand kann im äußersten Fall den Regulator zum Eingreifen zwingen

2.) Fachlich zentral, technisch dezentral:

Die Definitionsvorgabe und Spezifikation erfolgt durch das FDS-Scheme. Die Scheme-Teilnehmer setzen das Dashboard gemäß dieser Spezifikation eigenständig auf Basis ihres Technologie-Stacks um.

Vorteile:

• Fachlich werden Interpretationsspielräume ausgeschlossen und die Dashboards erfüllen die Mindestanforderungen
• Die Dateninhaber behalten ihre Technologiesouveränität

Nachteile:

• Da jeder Dateninhaber technisch sein eigenes Dashboard bereitstellt, muss der Funktionsaufruf von jedem Datennutzer implementiert werden, was insgesamt zu hohen Implementierungsaufwänden auf Seiten der Datennutzer führt
• Aufgrund unterschiedlicher Technologie-Stacks, die über das Scheme in Berührung kommen, entsteht für die Scheme-Teilnehmer weiterhin ein hoher Testaufwand

3.) Fachlich und technisch zentral:

Das Scheme definiert, wie das Dashboard für alle Cases auszusehen hat. Außerdem stellt es für alle Scheme-Teilnehmer die technischen Regeln (ggf. einschließlich einem fern-ladbaren Softwarecode) zur Verfügung – d.h. das Scheme hostet das Dashboard. Dies könnte bspw. dadurch realisiert werden, dass das Scheme einen tokenisierten Aufruf-Link (URL) dem Datennutzer zurückspielt, mit dem der Kunde in einem neuen Browser-Fenster (Redirect) auf ein zentrales Dashboard und von dort wieder zurück zur aufrufenden Seite gelangt.

Vorteile:

• Das Dashboard kann effizient und in gleicher Weise, technisch wie fachlich, dem Datennutzer und schlussendlich dem Kunden zugänglich gemacht werden
• Verlässlichkeit insbesondere für Datennutzer und Kunden, weil der Aufruf des Dashboards und der geladene Inhalt gleich ist und Überraschungen reduziert
• Für Datennutzer entstehen geringere Implementierungskosten, da das Aufrufszenario nur in einer Ausprägung und nur einmal realisiert werden muss
• Eine zentrale Bereitstellung des Dashboards könnte eine konsolidierte Übersicht über alle erteilten Berechtigungen – unabhängig vom Dateninhaber – ermöglichen. D.h. das Dashboard generiert sich maßgeblich aus den Berechtigungen, die ein Kunde gegenüber Dateninhabern und Datennutzern innerhalb eines Financial Data Sharing Schemes erteilt hat
• Das FDSS könnte für alle Teilnehmer die Interoperabilität mit anderen Data-Schemes (Branche und EU-Land) sicherstellen

Nachteile:

• Der Dateninhaber könnte sich in seiner Freiheit zu stark eingeschränkt sehen
• Technologie-Kompatibilität ist nicht immer ohne Weiteres gegeben, insbesondere dann, wenn Fremdinhalt im eigenen Angebot geladen werden soll (Hand-over von Tokens und Daten berücksichtigen)
• Höherer Koordinierungsaufwand in der synchronen Abfrage aller Berechtigungen und Zusammenführung der Ergebnisse
• Je nach Umsetzung könnte eine zentrale Datenspeicherung erforderlich sein

Fee Clearing und Settlement

Da der Zugriff auf ein FiDA-Scheme bzw. die Daten eines Kunden zur Deckung der Betriebskosten kostenpflichtig sein darf (vgl. Artikel 10 Abs. 1 lit. h VO-E), müssen die Scheme-Teilnehmer untereinander abgerechnet werden. Dieses Clearing und das darauffolgende Settlement sollte, vom Scheme ausgelöst, periodisch, z.B. monatlich, durchgeführt werden.

Da die Zugriffe gemäß dem hier zugrunde gelegten und erarbeiteten Konzept ohnehin auch technisch über das Scheme selbst erfolgen, ist das zentrale Führen einer revisionssicheren Datenbank relativ geradlinig machbar. Durch das Mappen der Zugriffe auf Tabellen mit den festgelegten Kosten für die einzelnen Zugriffe lässt sich zu jedem Zeitpunkt auch innerhalb der Abrechnungsperiode die Höhe des Vergütungsanspruchs bzw. der aufgelaufenen Kosten errechnen. Diese sollten vom Scheme-Teilnehmer auch jederzeit abrufbar bzw. Kosten auf mit einem Maximalbetrag beschränkbar sein.

Das Clearing erfolgt dann seitens des Schemes z.B. am Monatsanfang bzw. ersten Arbeitstag für den zurückliegenden Monat. Dabei werden die Nettoansprüche errechnet und die angegebenen Konten z.B. durch Lastschriften automatisiert belastet oder in Rechnung gestellt. Nach Ausgleich der Kosten durch die Netto-Zahler werden die Vergütungen den Netto-Empfängern auf das angegebene Konto gutgeschrieben (Settlement-Prozess).

Um stets ein Netto-Guthaben sicherzustellen, ist eine Registriergebühr der Datennutzer als „Pfand“ zielführend. Falls ein Datennutzer in Zahlungsverzug gerät, ist eine (temporäre) Zugriffssperre denkbar und technisch einfach umzusetzen.

Offene Fragen und Themen zur weiteren Vertiefung

Dieser Fachbeitrag beleuchtet nur einen Teilaspekt der FiDA-Regulierung, folglich bleiben Fragen offen, die in zuständigen Projektgruppen beantwortet werden müssen.

• Entwicklung und Festlegung der technischen Standards
• Technische Architektur und Verzahnung der Prozesse (z.B. zwischen Data User und Data Holder)
• Sicherstellung Interoperabilität über Schemes und Ländergrenzen hinweg
• Informationssicherheit und Datenschutz
• Klarheit über den rechtlichen Rahmen
• Regelungen zu Haftung
• Umfang und Kategorien von Daten, die Data User an nicht-lizenzierte Service Provider zur Verarbeitung weitergeben dürfen
• Organisation des Clearings und des Fee Settlements
• Ermittlung und Festlegung der Entgelte für Datenabfragen
• Definition einzuhaltender Verfügbarkeiten technischer Systeme und von Service Levels (Scheme, Data User)

Die Aufzählung ist weder vollständig noch kann sie auf Basis des heutigen Stands (Juli 2024) als abschließend betrachtet werden kann, da zum einen nach der Verabschiedung der Verordnung durch das EU-Parlament technische Regulierungsstandards (RTS) und weitere spezifizierende Guidelines der Aufsichtsbehörden zu erwarten sind.

7 Identifizierung, Authentifizierung und Autorisierung von Kunden

Der Separierbarkeit halber unterscheiden wir hier zwischen Identifizierung, Authentifizierung und Autorisierung der Endnutzer.

Identifizierung

Der Endnutzer muss für alle Scheme-Teilnehmer eindeutig identifizierbar sein. In Ermangelung eines de-facto-Standards zur Identifizierung einer natürlichen Person wie z.B. in den Vereinigten Staaten üblich (Social Security Number) bietet es sich an, auf Datentupel zurückzugreifen, bestehend aus:

• Vor- und Zunamen, Geburtsname
• Geburtsdatum und -ort

In Kombination mit veränderlichen Daten wie

• Adresse
• Telefon-Nummern
• Ausweisnummern

Ein Praxisbeispiel für diese Art von Identifizierung bietet die Umsetzung der OASIS-Datenbank, die Sperreinträge von Glücksspielern enthält: Hier wird Vor- und Nachname, Geburtsname, -datum und -ort sowie die aktuelle Adresse verwendet, um eine Person zweifelsfrei zu identifizieren. Im Nachfolgenden wird eine eindeutige ID vergeben, was sich auch im FiDA-Scheme-Kontext für die nachfolgende Verarbeitung anbietet.

Im Unternehmenskontext muss im Rahmen der Identifizierung auch die juristische Person, für die der Endnutzer als Erfüllungsgehilfe agiert, eindeutig identifiziert werden. Dies kann z.B. mittels Handelsregisternummer oder der Umsatzsteuer-ID erfolgen.

Authentifizierung

Sofern der Nutzer in der Datenbank vorhanden ist, muss er sich für die unterschiedlichen Geschäftsvorfälle authentifizieren, z.B. zum Zugriff auf das Berechtigungs-Dashboard, zum Ändern von Stammdaten oder zur Autorisierung von Dritten.

Da es, anders als z.B. im Bankenumfeld, in den von der FiDA betroffenen Industrien in häufigen Fällen keine Online-Zugangsdaten bzw. Zugriffe auf etwaige interne Bereiche gibt, ist es zielführend, auf das Konzept eines vom Scheme betriebenen „Identity-Brokers“ zu setzen. Dieser vereint unterschiedliche Authentifizierungsmethoden, die dann jeweils zum gewünschten Ergebnis, nämlich dem Authentifizierungs-Token und damit dem eingeloggten Zustand des Nutzers führen.

Zu den im Broker zusammengeführten Identity-Providern könnten zählen:

• Login-Daten bei den einzelnen Dateninhabern (z.B. in das Online-Portal einer Versicherung)
• Online-Personalausweis / AusweisApp
• Regulierte Drittanbieter wie z.B. Banken (Login über Open Banking / Onlinebanking)
• ID-Anbieter wie z.B. IDnow, WebID, verimi
• Nach dem Onboarding- / Erstauthentifizierung ggf. scheme-eigene Lösungen wie biometrische Logins und / oder eigene Nutzername-/Passwort-Tupel

Eine starke Kundenauthentifizierung (Strong Customer Authentication – SCA) wird sinnvollerweise zumindest für unbekannte Geräte oder Umgebungen wie im Zahlungskontext zwingend notwendig sein. Diese umfasst als 2-Faktor-Authentifizierung die Notwendigkeit von mindestens zwei von drei Faktoren aus:

• Wissen: Ein Geheimnis, das nur dem Nutzer bekannt ist, wie beispielsweise ein Passwort.
• Besitz: Ein Gegenstand, den nur der Nutzer besitzt, wie etwa eine Karte oder ein Gerät.
• Inhärenz: Eine einzigartige Eigenschaft des Nutzers, wie ein Fingerabdruck oder andere biometrische Merkmale.

Autorisierung

Ist der Nutzer authentifiziert, ist er selbst autorisiert, seine Datenfreigaben (Autorisierungen) zu lesen, zu bearbeiten und zu löschen (Read, Update, Delete). Die Erstellung einer Datenfreigabe selbst wird immer anlassbezogen und damit im Kontext eines Geschäftsvorfalls vom Datennutzer (Finanzinstitut oder FISP) ausgelöst sein.

8 Identifizierung, Authentifizierung und Autorisierung der Scheme-Teilnehmer (Dateninhaber und Datennutzer)

Identifizierung

Die Scheme-Teilnehmer identifizieren sich dem Scheme gegenüber durch eIDAS-Zertifikate und -Signaturen. Im Zertifikat sind neben Namen und Adresse des Zertifikatsinhabers bzw. Scheme-Teilnehmers auch die Registriernummer(n) hinterlegt. Die Zertifikatskette lässt sich ultimativ auf einen in der EU-Liste aufgeführten offiziellen Trust Service Provider zurückführen (zurzeit z.B. 16 aktuell registrierte in Deutschland) und damit die Gültigkeit verifizieren. Wie in anderen eIDAS-Kontexten auch wird neben der Gültigkeit auch gegen Sperrlisten (Revocation Lists) geprüft. Weitere Prüfungen z.B. gegen Datenbanken der nationalen Regulatoren, können für die Prüfung einer gültigen Erlaubnis zum Passporting (d.h. zum Betreiben des Geschäfts in einem anderen EU-Land als das Land, indem die Erlaubnis erteilt wurde) ggf. sinnvoll sein.

Da im FiDA-Scheme auch Backoffice-Prozesse wie Abrechnung bzw. Settlement eine Rolle spielen, die mehr Daten erfordern als im Zertifikat hinterlegbar sind, ist eine automatisierbare Vorregistrierung eines Scheme-Teilnehmers beim Scheme zielführend, in den Angaben wie z.B. Ansprechpartner und Kontaktdaten zur Konfliktlösung, Logos, Steuernummern sowie Abrechnungsdetails angegeben werden.

Authentifizierung

Die Authentifizierung eines Scheme-Teilnehmers geschieht ebenfalls durch das oben genannte Zertifikat bzw. Signatur einer Anfrage mittels der Zertifikatsinfrastruktur.

Autorisierung

Bei der Autorisierung zum Zugriff auf Nutzerdaten handelt es sich im Prinzip um eine Verknüpfung eines Endnutzers mit dem Scheme-Teilnehmer. Dabei ist in dieser Verknüpfung hinterlegt:

• Umfang der Berechtigung, also auf welche Datenpunkte zugegriffen werden darf
• Zeitdauer bzw. Ablaufzeitstempel der Berechtigung
• Ein Endnutzer, identifiziert mittels ID
• Ein Dateninhaber
• Ein Datennutzer bzw. FISP

Im Kontext der Zahlungsdienste heißt diese Autorisierung „Consent“, also die Zustimmung des Nutzers zum Datenzugriff. Dieser Consent wird neben dem eIDAS-Zertifikat bzw. -Signatur als Referenz auf die Berechtigung in allen zukünftigen Anfragen betreffend diesen Nutzer mitgesendet.

Die Berechtigung kann vom Endnutzer und Datennutzer jederzeit, vom Dateninhaber und vom Scheme aus wichtigen Gründen widerrufen werden, und muss dann mit ggf. anderen Berechtigungen neu erstellt werden. Die Neuerstellung eines Consents „überschreibt“ bzw. invalidiert auch etwaige bisher gültige Consents mit demselben Tupel aus

• Endnutzer
• Dateninhaber
• Datennutzer bzw. Finanzinformationsdienstleister (FISP)

9 Vorbild PSD2: Learnings und Handeln des Regulators

Für eine Vorstellung des Handelns des Regulators lohnt sich ein Blick auf die Historie der PSD2 (Payment Services Directive 2 bzw. 2. Zahlungsdiensterichtlinie): In nahezu jedem Punkt und jedem Konflikt bzw. Fragestellung der Marktteilnehmer hat der Regulator im Sinne eines freien und transparenten Marktes entschieden.

Keine große Überraschung, war ja der Geist der PSD2 gerade der erweiterte Wettbewerb zwischen kontoführendes Zahlungsinstitut / Banken und sogenannten Third Party Providers (TPPs) (Zahlungsdienste und Zahlungsinstitute). Um nur einige Beispiele zu nennen:

• Hindernisse:
  Unzulässige Hindernisse seitens der Banken sind in sehr engem Rahmen definiert, dazu zählen insbesondere eine geringere Performance oder Datentiefe als das kontoführende Zahlungsinstitut selbst anbietet, zusätzliche Schritte in den Redirect-SCA-Verfahren oder fehlende Datenpunkte. Im Grunde: Wenn ein das Zahlungskonto betreffender Datenpunkt oder Geschäftsvorfall von den bankeigenen Schnittstellen angeboten wird, muss er auch in der dedizierten PSD2-Schnittstelle angeboten werden. Es sollte also nicht erwartet werden, dass eine mit nur möglichst wenigen Daten gefüllte Schnittstelle vom Regulator als FiDA-konform akzeptiert wird.
• Vorregistrierung:
  Eine manuelle, ggf. Tage dauernde Registrierung und Freischaltung des TPPs pro Nutzer ist unzulässig, ebenso eine manuelle Registrierung des TPPs generell.
• KPIs:
  Jeder Anbieter von dedizierten Schnittstellen muss öffentlich KPIs (Leistungsstatistiken) zur Verfügung stellen, die Up- und Downtimes, Fehlerraten und Antwortzeiten umfassen.

Aus der PSD2 lassen sich außerdem Lehren ziehen in Bezug auf weitere Nachteile einer dezentral betriebenen Infrastruktur: Es gibt keine zentralen Server oder Schnittstellen, sondern jedes kontoführende Zahlungsinstitut betreibt sein eigenes System aus einer oder mehrerer URLs und zahlreichen in der NextGenPsd2-Schnittstelle der Berlin Group vorgesehenen „Implementer Options“. Zwar gibt es auf der Seite der NISP (NextGenPSD2 Implementation Support Program) ein zentrales, aus unserer Sicht halbwegs gewartetes Verzeichnis von „Sandboxes“, also den Testumgebungen der teilnehmenden Banken, allerdings werden diese Sandboxes unserer Erfahrung nach von den meisten TPPs gemieden, weil sie sich abweichend zur Produktiv-Schnittstelle verhalten. Außerdem sind die Produktiv-Umgebungen nicht aufgelistet. Das Ergebnis ist ein Flickenteppich und erhöhter Wartungsaufwand für die Nutzer der Schnittstelle.

10 Über BANKSapi

Die BANKSapi Technology GmbH wurde 2016 als eigenständiges Unternehmen gegründet und ist ein in Deutschland ansässiges und von der BaFin lizenziertes Zahlungsinstitut sowie ein Open Finance-Softwaredienstleister. Die Technologie von BANKSapi ist seit 2015 im Einsatz und wurde seither stets an den neusten Stand der Technik und den regulatorischen Anforderungen angepasst sowie kontinuierlich um Mehrwertfunktionen erweitert.

BANKSapi entwickelt und betreibt auf ihrer Plattform Kontoinformationsdienste, A2A-Zahlungslösungen und KI-gestützte Datenanalysen für Mehrwertfunktionen. Zudem entwickelt es end-to-end moderne Apps, Portale und Webanwendungen, z.B. als Financial Home aus einem Guss. Das Unternehmen hat frühzeitig im Bereich der Künstlichen Intelligenz eine Kompetenz rund um die Zahlungsstromanalyse aufgebaut, mit der aus Kontoumsätzen bspw. automatisiert Versicherungen oder Risikomerkmale erkannt oder wertvolle Vertriebsimpulse rund um das finanzielle Leben der Kunden generiert werden können. Außerdem sind mithilfe von Open Banking weitere Use Cases rund um Identitätsprüfung (z.B. für initiale Registrierung bei Kundenportalen) oder Bonitätscheck möglich.

Auf der Open Banking Plattform können mit einer singulären Schnittstelle, sogenannte Application Programming Interfaces (API), sämtliche Use Cases vom Kontodatenabruf bis hin zu Online-Überweisungen durchgeführt und Mehrwertdienste auf Basis von Data Analytics in Anspruch genommen werden. Die API abstrahiert für den Implementierer/Entwickler die Komplexität unterschiedlicher Schnittstellenformate und harmonisiert alle Daten in ein einheitliches Format. Somit können hunderte Millionen Zahlungskonten (Giro- und Kontokorrentkonten), Sparkonten, Kreditkarten, Darlehenskonten, Depots, Produkte von Bausparkassen sowie Konten von sonstigen Zahlungsdienstleistern (z.B. PayPal) für B2C und B2B auf einfache Weise angebunden werden.

Zum Kundenkreis gehören beispielsweise namhafte Versicherungskonzerne, Finanzvertriebe oder ERP-System-Hersteller.

Die BANKSapi Technology GmbH ist ein Unternehmen der Finconomy AG und verfügt zusammen mit dieser Unternehmensgruppe mehr als 22 Jahre Erfahrung in der Softwareentwicklung und im Anwendungsbetrieb für die Finanzindustrie. 

11 Die Autoren

Felix Baaken
Co-CEO & Co-Founder

Felix hat nach dem Verkauf seines B2B2C-Loyalty-Unternehmens mit über 250.000 Nutzern einige Jahre bei einem weltweit führenden Finanzdienstleister mit mehreren cross-funktionalen Teams Innovationen entwickelt und erfolgreich an den Markt gebracht. Neben den Produkten im IoT-Bereich fielen darunter Mobile Payment sowie AI-gestützte Datenprodukte.

Manuel Wanner-Behr
Co-CEO

Manuel war als Produktchef Co-Founder eines FinTech & InsurTech-Start-ups. Nach dem erfolgreichen Verkauf des Unternehmens wurde er dessen CEO und wurde später zusätzlich zum CEO eines digitalen Versicherungsanbieters in einem börsennotierten Finanzkonzern berufen. Davor hat der gelernte Bankkaufmann seine Karriere im Produktmanagement einer Spezialbank gestartet.

Beide Autoren haben praktische Gründungserfahrungen sowie Produktentwicklungskompetenz in regulierten Branchen (ZAG, KWG, WPHG etc.) insbesondere im Kontext von FinTech und InsurTech gemeinsam.

Haben Sie Fragen? Dann treten Sie gerne mit uns in Kontakt und lernen Sie uns kennen!