Customer Identity Verification Exception Rate

A customer asks support to change account ownership or export sensitive data, but the usual identity check fails because the customer has lost their phone. Customer identity verification exception rate measures the share of eligible verification attempts that need an approved alternative, escalation or rejection because the standard path did not establish identity.

Define the event first, since one person can attempt verification several times, and specify attempt-based or case-based counting. NIST's digital identity guidance describes proofing exceptions and errors, including ways to support applicants who lack the usual evidence, while the UK Information Commissioner's Office advises verifying requester identity and the destination for information in access requests.

These are distinct contexts, not a single global identity policy. Define the standard path, since login, multifactor challenge and account records may provide different assurance for different actions, and risk-match the action, because viewing a public help article does not need the same proof as changing a payout account.

Check the source, as an email address or caller ID alone does not prove the person controls the customer account, and check the destination, since a requester may pass identity proof but ask for data to be sent to an unverified new address. Preserve accessibility, because people may lack a particular phone, document or device and an approved alternate route can protect access without weakening controls.

Review delegated access too, as an employee can be authorised by a company even if they are not the account owner, so confirm that role. Record the reason, since a lost authenticator, mismatched name, expired document, suspected impersonation and system outage are different exceptions, and set the outcome so that alternative verified, unresolved, denied and referred for investigation are reported separately.

Do not share sensitive data during the check, because verification is a gate, not an excuse to reveal account facts to help a caller pass, and avoid overcollection by asking for evidence proportionate to the action and retaining it under the privacy policy. Record timestamps so that the initial attempt, alternative evidence, final decision and any account action are distinct.

Track attempts, as repeated guessing can be an abuse signal but legitimate customers may also struggle with a broken flow, and separate false rejects, since a high exception rate might reveal accessibility or data-quality problems rather than widespread fraud. Check automated matches, because similar names, transliteration and outdated records can generate legitimate exceptions, and handle outages without inventing alternate controls ad hoc if the standard identity provider is down.

Use human review, with an approved escalation path and a traceable reviewer, for high-risk exceptions, and audit override use, since a privileged staff override without rationale can hide unauthorised changes. Show open cases, as a case stuck waiting for evidence is not a successful verification, report by action because billing changes, privacy requests and basic account support may have different exception rates, and keep the denominator honest, since excluding difficult cases makes the rate appear artificially low.

Pair it with outcome quality, because a low exception rate can mean a smooth process or weak checks, so review sampled decisions, and protect staff by handling a disputed identity neutrally rather than with accusations based on one mismatch. An exception should not disappear when an agent ultimately completes the task, because the rate tracks the difficult path while the outcome tracks whether access was correctly granted or withheld, so use the measure to improve safe, accessible verification without granting access from an unverified claim.