Gwg Live Screening

gwg-live-screening

> Status: beta — automatisierte Tests laufen grün in CI (tests/: > Parser gegen fiktive EU-/UN-Fixtures, Match-Stufen S1–S4, Frische-Gate, > CLI-Adversarialfälle, Abruf-URL-Format). Noch nicht händisch abgenommen > und nicht gegen die echten Listen produktiv geprüft — status: getestet > vergibt erst der Maintainer nach eigener Prüfung (siehe > CONVENTIONS.md, > Reifegrad-Leiter). Die §-Zitate unten tragen den Marker ⚠️ (nicht gegen > gesetze-im-internet.de geprüft).

Zweck

Screent Parteinamen (natürliche und juristische Personen) gegen zwei offizielle, öffentlich abrufbare Sanktionslisten und erzeugt einen Dokumentations-Report für die Akte:

• EU-Konsolidierte Finanzsanktionsliste (FSF „full file", XML-Export,

webgate.ec.europa.eu),

• UN Security Council Consolidated List (XML, scsanctions.un.org).

Der Abgleich unterstützt die organisatorische Sanktions-/Embargo-Prüfung (u. a. im Rahmen der GwG-Sorgfaltspflichten, § 10 GwG ⚠️, und des EU-Sanktionsrechts) — er ersetzt sie nicht: der Executor liefert Kandidaten, die Bewertung und jede Maßnahme bleibt beim Verpflichteten.

Abgrenzung zum Nachbar-Skill [gwg-risiko-check](../gwg-risiko-check/SKILL.md): jener klassifiziert das Länderrisiko eines Mandats anhand von Länderlisten (EU-Hochrisiko/FATF); dieser Skill screent konkrete Personen/Organisationen gegen Sanktionslisten. Zwei verschiedene Prüfungen.

Eingaben (Datei-Kontrakt, P2)

| Eingabe | Pflicht | Format | Beschreibung | |---|---|---|---| | Parteien | ja (--parteien) | .csv (Pflichtspalte name) oder .json | Zu prüfende Personen/Organisationen. Vollständiger Kontrakt: [schema/README.md](schema/README.md), Beispiel: [schema/beispiel-parteien.json](schema/beispiel-parteien.json). | | Listen-Verzeichnis | ja (--listen-verzeichnis) | Verzeichnis mit *.xml + abruf-meta.json | Lokale Listen-Dateien (EU-FSF/UN, Format automatisch erkannt) und die vom Abruf-Skript geschriebene Metadatei mit abgerufen_am je Liste. |

Der Executor liest nur — keine Persistierung, kein Netzwerkzugriff.

Ablauf

1. Listen beschaffen (getrennt vom Screening). Der Abruf läuft über das

klar abgetrennte Skript [core/adapters/sanktionslisten/abruf.py](../../core/adapters/sanktionslisten/abruf.py) (nur Stdlib urllib) — nie im Screening-Executor (P3-Deterministik). Es lädt die zwei offiziellen URLs in ein Zielverzeichnis und schreibt abruf-meta.json mit abgerufen_am. Alternativ manuell:

``bash # UN (frei abrufbar) curl -L -o listen/un-consolidated.xml \ https://scsanctions.un.org/resources/xml/en/consolidated.xml # EU-FSF „full file" (öffentlicher Token-Parameter laut EU-Doku) curl -L -o listen/eu-fsf.xml \ "https://webgate.ec.europa.eu/fsd/fsf/public/files/xmlFullSanctionsList_1_1/content?token=" ``

Bei manuellem Download muss abruf-meta.json von Hand das abgerufen_am je Datei tragen, sonst greift das Frische-Gate (Schritt 3).

1. Claude erstellt die Parteien-Datei nach dem Kontrakt in

[schema/README.md](schema/README.md), ausschließlich aus dem, was Nutzer oder Akte hergeben — nie Namen erfinden (Anti-Halluzination).

1. Claude ruft den Executor auf (kein eigenes Namensvergleichen durch das

Modell, P3):

``bash python3 ${CLAUDE_PLUGIN_ROOT}/skills/gwg-live-screening/executor.py \ --parteien \ --listen-verzeichnis \ [--output ] \ [--schwelle-moeglich ] ``

Frische-Gate (D19-Muster): Je Liste müssen Generierungsdatum (aus dem XML) UND abgerufen_am (aus abruf-meta.json) vorliegen; fehlt eines, bricht der Executor mit Exit 3 ab und erzeugt keinen Report. Ist eine Liste älter als 7 Tage, trägt der Report eine Warnung.

1. Der Executor entscheidet Stufe und Score deterministisch (P3), über die

wiederverwendbare Bibliothek [core/calc/matching](../../core/calc/matching/): S1 exakt / S2 Token / S3 Kölner Phonetik / S4 Fuzzy ≥ Schwelle — jeweils gegen Primärname UND alle Aliase jedes Listeneintrags. Kategorien treffer (S1/S2), moeglicher_treffer (S3/S4), kein_treffer. Claude liest ausschließlich den JSON-Report und übernimmt stufe, score, listen_referenz und begruendung unverändert.

