Insight

Vertrauende Partei werden: Die Anbindung an die EUDI-Wallet

Wer Daten aus der EUDI-Wallet abfragen will, registriert sich mit Zweck. Wie Banken Zweckregister, Pseudonyme und Betriebsfälle vor der Anbindung klären.

Kunde und Betreuung

6 min Lesezeit

Kernaussage

Der Zugang zur Wallet beginnt mit der Frage, welche Daten ein Prozess wirklich braucht. Wer Zwecke sauber festlegt, erfüllt die Registrierungspflicht nebenbei und entrümpelt jahrzehntealte Formulare.

Titelbild zum Beitrag „Vertrauende Partei werden: Die Anbindung an die EUDI-Wallet“

Die wichtigsten Erkenntnisse

Registrierung und Zweckbindung kommen vor der Technik

Jede Abfrage ohne benennbaren Zweck entfällt

Betriebsfälle entscheiden über Alltagstauglichkeit

Wer Wallet-Daten will, muss sich zuerst selbst ausweisen

Die meisten Institute denken bei der EUDI-Wallet an ihre Kunden. Der erste Schritt betrifft aber das Institut selbst: Wer Daten aus der Wallet abfragen will, registriert sich als vertrauende Partei in seinem Mitgliedstaat, legt dabei für jede Verwendung offen, welche Daten er anfordert, und darf danach nichts anderes verlangen. Die eigentliche Arbeit ist deshalb fachlich, nicht technisch: festzulegen, welche Daten jeder Prozess wirklich braucht.

Die Registrierung ist keine Formalie, sie ist das Rückgrat des Vertrauensmodells. Kunden sehen in ihrer Wallet, wer welche Daten wofür anfragt, und geben gezielt frei.

Was bedeutet „vertrauende Partei“?

Vertrauende Partei, in der Verordnung „vertrauender Beteiligter“, ist der eIDAS-Begriff für jede Organisation, die sich auf die Wallet verlässt, also Identitätsdaten oder Bescheinigungen abfragt. Artikel 5b der Verordnung (EU) 2024/1183 knüpft daran klare Pflichten. Die vertrauende Partei registriert sich in dem Mitgliedstaat, in dem sie niedergelassen ist, und gibt dabei mindestens an, wer sie ist, wie sie erreichbar ist und welche Daten sie für welche beabsichtigte Verwendung anfordern muss. Andere Daten darf sie von Nutzern nicht verlangen.

Die Mitgliedstaaten machen diese Angaben öffentlich und maschinenlesbar zugänglich, und die vertrauende Partei muss sich gegenüber dem Nutzer identifizieren. Für ein Institut heißt das: Die Frage, welche Daten es in welchen Prozessen abfragt, wird künftig nach außen sichtbar beantwortet. Diese neue Transparenz belohnt Institute, deren Datenpraxis einer Sichtprüfung standhält.

Die nationale Ausgestaltung der Registrierung soll nach einem Überblick der Kanzlei Heuking vom Oktober 2026 das Digitale Identitätengesetz regeln, das sich zu diesem Zeitpunkt noch im parlamentarischen Verfahren befand.

Wie läuft die Anbindung im Verbund?

Für Sparkassen und Genossenschaftsbanken liegt nahe, dass die produktive Anbindung über die Verbund-IT läuft, über Finanz Informatik oder Atruvia. Die Verordnung regelt diesen Fall in Artikel 5b Absatz 10: Vermittler, die im Namen vertrauender Beteiligter handeln, gelten selbst als vertrauende Beteiligte und dürfen keine Daten über den Inhalt der Transaktion speichern. Die Zweckfestlegung je Prozess bleibt trotzdem Aufgabe des Instituts, denn nur das Institut weiß, wofür es eine Angabe braucht.

Praxiserfahrung lässt sich früh sammeln. Bundesdigitalministerium und SPRIND haben laut netzpolitik.org im Januar 2026 eine Testumgebung geöffnet, in der Behörden und Unternehmen geplante Anwendungen erproben können, nach vorheriger Registrierung als vertrauende Partei. Ein Nachmittag mit zwei Prozessverantwortlichen in einer solchen Umgebung erzeugt oft mehr belastbare Erkenntnis als mehrere Konzeptrunden, und wer die Abläufe gesehen hat, formuliert präzisere Anforderungen an den Verbund.

