Stellen Sie sich vor, Ihre Bank launcht einen neuen Premium-Service: einen Finanz-Check, der Kunden in Minuten zeigt, wo sie sparen, optimieren oder besser investieren können. Die Daten dafür sind vorhanden. Die Produktidee ist sauber. Im Steering ist man sich einig: „Das ist unser nächster Umsatzhebel.“

Und dann beginnt die Realität: Wie erklären wir den Mehrwert so, dass Kunden wirklich zustimmen? Wie holen wir die Einwilligung sicher ein? Und wie führen wir den Kunden nach seiner aktiven Einwilligung (Opt-in) direkt in den Service, im besten Fall bis zur Annahme und Zahlung?

Dafür ist FiDA gedacht. FiDA steht für Financial Data Access, ein EU-Vorschlag für eine Verordnung zum Zugang zu Finanzdaten. FiDA schafft die Datenbasis für Open Finance.

Wert entsteht, wenn Consent, Nachweis und Aktivierung als durchgängige Consent-to-Service-Journey strukturiert sind.

Dieser Artikel zeigt, wie Sie die Journey so operationalisieren, dass aus Datenfreigabe Nutzung wird und aus Nutzung neue, wiederkehrende Erlöse.

Was ist FiDA im Detail und warum sollten Banken sich jetzt damit beschäftigen?

FiDA (Financial Data Access) ist ein EU-Regelwerk für Open Finance, das den kontrollierten Austausch von Finanzdaten auf Basis von Kundeneinwilligungen ermöglichen soll.

Für Banken ist FiDA eine Produkt-Chance: Wer Consent, Nachweis und Aktivierung sauber operationalisiert, kann datenbasierte Services schneller skalieren und daraus neue, wiederkehrende Erlöse entwickeln.

Hinweis: FiDA ist regulatorisch im Aufbau und wird schrittweise konkretisiert. Für Banken lohnt es sich aber auf Dauer, die kundenseitigen Consent-to-Service-Workflows zu standardisieren, weil genau diese Bausteine über die Skalierung entscheiden.

Was bedeutet FiDA konkret für Banken?

FiDA schafft die technische Grundlage zur Datennutzung mit Zustimmung. In der Praxis entscheiden jedoch die Kunden: Wie verständlich ist der Mehrwert, wie einfach ist die Zustimmung, wie revisionssicher ist der Nachweis und wie nahtlos startet danach der Service? Genau diese „Consent-to-Service-Journey“ macht FiDA im Banking produktfähig.

Die Erfolgsfrage lautet nicht „Können wir Daten teilen?“, sondern „Wie bringen wir Kunden sicher, verständlich und mobil durch Zustimmung, Nachweis und Aktivierung: ohne Portalhürden, ohne Medienbrüche, ohne Audit-Lücken?

FiDA kurz eingeordnet: Was geregelt wird und was nicht

FiDA schafft den Rahmen für einen standardisierten, sicheren Datenaustausch, aber liefert noch kein funktionierendes Kundenerlebnis. Für Banken ist deshalb die klare Trennung von Infrastruktur und Interaktion entscheidend:

  • Datenzugang: Die technische Basis, also APIs, Standards, Zugriffsberechtigungen.
  • Kundennutzen: konkrete Ergebnisse für den Kunden, also bessere Konditionen, schnellere Entscheidungen, weniger Dokumentnachreichungen, bessere Finanzübersicht. Wenn der Kunde den Nutzen nicht in ein, zwei Sätzen versteht, sinken Einwilligung und Abschlussquote.

Die oft übersehene Hürde: Warum FiDA selten an APIs scheitert

In der Praxis bremsen nicht Datenmodelle, sondern Reibungspunkte wie unverständliche Einwilligungstexte, zu viele Klicks, ein Portalzwang, fehlende Nachweise und ein komplizierter Widerruf.

Das Ergebnis: Abbrüche, geringe Aktivierung und Audit-Risiken. Wer FiDA erfolgreich umsetzt, behandelt Consent als produktkritischen Ablauf, mit klaren Verantwortlichkeiten, Messpunkten und belastbarer Protokollierung.

Typische Abbruchgründe im Consent-Flow

  • „Ich verstehe nicht, wofür das ist“ = Mehrwert unklar
  • „Texte zu lang / zu juristisch“ = Text-„Overload“
  • „Ich muss mich einloggen, eine App installieren“ = unnötige Hürden
  • „Ich soll Daten freigeben, aber sehe nicht, was ich bekomme“ = fehlende Gegenleistung
  • „den Widerruf finde ich nicht“ = Kontrollverlustgefühl
