The identity check happens once. The money moves every week.

Unemployment insurance made an estimated $5.6 billion in improper payments in fiscal 2025, and states have spent heavily on identity verification at the front door. The front door is not where the money leaves. It leaves at the weekly certification, which is a web form behind a password.

It is Sunday evening in a state that runs its weekly certifications on a Sunday to Saturday cycle. A claimant opens the state workforce agency portal on a phone, signs in, and answers the same four questions as last week. Were you able to work. Were you available for work. Did you look for work. Did you earn anything. Four radio buttons, a checkbox affirming that the answers are true under penalty of perjury, and a submit button. Payment lands Wednesday.

Now run the same evening from a different chair. Someone in another country has the claimant's credentials, bought in a bundle after a data breach or harvested by an infostealer from the claimant's laptop. They sign in first. They answer the same four questions, because the answers are obvious and the script that fills them takes under a second. Before submitting, they change the payment destination to a prepaid card they control. Payment lands Wednesday, in their account.

The claimant finds out on Thursday, or the following Monday, or three weeks later when they finally get through on the phone. By then the money has been moved twice more.

Here is the part that should bother anyone who works on this problem. That state may have spent millions of dollars on identity proofing. The claimant may have stood in front of a camera holding a driver's licence, waited in a video queue, and been verified to a high assurance level. All of that happened once, at filing, possibly months earlier. None of it was present on Sunday evening. The control and the loss are in different places.

How much of the $186 billion is actually fraud?

Start here, because almost every article about this topic gets it wrong in the first paragraph, and the people who work in program integrity stop reading at that point.

The Government Accountability Office reported that federal agencies estimated roughly $186 billion in improper payments across dozens of programs in fiscal year 2025 (GAO, Payment Integrity report GAO-26-108694; some contemporaneous reporting cited a slightly lower figure of about $183 billion, and the difference comes down to which programs are counted). Within that, the Department of Labor's unemployment insurance program accounted for about $5.6 billion, at an improper payment rate near 15 percent, which places it among the higher rate programs the GAO tracks (GAO figures as summarised by the Bipartisan Policy Center and Federal News Network).

An improper payment is not a fraudulent payment. This is the single most important sentence in this post.

What an improper payment actually is

The federal definition covers any payment that should not have been made, or that was made in an incorrect amount, and it also covers payments where the agency lacked sufficient documentation to tell either way. That last category is large. A payment can be recorded as improper because a claimant did not log a work search correctly, because an employer reported wages late, because a state applied an eligibility rule inconsistently, or because a file that would have proved the payment correct was never attached.

So when you read that a program made billions in improper payments, you are reading a number that mixes at least four different things:

• Documentation failures. The payment may well have been correct. Nobody can prove it.
• Eligibility errors. A real person, correctly identified, paid the wrong amount or paid when a rule said they should not have been.
• Claimant error. Someone reported part time earnings in the wrong week.
• Fraud. Someone deliberately obtained money they were not entitled to, which itself splits into eligibility fraud by real claimants and identity fraud by people impersonating others or inventing them.

Identity fraud is one slice of the fourth bucket. It is not the whole $5.6 billion and anyone who tells you it is has something to sell. What makes it the slice worth writing about is not its size relative to the total. It is that it is the only slice where a technical control can be deterministic. You cannot cryptographically prevent a state from misapplying an eligibility rule. You can cryptographically prevent a payment to someone who cannot produce the enrolled claimant's signature.

Why did the pandemic break unemployment insurance so badly?

The scale of pandemic era losses was extraordinary. GAO estimates cited in congressional testimony have placed fraud in pandemic unemployment programs in the range of $100 billion to $135 billion (GAO analysis, as cited in House Ways and Means Committee materials, March 2026). It is worth understanding how that happened, because the standard telling is unfair and the unfair version leads to bad policy.

