Skip to main content

​
The rule this page exists for

A face is a stable identity. It is not a fraud label, and Didit will not treat it as one. That distinction matters most in the case that motivated it: a real, consenting person attempts to verify under an identity that is not theirs. The attempt must be stopped. But three separate people must be left alone afterwards — that same person when they later verify with their own valid identity, the person whose identity was borrowed (who is the victim, not the offender), and anyone whose face merely looks similar. So fraud meaning is attached to an identity claim, which is an event, never to the person who made it or to the identity they claimed.

​
Four dimensions, four fields

A decision is never collapsed into one word chosen on your behalf. Each of these is reported independently, and you decide what your product does with the combination: A failed liveness check, an identity mismatch and a network pattern are three different statements about three different things. Reading them as one number is how a bad photo turns into an accusation.

​
Identity match needs a trusted reference

match and mismatch are only produced when there is something trustworthy to compare a face against — a government document portrait, or an identity already strongly bound to that face. An email address or a phone number with no prior strong binding gives you nothing to compare a face to. In that case the answer is no reference, never mismatch, and never a match inferred from face history alone.

​
What cross-organization evidence can and cannot say

When cross-organization sharing is enabled for your organization, a session can raise CROSS_ORG_IDENTITY_CLAIM_PATTERN. It means:
Other participating organizations recorded identity-claim events for this same person in which the claimed identity did not match the evidence on those sessions.
It does not mean the person is fraudulent, and no Didit response will ever say that. Three guarantees back this up:
  • It is suppressed when your own check passed. If this session’s own identity match is match, the warning is not raised at all. A person who verifies successfully against their own trusted reference is verified — whatever they may have been involved in before belongs to those claims, not to this one.
  • It cannot decline. The action is Review or No action. Setting Decline on cross_org_identity_claim_pattern_action is downgraded to Review, because history about a person may open an investigation into the current claim but may never reject it.
  • It is aggregate only. The payload carries how many organizations, how many mismatched claims, how many distinct identities were claimed and how recent — never who they are, never their sessions, never any of their data.
CROSS_ORG_FRAUD_FACE is the retired version of this warning and is no longer raised. It is kept as a value so existing logs and rules keep resolving; historical occurrences are records, not judgments about a person.

​
Face-only lookup: a person id, not a verdict

Recognising the same human being again is a separate capability from deciding anything about them. A face-only lookup returns a stable opaque person id for high-confidence repeat captures of the same face, and nothing else.
  • The id is a random identifier. It is not derived from a face, an embedding, a session, an organization or a customer reference, so it discloses nothing beyond “this capture was seen before”.
  • It carries no fraud state. There is no field on it that could.
  • A low-confidence or possible match never merges two people. Over-merging fuses two human beings into one identity and cannot be undone from the data; under-merging only costs recall.

​
Multi-account detection is same-organization and segmented

“Has this face opened several accounts with us” is a different product question from cross-organization evidence, and it is answered inside your own organization only. Set multi_account_segment on session create to give that search an explicit realm. Two sessions in different segments are never duplicates of each other, which is what lets you run separate personal and business account bases — or one segment per sub-client — without a person who legitimately holds one account in each looking like account farming. Omit it and every session sits in the single default realm, which is exactly today’s behaviour. Blocklist and allowlist matching deliberately ignore segments: a blocklisted face is blocklisted everywhere in your organization, so a segment can never be used to escape one.

​
Privacy

  • Faces never cross the organization boundary. The shared fraud index physically cannot hold one — the database rejects the write.
  • What does cross the boundary is a one-way keyed hash of an exact value (a document number, a device, an IP, a phone, an email) that a participating organization labelled as fraud.
  • Cross-organization reads answer with counts and recency buckets. The contributing organization is never named, and no raw value, image or session ever leaves.
  • Sharing is reciprocal and opt-in: an organization that does not contribute does not query.
  • Cross-organization face intelligence specifically is off by default and stays off until the data-protection impact assessment and legal review for the biometric-person identifier and the claim-event model are complete.