Practical guide
Sanctions data freshness: check the source and screening versions
Distinguish source imports, active versions, and completed customer screenings so a recent timestamp does not hide an outdated check.
On this page
Check which source version is active
Sanctions data freshness concerns both the source and the check that used it. In SanctionsKit, start with coverage for context, then use the workspace or authenticated GET /api/v1/sources for current state. A public source page is not proof that the source is active for screening.
GET /sources returns a data array. Read availability, fresh, currentVersion, qualification and lastImport. Qualification keeps implemented, fixtureTested, liveFetchTested, rightsApproved and activated separate. A newer import attempt can fail without replacing the active version.
Read the version retained by the actual result
Open the check in Screening history in the dashboard, or call GET /api/v1/results/{id}. Read sourceId, version, retrievedAt, publishedAt when supplied, and fresh in coverage. Keep versions.dataset, versions.matchingEngine and versions.policy with the result.
retrievedAt is the time of retrieval, not authority publication. publishedAt can be absent. createdAt is the screening time. Do not collapse them into one updated-at label or assume today's source state was true when an older check ran.
Treat stale or unavailable required coverage as unfinished work
Discovery helps plan a request; the screening checks source eligibility again when it runs. If required coverage fails, keep the error and leave the business task pending. An empty source choice or fabricated no_match is not a recovery.
Keep safe operation references and follow the error guide. Retrying a request does not repair a failed source refresh by itself. Confirm that a later successful result contains all intended coverage before calling the screening step recovered.
Example: publication, activation and screening happen separately
In the fictional timeline below, the first customer check uses an older source version even though the authority has published an update. Downloading and activating a file are separate from screening a customer against it. The sequence explains why a recent update can leave earlier results unchanged.
If the authority gives no reliable release time, leave it unknown. Do not substitute the retrieval time. Save source version IDs with both results so a later reviewer can tell whether new source facts or changed customer input explain a different outcome.
Scroll horizontally to compare every column.
| Time | Event | What the evidence establishes |
|---|---|---|
| 09:00 | Authority publishes an update | The publisher has changed its data. The provider has not activated it yet. |
| 09:05 | Customer screening completes | This result still uses the earlier source version. |
| 09:07 | Provider fetches the file | The download exists; validation and activation remain separate. |
| 09:12 | Validated snapshot becomes active | New screenings can use the new version; earlier results remain unchanged. |
| 09:20 | Customer rescreen completes | The new result can record the updated source version. |
Verify that monitored customers used the updated version
Compare Monitoring's lastSuccessfulAt and lastScreeningId with the result's coverage. An active new source version does not prove every customer has already been rechecked. A paused monitor or outdated saved identity needs separate attention.
Read Changes needing attention for new evidence, failed checks and recoveries. Open the current case when review is required. Acknowledge the event separately from deciding identity. Preserve the earlier result for comparison instead of rewriting its source version.
Keep the evidence needed to explain freshness
For a questioned check, keep its ID, selected sources, returned versions and timestamps, observed source status and remaining gaps. These show what you observed. They do not establish an instant-update guarantee.
Use monitoring reconciliation to verify the affected customers and follow-up work. For a legal effective date, read the authority's material. A provider's download timestamp cannot establish when the underlying measure took effect.
Sources and references
Authority and technical sources
SanctionsKit documentation
Frequently asked questions
Does a recent source import prove a customer was screened with it?
No. Open the customer's completed result and read its retained coverage version. Source import, activation and customer screening are separate events. A monitor may still be waiting, paused or failed after a source update.
What is the difference between retrievedAt and publishedAt?
retrievedAt records when the service obtained the source. publishedAt reflects publication information when the publisher supplies it. The latter may be unknown. Neither should be substituted for the legal effective date of a measure.
Can a newer failed import replace the version shown for an older result?
No. Read the active currentVersion separately from import attempts, and keep the historical result's version intact. A later attempt does not prove a new qualified version was activated or used by that check.
How do I verify recovery from stale required coverage?
Resolve the source issue, then inspect a later successful screening with the intended coverage and versions. Reconcile affected monitors and review events. A retry being queued or an endpoint recovering is not enough evidence by itself.