State unemployment systems were built for a caseload measured in tens of thousands. In the spring of 2020 they received millions of claims in weeks. At the same moment, Congress created new benefit categories, most significantly one covering self employed and gig workers who had no wage records in any state system. That last detail matters more than any other. The entire fraud control model of unemployment insurance rested on cross referencing a claim against employer reported wages. A program deliberately designed to pay people who have no employer wage record removed the load bearing wall.

Agencies were also told, correctly, that people needed money in days rather than weeks. Every verification step you add is a day of delay for a person who cannot buy groceries. Faced with that instruction, on systems written in COBOL, with call centres melting down, states relaxed checks. Criminal groups noticed within days.

None of that is carelessness. It is the entirely predictable result of asking a system to do something it was not designed for while simultaneously removing its main control and demanding speed. Any honest account has to start there, or the resulting recommendations will assume a level of institutional slack that does not exist.

What changed afterwards, and what did not

What changed: nearly every state bought identity proofing. Claimants now commonly complete a document and selfie check with a commercial vendor or through a federal service before a claim is approved. Cross state data matching improved. Treasury's Do Not Pay service is more widely used. States check bank account details against name records.

What did not change: the weekly certification. It is still a web form. It is still protected by whatever the claimant used to log in, which in many states is a username and password, sometimes with a one time code by text message. The payment destination can still often be changed inside the same session that just logged in.

The industry hardened the front door of a building whose windows open from the inside.

Where does the money actually leave the building?

Map the claim lifecycle honestly and the answer becomes obvious. Every unemployment claim has roughly these steps, and money only moves at some of them.

Read the third and fourth columns together. The two rows where money moves or is redirected are exactly the two rows with nothing in the fourth column. Identity assurance is concentrated at a step where no money moves, and absent at every step where it does.

This is a specific, named failure and it is not unique to benefits. We call it Session-Inherited Authorization: after login, every subsequent action carries the authority of the login, so stealing the session is equivalent to being the person. It is the same structure that lets an attacker who has stolen a corporate session move a payment without ever defeating multifactor authentication, and the same structure that makes a direct deposit change the entire payroll attack. Benefits systems are not unusually badly built. They have the default architecture of the web, applied to money.

Why does identity proofing at filing not stop this?

Because proofing answers a question that goes stale.

When a claimant completes a document and selfie check, the system learns that at that moment, a person matching this identity document was present. It is a genuinely useful fact. It is also a fact about a moment, and it is asserted about an account rather than bound to a key that the person will use later.

Think of it as a nightclub that checks identification at the door on Friday and then leaves the door open until Sunday. The check was rigorous. It is simply not connected in time to anything that happens afterwards.

There are three distinct ways money leaves after a valid proofing event, and it is worth separating them because they call for different responses.

Account takeover of a real claimant

The most common and the most harmful to individuals. The claimant is real, proofed, entitled to the money. Their credentials are compromised through a breach, reuse, an infostealer, or a phishing page. The attacker changes the payment destination and certifies. The state's records show a properly proofed identity certifying and being paid. Nothing in the record looks wrong.

Stolen identity used at filing

A criminal group files using a real person's stolen identity details, and passes proofing either by defeating the check or, more often, because the person whose identity was stolen is not watching and the documents are genuine. The response to this is better proofing, and better proofing genuinely helps here. It is also the case that injection attacks against verification pipelines have made the camera a much weaker evidence source than it was, so proofing is getting harder rather than easier.

Scripted certification at scale

Once a fraudulent claim is established, keeping it paying is trivial. The weekly certification is four predictable answers. A single operator can maintain hundreds of claims with a script that takes a few seconds per claim per week. This is the part that turns a one time theft into an annuity, and it is precisely the part that no control touches.

Detection based approaches attack the third pattern by looking for clusters: the same device, the same address range, the same behavioural timing across many claims. This works, in the sense that it finds rings. It works after the payments have gone out, which is why recovery rates are what they are. And it produces false positives that fall on people who share a shelter's network connection, use a library computer, or live in a household where several people legitimately claim.

