Compliance
Plattform-Start Sommer 2026 · Testzugang ab sofort verfügbar
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.
v6 · 20. Mai 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.
Die Plattform verwandelt tägliche Screening-Vorgänge in nachweisbereite 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 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.
- Zusammengehörige Prüfungen in einem Fall bündeln. TARIC-Abfragen, Unternehmensprüfungen und Schiffsverifizierungen reisen gemeinsam – ein prüffähiges Artefakt pro Entscheidung.
- Nutzen Sie es dort, wo gearbeitet wird. Der Jurist in der Web-App, der Entwickler über die API, der KI-Agent über MCP – dieselben Daten, dieselben Quellen, derselbe Nachweispfad.
- Starten Sie heute im Testarbeitsbereich. Keine sechsstellige Mindestsumme, keine sechsmonatige Integration, keine Compliance-Abteilung als Voraussetzung.
Arbeitsbereichsstatus, aktivierte Dienste, Bereitschaft und letzte Prüfungen in einer konsistenten 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 jeden in der Oberfläche verfügbaren Workflow. Integrieren Sie Compliance in KYC-Onboarding, Lieferantenprüfung, Transaktionsüberwachung oder jede interne Automatisierung.
- 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 Nachweispfad. Eine über die API ausgeführte Prüfung landet im selben Screening-Cases-Register wie eine Prüfung über die Oberfläche. Der Prüfer sieht beide. Der Auditor sieht beide.
- Eine Quelle der Wahrheit. Alle drei Kanäle greifen auf dieselben Sanktionsdaten, dieselben TARIC-Maßnahmen und dieselbe Close-Match-Logik zu. Keine Abweichung zwischen „API-Version" und „Oberflächenversion".
- API und MCP sind erstklassig, nicht Enterprise-only. Im Testarbeitsbereich heute verfügbar, genauso wie die Web UI.
Ökosystem
REST API
Interne Automatisierung
Vereinheitlichte Daten
Sanktionen · TARIC · Close-Match
Ein Nachweispfad
Screening Cases Register
Keine Abweichung zwischen Oberfläche und API – dieselben Quellen, dieselbe Close-Match-Logik, dasselbe Fall-Artefakt.
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.
- Dieselbe Prüfung, jeder Kanal – Web, API, MCP. Identische Ausgabe, identische Quellen.
Datum-bewusst
Gespeicherte Parameter
API/MCP-Ausgabe identisch
07 · Sanktionsprüfung
Siebzehn Listen. Jede Variante. Ein prüffähiges Ergebnis.
Offizielle Sanktionsquellen sind durchsuchbar und mit dem Ursprungseintrag 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. Siebzehn offizielle Listen, automatisch gepflegt (Tabelle gegenüber).
- 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.
- Durchstöbern Sie den strukturierten Datensatz direkt. Die Reference Library zeigt die Tabelle gelisteter Unternehmen – filtern Sie nach Programm, Typ, Land oder Quelle, wenn Sie einen Quelldatensatz außerhalb einer aktiven Prüfung verifizieren.
Datenabdeckung · 17 Quellen
| Offizielle Quelle | Behörde |
|---|
| OFAC SDN | USA |
| OFAC Non-SDN | USA |
| EU FSF | Europäische Union |
| EU Russia (Reg. 833/2014) | Europäische Union |
| EU Belarus (Reg. 765/2006) | Europäische Union |
| EU Russia asset-freeze (Reg. 269/2014) | 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 |
| EE national sanctions | Estland |
| LV FID | Lettland |
| LV FID frozen-assets | Lettland |
| PL MSWiA | Polen |
| UA NSDC | Ukraine |
Listen werden automatisch gepflegt. Güterbezogene Sanktionen werden gleichzeitig gegen TARIC-Annexe geprüft.
08 · ISO 20022 Zahlungsprüfung
Pre-Flight-Prüfung für pain.001 und pacs.008.
Ein nachrichtenbewusster Wrapper um dieselbe Engine. Rohpayload als Prüfnachweis erhalten.
- Full Payload Mandate. Die gesamte rohe pain.001-/pacs.008-XML wird als unveränderliches binäres Artefakt aufbewahrt. Vorgefilterte Felder sind verboten — sie brechen die Beweiskette.
- XSD-Validierung gegen offizielle iso20022.org-Schemas. Strukturelle Fehler lösen einen Integrity Error aus und halten den Fall im Status "Needs Review", bis ein Prüfer eine Begründung erfasst.
- 6-Knoten-Teilnehmermodell. Sender Bank, Ordering Institution, Ordering Customer, Intermediary Banks, Beneficiary Bank, Beneficiary — jeder gegen dieselben vierzehn Quellen geprüft. Details auf der nächsten Folie.
- BIC-zu-Entität-Auflösungs-Waterfall. Tier 1 GLEIF-Cache · Tier 2 Echtzeit-API · Tier 3 gegründete LLM-Websuche — Quell-URL als unveränderlicher Prüfnachweis erfasst.
- Unified Verdict + Persona Separation. Ein einziger High-Risk-Treffer auf einem Knoten markiert die Transaktion. Personenknoten erhalten Personenlogik; Unternehmensknoten erhalten Unternehmenslogik.
- Conflict Detection. Wenn der BIC-aufgelöste Name vom XML abweicht, löst der Fall eine Data Integrity Warning aus — eine Verteidigung gegen Namensverschleierung.
Markenversprechen · case-as-audit
Der schwierige Teil ist nicht die Prüfung. Es ist die Verteidigung des Ergebnisses.
Jeder Statusübergang ist mit Zeitstempel und Prüfer versehen. Historische Snapshots bewahren den Zustand der Listen zum Zeitpunkt der Prüfung — als Verteidigung gegen spätere "Data-Drift"-Argumente.
Für Unternehmen, Regionalbanken, Notare — alle, deren ausgehende Überweisung sie OFAC-, EU- oder UK-Sanktionen aussetzt — ist der Fall die Prüfung.
09 · 6-Knoten-Teilnehmermodell
Jede pain.001 zerlegt sich in sechs prüfbare Teilnehmer.
Jeder Knoten wird unabhängig geprüft. Ein High-Risk-Treffer auf einem markiert die Transaktion.
| # | Rolle | pain.001-Mapping | pacs.008-Mapping | Entität | Was geprüft wird |
|---|
| 1 | Sender Bank | DbtrAgt (implied initiation) | InstgAgt | Unternehmen | Die ursprüngliche Geschäftsbank. BIC gegen alle vierzehn Quellen auf Eigentum/Jurisdiktion 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) | Person | Die initiierende Rechtspersönlichkeit. Person-Logik (DOB, Pass), vollständige Namensübereinstimmung. |
| 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) | Person | Die letztempfangende Partei — Rechtspersönlichkeit oder natürliche Person. Person- oder Unternehmenslogik je Typ. |
Warum sechs, nicht zwei
Die meisten Unternehmens-Tools prüfen den Beneficiary (Knoten 6) und hören auf. Die echte Exposition sitzt in Knoten 4 und 5 — Intermediary-Korrespondenten und die Beneficiary Bank. Ein sauberer Beneficiary bei einem sanktionierten Korrespondenten ist keine verteidigbare Transaktion.
10 · Screening Cases — Alleinstellungsmerkmal
Jede Prüfung landet in einem Fall. Jeder Fall ist sein eigenes Audit.
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.
- Jede Prüfung wird Teil eines Falls. TARIC-Abfragen, Sanktionsprüfungen gegen Personen/Unternehmen/Schiffe/Luftfahrzeuge, Bankverifizierungen und ISO-20022-Zahlungsprüfungen (pain.001-/pacs.008-Nachrichten) – alle Stränge einer einzelnen Entscheidung reisen gemeinsam.
- Lebenszyklus-Status steuern den Workflow. Offen → Prüfung erforderlich → Geschlossen → Archiviert. Jeder Übergang wird mit Zeitstempel, Bearbeiter und Datenstand zum Zeitpunkt protokolliert.
- Treffer erscheinen im Fall. Rote „Treffer"-Marker, quellverknüpfte Einträge, Bearbeiterhinweise – sichtbar im Fall-Kontext, nicht versteckt in einem separaten Alarm-Tool.
- Der Unterschied zu Refinitiv, Dow Jones, Sayari: Sie liefern Screening-Ergebnisse. Compliance Platform liefert den Fall, zu dem diese Ergebnisse gehören – das audit-fertige Artefakt, nicht die rohe Ausgabe.
- 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. Fügen Sie pain.001-/pacs.008-XML ein – die Teilnehmerkette (bis zu 6 Knoten) wird gegen dieselben vierzehn Listen (siehe Folie 9) geprüft, die Nachweise werden neben dem Fall gespeichert.
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 eine Abfrageoberfläche, kein Generierungswerkzeug. Fragen Sie, welche TARIC-Maßnahmen gelten, welche Listen einen Namen enthalten, welche Fälle einen Geschäftspartner betreffen – der Assistent fragt indizierte Daten ab und liefert zitierte Ergebnisse.
- 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.
- Beide Oberflächen sind fundiert. Keine halluzinierten Verordnungen, keine erfundenen Sanktionsprogramme, keine plausibel klingenden, aber falschen Zitate. Der Agent gibt nur das zurück, was die Plattform indiziert – nicht mehr.
- Agent-gesteuerte Prüfungen landen im selben Screening-Cases-Register. Web, API, MCP – derselbe Fall, derselbe Nachweispfad. Es gibt keinen „KI-Silo", in dem Prüfungen das Audit umgehen.
- 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
Keine Halluzinationen
Screening Cases
Derselbe Fall · dasselbe Audit
KI-Vertrauen wird durch Zitate und Audit-Protokollierung gewonnen – nicht durch ein vages „KI-gestützt"-Versprechen.
12 · Status & Aufruf
Vor Markteinführung. Testzugang ab sofort verfügbar.
Eine Feedback-Partnerschaft für Teams, die verteidigungsfähiges Screening ohne Unternehmens-Overhead brauchen.
- Stand. Markteinführung der Produktionsplattform geplant für Sommer 2026.
- Testzugang ab sofort verfügbar. Keine sechsstellige Mindestsumme, keine sechsmonatige Integration, keine Compliance-Abteilung als Voraussetzung. Verfügbar für Teams jeder Größe.
- Was der Testzugang umfasst. Vollständige Web UI, API und MCP Server; aktuelle Sanktionslisten; aktuelle TARIC-Maßnahmen; Screening Cases und Nachweispfad.
- Was wir im Gegenzug erbitten. Echte Workflow-Fragen, Rückmeldungen zu Abdeckungslücken, Integrations-Anwendungsfälle. Keine Zahlungspflicht.
- 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 richten den Pilotzugang an Handels- und Regulierungsprüfungen, Sanktionsprüfungen, Nachweisaufbereitung oder API/MCP-Integration aus.
Anhang A · Unterstützte Sanktionslisten
Siebzehn offizielle Quellen. Ein Screening-Lauf.
Jede Liste unten ist eine offizielle staatliche oder supranationale Quelle – automatisch synchronisiert, mit dem Ursprungseintrag verknüpft und gemeinsam geprüft.
| Offizielle Quelle |
Behörde |
Zuständigkeitsbereich |
| UN SC Consolidated List | UN SC | Vereinte Nationen |
| EU Consolidated Financial Sanctions (FSF) | Europäische Kommission / DG FISMA | Europäische Union |
| EU Russia asset-freeze — Reg. 269/2014 | EUR-Lex | Europäische Union |
| EU Russia — Reg. 833/2014 | EUR-Lex | Europäische Union |
| EU Belarus — Reg. 765/2006 | EUR-Lex | Europäische Union |
| OFAC SDN List | U.S. Treasury / OFAC | USA |
| OFAC Consolidated Non-SDN List | U.S. Treasury / OFAC | USA |
| UK Sanctions List | UK FCDO | Vereinigtes Königreich |
| Swiss SECO Sanctions List | SECO | Schweiz |
| Canada Consolidated (SEMA) | Global Affairs Canada | Kanada |
| Australian Sanctions Consolidated List | DFAT | Australien |
| Japan MOF economic sanctions | Japanisches Finanzministerium | Japan |
| Ukraine State Register of Sanctions | NSDC der Ukraine | Ukraine |
| Estonian Government national sanctions | Estnisches Außenministerium | Estland |
| Latvia FID National Sanctions List | Lettisches FID | Lettland |
| Latvian FID frozen-assets registry | Lettisches FID | Lettland |
| Poland MSWiA national sanctions list | Polnisches MSWiA | Polen |
Abdeckung auf einen Blick
5 multilateral / EU-weit – UN-Sicherheitsrat, EU FSF und die drei EUR-Lex-Verordnungen zu Russland/Belarus (269/2014, 833/2014, 765/2006).
8 national – USA (OFAC SDN + Non-SDN), Vereinigtes Königreich, Schweiz, Kanada, Australien, Japan, Ukraine.
4 EU-Mitgliedstaaten – Estland, Lettland (FID-Liste + Register eingefrorener Vermögenswerte), Polen.
Wie die Quellen aktuell bleiben
Die meisten Quellen synchronisieren täglich; publikationsgesteuerte Listen aktualisieren sich bei jeder offiziellen Aktualisierung. Jeder Screening-Treffer zitiert seine Quellliste, sein Programm und seine Rechtsgrundlage – siehe Anhang B für die Match-Algorithmen.
Anhang B · Close-Match-Suchalgorithmen
Sechs Suchpfade laufen parallel. Das stärkste Signal gewinnt.
Namen stimmen selten exakt überein. Trigram, Token-Sort, Phonetik, Edit-Distance, Exact-Token und Identifier — alle bewerten dieselbe Abfrage, der Score spiegelt das stärkste Signal wider.
| # | 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
raw = max(Signal) × 100 über die sechs Pfade oben.
+ Boni: DOB übereinstimmend +10, Land übereinstimmend +5.
− Sicherheits-Caps: Eine Single-Token-Fuzzy-Abfrage wird auf 84 (Review-Tier) begrenzt — "Ivanov" allein bestätigt nie Identität.
↑ Override: exakter Identifier-Match erzwingt 100.
Score-Stufen · Standardschwelle 75
100 Bestätigter Beweis · 90–99 Treffer (manuelle Prüfung erforderlich) · 75–89 Review (vor Freigabe untersuchen) · <75 Schwach (bei Standardschwelle nicht zurückgegeben)
Anhang C · VoP — Verification of Payee
EPC288-23-Close-Match-Klassifizierung über der Standardprüfung.
Unter Reg. (EU) 2024/886 muss der Originator den Empfängernamen verifizieren — nicht nur seine Bank. Unser VoP-Wrapper nimmt dieselben Sanktionskandidaten aus Anhang B und klassifiziert den Namens-Match nach EPC288-23-Regeln.
| 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 | registrierter Name nicht verfügbar | Empfänger-PSP gab keinen Namen zurück |
Klassisches VoP vs. unser VoP
Klassisches VoP fragt "stimmt der Empfängername mit dem IBAN-Kontoinhaber überein?" — beantwortet durch den PSP des Empfängers.
Unser VoP fragt "stimmt der Empfängername mit einem Sanktionskandidaten überein?" — wickelt die Standardprüfung aus Anhang B mit EPC288-23-Close-Match-Klassifizierung um.
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
