Skip to main content

Watchlists

Watchlists are the galleries that face duplicity check and document duplicity check search against. Each tenant (in case of SaaS) has its own isolated watchlists; the face of a new applicant — and their document name data — is compared against them to decide whether the person is new, returning, blocked, or already being processed.

The watchlists​

WatchlistWho is in itEffect of a match
CustomerActive, verified customers.Recognized as a returning customer — the attempt can be merged or updated instead of creating a duplicate.
BlocklistPeople to refuse — known fraudsters or otherwise unwanted.The predefined workflows reject the attempt; a face that is only similar (review band) is sent to manual review instead.
ReviewApplicants whose verification an operator still has to decide.The new attempt is flagged as review so it is judged together with the pending case.
In-progress (concurrent)Applicants whose verification is running right now. Internal, transient, not visible to the Company.Flags a second simultaneous attempt by the same person as concurrent.

Membership rules​

  • A person is represented by one watchlist member, tied to their Customer record.
  • A member is in at most one of the Customer, Blocklist and Review watchlists at a time — a person is a customer, or blocked, or pending, never two at once.
  • The watchlist of a member follows the state of the Customer: activating, blocking, or anonymizing a Customer moves or removes their member accordingly.
  • The face gallery and the name gallery are kept in step: whatever moves a face member moves the corresponding name-vector member.

How outcomes move members​

Workflow outcomes and operator actions move members between watchlists:

ActionEffect
Onboarding accepted as a new, unique customerMember added to the Customer watchlist.
Operator puts a Customer on the Blocklist, or puts a rejected attempt as new on BlocklistMember moved to or added to the Blocklist — the face (on tenants with the 1:N add-on, even when the face had never been enrolled before) and the document data.
Onboarding rejected because it matched a blocklisted personNo new member — the predefined workflows link the attempt to the blocked Customer. A custom workflow can add the attempt with the 1N_add_current_to_blocklist action.
Attempt held for manual reviewMember added to the Review watchlist until an operator decides.
Verification finishes (any outcome)The transient In-progress entry is removed.
Workflow merges the attempt into an existing CustomerThe attempt is removed from the search, so the person keeps a single member.
Customer anonymizedMember removed entirely, including the stored face template.

If a watchlist update cannot be applied at once, it is retried; an update that still fails is recorded, raises an alert for the operations team and is re-applied, so a blocklisted face cannot silently stay off the Blocklist.

Underlying data​

Watchlists do not store photos or readable names. The face galleries hold biometric templates; the name galleries hold non-reversible name vectors (see document duplicity check). The original images and data are retained separately (on the Stored tier) so that templates can be regenerated without asking users to re-enrol.

See also​