Wie wird der Zweck je Prozess festgelegt?

Technisch ist die Abfrage ein gelöstes Problem, die anspruchsvolle Arbeit ist fachlich. Für jeden Prozess legt das Institut fest, welche Daten er wirklich braucht. Die Kontoeröffnung braucht den Identitätsdatensatz. Ein Altersnachweis braucht nicht das Geburtsdatum, sondern die Bestätigung der Volljährigkeit; die Verordnung verlangt dafür in Artikel 5a, dass die Wallet selektiv offengelegte Daten unterstützt. Die Adressänderung braucht die Adresse, nicht die ganze Identität.

Bewährt ist die kleine Runde je Strecke: Prozessverantwortung, Datenschutz und Marktfolge, eine Stunde pro Prozess, Ergebnis ist eine Zeile im Zweckregister. Die Gegenprobe gehört dazu: Jede Datenabfrage, für die sich kein Zweck benennen lässt, entfällt. Nebenbei werden Formulare entrümpelt, die über Jahrzehnte gewachsen sind. Wie dieselbe Logik in Versicherungsanträgen wirkt, zeigt der Beitrag zu Attributen statt Aktenkopien.

Prozesskette: 1. Zwecke je Prozess festlegen (nur Daten mit Rechtsgrundlage); 2. Registrieren (Identität, Kontakt, Daten je Verwendung); 3. In der Testumgebung erproben (Abläufe sehen, Anforderungen schärfen); 4. Betriebsfälle klären (Abbruch, Verlust, Kernsystem, Service); 5. Pilot, dann Rollout (Strecke mit der höchsten Abbruchquote). Darstellung: Sotica auf Basis VO (EU) 2024/1183, Art. 5b

Welche Rolle spielen Pseudonyme?

Eine Regel wird in Bankprojekten gern überlesen. Nach Artikel 5b Absatz 9 dürfen vertrauende Beteiligte die Verwendung von Pseudonymen nicht verweigern, wenn die Identifizierung des Nutzers nicht durch Unionsrecht oder nationales Recht vorgeschrieben ist. Für kontoführende Prozesse ist das unerheblich, dort verlangt das Geldwäscherecht die volle Identität. Am Rand des Angebots gibt es aber die anderen Fälle: Newsletter, Veranstaltungsportal, Finanzrechner mit Merkfunktion, Kundenfeedback.

Die saubere Lösung ist eine Zwei-Klassen-Logik: volle Identität nur, wo das Gesetz sie trägt, Pseudonym überall sonst, und die Grenze dokumentiert. Pseudonyme gehören nach einer Übersicht von Namirial vom August 2026 allerdings nicht zum Startumfang der deutschen Wallet, sie folgen nach dem Start.

Welche Betriebsfragen müssen vor dem Start beantwortet sein?

Vier Fälle entscheiden über die Alltagstauglichkeit. Bricht der Kunde die Freigabe ab, braucht die Strecke einen sauberen Rücksprung statt einer Fehlermeldung. Bei Wallet-Verlust oder Gerätewechsel müssen Service und Sperrprozesse den Fall kennen. Im Kernsystem müssen Wallet-Identifizierungen dieselben Merkmale setzen wie Altverfahren, vom Legitimationskennzeichen bis zum Prüfdatum, damit nachgelagerte Prozesse keinen Unterschied sehen. Und das Servicecenter braucht das Wissen vor dem ersten Anruf, nicht danach.

Ein kurzer Testkatalog über die häufigsten Folgeprozesse, von der Kartenbestellung bis zur Vollmachtserteilung, deckt Stolperstellen vor dem Livegang auf. Ändern sich später Zwecke oder Datenumfang, muss die vertrauende Partei das nach Artikel 5b Absatz 6 unverzüglich melden; das Zweckregister gehört deshalb in die laufende Pflege, nicht ins Projektarchiv.

In welcher Reihenfolge führt der Weg zur Annahmepflicht?

