> For the complete documentation index, see [llms.txt](https://docs.1kosmos.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.1kosmos.com/identity-verification/non-doc-verification/ssn-verification.md). # SSN Verification *** ## Overview SSN verification confirms that a US Social Security Number is valid, that it's associated with the user claiming it, and — depending on the data source — that the user's name, date of birth, and other identity attributes match the official record. It happens entirely from data the user provides; no SSN card scan is required. This makes it one of the lowest-friction verification methods available for US users. The trade-off is that SSN verification on its own is a lighter check than document + selfie — it confirms the SSN is real and belongs to the claimed individual, but it doesn't physically prove the person sitting at the device is that individual. Pair it with another signal (biometric, possession, or document) when assurance matters. ### What happens during SSN verification {% stepper %} {% step %} **The user enters their identity attributes** At minimum, the user provides their SSN, full legal name, and date of birth. Some flows also collect address. Inputs are masked client-side and transmitted over TLS to the verification service. {% endstep %} {% step %} **The SSN is structurally validated** Before any external lookup, the SSN is checked against known structural rules — valid area numbers, no known invalid ranges (such as the famous 078-05-1120 once printed on a sample card), and length/format. Obvious bad inputs are rejected immediately without burning a downstream lookup. {% endstep %} {% step %} **The SSN is verified against an authoritative source** The platform queries one of: * **eCBSV (Electronic Consent Based SSN Verification)** — the Social Security Administration's authoritative consent-based service. Returns a simple yes/no on whether the submitted SSN, name, and DOB match SSA records. * **Credit bureau attribute matching** — queries one or more of the major US credit bureaus (Equifax, Experian, TransUnion) for an identity record matching the submitted attributes. Returns a match score plus optional supplementary fields. * **Issuance and death indicators** — checks whether the SSN was issued before the claimed date of birth (a synthetic-identity signal) and whether it appears on the SSA Death Master File. The choice of source depends on the flow's configuration and the use case's regulatory requirements. {% endstep %} {% step %} **Result is returned** The verification returns a pass/fail decision plus the specific signals that informed it — match score, issuance check, death indicator, and any data-source-specific flags. If the result is inconclusive (common with thin-file users), the flow can route to a fallback verification method or to manual review. {% endstep %} {% endstepper %} ### Why this method works well | Benefit | What it means in practice | | --------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Extremely low friction** | A few text fields and 5–10 seconds to complete. No camera, no document, no upload. | | **Strong synthetic-identity detection** | Issuance-date and death-indicator checks catch a meaningful fraction of synthetic and stolen identities — failures document verification alone wouldn't detect. | | **Authoritative for US KYC** | eCBSV is SSA's own service; credit bureau matching is the basis of decades of KYC and CIP programs. Regulators understand and accept these. | | **Works for thin-document users** | Users without a passport or current driver's license can still verify if they're in the credit-bureau or SSA record. | | **Cheap to run as a fraud signal** | Even when document verification is the primary method, running an SSN check in parallel adds a useful independent signal at low cost. | ### Use cases where SSN verification fits * **Lightweight customer onboarding for US-only services.** Low-risk accounts (free tiers, content platforms, marketplace seller signup) where document verification would be over-collection. * **Customer Identification Program (CIP) under the USA PATRIOT Act.** Where rules allow non-documentary CIP, SSN verification is a foundational component. * **Re-verification at sensitive moments.** Confirm an existing user's SSN before allowing a tax-document download, a wire transfer, or a beneficiary change. * **Composite KYC.** Combine SSN verification with phone-based verification and a credit-bureau header match for a layered, document-free KYC that meets CIP requirements at very low friction. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.1kosmos.com/identity-verification/non-doc-verification/ssn-verification.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.