Identity & verification

Verification establishes three separate things before anything about an account is disclosed: which record this is, whether the person on the line is who they say, and what they are entitled to hear. A caller ID match answers only the first. It does not tell you who is holding the phone, and it says nothing about what they may hear — but a floor that treats those as one question will read a balance to whoever dialled. So the platform keeps three questions apart. 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?”

Starting a verification session

The route binds the verification attempt to an existing interaction and uses numeric servicing IDs.

The response returns policy-selected prompts without expected answers, which is what stops the challenge from becoming its own crib sheet: an operator who can see the answer on screen is not verifying anybody. 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.

What the call returns

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 session is bound to the live interaction it protects, so assurance is attached to a conversation rather than floating loose on a customer record where a later call could pick it up. A standalone interaction-free session, a session read, and an explicit fail command sit under the same /verification/sessions family.

Five states, five disclosure limits

Verification is not reusable forever. Expiry, channel change, higher-risk action, contradictory signal, or handoff may require a new or elevated session — the person who passed on Tuesday’s call is a claim about Tuesday, and a transfer is precisely where a conversation changes hands without anyone noticing.

Factors and attempt counters

Knowledge visible in a portal, on a statement, in a public record, or in a breached credit file is knowledge an impostor can hold as easily as a borrower, so it cannot carry a challenge on its own. Configure independent possession, provider, authenticated-session, or approved document factors. Attempt counters and fraud controls are shared across workers, because three failed attempts on the phone followed by three fresh ones in chat is six attempts, and a per-channel counter would call it two.

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: proving who somebody is settles identity, and what they may do on somebody else’s loan was decided separately, by the borrower.

AI sees the state, never the answers

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. An agent that could grade its own challenge would be the only participant on the call able to decide it had passed.