Compliance
Operational compliance workflows · Web UI · API · MCP
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.
v7 · September 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 saved 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.
- Start from the register, not from a name. Pull a company from supported Latvian, Estonian, Polish, or Kazakh register data. Where the official record exposes officers or owners, add those related parties to screening.
- Produce defensible evidence as part of the workflow. Saved cases keep timestamps, source links, parameters, results, and reviewer context together.
- Start in the 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 supported integration workflows. The channel is a paid add-on on self-service plans and included with Enterprise.
- 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 when persisted. Web, API, and MCP can create the same Screening Case artefact; quick one-shot checks remain transient by design.
- Shared core. All three channels use the same core screening and source catalogue. Entitlements, persistence and output remain specific to each channel.
- Entitlements are explicit. MCP is included within each plan's limits; REST API access is an optional paid add-on, or included with Enterprise.
Ecosystem
REST API
Internal automation
Same data
Sanctions · TARIC · close-match
One audit trail
Screening Cases register
Shared core screening; saved checks use the common 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.
- A whole declaration at once. Check every line of a customs declaration in one run instead of code by code, and get a single justification report covering all of them.
Date-aware
Saved parameters
07 · Sanctions screening
150+ official sources. Every result tied to evidence.
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. A catalogue of 150+ official sources across sanctions, PEP/EDD, debarment, export control, maritime risk, regulatory watchlists, business registers, and customs reference.
- 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 · 14 examples from the 150+ catalogue
| Official source | Authority |
|---|
| OFAC SDN | United States |
| EU FSF | European Union |
| EU Russia (Reg. 833/2014) | European Union |
| EU Belarus (Reg. 765/2006) | European Union |
| UN SC Consolidated | United Nations |
| UK Sanctions List | United Kingdom |
| CH SECO | Switzerland |
| JP MOF | Japan |
| AU DFAT | Australia |
| CA SEMA | Canada |
| LV FID | Latvia |
| LV FID frozen-assets | Latvia |
| PL MSWiA | Poland |
| UA NSDC | Ukraine |
Each workflow selects the relevant source profile. Refresh cadence and freshness evidence follow the official publisher.
08 · ISO 20022 payment screening
Pre-flight screening for pain.001 and pacs.008.
The parser extracts the parties present in the message; a persisted case keeps the raw payload and evidence.
- Full-message parsing. pain.001 and pacs.008 XML is parsed as supplied. When a PaymentCase is created, the raw XML, SHA-256 hash, message metadata, and warnings are stored with it.
- Validation is explicit. Structural checks always run. XSD status is recorded as valid, invalid, or not configured; an invalid configured schema produces an integrity error.
- Role-aware participants. Banks, debtor, creditor, and any intermediary agents present in the XML are extracted independently. Missing required roles become warnings.
- Policy-based source selection. Each participant is screened using the source profile selected for the case — not an unconditional scan of every catalogue source.
- BIC resolution is evidence-led. Configured resolvers can add legal-name context. Unresolved identifiers and name conflicts remain visible rather than being silently inferred.
- Choose persistence. A quick screening run is transient; creating a PaymentCase stores participant results and the message evidence for review.
Brand promise · case-as-audit
The hard part isn't the screening. It's defending the result.
A persisted PaymentCase keeps the source XML hash, validation state, extracted participants, selected policy, and screening evidence together.
The audit trail is created when the workflow is saved as a case; one-shot runs are intentionally separate and time-limited.
09 · ISO 20022 participant roles
Six role classes are recognized. Only parties present are screened.
pain.001 and pacs.008 expose different chains; each extracted participant is evaluated independently.
| # |
Role |
pain.001 mapping |
pacs.008 mapping |
Entity |
What gets screened |
| 1 |
Sender Bank |
DbtrAgt (implied initiation) |
InstgAgt |
Corporate |
The initiating or instructing bank when present. BIC and resolved name evidence are screened under the selected source policy. |
| 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) |
Party |
The debtor details present in the XML. Names and available identifiers become screening inputs and evidence. |
| 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) |
Party |
The creditor details present in the XML. Names and available identifiers become screening inputs and evidence. |
Why model roles, not a fixed count
A pain.001 message normally has no intermediary-agent nodes; pacs.008 can carry several. The parser records the roles actually present and flags missing required roles for review.
10 · Screening Cases — the differentiator
Persist the checks that need an audit trail.
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.
- Persistent workflows join a case. TARIC look-ups, sanctions screenings against people/companies/vessels/aircraft, bank verifications, and ISO 20022 payment cases can travel together. Quick checks can remain transient.
- Lifecycle states drive workflow. Cases move through Open, Closed, and Archived; their items record Pending, Clear, Hit, Review, or Error with timestamps and reviewer context.
- Hits surface inside the case. Red "hits" badges, source-linked entries, reviewer notes — visible in case context, not buried in a separate alerting tool.
- What sets us apart. The large data vendors hand you screening results. Compliance Platform hands you the case those results belong to — the audit-ready artefact.
- 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, review the extracted participants and validation state, then persist the run when a durable case record is required.
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 source-grounded. It calls platform tools for TARIC, sanctions, entity, payment, and case data, and keeps tool evidence distinct from generated explanation.
- 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.
- Evidence remains attributable. Tool results carry source links and freshness context; generated summaries do not replace the underlying record.
- Persistence is explicit. Agent workflows can create the same Screening Case artefact as the Web UI; one-shot tool calls remain transient until the user chooses to save them.
- 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
Source-linked evidence
Screening Cases
Same case · same audit
AI trust comes from attributable tool evidence and explicit persistence, not an unsupported automation claim.
12 · Status & CTA
Ready for real compliance workflows.
A complete workspace for teams that need defensible screening without enterprise overhead.
- Access. Request a workspace and start with your first workflow.
- Available today. No six-figure floor, no six-month integration, and no compliance department prerequisite. Built for teams of any size.
- What access includes. Web UI and MCP within plan limits, live source-backed screening, TARIC measures, Screening Cases, and an audit trail. REST API access is an add-on on paid self-service plans and included with Enterprise.
- How we set it up. Tell us about the workflow, expected volume, and users. We configure the right plan, limits, and integration access.
- 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 configure workspace access for trade and regulatory checks, sanctions review, report evidence, or API/MCP integration.
Appendix A · Representative sources by layer
150+ official sources. Relevant coverage per workflow.
The anchor source in each screening layer is named below — the backbone, not the full list. The complete, always-current catalogue is browsable online.
| Layer |
Anchor sources |
| Sanctions · 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 |
| Export control · 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 |
| MDB debarment · 5 | World Bank · EBRD · Asian Development Bank · Inter-American Development Bank · African Development Bank |
| Maritime risk · 8 | Paris, Tokyo, Black Sea, Abuja, Riyadh, Caribbean and Viña del Mar Port State Control (bans + detentions) |
| Regulatory watchlists · 8 | Baltic supervisory, gaming and consumer-protection warning lists |
| Business registers · 8 | Latvia and Estonia enterprise registers · Poland KRS · Hong Kong Companies Registry · Japan NTA · GLEIF LEI |
| Customs + legal reference · 12 | EU TARIC · ECICS chemicals · EUR-Lex · EU Sanctions Map · EU AML high-risk third countries · EU VIES |
Coverage at a glance
151 enabled sources across ten categories. The table names the anchor in each layer; the full catalogue lists every source with its authority, jurisdiction and freshness evidence.
Browse the full catalogue:
compliance-mcp.com/sources
How the sources stay current
Refresh cadence follows each official publisher and is tracked with freshness evidence. A workflow selects the relevant source profile; every returned candidate identifies its source list, programme, and legal reference.
Appendix B · Close-match search algorithms
Six evidence signals. Exact identifiers remain decisive.
Exact-token and identifier paths are evaluated first; fuzzy and phonetic candidates run when needed, or together in deep-search mode. Name scores rank candidates for review.
| # |
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. An exact normalized identifier returns 100. |
Score model
Name score: the strongest applicable similarity or token-coverage signal, then entity-type safeguards.
Corroboration: exact DOB adds +10; a matching subject country adds +5.
Low-information caps: common one-token company queries cap at 70; single-token fuzzy/person and rare company containment cap at 84.
Phonetic-only cap: uncorroborated multi-token, company, and vessel phonetic-only candidates cap at 60.
Exact identifier: returns 100 and is exposed separately from name-only evidence.
Full methodology:
compliance-mcp.com/library/learning/entity-screening-algorithms
Score tiers · default threshold 75
The default candidate threshold is 75. A name score — even 100 — ranks a candidate; it does not confirm identity. Exact identifiers are the separate corroborating signal.
Appendix C · VoP — Verification of Payee
EPC-style close-match labels for screening candidates.
Reg. (EU) 2024/886 requires the payer's PSP to offer IBAN/name verification with the payee's PSP. This product function instead classifies the name distance to sanctions candidates; it is not bank account-holder verification.
| 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 |
input or candidate name unavailable |
comparison cannot be performed |
Regulated VoP vs screening classifier
Regulated VoP checks the payer-supplied payee name or identifier against the account-holder data held by the payee's PSP.
Screening classifier applies MTCH / CMTC / NMTC / NOAP-style labels to sanctions candidates returned by the platform. It supports review; it does not satisfy PSP VoP by itself.
References: Regulation (EU) 2024/886, Article 5c; EPC VOP Scheme Rulebook v1.1 (effective 20 September 2026).
Full methodology:
compliance-mcp.com/library/learning/entity-screening-algorithms
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