Je weniger Medienbrüche und je klarer der Evidence-Standard, desto höher die Nutzung.

Ein robustes Modell verbindet Aufklärung, Zustimmung, Nachweis, Widerruf und Service-Aktivierung in einem durchgehenden Workflow. Ziel ist nicht „Consent gesammelt“, sondern „Service gestartet“.

Bei Premium-Services muss der Ablauf zusätzlich Annahme, Vertrag und Zahlung abdecken, ohne den Nutzer aus dem Prozess zu werfen.

Schritt 1: Mehrwert erklären

  • Beispiele: Nutzen in nur einem Satz
  1. Retail-Kredit: „Schnellere Kreditentscheidung, weniger Nachreichungen.“
  2. Wealth: „Portfolio-Check und Sparpotenziale in Minuten.“
  3. SME: „Cashflow-Analyse und Finanzierungsvorschlag.“

Schritt 2: Einwilligung einholen

  • Klare Option „Nur für diesen Zweck“, keine Sammelzustimmung
  • „Umsatzdaten“ getrennt von „Depot“, getrennt von „Krediten“: pro Use Case eine Einwilligung

Schritt 3: Evidence erzeugen

  • Consent erfassen: Zeit, Kanal, Textversion, Auswahl, Authentisierung, Zweck, Empfänger, Datenkategorien
  • Bankintern: Evidence-ID als Referenz, damit Revision später nicht suchen muss

Schritt 4: Service aktivieren

  • Nach dem Consent startet direkt: Analyse, Angebot, Terminbuchung, Entscheidungsvorbereitung
  • Der Kunde merkt sofort Progress, über Status, Ergebnis, nächste Aktion

Optional: Vertrag & Zahlung (Premium)

  • Für Wealth- oder Premium-Checks: Angebot erklären → Annahme → ggf. Signatur → Zahlung

Evidence & Audit-Trail: Was Sie nachweisen müssen, damit es prüfbar bleibt

Revisionssicherheit entsteht bei jedem Schritt: wer zugestimmt hat, wozu, wann, mit welcher Textversion und über welchen Kanal. Außerdem muss nachvollziehbar sein, welche Datenkategorien an welchen Empfänger gehen und wie Widerrufe verarbeitet wurden.

Minimum Viable Audit

Diese Felder müssen Banken für FiDA-Consent mindestens nachweisen

Kategorie Mindestfeld Warum es audit-relevant ist
Identifikation Customer-ID / Person-Referenz (pseudonymisiert möglich) Eindeutige Zuordnung der Zustimmung
Consent-Event Consent-ID (eindeutig) Referenzierbarkeit in Systemen / Workflows
Zeitpunkt Timestamp + Zeitzone Prüfbarkeit der zeitlichen Gültigkeit
Kanal Web / Mobile / Filiale-assistiert / Service-Center-Link Nachvollziehbarkeit des Entstehungskontexts
Zweck Zweck(e) + kurze Beschreibung Zweckbindung („wofür genau?“)
Datenkategorien Ausgewählte Datenkategorien (z. B. Umsätze, Depot, Kredit) Umfang der Freigabe klar abgrenzen
Empfänger / Verwendung Empfänger (Rolle / Organisation / Partner) + Verwendungszweck „Wer nutzt / erhält die Daten wofür?“
Textversion Consent-Textversion (Version / Hash) Beweis, was der Kunde wirklich gesehen hat
Auswahl / Granularität Optionen / Checkboxes + Auswahlzustand Belegt, wozu genau zugestimmt wurde
Identitätsniveau Authentisierungsmethode / Assurance-Level (risikobasiert) Einordnung der Verlässlichkeit des Consent
Gültigkeit Startzeit, ggf. Endzeit / Expiry-Regel Abgrenzung „wann gilt es?“
Statusverlauf aktiv / widerrufen / abgelaufen + Status-Timestamps Lebenszyklus des Consent nachvollziehbar
Widerruf Widerrufskanal + Widerruf-Event-ID Belegt Kontrollmöglichkeit und Umsetzung
Verarbeitungseffekte „Stop / Change“-Event im Workflow (Referenz) Nachweis, dass Widerruf / Status wirkt
Protokollintegrität Audit-Trail-Record-ID / immutable Log-Referenz Manipulationsschutz / Integritätshinweis