What would a per-claim certification actually look like?

The control moves to the two rows in the table that move money. Instead of the certification being a form submission inside a session, it becomes an action the claimant signs on a device enrolled to them.

Concretely, at the end of the certification flow, the state's system asks the claimant's enrolled device to sign a structured object describing exactly what is being attested. The object is small and it is the whole point, so it is worth reading:

{
  "type": "ui.weekly_certification",
  "claim_id": "ST-2026-0041877",
  "week_ending": "2026-09-12",
  "attestations": {
    "able_to_work": true,
    "available_for_work": true,
    "sought_work": true,
    "earnings_reported_cents": 18500
  },
  "payment_destination_fingerprint": "sha256:7f1c0e...93ab",
  "amount_claimed_cents": 41200,
  "issued_at": "2026-09-14T23:11:04Z"
}

The claimant's device signs the hash of that object. The state stores the signature next to the certification record. Three properties follow, and each one solves a real operational problem.

The attacker cannot produce it. Someone holding the claimant's username and password does not hold the claimant's device. The certification fails. No payment is generated. Not flagged for review, not scored as risky. It does not complete.

The payment destination is inside the signed object. Notice the fingerprint field. The claimant is not just attesting that they looked for work, they are attesting to where the money goes. Changing the destination after the fact invalidates the signature against that week's record. The redirect attack, which is the one that hurts real claimants most, requires forging a signature rather than clicking through a settings page.

The record is evidence. An auditor from the Department of Labor's inspector general, or a state auditor, can verify the signature offline against a published key, without calling the state's IT department and without trusting the state's log. This matters for a program on the GAO High Risk List, where a substantial share of the improper payment estimate is documentation failure rather than actual error. A signed certification is documentation that cannot be lost, backdated, or disputed.

The verification side is unremarkable, which is the intent:

from manav import verify_receipt

def accept_certification(record, receipt):
    ok = verify_receipt(
        receipt,
        payload = canonical(record),
        subject = record["claim_id"],
        max_age_seconds = 900
    )
    if not ok:
        return hold_for_manual_review(record)
    return queue_payment(record)

There is no call back to a vendor in that verification. The receipt checks against a published Ed25519 key. A state can verify certifications during a vendor outage, and an auditor can verify them years later. That property is discussed in more depth in the post on verifying credentials without phoning the issuer. The signing flow itself is a single device gesture, which you can try in the signing demo, and the request and receipt formats are documented in the developer documentation.

Not every week needs the same weight

The obvious objection is that this adds a step to a process people do 26 or more times. It should not add the same step every time. A sensible design signs every certification, because signing is a single device gesture, and reserves a liveness check for the weeks that matter: the first certification after a payment destination change, the first after a long gap, a claim that has just crossed a value threshold, or a new device. That is the difference between a control and a ritual.

What does this cost the claimant who has nothing?

This is the section that decides whether the idea is worth anything, and it deserves more space than the mechanism did.

Every identity control added to a benefits system produces two kinds of error, and they do not fall on the same people. A control that is too loose pays criminals. A control that is too tight blocks eligible claimants. The people blocked by a tight control are, by the structure of the program, people who have just lost their income. Some of them do not have a current driver's licence. Some do not have a smartphone, or have one with a cracked camera, or have a prepaid plan that ran out of data. Some do not have a stable address to receive mail. Some are working two shifts and cannot sit in a video verification queue for forty minutes during business hours.

When identity proofing was rolled out across state unemployment systems during and after the pandemic, this was not a theoretical concern. The deployment of commercial verification services in state systems drew sustained criticism and congressional scrutiny, with reporting and advocacy focused on claimants stuck in verification queues, unable to complete document checks, or locked out entirely while waiting for benefits they were entitled to. Those complaints were legitimate. They are the direct, predictable output of optimising one error type without measuring the other.

Anyone proposing a new control in this space, including us, is obliged to answer the access question before the fraud question. So here is the answer, stated as design constraints rather than aspirations.