Die Reihenfolge ergibt sich rückwärts vom Stichtag. Die Annahmepflicht für Banken greift nach dem Heuking-Überblick ab Ende Dezember 2027, die deutsche Wallet d-you soll laut Bundesdigitalministerium am 2. Januar 2027 starten. Davor liegen Prozess- und Zweckinventur sowie erste Testerfahrung, ab dem Start ein Pilot auf einer echten Strecke mit messbarem Schmerz, bevorzugt der Legitimationsprozess mit der höchsten Abbruchquote, danach der Rollout mit dem Pilot als Vorlage. Den größeren Rahmen beschreibt der EUDI-Wallet-Fahrplan für Sparkassen, die Verteilung der Verantwortung im Institut der Beitrag zur Wallet-Zuständigkeit in der Bank.

Was das Management jetzt anstoßen sollte

  1. Eine Zweckinventur beauftragen: je Prozess die benötigten Daten mit Rechtsgrundlage, beginnend mit den volumenstärksten Strecken.

  2. Die Pseudonym-Grenze festlegen: volle Identität nur dort, wo das Gesetz sie verlangt.

  3. Testerfahrung sammeln: zwei Prozessverantwortliche in die Testumgebung schicken, bevor Anforderungen an den Verbund gehen.

  4. Die Betriebsfälle klären: Abbruch, Wallet-Verlust, Ablage im Kernsystem und Servicewissen.

  5. Einen Pilot auswählen: die Legitimationsstrecke mit der höchsten Abbruchquote, mit Kennzahlen davor und danach.

Häufige Fragen

Muss sich jedes Institut selbst registrieren, wenn der Verbund die Anbindung baut?
Der Dienstleister, der im Namen des Instituts handelt, gilt nach Artikel 5b Absatz 10 selbst als vertrauender Beteiligter. Wie Registrierung und Zwecke zwischen Verbund und Institut aufgeteilt werden, regelt die nationale Umsetzung; die fachliche Zweckfestlegung bleibt in jedem Fall beim Institut.

Darf das Institut mit Zustimmung des Kunden mehr Daten abfragen als registriert?
Nein. Nach Artikel 5b Absatz 3 dürfen vertrauende Beteiligte keine anderen Daten verlangen als die bei der Registrierung angegebenen.

Was passiert, wenn sich ein Prozess später ändert?
Änderungen an den registrierten Angaben sind unverzüglich zu melden. Ein gepflegtes Zweckregister macht das zu einer Routineaufgabe.

Weitere Beiträge zu Zeitplan, Pflichten und Einsatzfällen bündelt das Dossier EUDI-Wallet & digitale Identität.

Wie viele Felder in den eigenen Formularen eine Zweckprüfung überstehen würden, ist oft die ehrlichste Kennzahl für die Datenpraxis eines Instituts. Gern sprechen wir in einem ersten Gespräch darüber.

Sotica Insights

Redaktion · Beiträge aus der Beratungspraxis

Ein Thema, das gerade beschäftigt?

Gemeinsam einordnen, was daraus folgt.

Titelbild zum Beitrag „Vertrauende Partei werden: Die Anbindung an die EUDI-Wallet“

Die wichtigsten Erkenntnisse

Registrierung und Zweckbindung kommen vor der Technik

Jede Abfrage ohne benennbaren Zweck entfällt

Betriebsfälle entscheiden über Alltagstauglichkeit

Wer Wallet-Daten will, muss sich zuerst selbst ausweisen

Die meisten Institute denken bei der EUDI-Wallet an ihre Kunden. Der erste Schritt betrifft aber das Institut selbst: Wer Daten aus der Wallet abfragen will, registriert sich als vertrauende Partei in seinem Mitgliedstaat, legt dabei für jede Verwendung offen, welche Daten er anfordert, und darf danach nichts anderes verlangen. Die eigentliche Arbeit ist deshalb fachlich, nicht technisch: festzulegen, welche Daten jeder Prozess wirklich braucht.

Die Registrierung ist keine Formalie, sie ist das Rückgrat des Vertrauensmodells. Kunden sehen in ihrer Wallet, wer welche Daten wofür anfragt, und geben gezielt frei.

Was bedeutet „vertrauende Partei“?

