Unit 02 · Chapter 1 · 10 min read

Identity, credentials, and synthetic profiles

Separate identity proofing from login security and account behavior.

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

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.

Resolve the person behind the claim Resolve the person behind the claim — the flow Follow the sequence. Connect the applicant to that evidence. Resolve Identify the claimed person Validate Check the supporting evidence Verify Connect the applicant to that evidence — Follow the sequence. Connect the applicant to that evidence. Chapter sources · Open image

Resolve the person behind the claim Resolve the person behind the claim — the distinction These concepts answer different questions. Read each definition in the context of the section. Proofing Confidence in an identity claim Authentication Confidence in control of an authenticator — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Resolve the person behind the claim Identity review specimen Fictional teaching record. Accessible alternative route. Identity review specimen Illustrative data; not a real customer record or a prescribed policy. Document validated Evidence appears valid Applicant link unresolved Possession is not yet established Action assisted review Accessible alternative route The checks establish different facts — Fictional teaching record. Accessible alternative route. Chapter sources · Open image

Resolve the person behind the claim Resolve the person behind the claim — control and failure modes The checks establish different facts. The branches show why alternative designs fail. Control design Preserve separate proofing and authentication states. The checks establish different facts. Failure mode 1 Treat login success as full identity proof. Credential control does not establish identity. avoid Failure mode 2 Count two shared-data vendors as independent. Their errors may be correlated. avoid Failure mode 3 Reject without correction route. Evidence errors can harm legitimate applicants. avoid — The checks establish different facts. The branches show why alternative designs fail. Chapter sources · Open image

Synthetic identity is a lifecycle problem

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.

Synthetic identity is a lifecycle problem Synthetic identity is a lifecycle problem — the flow Follow the sequence. Test the claimed relationships. Observe Collect time-stamped identity claims Connect Find relevant shared attributes Evaluate Test the claimed relationships — Follow the sequence. Test the claimed relationships. Chapter sources · Open image

Synthetic identity is a lifecycle problem Synthetic identity is a lifecycle problem — the distinction These concepts answer different questions. Read each definition in the context of the section. Shared attribute A possible relationship Confirmed abuse Evidence supports a harmful pattern — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Constructed-profile review

Fictional educational excerpt / Not for execution

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

Fictional teaching record. Needs independent support. Chapter sources · Open image

Evidence freshness changes meaning

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.

Evidence freshness changes meaning Evidence freshness changes meaning — the flow Follow the sequence. Obtain evidence when justified. Observe Record source event time Assess Compare freshness to the use Refresh Obtain evidence when justified — Follow the sequence. Obtain evidence when justified. Chapter sources · Open image

Evidence freshness changes meaning Evidence freshness changes meaning — the distinction These concepts answer different questions. Read each definition in the context of the section. Received today New delivery timestamp Current evidence Information remains fit for this decision — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Evidence freshness changes meaning Freshness specimen Fictional teaching record. Illustrative product rule. Freshness specimen Illustrative data; not a real customer record or a prescribed policy. Vendor response September 17 Delivery date Source record January 4 Underlying observation Decision refresh required Illustrative product rule A fresh API call can return stale evidence — Fictional teaching record. Illustrative product rule. Chapter sources · Open image

Evidence freshness changes meaning Evidence freshness changes meaning — control and failure modes A fresh API call can return stale evidence. The branches show why alternative designs fail. Control design Track source age as well as response time. A fresh API call can return stale evidence. Failure mode 1 Use response time as proof date. That confuses delivery with observation. avoid Failure mode 2 Discard every old record. Some historical facts remain useful. avoid Failure mode 3 Refresh only after a loss. The control may be needed before exposure. avoid — A fresh API call can return stale evidence. The branches show why alternative designs fail. Chapter sources · Open image

Design for legitimate exceptions

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.

Design for legitimate exceptions Design for legitimate exceptions — the flow Follow the sequence. Review recurring failure patterns. Fail Identify the exact evidence barrier Assist Offer an approved alternate method Learn Review recurring failure patterns — Follow the sequence. Review recurring failure patterns. Chapter sources · Open image

Design for legitimate exceptions Design for legitimate exceptions — the distinction These concepts answer different questions. Read each definition in the context of the section. Alternative method Different evidence with suitable assurance Uncontrolled bypass No evidence for the required claim — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Design for legitimate exceptions Assisted review record Fictional teaching record. Document the evidence used. Assisted review record Illustrative data; not a real customer record or a prescribed policy. Barrier camera cannot focus Capture problem Alternative approved assisted capture Same assurance objective Outcome identity resolved Document the evidence used Accessibility and assurance can be designed together — Fictional teaching record. Document the evidence used. Chapter sources · Open image

Design for legitimate exceptions Design for legitimate exceptions — control and failure modes Accessibility and assurance can be designed together. The branches show why alternative designs fail. Control design Offer a controlled alternative. Accessibility and assurance can be designed together. Failure mode 1 Approve anyone who complains. Pressure is not evidence. avoid Failure mode 2 Permanently reject every capture error. Technical failure does not prove false identity. avoid Failure mode 3 Ask for unrelated sensitive data. More data does not necessarily solve the barrier. avoid — Accessibility and assurance can be designed together. The branches show why alternative designs fail. Chapter sources · Open image

Minimize identity data exposure

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.

Minimize identity data exposure Minimize identity data exposure — the flow Follow the sequence. Apply the approved lifecycle. Collect Use purpose-limited evidence Restrict Separate raw records from references Retain Apply the approved lifecycle — Follow the sequence. Apply the approved lifecycle. Chapter sources · Open image

Minimize identity data exposure Minimize identity data exposure — the distinction These concepts answer different questions. Read each definition in the context of the section. Token reference Links a decision to protected evidence Raw document copy Contains directly identifying information — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Minimize identity data exposure Access boundary record Fictional teaching record. Minimum data for the task. Access boundary record Illustrative data; not a real customer record or a prescribed policy. Risk event identity-ref-19 Reference only Evidence vault restricted Raw records stay here Support view redacted Minimum data for the task Most consumers need a result rather than a document — Fictional teaching record. Minimum data for the task. Chapter sources · Open image

Minimize identity data exposure Minimize identity data exposure — control and failure modes Most consumers need a result rather than a document. The branches show why alternative designs fail. Control design Use restricted evidence storage and references. Most consumers need a result rather than a document. Failure mode 1 Copy documents into every log. That spreads sensitive data. avoid Failure mode 2 Keep all exports forever. Retention needs a defined purpose and rule. avoid Failure mode 3 Use production identities in test fixtures. Test systems do not need real customer documents. avoid — Most consumers need a result rather than a document. The branches show why alternative designs fail. Chapter sources · Open image

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.

Sources

Reviewed 2026-09-17