FiDA im Trilog: Warum Permission Management zur Kundenschnittstelle wird

FiDA ist noch kein verabschiedetes Recht. Die Verordnung für den Zugang zu Finanzdaten befindet sich im Trilog zwischen Europäischem Parlament, Rat und Kommission. Deshalb sollten Institute heute weder eine fertige Pflichtenliste behaupten noch das Thema auf einen späteren Rechtsakt vertagen. Der sinnvolle Arbeitsauftrag liegt dazwischen: Ein belastbares Zielbild für Permission Management entwickeln und jede Produktentscheidung sauber als Konzept, Parlamentsposition, Ratsposition oder späteres finales Recht kennzeichnen. Die Kommission legte ihren Vorschlag am 28. Juni 2023 vor; der Rat nahm seine allgemeine Ausrichtung am 4. Dezember 2024 an. Das Parlament beschloss sein Verhandlungsmandat im ECON-Ausschuss am 4. Dezember 2024, die Bestätigung im Plenum folgte am 18. Dezember 2024. Die Verhandlungen laufen weiter. Europäische Kommission: Framework for financial data access Europäisches Parlament: Legislative Train Schedule

Der Kern der Diskussion ist größer als ein weiterer Zustimmungsdialog. Der Kommissionsvorschlag zielt auf einen Rahmen für den sicheren Zugang zu Kundendaten im Finanzsektor über Zahlungskonten hinaus. Die Parlamentsposition bezieht den Zugang auf Daten ein, die Finanzinstitute im gesamten Finanzsektor verarbeiten. Genannt werden dabei unter anderem Daten zu Krediten, Sparen, Investments, Pensionen und Nichtlebensversicherungen; Daten zu Kranken- und Gesundheitsdeckung sollen nach dem Mandat des Parlaments ausgenommen sein. Europäische Kommission: Framework for financial data access Europäisches Parlament: Legislative Train Schedule

Für Banken, Versicherer, Vermögensverwalter und Datennutzer verschiebt sich damit die Designfrage: Nicht nur „Kann eine Schnittstelle Daten bereitstellen?“, sondern „Versteht die Kundin oder der Kunde jederzeit, was mit den eigenen Daten geschieht?“ Ein Permission Dashboard darf daher kein Compliance-Anhang sein. Es muss zur Kundenschnittstelle werden, über die ein Datenzugriff verständlich erklärt, erteilt, beobachtet und beendet werden kann.

Vier Stufen, die nicht vermischt werden dürfen

Ausgangsbasis ist der Kommissionsvorschlag. Er beschreibt die Möglichkeit, aber keine Pflicht der Kundinnen und Kunden, Daten mit Daten­nutzern zu teilen. Zugleich sieht er vor, dass Datenhalter Daten über die erforderliche technische Infrastruktur verfügbar machen, sofern eine Kundenerlaubnis vorliegt. Der Vorschlag spricht außerdem von Kontrolle darüber, wer auf Daten zugreift und zu welchem Zweck, sowie von standardisierten Kundendaten und technischen Schnittstellen. Das ist die Architekturabsicht der Kommission, nicht geltendes FiDA-Recht. Europäische Kommission: Framework for financial data access

Das Mandat des Europäischen Parlaments präzisiert diese Richtung für die interinstitutionellen Verhandlungen. Zugang soll auf der ausdrücklichen Permission der Kundin oder des Kunden beruhen. Daten­nutzende müssten angeben, was sie mit den Daten tun wollen. Eine Weitergabe an Dritte ohne Permission wäre nicht zulässig; die Zustimmung soll jederzeit und kostenlos widerrufen werden können. Darüber hinaus fordert das Mandat vertragliche Haftungsvereinbarungen der Mitglieder von Finanzdatenzugangssystemen und eine Entschädigung der Kundschaft bei Missbrauch, auch bei einer unzulässigen Weitergabe an Dritte. Europäisches Parlament: Legislative Train Schedule

Der Rat unterstützt in seiner allgemeinen Ausrichtung den Grundansatz der Kommission weitgehend, schlägt aber eine schrittweise Umsetzung vor und will Mitgliedstaaten Flexibilität einräumen. Die Ratsposition ist kein finaler Zeitplan. Konkrete endgültige Fristen sollten deshalb weder in Roadmaps noch in Kundeninformationen als feststehend behandelt werden. Europäisches Parlament: Legislative Train Schedule

