Fälschungserkennung bei Ausweisdokumenten und Liveness-Prüfung

Banken, Versicherer, Telekommunikationsunternehmen, Mobilitätsanbieter und E-Commerce-Firmen nehmen Kundinnen und Kunden immer häufiger auf, ohne sie zu treffen. Betrüger antworten mit gefälschten oder gestohlenen Ausweisen, ausgedruckten oder abgespielten Selfies, Masken und zunehmend mit Deepfakes, die direkt in den Kamerastrom eingespeist werden. Moderne Systeme zur Identitätsprüfung (IDV) prüfen das Dokument (optische Sicherheitsmerkmale, MRZ, NFC-Chip), die Person (Liveness, Gesichtsabgleich) und den Kanal (Geräte- und Injection-Integrität) und geben nur unklare Fälle an einen Menschen weiter.

Problem & Nutzen

• Heute: Das Onboarding aus der Ferne stützt sich auf das Foto eines Ausweises und ein Selfie oder auf Video-Ident-Gespräche mit einer Mitarbeiterin bzw. einem Mitarbeiter. Beschäftigte und einfache OCR erkennen gute Fälschungen nicht zuverlässig, und Mitarbeitende erkennen Gesichtstausch in Echtzeit schlecht. Strenge Prüfungen kosten Abschlüsse; schwache Prüfungen ermöglichen Mule-Konten, synthetische Identitäten und Kontoübernahmen.
• KI-Nutzen: Automatisierte Dokumentenforensik, passive/aktive Liveness-Prüfung und Gesichtsabgleich entscheiden die meisten Fälle in Sekunden; Mitarbeitende bleiben den Ausnahmen vorbehalten. Das Auslesen des NFC-Chips eines eID/E-Passes (kryptografisch signiert) ist deutlich stärker als die Beurteilung der gedruckten Karte.
• Veränderte Bedrohungslage: Das BSI stellt fest, dass Deepfakes biometrische Fernprüfungen wie die Videoidentifikation überwinden können, dass einige Face-Swap-Modelle in Echtzeit laufen und dass automatisierte Detektoren auf neue Angriffsmethoden oft schlecht verallgemeinern [6]. Die Abwehr muss daher mehrschichtig sein und darf sich nicht auf einen einzigen Detektor verlassen.
• Regulatorischer Sog: Die EU-Mitgliedstaaten müssen bis Ende 2026 EUDI-Wallets anbieten, und Anbieter, die zur Identifizierung ihrer Kunden verpflichtet sind, müssen die Wallet akzeptieren [7]. Wallet-Nachweise werden die Fotos von Dokumenten schrittweise ersetzen, doch Prüfungen von Ausweisdokumenten bleiben noch Jahre nötig (ausländische Dokumente, Wallet-Wiederherstellung, nicht regulierte Anwendungsfälle).
• Eine allgemeingültige Zahl zur Betrugsreduktion wird hier nicht genannt; messen Sie Ihre eigene Ausgangslage mit Testangriffen.

Varianten

• KYC-/AML-Onboarding (Banken, Zahlungsdienste, Krypto, Versicherung): vollständige Prüfung aus Dokument, Chip, Liveness und Abgleich, gekoppelt an die Identifizierungspflichten der Geldwäschebekämpfung (z. B. GwG in Deutschland); siehe ANOM-002, ANOM-016.
• Kontowiederherstellung / zusätzliche Prüfung: Selfie wird mit dem Foto abgeglichen, das beim Onboarding oder in einem Nachweis bereits verifiziert wurde (z. B. Microsoft Entra Verified ID Face Check [4]); siehe SEC-005.
• Alters- und Berechtigungsprüfungen: dokumentenbasierte Altersverifikation für Glücksspiel, Alkohol, nicht jugendfreie Inhalte.
• Belegschaft und Gig-Plattformen: Onboarding von Fahrern, Kurieren, Freelancern, Remote-Einstellungen; Abwehr falscher Bewerber.
• SIM-Registrierung bei Telekommunikationsanbietern, Carsharing, Vermietung, Hotels: Dokument und Selfie an Self-Service-Punkten.
• Öffentlicher Sektor: Online-Dienste, Abläufe mit Personalausweis (nPA) und Wallet; Grenzkontrolle und Strafverfolgung liegen außerhalb dieser Datei (siehe Risiken).
• Private Nutzung: keine direkte; Verbraucher begegnen dem Verfahren als geprüfte Person. Datenschutzfreundliche Option: Prüfung auf dem Gerät und selektive Offenlegung über eine Wallet.

