Blocklist and duplicate detection

Settings → Fraud prevention holds two things: your blocklist, and the duplicate detection rules. Both work on every verification — individual or business — and both leave the final say with a person unless you choose to reject automatically.

The blocklist

Add anything you never want to verify:

Every entry has:

• When matched — Send to manual review (the default) or Reject.
• Reason — free text, visible only to your team.
• Expires on — optional. An expired entry stops matching and is hidden unless you tick Show expired entries.

Document numbers, phone numbers, emails and devices are never stored as plain values: the hash uses a key only Certivant holds, so the list cannot be read back. The list shows the masked hint only.

Add from a verification

Open a verification and choose Add to blocklist. The dialog lists what that verification carries — face, document number(s), email, phone, IP address, device — and you tick what to block. Things the verification doesn't have are greyed out. The values are never displayed.

A face can only be added when the verification has a stored face template (the applicant gave the identity fraud check consent).

What happens on a match

When an applicant submits, Certivant compares the verification with your active entries:

• The request gets a Blocklist match signal. The reviewer sees the type of match ("a blocked email address"), never the blocked value.
• With Send to manual review, the verification cannot be auto-approved: it goes to review with the trigger Matched the blocklist.
• With Reject, the verification is rejected. The applicant is told nothing about why; the explanation page only says an additional identity check is required.
• Policies and workflows can read fraud.blocklistMatch (true/false) and fraud.blocklistKinds (a list such as email, ip). See the policy designer.

A face matches when it is within the same distance used by the cross-organization face check, against your own entries only. Other organizations never see or match your blocklist.

Every add, change and removal is written to the audit log (blocklist.entry_added, blocklist.entry_updated, blocklist.entry_removed) with who did it, the entry type and the action — not the value.

Permissions

Owners and admins have all three. The Compliance officer role has all three; the KYC reviewer role can view; the Senior reviewer can view and manage the blocklist.

Duplicate detection rules

Each rule has an action, like the network risk settings:

For the device and IP rules you set how many different people and how many days. Leave the device threshold empty to use the platform default (3).

The same person verifying again never trips a rule. Two verifications are the same person when the email, or the name together with the date of birth, agree — so a retry, a renewal or a second document under a new applicant record is fine. Phone and email checks compare the name and date of birth directly (accents, name order and punctuation are ignored); when one side has no name or date of birth the result is "unknown" and nothing happens.

Lookups use the one-way indexes already kept for searching applicants — Certivant never scans plaintext. These rules don't run while your organization is in debug mode; the blocklist always does. The document-number rule (the same number on another person's verification) is automatic and unchanged — see Fraud signals.

How devices are recognised

In the hosted verification page and in public forms, the applicant's browser sends two privacy-conscious signals, both hashed before they leave the browser or before they are stored:

• a fingerprint of stable traits: browser, screen size, time zone, languages, platform, number of processor cores and how the browser draws a small canvas and reports its graphics card;
• a random device id kept in the browser's storage and a long-lived first-party cookie. It identifies a returning browser even if its traits changed (an update, a resized window). Clearing the browser's data resets it.

Neither value contains personal data, and neither is shown to you. Certivant HMACs both with a server key before storing them, and the applicant's consent text mentions that technical device and connection data is recorded to prevent fraud. A change in how the fingerprint is built restarts the device history, so after an upgrade the device rule needs a few verifications before it can match again.

Related

• Fraud signals and face matching — the signals these rules produce.
• Policy designer — use fraud.blocklistMatch, fraud.duplicatePhone, fraud.duplicateEmail, fraud.duplicateDevice and fraud.duplicateIp in your own rules.
• Automation workflows — react to the same facts.
• Blocklist API — manage the list from your own system.
• Age check — the default minimum age and buffer live in the same Rules card.