Erst der im Trilog vereinbarte und anschließend formell angenommene Rechtstext kann die endgültigen Pflichten definieren. Bis dahin müssen Projekte mit Versionen arbeiten: Was stammt aus dem Vorschlag, was aus dem Parlamentsmandat, was aus der Ratsposition und was ist lediglich ein eigenes Betriebs- oder Serviceziel? Diese Kennzeichnung verhindert, dass vorausschauende Produktarbeit als vorweggenommene Rechtsbehauptung erscheint.

Permission ist ein erklärbarer Kundenauftrag

Ein gutes Permission Management übersetzt den Zugriff nicht in juristische Allgemeinplätze, sondern in einen nachvollziehbaren Kundenauftrag. Am Anfang steht ein konkreter Zweck. Wenn eine Kundin Daten für eine Finanzübersicht, einen Vergleich oder eine Beratung freigeben soll, muss dieser Zweck in ihrer Sprache sichtbar sein. Die Parlamentsposition verlangt gerade, dass Daten­nutzende angeben, was sie mit den Daten tun wollen. Daraus folgt für die Gestaltung: Der Zweck gehört nicht in einen langen Datenschutzhinweis, sondern in den Moment der Entscheidung. Europäisches Parlament: Legislative Train Schedule

Ebenso wichtig ist der Datenumfang. „Finanzdaten“ ist für eine Person keine brauchbare Erklärung. Das Dashboard sollte deshalb eindeutig zeigen, welche Datenbereiche für welchen Service angefragt werden. Bei einem Rahmen, der über Zahlungskonten hinausreichen soll, ist diese Einordnung besonders wichtig: Daten zu einem Kredit, einer Geldanlage oder einer Versicherung können unterschiedliche Erwartungen auslösen. Die konkrete Reichweite hängt vom späteren Recht und von der jeweiligen Freigabe ab; das Interface sollte diese Unterschiede nicht verdecken. Europäische Kommission: Framework for financial data access Europäisches Parlament: Legislative Train Schedule

Eine Permission braucht außerdem einen klaren Empfänger. Kundinnen und Kunden sollten sehen, welcher Datenhalter Daten bereitstellt und welcher Datennutzer sie erhalten soll. Falls weitere Parteien eine Rolle spielen, darf daraus keine unsichtbare Kette werden: Das Parlamentsmandat sieht vor, dass Daten nicht ohne Permission an Dritte übertragen werden. Das ist ein starkes Argument für eine Darstellung, die Empfänger nicht nur beim Erstkontakt nennt, sondern später im Statusbereich erneut auffindbar macht. Europäisches Parlament: Legislative Train Schedule

Die notwendige Zeitdimension besteht aus zwei Teilen: der Laufzeit einer aktiven Permission und dem jederzeit möglichen, kostenlosen Widerruf, den das Parlamentsmandat fordert. Ein Interface sollte daher nicht den Eindruck einer endgültigen Einwilligung erzeugen. Es sollte deutlich machen, ob ein Zugang angefragt, aktiv, widerrufen oder beendet ist, und ob eine Aktion aussteht. Diese Statuslogik ist ein Produktprinzip, keine Behauptung über die finale technische Ausgestaltung von FiDA.

Das Dashboard als Servicefläche gestalten

Wer Permission nur als Kontrollnachweis denkt, baut leicht eine Liste von Freigaben, die fachlich korrekt, aber für Kundinnen und Kunden kaum nutzbar ist. Eine Kundenschnittstelle beantwortet im Alltag sechs Fragen: Wofür wird der Zugang genutzt? Welche Daten sind umfasst? Wer erhält sie? Wie lange gilt der Zugriff? Welchen Status hat er? Und wie kann ich ihn beenden? Diese Informationen gehören zusammen, weil sie gemeinsam die Kontrolle über den Datenzugriff vermitteln, die der Vorschlag und das Parlamentsmandat in unterschiedlicher Tiefe vorsehen. Europäische Kommission: Framework for financial data access Europäisches Parlament: Legislative Train Schedule

