Zgodność
Uruchomienie platformy latem 2026 · Dostęp testowy otwarty już dziś
Compliance Platform
Weryfikacja handlu i sankcji z dowodami.
CN / TARIC
Listy sankcyjne
Screening Cases
Płatności ISO 20022
API + MCP
Niepowiązany z Komisją Europejską. Nie zastępuje oficjalnych źródeł ani decyzji właściwych organów.
v6 · 20 maja 2026
02 · Wyzwanie
Trudność nie tkwi w weryfikacji. Trudność — w obronie wyniku.
Praca zgodności zawodzi, gdy odpowiedzi nie można odtworzyć, udokumentować źródłem ani wyjaśnić audytorowi.
- Listy sankcyjne, środki TARIC i rejestry podmiotów rozproszone są między dziesiątkami regulatorów. Ich ręczne łączenie marnuje czas kontrolerów.
- Większość narzędzi daje odpowiedź tak/nie. Audytorzy potrzebują linku do źródła, znacznika czasu i uzasadnienia kontrolera.
- Pseudonimy, transliteracje i lokalne warianty nazw zamieniają dzisiejsze czyste „brak dopasowania" w jutrzejsze pominięte dopasowanie.
- Weryfikacje TARIC, weryfikacje podmiotów i potwierdzenia statków gromadzą się w arkuszach i e-mailach — a nie jako jedna audytowalna sprawa.
- Gdy narzędzie oznacza dopasowanie, kontrolerzy nie zawsze widzą dlaczego. To utrudnia obronę decyzji podczas audytu.
- Inżynierowie tworzący wewnętrzną automatyzację zazwyczaj zmuszeni są scrapować ten sam interfejs, którego używają zespoły zgodności.
Luka w obronie audytu
1
Wiele oficjalnych źródeł
Listy sankcyjne, środki TARIC, rejestry podmiotów
2
Ręczne łączenie
Arkusze, zrzuty ekranu, wątki e-mail
?
Decyzja podczas audytu
„Gdzie są dowody?"
Obroniony wynik utrzymuje razem dane, źródło, parametry, kontrolera i czas.
03 · Grupa docelowa + pozycjonowanie
Narzędzia zgodności tworzono dla banków pierwszego poziomu. Praca zgodności odbywa się wszędzie indziej.
Ta sama presja regulacyjna sięga teraz zespołów bez osobnego działu zgodności.
- Narzędzia zgodności powstały po 11 września i dojrzewały w bankach oraz firmach konsultingowych Big Four. Nadal kosztują i konfigurują się odpowiednio.
- Ta sama presja regulacyjna, znacznie szersze pole: międzynarodowe korporacje, banki regionalne i MŚP, firmy logistyczne, agenci celni, regionalne lotniska, grupy operacyjne policji, notariusze i służby społeczne.
- Te zespoły nie mają osobnego działu zgodności. Praca spada na operacje, dział prawny lub kierownictwo — obok codziennych obowiązków.
- Potrzebują tak samo obronnych dowodów weryfikacji jak bank pierwszego poziomu — ale nie mogą uzasadnić sześciocyfrowej licencji ani sześciomiesięcznej integracji.
- Potrzebują dostępu tam, gdzie pracują: narzędzie webowe dla prawnika, API dla inżyniera, serwer MCP dla agenta AI.
- Długi ogon zgodności jest rzędy wielkości większy niż rdzeń banków / Big Four — to samo ryzyko regulacyjne, znacznie mniej narzędzi, żadnego poważnego dostawcy, który by je obsługiwał.
Długi ogon zgodności
Rdzeń banków / Big Four
Międzynarodowe korporacje
Banki regionalne i MŚP
Firmy logistyczne
Agenci celni
Regionalne lotniska
Grupy operacyjne policji
Notariusze
Służby społeczne
Ta sama presja. Znacznie mniej narzędzi. Żadnego poważnego dostawcy dla całego spektrum.
04 · Główne funkcje
Obroniona zgodność — bez osobnego działu zgodności.
Platforma zamienia codzienne operacje weryfikacji w decyzje gotowe na dowody.
- Uzyskaj jedną powiązaną ze źródłem odpowiedź na pytanie „Czy można to wysłać, przetworzyć lub przeprowadzić jako transakcję?" — obejmującą środki TARIC/CN, sankcje i rejestry podmiotów, a nie trzy osobne narzędzia.
- Twórz obronne dowody jako produkt uboczny pracy. Każda weryfikacja automatycznie otrzymuje znacznik czasu, link do źródła i przypisanie kontrolera — brak osobnego przygotowania do audytu.
- Wykrywaj to, co pomija ręczna kontrola. Dopasowania pseudonimów, warianty transliteracji i lokalne wzorce nazw ujawniają kandydatów, których skanowanie tak/nie pominęłoby.
- Grupuj powiązane weryfikacje w jednej sprawie. Wyszukiwania TARIC, weryfikacje podmiotów i potwierdzenia statków podróżują razem — jeden audytowalny artefakt na jedną decyzję.
- Używaj tam, gdzie odbywa się praca. Prawnik w aplikacji webowej, inżynier przez API, agent AI przez MCP — te same dane, te same źródła, ten sam ślad audytu.
- Zacznij w testowej przestrzeni roboczej już dziś. Bez sześciocyfrowego minimum, bez sześciomiesięcznej integracji, bez wymogu działu zgodności.
Stan przestrzeni roboczej, aktywowane usługi, gotowość i ostatnie weryfikacje w jednym spójnym widoku.
05 · Kanały
Trzy interfejsy, jedno źródło prawdy.
Kontroler, inżynier i agent AI używają pod spodem tych samych danych.
- Web UI — pełny interfejs weryfikacji do bezpośredniego użycia przez kontrolera. Te same dane, te same dowody, ten sam ślad audytu co w innych kanałach.
- API — punkty końcowe REST dla każdego przepływu pracy dostępnego w interfejsie. Wbuduj zgodność w onboarding KYC, weryfikację dostawców, monitorowanie transakcji lub dowolną wewnętrzną automatyzację.
- MCP Server — udostępnia przepływy weryfikacji jako natywne narzędzia dla agentów AI. Każdy klient zgodny z MCP (Claude, ChatGPT Agents, własny) może wywoływać weryfikacje i otrzymywać dowody z linkami do źródła.
- Jeden ślad audytu. Weryfikacja wykonana przez API trafia do tego samego rejestru Screening Cases, co weryfikacja przez interfejs. Kontroler widzi obie. Audytor widzi obie.
- Jedno źródło prawdy. Wszystkie trzy kanały odpytują te same dane sankcyjne, te same środki TARIC, tę samą logikę bliskich dopasowań. Brak rozbieżności między „wersją API" a „wersją interfejsu".
- API i MCP są pierwszorzędne, nie tylko dla enterprise. Dostępne w testowej przestrzeni roboczej już dziś, tak samo jak Web UI.
Ekosystem
Web UI
Interfejs kontrolera
REST API
Wewnętrzna automatyzacja
MCP Server
Narzędzia dla agentów
Zunifikowane dane
Sankcje · TARIC · bliskie dopasowania
Jeden ślad audytu
Rejestr Screening Cases
Brak rozbieżności między interfejsem a API — te same źródła, ta sama logika bliskich dopasowań, ten sam artefakt sprawy.
06 · Weryfikacje kodów TARIC / CN
Jedno zapytanie, wszystkie obowiązujące środki, połączone ze źródłem.
Weryfikacje uwzględniające datę zachowują dane wejściowe, które wytworzyły wynik.
- Wprowadź to, czego wymaga deklaracja celna: kod CN/TARIC, kraj przeznaczenia, odpowiednią datę. Opcjonalne zawężenia — typ środka, dodatkowe kody.
- Otrzymaj dwie warstwy w jednym raporcie: powiadomienie o załączniku sankcyjnym, gdy ma zastosowanie, plus pełny obraz środków TARIC — zawieszenia taryfowe, kontrole importu/eksportu, zakazy, reguły specyficzne dla pochodzenia — każdy z odniesieniem do rozporządzenia, zakresem dat i wbudowanymi definicjami warunków.
- Każdy środek odsyła do swojego źródła — odpowiedniego rozporządzenia UE lub wpisu bazy danych TARIC. Raport pokazuje kontrolerom (i audytorom) uzasadnienie, nie tylko werdykt.
- Zapytania uwzględniające datę. Odtwórz weryfikację na dowolną wcześniejszą datę. Broń wcześniejszej decyzji z dokładnym stanem regulacyjnym, który obowiązywał wtedy.
- Zapisane parametry podróżują z wynikami. Dane wejściowe, które wytworzyły weryfikację, są przechowywane obok wyniku. Brak luk typu „czego szukałem?" w śladzie audytu.
- Ta sama weryfikacja, każdy kanał — web, API, MCP. Identyczny wynik, identyczne źródła.
Z uwzględnieniem daty
Parametry zapisane
Identyczne przez API/MCP
07 · Weryfikacja sankcji
Siedemnaście list. Każdy wariant. Jeden wynik audytowalny.
Oficjalne źródła sankcji są przeglądalne i powiązane z pierwotnym wpisem.
- Co jest sprawdzane. Nazwy — osoby, firmy, statki, statki powietrzne — wraz z pseudonimami, lokalnymi wariantami nazw, transliteracjami, datami urodzenia i identyfikatorami (paszport, IMO, BIC, numery rejestracyjne).
- Z czym jest porównywane. Siedemnaście oficjalnych list, utrzymywanych automatycznie (tabela obok).
- Logika dopasowania wykrywa to, co pomija ręczna kontrola. Pseudonimy, transliteracje, ekwiwalenty fonetyczne i lokalne wzorce nazw są oceniane obok dokładnych dopasowań. Próg konfigurowalny dla każdej weryfikacji.
- Każde dopasowanie przychodzi ze swoim źródłem. Każde dopasowanie odsyła do pierwotnego wpisu listy — nazwa listy, program, odniesienie do rozporządzenia, podstawy umieszczenia. Kontroler widzi dowody, nie tylko werdykt.
- Również sankcje na poziomie towarów. Ten sam przepływ pracy sprawdza kody CN/TARIC pod kątem załączników ograniczających towary (np. RU rozporządzenie 833/2014 ZAŁĄCZNIK XXIII), tak by weryfikacja podmiotu i weryfikacja towaru trafiły do tej samej sprawy.
- Przeglądaj ustrukturyzowany zbiór danych bezpośrednio. Reference Library pokazuje tabelę umieszczonych podmiotów — filtruj według programu, typu, kraju lub źródła, gdy weryfikujesz wpis źródłowy poza aktywną weryfikacją.
Zakres danych · 17 źródeł
| Oficjalne źródło | Organ |
|---|
| OFAC SDN | USA |
| OFAC Non-SDN | USA |
| EU FSF | Unia Europejska |
| EU Russia (Reg. 833/2014) | Unia Europejska |
| EU Belarus (Reg. 765/2006) | Unia Europejska |
| EU Russia asset-freeze (Reg. 269/2014) | Unia Europejska |
| UN SC Consolidated | ONZ |
| UK Sanctions List | Wielka Brytania |
| CH SECO | Szwajcaria |
| JP MOF | Japonia |
| AU DFAT | Australia |
| CA SEMA | Kanada |
| EE national sanctions | Estonia |
| LV FID | Łotwa |
| LV FID frozen-assets | Łotwa |
| PL MSWiA | Polska |
| UA NSDC | Ukraina |
Listy aktualizowane automatycznie. Sankcje na poziomie towarów sprawdzane jednocześnie wobec aneksów TARIC.
08 · Weryfikacja płatności ISO 20022
Pre-flight weryfikacja dla pain.001 i pacs.008.
Wrapper świadomy wiadomości wokół tego samego silnika. Surowy ładunek zachowany jako dowód audytowy.
- Full Payload Mandate. Cały surowy XML pain.001 / pacs.008 jest zachowywany jako niezmienny binarny artefakt. Pola wstępnie filtrowane są zabronione — łamią łańcuch dowodowy.
- Walidacja XSD wobec oficjalnych schematów iso20022.org. Błędy strukturalne wywołują Integrity Error i trzymają sprawę w "Needs Review", aż kontroler odnotuje uzasadnienie.
- Model 6 węzłów uczestników. Sender Bank, Ordering Institution, Ordering Customer, Intermediary Banks, Beneficiary Bank, Beneficiary — każdy sprawdzany osobno wobec tych samych czternastu źródeł. Szczegóły na następnym slajdzie.
- Wodospad rozwiązywania BIC do podmiotu. Tier 1 lokalny cache GLEIF · Tier 2 API w czasie rzeczywistym · Tier 3 wyszukiwanie LLM z gruntowaniem — URL źródłowy uchwycony jako niezmienny dowód.
- Unified Verdict + Persona Separation. Jeden hit high-risk na dowolnym węźle oznacza transakcję. Węzły osoby otrzymują logikę osoby; węzły podmiotu — logikę podmiotu.
- Conflict Detection. Jeśli nazwa rozwiązana przez BIC różni się od XML, sprawa podnosi Data Integrity Warning — obrona przed taktykami zaciemniania nazwy.
Obietnica marki · case-as-audit
Trudne nie jest sprawdzanie. Trudna jest obrona wyniku.
Każde przejście stanu jest opatrzone znacznikiem czasu i kontrolerem. Historyczne migawki zachowują stan list w momencie sprawdzania — obrona przed późniejszymi argumentami "data drift".
Dla firm, banków regionalnych, notariuszy — każdego, kogo wychodzący przelew naraża na odpowiedzialność OFAC, UE lub UK — sprawa jest audytem.
09 · Model 6 węzłów uczestników
Każdy pain.001 rozkłada się na sześciu sprawdzalnych uczestników.
Każdy węzeł jest sprawdzany niezależnie. Jeden hit high-risk na którymkolwiek oznacza całą transakcję.
| # | Rola | Mapowanie pain.001 | Mapowanie pacs.008 | Podmiot | Co jest sprawdzane |
|---|
| 1 | Sender Bank | DbtrAgt (implied initiation) | InstgAgt | Podmiot | Bank komercyjny inicjujący. BIC sprawdzony wobec wszystkich czternastu źródeł na własność/sankcje jurysdykcyjne. |
| 2 | Ordering Institution | DbtrAgt (Debtor Agent) | DbtrAgt (Debtor Agent) | Podmiot | Debtor Agent zidentyfikowany w XML. Często ten sam co Sender Bank dla direct pain.001 — nie zawsze. Sprawdzany osobno. |
| 3 | Ordering Customer | Dbtr (Debtor) | Dbtr (Debtor) | Osoba | Podmiot prawny inicjujący płatność. Logika osoby (DOB, paszport), pełne dopasowanie nazwy. |
| 4 | Intermediary Banks | N/A | IntrmyAgt1 → IntrmyAgt[n] | Podmiot | Łańcuch korespondentów. Często niewidoczny dla nadawcy, ale materialnie wyeksponowany, gdy sankcjonowany korespondent jest na ścieżce. |
| 5 | Beneficiary Bank | CdtrAgt (Creditor Agent) | CdtrAgt (Creditor Agent) | Podmiot | Instytucja odbierająca. Najczęściej pomijany cel sprawdzania — łapie ekspozycję UE Rosja/Białoruś pod Reg. 833/765. |
| 6 | Beneficiary | Cdtr (Creditor) | Cdtr (Creditor) | Osoba | Ostateczna strona odbierająca — podmiot prawny lub osoba fizyczna. Logika osoby lub podmiotu wg typu. |
Dlaczego sześć, nie dwa
Większość narzędzi po stronie firmy sprawdza Beneficiary (węzeł 6) i kończy. Prawdziwa ekspozycja siedzi w węzłach 4 i 5 — korespondentach pośrednich i banku beneficjenta. Czysty beneficjent przy sankcjonowanym korespondencie nie jest transakcją obronną.
10 · Screening Cases — czynnik wyróżniający
Każda weryfikacja trafia do sprawy. Każda sprawa to osobny audyt.
Artefakt decyzji, a nie tylko surowy wynik weryfikacji.
- Jednostka pracy zgodności to sprawa, nie weryfikacja. Jedna transakcja, klient lub przesyłka generuje wiele weryfikacji — ale audytor widzi jedną decyzję. Sprawa jest artefaktem tej decyzji.
- Każda weryfikacja dołącza do sprawy. Wyszukiwania TARIC, weryfikacje sankcyjne wobec osób/firm/statków/statków powietrznych, potwierdzenia bankowe i weryfikacje płatności ISO 20022 (komunikaty pain.001 / pacs.008) — wszystkie wątki jednej decyzji podróżują razem.
- Stany cyklu życia sterują przepływem pracy. Otwarta → Wymaga przeglądu → Zamknięta → Zarchiwizowana. Każde przejście jest rejestrowane ze znacznikiem czasu, kontrolerem i stanem danych w danym momencie.
- Dopasowania pojawiają się w sprawie. Czerwone znaczniki „dopasowanie", wpisy z linkami do źródła, notatki kontrolera — widoczne w kontekście sprawy, nie ukryte w osobnym narzędziu alertów.
- Czynnik wyróżniający wobec Refinitiv, Dow Jones, Sayari: oni dają wyniki weryfikacji. Compliance Platform daje sprawę, do której te wyniki należą — artefakt gotowy do audytu, nie surowy wynik.
- Odtwarzalna później. Otwórz dowolną sprawę ponownie, aby zobaczyć dokładne parametry, dopasowania, źródła i uzasadnienie kontrolera w stanie, w jakim były wtedy. Audyt nie jest osobnym zadaniem — sprawa jest audytem.
ISO 20022
Weryfikacja płatności, gotowa do sprawy. Wklej pain.001 / pacs.008 XML — łańcuch (do 6 węzłów) sprawdzany pod kątem czternastu list (zob. slajd 9), dowody obok sprawy.
Audyt nie jest osobnym zadaniem — sprawa jest audytem.
11 · AI Assistant + MCP
Ten sam ślad dowodów. Teraz dostępny dla agenta.
Warstwa agentów jest ugruntowana, cytowana i zarejestrowana — nie równoległe AI-silos.
- AI Assistant to interfejs wyszukiwania, nie narzędzie generowania. Zapytaj, które środki TARIC mają zastosowanie, które listy zawierają nazwę, które sprawy dotyczyły kontrahenta — asystent odpytuje zaindeksowane dane i zwraca cytowane wyniki.
- MCP udostępnia te same przepływy pracy zewnętrznym agentom. Każdy klient zgodny z MCP — Claude, ChatGPT Agents, własny — może wywołać weryfikację jako natywne narzędzie i otrzymać dowody z linkami do źródła.
- Oba interfejsy są ugruntowane. Brak halucynowanych rozporządzeń, brak zmyślonych programów sankcyjnych, brak wiarygodnie wyglądających, ale fałszywych cytatów. Agent zwraca to, co platforma indeksuje — nic więcej.
- Weryfikacje sterowane agentem trafiają do tego samego rejestru Screening Cases. Web, API, MCP — ta sama sprawa, ten sam ślad audytu. Brak „AI-silosu", w którym weryfikacje unikają audytu.
- Praktyczne zastosowanie: tworzenie notatek kontrolera dla niejednoznacznych dopasowań, pobieranie wcześniejszych spraw związanych z krajem lub programem, weryfikacja wsadowa list kontrahentów / statków / banków, podsumowanie warunków rozporządzeń prostym językiem.
- Nabywcy zgodności w 2026 są słusznie sceptyczni wobec AI. Warstwa agentów platformy zdobywa zaufanie, ponieważ jest ugruntowana, cytowana i zarejestrowana — a nie twierdząc „zaufaj nam, nasze AI jest inne".
Inteligencja agentowa
AI Assistant
Wyszukiwanie w konsoli
MCP Server
Zewnętrzni agenci
Zaindeksowane dane
Brak halucynacji
Screening Cases
Ta sama sprawa · ten sam audyt
Zaufanie do AI zdobywa się cytatami i rejestracją audytu — a nie mglistą obietnicą „z napędem AI".
12 · Status i wezwanie
Przed uruchomieniem. Dostęp testowy otwarty już dziś.
Partnerstwo zwrotne dla zespołów, które potrzebują obronnej weryfikacji bez korporacyjnego narzutu.
- Etap. Uruchomienie platformy produkcyjnej zaplanowane na lato 2026 roku.
- Dostęp testowy dostępny już dziś. Bez sześciocyfrowego minimum, bez sześciomiesięcznej integracji, bez wymogu działu zgodności. Dostępny dla zespołów dowolnej wielkości.
- Co zawiera dostęp testowy. Pełny Web UI, API i MCP Server; aktualne listy sankcyjne; bieżące środki TARIC; Screening Cases i ślad audytu.
- O co prosimy w zamian. Prawdziwe pytania dotyczące przepływu pracy, opinie o lukach w pokryciu, przypadki użycia integracji. Bez zobowiązania klienta płacącego.
- Obronna przejrzystość. Niepowiązany z Komisją Europejską. Nie zastępuje oficjalnych źródeł ani decyzji właściwych organów.
- Skontaktuj się. Napisz na sales@norvext.com
Kontakt
sales@norvext.com
Podziel się konkretnym przypadkiem użycia i oczekiwanym wolumenem — dostosowujemy dostęp pilotażowy wokół weryfikacji handlowych i regulacyjnych, przeglądu sankcji, przygotowania dowodów lub integracji API/MCP.
Załącznik A · Obsługiwane listy sankcyjne
Siedemnaście oficjalnych źródeł. Jeden przebieg weryfikacji.
Każda lista poniżej to oficjalne rządowe lub ponadnarodowe źródło — automatycznie synchronizowane, powiązane z pierwotnym wpisem i sprawdzane razem.
| Oficjalne źródło |
Organ |
Jurysdykcja |
| UN SC Consolidated List | UN SC | Organizacja Narodów Zjednoczonych |
| EU Consolidated Financial Sanctions (FSF) | Komisja Europejska / DG FISMA | Unia Europejska |
| EU Russia asset-freeze — Reg. 269/2014 | EUR-Lex | Unia Europejska |
| EU Russia — Reg. 833/2014 | EUR-Lex | Unia Europejska |
| EU Belarus — Reg. 765/2006 | EUR-Lex | Unia Europejska |
| OFAC SDN List | Departament Skarbu USA / OFAC | USA |
| OFAC Consolidated Non-SDN List | Departament Skarbu USA / OFAC | USA |
| UK Sanctions List | UK FCDO | Wielka Brytania |
| Swiss SECO Sanctions List | SECO | Szwajcaria |
| Canada Consolidated (SEMA) | Global Affairs Canada | Kanada |
| Australian Sanctions Consolidated List | DFAT | Australia |
| Japan MOF economic sanctions | Ministerstwo Finansów Japonii | Japonia |
| Ukraine State Register of Sanctions | NSDC Ukrainy | Ukraina |
| Estonian Government national sanctions | MSZ Estonii | Estonia |
| Latvia FID National Sanctions List | Łotewski FID | Łotwa |
| Latvian FID frozen-assets registry | Łotewski FID | Łotwa |
| Poland MSWiA national sanctions list | MSWiA | Polska |
Pokrycie w skrócie
5 wielostronnych / ogólnounijnych — Rada Bezpieczeństwa ONZ, EU FSF oraz trzy rozporządzenia EUR-Lex dotyczące Rosji/Białorusi (269/2014, 833/2014, 765/2006).
8 krajowych — Stany Zjednoczone (OFAC SDN + Non-SDN), Wielka Brytania, Szwajcaria, Kanada, Australia, Japonia, Ukraina.
4 z państw członkowskich UE — Estonia, Łotwa (lista FID + rejestr zamrożonych aktywów), Polska.
Jak źródła pozostają aktualne
Większość źródeł synchronizuje się codziennie; listy oparte na publikacjach odświeżają się przy każdej oficjalnej aktualizacji. Każde dopasowanie weryfikacji cytuje swoją listę źródłową, program i odniesienie prawne — zob. Załącznik B dotyczący algorytmów dopasowania.
Załącznik B · Algorytmy wyszukiwania close-match
Sześć ścieżek wyszukiwania działa równolegle. Wygrywa najsilniejszy sygnał.
Nazwy rzadko zgadzają się dokładnie. Trigram, token-sort, fonetyka, edit-distance, exact-token i identyfikator oceniają to samo zapytanie — wynik odzwierciedla najsilniejszą ścieżkę.
| # | Algorytm | Technologia | Co łapie |
|---|
| 1 | Podobieństwo trigramowe | pg_trgm · GIN | Nakładanie fragmentów trzyliterowych. Ivanov Ivan ↔ Ivanov Ivan Petrovich. |
| 2 | Trigram token-sort | pg_trgm · tokeny posortowane | Eliminuje efekt kolejności słów. Sirius Trading ↔ Trading House Sirius. |
| 3 | Double Metaphone | fuzzystrmatch | Ekwiwalencja fonetyczna. Ivanov ↔ Ivanoff, Mikhail ↔ Michael. Cyrylica jest najpierw transliterowana. |
| 4 | Levenshtein | levenshtein_less_equal() | Min-edit dla krótkich ciągów i literówek. Ivanov ↔ Ivanoff. |
| 5 | Exact token | tabela tokenów · btree | Lookup deterministyczny po aliasach/transliteracjach. Northbridge Trading Ltd ↔ zapisany alias. |
| 6 | Match identyfikatora | znormalizowane identyfikatory | Rejestracja, IMO, BIC/SWIFT, paszport, ID narodowy, ID podatkowy. Wymusza wynik 100. |
Model punktacji
raw = max(sygnał) × 100 przez sześć ścieżek powyżej.
+ bonusy: DOB zgodne +10, kraj zgodny +5.
− safety caps: single-token fuzzy-only zapytanie ograniczone do 84 (tier review) — "Ivanov" sam nigdy nie potwierdza tożsamości.
↑ override: dokładny match identyfikatora wymusza 100.
Tiery wyniku · próg domyślny 75
100 Dowód potwierdzony · 90–99 Hit (review manualny obowiązkowy) · 75–89 Review (zbadać przed zamknięciem) · <75 Słaby (nie zwracany przy progu domyślnym)
Załącznik C · VoP — Verification of Payee
Klasyfikacja close-match EPC288-23 nakładana na standardową weryfikację.
Pod Reg. (UE) 2024/886 nadawca musi zweryfikować nazwę beneficjenta — nie tylko jego bank. Nasz wrapper VoP bierze tych samych kandydatów sankcji z Załącznika B i klasyfikuje dopasowanie nazwy wg reguł EPC288-23.
| Wynik | Scenariusz | Logika | Przykład |
|---|
| MTCH | exact | równe po normalizacji | Jan Kowalski = Jan Kowalski |
| CMTC | s2a_levenshtein | edit-distance ≤ 2 | Muller ~ Mueller |
| CMTC | s2b_transposition | jedna sąsiednia zamiana | Smtih ~ Smith |
| CMTC | s2c_initial | inicjał + nazwisko | J Smith ~ John Smith · tylko osoba fizyczna |
| CMTC | s2d_phonetic | ekwiwalencja fonetyczna | Kowalsky ~ Kowalski · tylko osoba fizyczna |
| NMTC | no_match | żaden scenariusz nie wyzwolony | ABC Trading vs XYZ Logistics |
| NOAP | not applicable | nazwa zarejestrowana niedostępna | PSP beneficjenta nie zwrócił nazwy |
Klasyczny VoP vs nasz VoP
Klasyczny VoP pyta "czy nazwa beneficjenta zgadza się z posiadaczem rachunku IBAN?" — odpowiada PSP beneficjenta.
Nasz VoP pyta "czy nazwa beneficjenta zgadza się z kandydatem sankcji?" — wrapper na standardowej weryfikacji z Załącznika B z klasyfikacją close-match EPC288-23.
Normalizacja VoP · 6 kroków
1. Małe litery · 2. Ekspansja nordycka (ø→oe, ä→ae, ß→ss) · 3. Unaccent (é→e) · 4. Usuń sufiksy prawne (SIA, LLC, GmbH) · 5. Whitelist [a-z0-9\s] · 6. Skompresuj białe znaki