So funktioniert es

1. capture (SDK in app/web: document + selfie/video, guided)
2. channel integrity (app attestation, root/jailbreak, emulator, virtual camera, hooking detection)
3. document analysis (type classification
4. OCR/MRZ
5. security features
6. tamper/copy/print-screen detection)
7. chip read (NFC: passive/active/chip authentication, certificate chain) when available
8. liveness (passive or active; presentation-attack + injection-attack detection)
9. face match (selfie vs. chip/document photo; threshold per risk level)
10. consistency + risk (data vs. MRZ/chip, age, expiry, device/IP reputation, duplicate-identity check)
11. decision (accept / step-up / manual review / reject) + evidence archive

• Dokumentenprüfungen: Klassifikator für den Dokumenttyp, OCR und Prüfsummenvalidierung der MRZ, Detektoren für Hologramme, Schriftarten, Mikroschrift, Fotoaustausch, Bildschirmwiedergabe und Fotokopie; forensische Prüfungen unter UV/IR auf dedizierten Lesegeräten (Regula nennt eine Datenbank mit über 16.500 Dokumenttypen aus 254 Ländern und Gebieten sowie ICAO-9303-MRZ- und Chip-Authentifizierung [3]).
• Liveness: Die Präsentationsangriffserkennung (PAD) findet ausgedruckte Fotos, Wiedergaben und Masken; die Injection-Angriffserkennung (IAD) findet synthetisches Video, das an der Kamera vorbei eingespeist wird (virtuelle Kameras, manipulierte SDKs, Emulatoren). Die Abwehr braucht sowohl Kontrollen auf der Aufnahmeseite als auch eine serverseitige Analyse. Challenge-Response-Verfahren (AWS nutzt für höchste Genauigkeit Gesichtsbewegung plus eine Farblicht-Sequenz) erhöhen die Widerstandsfähigkeit gegen Wiedergabe [2].
• Gesichtsabgleich: Embedding-basierter 1:1-Vergleich mit abgestimmten Schwellenwerten; Anbieter geben die Sicherheit als Score an (Microsoft dokumentiert einen konfigurierbaren Schwellenwert von 50–100) [4].
• Mensch-in-der-Schleife (Human-in-the-Loop): Grenzwertige Scores, Dokumenttypen ohne Vorlagen und alle Ablehnungen, die eine Person von einem Dienst aussperren können, gehen an geschulte Prüferinnen und Prüfer; Nutzer brauchen einen alternativen Weg (Filiale, Post-Ident, eID).

Datenaufbereitung

Die Daten entstehen überwiegend bei der Aufnahme: Fotos oder Videos von Ausweisdokumenten und Selfies von Kundinnen und Kunden, meist über eine Mobil-App oder ein Web-Onboarding. Referenzdaten (Dokumentvorlagen, Sicherheitsmerkmale, Muster der ausstellenden Staaten) stammen vom Anbieter. In einem KMU liegen die begleitenden Unterlagen im CRM, im Onboarding-Postfach, in Papierkopien und auf Dateiablagen. Typische Lücken sind schlechte Bildqualität (Spiegelungen, Unschärfe), Fotos von Bildschirmen, fehlende Einwilligungsnachweise, verstreute Ausweiskopien ohne Löschfristen und keine mit Labels versehene Historie bestätigter Betrugsfälle.

Schritte der Aufbereitung: (1) den Aufnahmeablauf und Hinweise zur Bildqualität für die Nutzer festlegen; (2) vorhandene Ausweiskopien bereinigen, Aufbewahrungs- und Löschregeln festlegen und Zugriffsrechte einschränken (PREP-023, PREP-025); (3) die Daten als biometrische Daten mit hohem Risiko einstufen (PREP-024); (4) bestätigte Betrugsfälle und fälschliche Ablehnungen gemeinsam mit dem Compliance-Team als Testdatensatz sammeln (PREP-018, PREP-020); (5) Daten, die zur Feinabstimmung genutzt werden, pseudonymisieren (PREP-022). Bei Weg A ist wenig Aufbereitung von Trainingsdaten nötig; der Aufwand wird von Prozess, Einwilligung und der Bereinigung der Aufbewahrung bestimmt, etwa 20–30 Prozent des Gesamtaufwands.

