About Verifex
Screening decisions should be explainable.
Verifex helps teams screen sanctions, PEP, and entity-risk data while preserving match reasoning, list versions, algorithm versions, and reviewable evidence for every decision.
Why we exist
Sanctions screening is not enough. Every decision needs evidence.
Screening tools often return scores or matches. Compliance teams still need to explain those decisions later — to auditors, banking partners, and regulators.
Audits and internal reviews require more than a risk level. They require proof: which lists were checked, which versions were active, what the match reasoning was, and why the decision was recommended.
Verifex is designed around decision evidence, not only matching. Every screening produces a structured, retrievable record that preserves the full context of the decision at the moment it was made.
What we build
Infrastructure for reviewable decisions.
Sanctions & PEP Screening API
Multi-source screening against sanctions, PEP, watchlist, and debarment lists. Exact, fuzzy, phonetic, and contextual matching with structured confidence scores.
Evidence Capsules
Structured JSON records that preserve query input, list versions, algorithm version, match rationale, adjudication reasoning, and a deterministic hash for every screening decision.
Benchmark Transparency
An internal benchmark test set with disclosed methodology, true positives, false positives, and edge cases. No sales call required to evaluate accuracy.
Sentinel-Tested Matching Engine
A continuously monitored matching pipeline that screens critical sanctioned entities across name variants, transliterations, aliases, and abbreviations — with regression testing after every change.
Decision evidence
Evidence Capsules preserve every decision.
Most screening tools return a risk level and discard the context. Verifex preserves a structured record — an Evidence Capsule — that reconstructs exactly why a decision was made.
Query input
The exact name, entity type, country, and date of birth submitted at screening time.
List version tracking
Which source lists were active, their ingestion timestamps, and version identifiers at the moment of screening.
Algorithm version tracking
The matching pipeline version and penalty configuration used to produce the result.
Match reasoning
Structured explanation of match stage, confidence derivation, penalty chain, and source context.
JSON evidence export
Export Evidence Capsules as structured JSON for integration into audit systems and compliance workflows.
Deterministic hash
Each capsule includes a tamper-evident hash so the record integrity can be verified later.
Accuracy
Matching accuracy should be measurable.
We publish a living benchmark with disclosed methodology, true positives, false positives, and edge cases. Anyone can evaluate Verifex accuracy without a sales call or an NDA.
Published test set
A vendor-authored benchmark covering exact matches, spelling variations, transliterations, phonetic matching, word-order changes, entity names, PEP screening, and adversarial inputs.
Disclosed methodology
How F1, precision, and recall are calculated — and what the benchmark does not cover.
False positive breakdown
Every false positive is categorized by cause and confidence level, with remediation status.
Open comparison
Results are compared against published research (OpenSanctions Pairs, Federal Reserve FEDS 2025-092) where applicable.
Matching engine
Regression-tested with sentinel entities.
The matching engine is continuously monitored against a set of critical sanctioned entities. If a code change causes a regression — a missed alias, a dropped transliteration, a false clear — it is caught before reaching production.
Name variant coverage
Full names, aliases, abbreviations, transliterations, and patronymic derivatives are tested across multiple scripts.
Cross-source validation
Critical entities are verified against multiple independent sources to reduce single-source blind spots.
Penalty pipeline
A 10-penalty scoring pipeline with contextual scoring, entity-type mismatch detection, and common-name disambiguation.
Continuous monitoring
Sentinel tests run on every deployment. Regressions block release.
Principles
How we build.
Evidence over black boxes
Every decision should be reconstructible. If you cannot explain why a name was cleared, the tool is not complete.
Explainability over opaque scores
Confidence scores are useful. Structured reasoning — match stage, penalties, source context — is necessary.
Regression testing over assumptions
The matching engine is monitored with sentinel tests for critical sanctioned entities. Changes are tested before they reach production.
Source transparency over hidden lists
We disclose which sources are checked, when they were last updated, and what version was active at screening time.
Developer-first infrastructure
REST API, structured JSON, webhooks, and clear documentation. No portal-first workflow that forces manual steps.
Compliance-safe wording
We provide decision-support evidence, not legal judgment or compliance guarantees. Final review is yours.
Product stage
What's available today
An honest, current status for every capability — kept in one shared registry so it stays consistent across the site. Pilot and beta features are exactly that; nothing here is presented as more finished than it is.
- Sanctions screening
- PEP screening
Included on Starter and above (not on the Free plan).
- Batch screening
POST /v1/screen/batch — up to 100 entities per request, plan-gated.
- Continuous monitoring
Re-screens saved subjects when lists change (POST /v1/watches).
- Webhooks
- Evidence Capsule
- Audit history
- Audit / evidence export
Available on Growth and above (CSV/JSON).
- GLEIF / LEI data
Global LEI company data that enriches KYB and entity screening — a data source, not a standalone lookup endpoint.
- UBO / ownership analysis
Included on Starter and above.
- OFAC 50% Rule
Computed through UBO ownership aggregation.
- Adverse media
Available on Growth and above (GDELT + LLM classification).
- Supplier risk
Composed from screening + debarment lists + KYB/UBO; no dedicated endpoint.
- Vessel screening
POST /v1/screen/vessel (name / IMO / MMSI).
- Pharmaceutical trade compliance
Delivered through the core screening / KYB / UBO APIs; no dedicated pharma engine.
- Embedded compliance
The REST API plus an embeddable widget.
- Python SDK
Published on PyPI (pre-1.0).
- Node.js SDK
Published on npm (pre-1.0).
- Go SDK
Published Go module (pre-1.0).
- Rust SDK
Published on crates.io (pre-1.0).
- Slack alerts
Slack notifications for monitoring/watch changes (per-user webhook URL).
- Email notifications
Email for monitoring changes and quota alerts.
- KYB (automated)
Automated KYB is UK company data via Companies House; requires configuration. Other jurisdictions are manual dossiers.
- Verifex Shield (fraud decisioning)
Real-time risk decisioning — in pilot; disabled by default and enabled per tenant.
- Manual KYB dossiers
Analyst-produced dossiers (e.g. Türkiye, Azerbaijan), sold separately.
Decision-support, not legal judgment. Verifex provides decision-support infrastructure. It does not replace legal judgment, regulatory advice, or a compliance team's final review. Every screening result should be reviewed in the context of your own risk-based compliance program.