The photo of the damage is the claim. Now anyone can make one.
For a hundred years a photograph stood in for an inspector's visit, and the entire remote claims process was built on that substitution. Generative imagery quietly removed the thing the substitution depended on. The industry's answer has been to buy detectors, which is a race against a counterparty who upgrades faster than you do.
The Tuesday morning that should worry every claims leader
A hailstorm crosses a county in the small hours. By nine in the morning the carrier's first notice of loss queue holds several hundred new claims, which is exactly what a hail event looks like from the inside. Nothing about the volume is suspicious. The volume is the weather.
One of those claims arrives with eleven photographs. A roof from four angles. Three close ups of dented aluminium flashing. A downspout separated at the seam. Two interior ceiling stains. And a wide shot down the street with hail still sitting in the gutter, because a good claimant knows to photograph the context.
An adjuster opens them a few minutes later. They are good photographs. The roof shots are slightly overexposed toward the sky, which is what happens when a person stands in a driveway and holds a phone up at an angle. The hail in the gutter is the right size for the cell that actually crossed that county that night. The ceiling stain has the irregular brown ring that water makes and that paint does not. The metadata says the photos were taken this morning on a recent iPhone.
The adjuster approves. Some days later the payment clears.
There was no hail damage. There was a hailstorm, which is what made the claim plausible. There was a roof, which is what made the address real. Everything in between was produced in a few minutes by somebody who has never stood in that driveway.
Here is the part that should genuinely unsettle a claims leader: the adjuster did nothing wrong. They applied the standard of care the industry taught them, on evidence the industry told them to trust, and the standard of care no longer works. This is not a training problem, and it will not be fixed by a memo about vigilance.
How do insurers stop AI generated claim photos? Not by detecting them. Detection is a race against generators that improve faster than detectors, and in insurance a false positive means accusing a real claimant of fraud on the worst day of their year. The deterministic control is to stop accepting unsigned files: hash the image on the claimant's device at the moment of capture, bind that hash to their enrolled key, and treat an unsigned file as an unverified file.
What exactly did generative imagery break?
The photograph was never evidence. It was a proxy for a visit.
Before remote claims, somebody drove to the property. That person was an employee or a contracted adjuster, they were accountable, and their presence at the address was the actual evidence. The report they filed was a summary of a human being having stood in a place and looked at a thing.
Photographs entered the process as a compression of that visit. They were trusted not because images are inherently trustworthy but because producing a convincing fake photograph of specific damage at a specific property used to be harder and more expensive than simply committing a smaller, more boring fraud. The economics did the security work. Nobody wrote that down, because nobody had to.
Then carriers noticed that the visit was the expensive part. Remote claims handling is faster, it costs a fraction of a truck roll, and here is the part that gets forgotten in these discussions: customers overwhelmingly prefer it. Photographing your own bumper in a supermarket car park and getting paid in three days is a better experience than waiting a week for an appointment. The industry did not move to remote claims out of laziness. It moved because remote claims are better for almost everybody.
That entire structure rests on the compression holding. And the compression was only ever held in place by cost.
What changed is the price, not the possibility
Photo manipulation is not new. Claims handlers have dealt with splicing, reused images from other incidents, and damage that predated the policy for as long as there have been photographs. The industry calls the crude version shallowfakes, and it has always caught a portion of them.
What changed between roughly 2024 and 2026 is that producing a photorealistic image of plausible damage, in the right lighting, at the right angle, with the right kind of wear on the surrounding surfaces, stopped requiring skill, stopped requiring time, and stopped requiring money. When a capability goes from expensive and rare to free and instant, the defences that were quietly built on cost stop working all at once. They do not degrade gracefully. They were load bearing and invisible, which is the worst combination.
How much of this is actually happening?
Honestly: nobody knows precisely, and you should be suspicious of anyone who tells you they do.
The most cited figure comes from vendor analysis. Shift Technology has reported that a substantial share of claims now contain some form of AI altered or AI generated media, with figures circulating in the range of 20 to 30 percent. Some European insurers have separately been reported as describing sharp increases in claims featuring manipulated vehicle images, with one widely repeated figure putting the rise at around 300 percent. Treat both of these as vendor and insurer reported, not as measured industry fact.
The reason to hedge is not politeness. It is that the definitions are doing enormous work. "AI altered" can mean a fabricated scene of damage that never existed. It can also mean a photograph that went through a phone's computational photography pipeline, or a brightness adjustment, or an automatic background cleanup, or a crop performed by an app that used a machine learning model to decide where to crop. Modern phones apply learned processing to essentially every image they take. If your detector flags learned processing, your detector flags reality.
That is why the reported range is so wide, and the width of the range is itself the most useful finding. When credible analysts differ by a factor across a category this important, it means the industry cannot currently measure the thing it is trying to manage. You cannot run a control programme on a number that moves by a factor of two depending on what you count.
We are deliberately not going to quote an industry loss total here. The figures that circulate for insurance fraud in aggregate are weakly sourced, frequently recycled without attribution, and mostly predate the specific phenomenon under discussion. The direction of travel is well evidenced. The magnitude is not, and pretending otherwise would be exactly the kind of claim this series exists to criticise.
You do not need the industry number anyway. You need your own. A carrier handling two million claims a year, with even a small percentage of synthetic media leakage at a mid three figure average severity, is looking at an eight figure exposure before it spends anything on detection. That arithmetic you can do internally this week, and it will be more useful than any published figure.
Why can't insurers just detect AI generated claim photos?
The generator is always newer than the detector
This is the structural problem, and it is not specific to insurance. A detector is trained on the outputs of generators that existed when the training set was assembled. It is then deployed against the outputs of generators that exist now. The gap between those two dates is the attacker's advantage, and it never closes, because the generator side has more capital, more researchers, and a much faster release cycle than the fraud detection side of the insurance industry.
Every published detection benchmark should be read with one question in mind: which generators were in the evaluation set? A detector reporting excellent recall against last year's models tells you very little about this year's, and the vendor is not being dishonest when it publishes that number. It is simply the only number it can produce.
The false positive problem is much worse in insurance than elsewhere
This is the part that people outside claims consistently underrate, and it is the reason detection will underperform in insurance specifically even if it works acceptably somewhere else.
In most fraud contexts a false positive is an annoyance. A card gets declined, the customer calls, the transaction goes through. In claims, a false positive means telling a person who has just had a fire, a flood, or a collision that you suspect them of fabricating evidence. That person is having the worst week of their year. They are frequently in financial distress, they may be displaced from their home, and they now have to prove a negative about a photograph they took honestly.
The consequences of getting that wrong are not merely reputational. Unfair claims practices are regulated. Bad faith litigation is expensive and the discovery is unpleasant. Market conduct examinations exist. And a wrongly accused claimant with a compelling story is a local news segment.
So carriers will do the rational thing, which is to set detection thresholds conservatively. Conservative thresholds mean fewer false accusations, which is correct and humane, and it also means catching less fraud. The false positive cost in insurance is asymmetric and high, so the operating point drifts toward permissiveness. The vendor sells you a model with a good curve, and your risk and compliance functions, entirely correctly, insist you operate at the least aggressive point on it.
This is a case where the humane choice and the effective choice genuinely conflict, and pretending otherwise helps nobody. The way out is not to become less humane. It is to stop relying on a control that forces the trade in the first place.
And EXIF metadata is not evidence, it is a suggestion
Some claims systems check embedded metadata: capture timestamp, GPS coordinates, device model. It is still occasionally described as verification. EXIF fields are editable text. There are free tools, some of them one line command invocations, that will set any field to any value. There are phone apps whose entire purpose is producing images with chosen metadata. Meanwhile, the honest claimant's metadata is routinely destroyed by the pipeline: messaging apps strip it, upload portals re-encode, and privacy settings suppress location by default.
So metadata is trivially forged by the dishonest and routinely absent for the honest. As a signal it is close to inverted, and any weight placed on it should be removed rather than tuned.
What does C2PA prove, and what does it miss?
The most serious standards work in this area is C2PA, the Coalition for Content Provenance and Authenticity, whose specification defines cryptographically signed manifests that travel with a piece of media and record where it came from and what was done to it. Adobe's Content Authenticity Initiative is the associated adoption effort, and it has enrolled a large number of member organisations across the media and technology industries.
It deserves credit rather than the dismissive treatment it usually gets from vendors selling something else. C2PA is well designed, the cryptography is sound, and if it achieves broad adoption in camera hardware and editing tools, a great deal of provenance becomes checkable that is not checkable now. Two limitations matter for claims specifically.
The first is stripping. A C2PA manifest travels with the file, and most upload paths do not preserve it. Messaging apps, email clients, web forms that re-encode on upload, and screenshots all discard it. A claimant who photographs their car and sends it through a messaging app to their broker, who forwards it to the carrier, has delivered a file with no manifest, and there is nothing anomalous about that claimant. Absence of provenance is the normal case, which means absence cannot be treated as suspicious.
The second is the more important one for our purposes: C2PA answers what and how, not who. A manifest can attest that a particular camera captured an image at a particular time and that specific edits followed. It is not designed to attest that a specific accountable human, the person named on this policy, stood behind that capture. Those are different claims, and the second one is what a claims file actually needs.
The right relationship is composition, not competition. Device and edit provenance from the standard, human accountability from a signature. They answer adjacent questions and a claims system benefits from both.
What is a capture receipt?
Here is the move, and it is worth going slowly because the whole argument turns on it.
Stop asking a question about the file and start asking a question about the moment. The file question is "is this image real", which is a probabilistic judgment about pixels, and it gets harder every quarter. The moment question is "did an enrolled human capture this on their device at this time and put their name to it", which is a cryptographic fact, and it does not get harder as generators improve. It does not get harder because it never looked at the pixels.
Think of it like a notary. A notary does not authenticate the contents of a document. A notary has no opinion on whether your contract is a good idea, and they are not verifying your claims about the world. What they attest is narrow and reliable: this person, whose identity I checked, signed this document in my presence on this date. That narrow attestation is enormously useful precisely because it is narrow, and because it does not require the notary to be an expert in the thing being signed.
A capture receipt is the same shape. It does not claim the damage is real. It claims that this enrolled human captured this exact image at this time on this device, and here is a signature anyone can check.
The mechanism, step by step
The claimant opens the carrier's claim flow and takes a photograph inside it. Four things then happen before the image goes anywhere.
First, the image is hashed on the device at shutter time. A SHA-256 of the image bytes, computed in the capture buffer, before compression choices, before any upload, before the file could have been swapped for another one. That hash is now a fingerprint of exactly these pixels, and any change to any pixel produces a completely different hash.
Second, the claimant's enrolled key signs a small record containing that hash. Enrollment happened earlier, at policy issue or at first claim, and it bound this human to a key on this device. A liveness check at capture time raises the cost of somebody else holding the phone.
Third, the receipt is assembled and travels with the claim. Not the biometric, not an identity document, not the face. A one way key, a hash, a timestamp, and a signature.
Fourth, when the eleven photographs are done, the claimant signs the submission itself: the set of capture hashes plus a hash of the narrative. That second signature is what converts a pile of files into a claim a specific person has put their name to.
What is actually signed
capture_receipt = {
"claim_ref": "FNOL-2026-0913-1183",
"captured_at": "2026-09-13T09:02:41Z",
"image_sha256": "9f2c4b1e...", // hashed in the capture buffer
"device_key": "dk_8f14a2...", // the enrolled device
"human_key": "hk_3c9e07...", // one way key, not a face, not an ID
"liveness": "passed",
"sequence": 3 // third capture of eleven this session
}
signature = Ed25519_sign(device_private_key, canonical_json(capture_receipt))
// and once the session is complete, the claimant signs the bundle:
submission = {
"claim_ref": "FNOL-2026-0913-1183",
"capture_hashes": ["9f2c4b1e...", "2a71d0c8...", ...], // all eleven
"narrative_sha256": "c4e9018b...",
"submitted_at": "2026-09-13T09:11:07Z"
}
submission_signature = Ed25519_sign(human_key, canonical_json(submission))
Note what is not in there. No image. No face template. No identity document. No location history. The identity layer never holds the photograph, and the carrier's existing claim system keeps holding the images exactly as it does today. The receipt is a small, boring object, and boring is the security property.
Verification is the part that matters operationally. The adjuster's system checks two things: that each image on file hashes to the value in its receipt, and that the signatures verify against the published key. Both checks are local arithmetic. Neither requires calling anyone, which means the check still works during an outage, still works in five years, and still works for a reinsurer auditing the file long after the claim closed.
def verify_capture(image_bytes, receipt, signature, published_key):
if sha256(image_bytes) != receipt["image_sha256"]:
return "IMAGE_ALTERED_AFTER_CAPTURE"
if not ed25519_verify(published_key, signature, canonical_json(receipt)):
return "SIGNATURE_INVALID"
return "OK" # this human captured these exact pixels at this time
What the claimant experiences
They open the app, take photos the way they already would, and at the end they confirm the submission with the same gesture that unlocks their phone. If they are already enrolled, the whole thing adds a few seconds and one tap. Enrollment itself, the first time, is roughly the length of a password reset.
The honest claimant's life gets marginally easier rather than harder, because signed submissions can be routed faster with less documentation friction. That matters. A control that punishes honest customers to catch dishonest ones does not survive contact with a product team, and it should not.
What does each kind of claim evidence actually prove?
| Evidence type | What it genuinely proves | What it does not prove | Survives the vendor disappearing? |
|---|---|---|---|
| Uploaded photo file | A file exists | Origin, time, author, integrity | Not applicable |
| EXIF metadata | Nothing reliable, fields are editable text | Anything at all, and it is absent for many honest claimants | Not applicable |
| Forensic detection score | A probability under one model, at one moment | Any specific file's origin, and it drifts as generators improve | No, the score is not reproducible later |
| In app capture, unsigned | The carrier's app was used | Who held the phone | No, it is the carrier's own log |
| C2PA manifest | Device and edit provenance, when preserved | Which accountable human stood behind it, and it is stripped by most upload paths | Yes, if the manifest survives |
| Capture receipt plus signed submission | This enrolled human captured these exact pixels at this time and put their name to the bundle | That the depicted scene is truthful | Yes, verifies offline against a published key |
The last column is the one that rarely appears in vendor comparisons and matters most in an industry where files get audited by reinsurers years later, and where a subrogation dispute can outlive the software that processed the claim.
What this cannot do
This section is the most important one in the post, and if you read nothing else, read it, because the failure mode of writing like this is overselling.
A real human can photograph a staged scene. This is the big one. If somebody genuinely takes a hammer to their own bumper and photographs the result honestly, every signature verifies, every hash matches, and the claim is still fraudulent. A capture receipt proves who captured what and when. It does not prove that the depicted scene is a truthful account of an insured loss. Staged loss fraud is a different problem, it is largely addressed by investigation and by pattern analysis across claims, and nothing here touches it. Anyone who tells you cryptography solves staged loss is selling something.
Enrollment is the trust bottleneck. Somebody, once, has to bind the right human to the key. Get that wrong and everything downstream is a well signed lie. Enrollment at policy issue is the strongest point in the lifecycle, and it should be treated with the seriousness of the moment it actually is.
A compromised or coerced device signs happily. If a fraud ring controls the enrolled phone, or an organised operation enrolls under a synthetic identity and then uses that identity honestly for a year before filing, the signatures will be perfect. This raises the cost per fraudulent claim substantially, which is the actual goal, and it does not reduce it to zero.
Coverage will never be complete. Some claimants will not enroll, some will have no smartphone, some will file through a broker or a public adjuster, and some losses are reported by third parties. Any design that only works when adoption is universal is not a design, it is a wish. The realistic model is a threshold: unsigned claims are not rejected, they are routed to the process you use today, and signed claims get a faster path. The incentive does the adoption work over time.
This does not replace physical inspection. For high severity claims, sending a human being remains the right answer, and it always will be. This is about the enormous volume of low and mid severity claims where a truck roll was never going to be economic.
What to do this week
- Calculate your own exposure instead of quoting the industry's. Take your claim volume, your average severity by line, and a range of leakage assumptions from a tenth of a percent to two percent. That range is your actual decision input, and you can produce it from data you already have.
- Ask your detection vendor which generators were in the evaluation set, and on what date. Then ask what the recall curve looked like twelve months earlier. The shape of that trend across two data points tells you more than the headline number.
- Find where you still treat EXIF as a signal and remove it. It is forged by the dishonest and stripped for the honest. If it is contributing to a risk score, it is contributing noise.
- Measure your false positive cost properly. Not the handling minutes. Include complaint handling, regulatory exposure, and the retention effect on wrongly challenged customers. This number is usually much larger than claims leaders assume, and it is the number that justifies moving from detection to proof.
- Classify your claim intake by severity band and decide which band would justify a signed capture requirement. It is almost never the whole book, and starting with the whole book is how these programmes die.
- Check whether your intake pipeline preserves C2PA manifests. Most re-encode on upload and destroy them. If you are planning any provenance strategy, this is the prerequisite nobody checks.
- Run one adversarial test. Have somebody generate ten synthetic damage photographs for a line you write and put them through your live intake. Do not use a public benchmark set. Use your own pipeline, this quarter's tools, and count what got through.
Where this leaves the industry
The insurance industry has been here before, in a way that should be reassuring rather than alarming. Signatures on applications, witnesses on policies, notarisation on high value instruments, and adjuster attendance at inspections were all mechanisms for binding an accountable human to a claim about the world. The industry did not invent those because it enjoyed paperwork. It invented them because evidence without an accountable author is not worth much, and it has known this for a very long time.
Remote claims handling quietly removed the accountable author and replaced them with a file. That worked for as long as producing a convincing file was expensive. It is not expensive any more. Putting the human back into the evidence is not a return to truck rolls. It is the same principle the industry already understood, implemented with a signature instead of a notary's stamp, at a cost of about four seconds and one tap. The technology to do this is not exotic: on device capture, on device hashing, a passkey signature, an offline verifiable receipt. Manav ships those pieces today, including on device document capture where pages never leave the browser until they are shared, and per action signatures with liveness. What is missing is not cryptography. It is a decision about what a carrier will accept as evidence.
That decision is the whole thing. Detection asks your adjusters to be better at spotting fakes every quarter, forever, against an opponent who is getting better faster. Proof asks your claimants for one tap. Only one of those is a strategy.
If you want the mechanics of how per action signatures and offline verifiable receipts work in practice, the developer documentation covers the payload construction and verification path, and the signing demo shows the flow end to finish in a browser.
Frequently asked questions
How do insurers stop AI generated claim photos? Not by detecting them, because generators improve faster than detectors and insurance false positives are unusually costly. The deterministic control is to require the image to be hashed on the claimant's device at capture and signed by their enrolled key, then treat unsigned files as unverified and route them to your existing manual process.
Can EXIF metadata prove a claim photo is real? No. EXIF fields are editable text and free tools will set any value you like. Worse, honest claimants routinely lose their metadata because messaging apps strip it and upload portals re-encode. It is forged by the dishonest and absent for the honest, so as a fraud signal it is close to inverted and should be removed rather than tuned.
Does C2PA stop insurance fraud? It helps with a different part of the problem. C2PA attests device and edit provenance, which is genuinely valuable, but it is stripped by most upload paths and it is not designed to attest which accountable human stood behind the capture. It composes well with a human signature rather than substituting for one.
What is a capture receipt? A small signed record created at the moment a photograph is taken. It contains a hash of the image bytes, a timestamp, the enrolled human's one way key, and a signature. It carries no image, no face template and no identity document, and it verifies offline against a published key without contacting the issuer.
Does this catch staged damage? No, and this is the honest limit. If somebody damages their own property and photographs it truthfully, every signature verifies and the claim is still fraudulent. Capture receipts prove who captured what and when. Staged loss is addressed by investigation and cross claim pattern analysis, and nothing in this approach touches it.
Will claimants actually enroll? Some will not, which is why the sensible design is a threshold rather than a mandate. Unsigned claims follow the process you run today, and signed claims get a faster path with less documentation friction. The incentive drives adoption over time without penalising anybody who cannot participate.
Does the insurer end up holding biometric data? Not in this design. The face match happens on the claimant's device and produces a one way key. What travels is a hash, a timestamp, a key and a signature. That matters for exposure under biometric privacy laws, because the cheapest way to avoid a biometric data liability is to never hold biometric data.
Sources
- Shift Technology, research and insight publications on AI altered media in claims: shift-technology.com
- Coalition for Content Provenance and Authenticity, C2PA specifications: c2pa.org
- Content Authenticity Initiative, adoption and member information: contentauthenticity.org
- Regulation (EU) 2024/1689, the Artificial Intelligence Act, including Article 50 transparency obligations: eur-lex.europa.eu
- Coalition Against Insurance Fraud, research and statistics index: insurancefraud.org
- National Association of Insurance Commissioners, market conduct and model laws: content.naic.org
- FBI Internet Crime Complaint Center, annual reports: ic3.gov
A notary never authenticates the contents of a document. That narrow attestation is exactly why it is worth something, and it is exactly what a claim file no longer has.