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.

Who can do this:Org ownerOrg adminOrg member— Members see it on requests they have access to.

What it does

When you verify a person you have already verified and approved in your organization, Certivant compares the new verification with that earlier one — the customer's file — and tells the reviewer what is the same, what changed in an ordinary way, and what conflicts.

It never blocks a legitimate change. A move, a renewed licence, a married name or a new phone number are all normal. Only a real conflict adds a review reason, and a review reason sends the request to a person — it never rejects on its own.

The comparison stays inside your organization. Nothing is compared with, or shown from, another organization's verifications.

How Certivant finds the customer's file

Public forms create a new applicant record for every submission, so Certivant does not rely on the record. It looks for your organization's earlier requests of the same person using, in this order:

Your own reference for the customer (the reference you send with the request or on the applicant).
The same email address, then the same phone number.

A match on a key is then confirmed: the date of birth must match, and so must the name or the document number. This keeps a shared inbox or a recycled phone number from linking two different people. The one exception is your own reference: if it matches but the date of birth is different, Certivant accepts the match and flags it — see Returning customer doesn't match the file below.

The file is the person's latest approved verification (its frozen verified-ID record). Deleted or erased verifications are never used.

What is compared

The Returning customer — compared with the file card on the request detail page shows one row per field, with a status:

Status	Meaning
Match	Same as the file.
Changed	Different in an ordinary way. No review reason by itself.
Conflict	Contradicts the file. Adds a review reason.
Unknown	Could not be compared (not read, not labelled on the document, or a different document). Never a conflict.

Field	Rule
Date of birth	Must match exactly. A different date is a conflict.
Name	Accents, word order and middle names are ignored. A different surname with the same date of birth and the same document is changed (marriage, divorce). A different name without that support is a conflict.
Email and phone	A new value is changed. It is noted as confirmed by code or not confirmed.
Address	A new address is changed — moves are normal.
Document	See below.

The card shows statuses and rule labels only. It does not copy the customer's personal data anywhere new.

Driver's licence and ID documents

Documents are matched by their number (and the document type and the issuing province or state, when known). Only values the document labels count — an expiry date printed without a label is unknown, never a conflict.

Situation	Result
Same number, later expiry and a later (or unreadable) issue date	Changed — document renewed. Legitimate even if the old card had not expired yet.
Same number, earlier expiry than on file	Conflict — Licence expiry conflicts with the file.
Same number, same issue date, different expiry	Conflict (high). One issue date cannot carry two expiry dates.
Same number, later expiry but an earlier issue date than on file	Conflict.
Different number (or another type, or another province)	Unknown — a different document, verified fresh like any first document.
Same number, same expiry	Match.
Same number, same card reference number ("Reference", "DD"), but different dates	Conflict (high). The reference number names one physical card and changes at every renewal or replacement — the same reference with other dates means the dates were altered.
Same number, new card reference number, same expiry	Match — replacement card (lost, stolen, address change).

A month-only expiry date counts to the end of that month.

Attempt history

Each new verification also records how often you verified this customer before and for which reasons. It counts every earlier attempt, not only approved ones. A person is found as described above. A business (KYB) is found by your reference or its registration number.

The card on the request detail page shows:

Verification N with your organization — every attempt, this one included — and how many were for this same reason.
How the earlier attempts for this reason ended: approved, rejected, in review, not completed, cancelled.
Already verified here for — the reasons this customer was already approved for, with a count and the last date.

"The same reason" means the same classified reason code. When the reason couldn't be classified, it means the same reason text.

The API returns the same data as attemptHistory on GET /api/v1/kyc/requests/:id. It is null for a first-time customer. Use it to decide what to do with a customer who keeps retrying, for example someone rejected three times for device financing:

"attemptHistory": {
  "totalAttempts": 4,
  "samePurposeAttempts": 3,
  "samePurposeOutcomes": { "approved": 0, "rejected": 2, "inReview": 0, "inProgress": 0, "cancelled": 0 },
  "previousOutcomes": { "approved": 1, "rejected": 2, "inReview": 0, "inProgress": 0, "cancelled": 0 },
  "verifiedPurposes": [
    { "purpose": "account_opening", "count": 1, "lastVerifiedAt": "2026-06-02T14:10:00.000Z" }
  ],
  "firstAttemptAt": "2026-03-11T09:00:00.000Z"
}

Only reason codes and counts are stored. Nothing comes from another organization.

Review reasons

These three reasons add a review step. None of them rejects.

Review reason	When
Licence expiry conflicts with the file (`licence_expiry_conflict`)	The licence number matches but the expiry or issue dates contradict the file, as in the table above.
Returning customer doesn't match the file (`returning_customer_mismatch`)	The date of birth conflicts, or the name conflicts, or two or more identity fields changed at once without being confirmed — a new name, an unconfirmed new email, an unconfirmed new phone. A renewal, a move or a contact confirmed by code never counts. A match on your own reference with a different date of birth is a possible account takeover and shows a red notice on the card.
Several addresses in a year (`address_change_frequent`)	The same person (found as above) used three or more different addresses in the last 12 months across their verifications, this one included.

Addresses are compared after being normalized (case, accents, punctuation, "Street" / "St.", apartment and unit notation, postal code), and kept only as a keyed hash.

Use it in policies and workflows

The policy designer and automation workflows can read these fields:

Field	Type	Meaning
`returning.isReturning`	true/false	The same person was verified and approved in your organization before.
`returning.conflicts`	list	Fields that conflict with the file: `dateOfBirth`, `name`, `document`.
`returning.changedFields`	list	Fields that changed in an ordinary way: `address`, `email`, `phone`, `document`, `name`.
`returning.addressCount12m`	number	Distinct addresses in the last 12 months.

The three review reasons can also be tested with reviewTriggers CONTAINS '…'.

Review KYC and KYB requests — the detail page where the card appears.
Fraud signals and face matching — the other review reasons.
Fraud Network — the cross-company fraud network and how it compares a new verification with other companies.
Policy designer — use the returning.* fields in your own rules.

Returning Customers

On this page