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.
Dieser Artikel zeigt, wie Sie die Journey so operationalisieren, dass aus Datenfreigabe Nutzung wird und aus Nutzung neue, wiederkehrende Erlöse.
Das erwartet Sie in diesem Artikel:
- Was ist FiDA im Detail und warum sollten Banken sich jetzt damit beschäftigen?
- FiDA kurz eingeordnet: Was geregelt wird und was nicht
- Die oft übersehene Hürde: Warum FiDA selten an APIs scheitert
- Referenzmodell „Consent-to-Service“: Der Ablauf, der FiDA produktfähig macht
- Evidence & Audit-Trail: Was Sie nachweisen müssen, damit es prüfbar bleibt
- UX, Mobilität, Verständlichkeit: So erreichen Sie hohe Opt-in-Raten
- Wie aus Datenfreigabe ein Premium-Service wird
- Paperfly im FiDA-Stack: Interaktionsebene statt Datenplattform
- Fazit: So machen Sie FiDA für Ihre Bank profitabel
- FAQ: Die häufigsten Fragen aus Digital, Compliance und Operations
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.
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:
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.
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.
Referenzmodell „Consent-to-Service“: Der Ablauf, der FiDA produktfähig macht
Ein robustes Modell verbindet Aufklärung, Zustimmung, Nachweis, Widerruf und Service-Aktivierung in einem durchgehenden Workflow. Ziel ist nicht „Consent gesammelt“, sondern „Service gestartet“.
Schritt 1: Mehrwert erklären
- Beispiele: Nutzen in nur einem Satz
- Retail-Kredit: „Schnellere Kreditentscheidung, weniger Nachreichungen.“
- Wealth: „Portfolio-Check und Sparpotenziale in Minuten.“
- 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.
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.
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.
Mini-Glossar (FiDA: Consent-to-Service)
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.
