Compliance
Operative Compliance-Workflows · Web UI · API · MCP
Compliance Platform
Handels- und Sanktionsprüfung mit Nachweisen.
CN / TARIC
Sanktionslisten
Screening Cases
ISO 20022 Zahlungen
API + MCP
Nicht mit der Europäischen Kommission verbunden. Kein Ersatz für offizielle Quellen oder Entscheidungen zuständiger Behörden.
v7 · September 2026
02 · Herausforderung
Das Schwierige ist nicht das Screening. Es ist, das Ergebnis zu verteidigen.
Compliance-Arbeit scheitert, wenn eine Antwort nicht reproduzierbar, nicht belegbar und nicht für einen Prüfer nachvollziehbar ist.
- Sanktionslisten, TARIC-Maßnahmen und Unternehmensregister verteilen sich auf Dutzende von Regulatoren. Sie manuell zusammenzuführen kostet wertvolle Zeit der Prüfer.
- Die meisten Tools liefern ein Ja/Nein-Ergebnis. Prüfer brauchen den Link zur Quelle, den Zeitstempel und die Begründung des Bearbeiters.
- Aliase, Transliterationen und lokale Namensvarianten verwandeln einen sauberen „kein Treffer" heute in einen versäumten Treffer morgen.
- TARIC-Prüfungen, Unternehmensprüfungen und Schiffsverifizierungen sammeln sich in Tabellen und E-Mails – nicht als ein einziger prüffähiger Fall.
- Wenn ein Tool einen Treffer markiert, sehen Prüfer nicht immer, warum. Das macht die Entscheidung im Audit schwer zu verteidigen.
- Entwickler, die interne Automatisierung aufbauen, müssen meist dieselbe Oberfläche scrapen, die Compliance-Teams nutzen.
Audit-Nachweis-Lücke
1
Viele offizielle Quellen
Sanktionslisten, TARIC-Maßnahmen, Unternehmensregister
2
Manuelle Zusammenführung
Tabellen, Screenshots, E-Mail-Verkehr
?
Entscheidung im Audit
„Wo ist der Nachweis?"
Ein verteidigungsfähiges Ergebnis hält Daten, Quelle, Parameter, Bearbeiter und Zeit zusammen.
03 · Zielgruppe + Positionierung
Compliance-Tools wurden für Tier-1-Banken entwickelt. Compliance-Arbeit findet überall sonst statt.
Dasselbe regulatorische Risiko erreicht jetzt Teams ohne eigene Compliance-Abteilung.
- Compliance-Tools entstanden nach dem 11. September und reiften in Banken und Big-Four-Beratungen. Sie kosten und konfigurieren sich noch immer entsprechend.
- Derselbe regulatorische Druck, ein viel breiteres Feld: multinationale Konzerne, Regional- und KMU-Banken, Logistikunternehmen, Zollagenten, regionale Flughäfen, polizeiliche Einsatzgruppen, Notare und kommunale Dienste.
- Diese Teams haben keine eigene Compliance-Abteilung. Die Arbeit liegt bei Operations, der Rechtsabteilung oder der Geschäftsleitung – neben dem Tagesgeschäft.
- Sie brauchen ebenso verteidigungsfähige Prüfungsnachweise wie eine Tier-1-Bank – können aber keine sechsstellige Lizenz oder eine sechsmonatige Integration rechtfertigen.
- Sie brauchen Zugang dort, wo sie arbeiten: ein Web-Tool für den Juristen, eine API für den Entwickler, einen MCP-Server für den KI-Agenten.
- Der Compliance-Long-Tail ist um Größenordnungen größer als der Banken-/Big-Four-Kern – dasselbe regulatorische Risiko, viel weniger Werkzeuge, kein ernstzunehmender Anbieter, der ihn bedient.
Der Compliance-Long-Tail
Banken- / Big-Four-Kern
Multinationale Konzerne
Regional- & KMU-Banken
Logistikunternehmen
Zollagenten
Regionalflughäfen
Polizei-Einsatzgruppen
Notare
Kommunale Dienste
Derselbe Druck. Viel weniger Werkzeuge. Kein ernsthafter Anbieter für die ganze Breite.
04 · Hauptfunktionen
Verteidigungsfähige Compliance – ohne eigene Compliance-Abteilung.
Tägliche Screening-Vorgänge werden zu nachweisbereiten Entscheidungen.
- Eine quellverknüpfte Antwort auf die Frage „Darf das versendet, verarbeitet oder abgewickelt werden?" – über TARIC/CN-Maßnahmen, Sanktionen und Unternehmensregister hinweg, nicht in drei getrennten Tools.
- Verteidigungsfähige Nachweise als Nebenprodukt der Arbeit. Jede gespeicherte Prüfung wird automatisch mit Zeitstempel, Quellenverweis und Bearbeiter versehen – keine separate Audit-Vorbereitung nötig.
- Erkennen Sie, was manuelle Prüfungen übersehen. Alias-Treffer, Transliterationsvarianten und lokale Namensmuster bringen Kandidaten zutage, die ein Ja/Nein-Scan überspringen würde.
- Vom Register statt nur vom Namen starten. Unternehmen aus unterstützten lettischen, estnischen, polnischen oder kasachischen Registerdaten laden. Soweit der amtliche Datensatz Organe oder Eigentümer ausweist, diese Parteien mitprüfen.
- Prüffähige Nachweise im Arbeitsablauf erzeugen. Gespeicherte Fälle halten Zeitstempel, Quellenlinks, Parameter, Ergebnisse und Prüferkontext zusammen.
- Starten Sie heute im Arbeitsbereich. Keine sechsstellige Mindestsumme, keine sechsmonatige Integration, keine Compliance-Abteilung als Voraussetzung.
Status, aktivierte Dienste und letzte Prüfungen in einer Ansicht.
05 · Kanäle
Drei Oberflächen, eine Quelle der Wahrheit.
Prüfer, Entwickler und KI-Agent nutzen darunter dieselben Daten.
- Web UI – die vollständige Screening-Oberfläche für die direkte Nutzung durch Prüfer. Dieselben Daten, dieselben Nachweise, derselbe Nachweispfad wie in den anderen Kanälen.
- API – REST-Endpunkte für unterstützte Integrations-Workflows. Auf Self-Service-Tarifen ist der Kanal ein kostenpflichtiges Add-on; bei Enterprise ist er enthalten.
- MCP Server – stellt Screening-Workflows als native Tools für KI-Agenten bereit. Jeder MCP-kompatible Client (Claude, ChatGPT Agents, eigenentwickelt) kann Prüfungen aufrufen und quellverknüpfte Nachweise erhalten.
- Ein Prüfpfad bei Speicherung. Web, API und MCP können dasselbe Screening-Case-Artefakt anlegen; schnelle Einzelprüfungen bleiben bewusst temporär.
- Gemeinsamer Kern. Alle drei Kanäle nutzen dieselbe Kernprüfung und denselben Quellenkatalog. Berechtigungen, Speicherung und Ausgabe bleiben kanalspezifisch.
- Klare Berechtigungen. MCP ist innerhalb der Tariflimits enthalten; REST-API-Zugriff ist ein Add-on oder Bestandteil von Enterprise.
Ökosystem
REST API
Interne Automatisierung
Vereinheitlichte Daten
Sanktionen · TARIC · Close-Match
Ein Nachweispfad
Screening Cases Register
Gemeinsame Kernprüfung; gespeicherte Prüfungen nutzen das gemeinsame Fallartefakt.
06 · TARIC / CN-Code-Prüfungen
Eine Abfrage, alle anwendbaren Maßnahmen, mit Quellenverweis.
Datum-bewusste Prüfungen bewahren die Eingaben auf, die das Ergebnis erzeugt haben.
- Geben Sie ein, was eine Zollanmeldung braucht: den CN/TARIC-Code, das Bestimmungsland, das relevante Datum. Optionale Eingrenzung – Maßnahmenart, Zusatzcodes.
- Zwei Ebenen in einem Bericht: ein Sanktionsanhang-Hinweis (falls anwendbar) plus das volle TARIC-Maßnahmenbild – mit Verordnungsverweis, Datumsbereich und Bedingungsdefinitionen.
- Jede Maßnahme verweist auf ihre Quelle – die EU-Verordnung oder den TARIC-Datenbankeintrag. Prüfer und Auditoren sehen die Begründung, nicht nur das Urteil.
- Datum-bewusste Abfragen. Reproduzieren Sie eine Prüfung zu einem beliebigen früheren Datum mit dem damaligen regulatorischen Stand.
- Gespeicherte Parameter reisen mit den Ergebnissen. Die Eingaben, die eine Prüfung erzeugt haben, bleiben neben der Ausgabe – keine Lücken im Nachweispfad.
- Eine ganze Anmeldung auf einmal. Prüfen Sie alle Positionen einer Zollanmeldung in einem Lauf statt Code für Code und erhalten Sie einen einzigen Nachweisbericht für alle.
07 · Sanktionsprüfung
150+ offizielle Quellen. Jedes Ergebnis ist mit Nachweisen verknüpft.
Offizielle Quellen sind durchsuchbar und mit dem jeweiligen Primärdatensatz verknüpft.
- Was geprüft wird. Namen – Personen, Unternehmen, Schiffe, Luftfahrzeuge – zusammen mit Aliasen, lokalen Namensvarianten, Transliterationen, Geburtsdaten und Kennungen (Pass, IMO, BIC, Registriernummern).
- Wogegen geprüft wird. Ein Katalog mit 150+ offiziellen Quellen: Sanktionen, PEP/EDD, Ausschluss, Exportkontrolle, maritime Risiken, aufsichtsrechtliche Warnlisten, Unternehmensregister und Zollreferenzen.
- Match-Logik erkennt, was die manuelle Prüfung übersieht. Aliase, Transliterationen, phonetische Entsprechungen und lokale Namensmuster werden neben exakten Treffern bewertet. Der Schwellenwert ist pro Prüfung konfigurierbar.
- Jeder Treffer kommt mit seiner Quelle. Jeder Treffer verweist auf den Ursprungseintrag der Liste – Listenname, Programm, Verordnungsverweis, Listungsgründe. Der Prüfer sieht Nachweise, nicht nur ein Urteil.
- Auch Sanktionen auf Warenebene. Derselbe Workflow prüft CN/TARIC-Codes gegen warenbezogene Sanktionsanhänge (z. B. RU-VO 833/2014 ANHANG XXIII), sodass eine Unternehmensprüfung und eine Warenprüfung im selben Fall landen.
- Reference Library: Filter nach Programm, Typ, Land und Quelle.
Datenabdeckung · 14 Beispiele aus dem Katalog mit 150+
| Offizielle Quelle | Behörde |
|---|
| OFAC SDN | USA |
| EU FSF | Europäische Union |
| EU Russia (Reg. 833/2014) | Europäische Union |
| EU Belarus (Reg. 765/2006) | Europäische Union |
| UN SC Consolidated | Vereinte Nationen |
| UK Sanctions List | Vereinigtes Königreich |
| CH SECO | Schweiz |
| JP MOF | Japan |
| AU DFAT | Australien |
| CA SEMA | Kanada |
| LV FID | Lettland |
| LV FID frozen-assets | Lettland |
| PL MSWiA | Polen |
| UA NSDC | Ukraine |
Für jeden Workflow wird das relevante Quellenprofil gewählt. Aktualisierungsrhythmus und Freshness-Nachweise folgen dem offiziellen Herausgeber.
08 · ISO 20022 Zahlungsprüfung
Pre-Flight-Prüfung für pain.001 und pacs.008.
Der Parser extrahiert die im Dokument vorhandenen Parteien; ein gespeicherter Fall hält Rohdaten und Nachweise zusammen.
- Vollständige Nachricht. pain.001-/pacs.008-XML wird wie übergeben verarbeitet. Beim Anlegen eines PaymentCase werden Roh-XML, SHA-256, Metadaten und Warnungen gespeichert.
- Explizite Validierung. Strukturprüfungen laufen immer. Der XSD-Status lautet valid, invalid oder not configured; eine ungültige konfigurierte XSD erzeugt einen Integrity Error.
- Rollenbasierte Teilnehmer. Banken, Schuldner, Gläubiger und vorhandene Intermediäre werden getrennt extrahiert; fehlende Pflichtrollen werden gewarnt.
- Quellen nach Richtlinie. Jeder Teilnehmer wird mit dem für den Fall gewählten Quellenprofil geprüft, nicht pauschal mit dem gesamten Katalog.
- BIC-Auflösung mit Evidenz. Konfigurierte Resolver können den Rechtsnamen ergänzen; ungelöste Kennungen und Namenskonflikte bleiben sichtbar.
- Speicherung nach Wahl. Ein Schnelllauf ist temporär; ein PaymentCase speichert Teilnehmerergebnisse und Nachrichtennachweise.
Markenversprechen · case-as-audit
Der schwierige Teil ist nicht die Prüfung. Es ist die Verteidigung des Ergebnisses.
Ein gespeicherter PaymentCase hält XML-Hash, Validierungsstatus, extrahierte Teilnehmer, gewählte Richtlinie und Screening-Nachweise zusammen.
Der Prüfpfad entsteht beim Speichern als Fall; Einzelprüfungen bleiben getrennt und zeitlich begrenzt.
09 · ISO-20022-Teilnehmerrollen
Sechs Rollenklassen werden erkannt. Geprüft werden nur vorhandene Parteien.
pain.001 und pacs.008 enthalten unterschiedliche Ketten; jeder extrahierte Teilnehmer wird separat bewertet.
| # | Rolle | pain.001-Mapping | pacs.008-Mapping | Entität | Was geprüft wird |
|---|
| 1 | Sender Bank | DbtrAgt (implied initiation) | InstgAgt | Unternehmen | Initiierende oder instruierende Bank, sofern vorhanden. BIC und aufgelöster Name werden gemäß dem gewählten Quellenprofil geprüft. |
| 2 | Ordering Institution | DbtrAgt (Debtor Agent) | DbtrAgt (Debtor Agent) | Unternehmen | Der in der XML identifizierte Debtor Agent. Oft identisch mit Sender Bank — nicht immer. Separat geprüft. |
| 3 | Ordering Customer | Dbtr (Debtor) | Dbtr (Debtor) | Partei | Im XML vorhandene Schuldnerdaten. Name und verfügbare Kennungen werden zu Screening-Eingaben und Nachweisen. |
| 4 | Intermediary Banks | N/A | IntrmyAgt1 → IntrmyAgt[n] | Unternehmen | Korrespondenzkette. Oft unsichtbar für den Originator, aber materiell exponiert bei sanktionierten Korrespondenten. |
| 5 | Beneficiary Bank | CdtrAgt (Creditor Agent) | CdtrAgt (Creditor Agent) | Unternehmen | Die empfangende Institution. Das am häufigsten übersehene Ziel — fängt EU-Russland/Belarus unter Reg. 833/765. |
| 6 | Beneficiary | Cdtr (Creditor) | Cdtr (Creditor) | Partei | Im XML vorhandene Gläubigerdaten. Name und verfügbare Kennungen werden zu Screening-Eingaben und Nachweisen. |
Warum Rollen statt einer festen Zahl
pain.001 enthält üblicherweise keine Intermediärbank-Knoten; pacs.008 kann mehrere enthalten. Der Parser erfasst vorhandene Rollen und warnt bei fehlenden Pflichtrollen.
10 · Screening Cases — Alleinstellungsmerkmal
Speichern Sie Prüfungen, die einen Audit-Trail benötigen.
Das Entscheidungsartefakt, nicht nur das rohe Screening-Ergebnis.
- Die Arbeitseinheit von Compliance ist der Fall, nicht die Prüfung. Eine Transaktion, ein Kunde oder eine Sendung erzeugt viele Prüfungen – aber der Auditor sieht eine Entscheidung. Der Fall ist das Artefakt dieser Entscheidung.
- Persistente Workflows gehören in einen Fall. TARIC-, Sanktions-, Bank- und ISO-20022-Prüfungen können gemeinsam dokumentiert werden; Schnellprüfungen können temporär bleiben.
- Status steuert den Workflow. Fälle verwenden Open, Closed und Archived; Elemente verwenden Pending, Clear, Hit, Review oder Error mit Zeit- und Prüferkontext.
- Treffer erscheinen im Fall. Rote „Treffer"-Marker, quellverknüpfte Einträge, Bearbeiterhinweise – sichtbar im Fall-Kontext, nicht versteckt in einem separaten Alarm-Tool.
- Was uns unterscheidet. Die großen Datenanbieter liefern Screening-Ergebnisse. Compliance Platform liefert den Fall, zu dem sie gehören – das audit-fertige Artefakt.
- Später reproduzierbar. Öffnen Sie einen beliebigen Fall erneut, um die genauen Parameter, Treffer, Quellen und die Bearbeiterbegründung in dem Zustand zu sehen, in dem sie damals standen. Das Audit ist keine separate Aufgabe – der Fall ist das Audit.
ISO 20022
Zahlungsprüfung, fallfertig. pain.001-/pacs.008-XML einfügen, Teilnehmer und Validierungsstatus prüfen und den Lauf speichern, wenn ein dauerhafter Fall erforderlich ist.
Das Audit ist keine separate Aufgabe – der Fall ist das Audit.
11 · AI Assistant + MCP
Derselbe Nachweispfad. Jetzt für einen Agenten erreichbar.
Die Agenten-Schicht ist fundiert, zitierfähig und protokolliert – kein paralleler KI-Silo.
- Der AI Assistant ist quellenbasiert. Er ruft Plattform-Tools für TARIC, Sanktionen, Entitäten, Zahlungen und Fälle auf und trennt Tool-Nachweise von generierter Erklärung.
- MCP stellt dieselben Workflows externen Agenten zur Verfügung. Jeder MCP-kompatible Client – Claude, ChatGPT Agents, eigenentwickelt – kann Screening als natives Tool aufrufen und quellverknüpfte Nachweise erhalten.
- Nachweise bleiben zuordenbar. Tool-Ergebnisse enthalten Quellenlinks und Freshness-Kontext; eine generierte Zusammenfassung ersetzt den Primärdatensatz nicht.
- Speicherung ist ausdrücklich. Agenten können denselben Screening Case wie die Web UI anlegen; ein One-shot-Aufruf bleibt temporär, bis er gespeichert wird.
- Praktische Anwendung: Bearbeiterhinweise für mehrdeutige Treffer entwerfen, frühere Fälle zu einem Land oder Programm abrufen, Listen von Geschäftspartnern / Schiffen / Banken im Batch prüfen, Verordnungsbedingungen in einfacher Sprache zusammenfassen.
- Compliance-Käufer sind 2026 zu Recht KI-skeptisch. Die Agenten-Schicht der Plattform gewinnt Vertrauen, weil sie fundiert, zitiert und protokolliert ist – nicht durch die Behauptung „Vertrauen Sie uns, unsere KI ist anders".
Agenten-Intelligenz
AI Assistant
Abfrage im Kabinett
MCP Server
Externe Agenten
Indizierte Daten
Quellenbezogene Nachweise
Screening Cases
Derselbe Fall · dasselbe Audit
AI-Vertrauen entsteht durch zuordenbare Tool-Nachweise und ausdrückliche Speicherung, nicht durch unbelegte Automatisierungsversprechen.
12 · Status & Aufruf
Bereit für reale Compliance-Workflows.
Ein vollständiger Arbeitsbereich für Teams, die belastbares Screening ohne Enterprise-Aufwand benötigen.
- Zugang. Fordern Sie einen Arbeitsbereich an und starten Sie mit Ihrem ersten Workflow.
- Heute verfügbar. Keine sechsstellige Mindestsumme, keine sechsmonatige Integration und keine Compliance-Abteilung als Voraussetzung. Für Teams jeder Größe.
- Im Zugang enthalten. Web UI und MCP innerhalb der Tariflimits, quellenbasierte Prüfungen, TARIC-Maßnahmen, Screening Cases und Audit-Trail. REST API ist ein Add-on bei bezahlten Self-Service-Tarifen und bei Enterprise enthalten.
- Einrichtung. Nennen Sie uns Workflow, erwartetes Volumen und Nutzer. Wir konfigurieren den passenden Tarif, Limits und Integrationszugang.
- Defensive Transparenz. Nicht mit der Europäischen Kommission verbunden. Kein Ersatz für offizielle Quellen oder Entscheidungen zuständiger Behörden.
- Kontakt. Schreiben Sie an sales@norvext.com
Kontakt
sales@norvext.com
Teilen Sie den konkreten Anwendungsfall und das erwartete Volumen mit – wir konfigurieren den Arbeitsbereich für Handels- und Regulierungsprüfungen, Sanktionsprüfungen, Nachweisaufbereitung oder API/MCP-Integration.
Anhang A · Repräsentative Quellen je Ebene
150+ offizielle Quellen. Relevante Abdeckung je Workflow.
Die Ankerquelle jeder Prüfungsebene ist unten genannt — das Rückgrat, nicht die vollständige Liste. Der komplette, stets aktuelle Katalog ist online einsehbar.
| Ebene |
Ankerquellen |
| Sanktionen · 49 | OFAC (SDN + Non-SDN) · EU Consolidated (FSF) + EUR-Lex Russia/Belarus (Reg. 269/2014, 833/2014, 765/2006) · UN Security Council · UK · Switzerland (SECO) · Canada (SEMA) · Australia (DFAT) · Japan (MOF) · Ukraine (NSDC) · Baltic + Poland national lists |
| Exportkontrolle · 33 | EU Dual-Use (Reg. 2021/821) + Common Military List · US Consolidated Screening List + Commerce Control List · EU/G7 Common High-Priority Items · Japan METI End-User List · UAE control list |
| PEP / EDD · 28 | European Parliament · UK, German, Spanish and Danish parliaments · France HATVP · Baltic + Central-Asia legislatures · role-scoped UK public bodies |
| Ausschluss (MDB) · 5 | World Bank · EBRD · Asian Development Bank · Inter-American Development Bank · African Development Bank |
| Maritime Risiken · 8 | Paris, Tokyo, Black Sea, Abuja, Riyadh, Caribbean and Viña del Mar Port State Control (bans + detentions) |
| Aufsichtsrechtliche Warnlisten · 8 | Baltic supervisory, gaming and consumer-protection warning lists |
| Unternehmensregister · 8 | Latvia and Estonia enterprise registers · Poland KRS · Hong Kong Companies Registry · Japan NTA · GLEIF LEI |
| Zoll + Rechtsreferenz · 12 | EU TARIC · ECICS chemicals · EUR-Lex · EU Sanctions Map · EU AML high-risk third countries · EU VIES |
Abdeckung auf einen Blick
151 aktive Quellen in zehn Kategorien. Die Tabelle nennt den Anker je Ebene; der vollständige Katalog listet jede Quelle mit Behörde, Zuständigkeit und Freshness-Nachweis.
Vollständigen Katalog ansehen:
compliance-mcp.com/sources
Wie die Quellen aktuell bleiben
Der Aktualisierungsrhythmus folgt dem offiziellen Herausgeber und wird mit Freshness-Nachweisen erfasst. Jeder Workflow wählt das relevante Quellenprofil; jeder Kandidat nennt Liste, Programm und Rechtsgrundlage.
Anhang B · Close-Match-Suchalgorithmen
Sechs Evidenzsignale. Exakte Identifikatoren bleiben entscheidend.
Exact-token und Identifikator werden zuerst geprüft; fuzzy und phonetische Kandidaten laufen bei Bedarf oder gemeinsam im Deep Search. Namensscores ordnen Kandidaten für die Prüfung.
| # | Algorithmus | Technologie | Was er erfasst |
|---|
| 1 | Trigram-Ähnlichkeit | pg_trgm · GIN | Dreibuchstaben-Fragment-Überschneidung. Ivanov Ivan ↔ Ivanov Ivan Petrowitsch. |
| 2 | Token-Sort-Trigram | pg_trgm · sortierte Tokens | Entfernt Wortreihenfolge-Effekte. Sirius Trading ↔ Trading House Sirius. |
| 3 | Double Metaphone | fuzzystrmatch | Phonetische Äquivalenz. Ivanov ↔ Ivanoff, Mikhail ↔ Michael. Kyrillisch wird zuerst transliteriert. |
| 4 | Levenshtein | levenshtein_less_equal() | Min-Edit-Anzahl für kurze Strings und Tippfehler. Ivanov ↔ Ivanoff. |
| 5 | Exact Token | Token-Tabelle · btree | Deterministischer Alias-/Transliterations-Lookup. Northbridge Trading Ltd ↔ gespeicherter Alias. |
| 6 | Identifier-Match | normalisierte Identifikatoren | Registrierung, IMO, BIC/SWIFT, Pass, nationale ID, Steuer-ID. Erzwingt Score 100. |
Score-Modell
Namensscore: stärkstes anwendbares Ähnlichkeits- oder Token-Signal, danach entity-spezifische Schutzregeln.
Bestätigung: exaktes Geburtsdatum +10, passendes Subjektland +5.
Low-information caps: häufiges Firmen-Einzeltoken 70; Fuzzy-Einzeltoken/Person und seltene Firmen-Teilmenge 84.
Nur Phonetik: unbestätigte Mehrwort-, Firmen- und Schiffskandidaten sind auf 60 begrenzt.
Exakter Identifikator: ergibt 100 und wird getrennt von reiner Namensevidenz ausgewiesen.
Vollständige Methodik:
compliance-mcp.com/library/learning/entity-screening-algorithms
Score-Stufen · Standardschwelle 75
Standardschwelle ist 75. Ein Namensscore, auch 100, ordnet einen Kandidaten ein und bestätigt keine Identität; der exakte Identifikator ist das separate Bestätigungssignal.
Anhang C · VoP — Verification of Payee
EPC-artige Close-Match-Codes für Screening-Kandidaten.
Reg. (EU) 2024/886 verlangt, dass der PSP des Zahlers die IBAN-/Namensprüfung mit dem PSP des Empfängers anbietet. Diese Funktion klassifiziert stattdessen Namensabstände zu Sanktionskandidaten und ist keine Kontoinhaberprüfung.
| Ergebnis | Szenario | Logik | Beispiel |
|---|
| MTCH | exact | gleich nach Normalisierung | Jan Kowalski = Jan Kowalski |
| CMTC | s2a_levenshtein | Edit-Distanz ≤ 2 | Muller ~ Mueller |
| CMTC | s2b_transposition | ein benachbarter Tausch | Smtih ~ Smith |
| CMTC | s2c_initial | Initial + Nachname | J Smith ~ John Smith · nur natürliche Person |
| CMTC | s2d_phonetic | phonetische Äquivalenz | Kowalsky ~ Kowalski · nur natürliche Person |
| NMTC | no_match | kein Szenario ausgelöst | ABC Trading vs XYZ Logistics |
| NOAP | not applicable | Eingabe- oder Kandidatenname fehlt | Vergleich nicht möglich |
Reguliertes VoP und Screening-Klassifikator
Reguliertes VoP gleicht den vom Zahler gelieferten Namen oder Identifikator mit den Kontoinhaberdaten beim PSP des Empfängers ab.
Screening-Klassifikator ordnet MTCH / CMTC / NMTC / NOAP den Plattform-Kandidaten zu. Er unterstützt die Prüfung, erfüllt aber nicht allein die PSP-VoP-Pflicht.
Quellen: Verordnung (EU) 2024/886, Art. 5c; EPC VOP Scheme Rulebook v1.1 (wirksam ab 20. September 2026).
Vollständige Methodik:
compliance-mcp.com/library/learning/entity-screening-algorithms
VoP-Normalisierung · 6 Schritte
1. Kleinbuchstaben · 2. Nordische Erweiterung (ø→oe, ä→ae, ß→ss) · 3. Unaccent (é→e) · 4. Rechtsform-Suffixe entfernen (SIA, LLC, GmbH) · 5. Whitelist [a-z0-9\s] · 6. Whitespace komprimieren