The fourth column is where honesty lives. A signed certification is not free of access risk. It moves the risk from "can you produce a document today" to "do you still have the device you enrolled". Those are different problems with different populations affected, and the second one is more tractable, because a device can be re-enrolled in minutes by someone who can demonstrate continuity, whereas a person without a current identity document may need weeks and a government office visit.

The design constraints that make this acceptable

• It must work on a borrowed phone. A claimant using a friend's device for five minutes must be able to certify. That means the enrolled credential cannot be locked to a single handset with no recovery path.
• No document upload after first enrollment. The document check, if it happens at all, happens once. Every subsequent week is a device gesture, not a paperwork event.
• No biometric database. Where a face check is used for liveness, it runs on the device and leaves behind a one way key, not a template. A state that holds a face database of everyone who has ever claimed unemployment has created a target and a civil liberties problem that will outlive the fraud it prevented.
• The receipt belongs to the claimant. They can export it, keep it, and use it as proof they certified honestly when a state later disputes a payment. This is not a small thing. Overpayment clawbacks against claimants who did nothing wrong are one of the more brutal features of these programs, and a signed record cuts both ways.
• The staffed fallback is a normal path. Not an exception queue with a six week wait. If a claimant cannot complete the signature, a human resolves it on a timescale measured in hours, and the system reports fallback volume as a headline metric rather than hiding it.

That last constraint is the one most likely to be dropped in procurement, and it is the one that determines whether the whole thing is an improvement or another wall. Any design that optimises only the fraud column has failed, and it should be described as a failure rather than as a difficult tradeoff.

Does this also help across state lines?

Partially, and this is where the second structural failure shows up. A claimant proofed to a high standard in one state is completely unknown to the next. Every state runs its own island of verified humans, which means multi state fraud rings work precisely because states cannot compare notes at the level of individuals without building the kind of shared database nobody wants.

A receipt held by the claimant changes the shape of that problem. If the person holds a portable proof that a human with continuity to this key was verified and certified honestly in another state, the receiving state can verify it offline without a federal registry of claimants and without either state querying the other. That is the same argument developed at length in the piece on making verification results travel between institutions, and it applies just as well between two American states as between two countries.

Honest limits

• This does not address eligibility fraud. A real claimant who is working full time and certifies that they are not has signed a truthful looking attestation with their own device. The signature makes them accountable for the lie, which has evidentiary value in prosecution, but it does not detect it. Wage cross matching remains the control for that, and it is a different problem.
• It does not address the bulk of improper payments. If most of a program's improper payment estimate is documentation and eligibility error, then fixing identity fraud fixes a minority of the number. Anyone selling this as a solution to the $5.6 billion is misrepresenting it. The honest claim is narrower: it closes the category where a technical control can be deterministic.
• First enrollment is still the weak point. If a criminal group completes proofing with a stolen identity and enrolls its own device, every subsequent certification will be perfectly signed. The signature proves continuity from enrollment, not that enrollment was honest. This is the Enrollment Binding Gap and it is why proofing spend does not go to zero.
• Manav cannot be inserted into a state system directly. These are procured platforms built by modernization vendors and integrators. What is described here is a reference design and a policy argument, and the realistic path is a pilot inside one vendor's certification module, not a state deploying a startup's product.
• Some of this is roadmap. The per-action signature, the companion device flow with on device face matching, and offline verifiable receipts are shipped. Selective disclosure of claim attributes without revealing the underlying record is not; that work depends on SD-JWT and predicate proofs that we have not shipped.

What to do this week

If you work in program integrity, at a state agency, or for a vendor building these systems, this is the short list.