Auch der Widerruf braucht eine kundenfähige Ausgestaltung. „Widerrufen“ ist kein vollständiger Prozess, wenn danach unklar bleibt, ob der Zugriff beendet wurde, was mit dem angebundenen Service passiert und wo Hilfe erreichbar ist. Das Zielbild sollte deshalb eine Bestätigung, einen sichtbaren Statuswechsel und eine verständliche Serviceinformation vorsehen. Welche Datenaufbewahrung oder Folgeprozesse der finale Rechtsakt verlangen wird, ist offen; die Kommunikation darf den Widerruf dennoch nicht verschleiern.

Standardisierung muss im Kundenerlebnis ankommen

Die Kommission nennt die Standardisierung von Kundendaten und erforderlichen technischen Schnittstellen als Bestandteil des vorgeschlagenen Rahmens. Das ist nicht nur eine Backoffice-Aufgabe. Standards können erst dann ihren Zweck erfüllen, wenn Kundinnen und Kunden über verschiedene Angebote hinweg wiederkehrende Informationen erkennen: Zweck, Datenumfang, Empfänger, Permission-Status und Widerruf sollten nicht jedes Mal völlig anders erklärt werden. Europäische Kommission: Framework for financial data access

Das bedeutet nicht, dass alle Oberflächen gleich aussehen müssen. Es bedeutet, dass dieselben Fragen zuverlässig beantwortet werden. Ein Produktteam kann dazu ein fachliches Permission-Objekt definieren, das für App, Web, Contact Center und Fachbearbeitung dieselben Kernelemente führt. Die Oberfläche bleibt verständlich; die operativen Teams sehen denselben Kontext. Entscheidend ist eine klare Trennung: Dieses Objekt ist ein internes Zielbild, nicht die Behauptung, FiDA schreibe bereits einen konkreten Datenstandard oder ein bestimmtes Dashboard vor.

Die Parlamentsposition enthält zudem den Vorschlag, dass die Europäische Bankenaufsichtsbehörde Register zugelassener Financial Information Service Providers sowie Register von zwischen Datenhaltern und Daten­nutzern vereinbarten Finanzdatenzugangssystemen einrichten soll. Für die spätere Gestaltung kann das Orientierung über Rollen und Zugänge bieten. Solange die Verhandlungen nicht abgeschlossen sind, sollte es jedoch nicht als bereits verfügbare oder abschließend definierte Prüfquelle eingeplant werden. Europäisches Parlament: Legislative Train Schedule

Haftung nicht hinter dem Interface verstecken

Permission Management ist nicht nur eine Frage der Transparenz. Das Parlamentsmandat sieht vertragliche Haftungsregelungen für mögliche Datenschutzverletzungen zwischen den Systemmitgliedern und eine Entschädigung bei Datenmissbrauch vor. Besonders wichtig: Die genannte Entschädigung umfasst auch den Fall einer Datenübertragung an Dritte ohne ausdrückliche Permission. Das ist weiterhin eine Position des Parlaments für den Trilog, keine geltende FiDA-Regel. Europäisches Parlament: Legislative Train Schedule

Für das Betriebsmodell spricht das dafür, Permission-Ereignisse sauber nachvollziehbar zu halten: Wer hat welchen Zugang angefragt? Welcher Zweck und Umfang wurden gezeigt? Wann wurde Permission erteilt, geändert oder widerrufen? Über welchen Kanal lief die Interaktion? Solche Fragen sind keine Rechtsberatung und keine Vorwegnahme künftiger Beweisregeln. Sie helfen jedoch, dass Fachbereich, Datenschutz, Service und Risikofunktionen im Problemfall über denselben Ablauf sprechen.

Die Führungsaufgabe ist damit klar umrissen. Unternehmen sollten heute eine zentrale Permission-Lifecycle-Fähigkeit aufbauen, ohne einen noch nicht verabschiedeten Gesetzestext in verbindliche Kundenversprechen zu übersetzen. Wer Zweck, Datenumfang, Empfänger, Dauer, Widerruf, Status und Service als zusammenhängende Kundenschnittstelle plant, ist für verschiedene Verhandlungsausgänge besser vorbereitet. Und wer jede Anforderung konsequent ihrer Quelle zuordnet, bleibt in der Gegenwart rechtlich sauber.

Illustration: KI-generiert. KI-gestützte Inhalte: Bei der Erstellung unserer Beiträge setzen wir KI-Technologien und automatisierte Agenten ein, unter anderem von Microsoft, Google, OpenAI, Anthropic und weiteren Anbietern. Themen, fachliche Ausrichtung und finale Freigabe liegen bei unserem Team.