Identity & verification
Separate record matching from assurance, bind verification to one purpose and session, limit disclosure by current assurance, and represent third-party authority independently.
Identification answers “which customer record might this be?” Verification answers “what assurance did this participant establish for this purpose now?” Authority answers “what may this participant receive or do?”
Verification lifecycle
Create a purpose-bound session
The current route binds the verification attempt to an existing interaction and uses numeric servicing IDs:
curl -X POST "$BASE/v1/servicing/verification/sessions" \
-H "Authorization: Bearer $TOKEN" \
-H "LendEasy-Tenant: demo-lender" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: verify-maya-account-access-call-91" \
-d '{
"customerRef": "412",
"interactionId": 3001,
"caseId": 1001,
"purpose": "ACCOUNT_DISCLOSURE"
}'The response returns policy-selected prompts without expected answers. Submit one complete attempt to POST /v1/servicing/verification/sessions/{sessionId}/answers; the operation updates the linked interaction’s assurance state and never echoes or logs raw answers.
Starting a session
curl -X POST "$BASE/v1/servicing/verification/sessions" \
-H "Authorization: Bearer $TOKEN" \
-H "LendEasy-Tenant: demo-lender" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: verify-maya-account-access-call-91" \
-d '{
"customerRef": "412",
"interactionId": 3001,
"caseId": 1001,
"purpose": "ACCOUNT_DISCLOSURE"
}'{
"sessionId": 7401,
"status": "PENDING",
"attemptLimit": 3,
"prompts": [
{ "questionCode": "RECENT_PAYMENT_AMOUNT", "prompt": "What was the amount of your most recent payment?" }
]
}Every implemented session is bound to the live interaction it protects. An interaction-free standalone session, a session read, and an explicit fail command remain roadmap direction under the same /verification/sessions family.
Disclosure matrix
| State | Permitted behavior |
|---|---|
| Unidentified | Generic greeting and safe routing only. |
| Identified, unverified | Non-sensitive process guidance; no account detail. |
| Verified standard | Facts permitted by the purpose and session assurance. |
| Verified elevated | Specifically approved higher-risk disclosure or action. |
| Failed/expired | Sensitive content sealed; alternate journey or handoff. |
Verification is not reusable forever. Expiry, channel change, higher-risk action, contradictory signal, or handoff may require a new or elevated session.
Challenge design
Do not rely solely on knowledge visible in a portal, statement, public record, or compromised credit file. Configure independent possession, provider, authenticated-session, or approved document factors. Attempt counters and fraud controls are shared across workers so channel hopping cannot reset them.
Authorized parties
A verified person still needs authority. Loan-party records represent borrower, co-borrower, guarantor, authorized representative, legal representative, and other supported roles with effective interval, scope, evidence, and verification. A limited authority to receive statements does not permit a payment, promise, address change, or contract modification.
AI boundary
AI workers see verification state and permitted disclosure scope—not challenge answers or raw identifiers. They cannot lower the required assurance, invent a satisfied factor, or continue sensitive disclosure after failure or expiry.