Point-in-time sanctions screening: "was this name on the list on that day"

A live sanctions check answers "today". An audit asks about a past date. How to screen as-of a historical date, why birth year beats a smarter name match, and what the endpoint does not cover.

Updated 2026-08-09

Most sanctions screening questions are about right now: is this new customer clean before I open the account? But a real slice of them are about the past — a compliance auditor asking whether a counterparty was listed at the time a transaction happened, not today; a dispute where the other side says "we were never sanctioned" and you need to check what the list actually said on that date. A live-only check cannot answer that, because sanctions lists change: names are added, delisted, aliases updated. This guide is about the asOf parameter and the parts of the response that make the answer defensible.

A live screen, and what a "clear" result actually promises

curl "https://api.temsor.com/v1/sanctions/screen?name=John%20Smith&type=individual&birthYear=1975&country=Turkey"

{
  "hitCount": 0,
  "highestScore": 0,
  "decision": "clear",
  "matches": [],
  "coverage": [
    { "source": "OFAC_SDN", "records": 270298, "lastRun": "2026-08-09", "archiveFrom": "2026-07-26" },
    { "source": "EU",       "records": 87486,  "lastRun": "2026-08-09", "archiveFrom": "2026-07-26" },
    { "source": "UN",       "records": 15165,  "lastRun": "2026-08-09", "archiveFrom": "2026-07-26" },
    { "source": "UK_OFSI",  "records": 77025,  "lastRun": "2026-08-09", "archiveFrom": "2026-07-26" },
    { "source": "CH_SECO",  "records": 129060, "lastRun": "2026-08-09", "archiveFrom": "2026-07-26" },
    { "source": "CA_SEMA",  "records": 85260,  "lastRun": "2026-08-09", "archiveFrom": "2026-07-26" }
  ],
  "notice": "Screening output is informational ... not legal advice and not a compliance decision. Confirm any hit against the issuing authority before acting on it; the source URL is included with every match."
}

The coverage block is not decoration — it tells you exactly which six lists were checked (US OFAC SDN, UN, EU, UK OFSI, Switzerland SECO, Canada SEMA), how many records each held, and when each was last refreshed. A "clear" result is only as good as that list — it means "not found in these six sources as of this run", not "not sanctioned anywhere by anyone".

Screening a past date

curl "https://api.temsor.com/v1/sanctions/screen?name=Usama%20Bin%20Ladin&type=individual&asOf=2026-07-28"

{
  "query": { "name": "Usama Bin Ladin", "normalized": "osama ladin", "asOf": "2026-07-28" },
  "hitCount": 2,
  "highestScore": 1,
  "decision": "match",
  "matches": [{
    "id": "eu:833",
    "score": 1,
    "source": "EU",
    "sourceUrl": "https://data.europa.eu/data/datasets/consolidated-list-of-persons-groups-and-entities-subject-to-eu-financial-sanctions",
    "primaryName": "Usama  Bin  Muhammed  Bin  Awad,  Osama  Bin  Laden",
    "matchedName": "Usama bin Ladin",
    "matchedNameKind": "aka",
    "listedOn": "2013-06-25",
    "firstSeen": "2026-07-26",
    "lastSeen": "2026-08-09",
    "delistedAt": null
  }]
}

matchedNameKind: "aka" means the hit came from an alias on the record, not the primary name — worth surfacing to a reviewer, since alias matches carry a different confidence than an exact primary-name hit even at the same score. firstSeen / lastSeen / delistedAt are what make a past-dated answer possible at all: they record when this archive first observed the entry and whether it has since been removed from the source list.

Be precise about what "point in time" covers here. This archive began recording daily snapshots on 2026-07-26. Ask for an asOf before that and you get the earliest snapshot held, with a warning saying so — not a reconstruction of what the list looked like years ago:

curl "https://api.temsor.com/v1/sanctions/screen?name=Test&asOf=2020-01-01"

"warnings": [
  "Archive begins on 2026-07-26; an asOf of 2020-01-01 predates it and the answer reflects the earliest snapshot we hold.",
  "Only one name part was supplied. A single surname rarely reaches the score floor, so this \"clear\" result does not mean the name is absent from the lists — screen with the full name."
]

The six source lists themselves are official and public; this endpoint has been taking daily snapshots of them since 2026-07-26, and that is the honest boundary of how far back asOf currently reaches.

Why transliteration and fuzzy matching matter

Names crossing from Arabic, Cyrillic or other scripts into Latin script rarely land on one spelling. The same person shows up as "Usama Bin Ladin" in one query and "Osama Ben Laden" in another — both should hit the same record:

curl "https://api.temsor.com/v1/sanctions/screen?name=Osama%20Ben%20Laden&type=individual"

{ "highestScore": 1, "decision": "match", "matches": [{ "matchedName": "Usama  bin  Laden", "matchedNameKind": "aka", "score": 1 }] }

A pure exact-string check would have missed this. Matching is normalisation- and alias-aware, and every match reports which name field it hit against (primaryName vs. matchedName with its matchedNameKind) so a reviewer can see why it fired.

Narrowing false positives: birth year beats a better name check

Common names produce common false positives — the fix is rarely a smarter name algorithm, it is supplying what you already have on file:

curl "https://api.temsor.com/v1/sanctions/screen?name=Usama%20Bin%20Ladin&type=individual&birthYear=1990"

{ "highestScore": 0.8, "decision": "possible" }

Same name, same source record — but a birth year that does not match any birth date on file drops the score from a full 1 ("match") to 0.8 ("possible") automatically. Pass birthYear and country whenever you have them; narrowing type to individual / entity / vessel / aircraft helps the same way. minScore (default 0.75) sets the floor below which a candidate is not returned at all.

What this endpoint does not do

No PEP data. All six sources are sanctions lists. Politically-exposed-persons screening is a different data category and is not covered here.
Not a compliance decision. The response says so directly — it is a lead for a human reviewer to confirm against the issuing authority's own record via sourceUrl, not an automated clear/reject verdict.
No reconstruction before the archive start date. asOf reaches back to 2026-07-26; earlier dates return the earliest snapshot with an explicit warning, not a fabricated historical state.

Frequently asked

What does asOf actually screen against?

A daily snapshot of the six source lists taken on or nearest to that date. The archive of snapshots begins on 2026-07-26; an asOf earlier than that returns the earliest snapshot held, flagged with a warning rather than silently treated as accurate.

Does this include PEP (politically exposed persons) screening?

No. All six sources — OFAC SDN, UN, EU, UK OFSI, Switzerland SECO, Canada SEMA — are sanctions lists. PEP data is a separate category and is not part of this endpoint.

A hit shows matchedNameKind "aka" — is that as serious as a primary-name match?

It means the name you searched matched an alias on the record rather than the primary listed name. It is still a real hit worth reviewing, but the field is returned specifically so a human reviewer can weigh alias matches differently from exact primary-name matches.

How do I cut down false positives on a common name?

Supply birthYear and country if you have them, and narrow type to individual/entity/vessel/aircraft. A wrong birth year alone can drop a full-score match down to "possible" — narrowing inputs works better here than trying to out-clever the name matching.

Endpoints used here

/v1/sanctions/screen

Open the reference, run it in the browser, no key required.