Compliance
Platform launch summer 2026 · Test access open today
Compliance Platform
Trade and sanctions screening with evidence.
CN / TARIC
Sanctions lists
Screening Cases
ISO 20022 payments
API + MCP
Not affiliated with the European Commission. Does not replace official sources or decisions by competent authorities.
v6 · 20 May 2026
02 · The challenge
The hard part isn't the screening. It's defending the result.
Compliance work fails when an answer can't be reproduced, sourced, or explained to an auditor.
- Sanctions lists, TARIC measures, and entity registers live across dozens of regulators. Combining them by hand burns reviewer time.
- Most tools give a yes/no result. Auditors want the source link, the timestamp, and the reviewer's reasoning.
- Aliases, transliterations, and local-name variants turn a clean "no match" today into a missed match tomorrow.
- TARIC checks, entity screenings, and vessel verifications accumulate across spreadsheets and email — not as a single auditable case.
- When a tool flags a match, reviewers can't always see why. That makes the decision hard to defend under audit.
- Engineers building internal automation are usually stuck scraping the same UI that compliance teams use.
Audit-defense gap
1
Many official sources
Sanctions lists, TARIC measures, entity registers
2
Manual combination
Spreadsheets, screenshots, email threads
?
Decision under audit
"Where is the evidence?"
A defensible result keeps data, source, parameters, reviewer, and timing together.
03 · Target audience + positioning
Compliance tooling was built for Tier 1 banks. Compliance work happens everywhere else.
The same regulatory exposure now reaches teams without enterprise compliance departments.
- Compliance tooling emerged after 9/11 and matured inside banks and Big Four consultancies. It still costs and configures like it.
- Same regulatory pressure, much wider field: multinational corporates, regional and SMB banks, logistics firms, customs brokers, regional airports, police task forces, notaries, and community services.
- These teams don't have a dedicated compliance department. The work falls to operations, legal, or the GM — done alongside their day job.
- They need defensible screening evidence just as much as a Tier 1 bank does — but can't justify a six-figure license or six-month integration.
- They need it accessible from where they work: a web tool the lawyer uses, an API the engineer integrates, an MCP server the AI agent calls.
- The compliance long tail is orders of magnitude larger than the bank/Big Four core — same regulatory exposure, far less tooling, no serious incumbent serving them.
The compliance long tail
Bank / Big Four core
Multinational corporates
Regional & SMB banks
Logistics firms
Customs brokers
Regional airports
Police task forces
Notaries
Community services
Same pressure. Far less tooling. No serious incumbent serving the full breadth.
04 · Main functionalities
Defensible compliance, without an enterprise compliance team.
The platform turns daily screening operations into evidence-ready decisions.
- Get a single source-linked answer to "is this OK to ship, process, or transact?" — across TARIC/CN measures, sanctions, and entity registers, not three separate tools.
- Produce defensible evidence as a side effect of the work. Every check is timestamped, source-linked, and reviewer-tagged automatically — no separate audit-prep ritual.
- Catch what manual review misses. Alias matching, transliteration variants, and local-name patterns surface candidates a yes/no scan would skip.
- Group related checks into a single case. TARIC look-ups, entity screenings, and vessel verifications travel together — one auditable artefact per decision.
- Use it from where the work happens. Lawyer in the web app, engineer via API, AI agent via MCP — same data, same sources, same audit trail.
- Start in the test workspace today. No six-figure floor, no six-month integration, no compliance department prerequisite.
Workspace status, enabled services, readiness, and recent checks in one consistent view.
05 · Channels
Three surfaces, one source of truth.
Reviewer, engineer, and AI agent use the same data underneath.
- Web UI — the full screening surface for direct reviewer use. Same data, same evidence, same audit trail as the other channels.
- API — REST endpoints for every workflow exposed in the UI. Build compliance into KYC onboarding, vendor due diligence, transaction monitoring, or any internal automation.
- MCP Server — exposes screening workflows as native tools for AI agents. Any MCP-capable client (Claude, ChatGPT Agents, custom) can call checks and receive source-linked evidence.
- One audit trail. A check run via API lands in the same Screening Cases register a UI-driven check does. The reviewer sees both. The auditor sees both.
- One source of truth. All three channels query the same sanctions data, the same TARIC measures, the same close-match logic. No "API version" vs "UI version" drift.
- API and MCP are first-class, not enterprise-gated. Available in the test workspace today, same as the Web UI.
Ecosystem
REST API
Internal automation
Same data
Sanctions · TARIC · close-match
One audit trail
Screening Cases register
No UI/API drift — same sources, same close-match logic, same case artefact.
06 · TARIC / CN code checks
One query, every applicable measure, source-linked.
Date-aware checks preserve the inputs that produced the result.
- Input what a customs declaration needs: the CN/TARIC code, the destination country, the relevant date. Optional narrowing — measure type, additional codes.
- Get back two layers in one report: a sanctions annex callout when applicable, plus the full TARIC measure picture — tariff suspensions, import/export controls, prohibitions, origin-specific rules — each with regulation reference, date range, and inline condition definitions.
- Every measure links back to its source — the underlying EU regulation or TARIC database entry. The report shows reviewers (and auditors) the reasoning, not just the verdict.
- Date-aware queries. Reproduce a check as of any prior date. Defend a past decision with the exact regulatory state that applied at the time.
- Saved parameters travel with results. The inputs that produced a check are preserved alongside the output. No "what did I search for?" gaps in the audit trail.
- Same check, every channel — web, API, MCP. Identical output, identical sources.
Date-aware
Saved parameters
Same output via API/MCP
07 · Sanctions screening
Seventeen lists. Every variant. One auditable result.
Official sanctions sources are browsable and linked back to the originating record.
- What gets screened. Names — people, companies, vessels, aircraft — together with aliases, local-name variants, transliterations, dates of birth, and identifiers (passport, IMO, BIC, registration numbers).
- What it's screened against. Seventeen official lists, maintained automatically (table opposite).
- Match logic catches what manual review misses. Aliases, transliterations, phonetic equivalents, and local-name patterns are evaluated alongside exact matches. Threshold is configurable per check.
- Every match comes with its source. Each hit links back to the originating list entry — list name, programme, regulation reference, listing grounds. The reviewer sees evidence, not just a verdict.
- Goods-level sanctions, too. The same workflow checks CN/TARIC codes against goods-restricting annexes (e.g., RU Reg. 833/2014 ANNEX XXIII), so an entity check and a goods check land in the same case.
- Browse the structured dataset directly. The Reference Library surfaces the listed-entities table — filter by programme, type, country, or source when verifying a source record outside an active screening run.
Data coverage · 17 sources
| Official source | Authority |
|---|
| OFAC SDN | United States |
| OFAC Non-SDN | United States |
| EU FSF | European Union |
| EU Russia (Reg. 833/2014) | European Union |
| EU Belarus (Reg. 765/2006) | European Union |
| EU Russia asset-freeze (Reg. 269/2014) | European Union |
| UN SC Consolidated | United Nations |
| UK Sanctions List | United Kingdom |
| CH SECO | Switzerland |
| JP MOF | Japan |
| AU DFAT | Australia |
| CA SEMA | Canada |
| EE national sanctions | Estonia |
| LV FID | Latvia |
| LV FID frozen-assets | Latvia |
| PL MSWiA | Poland |
| UA NSDC | Ukraine |
Lists maintained automatically. Goods-level sanctions checked against TARIC annexes simultaneously.
08 · ISO 20022 payment screening
Pre-flight screening for pain.001 and pacs.008.
A message-aware wrapper around the same engine. Raw payload preserved as audit evidence.
- Full Payload Mandate. The entire raw pain.001 / pacs.008 XML is preserved as an immutable binary artefact. Pre-filtered fields are prohibited — they break the chain of custody.
- XSD validation against official iso20022.org schemas. Structural failures raise an Integrity Error and hold the case in "Needs Review" until a reviewer records justification.
- 6-node participant model. Sender Bank, Ordering Institution, Ordering Customer, Intermediary Banks, Beneficiary Bank, Beneficiary — each screened against the same fourteen sources. Detailed on the next slide.
- BIC-to-entity resolution waterfall. Tier 1 GLEIF cache · Tier 2 real-time API · Tier 3 grounded LLM web search — source URL captured as immutable audit evidence.
- Unified Verdict + Persona Separation. One high-risk hit on any node flags the transaction. Person nodes get Person logic; Corporate nodes get Corporate logic.
- Conflict Detection. If the BIC-resolved name differs from the XML, the case raises a Data Integrity Warning — a defence against name-obfuscation.
Brand promise · case-as-audit
The hard part isn't the screening. It's defending the result.
Every state transition is timestamped and reviewer-tagged. Historical snapshots preserve the regulatory list state at the time of screening — defending against future "data drift" arguments.
For corporates, regional banks, notaries — anyone whose outbound wire exposes them to OFAC, EU, or UK sanctions liability — the case is the audit.
09 · 6-node participant model
Every pain.001 decomposes into six screenable participants.
Each node is screened independently. A high-risk hit on any one flags the transaction.
| # |
Role |
pain.001 mapping |
pacs.008 mapping |
Entity |
What gets screened |
| 1 |
Sender Bank |
DbtrAgt (implied initiation) |
InstgAgt |
Corporate |
The originating commercial bank. BIC resolved against all fourteen sources for ownership / jurisdictional sanctions. |
| 2 |
Ordering Institution |
DbtrAgt (Debtor Agent) |
DbtrAgt (Debtor Agent) |
Corporate |
The Debtor Agent identified in the XML. Often same as Sender Bank for direct pain.001 — but not always. Screened separately. |
| 3 |
Ordering Customer |
Dbtr (Debtor) |
Dbtr (Debtor) |
Person |
The originator legal entity initiating the payment. Person-logic screening (DOB, passport where applicable), full name match. |
| 4 |
Intermediary Banks |
N/A |
IntrmyAgt1 → IntrmyAgt[n] |
Corporate |
Correspondent chain. Often invisible to the originator but materially exposed if a sanctioned correspondent sits in the path. |
| 5 |
Beneficiary Bank |
CdtrAgt (Creditor Agent) |
CdtrAgt (Creditor Agent) |
Corporate |
The receiving institution. The most-often overlooked screening target — and the one that catches EU Russia / Belarus exposure under Reg. 833 / 765. |
| 6 |
Beneficiary |
Cdtr (Creditor) |
Cdtr (Creditor) |
Person |
The ultimate receiving party — counterparty legal entity or natural person. Person-logic or Corporate-logic per node type. |
Why six, not two
Most corporate-side tools check the Beneficiary (node 6) and stop. The real exposure sits in nodes 4 and 5 — intermediary correspondents and the beneficiary bank. A clean beneficiary at a sanctioned correspondent is not a defensible transaction.
10 · Screening Cases — the differentiator
Every check lands in a case. Every case is its own audit.
The decision artefact, not just raw screening output.
- The unit of compliance work is the case, not the check. One transaction, customer, or shipment generates many checks — but the auditor sees one decision. The case is the artefact of that decision.
- Every check joins a case. TARIC look-ups, sanctions screenings against people/companies/vessels/aircraft, bank verifications, and ISO 20022 payment screenings (pain.001 / pacs.008 messages) — all the threads of a single decision travel together.
- Lifecycle states drive workflow. Open → Needs review → Closed → Archived. Each transition is logged with timestamp, reviewer, and the state of data at the time.
- Hits surface inside the case. Red "hits" badges, source-linked entries, reviewer notes — visible in case context, not buried in a separate alerting tool.
- The differentiator from Refinitiv, Dow Jones, Sayari: they give you screening results. Compliance Platform gives you the case those results belong to — the audit-ready artefact, not the raw output.
- Reproducible later. Re-open any case to see exact parameters, hits, sources, and reviewer reasoning as they stood at the time. The audit isn't a separate task — the case is the audit.
ISO 20022
Payment screening, case-ready. Paste pain.001 / pacs.008 XML — the 6-node participant chain (slide 9) is screened against the same fourteen lists, evidence stored alongside the case.
The audit isn't a separate task — the case is the audit.
11 · AI Assistant + MCP
Same evidence trail. Now reachable by an agent.
The agent layer is grounded, cited, and recorded — not a parallel AI silo.
- The AI Assistant is a retrieval surface, not a generation tool. Ask which TARIC measures apply, which lists contain a name, which cases involved a counterparty — the assistant queries indexed data and returns cited results.
- MCP exposes the same workflows to external agents. Any MCP-capable client — Claude, ChatGPT Agents, custom — can call screening as a native tool and receive source-linked evidence.
- Both surfaces are grounded. No hallucinated regulations, no invented sanctions programs, no plausible-looking but fake citations. The agent returns what the platform indexes — nothing more.
- Agent-driven checks land in the same Screening Cases register. Web, API, MCP — same case, same audit trail. There's no "AI silo" of checks that escape the audit.
- Practical use: drafting reviewer notes for ambiguous matches, retrieving past cases involving a country or programme, batch-checking lists of counterparties / vessels / banks, summarising regulation conditions in plain language.
- Compliance buyers in 2026 are right to be AI-skeptical. The platform's agent layer earns trust by being grounded, cited, and recorded — not by claiming "trust us, our AI is different."
Agentic intelligence
AI Assistant
In-cabinet retrieval
MCP Server
External agents
Indexed data
No hallucinations
Screening Cases
Same case · same audit
AI trust is earned by citations and audit logging — not by a vague "AI-powered" claim.
12 · Status & CTA
Pre-launch. Test access open today.
A feedback partnership for teams that need defensible screening without enterprise overhead.
- Stage. Production platform launch planned for summer 2026.
- Test access available today. No six-figure floor, no six-month integration, no compliance department prerequisite. Available to teams of any size.
- What test access includes. Full Web UI, API, and MCP server; live sanctions lists; current TARIC measures; Screening Cases and audit trail.
- What we'd ask in return. Real workflow questions, feedback on coverage gaps, integration use cases. Not a paying-customer commitment.
- Defensive transparency. Not affiliated with the European Commission. Does not replace official sources or decisions by competent authorities.
- Get in touch. Email sales@norvext.com
Get in touch
sales@norvext.com
Share the concrete use case and expected volume — we shape pilot access around trade and regulatory checks, sanctions review, report evidence, or API/MCP integration.
Appendix A · Sanctions lists supported
Seventeen official sources. One consolidated screening surface.
Every list below is an official government or supranational source, synced automatically and linked back to the originating record — screened together in a single run.
| Official source |
Authority |
Jurisdiction |
| UN SC Consolidated List | UN Security Council | United Nations |
| EU Consolidated Financial Sanctions (FSF) | European Commission / DG FISMA | European Union |
| EU Russia asset-freeze — Reg. 269/2014 | EUR-Lex | European Union |
| EU Russia — Reg. 833/2014 | EUR-Lex | European Union |
| EU Belarus — Reg. 765/2006 | EUR-Lex | European Union |
| OFAC SDN List | U.S. Treasury / OFAC | United States |
| OFAC Consolidated Non-SDN List | U.S. Treasury / OFAC | United States |
| UK Sanctions List | UK FCDO | United Kingdom |
| Swiss SECO Sanctions List | SECO | Switzerland |
| Canada Consolidated (SEMA) | Global Affairs Canada | Canada |
| Australian Sanctions Consolidated List | DFAT | Australia |
| Japan MOF economic sanctions | Japan Ministry of Finance | Japan |
| Ukraine State Register of Sanctions | NSDC of Ukraine | Ukraine |
| Estonian Government national sanctions | Estonian MFA | Estonia |
| Latvia FID National Sanctions List | Latvian FID | Latvia |
| Latvian FID frozen-assets registry | Latvian FID | Latvia |
| Poland MSWiA national sanctions list | Polish MSWiA | Poland |
Coverage at a glance
5 multilateral / EU-wide — UN Security Council, EU FSF, and the three EUR-Lex Russia/Belarus regulations (269/2014, 833/2014, 765/2006).
8 national — United States (OFAC SDN + Non-SDN), United Kingdom, Switzerland, Canada, Australia, Japan, Ukraine.
4 EU member-state — Estonia, Latvia (FID list + frozen-assets registry), Poland.
How the sources stay current
Most sources sync daily; publication-driven lists refresh on each official update. Every screening hit cites its source list, programme and legal reference — see Appendix B for the match algorithms.
Appendix B · Close-match search algorithms
Six search paths run in parallel. The strongest signal wins.
Names rarely match exactly. Trigram, token-sort, phonetic, edit-distance, exact-token and identifier paths all evaluate the same query — the score reflects whichever path produced the strongest evidence.
| # |
Algorithm |
Technology |
What it catches |
| 1 |
Trigram similarity |
pg_trgm · GIN |
Three-letter fragment overlap. Ivanov Ivan ↔ Ivanov Ivan Petrovich. |
| 2 |
Token-sort trigram |
pg_trgm · sorted tokens |
Removes word-order effects. Sirius Trading ↔ Trading House Sirius. |
| 3 |
Double Metaphone |
fuzzystrmatch |
Phonetic equivalence. Ivanov ↔ Ivanoff, Mikhail ↔ Michael. Cyrillic transliterates first. |
| 4 |
Levenshtein |
levenshtein_less_equal() |
Min-edit count for short strings and typos. Ivanov ↔ Ivanoff. |
| 5 |
Exact token |
token table · btree |
Deterministic alias/transliteration lookup. Northbridge Trading Ltd ↔ stored alias. |
| 6 |
Identifier match |
normalized identifiers |
Registration, IMO, BIC/SWIFT, passport, national ID, tax ID. Forces score to 100. |
Score model
raw = max(signal) × 100 across the six paths above.
+ bonuses: DOB matched +10, country matched +5.
− safety caps: a single-token fuzzy-only query is capped at 84 (review tier) so "Ivanov" alone never auto-confirms identity.
↑ override: exact identifier match forces 100.
Score tiers · default threshold 75
100 Confirmed evidence · 90–99 Hit (human review mandatory) · 75–89 Review (investigate before clearing) · <75 Weak (not returned at default threshold)
Appendix C · VoP — Verification of Payee
EPC288-23 close-match classification, layered on standard screening.
Under Reg. (EU) 2024/886, the originator must verify the payee name — not just the originator's bank. Our VoP wrapper takes the same sanctions candidates from Appendix B and classifies the name match per EPC288-23 close-match rules.
| Result |
Scenario |
Logic |
Example |
| MTCH |
exact |
equal after normalization |
Jan Kowalski = Jan Kowalski |
| CMTC |
s2a_levenshtein |
edit distance ≤ 2 |
Muller ~ Mueller |
| CMTC |
s2b_transposition |
one adjacent swap |
Smtih ~ Smith |
| CMTC |
s2c_initial |
initial + surname |
J Smith ~ John Smith · natural person only |
| CMTC |
s2d_phonetic |
phonetic equivalence |
Kowalsky ~ Kowalski · natural person only |
| NMTC |
no_match |
no scenario triggered |
ABC Trading vs XYZ Logistics |
| NOAP |
not applicable |
registered name unavailable |
payee PSP did not return a name |
Classic VoP vs our VoP
Classic VoP asks "does the payee name match the IBAN account holder?" — answered by the payee's PSP.
Our VoP asks "does the payee name match a sanctions candidate?" — wraps the standard screening from Appendix B with EPC288-23 close-match classification.
VoP normalization · 6 steps
1. Lowercase · 2. Nordic expansion (ø→oe, ä→ae, ß→ss) · 3. Unaccent (é→e) · 4. Strip legal suffixes (SIA, LLC, GmbH) · 5. Whitelist [a-z0-9\s] · 6. Collapse whitespace
