Multi accounts 1:N
While Identity Verification asks "is it the right person?", Multi accounts 1:N asks "does this face already exist somewhere else in the operator's base?".
What it does
Performs a segmented 1:N biometric search in the operator's base, cross-referencing the received face against all records associated with the same clientReferenceSegment. Detects whether the biometric is already linked to a different clientReference — indicating that the same person has created, or is attempting to create, multiple accounts with the same operator.
Adoption differentiator: accepts selfies already stored in the operator's base (taken months or years ago) for base hygiene purposes.
Inputs
- A process created via Create Process (Web & Native) or Create Process (API) with the
multi-accountsflow. - The user's selfie in
imageBase64(PNG, JPEG, or WebP; minimum 640×480; maximum 800 KB). - The
subject.clientReferencefield — unique identifier of the user in the operator's system.
Possible responses
| Response | Meaning |
|---|---|
reproved | Multi-account detected. The facial biometric is already linked to a different clientReference within the same segment. |
inconclusive | Multi-account not detected. The face is not registered under any other account in the operator's base. |
YES or NO responseMulti accounts 1:N does not return YES or NO — the absence of duplicity is represented as inconclusive, not as a confirmation that there will never be a risk.
Availability
| Surface | Supported |
|---|---|
| SDK (Android, iOS, Flutter) | — |
| Web (iFrame, Redirect) | — |
| API (headless, no SDK) | ✅ |
Valid combinations
Within the pipeline, Multi accounts 1:N may or may not be preceded by Liveness (when used by Unico), and is followed by Conditional Enroll — which registers the face only when the result is INCONCLUSIVE and for the first clientReference in that segment, preventing biometric pollution.
multi-accounts 1:N → Conditional Enroll
The search scope is controlled by the clientReferenceSegment field configured in the APIKey.