Umsetzungswege

Welcher Weg für wen

• KMU: Weg A - Es gibt ausgereifte, zertifizierte, in der EU gehostete Dienste zur Identitätsprüfung (eIDAS-/AML-tauglich) mit Preisen je Prüfung; Fälschungs- und Liveness-Erkennung selbst zu bauen ist nicht realistisch.
• Großunternehmen: Weg A - Die Identitätsprüfung ist eine Standardfunktion mit zertifizierten Anbietern; B nur für besondere Dokumenttypen oder tiefe Integration.
• Entwickler: Weg B - OCR-, Dokumentenprüf- und Liveness-APIs zu einem eigenen Onboarding-Ablauf für Ihre Kunden zusammensetzen.
• Öffentlicher Sektor: Weg A - Behörden sollten zertifizierte Produkte (z. B. eID-basiert oder vom BSI evaluiert) gegenüber selbst entwickelten biometrischen Prüfungen bevorzugen.

Weg A — Kaufen (Standardsoftware) (für die meisten Organisationen empfohlen)

• IDV-Plattformen (EU/Deutschland): IDnow (DE, München: Dienste für Dokument, Biometrie, eID, EUDI-Wallet und qualifizierte Signatur) [5], Nect (DE), WebID Solutions (DE), Authada (DE), Signicat (NO), Veriff (EE), Onfido (jetzt Teil von Entrust), Sumsub, Jumio, Incode, Yoti (UK), iProov (UK, Liveness). Prüfen Sie: Datenspeicherung in der EU, ISO/IEC-30107-3-PAD-Testbescheinigungen, Tests zu Injection-Angriffen, Zertifizierung für Ihren Sektor (z. B. anerkannt für die Identifizierung nach GwG/BaFin, ETSI TS 119 461 für Vertrauensdienste), Abschlussquoten.
• Testnachweise: iBeta veröffentlicht ISO-30107-3-PAD-Bestätigungsschreiben; Level 2 erlaubt höchstens 1 % erfolgreiche Angriffe und verlangt eine Fehlerquote bei echten Nutzern von höchstens 15 %, Level 1 erlaubt 0 % erfolgreiche Angriffe [9]. Diese Schreiben decken Präsentationsangriffe ab, nicht Injection-Angriffe; fragen Sie daher gesondert nach Letzteren.
• Dokumentenleser: Regula (Dokumenten-SDK/Lesegeräte, forensische Geräte) für besetzte Schalter und Kioske [3].
• Wählen Sie A, wenn: regulierte Aufnahme von Kunden, kein eigenes Biometrie-Team. Fast immer die richtige Standardwahl.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Cloud-Bausteine für Liveness und Abgleich: Amazon Rekognition Face Liveness mit CompareFaces (liefert einen Score von 0–100, ein Referenzbild und Audit-Bilder; AWS betont, dass es mit weiteren Faktoren und mit Kontrollen auf dem Gerät kombiniert werden muss) [2]; Azure AI Vision Face mit Liveness (laut Microsoft konform mit iBeta Level 2 [4]). Nutzen Sie EU-Regionen; beide Anbieter weisen darauf hin, dass die Ergebnisse probabilistisch sind.
• Dokumentenerkennung: Azure Document Intelligence (Modell für Ausweisdokumente), Google Document AI (Identitätsprozessoren), Textract AnalyzeID, Mistral OCR (EU); ein VLM kann Schlussfolgerungen über Unstimmigkeiten ergänzen, darf aber nicht der einzige Fälschungsdetektor sein.
• Orchestrierung: ein eigener Entscheidungsdienst (Regeln + Gradient-Boosting-Risikomodell), Workflow-Engine für die manuelle Prüfung.
• Wählen Sie B, wenn: Sie ein Entwicklerteam haben, die Kontrolle über die Benutzerführung brauchen und eine verwaltete Biometrie-API akzeptieren. Beachten Sie, dass Sie dann das Risiko bei Injection-Angriffen und Entscheidungslogik selbst tragen.

Weg C — Selbst betreiben (Open Source)