Vertrauende Partei, in der Verordnung „vertrauender Beteiligter“, ist der eIDAS-Begriff für jede Organisation, die sich auf die Wallet verlässt, also Identitätsdaten oder Bescheinigungen abfragt. Artikel 5b der Verordnung (EU) 2024/1183 knüpft daran klare Pflichten. Die vertrauende Partei registriert sich in dem Mitgliedstaat, in dem sie niedergelassen ist, und gibt dabei mindestens an, wer sie ist, wie sie erreichbar ist und welche Daten sie für welche beabsichtigte Verwendung anfordern muss. Andere Daten darf sie von Nutzern nicht verlangen.

Die Mitgliedstaaten machen diese Angaben öffentlich und maschinenlesbar zugänglich, und die vertrauende Partei muss sich gegenüber dem Nutzer identifizieren. Für ein Institut heißt das: Die Frage, welche Daten es in welchen Prozessen abfragt, wird künftig nach außen sichtbar beantwortet. Diese neue Transparenz belohnt Institute, deren Datenpraxis einer Sichtprüfung standhält.

Die nationale Ausgestaltung der Registrierung soll nach einem Überblick der Kanzlei Heuking vom Oktober 2026 das Digitale Identitätengesetz regeln, das sich zu diesem Zeitpunkt noch im parlamentarischen Verfahren befand.

Wie läuft die Anbindung im Verbund?

Für Sparkassen und Genossenschaftsbanken liegt nahe, dass die produktive Anbindung über die Verbund-IT läuft, über Finanz Informatik oder Atruvia. Die Verordnung regelt diesen Fall in Artikel 5b Absatz 10: Vermittler, die im Namen vertrauender Beteiligter handeln, gelten selbst als vertrauende Beteiligte und dürfen keine Daten über den Inhalt der Transaktion speichern. Die Zweckfestlegung je Prozess bleibt trotzdem Aufgabe des Instituts, denn nur das Institut weiß, wofür es eine Angabe braucht.

Praxiserfahrung lässt sich früh sammeln. Bundesdigitalministerium und SPRIND haben laut netzpolitik.org im Januar 2026 eine Testumgebung geöffnet, in der Behörden und Unternehmen geplante Anwendungen erproben können, nach vorheriger Registrierung als vertrauende Partei. Ein Nachmittag mit zwei Prozessverantwortlichen in einer solchen Umgebung erzeugt oft mehr belastbare Erkenntnis als mehrere Konzeptrunden, und wer die Abläufe gesehen hat, formuliert präzisere Anforderungen an den Verbund.

Wie wird der Zweck je Prozess festgelegt?

Technisch ist die Abfrage ein gelöstes Problem, die anspruchsvolle Arbeit ist fachlich. Für jeden Prozess legt das Institut fest, welche Daten er wirklich braucht. Die Kontoeröffnung braucht den Identitätsdatensatz. Ein Altersnachweis braucht nicht das Geburtsdatum, sondern die Bestätigung der Volljährigkeit; die Verordnung verlangt dafür in Artikel 5a, dass die Wallet selektiv offengelegte Daten unterstützt. Die Adressänderung braucht die Adresse, nicht die ganze Identität.

Bewährt ist die kleine Runde je Strecke: Prozessverantwortung, Datenschutz und Marktfolge, eine Stunde pro Prozess, Ergebnis ist eine Zeile im Zweckregister. Die Gegenprobe gehört dazu: Jede Datenabfrage, für die sich kein Zweck benennen lässt, entfällt. Nebenbei werden Formulare entrümpelt, die über Jahrzehnte gewachsen sind. Wie dieselbe Logik in Versicherungsanträgen wirkt, zeigt der Beitrag zu Attributen statt Aktenkopien.

Prozesskette: 1. Zwecke je Prozess festlegen (nur Daten mit Rechtsgrundlage); 2. Registrieren (Identität, Kontakt, Daten je Verwendung); 3. In der Testumgebung erproben (Abläufe sehen, Anforderungen schärfen); 4. Betriebsfälle klären (Abbruch, Verlust, Kernsystem, Service); 5. Pilot, dann Rollout (Strecke mit der höchsten Abbruchquote). Darstellung: Sotica auf Basis VO (EU) 2024/1183, Art. 5b

Welche Rolle spielen Pseudonyme?

