# Leitfaden zur Sanktionsprüfung: Wie Compliance wirklich funktioniert > Erfahren Sie, wie Sanktionsprüfung funktioniert – von der Abgleichlogik bis zu Fehlalarmen – mit praktischen Hinweisen für Finanzteams, die 2026 eine risikobasierte Compliance aufbauen. Source: https://www.electe.net/de/beitrag/sanctions-screening Site guide: https://www.electe.net/de/llms.txt Die Sanktionsprüfung hat aufgehört, eine einmal täglich durchzuführende Checkliste zu sein, seit große kommerzielle Datenbanken damit begonnen haben, Sanktionsdaten mehrmals täglich über Dutzende bis Hunderte offizieller Listen hinweg zu aktualisieren. LexisNexis gibt an, dass die Abdeckung **180 globale Sanktionslisten** sowie **1.700 Durchsetzungsquellen und Gerichtsakten** umfasst, mit Aktualisierungen bis zu **vier Mal täglich innerhalb von 24 Stunden nach Veröffentlichung der Quelle** ([LexisNexis WorldCompliance Data](https://risk.lexisnexis.com/products/worldcompliance-data)). Dieser Umfang verändert die Aufgabe. Analysten prüfen nicht mehr statisch eine Liste nach einem Namen, sondern führen eine kontinuierliche Kontrolle über Kunden, Gegenparteien, Zahlungen und Eigentümerwechsel durch, und diese muss schnell genug ablaufen, um eine problematische Transaktion vor der Abwicklung zu stoppen. Der Fehler, den viele Teams machen, besteht darin, die Sanktionsprüfung nur als Abgleichproblem zu behandeln. Die schwerwiegenderen Fehler beginnen meist früher, bei unsauberen Daten, unvollständigen Eigentümerketten und Listen-Feeds, die sich nicht sauber einlesen lassen. Eine Warteschlange voller Alarme, die wichtig wirken, es aber nicht sind, oder ein echter Treffer, der zu spät eintrifft, um noch relevant zu sein, deutet meist auf eine schwache Datenintegrität hin, nicht nur auf eine schwache Engine. Die Kontrolle ist immer nur so gut wie ihre Eingaben. In der Praxis werden die besten Programme von Menschen entwickelt, die sowohl die Regeln als auch die Daten verstehen. ## Inhaltsverzeichnis - Was Sanktionsprüfung tatsächlich ist - Das regulatorische Umfeld und warum es wichtig ist - Wie Abgleich-Engines im Hintergrund funktionieren - - Normalisierung kommt zuerst - Scoring misst wahrscheinliche Treffer - Entscheidungen hängen von Schwellenwerten ab - Fehlalarme und das Problem der Datenintegrität - - Sekundäre Identifikatoren leisten die Hauptarbeit - Fehlerhafte Eingaben erzeugen verrauschte Ergebnisse - Eigentümerstrukturen, Aliase und regimeübergreifende Komplexität - - Warum Aliase genauso wichtig sind wie Namen - Prüfungen innerhalb eines einzigen Regimes lassen Lücken - Wo ELECTE in einen Compliance-Stack passt - Wichtige Erkenntnisse und eine praktische Checkliste - Häufig gestellte Fragen zur Sanktionsprüfung ## Was Sanktionsprüfung tatsächlich ist Sanktionsprüfung ist der Prozess, bei dem **Kunden-, Gegenpartei- und Transaktionsdaten** mit konsolidierten Sanktions- und Durchsetzungslisten abgeglichen werden, damit ein Institut entscheiden kann, ob eine Aktivität freigegeben, überprüft oder blockiert wird. Diese Listen stammen in der Regel von Stellen wie **OFAC**, der **EU**, dem **UK OFSI** und den **UN**, sowie von nationalen Behörden und Durchsetzungsprotokollen. Der Zweck besteht nicht nur darin, exakte Namensübereinstimmungen zu finden. Es geht darum, verbotene Risikopositionen frühzeitig genug zu erkennen, um Onboarding, Zahlungen, Handelsströme oder eigentümerbezogene Risiken zu stoppen. Auf praktischer Ebene betrachtet die Kontrolle Identifikatoren wie **Name, Geburtsdatum, Nationalität, Adresse, Ausweisnummern und wirtschaftlich Berechtigten**. Ein sauberes Ergebnis bedeutet, dass die Partei fortfahren kann, ein möglicher Treffer geht zur Überprüfung, und ein bestätigter Treffer löst je nach Richtlinie eine Eskalation oder Blockierung aus. Diese Ausgabelogik ist wichtig, weil sie den Analysten mitteilt, welche Maßnahme zu ergreifen ist, nicht nur, was die Engine bemerkt hat. > **Praktische Regel:** Wenn sich Ihr Prüfungsergebnis nicht in einfachen Worten erklären lässt, ist Ihr Prozess zu fragil für einen Prüfer oder Wirtschaftsprüfer. Der tiefere Punkt ist folgender: Viele Fehler, die wie Abgleichfehler aussehen, sind in Wirklichkeit **Fehler der Datenintegrität**. Ein Name kann in einem System korrekt sein und in einem anderen fehlerhaft, eine Eigentümerkette kann unvollständig sein, oder ein Feed kann veraltet sein, bis Ihre Engine ihn verarbeitet. Sobald man das versteht, wird die Kontrollfläche klarer, denn man optimiert nicht nur Software, sondern verwaltet die Datenqualität durchgängig. ## Das regulatorische Umfeld und warum es wichtig ist Die Sanktionsprüfung befindet sich genau an dem Punkt, an dem Politik zu operativer Kontrolle wird. US-Sanktionsvorschriften können zivilrechtliche Strafen, strafrechtliche Geldbußen und sogar Freiheitsstrafen bei vorsätzlichen Verstößen nach sich ziehen, weshalb Teams die Prüfung als Teil des täglichen Risikoworkflows behandeln, nicht als optionales Häkchen ([Tincheck OFAC-Verifizierung](https://tincheck.com/blog/ofac-verification/)). Öffentliche Zusammenfassungen von Durchsetzungsmaßnahmen zeigen zudem, dass Strafen und Vergleiche schnell ansteigen können, sodass schwache Kontrollen rasch teuer werden. Für einen Junior-Analysten lautet die Lehre daraus einfach: Wenn die Kontrolle vage ist, wird sie versagen, sobald das Dateivolumen oder die Ausnahmewarteschlange wächst. Das größere Problem ist der Umfang. OFACs **50-Prozent-Regel** behandelt eine Einheit als blockiert, wenn blockierte Personen direkt oder indirekt in der Summe **50 Prozent oder mehr** davon besitzen, und eine Einheit kann diesen automatischen Status verlieren, wenn der Anteil blockierten Eigentums nach einer Veräußerung unter diesen Schwellenwert fällt ([OFAC FAQ](https://ofac.treasury.gov/faqs/topic/1521)). Das bedeutet, dass die Eigentümerprüfung Teil der Sanktionsprüfung ist, nicht eine separate rechtliche Übung. Eine Einheit kann bei einer Namensprüfung unauffällig erscheinen und dennoch über ihre Eigentümer eine verbotene Risikoposition tragen. Wichtige Sanktionsregime und Screening-ErwartungenRegimeAusstellende BehördeZentrale Screening-ErwartungOFACUS-FinanzministeriumNamen und Eigentumsverhältnisse prüfen, einschließlich kumulierter gesperrter Eigentumsanteile und zeitnaher Übernahme neuer ListenEU-RahmenwerkEuropäische UnionAbgleich mit konsolidierten Listungen und eigentumsbezogener ExpositionUK OFSIBritisches FinanzministeriumNamen, Aliasnamen und Eigentumsexposition gemäß den britischen Sanktionsvorschriften prüfenUN-SanktionenUN-SicherheitsratAbgleich mit UN-Listungen und zeitnahe Aktualisierung der Arbeitsabläufe Die Kontrolle muss auch zu der Art passen, wie Aufsichtsbehörden erwarten, dass Fälle bearbeitet werden. Die Zentralbank der VAE gibt vor, dass ein potenzieller Treffer zunächst gesperrt und anschließend durch Abgleich sekundärer Identifikatoren wie Geburtsdatum und Adresse mit den Sanktionslistendaten aufgelöst werden soll; ein Falschtreffer kann freigegeben werden, wenn keine weiteren verdächtigen Aktivitäten vorliegen ([Leitlinien der Zentralbank der VAE zu Falschtreffern](https://rulebook.centralbank.ae/en/rulebook/35-verification-false-positives)). Das ist dieselbe grundlegende Disziplin, die Prüfer auch andernorts erwarten: den Datensatz vergleichen, den Grund dokumentieren und die Entscheidung nachvollziehbar halten. Ein ähnlicher Ansatz zeigt sich bei einer [strafrechtlichen Hintergrundüberprüfung für Freiwillige](https://www.volunteerbadge.com/volunteer-criminal-background-check), bei der der Identitätsabgleich und die dokumentierte Entscheidung genauso wichtig sind wie der ursprüngliche Alarm. Die praktische Erkenntnis lautet: Screening-Fehler sind oft Datenintegritätsfehler. Ein Name kann mit fehlerhafter Transliteration ankommen, eine Eigentümerkette kann unvollständig sein, oder ein Eingangsfeed kann veraltet sein, bevor die Engine ihn überhaupt bewertet. In solchen Fällen liegt das Problem nicht allein in der Abgleichlogik. Es liegt an der Qualität der Daten, die Sie eingespeist haben, und genau dort sollte die operative Entscheidung ansetzen. ## Wie Matching-Engines im Hintergrund funktionieren Eine Screening-Engine erledigt in der Regel drei Schritte nacheinander. Zunächst normalisiert sie die Daten. Dann bewertet sie die Ähnlichkeit. Schließlich wendet sie eine Entscheidungsregel an. Das klingt einfach, aber jeder Schritt existiert, weil reale Namen unübersichtlich sind. ### Zuerst kommt die Normalisierung Die Normalisierung entfernt vermeidbare Unterschiede, damit die Engine den inhaltlichen Kern eines Datensatzes vergleichen kann statt seiner Formatierung. Das bedeutet: Kleinschreibung, Entfernen von Leerzeichen, Transliteration von Schriftsystemen, Entfernen von Stoppwörtern und Aufteilung von Namen in Vor- und Nachnamen-Token. Ohne diesen Schritt können „Mohammed Al-Rashid“ und „Muhammad al Rashid“ unterschiedlicher wirken, als sie tatsächlich sind. ### Die Bewertung misst wahrscheinliche Treffer Nach der Normalisierung nutzt die Engine Fuzzy-Matching-Methoden wie **Levenshtein**, **Jaro-Winkler** und **Metaphone** oder **Double-Metaphone**, um Ähnlichkeitswerte zu vergeben. Eine tokenbasierte Bewertung funktioniert bei mehrteiligen Namen in der Regel besser als eine Bewertung des gesamten Strings, da sie die relevanten Bestandteile gewichten kann, anstatt den gesamten Namen als eine einzige, fragile Einheit zu behandeln. Deshalb kann ein Name mit vertauschten Token oder einem fehlenden Artikel trotzdem als Prüffall auftauchen. ### Entscheidungen hängen von Schwellenwerten ab Der letzte Schritt ist die Schwellenwertlogik. Ein konfigurierbarer Score-Grenzwert, kombiniert mit einer stärkeren Gewichtung hochwertiger Identifikatoren wie **Geburtsdatum, Land und Ausweisnummer**, führt zu einer klaren Entscheidung: Freigabe, Prüfung oder Treffer. Die zentrale Herausforderung besteht darin, diese Schwellenwerte auf das eigene Portfolio abzustimmen, denn ein Standardwert des Anbieters, der bei einer Population funktioniert, kann sich bei einer anderen ungünstig verhalten. Für eine tiefergehende, geschäftsorientierte Betrachtung der automatisierten Mustererkennung siehe [**ELECTE su ML per business**](https://www.electe.net/post/algoritmi-di-machine-learning). > Die Engine ist nur so gut wie die Daten, die Sie ihr zuführen. Wenn vorgelagerte Datensätze fehlerhaft sind, muss selbst das beste Scoring-Modell der Welt noch raten. ## Falsch-Positive und das Problem der Datenintegrität Falsch-positive Treffer deuten auf ein Programm hin, das sich zu stark auf ungenaue Abgleichslogik oder schwache Ausgangsdaten stützt. Branchenberichte, die im Brief zitiert werden, sprechen davon, dass rund **95 bis 99 Prozent** aller Sanktions-Screening-Alerts falsch-positiv sind, was bedeutet, dass nur etwa **1 bis 5 Prozent** echte Treffer sind, die eskaliert werden müssen ([Ionova false positives](https://ionova.ai/blog/sanctions-false-positives)). Deshalb löst das Hinzufügen weiterer Prüfer das Problem nur selten. Wenn die Warteschlange verrauscht ist, verbringen Mitarbeiter weiterhin Zeit damit, Datensätze zu klären, die nie riskant waren. Ein besserer Weg, die Alert-Warteschlange zu betrachten, besteht darin, sie wie eine Datenqualitätsprüfung zu behandeln. Eine Screening-Engine kann Identitäten nicht gut abgleichen, wenn der Eingabedatensatz unvollständig, inkonsistent oder schlecht formatiert ist. In der Praxis lautet die erste Frage oft, ob die Daten überhaupt sauber genug ins System eingegeben wurden, damit der Abgleich funktionieren kann. Für einen breiteren Blick auf Datenqualität ist [Datenvalidierung](https://www.electe.net/post/data-validation-techniques) ein nützlicher interner Referenzpunkt, um über Validierung vor dem Abgleich nachzudenken. ### Sekundäre Identifikatoren leisten die eigentliche Arbeit Sekundäre Identifikatoren trennen einen echten Treffer von einer bloßen Ähnlichkeit. Vor- und Nachname allein sind schwache Signale. Kommen Geburtsdatum, Land oder Ausweisnummer hinzu, lässt sich die Prüfung leichter rechtfertigen, weil der Analyst eine weitere Möglichkeit hat, die Identität zu verifizieren. ### Fehlerhafte Eingaben erzeugen verrauschte Ergebnisse Zusätzliche Leerzeichen, diakritische Zeichen, abgeschnittene Zahlungsfelder und Transliterationsvarianten füttern alle die Rauschmaschine. Eine perfekte Engine kann keine Informationen wiederherstellen, die nie angekommen sind, und ein statischer Schwellenwert kann Daten nicht korrigieren, die systemübergreifend inkonsistent erfasst wurden. Deshalb ist das Testen gegen eine gelabelte Population wichtiger, als einer glänzenden Demo zu vertrauen. Eine sinnvolle Gewohnheit ist es, dieselbe Warteschlange unter mehreren Datenbedingungen zu testen, nicht nur bei exakten Namensübereinstimmungen. - **Feldqualität bei der Erfassung prüfen:** Stellen Sie sicher, dass Namen, Adressen und Ausweisdaten vollständig ankommen und nicht durch Beschränkungen des Quellsystems abgeschnitten werden. - **Mit bekannten Varianten vergleichen:** Beziehen Sie Transliterationen und Unterschiede bei Leerzeichen in Ihr Testset ein. - **Schwellenwertverhalten überprüfen:** Beobachten Sie, wie sich die Alert-Volumina ändern, wenn Sie jeweils ein Feld anpassen. - **Entscheidungslogik dokumentieren:** Halten Sie fest, warum ein Fall abgeschlossen wurde, nicht nur dass er abgeschlossen wurde. ## Eigentümerschaft, Aliase und regimeübergreifende Komplexität Modernes Sanktions-Screening scheitert, wenn Teams es nur als Namensabgleich behandeln. Eigentümerschaft kann Risiken erzeugen, selbst wenn die blockierte Person nicht die direkte Gegenpartei ist. OFACs **50-Prozent-Regel** macht das in ihren Leitlinien zu indirekter Eigentümerschaft und Blockierungsrisiken deutlich. Ein sauberer Kundendatensatz kann dennoch innerhalb einer blockierten Eigentümerkette liegen, weshalb Analysten prüfen müssen, wer die Einheit kontrolliert, nicht nur, wie die Einheit heißt ([OFAC FAQ](https://ofac.treasury.gov/faqs/topic/1521)). ### Warum Aliase genauso wichtig sind wie Namen Die Abdeckung von Aliasen unterscheidet ein eng gefasstes Programm von einem, das einer Prüfung standhält. Menschen ändern ihre gesetzlichen Namen, wechseln zwischen Schriftsystemen, verwenden transliterierte Schreibweisen oder handeln über Einheiten, die unter anderen Namen auftreten. Wenn eine Screening-Datei diese Varianten ausschließt, kann die Kontrolle vollständig wirken, obwohl gerade die Datensätze fehlen, die am ehesten falsch interpretiert werden. ### Prüfungen mit nur einem Regime hinterlassen Lücken Der Auszug aus den Branchenrichtlinien besagt, dass Befragte **Datenqualität (26,85 %)** vor **Komplexität wirtschaftlichen Eigentums (16,11 %)** und **regimeübergreifende Compliance (14,77 %)** einstuften ([AML Watcher Sanktions-Leitfaden](https://amlwatcher.com/blog/ofac-ofsi-eu-un-sanctions-screening-guide/)). Das deutet ebenso auf ein Datenproblem wie auf ein Richtlinienproblem hin. Ein Programm, das um eine einzige Listenfamilie herum aufgebaut ist, lässt sich einfacher betreiben, kann aber Risiken übersehen, wenn derselbe Kunde, dieselbe Zahlung oder Gegenpartei mehr als ein Sanktionsuniversum berührt. Vergleich: Screening mit einem Regime vs. mehreren RegimenScreening mit einem RegimeKonsolidiertes Multi-Regime-ScreeningAbdeckungEng, an eine Listenfamilie gebundenBreitere Abdeckung über die wichtigsten Regime hinwegOwnership-LogikOft schwach oder manuellBesser geeignet für Ketten wirtschaftlichen EigentumsUmgang mit AliasnamenUneinheitlichIn der Regel vollständiger und dedupliziertOperatives RisikoÜbersieht grenzüberschreitende ExponierungBesser an die globale operative Realität angepasst Die operative Entscheidung ist eindeutig. Wenn Ihr Geschäft grenzüberschreitend tätig ist, geschichtete Eigentumsstrukturen nutzt oder Entitäten mit komplexer Herkunft onboardet, sollte Screening auf Basis von Ownership-Graphen verpflichtend sein, nicht optional. Ist Ihr Fußabdruck lokal und einfach, braucht die Akte dennoch eine dokumentierte, risikobasierte Begründung dafür, was Sie bewusst nicht gescreent haben. ## Wo ELECTE in einen Compliance-Stack passt Eine Screening-Engine entscheidet, ob ein Datensatz ein Treffer ist. Eine Datenanalyse-Schicht hilft Ihnen nachzuweisen, dass die Kontrolle über die Zeit funktioniert. Dieser Unterschied ist wichtig, weil Prüfer nicht nur wissen wollen, dass Alerts existieren – sie wollen Belege dafür, dass das Programm wirksam, konsistent und governance-konform ist. Analytics kann Alert-Entscheidungen aggregieren, Falsch-Positiv-Muster nach Geschäftsbereich messen und zeigen, ob Listenaktualisierungen sauber übernommen werden. Sie kann auch helfen, Fälle zu erkennen, in denen Transaktionsüberwachungsdaten und Screening-Ergebnisse widersprüchlich sind – genau dort verstecken sich oft übersehene Treffer. So eingesetzt, wird Analytics zum Bindeglied zwischen Betrieb, Testing und Audit. > **Best Practice:** Behandeln Sie Screening-Alerts als Beweismittel, nicht nur als Workflow-Elemente. Werden sie konsistent protokolliert, können sie Trendanalysen, Stichprobenprüfungen und Kontrolltests unterstützen. Für Teams, die diese Governance-Schicht aufbauen, ist [**ELECTE data governance**](https://www.electe.net/compliance) die passendste Lösung für dieses Betriebsmodell, da sie darauf ausgerichtet ist, Nachweise strukturiert, überprüfbar und analysebereit zu halten. Der eigentliche Mehrwert liegt in der Messbarkeit. Wenn Sie Trefferquoten, Bearbeitungszeiten und Abdeckungslücken teamübergreifend nachverfolgen können, hört Sanktions-Screening auf, eine Black Box zu sein, und wird zu einer Kontrolle, die Sie verbessern können. Das erleichtert Prüfungen, gibt der Führungsebene aber auch einen klareren Blick darauf, wo das Programm stark ist und wo es Risiken durchlässt. ## Kernaussagen und eine praktische Checkliste Die wichtigste Lehre ist, dass **Sanktions-Screening zuerst ein Problem der Datenintegrität und erst zweitrangig ein Matching-Problem ist**. Sind die Eingangsdaten unsauber, der Listen-Feed veraltet oder die Eigentumskette unvollständig, gerät selbst eine starke Engine an ihre Grenzen. Schwellenwerte, Identifikatoren und Governance zählen mehr als das reine Alert-Volumen. Nutzen Sie diese Checkliste als praktisches Maßnahmenpaket, nicht als Grundsatzpapier: 1. **Behandeln Sie die Datenerfassung als Kontrolle.** Überprüfen Sie, dass Namen, Adressen, IDs und Eigentumsdaten unverändert aus jedem Quellsystem ankommen. 2. **Passen Sie Schwellenwerte an Ihr Portfolio an.** Testen Sie nach Änderungen der Population neu, statt sich auf Anbieter-Standardwerte zu verlassen. 3. **Reichern Sie mit sekundären Identifikatoren an.** Machen Sie Geburtsdatum, Land und ID-Nummer zum Teil der Prüflogik. 4. **Prüfen Sie bei Onboarding und bei Zahlung.** Gehen Sie nicht davon aus, dass eine Prüfung den gesamten Lebenszyklus abdeckt. 5. **Erfassen Sie indirektes Eigentum.** Dokumentieren Sie, wie Sie die **50-Prozent-Regel** und die zugehörige Eigentumslogik anwenden. 6. **Aktualisieren Sie Listen zeitnah.** Stimmen Sie die Übernahme von Listen mit Ihrem operativen Risiko und Ihrem Aktualisierungsrhythmus ab. 7. **Verfolgen Sie die Bearbeitungszeiten von Fehlalarmen.** Langsame Prüfzyklen sind ein Kontrollproblem, nicht nur ein Betriebsthema. 8. **Bewahren Sie Prüfnachweise auf.** Speichern Sie die Logik, die Datenpunkte und die endgültige Entscheidung für jeden Fall. 9. **Testen Sie Transliterationspfade.** Beziehen Sie arabisch-lateinische und andere Namensvarianten in Validierungsstichproben ein. 10. **Überprüfen Sie Lücken in der Listenabdeckung.** Prüfen Sie, ob ein Regime oder eine Quellenfamilie blinde Flecken hinterlässt. 11. **Weisen Sie die Kontrollverantwortung zu.** Benennen Sie einen fachlichen Verantwortlichen, nicht nur einen technischen. 12. **Testen Sie nach Änderungen erneut.** Jede neue Liste, jedes neue Feld oder jede Verschiebung der Population sollte eine Kontrollüberprüfung auslösen. ## Häufig gestellte Fragen zum Sanktions-Screening Wie oft sollten Watchlists aktualisiert werden? So oft wie es Ihr operatives Risiko erfordert, aber die verifizierten Daten des Berichts zeigen, dass große kommerzielle Datenbanken inzwischen mehrmals täglich aktualisieren, wobei LexisNexis bis zu **vier Aktualisierungen täglich innerhalb von 24 Stunden nach Veröffentlichung der Quelle** angibt ([LexisNexis WorldCompliance Data](https://risk.lexisnexis.com/products/worldcompliance-data)). Wenn eine Feed-Aktualisierung fehlschlägt, setzen Sie die betroffene Screening-Abhängigkeit aus, protokollieren Sie den Vorfall und wenden Sie Ihren dokumentierten Ausweichprozess an, damit Sie nachweisen können, dass kein veralteter Feed blind verwendet wurde. Wie validiert man Fuzzy-Matching-Schwellenwerte, ohne zu überanpassen? Verwenden Sie einen gekennzeichneten Validierungsdatensatz, der exakte Treffer, Transliterationen, Abstandsvarianten und echte Negativfälle enthält, und testen Sie nach Änderungen der Liste oder der Kundenpopulation erneut. Passen Sie das Modell nicht nur an die alte Warteschlange an, denn das kann dazu führen, dass es bei historischen Fällen gut aussieht, aber neue Muster übersieht. Wie geht das Eigentums-Screening mit Schwellenwerten von 50 Prozent plus in der Summe um? Im OFAC-Modell lautet die entscheidende Prüfung, ob eine oder mehrere gesperrte Personen zusammengerechnet **50 Prozent oder mehr** besitzen, direkt oder indirekt ([OFAC FAQ](https://ofac.treasury.gov/faqs/topic/1521)). Das bedeutet, Sie benötigen Eigentumsdaten, nicht nur Namensdaten, sowie eine Möglichkeit, indirekte Beteiligungen über Tochtergesellschaften und verbundene Unternehmen nachzuverfolgen. Was ist der Unterschied zwischen Transaktions-Screening und Kunden-Screening? Das Kunden-Screening prüft die Beziehung beim Onboarding und bei Änderungen im Lebenszyklus. Das Transaktions-Screening prüft das Zahlungs-, Überweisungs- oder Handelsereignis selbst und kann so Risiken erkennen, die erst nach Eröffnung des Kontos auftreten. Welche Prüfnachweise erwarten Aufsichtsbehörden? Sie erwarten in der Regel das Regelwerk, die Dateneingaben, den Bearbeitungsverlauf, die Begründung der Schwellenwerte und den Nachweis, dass Sie die Kontrolle nach einem risikobasierten Zeitplan getestet haben. Wenn Sie nicht zeigen können, wie ein Treffer aufgelöst wurde, ist die Kontrolle schwerer zu verteidigen. Wann sollte ein Namensabgleich eskaliert statt automatisch freigegeben werden? Geben Sie nur dann automatisch frei, wenn die sekundären Identifikatoren und Ihre dokumentierte Richtlinie dieses Ergebnis stützen. Wenn die Identifikatoren unvollständig, widersprüchlich oder von geringer Qualität sind, eskalieren Sie den Fall und bewahren Sie den Entscheidungsverlauf auf. --- Sanktions-Screening funktioniert am besten, wenn Sie es als lebendige Kontrolle behandeln, nicht als statischen Filter. ELECTE hilft Teams, Alarmdaten, Eigentumsnachweise und Prüfergebnisse in klare Analysen umzuwandeln, die Tests und Governance unterstützen. Wenn Sie einen messbareren Weg suchen, um Compliance-Abläufe zu steuern, besuchen Sie [ELECTE](https://www.electe.net) und sehen Sie, wie die Plattform Ihnen helfen kann, unübersichtliche Kontrolldaten in vertretbare Entscheidungen zu verwandeln.