Data methodology

Verifex publishes reliability telemetry about the official sanctions and screening sources it ingests — how current each source is, whether it is reachable, how large it is, and when its contents changed. This page explains how those figures are produced and, just as importantly, what they do not establish. It describes the source catalogue and the source health and changes surfaces; for how a screening decision itself is made, see the matching methodology.

What each measurement means

• Operating mode — whether a source is refreshed automatically, refreshed by an operator, held as a frozen index, or not screened. It describes how the source is maintained, not a promise that a refresh ran.
• Freshness — derived from when Verifex last ingested the source successfully, relative to how often the publisher updates it. Freshness that cannot be established is unknown, never current.
• Active records — the count of currently-active rows Verifex holds for the source. A count that could not be read is unavailable; a source that genuinely holds no active rows is 0. These are different, and shown differently.
• Publisher endpoint reachability & latency — Verifex probes each source's official publisher endpoint weekly and records whether it answered and how quickly. Reachability is the share of those probes that succeeded over the last 90 days; latency is the median round-trip. This is our reachability of the publisher's endpoint — not Verifex API or service uptime, and not a claim about the publisher's own availability. Probes the publisher blocks (HTTP 403 — “automated access restricted”) are excluded from the percentage rather than counted as downtime, and a percentage is withheld until there are enough probes to be honest. One failed probe never changes a public state; a source is only marked degraded after repeated failures.
• Screening impact — the layer that matters. It is derived from data freshness, not from endpoint reachability. A publisher endpoint that is blocked or unreachable while the last verified dataset is still within its freshness policy has screening impact none. Only a dataset that is stale beyond policy is marked coverage restricted, and even then the screening API keeps reporting coverage honestly and fails closed rather than returning a false clear.
• Detected changes — Verifex stores a content hash of every version it fetches. A new hash is a detected change. Record-count deltas describe how the volume moved between versions; they can also reflect re-publications or format changes, not only additions and removals of parties.

The honesty rules

• A value that could not be read is shown as unavailable, never as zero or as healthy.
• Freshness that cannot be established is unknown, never current.
• Degraded, stale and frozen sources are listed, not filtered out — a source going bad must be visible.
• Cached figures carry the time the data was read, so the age of what you are looking at is always clear.
• History accrues going forward. It is not back-filled, because it cannot be reconstructed after the fact.

Fact and observation are kept separate

Everything on the /data surfaces is a Verifex observation — what our systems measured about a source. It is not law, not regulatory guidance, and not the source's own published data. Where Verifex draws a conclusion from an observation, it is labelled as analysis, not stated as fact. We do not restate a publisher's or regulator's position as our own, and we do not turn a measurement into a legal characterisation.

What this telemetry does not establish

• It does not reproduce a source's list or say whether a particular person or entity appears on it — that is answered per screening request and preserved in that request's evidence.
• It does not assert the legal force of any listing, or which sanctions regime applies to your business — that depends on your jurisdiction, nexus and risk policy.
• It does not certify that a source is complete or authoritative; it reports what Verifex observed about it.

Machine-readable versions of this telemetry are available at /api/public/data-sources, /api/public/source-health and /api/public/sanctions-changes, and as an RSS feed.