Wenn Sie die Textversionierung und den Statusverlauf nicht sauber mitschreiben, wird der Consent im Audit schnell „nicht eindeutig belegbar“.

Paperfly setzt genau hier an: Evidence entsteht „by Design“ im Workflow, nicht als nachträglicher Export.

Wie Paperfly „Evidence by Design“ im Betrieb absichert

Viele FiDA-Initiativen scheitern nicht an der Datenverfügbarkeit, sondern an der Nachweisführung im Alltag: Consent wurde zwar eingeholt, aber Textversionen sind unklar, Statusverläufe fehlen, Widerrufe laufen über Tickets und im Audit beginnt die Rekonstruktion.

Paperfly setzt Evidence direkt in der Journey um: Jede Zustimmung wird als strukturiertes Ereignis erfasst, versioniert und revisionssicher protokolliert, sodass der Nachweis nicht „nachgebaut“ wird, sondern automatisch mitläuft.

Praxisnutzen: Weniger Audit-Rückfragen, weniger manuelle Rekonstruktion und weniger Sonderfälle im Widerruf senken operative Prozesskosten und erhöhen gleichzeitig Opt-in- und Abschlussquoten, weil die Journey stabil durchläuft.

UX, Mobilität, Verständlichkeit: So erreichen Sie hohe Opt-in-Raten

„Was passiert mit meinen Daten?“ in einem Satz: „Wir nutzen ausgewählte Kontodaten ausschließlich, um Ihnen „Service A“ anzubieten; Sie können die Freigabe jederzeit widerrufen.“

Link-first: ohne App- oder Portalzwang

  • Link-first als Standardkanal: Einstieg per SMS, E-Mail oder QR-Code immer in den gleichen Browser-basierten Workflow, ohne Installation, auch für Nichtkunden oder Bevollmächtigte.
  • Minimierte Reibung: kein App-Download, kein Passwort-Reset, keine Registrierungsabbrüche
  • Session-Resilience: Zwischenspeichern, “Später fortsetzen”: keine Datenverluste bei Abbruch oder Wechsel zwischen Handy, Tablet, PC.

Wie aus Datenfreigabe ein Premium-Service wird

FiDA eröffnet Ertragspotenzial, aber nur, wenn der Übergang von „Daten dürfen genutzt werden“ zu „Kunde nutzt und bezahlt Service“ operationalisiert ist. Dazu gehören Angebotserklärung, Annahme, Vertragslogik und bei Bedarf Zahlung in einem Flow.

Drei FiDA-nahe Premium-Use-Cases für Banken

  • Retail: Dokumenten- und Nachweis-Manager als Premium-Service
    Kunden reichen Nachweise (Einkommen, Adresse, Steuer, Familienstand) einmal strukturiert ein und nutzen sie wiederverwendbar für Kredit, Karte, Limit, Depot oder Vollmachten. Der Mehrwert: weniger Rückfragen, schnellere Bearbeitung und ein transparenter Status.
  • Retail: Kredit-Check „Fast Track“ als Premium-Add-on
    Kunden erhalten in wenigen Minuten eine Vorprüfung mit klaren nächsten Schritten (z. B. realistische Rate, notwendige Unterlagen, Zeit bis Entscheidung). Der Premium-Mehrwert: weniger Nachreichungen, schnellere Zusage, priorisierte Bearbeitung, ohne Termin- und Dokumenten-Pingpong.
  • KMU: Cashflow-Insights und Finanzierungsvorschlag
    Liquiditätsmonitoring, Forecast und passende Finanzierungsvorschläge auf Knopfdruck, ohne Excel-Pingpong, mit schnellerer Entscheidungsfähigkeit im Firmenkundengeschäft.

Allen drei Mustern gemeinsam: Ohne eine mobile, verständliche Consent-to-Service-Journey bleiben sie Konzept und skalieren nicht.

Paperfly im FiDA-Stack: Interaktionsebene statt Datenplattform

Paperfly sitzt dort, wo FiDA-Projekte praktisch werden: bei Einwilligung, Formularen, Signatur, Audit-Trail, Routing und Zahlung. Nicht als API- oder Analytics-Layer, sondern als Orchestrierungsschicht für kundennahe Prozesse.

Consent & Formulare

  • Banktaugliche Consent-Seiten, klare Auswahl, erklärende Texte
  • Auch nutzbar in Filiale / Servicecenter als „Assisted Journey“