• Realistisch für einzelne Komponenten, schwierig für eine durchgängige Absicherung. Bausteine: InsightFace (Code unter MIT; vortrainierte Modelle auf nichtkommerzielle Forschung beschränkt, für kommerzielle Nutzung ist eine Lizenz nötig) [8], Silent-Face-Anti-Spoofing (Apache-2.0, passive RGB-Liveness; die Autoren weisen auf die Kameraabhängigkeit hin und darauf, dass ihr stärkeres Modell nicht veröffentlicht ist) [10], Tesseract/PaddleOCR/Docling für Text, offene ICAO-9303-Bibliotheken für MRZ und eMRTD (z. B. JMRTD) für das Auslesen des Chips.
• Hardware: HW1–HW2; Gesichts- und Liveness-Modelle sind klein, und eine einzelne GPU mit 24 GB oder CPU-/Edge-Geräte bewältigen tausende Prüfungen pro Stunde. Ein souveräner Betrieb On-Premises ist möglich (öffentlicher Sektor, hohe Sicherheit), aber Sie müssen Ihre eigene PAD-/IAD-Bewertung durchführen; offene Modelle haben selten ISO-30107-3-Zertifikate.
• Wählen Sie C, wenn: strenge Anforderungen an die Datensouveränität, Kiosk-/Offline-Betrieb oder als Vorfilter vor einem zugekauften Dienst.

Weg D — Eigenes Training

Lohnt sich für Anbieter, große Banken oder Regierungen mit ungewöhnlichen Dokumenten (nationale Ausweise, die von Anbietern nicht abgedeckt werden) oder besonderen Angriffsprofilen. Erfordert tausende echte Proben und Angriffsproben mit Einwilligung, die Erzeugung synthetischer Angriffe und ein Red-Team-Programm; die Erhebung biometrischer Daten ist der wichtigste rechtliche und ethische Aufwand (DSGVO Art. 9). Rechnen Sie mit regelmäßigem Nachtrainieren, wenn sich die Angriffswerkzeuge ändern.

Stand der Technik (2026)

• Mehrschichtige Absicherung ist Standard: NFC-Chip-Authentifizierung (stärkster Dokumentennachweis), zertifizierte PAD, Schutz vor Injection, Risikosignale. ISO/IEC 30107-3 (PAD-Tests) und die Bestätigungsstufen von iBeta sind die übliche Basis [9]; aktuelle iBeta-Listen enthalten sowohl etablierte als auch neue Anbieter auf Level 1–3 [9].
• Injection-Angriffe sind die größte Lücke. Virtuelle Kameras, Emulatoren und Gesichtstausch in Echtzeit umgehen die auf die Kamera gerichtete PAD. Gegenmaßnahmen: Attestierung vertrauenswürdiger Geräte (Microsofts Face Check weist Android-Geräte ohne das Play-Integrity-Urteil MEETS_STRONG_INTEGRITY ab und läuft nur im Authenticator, um Injection zu verhindern) [4], gehärtete SDKs, serverseitige Analyse von Artefakten.
• Passive Liveness (ohne Handlung der Nutzer) verringert die Reibung, aber reine RGB-Modelle reagieren empfindlich auf Kamera und Szenario [10].
• Wallet-Wandel: EUDI-Wallets bis Ende 2026 [7] verlagern das Vertrauen von der Bildanalyse hin zu signierten Attestierungen, mit Gesichtsprüfung gegen ein Foto im Nachweis.
• Grenzen: Fairness (Fehlerraten unterscheiden sich nach Hautton, Alter, Behinderung, Kameraqualität), Dokumente, die nicht in den Anbieterdatenbanken stehen, einfache Smartphones und ein Wettrüsten mit generativen Modellen. Detektoren, die auf heutigen Fälschungen trainiert wurden, versagen oft bei neuen Generatoren [6].

Gemeinsame Bausteine & Kombinationen

• Gemeinsame Bausteine: Pipelines für face-biometrics, ocr-docparse, image-classification und VLM werden auch von ANOM-017 (manipulierte Kontoauszüge, Gehaltsabrechnungen), DOC-003 (Formulare und Ausweiserfassung) und SEC-011 (Deepfake-Erkennung in Gesprächen) genutzt. Ein GPU-Server (HW2) kann Dokumentenerkennung, Gesichts-Embedding und Liveness-Modelle gemeinsam hosten.
• Nachgelagerte und benachbarte Fälle: ANOM-004 (gefälschte Konten und Bots; Geräte- und Risikosignale teilen), ANOM-001 (Zahlungsbetrug), ANOM-002 und ANOM-016 (AML-Überwachung, Sanktions-/PEP-Prüfung der verifizierten Identität), ANOM-022 (Erkennung von Money Mules), AGENT-015 (Onboarding-/KYC-Agent, der diese Prüfung orchestriert), ANOM-015 (Herkunftsnachweis und KI-generierte Medien).
• Abgrenzung: ANOM-017 behandelt Manipulationen an Finanzdokumenten; diese Datei behandelt Ausweisdokumente und die Person vor der Kamera.
• Datenpipeline: ein Nachweisspeicher (Bilder, Scores, Entscheidung, Einwilligung) mit kurzer Aufbewahrung dient Audit, Einsprüchen und Modellüberwachung.