Eine Regel wird in Bankprojekten gern überlesen. Nach Artikel 5b Absatz 9 dürfen vertrauende Beteiligte die Verwendung von Pseudonymen nicht verweigern, wenn die Identifizierung des Nutzers nicht durch Unionsrecht oder nationales Recht vorgeschrieben ist. Für kontoführende Prozesse ist das unerheblich, dort verlangt das Geldwäscherecht die volle Identität. Am Rand des Angebots gibt es aber die anderen Fälle: Newsletter, Veranstaltungsportal, Finanzrechner mit Merkfunktion, Kundenfeedback.

Die saubere Lösung ist eine Zwei-Klassen-Logik: volle Identität nur, wo das Gesetz sie trägt, Pseudonym überall sonst, und die Grenze dokumentiert. Pseudonyme gehören nach einer Übersicht von Namirial vom August 2026 allerdings nicht zum Startumfang der deutschen Wallet, sie folgen nach dem Start.

Welche Betriebsfragen müssen vor dem Start beantwortet sein?

Vier Fälle entscheiden über die Alltagstauglichkeit. Bricht der Kunde die Freigabe ab, braucht die Strecke einen sauberen Rücksprung statt einer Fehlermeldung. Bei Wallet-Verlust oder Gerätewechsel müssen Service und Sperrprozesse den Fall kennen. Im Kernsystem müssen Wallet-Identifizierungen dieselben Merkmale setzen wie Altverfahren, vom Legitimationskennzeichen bis zum Prüfdatum, damit nachgelagerte Prozesse keinen Unterschied sehen. Und das Servicecenter braucht das Wissen vor dem ersten Anruf, nicht danach.

Ein kurzer Testkatalog über die häufigsten Folgeprozesse, von der Kartenbestellung bis zur Vollmachtserteilung, deckt Stolperstellen vor dem Livegang auf. Ändern sich später Zwecke oder Datenumfang, muss die vertrauende Partei das nach Artikel 5b Absatz 6 unverzüglich melden; das Zweckregister gehört deshalb in die laufende Pflege, nicht ins Projektarchiv.

In welcher Reihenfolge führt der Weg zur Annahmepflicht?

Die Reihenfolge ergibt sich rückwärts vom Stichtag. Die Annahmepflicht für Banken greift nach dem Heuking-Überblick ab Ende Dezember 2027, die deutsche Wallet d-you soll laut Bundesdigitalministerium am 2. Januar 2027 starten. Davor liegen Prozess- und Zweckinventur sowie erste Testerfahrung, ab dem Start ein Pilot auf einer echten Strecke mit messbarem Schmerz, bevorzugt der Legitimationsprozess mit der höchsten Abbruchquote, danach der Rollout mit dem Pilot als Vorlage. Den größeren Rahmen beschreibt der EUDI-Wallet-Fahrplan für Sparkassen, die Verteilung der Verantwortung im Institut der Beitrag zur Wallet-Zuständigkeit in der Bank.

Was das Management jetzt anstoßen sollte

  1. Eine Zweckinventur beauftragen: je Prozess die benötigten Daten mit Rechtsgrundlage, beginnend mit den volumenstärksten Strecken.

  2. Die Pseudonym-Grenze festlegen: volle Identität nur dort, wo das Gesetz sie verlangt.

  3. Testerfahrung sammeln: zwei Prozessverantwortliche in die Testumgebung schicken, bevor Anforderungen an den Verbund gehen.

  4. Die Betriebsfälle klären: Abbruch, Wallet-Verlust, Ablage im Kernsystem und Servicewissen.

  5. Einen Pilot auswählen: die Legitimationsstrecke mit der höchsten Abbruchquote, mit Kennzahlen davor und danach.

Häufige Fragen

Muss sich jedes Institut selbst registrieren, wenn der Verbund die Anbindung baut?
Der Dienstleister, der im Namen des Instituts handelt, gilt nach Artikel 5b Absatz 10 selbst als vertrauender Beteiligter. Wie Registrierung und Zwecke zwischen Verbund und Institut aufgeteilt werden, regelt die nationale Umsetzung; die fachliche Zweckfestlegung bleibt in jedem Fall beim Institut.

