Identity, credentials, and synthetic profiles
Separate identity proofing from login security and account behavior.
Three claims. Three kinds of evidence.
Enlarge to read every label and explore the connections
A real identity, control of a credential, and permission to act are different claims. Good systems preserve the distinction.
Start with the actor at the center.
Follow each spoke to its specific claim.
Keep evidence source and freshness with each claim.
A document looks real. The selfie looks real. The person behind the application may still be using someone else’s identity. Identity evidence is a collection of claims to test, not a single green badge that lasts forever.
Resolve the person behind the claim
- ResolveIdentify the claimed person
- ValidateCheck the supporting evidence
- VerifyConnect the applicant to that evidence
Identity proofing establishes confidence in a claimed identity. Authentication establishes confidence that an actor controls an authenticator. Authorization determines what that actor may do. Keep these concepts separate in the data model. A valid password cannot repair weak onboarding evidence.
Use multiple evidence types that answer different questions: does the identity exist, is the evidence valid, and does the applicant connect to it? Correlated checks add less confidence than they appear to. Two vendors may rely on the same underlying database. Record provenance and limitations, not just a final score. A rejected applicant also needs an accessible route to correct an error.
Identity work starts with the claim the product needs to establish. A low-risk account lookup, a new credit relationship, and a change to payout ownership do not necessarily require the same evidence. Collecting the maximum possible data for every interaction can increase privacy exposure and create a larger pool of sensitive material without resolving the real uncertainty.
Lantern can separate evidence into observed facts, provider assertions, and internal conclusions. An observed document image is not the same as a provider’s authenticity result, and neither is identical to the platform’s decision to permit an action. Recording the distinction allows the platform to revisit a conclusion when evidence expires or a provider reports an error. It also prevents a downstream team from treating a convenient boolean as proof of everything about a person.
Inside the mechanism. Identity resolution combines claims and evidence about a person or business. Keep the asserted identity, observed document, verification method, source, and unresolved conflicts separate. Similar names are weak identifiers; a shared address can be a household or office. False merges can contaminate many later decisions because the merged history appears more certain than the original evidence. Preserve reversible links and the reason for each resolution decision.
A concrete example. An applicant’s submitted identity must be connected to reliable evidence about the same subject. Similar text can refer to different people, while different text can refer to the same person. The matcher returns 139 candidates from 12,500 records. It identifies 39 of 42 known fictional identity matches and misses 3. After scoped suppressions and stale-evidence returns, review demand is 112. The example keeps identity resolution, control availability, and the final legal disposition separate.
When the assumption fails. The product treats a name similarity result as a verified identity. Use scoped attributes, source quality, and an exception path before granting the intended authority. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.
An applicant’s submitted identity must be connected to reliable evidence about the same subject. Similar text can refer to different people, while different text can refer to the same person.
- Proofing
- Confidence in an identity claim
- Authentication
- Confidence in control of an authenticator
Identity review specimen
Illustrative data; not a real customer record or a prescribed policy.
- Documentvalidated
Evidence appears valid
- Applicant linkunresolved
Possession is not yet established
- Actionassisted review
Accessible alternative route
The checks establish different facts
Preserve separate proofing and authentication states. The checks establish different facts.
- Failure mode 1avoid
- Treat login success as full identity proof. Credential control does not establish identity.
- Failure mode 2avoid
- Count two shared-data vendors as independent. Their errors may be correlated.
- Failure mode 3avoid
- Reject without correction route. Evidence errors can harm legitimate applicants.
Synthetic identity is a lifecycle problem
- ObserveCollect time-stamped identity claims
- ConnectFind relevant shared attributes
- EvaluateTest the claimed relationships
A synthetic profile combines identity elements into a constructed persona. Some elements can be genuine. A profile may build a long history before creating a large unpaid obligation. The useful signal is often inconsistency across time and relationships, not a single obviously false document.
Use an evidence graph that records when each name, address, device, account, and contact appeared. Shared attributes are leads, not verdicts: families and workplaces share infrastructure. Test whether the pattern is inconsistent with the claimed relationship. Preserve uncertainty in the case record so an analyst does not inherit a suspicion as an established fact.
Inside the mechanism. Synthetic identity risk can emerge over time through relationships among applications, contact details, credit behavior, devices, and payment destinations. No single unusual attribute establishes the conclusion. Compare the sequence with the claimed economic activity and consider legitimate thin-file customers. The system should retain observations and hypotheses separately. A later confirmed event can revise the label without turning every historical shared attribute into proof of coordinated misuse.
A concrete example. A fabricated profile can accumulate credible-looking history before a high-value action. The relevant unit is the account lifecycle, not one isolated application screen. The rule flags 466 of 16,000 account lifecycles. Of those flags, 230 meet the synthetic target, giving 49.36% precision. It misses 58 target events. Under the stated cost assumptions, residual loss and operating friction total $42,142. The important result is the connection between the population, action, capacity, and outcome—not one isolated score.
When the assumption fails. Evidence quality falls while the rule relies on accumulated activity as proof of legitimacy. Retain provenance and evaluate later authority changes against the full event history. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.
A fabricated profile can accumulate credible-looking history before a high-value action. The relevant unit is the account lifecycle, not one isolated application screen.
- Shared attribute
- A possible relationship
- Confirmed abuse
- Evidence supports a harmful pattern
Constructed-profile review
Illustrative data; not a real customer record or a prescribed policy.
- Addressshared by 12 applicants
Could have legitimate causes
- Deviceshared application history
Investigative lead
- Income historyinconsistent
Needs independent support
Shared data alone is not proof
Investigate inconsistent relationships with context. Shared data alone is not proof.
- Failure mode 1avoid
- Ban every shared address. Households and buildings create legitimate overlap.
- Failure mode 2avoid
- Ignore a mature account. Age does not prove legitimacy.
- Failure mode 3avoid
- Label all linked people as criminals. That exceeds the evidence.
Evidence freshness changes meaning
- ObserveRecord source event time
- AssessCompare freshness to the use
- RefreshObtain evidence when justified
An identity check describes what was established at a point in time. Contact details, documents, account control, and business ownership can change. Define refresh triggers according to the product and applicable duties. A high-risk destination change may justify a different action from an ordinary email typo correction.
Store observed_at, verified_at, source, and expiry separately. An event received today may describe information from last year. If a vendor returns an old record, the application should not label it newly verified merely because the API call was recent. Make stale evidence visible in the decision record and test the fallback behavior.
Inside the mechanism. Evidence has an observation time, a receipt time, and sometimes an expiry or expected refresh interval. A document may remain authentic while the address or ownership it records changes. Model freshness by the claim being used, not by one universal age limit. Keep stale, unavailable, contradictory, and verified states distinct. A refreshed record should reference the earlier conclusion and explain what changed rather than silently replacing the old decision evidence.
A concrete example. The platform has a past identity decision and a new request for a sensitive capability. The age of a decision and the age of its evidence are different facts. The case identifies 2,210 eligible records from a source population of 3,400. The required workflow completes for 2,144, but 32 completed records miss the illustrative internal target. Another 66 remain incomplete. Communication evidence covers 2,123 generated notices. Scope, completion, timeliness, and delivery are four separate properties of the customer outcome.
When the assumption fails. A current download date hides an outdated source record. Record source effective time, retrieval time, evidence scope, and refresh triggers. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.
The platform has a past identity decision and a new request for a sensitive capability. The age of a decision and the age of its evidence are different facts.
- Received today
- New delivery timestamp
- Current evidence
- Information remains fit for this decision
Freshness specimen
Illustrative data; not a real customer record or a prescribed policy.
- Vendor responseSeptember 17
Delivery date
- Source recordJanuary 4
Underlying observation
- Decisionrefresh required
Illustrative product rule
A fresh API call can return stale evidence
Track source age as well as response time. A fresh API call can return stale evidence.
- Failure mode 1avoid
- Use response time as proof date. That confuses delivery with observation.
- Failure mode 2avoid
- Discard every old record. Some historical facts remain useful.
- Failure mode 3avoid
- Refresh only after a loss. The control may be needed before exposure.
Design for legitimate exceptions
- FailIdentify the exact evidence barrier
- AssistOffer an approved alternate method
- LearnReview recurring failure patterns
Names change, documents expire, cameras fail, and people do not all have the same records. A proofing system that works only for a narrow population can reject honest customers at scale. Measure completion and error patterns across relevant groups using approved data and privacy controls.
Provide a secure alternative route for cases the standard flow cannot resolve. The alternative should maintain the needed assurance while reducing the specific barrier. Do not lower every control because one vendor fails. Compare assisted outcomes with automated outcomes to find recurring defects in document handling, transliteration, or accessibility.
A legitimate person may have an old address, a changed name, limited credit history, or a document that an automated reader handles poorly. These cases create uncertainty, not automatic proof of fraud. A proportionate exception path offers other relevant evidence and a trained review process. Measure how often customers enter that path, how long resolution takes, and whether the eventual outcome supports the initial concern. Otherwise, the apparent accuracy of the automated flow may come from quietly excluding the people it understands least well.
Inside the mechanism. Legitimate customers can have changed names, transliterated records, incomplete digital histories, or inaccessible authentication channels. An exception path should gather appropriate alternative evidence and preserve the same decision authority. Measure who enters the exception path, how long it takes, and where it fails. Removing a hard stop without controlling the alternate route can create a bypass; refusing all exceptions can create avoidable exclusion. The design problem includes both outcomes.
A concrete example. A document reader performs differently across formats and customer circumstances. The error path should distinguish uncertainty from a confirmed adverse finding. The rule flags 243 of 11,000 identity-check attempts. Of those flags, 79 meet the synthetic target, giving 32.51% precision. It misses 20 target events. Under the stated cost assumptions, residual loss and operating friction total $12,755. The important result is the connection between the population, action, capacity, and outcome—not one isolated score.
When the assumption fails. Unsupported documents produce both missed target cases and unnecessary customer flags. Use an accessible alternative-evidence path and evaluate outcomes across relevant segments. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.
A document reader performs differently across formats and customer circumstances. The error path should distinguish uncertainty from a confirmed adverse finding.
- Alternative method
- Different evidence with suitable assurance
- Uncontrolled bypass
- No evidence for the required claim
Assisted review record
Illustrative data; not a real customer record or a prescribed policy.
- Barriercamera cannot focus
Capture problem
- Alternativeapproved assisted capture
Same assurance objective
- Outcomeidentity resolved
Document the evidence used
Accessibility and assurance can be designed together
Offer a controlled alternative. Accessibility and assurance can be designed together.
- Failure mode 1avoid
- Approve anyone who complains. Pressure is not evidence.
- Failure mode 2avoid
- Permanently reject every capture error. Technical failure does not prove false identity.
- Failure mode 3avoid
- Ask for unrelated sensitive data. More data does not necessarily solve the barrier.
Minimize identity data exposure
- CollectUse purpose-limited evidence
- RestrictSeparate raw records from references
- RetainApply the approved lifecycle
Identity records can cause lasting harm if exposed. Keep raw evidence in a restricted store, use references in downstream systems, and log access. Limit exports and redact support views. Data needed for proofing does not belong in every analytics table.
Map retention to purpose, applicable requirements, and approved policy. Deleting an account should trigger a defined retention workflow rather than uncontrolled deletion of all evidence or indefinite retention of everything. Test restoration and backup behavior too. A record removed from the main application may still exist in exports, caches, and test environments.
Inside the mechanism. Separate the data needed to establish a claim from the data needed to explain a decision later. A token or scoped reference may serve routine operations better than a raw identity image. Restrict access by task and retain provenance without copying sensitive material into every case note. Logs should support investigation without becoming an uncontrolled identity database. Deletion and retention rules need to cover derived stores and exports as well as the original upload.
A concrete example. The decision needs a scoped verification result while raw documents contain much more sensitive information. Copying every artifact to every service creates unnecessary exposure. The case identifies 3,854 eligible records from a source population of 4,700. The required workflow completes for 3,738, but 56 completed records miss the illustrative internal target. Another 116 remain incomplete. Communication evidence covers 3,701 generated notices. Scope, completion, timeliness, and delivery are four separate properties of the customer outcome.
When the assumption fails. Document images enter general logs and support exports. Use limited assertions, controlled references, and purpose-based access to retained evidence. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.
The decision needs a scoped verification result while raw documents contain much more sensitive information. Copying every artifact to every service creates unnecessary exposure.
- Token reference
- Links a decision to protected evidence
- Raw document copy
- Contains directly identifying information
Access boundary record
Illustrative data; not a real customer record or a prescribed policy.
- Risk eventidentity-ref-19
Reference only
- Evidence vaultrestricted
Raw records stay here
- Support viewredacted
Minimum data for the task
Most consumers need a result rather than a document
Use restricted evidence storage and references. Most consumers need a result rather than a document.
- Failure mode 1avoid
- Copy documents into every log. That spreads sensitive data.
- Failure mode 2avoid
- Keep all exports forever. Retention needs a defined purpose and rule.
- Failure mode 3avoid
- Use production identities in test fixtures. Test systems do not need real customer documents.
Chapter connections
Continue with Account takeover and account recovery to follow the next part of the system. Use the glossary for terminology and risk mathematics for formulas and worked calculations.