1. Split your improper payment number. Get the identity fraud slice separated from eligibility error and documentation failure. If you cannot separate them, that is itself the finding, and it is the reason your remediation spend is mis-targeted.
2. Instrument the payment destination change. Count them. Count how many are followed within two weeks by a fraud report. In most agencies this data exists and nobody has ever pulled it as a single query.
3. Time-distance your controls. Write down, for each control you pay for, how many days elapse between the control firing and the money moving. Anything over seven days is a control on a different event than the one you think it protects.
4. Measure the second error type. Track how many eligible claimants abandon or are delayed at each verification step, broken down by whether they completed it on a mobile device. Publish it internally next to the fraud numbers. You cannot make a tradeoff you only measure one side of.
5. Ask your modernization vendor one question. What would it take to require a device bound signature on the weekly certification and the payment destination change. Not a one time code, a signature over the payload. The answer tells you how far the current architecture is from being fixable.
6. Check your fallback staffing. Find the actual median time to resolve a claimant who fails an automated identity step. If it is measured in weeks, no new control should ship until it is measured in hours.
7. Keep the receipt for the claimant. Whatever you build, make the record exportable to the person it describes. It protects them in overpayment disputes and it costs you nothing.

Frequently asked questions

How do states stop unemployment insurance identity fraud? Not by strengthening identity proofing at filing alone, because most identity fraud is extracted afterwards. The effective control is binding the two actions that move money, the weekly certification and the payment destination change, to a fresh signature from the claimant's enrolled device. An attacker holding stolen credentials cannot produce that signature, so the payment never generates.

Why are unemployment improper payments still around $5.6 billion? Because improper payments are mostly not identity fraud. The figure mixes documentation failures, eligibility errors, claimant mistakes, and fraud. Identity fraud is one slice. It is the slice where a deterministic technical control is possible, which is why it is worth targeting specifically rather than treating the whole number as one problem.

Does ID.me or Login.gov stop unemployment fraud? They raise the cost of filing a claim with an invented or stolen identity, which is real value. They do not cover account takeover of a legitimate claimant, scripted weekly certification, or a payment destination change made inside a valid session, because those happen after proofing and are protected only by the login.

What is a per-claim certification receipt? A signed record of one weekly attestation. It contains the claim identifier, the week, the four attestations, the reported earnings, and a fingerprint of the payment destination, signed by the claimant's enrolled device. It verifies offline against a published key, so an auditor can check it years later without contacting the state or a vendor.

Will this lock out claimants who lack documents or devices? It can, if implemented badly. The design has to work on a borrowed phone, require no document upload after first enrollment, store no biometric template, and treat the staffed human fallback as a normal path resolved in hours rather than an exception queue. A version that fails those constraints trades one harm for another and should not ship.

Does the state need to hold biometric data for this? No, and it should not. Where a face check is used to confirm liveness, it runs on the claimant's device and leaves a one way key behind. A central database of claimant faces creates a permanent target and a civil liberties problem that outlasts the fraud it was built to stop.

Can a signed certification help claimants, not just agencies? Yes. Overpayment clawbacks against people who certified honestly are a recurring harm in these programs. A receipt the claimant holds is evidence of exactly what they attested and when, verifiable without the agency's cooperation, which is useful precisely when the agency and the claimant disagree.

Sources

1. US Government Accountability Office, payment integrity and improper payments reporting, including the FY2025 government wide estimate: gao.gov/fraud-improper-payments
2. US Government Accountability Office, High Risk List, unemployment insurance program: gao.gov/high-risk-list
3. Bipartisan Policy Center, analysis of unemployment insurance improper payments and the federal role: bipartisanpolicy.org
4. US House Committee on Ways and Means, hearings and materials on pandemic unemployment fraud: waysandmeans.house.gov
5. US Department of Labor, Office of Inspector General, unemployment insurance oversight reports: oig.dol.gov
6. US Department of the Treasury, Do Not Pay service: fiscal.treasury.gov/DoNotPay
7. NIST Special Publication 800-63, Digital Identity Guidelines, on identity assurance and authentication assurance levels: pages.nist.gov/800-63-3

Every dollar of identity spend in unemployment insurance sits at the front door, and every dollar of identity loss walks out of a window that opens once a week.