Darf das Institut mit Zustimmung des Kunden mehr Daten abfragen als registriert?
Nein. Nach Artikel 5b Absatz 3 dürfen vertrauende Beteiligte keine anderen Daten verlangen als die bei der Registrierung angegebenen.

Was passiert, wenn sich ein Prozess später ändert?
Änderungen an den registrierten Angaben sind unverzüglich zu melden. Ein gepflegtes Zweckregister macht das zu einer Routineaufgabe.

Weitere Beiträge zu Zeitplan, Pflichten und Einsatzfällen bündelt das Dossier EUDI-Wallet & digitale Identität.

Wie viele Felder in den eigenen Formularen eine Zweckprüfung überstehen würden, ist oft die ehrlichste Kennzahl für die Datenpraxis eines Instituts. Gern sprechen wir in einem ersten Gespräch darüber.

Sotica Insights

Redaktion · Beiträge aus der Beratungspraxis

Ein Thema, das gerade beschäftigt?

Gemeinsam einordnen, was daraus folgt.

Titelbild zum Beitrag „Vertrauende Partei werden: Die Anbindung an die EUDI-Wallet“

Die wichtigsten Erkenntnisse

Registrierung und Zweckbindung kommen vor der Technik

Jede Abfrage ohne benennbaren Zweck entfällt

Betriebsfälle entscheiden über Alltagstauglichkeit

Wer Wallet-Daten will, muss sich zuerst selbst ausweisen

Die meisten Institute denken bei der EUDI-Wallet an ihre Kunden. Der erste Schritt betrifft aber das Institut selbst: Wer Daten aus der Wallet abfragen will, registriert sich als vertrauende Partei in seinem Mitgliedstaat, legt dabei für jede Verwendung offen, welche Daten er anfordert, und darf danach nichts anderes verlangen. Die eigentliche Arbeit ist deshalb fachlich, nicht technisch: festzulegen, welche Daten jeder Prozess wirklich braucht.

Die Registrierung ist keine Formalie, sie ist das Rückgrat des Vertrauensmodells. Kunden sehen in ihrer Wallet, wer welche Daten wofür anfragt, und geben gezielt frei.

Was bedeutet „vertrauende Partei“?

Vertrauende Partei, in der Verordnung „vertrauender Beteiligter“, ist der eIDAS-Begriff für jede Organisation, die sich auf die Wallet verlässt, also Identitätsdaten oder Bescheinigungen abfragt. Artikel 5b der Verordnung (EU) 2024/1183 knüpft daran klare Pflichten. Die vertrauende Partei registriert sich in dem Mitgliedstaat, in dem sie niedergelassen ist, und gibt dabei mindestens an, wer sie ist, wie sie erreichbar ist und welche Daten sie für welche beabsichtigte Verwendung anfordern muss. Andere Daten darf sie von Nutzern nicht verlangen.

Die Mitgliedstaaten machen diese Angaben öffentlich und maschinenlesbar zugänglich, und die vertrauende Partei muss sich gegenüber dem Nutzer identifizieren. Für ein Institut heißt das: Die Frage, welche Daten es in welchen Prozessen abfragt, wird künftig nach außen sichtbar beantwortet. Diese neue Transparenz belohnt Institute, deren Datenpraxis einer Sichtprüfung standhält.

Die nationale Ausgestaltung der Registrierung soll nach einem Überblick der Kanzlei Heuking vom Oktober 2026 das Digitale Identitätengesetz regeln, das sich zu diesem Zeitpunkt noch im parlamentarischen Verfahren befand.

Wie läuft die Anbindung im Verbund?

Für Sparkassen und Genossenschaftsbanken liegt nahe, dass die produktive Anbindung über die Verbund-IT läuft, über Finanz Informatik oder Atruvia. Die Verordnung regelt diesen Fall in Artikel 5b Absatz 10: Vermittler, die im Namen vertrauender Beteiligter handeln, gelten selbst als vertrauende Beteiligte und dürfen keine Daten über den Inhalt der Transaktion speichern. Die Zweckfestlegung je Prozess bleibt trotzdem Aufgabe des Instituts, denn nur das Institut weiß, wofür es eine Angabe braucht.