Aufwand, Kosten & Kennzahlen

• Weg A: Tage bis wenige Wochen (SDK-Integration, Feinabstimmung der Benutzerführung); Abrechnung je Verifizierung.
• Weg B: 2–4 Monate inkl. Benutzerführung, Entscheidungslogik, Sicherheitstests des Aufnahmekanals; Cloud-API-Kosten je Sitzung.
• Weg C: 4–9 Monate für einen Vorfilter oder einen souveränen Kiosk; laufender Red-Team-Aufwand.
• Weg D: 9–18 Monate, spezialisiertes Team; nur für Nischenbedarf.
• Kennzahlen: Akzeptanzrate von Angriffen (aus Red-Team-Tests), Ablehnungsrate echter Nutzer (BPCER), Abschluss-/Konversionsrate, Anteil manueller Prüfungen, durchschnittliche Bearbeitungszeit, dem Onboarding zugeordnete Betrugsverluste, Fairness-Kennzahlen je demografischer Gruppe, Ergebnisse von Einsprüchen.

Menschen & Veränderung

Beziehen Sie zuerst die Geschäftsführung und die oder den Compliance- bzw. Geldwäschebeauftragten ein, denn sie tragen die gesetzliche Pflicht zur Identifizierung der Kunden. IT-Sicherheit und die oder der Datenschutzbeauftragte werden früh gebraucht: Die Verarbeitung biometrischer Daten ist sensibel; prüfen Sie daher die Rechtsgrundlage, den Auftragsverarbeitungsvertrag (AVV) mit dem Anbieter und ob eine Datenschutz-Folgenabschätzung (DSFA) nötig ist (Art. 35 DSGVO; GUIDE-005). Die Rechtsabteilung prüft Anbietervertrag und Haftung (GUIDE-010). Beschäftigte im Onboarding, die Eskalationen bearbeiten, sind die Anwenderinnen und Anwender und brauchen Schulung zur Prüfung markierter Fälle.

Betriebsrat: im typischen Fall nein, da Kundinnen und Kunden und nicht Beschäftigte geprüft werden. Mitbestimmung kann entstehen, wenn Ausweisprüfungen von Beschäftigten einbezogen werden oder wenn Mitarbeitende, die die Ergebnisse bearbeiten, einzeln überwacht werden; dann gilt § 87 Abs. 1 Nr. 6 BetrVG. Informieren Sie den Betriebsrat rechtzeitig über die Änderung des Arbeitsablaufs nach § 90 Abs. 1 Nr. 3 (GUIDE-004).