Signatur und Audit-Trail

  • Signatur integriert im Ablauf
  • Audit-Trail als „Evidence by Design“, nicht als nachträglicher Export

Workflow-Orchestrierung (Routing, Nachforderung, Status)

  • Übergabe an Backoffice ohne E-Mail-Pingpong
  • Status & Nachforderung standardisiert

Payment Collection für Premium-Services

  • Zahlungsanforderung im gleichen Workflow, ohne Medienbruch
  • Inklusive Nachweis: „angenommen, bezahlt, aktiviert“

Fazit: So machen Sie FiDA für Ihre Bank profitabel

FiDA schafft die technische Basis für Open Finance. In der Bankpraxis entsteht Wert aber erst dann, wenn Einwilligung, Nachweis und Aktivierung als durchgängige Consent-to-Service-Journey gebaut sind: verständlich für Kunden, mobil ohne Hürden, revisionssicher dokumentiert und so gestaltet, dass nach dem Opt-in sofort ein Service startet.

Wer FiDA nur als Daten-Projekt behandelt, baut Schnittstellen, aber keine kundenfähige Journey, keine skalierbare Nutzung und erhält keine neuen Erlöse.

FAQ: Die häufigsten Fragen aus Digital, Compliance und Operations

Brauchen wir für FiDA eine App oder reicht ein mobiler Link?

Für hohe Aktivierung im Retail ist ein „Link-first“-Ansatz meist überlegen: weniger Login-Hürden, keine Installation, weniger Abbrüche. Eine App kann ergänzen (z. B. für Bestandskunden-Features), sollte aber nicht Voraussetzung sein, wenn Consent und Service-Start schnell und breit skaliert werden sollen.

Wie granular sollte die Einwilligung im FiDA-Use-Case sein?

So granular wie der Use Case es erfordert: typischerweise getrennt nach Zweck und Datenkategorien. Zu grob wirkt intransparent und senkt Vertrauen, zu kleinteilig erhöht Abbrüche. Ziel ist eine kontrollierbare Zustimmung mit wenigen, klaren Optionen.

Wie wird ein Widerruf in FiDA-Prozessen sauber operationalisiert?

Widerruf muss als produktiver Standardprozess funktionieren: leicht auffindbar, in wenigen Schritten ausführbar und systemisch wirksam. Das heißt: Consent-Status wechselt, Workflows stoppen oder passen sich an, und alle Ereignisse werden protokolliert. „Widerruf per Support-Ticket“ skaliert schlecht und erzeugt Audit- und Betriebslasten.

Welche Evidence-Felder braucht man als „Minimum Viable Audit“?

Mindestens müssen Banken nachweisen können: wer zugestimmt hat, wann, wozu, welche Datenkategorien, an wen und wofür (Empfänger, Rolle), mit welcher Textversion, wie authentisiert, sowie Statusverlauf inkl. Widerruf. Ohne Textversionierung wird der Nachweis angreifbar, weil später nicht eindeutig belegbar ist, was der Kunde tatsächlich gesehen hat.

Versionierung = jede Änderung an Texten, Zwecken, Optionen erzeugt eine neue Version, die im Nachweis referenziert wird.

Zweckbindung: Daten dürfen nur für den konkret beschriebenen Zweck verwendet werden (z. B. „Finanzcheck“ oder „Kreditvorprüfung“), nicht pauschal für weitere, nicht genannte Ziele.

Consent: dokumentierte Einwilligung des Kunden zu klar beschriebenen Datenverwendungen.

Consent-to-Service-Journey: Durchgängiger Prozess von Mehrwert-Erklärung über Einwilligung und Evidence bis zur Service-Aktivierung (optional inkl. Vertrag, Signatur, Zahlung), ohne Portalhürden und Medienbrüche.

Datenkategorien: welche Datentypen betroffen sind, z. B. Konto-Umsätze, Kredite, Depots.

Empfänger: wer Daten erhält bzw. wer sie nutzen darf, etwa Bank-internes Produkt, Partner, Drittanbieter.

Widerruf: Mechanismus, mit dem der Kunde seine Zustimmung einfach zurücknehmen kann.

Audit-Trail / Evidence: prüfbarer Nachweis: wer hat wann wozu wie zugestimmt, inklusive Textversion, Kanal, Identität, Events.

Identitätsniveau: wie stark die Authentisierung abgesichert ist, z. B. eingeloggter Bankkunde vs. externer Nutzer mit Ident-Check.