Praxiserfahrung lässt sich früh sammeln. Bundesdigitalministerium und SPRIND haben laut netzpolitik.org im Januar 2026 eine Testumgebung geöffnet, in der Behörden und Unternehmen geplante Anwendungen erproben können, nach vorheriger Registrierung als vertrauende Partei. Ein Nachmittag mit zwei Prozessverantwortlichen in einer solchen Umgebung erzeugt oft mehr belastbare Erkenntnis als mehrere Konzeptrunden, und wer die Abläufe gesehen hat, formuliert präzisere Anforderungen an den Verbund.

Wie wird der Zweck je Prozess festgelegt?

Technisch ist die Abfrage ein gelöstes Problem, die anspruchsvolle Arbeit ist fachlich. Für jeden Prozess legt das Institut fest, welche Daten er wirklich braucht. Die Kontoeröffnung braucht den Identitätsdatensatz. Ein Altersnachweis braucht nicht das Geburtsdatum, sondern die Bestätigung der Volljährigkeit; die Verordnung verlangt dafür in Artikel 5a, dass die Wallet selektiv offengelegte Daten unterstützt. Die Adressänderung braucht die Adresse, nicht die ganze Identität.

Bewährt ist die kleine Runde je Strecke: Prozessverantwortung, Datenschutz und Marktfolge, eine Stunde pro Prozess, Ergebnis ist eine Zeile im Zweckregister. Die Gegenprobe gehört dazu: Jede Datenabfrage, für die sich kein Zweck benennen lässt, entfällt. Nebenbei werden Formulare entrümpelt, die über Jahrzehnte gewachsen sind. Wie dieselbe Logik in Versicherungsanträgen wirkt, zeigt der Beitrag zu Attributen statt Aktenkopien.

Prozesskette: 1. Zwecke je Prozess festlegen (nur Daten mit Rechtsgrundlage); 2. Registrieren (Identität, Kontakt, Daten je Verwendung); 3. In der Testumgebung erproben (Abläufe sehen, Anforderungen schärfen); 4. Betriebsfälle klären (Abbruch, Verlust, Kernsystem, Service); 5. Pilot, dann Rollout (Strecke mit der höchsten Abbruchquote). Darstellung: Sotica auf Basis VO (EU) 2024/1183, Art. 5b

Welche Rolle spielen Pseudonyme?

Eine Regel wird in Bankprojekten gern überlesen. Nach Artikel 5b Absatz 9 dürfen vertrauende Beteiligte die Verwendung von Pseudonymen nicht verweigern, wenn die Identifizierung des Nutzers nicht durch Unionsrecht oder nationales Recht vorgeschrieben ist. Für kontoführende Prozesse ist das unerheblich, dort verlangt das Geldwäscherecht die volle Identität. Am Rand des Angebots gibt es aber die anderen Fälle: Newsletter, Veranstaltungsportal, Finanzrechner mit Merkfunktion, Kundenfeedback.

Die saubere Lösung ist eine Zwei-Klassen-Logik: volle Identität nur, wo das Gesetz sie trägt, Pseudonym überall sonst, und die Grenze dokumentiert. Pseudonyme gehören nach einer Übersicht von Namirial vom August 2026 allerdings nicht zum Startumfang der deutschen Wallet, sie folgen nach dem Start.

Welche Betriebsfragen müssen vor dem Start beantwortet sein?

Vier Fälle entscheiden über die Alltagstauglichkeit. Bricht der Kunde die Freigabe ab, braucht die Strecke einen sauberen Rücksprung statt einer Fehlermeldung. Bei Wallet-Verlust oder Gerätewechsel müssen Service und Sperrprozesse den Fall kennen. Im Kernsystem müssen Wallet-Identifizierungen dieselben Merkmale setzen wie Altverfahren, vom Legitimationskennzeichen bis zum Prüfdatum, damit nachgelagerte Prozesse keinen Unterschied sehen. Und das Servicecenter braucht das Wissen vor dem ersten Anruf, nicht danach.