1. Claude rendert den Report als Akten-Dokumentation (Markdown): je Partei

das Ergebnis (Treffer/möglicher Treffer/kein Treffer), bei Treffern die Liste, Fundstelle (listen_referenz, programm), Match-Stufe, den getroffenen Namen (Primär oder Alias) und ggf. Geburtsdatum. Dabei immer:

• die Listen-Frische ausweisen (Generierungs- + Abrufdatum je Liste) und

jede warnung_veraltet sichtbar machen;

• treffer und moeglicher_treffer optisch unterscheiden (z. B. ✅ / ⚠️);
• bei jedem Treffer/möglichen Treffer klarstellen, dass die Bewertung

und jede Maßnahme (Verdachtsmeldung § 43 GwG ⚠️, Bereitstellungsverbot nach EU-Sanktionsrecht ⚠️) beim Verpflichteten liegt — der Report liefert Kandidaten, keine Entscheidung;

• Nicht-Treffer ausdrücklich dokumentieren (negative clearance ist der

Hauptzweck der GwG-Dokumentation), aber „kein Treffer ist kein Freibrief" anbringen (Transliterations-/Schreibweisen-Grenze, siehe haftung);

• erwähnen, dass der Abgleich vollständig lokal/offline erfolgte.

1. Bei Exit 2 (Eingabefehler: Datei/Verzeichnis fehlt, Pflichtspalte

fehlt, kaputtes XML/JSON, unbekannte XML-Wurzel, Schwelle außerhalb [0,1]) und Exit 3 (Frische-Gate) gibt Claude die Fehlermeldung wieder und korrigiert die Eingabe bzw. löst einen frischen Abruf aus — es rät kein Ergebnis.

Output-Format

JSON-Report nach [schema/README.md](schema/README.md#ausgabe-json-report), Beispiel: [schema/beispiel-report.json](schema/beispiel-report.json) (tatsächlich vom Executor erzeugt). Jeder Zahlen-/Datums-/Score-Wert stammt aus dem Executor bzw. Parser (P3), nie vom Modell.

Beispiel

Eingabe: [schema/beispiel-parteien.json](schema/beispiel-parteien.json) (4 Parteien) gegen die Fixtures unter [tests/fixtures/](tests/fixtures/) (fiktive EU-FSF- und UN-Ausschnitte). Von Claude präsentiertes Ergebnis (aus dem Report übernommen):

| Partei | Ergebnis | Liste / Fundstelle | Stufe | Getroffener Name | |---|---|---|---|---| | Max Mustermann | ✅ treffer | EU-FSF / EU.9001.99 (MUSTER-PROG) | S1 | Max Mustermann (Primär) | | Musterbau AG | ✅ treffer | UN / MUe.9101 (MUSTER) | S1 | Musterbau AG (Alias) | | Maximilian Mustermann | ⚠️ moeglichertreffer | EU-FSF / EU.9001.99 | S3 (Kölner Phonetik) | Maximilian Mustremann (Alias) | | Johanna Sauber | — keintreffer | — | — | — (negative clearance dokumentiert) |

Hinweis: „Max Mustermann" erzeugt zusätzlich einen moeglicher_treffer (S4, Score 0.83) gegen den UN-Alias „Hans Mustermann" — ein bewusst in Kauf genommener falsch-positiver Kandidat der konservativen Schwelle 0.80, der händisch zu prüfen ist. Die Bewertung jedes Treffers und jede Maßnahme (§ 43 GwG ⚠️ / EU-Bereitstellungsverbot ⚠️) trifft der Verpflichtete.

Bewusst NICHT in v1 (Grenzen / Zurückstellungen)

• Nur EU-FSF + UN. OFAC (US) und UK/OFSI-Listen sind

zurückgestellt (anderes Schema, Lizenz-/Pflegefragen).

• Kein PEP-Screening — belastbare PEP-Listen gibt es nur aus kommerziellen

Quellen; kein offener Pflicht-Feed.

• Kein Transparenzregister-Abgleich — produktiv nur über Reseller

zugänglich.

• Nur lateinische Schreibweisen belastbar. Nicht-lateinische

Originalschreibweisen (arab./kyrill.) werden zwar geparst, aber das Matching (Kölner Phonetik/Fuzzy) ist dafür nicht ausgelegt — Transliterations-Grenze (steht auch im haftung-Feld).

• Keine Maßnahmen-Automatik. Verdachtsmeldung (§ 43 GwG ⚠️),

Bereitstellungs-/Verfügungsverbot (EU-Sanktionsrecht ⚠️) und jede weitere Konsequenz entscheidet und dokumentiert der Verpflichtete.

• Ein kein_treffer ist kein Freibrief — Schreibvarianten jenseits der

Stufen S1–S4 bleiben ggf. unentdeckt; die abschließende Prüfung bleibt Kanzleipflicht.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: eliasreiche
• Source: eliasreiche/legal-ops-germany
• License: Apache-2.0

Install and usage instructions live in the source repository linked above.