> ## Documentation Index > Fetch the complete documentation index at: https://docs.didit.me/llms.txt > Use this file to discover all available pages before exploring further. # Cross-organization identity claims > How Didit reports identity evidence from other organizations without ever labelling a person as fraudulent — separate result dimensions, claim-scoped evidence, and the default-off sharing switch. ## 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: | Dimension | What it answers | Where it appears | | ---------------------------------- | ----------------------------------------------------------------------------------- | ------------------------------------------------------------------------ | | **Input integrity** | Was the capture live, unmodified and from a real camera? | Liveness warnings (`LIVENESS_FACE_ATTACK`, `VIRTUAL_CAMERA_DETECTED`, …) | | **Identity match** | Did the person match the identity they claimed, against a trusted reference? | Face match and duplicate-face warnings on the session | | **Behaviour and network evidence** | Have other organizations seen claim events for this same person that did not match? | `CROSS_ORG_IDENTITY_CLAIM_PATTERN` | | **Final decision** | What the session's status became | `status` on the decision payload | 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.