Ein kurzer Testkatalog über die häufigsten Folgeprozesse, von der Kartenbestellung bis zur Vollmachtserteilung, deckt Stolperstellen vor dem Livegang auf. Ändern sich später Zwecke oder Datenumfang, muss die vertrauende Partei das nach Artikel 5b Absatz 6 unverzüglich melden; das Zweckregister gehört deshalb in die laufende Pflege, nicht ins Projektarchiv.

In welcher Reihenfolge führt der Weg zur Annahmepflicht?

Die Reihenfolge ergibt sich rückwärts vom Stichtag. Die Annahmepflicht für Banken greift nach dem Heuking-Überblick ab Ende Dezember 2027, die deutsche Wallet d-you soll laut Bundesdigitalministerium am 2. Januar 2027 starten. Davor liegen Prozess- und Zweckinventur sowie erste Testerfahrung, ab dem Start ein Pilot auf einer echten Strecke mit messbarem Schmerz, bevorzugt der Legitimationsprozess mit der höchsten Abbruchquote, danach der Rollout mit dem Pilot als Vorlage. Den größeren Rahmen beschreibt der EUDI-Wallet-Fahrplan für Sparkassen, die Verteilung der Verantwortung im Institut der Beitrag zur Wallet-Zuständigkeit in der Bank.

Was das Management jetzt anstoßen sollte

  1. Eine Zweckinventur beauftragen: je Prozess die benötigten Daten mit Rechtsgrundlage, beginnend mit den volumenstärksten Strecken.

  2. Die Pseudonym-Grenze festlegen: volle Identität nur dort, wo das Gesetz sie verlangt.

  3. Testerfahrung sammeln: zwei Prozessverantwortliche in die Testumgebung schicken, bevor Anforderungen an den Verbund gehen.

  4. Die Betriebsfälle klären: Abbruch, Wallet-Verlust, Ablage im Kernsystem und Servicewissen.

  5. Einen Pilot auswählen: die Legitimationsstrecke mit der höchsten Abbruchquote, mit Kennzahlen davor und danach.

Häufige Fragen

Muss sich jedes Institut selbst registrieren, wenn der Verbund die Anbindung baut?
Der Dienstleister, der im Namen des Instituts handelt, gilt nach Artikel 5b Absatz 10 selbst als vertrauender Beteiligter. Wie Registrierung und Zwecke zwischen Verbund und Institut aufgeteilt werden, regelt die nationale Umsetzung; die fachliche Zweckfestlegung bleibt in jedem Fall beim Institut.

Darf das Institut mit Zustimmung des Kunden mehr Daten abfragen als registriert?
Nein. Nach Artikel 5b Absatz 3 dürfen vertrauende Beteiligte keine anderen Daten verlangen als die bei der Registrierung angegebenen.

Was passiert, wenn sich ein Prozess später ändert?
Änderungen an den registrierten Angaben sind unverzüglich zu melden. Ein gepflegtes Zweckregister macht das zu einer Routineaufgabe.

Weitere Beiträge zu Zeitplan, Pflichten und Einsatzfällen bündelt das Dossier EUDI-Wallet & digitale Identität.

Wie viele Felder in den eigenen Formularen eine Zweckprüfung überstehen würden, ist oft die ehrlichste Kennzahl für die Datenpraxis eines Instituts. Gern sprechen wir in einem ersten Gespräch darüber.

Sotica Insights

Redaktion · Beiträge aus der Beratungspraxis

Ein Thema, das gerade beschäftigt?

Gemeinsam einordnen, was daraus folgt.

Sotica ist eine Unternehmensberatung mit Sitz in München. Für alle Aufträge gelten unsere AGB. Die Inhalte dieser Website dienen der allgemeinen Information. Sotica ist eine eingetragene Marke. © 2026 Sotica. Alle Rechte vorbehalten.

Sotica ist eine Unternehmensberatung mit Sitz in München. Für alle Aufträge gelten unsere AGB. Die Inhalte dieser Website dienen der allgemeinen Information. Sotica ist eine eingetragene Marke. © 2026 Sotica. Alle Rechte vorbehalten.

Sotica ist eine Unternehmensberatung mit Sitz in München. Für alle Aufträge gelten unsere AGB. Die Inhalte dieser Website dienen der allgemeinen Information. Sotica ist eine eingetragene Marke. © 2026 Sotica. Alle Rechte vorbehalten.