Fraud Signals and Face Matching
What the fraud signals on a Certivant KYC/KYB request mean — including face matching, which detects the same face used under another name or date of birth across every organization on Certivant without showing you anything about the other organization.
What it does
Every verification runs a set of fraud detectors. When one fires, it adds a
fraud signal to the request. Signals appear in the Fraud Signals card on
the request detail page and in the Needs review card, and they are part of
the API response (fraudSignals) and of the JSON results export.
Each signal has a severity:
- High — strong evidence of fraud. Some high signals send the request to manual review automatically.
- Medium — worth a look. Shown to the reviewer; does not force a decision.
- Low — informational.
Face matching
When an applicant's ID photo or selfie is processed, Certivant computes a face template — a list of numbers that describes the face, taken from the detected, cropped face only (never the whole card). The template is compared with the templates of earlier verifications across every organization that uses Certivant, not only yours. This is how a fraudster who reuses the same face with a new name at a different business gets caught.
The four face signals
| Signal | Severity | What it means | Effect |
|---|---|---|---|
| Face reused under another identity | High | The same face was already verified under a different name or date of birth — confirmed by a second, full face comparison. | The request is sent to manual review automatically. It is never rejected on this alone. |
| Possible face match | Medium | The face is close to an earlier verification, but the match is not confirmed. | Shown to the reviewer; no forced review. |
| Face seen before | Low | The same face was verified before under the same name and date of birth — usually the same person verifying again, or with another business. | Informational. |
| Face not indexed | Low | The face could not be checked: no face found, face too small, blurry, too dark or bright, glare, turned head, uncertain detection, the face search was unavailable, or the check timed out. | Informational — the reasons are listed in a small grey note. |
What you see — and what you never see
Match at another organization. The card says, for example, "This face was already verified at another organization under a different name and date of birth." That is all. You never see the other organization's name, its request, its applicant's name or picture — the server removes those details before anything reaches your browser, your API key, your webhooks or your exports. Your applicants are protected the same way when the match is found on another organization's request.
Match inside your organization. The card links to the other request by its 8-character ID ("Same face as request ABCD1234") and, when you are allowed to open both documents, shows the two faces side by side. If the other request belongs to a team you can't access, the card says so instead of naming it.
Every card also shows what differs (name, date of birth, document number), the similarity, and whether a second comparison confirmed the match.
Reviewing a face match
- Open the request and read the Face match block in the Fraud Signals card.
- For a match inside your organization, open the linked request and compare the documents and the applicants.
- For a match at another organization, treat it as a strong reason to look closer at this applicant's documents, selfie and data — then decide. Ask the applicant for more evidence or schedule a live ID verification if you are unsure.
- Approve or reject from the review panel as usual. Your decision and the signal are both kept in the audit log.
Consent
In public forms and on the hosted verification page, the consent panel asks the applicant to agree to the Face check before they upload anything. By default it is required: the applicant ticks the box to continue, and the selfie, liveness check and face match run. See The applicant experience.
Some laws require a non-biometric alternative (for example in Québec). Only there, switch on Let applicants skip the face check on the form (form editor → capture security options, off by default), or send faceCheckSkippable: true when you create the request through the API. The Face check box then carries an "Optional" tag, and the panel says, "If you don't agree, no selfie is taken: [organization] will verify your identity with you in a live video call." For verification links sent without a form, the organization setting in Verification settings (off by default) applies instead. The first match wins: faceCheckSkippable in the API when it is sent (true or false), then the form's switch, then the organization setting.
If the applicant refuses (possible only when the alternative is on):
- The selfie and the face and liveness check steps are skipped. The ID documents are still collected.
- No face match, no liveness check and no face fingerprint runs, so the applicant's face is not added to the fraud index.
- The request is sent to manual review. It is never auto-approved, and it is never rejected because of the refusal.
- The review reason Face check refused — verify in a live call (
biometric_consent_refused) is added, and the request page shows a card, "Face check refused — live verification recommended", with a Schedule live verification button.
You can use the code in policies and workflows, for example reviewTriggers CONTAINS 'biometric_consent_refused'.
In live ID verifications the Face check is a required purpose in the consent window too. It is not shown when the scheduler turned the full consent screen off: only video recording is asked then. When the alternative is on (set by the API, the request's form or the organization setting, in that order), the Face check is optional. An applicant who refuses it is not blocked and the call is not cancelled. Instead, that live session becomes the non-biometric alternative: the host compares the person's face with the ID visually on camera. Keeping a picture of an ID document for a person to look at isn't biometric, so the applicant can still send ID documents; only the selfie and the face check are turned off. See Without the face check.
Either way, the answer is kept as evidence with the verification: the purpose biometric_fraud_check, the wording version, when it was given, and the applicant's IP address and browser. A request.consent_recorded event is written to the audit trail.
Deletion
The face template follows the documents it came from: when a document or a request is deleted (manually, by your retention settings, after a decision, by an erasure or a data-deletion request), its face template is deleted too.
Driver's licence number check
In some places the issuer builds the driver's licence number from the holder's surname and date of birth. When the number on a licence doesn't fit the surname and date of birth Certivant read on the same card, it is a strong sign of a forgery or a mix-up. Certivant checks this for every driver's licence it reads and, when the number cannot belong to the holder, adds the review trigger Licence number doesn't match the name or date of birth (dl_number_mismatch).
| Region | What the number is checked against |
|---|---|
| Ontario | Surname initial, birth year, month and day |
| Québec | Surname initial, then day, month and year of birth |
| Nova Scotia | The first five letters of the surname, then day, month and year |
| Newfoundland and Labrador | Surname initial, then year, month and day |
| US states that use a Soundex number (for example Florida, Illinois, Wisconsin, Maryland, Michigan, New Jersey, and older Washington and New Hampshire numbers) | The American Soundex code of the surname and, where the state encodes it, the birth date |
| Great Britain | The first five letters of the surname, the decade and year of birth, the month and the day |
Other regions — and the other Canadian provinces, other US states, Northern Ireland and Minnesota — get no check, because their numbers do not carry the surname or birth date. The check is deliberately tolerant: it accepts the month either as written or with the offset some issuers add for women, and it does not enforce the sex a number implies, so it flags only a number that clearly doesn't fit.
A mismatch always goes to a person and never rejects on its own — a holder who changed surname after marriage can legitimately keep a number built from the old one. The reviewer sees the trigger in the verification's review reasons and the applicant sees the plain-language sentence "a person will review it". Policies and workflows can read it as document.dlNumberMismatch (true/false) — see the policy designer.
Other fraud signals
- Velocity — many submissions from the same applicant in a short time.
- Document reuse — the same document number on another profile in your organization.
- Document conflict — the documents on one request disagree on name or date of birth.
- Device reuse — the same device used by several identities. The number of people, the look-back window and the action are yours to set.
- IP velocity — many applicants from the same IP address.
- IP address used by several people — the same IP address behind several different identities within your window.
- Phone number / email address used by a different person — see Blocklist and duplicate detection.
- Blocklist match — the verification matches an entry on your blocklist. The card shows the type that matched (face, document number, phone, email, IP, device), never the value.
- Provider country mismatch — a bank or utility from a different country than the applicant's.
Related
- Review KYC and KYB requests — the detail page where signals appear.
- The applicant experience — the consent panel.
- Policy designer — use fraud signals in your own rules.
- Webhooks — signal types in webhook payloads.
Review KYC and KYB Verification Requests
Browse the Certivant KYC and KYB request list, use filters and bulk actions, and approve, reject, escalate, or override automated verification decisions from the detail screen.
Returning Customers
What Certivant does when you verify someone you already verified — it compares the new verification with the customer's file, tolerates a move, a renewed licence or a married name, and sends a real conflict to a person.