# Identity Verification

## Identity Verification
**What it is.** The KYC layer that confirms a user is who they say they are before we let them see their credit data. We support **three verification flows** out of the box; one is selected per host (controlled by the `verificationType` setting). You don't have to build any of them yourself.
**What it's for.** Satisfying regulatory KYC requirements for credit-data access, preventing fraud during account opening, and (in the case of the Prefill flow) reducing form-fill friction during sign-up.
**Available flows.**
**[Digital Identity Trust + Secure Multi-Factor Authentication](/client-spec/identity-verification-(digital-identity-trust-+-secure-multi-factor-authentication))** *(default)*
The classic flow. The user fills in the full identity form (name, SSN, DOB, address, mobile, optional email). We run **Equifax's Digital Identity Trust (DIT)** check, scoring the data against credit, utility, phone, email, and device signals. The DIT decision is one of **Approved** (verification passes — proceed), or **Review / Denied** (verification rejected). If DIT approves, we send an **SMFA magic link** to the user's phone (SMS) and the user taps it to confirm device ownership. SMFA returns one of: **GREEN / YELLOW** = device confirmed, user enrolled; **ORANGE / RED** = denied; **INCOMPLETE** = user hasn't clicked the link yet.
**Email as a fallback.** Phone (SMS) is the **primary** delivery channel. Email is supported **only as a fallback** when the phone cannot be verified — for example when the mobile number fails carrier validation, SMS delivery fails, the user reports they cannot receive the SMS, or the phone verification returned **RED** or **ORANGE** (denied) and the user still wants to try via email. Switch to email by passing `type=email` on both `POST /users/smfa-send-link/{ditToken}` and `POST /users/smfa-verify-status/{smfaToken}`. Don't use email as the default for users who have a working phone number.
Resend cooldown: **30 seconds**. Magic link expires after **15 minutes**.
![Digital Identity Trust + Secure Multi-Factor Authentication flow](https://efx-dev.stitchcredit.com/api/DIT_SMFA.png)
**[Digital Identity Trust + Customer OTP](/client-spec/identity-verification-(digital-identity-trust-+-customer-otp))**
Same DIT identity check as the default flow, but you handle the device-confirmation step yourself. We return the DIT result to your backend; your application sends its own OTP via your existing SMS/email infrastructure, the user enters the code in your UI, and you call back to mark the verification complete. Choose this flow when you already operate an SMS or email OTP system you'd rather reuse — branding, deliverability, and carrier relationships stay in your control.
`/direct/verify-user` is a **liability boundary** — it records that you confirmed the user's identity through your own OTP system before CRS proceeds with enrollment.
![Digital Identity Trust + Customer OTP flow](https://efx-dev.stitchcredit.com/api/DIT_Customer_OTP.png)
**[Prefill + Onboarding](/client-spec/identity-verification-(prefill-+-onboarding))**
The lowest-friction flow. The user enters only their **first name, last name, and phone number**. Behind the scenes we look up identity data tied to that phone number and pre-fill the remaining KYC fields (SSN, DOB, address). To verify the device, we first attempt **Silent Network Authentication (SNA)** through the user's mobile carrier — this is invisible to the user and completes the verification in a single tap. If SNA isn't available, we automatically fall back to a **6-digit OTP** sent over SMS. Pair this flow with the **[Device Risk SDK](/client-spec/prefill-onboarding-sdk)** on the client to maximize the SNA hit rate.
![Prefill + Onboarding flow](https://efx-dev.stitchcredit.com/api/Prefill_Onboarding.png)

Version: v3

## Description:

  - `Identity Verification` ()
    What it is. The KYC layer that confirms a user is who they say they are before we let them see their credit data. We support three verification flows out of the box; one is selected per host (controlled by the verificationType setting). You don't have to build any of them yourself. What it's for. Satisfying regulatory KYC requirements for credit-data access, preventing fraud during account opening, and (in the case of the Prefill flow) reducing form-fill friction during sign-up. Available flows. Digital Identity Trust + Secure Multi-Factor Authentication (default) The classic flow. The user fills in the full identity form (name, SSN, DOB, address, mobile, optional email). We run Equifax's Digital Identity Trust (DIT) check, scoring the data against credit, utility, phone, email, and device signals. The DIT decision is one of Approved (verification passes — proceed), or Review / Denied (verification rejected). If DIT approves, we send an SMFA magic link to the user's phone (SMS) and the user taps it to confirm device ownership. SMFA returns one of: GREEN / YELLOW = device confirmed, user enrolled; ORANGE / RED = denied; INCOMPLETE = user hasn't clicked the link yet. Email as a fallback. Phone (SMS) is the primary delivery channel. Email is supported only as a fallback when the phone cannot be verified — for example when the mobile number fails carrier validation, SMS delivery fails, the user reports they cannot receive the SMS, or the phone verification returned RED or ORANGE (denied) and the user still wants to try via email. Switch to email by passing type=email on both POST /users/smfa-send-link/{ditToken} and POST /users/smfa-verify-status/{smfaToken}. Don't use email as the default for users who have a working phone number. Resend cooldown: 30 seconds. Magic link expires after 15 minutes. Digital Identity Trust + Customer OTP Same DIT identity check as the default flow, but you handle the device-confirmation step yourself. We return the DIT result to your backend; your application sends its own OTP via your existing SMS/email infrastructure, the user enters the code in your UI, and you call back to mark the verification complete. Choose this flow when you already operate an SMS or email OTP system you'd rather reuse — branding, deliverability, and carrier relationships stay in your control. /direct/verify-user is a liability boundary — it records that you confirmed the user's identity through your own OTP system before CRS proceeds with enrollment. Prefill + Onboarding The lowest-friction flow. The user enters only their first name, last name, and phone number. Behind the scenes we look up identity data tied to that phone number and pre-fill the remaining KYC fields (SSN, DOB, address). To verify the device, we first attempt Silent Network Authentication (SNA) through the user's mobile carrier — this is invisible to the user and completes the verification in a single tap. If SNA isn't available, we automatically fall back to a 6-digit OTP sent over SMS. Pair this flow with the Device Risk SDK on the client to maximize the SNA hit rate.