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.

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.

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.