Screening

Verdicts & clearance

The Trust Layer derives verdict, risk_score and recommended_action from identity confidence, source severity and evidence sufficiency as separate signals. A risk level is not a clearance.

Screening verdicts

clear

Only a result that meets the canonical clearance contract may be presented as clear. A no-hit with incomplete coverage, a capped candidate set, or an ineligible mode remains unresolved.

possible_match

A match was found but key disambiguation fields (country, date of birth, entity type) are missing. Manual review is recommended.

confirmed_match

High-confidence match on a primary sanctions source with strong identity signals. Escalate to compliance immediately.

uncertain

The screening engine could not reach a confident conclusion. Review is recommended.

Important

possible_match is not a confirmed match

A possible_match means the system found a name similarity but lacks sufficient disambiguation data (country, date of birth, or entity type) to confirm identity. Always apply your own policy before taking action. Verifex provides screening evidence and decision support; it does not provide legal advice or final compliance determinations.

PEP vs sanctions

A source_severity: "pep" result comes from a Politically Exposed Person list. PEP hits require enhanced due diligence under most AML frameworks, but they are not sanctions block obligations. Verifex separates source_severity from confidence so compliance teams can apply the right policy for each source type.

What `critical` and `high` mean

The two bands answer different questions, and the difference is deliberate. critical means the party is designated and the identity is resolved: it requires corroborating identity evidence, specifically a matching official identifier or a full-precision date of birth. high means a designated party matched on name alone, which is a possible match rather than a confirmed one — so a name-only query, even an exact match at full confidence against a primary sanctions list, returns high and not critical. That is not a downgrade of the finding. It is the engine declining to assert an identity it has not established.

Because of that, branch on recommended_action, not on the band. A name-only sanctions hit returns manual_review with human_review_required: true, and it can never return auto_clear: the band already guarantees a risk score of at least 60, which is above the threshold at which an auto-clear is possible. An integration that blocks only on criticalwill route genuine sanctions matches to a review queue instead of stopping them, which is probably not what you intend. Supplying a date of birth or an identifier on the request is what lets a match reach critical.

The clearance contract

The most common integration mistake is branching on risk_level alone. A screening can return no matches because nothing was found, or because the sources were incomplete, the candidate set was capped, or the request ran as an Exact-Only lookup. Those are different facts and only one of them is a clearance. Every field below is returned on every screen.

Field	Type	What it means, and what it forbids
`screening_mode`	"standard" \| "exact_only"	Which screening contract produced this result. An `exact_only` result may never be read as a clearance. The mode deliberately skips fuzzy, phonetic, transliteration and typo recovery, so “no exact candidate” is not evidence the party is unlisted.
`clearance_eligible`	boolean	The engine's own answer to whether this result may be read as a clearance at all. When false, no combination of other fields makes the result clean. Treat it as unresolved regardless of `risk_level`.
`coverage_status`	"complete" \| "partial" \| "unavailable"	Whether every source the plan entitles was actually screened. Partial or unavailable coverage cannot clear. Absence of a hit in the sources that answered says nothing about the ones that did not.
`candidate_set_complete`	boolean	Whether the candidate set returned was the whole set, or capped. A truncated set cannot clear. No-hit inside a capped set is not no-hit: it is no-hit in the part that was examined.
`candidates_truncated`	boolean	True when the engine capped the candidate list for this request. Silently presenting a capped list as the complete set of possible matches.
`candidates_available`	number	How many candidates existed before the cap was applied. Reporting the returned count as though it were the number found.
`candidate_cap`	number	The cap that was applied. Leaving the caller unable to tell how much was withheld.
`retrieval_limitation`	"non_latin_no_match" \| absent	Present when a no-match is not a clearance because of a known retrieval limit. "non_latin_no_match": the name is in a non-Latin script and nothing was returned. These results carry risk_level "medium" with total_matches 0, so an integration that reads only risk_level still routes them to review. Treating a non-Latin no-match as cleared. Matching across scripts is not verified for every list; review it, and screen the Latin spelling as well.

Standard Screening vs Exact-Only Lookup

Standard is the recall-oriented compliance workflow: fuzzy, phonetic, transliteration and typo recovery all run, and a no-hit result with complete coverage can earn a clearance.

Exact-Only (screening_mode: "exact_only") deliberately skips all of that. It is a lookup, not a compliance screen, so an Exact-Only no-hit is never a clearance: it means no exact string matched, not that the party is unlisted. The API returns clearance_eligible: false on these results, and no other field can override it.

Candidate lifecycle

A returned candidate is not a match, and a match is not a confirmed identity. Collapsing these stages is how a lookup result becomes a reported sanctions hit.

Retrieved candidate: A record the search returned for comparison. It is a lookup result, not a statement about the party.
Potential match: A candidate whose identity evidence is consistent enough to warrant review. Still not a confirmed identity.
Analyst-confirmed identity: A human adjudicated the candidate as the same party. Only this stage supports a confirmed-match consequence.
False positive / unresolved: Adjudicated as a different party, or left undecided. Unresolved is not clean: it is undecided.