Identifikation und Qualifikation: zwei Dinge, die man ständig verwechselt
Wer als Softwarehersteller Kunden aus dem Finanz-, Immobilien- oder Versicherungsumfeld bedient, begegnet früh dem Wunsch nach einer GwG-konformen Signatur. Dahinter steckt meist ein Missverständnis, das sich durch viele Ausschreibungen zieht: Identifikation und Signatur werden als ein Vorgang gedacht. Tatsächlich sind es zwei Dinge mit unterschiedlichen Zwecken, unterschiedlichen Regeln und unterschiedlichen Verantwortlichen. Wer sie sauber trennt, baut die robustere Architektur und kann Fragen von Prüfern präzise beantworten.
Die Identifizierung nach dem Geldwäschegesetz (GwG) ist eine Pflicht der sogenannten Verpflichteten, zu denen unter anderem Kredit- und Finanzdienstleistungsinstitute, Versicherer, Immobilienmakler oder Güterhändler zählen. Sie müssen ihre Vertragspartner identifizieren, wirtschaftlich Berechtigte klären und Geschäftsbeziehungen überwachen. Wie die Identifizierung erfolgen darf, regelt das Gesetz, und die zulässigen Verfahren reichen vom Personalausweis über den elektronischen Identitätsnachweis bis zu videobasierten und weiteren Verfahren unter Bedingungen. Auslegungen der Aufsicht, etwa der BaFin, konkretisieren die Anforderungen.
Die Qualifikation einer Signatur betrifft dagegen das Vertrauensniveau nach der eIDAS-Verordnung: Eine qualifizierte elektronische Signatur (QES) wird von einem qualifizierten Vertrauensdiensteanbieter (QTSP) auf Basis eines qualifizierten Zertifikats erstellt, das eine geprüfte Identifikation voraussetzt. Beide Welten berühren sich, weil auch ein QTSP den Unterzeichner identifizieren muss. Aber die Identifikation für das Zertifikat ist nicht automatisch die Identifizierung des Verpflichteten nach GwG, und umgekehrt. Ob und unter welchen Bedingungen eine Identifizierung für den einen Zweck für den anderen genutzt werden kann, ist eine rechtliche Einzelfallfrage.
Die eine harte Unterscheidung dieses Beitrags lautet daher: Der Verpflichtete trägt die GwG-Verantwortung, der QTSP trägt die Qualifikation der Signatur, und die API-Schicht orchestriert beides, ohne eine der beiden Verantwortungen zu übernehmen. Wer etwas anderes verspricht, etwa „GwG-zertifizierte Signatur“, verwechselt Begriffe. Weder das GwG noch die eIDAS-Verordnung kennt ein Zertifikat für eine Signatur-API, und wir behaupten keines.
Für ISVs heißt das: Ihr Produkt ist in der Regel nicht selbst Verpflichteter, sondern Werkzeug Ihrer Kunden, die es sind. Das verschiebt die Frage. Nicht „Ist unser Produkt GwG-konform?“, sondern „Unterstützt unser Produkt unsere Kunden dabei, ihre Pflichten zu erfüllen, und können sie das belegen?“ Diese Formulierung ist ehrlicher und im Vertrieb stärker, weil sie die tatsächliche Rolle trifft. Ihre Kunden werden die genaue Anforderung kennen, und Sie müssen nachweisen können, dass Ihr Ablauf sie abbildet.
Die Verbindung zur Signatur entsteht dort, wo Verträge in regulierten Geschäftsbeziehungen unterschrieben werden. Ein Immobilienmakler, der einen Maklervertrag signieren lässt, ein Versicherer, der einen Antrag aufnimmt, oder ein Finanzdienstleister, der ein Konto eröffnet, braucht in der Regel eine identifizierte Person und eine belastbare Signatur. Ob dafür AES oder QES passt, hängt vom Vorgang ab. Eine Einordnung der Stufen finden Sie im Beitrag AES vs QES per API, die allgemeine Perspektive im Artikel GwG, Ident und QTSP bei E-Signatur.
Die Rollen im Überblick: Ident-Provider, QTSP-Partner, API-Schicht
Eine saubere Rollenverteilung ist das wichtigste Werkzeug in Gesprächen mit Prüfern und Einkäufern. Wir unterscheiden vier Akteure, die in einer regulierten Signaturstrecke zusammenspielen. Erstens der Verpflichtete, also Ihr Kunde, der die Pflichten nach GwG trägt. Zweitens der Ident-Provider, ein Dienst, der die Identifizierung technisch durchführt, etwa per Video, eID oder anderem zulässigem Verfahren. Drittens der QTSP-Partner, der bei QES Zertifikat und Signatur erbringt. Viertens die API-Schicht, die diese Elemente in Ihre Software integriert.
Der Ident-Provider liefert ein Ergebnis: Person identifiziert oder nicht, mit Nachweisdaten. Er arbeitet nach den für seinen Dienst geltenden Regeln und trägt die Verantwortung für die korrekte Durchführung. Ob ein Ident-Provider für Ihren Anwendungsfall zulässig ist, entscheidet der Verpflichtete, nicht der Softwarehersteller. Wichtig für Sie: Der Nachweis des Provider-Ergebnisses muss im Vorgang erhalten bleiben und mit der Signatur verknüpfbar sein, sonst fehlt später die Kette.
Der QTSP-Partner erbringt bei QES die qualifizierten Vertrauensdienste. Sign2x ist kein QTSP. Wir arbeiten für QES mit Partnern wie Sign8 zusammen, und die Qualifikation entsteht dort, unter Aufsicht und nach den Anforderungen der Verordnung. Für AES und SES ist kein QTSP erforderlich, die Zuordnung und Integrität sichert die Signaturstrecke selbst. Welcher Weg für Ihren Vorgang zulässig und sinnvoll ist, hängt vom Gesetz, vom Vertragszweck und von den Vorgaben Ihres Kunden ab.
Die API-Schicht, also Sign2x, bringt Signaturstufen und Abläufe in Ihr Produkt. Sie legt Vorgänge an, bindet Dokumente und Unterzeichner ein, steuert die Reihenfolge der Schritte, liefert Ereignisse zurück und stellt sicher, dass Ergebnisse von Ident-Provider und QTSP-Partner im Vorgang nachvollziehbar sind. Sie ist ausdrücklich nicht Verpflichteter, nicht Ident-Provider und nicht QTSP. Diese Klarheit schützt Sie vor Aussagen, die Sie später nicht halten können, und sie hilft Kunden, ihre eigene Verantwortung zu verorten.
Eine Matrix kann die Verteilung greifbar machen. Frage: Wer prüft die Identität? Antwort: der Ident-Provider, im Auftrag oder nach Maßgabe des Verpflichteten. Frage: Wer erzeugt die qualifizierte Signatur? Der QTSP-Partner. Frage: Wer verknüpft Ergebnisse mit dem Vertragsvorgang? Die API-Schicht mit Ihrer Software. Frage: Wer trägt die GwG-Pflichten? Der Verpflichtete. Frage: Wer trägt die Verantwortung für das Produktdesign? Sie als ISV. Wer diese fünf Antworten in Vertragsunterlagen und Sicherheitsdokumentation klar festhält, beantwortet die meisten Prüferfragen bereits vorab.
Wie sich die Rollenteilung im Kontext von Lieferkettenpflichten darstellt, beschreibt der Beitrag DORA Artikel 30 und der Signatur-Audit-Trail. Wir betonen auch hier: DORA, NIS-2 und GwG kennen keine Zertifizierung für Signatur-APIs. Was Sie liefern können, ist Evidence, also nachvollziehbare Daten zu Ablauf und Verantwortlichkeiten, und genau darauf sollte Ihre Architektur ausgerichtet sein.
Was ISVs orchestrieren: der Ablauf einer regulierten Signaturstrecke
Als ISV orchestrieren Sie den Ablauf aus Sicht Ihres Kunden und Ihrer Nutzer. Ein typischer Ablauf beginnt mit der Vorprüfung: Welcher Vorgang liegt vor, welche Stufe und welche Identifizierung sind nötig? Diese Regeln konfigurieren Sie je Vorgangstyp und gegebenenfalls je Mandant. Es folgt die Identifizierung durch den vorgesehenen Ident-Provider, deren Ergebnis in den Vorgang einfließt. Danach läuft die Signatur, bei QES über den Partner-QTSP. Am Ende steht der Abschluss mit Ablage, Nachweisen und Folgeprozessen.
Ihre Aufgabe ist es, diese Schritte so zu verbinden, dass kein Nutzer die Naht spürt und kein Nachweis verloren geht. Das beginnt bei der Reihenfolge: Signiert wird erst nach erfolgreicher Identifizierung, und Ihr System darf keinen Weg bieten, die Prüfung zu überspringen. Es setzt sich fort bei den Wartezuständen: Identifizierungen brauchen Zeit, Nutzer unterbrechen, und Ihr Zustandsmodell muss das abbilden. Wie Sie das sauber lösen, beschreibt der Beitrag Webhook State Management für E-Signatur-Events.
Dazu kommt die Datenzuordnung. Das Ergebnis der Identifizierung gehört zu einer konkreten Person und einem konkreten Vorgang. Ihr System sollte die Verknüpfung zwischen Identifizierungsnachweis, Signaturvorgang und Dokument eindeutig speichern, mit Zeitstempeln und Referenzen. Was an Daten tatsächlich bei Ihnen liegt und was beim Ident-Provider oder beim QTSP, sollten Sie bewusst festlegen und dokumentieren, denn davon hängen Auskunftsrechte, Löschfristen und Aufbewahrungspflichten ab.
Die Oberfläche entscheidet über Abschlussquoten. Identifizierungsstrecken sind für Nutzer aufwendig, und jede Unklarheit kostet Abschlüsse. Erklären Sie vor dem Start, was passiert, wie lange es dauert und was bereitliegen sollte. Halten Sie den Nutzer in Ihrer Oberfläche, statt ihn auf fremde Seiten zu schicken, soweit der Ident-Provider es erlaubt. Wie sich Strecken ohne Medienbruch gestalten lassen, steht im Beitrag White-label Signatur-API ohne Medienbruch.
Für mandantenfähige Produkte gilt zusätzlich: Nicht jeder Kunde hat dieselben Pflichten und Präferenzen. Ein Versicherungsmakler hat andere Anforderungen als ein Finanzdienstleister. Ihre Konfiguration sollte Ident-Verfahren, Stufen und Texte je Mandant ermöglichen, ohne dass dafür Code geändert wird. Außerdem sollte erkennbar sein, wer eine Konfiguration wann geändert hat, denn bei Prüfungen wird gefragt, welche Regeln zu einem bestimmten Zeitpunkt galten. Hintergründe zu Mandantenmodellen liefert Whitelabel-Anforderungen für ISVs.
Schließlich ist die Fehlerseite zu bedenken. Identifizierungen scheitern: Dokumente sind nicht lesbar, Videoverbindungen brechen ab, Nutzer sind nicht berechtigt. Ihr Ablauf braucht definierte Wege für solche Fälle: Wiederholung, alternatives Verfahren, manuelle Prüfung, Abbruch mit Begründung. Wichtig ist, dass ein gescheiterter Versuch nicht stillschweigend zu einer Signatur führt und dass der Fehler im Protokoll steht. Gerade in regulierten Strecken ist die Dokumentation des Scheiterns so wichtig wie die des Gelingens.
Praxisbeispiel: eine Maklerplattform mit GwG-nahem Vertragsabschluss
Ein Beispiel macht die Rollen greifbar. Ein ISV betreibt eine Plattform für Immobilienmakler, die Maklerverträge, Reservierungsvereinbarungen und Datenschutzerklärungen digital abschließen lassen. Die Makler sind Verpflichtete nach dem GwG und müssen bestimmte Vertragspartner identifizieren. Der ISV selbst ist es nicht, er liefert das Werkzeug. Die Plattform verbindet drei Dinge: einen Ident-Provider für die Identifizierung, die Signaturstrecke für den Vertragsabschluss und eine Ablage für Nachweise.
Im Ablauf legt der Makler in der Plattform einen Vorgang an. Das System prüft anhand der Konfiguration, welche Identifizierung für diesen Vorgangstyp vorgesehen ist, und startet sie für den Kunden des Maklers. Erst wenn das Ergebnis vorliegt und positiv ist, schaltet die Plattform die Signatur frei. Je nach Vorgang kommt AES oder QES zum Einsatz. Nach Abschluss erhält der Makler das signierte Dokument und einen Nachweisdatensatz, der Identifizierung, Signatur und Zeitpunkte verknüpft. Die Plattform selbst speichert nur, was für Betrieb und Nachweis nötig ist.
Interessant sind die Fragen, die der Makler im Prüfungsfall beantworten muss: Wer wurde wann und wie identifiziert? Wo liegt der Nachweis? Wurde vor der Signatur identifiziert? Mit der beschriebenen Architektur lassen sich diese Fragen aus dem Ereignisprotokoll beantworten, ohne dass jemand Screenshots sammelt. Das ist der praktische Wert sauberer Rollen und Datenflüsse. Zugleich bleibt klar, was die Plattform nicht leistet: Sie entscheidet nicht, ob ein Verfahren für den Fall zulässig ist, und sie ersetzt keine Risikoanalyse des Maklers.
Für den ISV ergibt sich ein Vertriebsvorteil, wenn er diese Abgrenzung offen kommuniziert. Makler und Compliance-Verantwortliche sind es gewohnt, dass Anbieter Zertifizierungen versprechen, die es nicht gibt. Ein Anbieter, der sagt „Wir liefern die Orchestrierung und die Nachweise, Sie tragen die Pflichten, und hier ist die Rollenmatrix“, wirkt glaubwürdiger. Das gilt auch für Anschlussfragen zu Lieferkette und Hosting, die sich mit der Dokumentation aus den vorigen Abschnitten beantworten lassen. Planen Sie für solche Gespräche eine Seite, die Rollen, Datenflüsse und Grenzen auf einen Blick zeigt. Sie verkürzt Sicherheitsfragebögen und gibt Ihrem Vertrieb eine verlässliche Grundlage, statt jede Frage neu zu improvisieren.
Datenflüsse und Hosting: wohin personenbezogene Daten gehen
In einer GwG-nahen Signaturstrecke fließen besonders sensible Daten: Ausweisdaten, Gesichtsbilder, Adressen, Vertragsinhalte. Daraus ergibt sich eine einfache, aber zentrale Aufgabe: Zeichnen Sie die Datenflüsse auf. Welche Daten gehen vom Nutzer an den Ident-Provider? Welche vom Ident-Provider an Sie oder an den QTSP? Welche gehen vom QTSP zurück? Wo liegen Dokumente, wo Nachweise, wo Protokolle? Eine solche Skizze ist die Grundlage für Auftragsverarbeitung, Datenschutz-Folgenabschätzung und Lieferkettendokumentation.
Zum Hosting: Sign2x läuft auf der Open Sovereign Cloud (OSC) von T-Systems, einem europäischen Betrieb unter europäischem Recht. Das betrifft unsere Plattform. Ident-Provider und QTSP-Partner sind eigene Beteiligte mit eigenen Standorten und Rechtsrahmen, die Sie bei Ihrer Bewertung gesondert betrachten sollten. Fragen Sie jeweils nach Verarbeitungsort, Eigentümerstruktur und Unterauftragnehmern. Eine Einordnung, warum Standort allein nicht genügt, liefert der Beitrag Cloud Act vs Datensouveränität.
Datensparsamkeit ist die wirksamste Schutzmaßnahme. Übertragen Sie nur Daten, die für den jeweiligen Schritt nötig sind, und speichern Sie Nachweise nur so lange und so weit, wie Gesetz und Vertrag es verlangen. Die DSGVO verlangt Zweckbindung und Minimierung, und bei Ausweisdaten gilt das mit besonderem Gewicht. Prüfen Sie, ob Sie Rohdaten wirklich brauchen oder ob ein Ergebnis mit Referenz genügt. Je weniger sensible Daten bei Ihnen liegen, desto kleiner ist die Angriffsfläche und desto einfacher die Dokumentation.
Aufbewahrungsfristen im Geldwäschekontext sind eigene Regeln, die sich von den Fristen für Verträge unterscheiden können. Klären Sie mit Ihren Kunden, wer welche Nachweise wie lange vorhält, und bilden Sie das in Ihrer Löschlogik ab. Ein Löschlauf, der Nachweise vor Ablauf der Pflicht entfernt, ist ein Compliance-Problem, einer, der sie unbegrenzt behält, ein Datenschutzproblem. Beides lässt sich mit klaren Klassen und Regeln pro Dokument- und Nachweistyp vermeiden.
Auch für Auditfragen gilt: Je klarer Ihre Datenflüsse, desto schneller Ihre Antworten. Wenn ein Kunde fragt, wo Ausweisdaten liegen, sollten Sie nicht suchen müssen, sondern auf ein Dokument verweisen können. Dasselbe gilt für die Frage, wer Zugriff hat. Wir unterstützen Sie gern bei der Strukturierung, aber die Verantwortung für die Gesamtdokumentation bleibt bei Ihnen und Ihren Kunden. Eine Selbsteinschätzung hilft beim Einstieg: Das Sign2x Quiz sortiert Anforderungen, das Help Center erklärt Begriffe.
Checkliste für ISVs: GwG-nahe Signaturstrecken vorbereiten
Die folgende Checkliste ersetzt keine Rechtsberatung und keine Prüfung durch Ihre Kunden, sie hilft aber, die Architektur auf typische Fragen vorzubereiten.
- Rollen festhalten: Dokumentieren Sie Verpflichteten, Ident-Provider, QTSP-Partner und API-Schicht mit Verantwortlichkeiten, und stellen Sie klar, dass Sign2x kein QTSP ist.
- Stufen zuordnen: Legen Sie je Vorgangstyp fest, ob SES, AES oder QES gilt, und lassen Sie die Zuordnung rechtlich prüfen.
- Reihenfolge erzwingen: Stellen Sie technisch sicher, dass die Signatur erst nach erfolgreicher Identifizierung möglich ist.
- Nachweise verknüpfen: Speichern Sie Identifizierungsergebnis, Signaturvorgang und Dokument mit eindeutigen Referenzen und Zeitstempeln.
- Fehlerwege definieren: Beschreiben Sie, was bei gescheiterter Identifizierung geschieht, und protokollieren Sie auch Fehlversuche.
- Datenflüsse zeichnen: Erfassen Sie, welche Daten wohin gehen, wo sie liegen und wie lange sie aufbewahrt werden.
- Mandanten konfigurieren: Ermöglichen Sie Verfahren, Stufen und Texte je Mandant mit Änderungshistorie.
- Partner prüfen: Prüfen Sie Status und Standort von Ident-Provider und QTSP regelmäßig und halten Sie das Ergebnis fest.
Wenn Sie diese acht Punkte abgearbeitet haben, besitzen Sie eine belastbare Grundlage für Gespräche mit Kunden und Prüfern. Beginnen Sie mit den Rollen und der Reihenfolge, denn sie sind am schnellsten festgelegt und bringen die größte Klarheit. Technische Grundlagen finden Sie im Developer Hub, Praxisfälle unter Use Cases, weitere Fachbeiträge im Sign2x Blog. Für Fragen zu Ihrem Szenario erreichen Sie uns über den Kontakt.
Auch der Ausblick gehört dazu: Mit der Einführung der EUDI Wallet werden sich Identifikationswege verändern. Welche Folgen das für Ihre Strecke hat, hängt von Durchführungsrechtsakten und den Anbietern ab. Wir bereiten die Architektur vor, behaupten aber keine produktive Wallet-Anbindung, wie wir im Beitrag eIDAS 2.0 Deadline und EUDI Wallet für SaaS erläutern. Die Rollentrennung, die Sie heute sauber festhalten, erleichtert Ihnen diesen Übergang, weil neue Kanäle in die Rolle des Ident-Providers passen, ohne den Rest zu verändern.
Rollen und Begriffe im Help Center nachlesen
Verwandte Beiträge: QTSP-Partner für ISVs und NIS-2 Nachweis über den Audit-Trail. Hinweise zur Informationssicherheit beim BSI.
Häufige Fragen
Ist Sign2x GwG-zertifiziert?
Nein, und es gibt kein GwG-Zertifikat für Signatur-APIs. Sign2x ist die API-Schicht, die Identifizierungsergebnisse und Signaturen im Vorgang nachvollziehbar verbindet. Die GwG-Pflichten tragen die Verpflichteten, also Ihre Kunden.
Ist Sign2x ein QTSP oder ein Ident-Provider?
Weder noch. Sign2x ist die API-Schicht. Für QES arbeiten wir mit Partner-QTSPs wie Sign8, die Identifizierung übernimmt ein dafür vorgesehener Ident-Provider.
Ersetzt eine QES die Identifizierung nach GwG?
Nicht automatisch. Identifikation für ein qualifiziertes Zertifikat und Identifizierung nach GwG sind unterschiedliche Vorgänge. Ob eine für den anderen Zweck nutzbar ist, ist eine rechtliche Einzelfallfrage.
Was muss ein ISV technisch sicherstellen?
Dass die Signatur erst nach erfolgreicher Identifizierung möglich ist, dass Ergebnisse mit Vorgang und Dokument verknüpft bleiben und dass auch Fehlversuche protokolliert werden.
Wo wird Sign2x gehostet?
Auf der Open Sovereign Cloud (OSC) von T-Systems. Ident-Provider und QTSP-Partner haben eigene Standorte, die Sie gesondert bewerten sollten.
