Step Configuration
Each HYPR Affirm verification step has its own configuration page. A step page covers what the step does, its prerequisites, its settings and defaults, what the requester sees, the data collected, and its results, retries and failure outcomes. For retry and failure-outcome behavior shared by all steps, see Injectable Outcomes and Retry Limits.
For the flow editor view, including which steps are available, how they are grouped and how to save or revert changes, see Configure Verification Steps.
Steps and the Data They Collect
The following table lists every step a verification flow can include, in the order the requester meets them. The order is fixed; the flow editor turns steps on and off but does not reorder them. Custom steps run after the step you choose for them.
| Step | Purpose | Data Collected from the Requester |
|---|---|---|
| Instructions | Lists the steps in the flow before it starts; always shown | None |
| Consent | Presents the consent notice, which the requester must accept to continue; always shown. See Consent Screen | The requester's acceptance |
| Login Identifier | Identifies the requester and looks up their directory record; always required | The username or email the requester types |
| Phone Number / Email Verification | Confirms that the requester controls the phone number or email address on file, optionally with a one-time code | The phone number the requester types, the chosen channel and the code the requester enters |
| Location | Checks the requester's location against the address on file and the location policy | The browser location, if the requester allows it, and the IP address of the connection |
| Identity Verification via Verified Credentials | Verifies an Entra Verified ID credential presented from Microsoft Authenticator | The Verified ID credential the requester presents |
| Document and Biometric Verification | Verifies a government-issued ID and, with Liveness Check, compares it with a live selfie, with optional Motion Detection, Dual Document and compliance checks | Images of one or two identity documents and, with Liveness Check, a selfie or video capture; a date of birth and address when Identity Verification With Document Issuer needs them and the directory lacks them |
| KYC Compliance Checks (AML / OFAC / Watchlists) | Options of Document and Biometric Verification that screen the requester against watchlists or check the document with its issuer | No capture of its own; uses the Document and Biometric Verification data |
| Photo ID and Liveness Capture | Compares a live selfie with a photo ID the requester captures or uploads | A photo of an ID and a selfie capture |
| Liveness-Only (Anchor Image) | Compares a live selfie with an anchor image from your directory, supplied by a User Image Directory Source customization | A selfie capture; see the step page for the document-upload fallback |
| Custom Verification Step | Runs your organization's own verification page, registered through the Code Customization API | Whatever your custom step collects |
| Approver Chat and Video | Places the requester in a live chat, with optional video, with the assigned approver | Chat messages and, if either party turns it on, live camera and microphone streams |
| Escalate to Live Chat | Sends a requester whose step failed to a live chat with an escalation approver at the end of the flow | As for Approver Chat and Video |
| Attestation | Requires an approver to approve or decline the requester's results before an outcome is issued | None from the requester; the approver's decision and notes |
| Verified Outcome | Defines what the requester receives after a successful verification | None |
| Unverified Outcome | Defines what the requester sees after a failed or denied verification | None |
For how Affirm handles document and biometric data, see Biometric Data and the Privacy Notice.
Profile Data Each Step Requires
Most verification steps compare what the requester presents against the profile held in your system of record. Use this table when you plan a flow, and again when you write a User Directory customization that has to supply the data.
| Step | Profile Data It Requires |
|---|---|
| Login Identifier | The login identifier itself must resolve to a record in the system of record. |
| Phone Number / Email Verification | A mobile phone number or an email address. |
| Location | The full postal address. |
| Document and Biometric Verification | First name and last name. Identity Verification With Document Issuer also uses a date of birth and an address, and asks the requester for them when the record lacks them. |
| Photo ID and Liveness Capture | None, unless the flow has a Custom Directory Source; the step then reads the requester's anchor image (see Liveness-Only). Otherwise it compares the captured selfie against the captured document. |
| Liveness-Only (Anchor Image) | An anchor image, supplied by a User Image Directory Source customization. |
| Approver Chat and Video | A manager identifier, unless an approver is configured explicitly on the flow. |
| Escalate to Live Chat | A manager identifier, unless an approver is configured explicitly on the flow. |
| Attestation | A manager identifier, unless an approver is configured explicitly on the flow. HYPR automated approval cannot be used with this step. |
| Verified Outcome | None. |
| Unverified Outcome | None. |
Choose steps whose required data your system of record holds. Each step you add raises the level of assurance and adds a step for the requester to complete. Select the set that meets your requirement rather than the largest set available.
Related
- Writing Affirm Code Customizations: supplying profile data from a system of record other than Okta or Entra ID
- Configure Verification Steps: steps table grouped by category, as the flow editor shows them
- Approvers and Escalation Approvers: approver chain configuration at the workflow level
- Injectable Outcomes and Retry Limits: per-step retry and failure-outcome configuration
- Network and Location Policy: policy-composition view for the Location step
- Escalation Policy: escalation policy driven by risk signals