KI-Kompetenz: Unterstützen Sie die Prüfenden mit Schulungen zu typischen Deepfake- und Fälschungsmustern, Fehlerraten und Verzerrungen bei Hauttönen und Altersgruppen (KI-Verordnung Art. 4, GUIDE-006). Typische Bedenken von Kundinnen und Kunden betreffen Datenschutz und Diskriminierung; bieten Sie einen alternativen manuellen Verifizierungsweg und klare Informationen an. Behalten Sie den Menschen in der Kontrolle: Grenzfälle und Ablehnungen gehen immer an eine geschulte Person, nie in eine automatische endgültige Ablehnung. Starten Sie zunächst mit einem Onboarding-Kanal als Pilot (GUIDE-009).

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): Biometrische Verifizierung, deren alleiniger Zweck die Bestätigung ist, dass eine Person die ist, für die sie sich ausgibt, ist von der Hochrisiko-Kategorie für biometrische Fernidentifizierung in Anhang III ausgenommen [1]. Ein typischer 1:1-Ablauf mit Selfie und Ausweis ist daher kein Hochrisiko-System nach Anhang III, doch die Einstufung hängt vom Kontext ab: 1:N-Suchen (z. B. Sanktionslisten über Kunden hinweg), biometrische Kategorisierung nach sensiblen Merkmalen oder Emotionserkennung fallen unter Anhang III oder Art. 5 und müssen vermieden werden. Biometrische Echtzeit-Fernidentifizierung in öffentlich zugänglichen Räumen zu Strafverfolgungszwecken ist grundsätzlich verboten (Art. 5 Abs. 1 Buchst. h) und nicht Teil dieses Anwendungsfalls. Lassen Sie dies juristisch prüfen; andere Verwendungen nach Anhang III (z. B. Zugang zu wesentlichen Diensten/Krediten) können für die nachgelagerte Entscheidung gelten.
• DSGVO: Gesichtsvorlagen zur eindeutigen Identifizierung sind besondere Kategorien personenbezogener Daten (Art. 9). Nötig sind eine Rechtsgrundlage (ausdrückliche Einwilligung oder gesetzliche Identifizierungspflicht wie das GwG), eine DSFA, Datenminimierung, kurze Aufbewahrung und eine nicht biometrische Alternative, damit die Einwilligung freiwillig ist. Für ausschließlich automatisierte Ablehnungen gelten die Schutzvorkehrungen nach Art. 22: bieten Sie eine menschliche Prüfung an.
• Branchenrecht: Identifizierungsregeln zur Geldwäschebekämpfung (GwG, BaFin-Auslegungshinweise, EU-AMLR ab 2027), eIDAS und ETSI TS 119 461 für Vertrauensdienste, DORA für das IKT-Risiko bei Drittanbietern von IDV, PSD2 für die starke Kundenauthentifizierung.
• Risiken und Gegenmaßnahmen: Injection-Angriffe (attestierte Geräte, gehärtetes SDK, serverseitige Analyse), Verzerrung (Tests je Gruppe, Schwellenwerte), Anbieterabhängigkeit und Verletzungen des Schutzes biometrischer Daten (Hosting in der EU, Verschlüsselung, Löschung), Aussperrung legitimer Nutzer (alternative Kanäle), übermäßige Datenerhebung (Scores statt Rohvideo speichern, soweit zulässig).

Erste Schritte

1. Je Nutzerreise das Sicherheitsniveau und die Rechtsgrundlage (AML, eIDAS, Alter) festlegen; klären, ob das Auslesen des NFC-Chips möglich ist.
2. 2–3 IDV-Anbieter in die engere Wahl nehmen; ISO-30107-3-Nachweise, Testergebnisse zu Injection-Angriffen und Bedingungen zur Datenspeicherung in der EU anfordern.
3. Mit Ihrer realen Kundenmischung (Dokumenttypen, Geräte) pilotieren und Konversion sowie Prüfquote messen.
4. Einen internen Red-Team-Test mit gedruckten, abgespielten und eingespeisten Angriffen durchführen und die Fairness je Gruppe messen.
5. DSFA, Aufbewahrungsregeln, Ausweichkanal und einen Weg zur Akzeptanz von EUDI-Wallets vorbereiten.

Quellen

1. EU AI Act Service Desk — Annex III (biometrics, verification exclusion) — https://ai-act-service-desk.ec.europa.eu/en/ai-act/annex-3
2. AWS — Amazon Rekognition Face Liveness — https://docs.aws.amazon.com/rekognition/latest/dg/face-liveness.html
3. Regula — Document Reader SDK — https://www.regulaforensics.com/products/document-reader-sdk/
4. Microsoft — Face Check with Microsoft Entra Verified ID — https://learn.microsoft.com/en-us/entra/verified-id/using-facecheck
5. IDnow — product overview — https://www.idnow.io/
6. BSI — Deepfakes: threats and countermeasures — https://www.bsi.bund.de/EN/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Kuenstliche-Intelligenz/Deepfakes/deepfakes_node.html
7. European Commission — European Digital Identity Regulation — https://digital-strategy.ec.europa.eu/en/policies/eudi-regulation
8. InsightFace — https://github.com/deepinsight/insightface
9. iBeta — ISO 30107-3 PAD confirmation letters — https://www.ibeta.com/iso-30107-3-presentation-attack-detection-confirmation-letters/
10. Minivision — Silent-Face-Anti-Spoofing — https://github.com/minivision-ai/Silent-Face-Anti-Spoofing