Identity Proofing in Benefits Systems: Measure Fraud Resistance, Access and Recovery Together
Back to Signal
State & LocalBenefits AdministrationAICompliance

Identity Proofing in Benefits Systems: Measure Fraud Resistance, Access and Recovery Together

August 24, 2026Jess Loban

The fraud problem is real; the denominator matters

The pandemic exposed benefits infrastructure to organized fraud at extraordinary scale. GAO's September 2023 estimate placed unemployment-insurance fraud between $100 billion and $135 billion for April 2020 through May 2023. That is an estimate of fraud across UI programs, not a measured total attributable solely to identity theft. GAO also distinguished estimated fraud from the much smaller amounts states had identified and recovered; DOL disputed the estimation methodology, and GAO defended it.

The operational response—document checks, liveness testing, device signals, and cross-program matching—addresses real weaknesses. But adding another check does not, by itself, establish that the overall service became safer. A control can catch a replayed identity while also creating an unresolved queue of legitimate applicants. Both outcomes belong in the assessment.

Treat friction as a cost, not a performance claim

A smartphone document check can be difficult for someone with an older device, unreliable connectivity, no stable address, or an identity record that does not match their current circumstances. Those are scenarios an agency should test with users, not assumptions that every member of a demographic group will fail. Nor should a failed check be treated as evidence that the person intended fraud.

Attackers may prepare specifically for a control, while legitimate users encounter it unexpectedly. A polished submission is not necessarily a trustworthy one, just as a difficult verification is not necessarily suspicious. A service must test both attack resistance and ordinary completion.

For each additional check, ask:

  • What risk does it address? Specify the attack, rather than accepting a general claim that a vendor uses AI.
  • What does it cost the applicant? Measure time, retries, inaccessible steps, and need for assistance.
  • What happens when it fails? Identify the recovery route and the staff accountable for resolving it.
  • What is the evidence of improvement? Compare confirmed outcomes with a baseline, including eligible users who could not complete the process.

Build risk-based verification with a safe recovery path

NIST SP 800-63A-4 distinguishes identity resolution, validation of evidence, and verification that the applicant is associated with that evidence. It calls for fraud management and usable redress, and describes options for people with different capabilities and resources. These guidelines are a design reference; a state must establish which requirements its own program has adopted.

Our implementation recommendation is to use risk signals to select an appropriate proofing path within the program's required assurance level. Low apparent risk is not permission to skip mandatory controls. Higher risk should trigger additional evidence or trained review, not an unexplained automatic conclusion that fraud occurred.

  1. Map the decision. Separate identity proofing from eligibility, authentication, and fraud adjudication. Passing an identity check does not establish eligibility.
  2. Specify escalation rules. Define how device, network, velocity, and identity-match signals combine, including what happens when data disagree.
  3. Preserve assisted alternatives. Offer accessible recovery and staffed resolution; protect those channels against social engineering as well.
  4. Connect to program processes. Provide appropriate notices, review, and appeal routes under the rules governing the benefit. Identity redress alone is not an eligibility appeal.
  5. Test the complete journey. Include applicants whose names changed, records are incomplete, devices fail, or documents require manual inspection.

The policy and technical teams need joint ownership. A vendor can return a risk score; the agency remains responsible for deciding what that score is allowed to do.

Measure access and fraud together

A dashboard that counts only blocked attempts cannot show whether the agency protected the program or obstructed it. We recommend tracking:

  • Confirmed fraudulent attempts, with the confirmation method and time lag disclosed.
  • Completion and abandonment at each step, without assuming all abandonment is fraud.
  • False rejections where outcomes can be established, plus the limits of that measurement.
  • Time to assisted resolution and the age of the oldest unresolved cases.
  • Reviewer reversals, complaints, and recurring data-quality problems.

Compare results across proofing paths and operational conditions while applying privacy controls to the measurement itself. Investigate disparities; a difference in outcomes is a reason to examine the process, not automatic proof of a single cause.

Keep the capability current

Synthetic identities, manipulated documents, and social engineering make static verification checklists inadequate. That does not establish that a particular AI product will detect them. Require a maintained threat model, representative testing, change records, and evidence that new controls improve the service before broad rollout.

Contracts should support controlled updates, access to decision records, independent testing, and recovery when a vendor service is unavailable. Retest after material model or policy changes rather than waiting for an annual renewal. Identity proofing is a continuing operational responsibility: precision means spending scrutiny where it helps while keeping a workable route open for the people the program serves.

Follow a legitimate failure into the recovery queue

Consider a hypothetical applicant whose document cannot be read on an older phone. The automated step fails. That tells the agency that this proofing attempt did not complete; it does not establish the person's eligibility or intent. A fraud-control dashboard that counts the event as a blocked impostor would overstate what the evidence shows.

Trace the alternative path with authorized test accounts. Can the person discover the next step, reach assistance, present acceptable evidence and obtain a decision within the service's operating requirements? At the same time, exercise an impersonator attempting to exploit that assisted route. The objective is a recovery process that serves legitimate users without becoming a bypass around required assurance.

Give the review team a shared case record showing the failed step, evidence already collected, allowed next actions and unresolved questions. Limit access to what each role needs. Requiring the applicant to restart repeatedly can create extra work without supplying better evidence; allowing a reviewer to disregard required checks creates a different risk. Specify which decisions the reviewer can make and when escalation is necessary.

Do not assign an outcome before the evidence arrives

An abandoned application is an observation, not a confirmed fraud finding or a confirmed wrongful exclusion. Some cases will remain unresolved. Report that uncertainty rather than forcing every event into a success or failure category that the evidence cannot support.

For a proposed control change, compare completion, confirmed attack outcomes and assisted-resolution workload over a defined period. Record changes in traffic, attack methods and measurement coverage. If confirmed fraud outcomes take time to establish, identify that lag in the report. A short-term increase in rejected attempts cannot alone show the net effect of the change.

The next useful investment might be stronger technical proofing, better source matching, clearer instructions or additional trained recovery capacity. Select the response to the demonstrated failure. A lower-friction route is appropriate only where it still meets the program's required assurance; a more demanding route needs evidence that it addresses a material risk and can be operated effectively.

Before widening deployment, have the program and security owners agree on the decision criteria, unresolved limitations and escalation capacity. The operating question is whether the complete service can establish trustworthy identity and resolve exceptions, not whether one screen stops more users.

Sources and further reading

For an agency balancing fraud controls with access to benefits, Spartan X’s work in security architecture, AI governance, and systems integration offers a way to bring the proofing technology and the service around it into the same design conversation.

Share this article
LinkedIn

BUILD WITH US

Ready to Solve Hard Problems?

Spartan X builds AI systems, autonomous platforms, and cybersecurity solutions for defense and national security.