To detect AI-edited or AI-generated photos in insurance claims, work in three layers, in this order. First, control how the photo is made: have the claimant record it in a session you issued, from a link, instead of choosing a file from the gallery. Second, read what the file and its receipt can tell you: the time your server received it, a seal that shows any later change, an independent timestamp. Third, and only then, examine a file that already exists: AI traces, a reverse image search, a comparison with earlier submissions.
Most guides start with the third layer. That is the weakest place to start, because no check on a finished file can show that an image is genuine. It can only fail to find something wrong.
This guide is for the claims handler who opens the file and the counter-fraud lead who writes the handler's rules. We build Venta Capture, a product of VentaVid, which sits in the first two layers, so read those sections with our bias in mind.
Why can't a claims handler just look harder at the photo?
Because the mistakes that used to give an edit away are mostly gone.
An edited photo once started as a real one, and the edit left marks: a repeated texture, a shadow pointing the wrong way, a soft edge around the pasted dent. A generated image has no original underneath. Malwarebytes, in a July 2026 guide to spotting AI images, puts it plainly: "don't assume an image is genuine just because you can't spot anything wrong."
The insurance version of that test has been run. SAS built three claim images for Insurance Business in February 2026: one fully synthetic collision scene, one real photo with the bystanders removed, the plate altered and windscreen damage added, and one untouched. Adam Hall, the SAS fraud specialist who made them, lists the tells that still show up (shadows that fall incorrectly, damage that doesn't match the impact, blurred plates, unusually clean backgrounds) and calls them "the first red flags". Flags, then. He doesn't call them proof.
In Verisk's State of Insurance Fraud study, published in March 2026, 98% of insurers agreed that AI editing tools are fueling a rise in digital media fraud, and 76% said manipulated submissions have grown more sophisticated. Two thirds (66%) believe this kind of fraud goes undetected often or very often, even though 65% already run automated detection tools from a vendor.
So the tools are in place and the files still get through. That is the argument for moving the first check forward, to the moment the photo is made.
Try it on your own phone
Want to see what a guided capture looks like?
Request a capture link and we email you one. Open it on your phone, follow the steps, and see exactly what your customer or field team would see. No app, no account.
How big is the problem you are checking for?
Big enough to need a method, and small enough that most of your claimants have done nothing wrong.
- Editing is ordinary behaviour now. In the Verisk study, 36% of consumers said they would consider digitally altering a claim image or document, rising to 55% among Gen Z.
- It was growing before image generators arrived. Allianz UK reported that cases where apps were used to distort real images, videos and documents rose 300% from 2022 into 2023.
- Insurers report it. Aviva stopped £233 million in suspect claims across more than 18,400 flagged claims in 2025. Admiral detected 71% more fraud in 2025 than in 2024. In Belgium, Assuralia counted €181 million in established fraud for 2025 and estimates the real total at up to €800 million a year.
- Few teams feel ready. In an ACFE and SAS survey, only 7% of anti-fraud professionals called their organisation more than moderately prepared for AI-driven fraud. The same release puts fraud in about 1 in 10 property and casualty losses.
If roughly one loss in ten involves fraud, nine in ten don't, and your method has to let those nine through without treating them as suspects. The spending is heading toward detection anyway: in Deloitte's survey of insurance executives, 35% put it among their top five uses for generative AI, and Swiss Re's SONAR 2025 lists deepfakes among its emerging risks. The full set of numbers is on our AI insurance fraud statistics page.
One distinction before the method. A shallowfake is a real photo changed with an ordinary editing app. An AI-edited photo is a real photo changed by a generative tool (damage added, an object removed). An AI-generated photo never had an original. The layers below cover all three; the low-tech version has its own guide, shallowfake insurance claims.
Layer 1: how do you know a claim photo was taken now and not picked from the gallery?
You don't find out afterwards. You arrange it beforehand.
"Send us some photos" asks the claimant to choose files. Every chosen file has a past you can't see: taken, saved, maybe edited, exported, saved again, uploaded. A generated image enters through the same upload field. When we mapped this for our own product, what stood out to me was how generous the standard process is: it hands the claimant days between taking a picture and sending it.
The alternative is to make the recording part of the request.
- The handler sends a single-use link by SMS, email or WhatsApp. It opens in the phone's browser. No app, no account.
- The claimant records inside that session. The workflow tells them what to show and in what order: the whole vehicle, then the damage from a distance, then close up. This is guided capture, and the camera opens from the page. There is no step where a file is picked.
- The server confirms where each file came from. A photo or video recorded in the session is marked as such. A file from the gallery, where the workflow allows one, is labelled separately and checked separately (see layer 3).
Law firm Debevoise, writing about AI-generated images in fake insurance claims in January 2026, lists the manual version of the same idea: a real-time video inspection in which "an adjuster directs the claimant to pan, zoom and capture specific features", and several photos "from multiple angles and distances". A guided session does the directing without putting an adjuster on a call for every claim.
What session checks add
A recording made in the session answers "was this chosen from a gallery?" It does not yet answer "was a camera pointed at a real scene just now?" Session checks narrow that second question. In Venta Capture they are switched on per customer, and each one produces an observation for the reviewer:
- A spoken code issued for that session. The claimant sees a short code on screen and says it on video. The code didn't exist before the session did, so footage recorded earlier can't contain it.
- A changing code in the frame. A small code block sits in every photo and video and changes during the session. The server reads it back, so material from another session stands out.
- A motion step. The claimant moves the phone to complete a short on-screen task, and the phone's movement sensor is laid next to the movement seen in the image.
- A device consistency check. The characteristics of the device are compared across the parts of one submission, so a switch halfway through is visible.
None of these says "genuine" or "fake". Each says what was performed, measured and recorded. How we set that up for claims is on the remote claim inspection page.
Layer 1 doesn't fit every claim. The burglary happened last night and the only photo of the scene is already on the phone. A workflow should allow that upload and treat it as what it is: a file with an unknown past.
Start for free and send the first link to your own phone if you want to see what the claimant sees.
Layer 2: what can the file and its receipt tell you?
Less than most people assume from the file. More than most people use from the receipt.
Metadata is a claim made by the phone. EXIF data holds the capture time, the device model, sometimes the location. All of it is written by the device and all of it can be changed or removed before the file reaches you. Messaging apps do it without anyone intending to: the Malwarebytes guide notes that WhatsApp, iMessage and Facebook re-encode images on upload and often strip the embedded information. Missing metadata isn't a finding, and tidy metadata isn't a clearance.
The receipt time on your server is a fact. It comes from your side, not from the phone's clock. It states one narrow thing: this file existed, in this exact form, when we received it. It says nothing about when the damage happened.
A seal shows change after receipt. On arrival, each file gets a digital fingerprint, and the submission as a whole gets a signed seal. If anyone alters a file afterwards, in month one or month eight, the fingerprint no longer matches. That makes the record tamper-evident. A file that was edited and then sent is sealed in its edited state.
An independent timestamp answers "says who?" Your own server's clock is still your clock. A timestamp from an outside timestamping authority, taken over the fingerprint of the whole case, means a third party stands behind the moment the case existed, and anyone can check it with that party.
In Venta Capture, every submission is sealed on receipt, photos and video recorded in the session carry a visible stamp with date, time and seal, the case gets a timestamp from an independent timestamping authority, and a reviewer can print a proof of seal for the file. The site describes it as more than 25 control points per submission. The mechanism is laid out on the sealed evidence page.
Layer 2 gives a handler a chain of custody from receipt onward. For a photo recorded in the session, layer 1 covers the stretch before. For a gallery file, nothing does, which is why layer 3 exists.
Layer 3: how do you check a photo that already exists?
With three searches, and with modest expectations.
This is the layer for the file that arrived by email, the upload a workflow allowed, the photo in a claim opened before any of the above was in place.
1. Look for AI traces. Detection software examines the image as a whole and in regions, looking for generation patterns or for a patch whose noise and compression differ from the rest of the frame. It is worth running. A hit is a reason to look closer, and a clean result means nothing was found. New generators remove the patterns that older detectors learned, so a clean result ages badly.
2. Run a reverse image search. It finds recycled photos: the salvage listing, the marketplace advert, the picture from someone's social media page. It can't find a generated image, because that image has no earlier appearance to find. Malwarebytes makes the mirror-image point for ordinary photos: "No matches don't necessarily mean an image is fake." Personal photos usually have no history online either.
3. Compare with earlier submissions. The same photo, or a near copy, submitted on another claim is one of the oldest schemes there is, and it needs no AI. This check only sees what your own records hold. A claimant who changes insurer takes the history with them.
Then the manual look, last. The tells from the SAS test still earn thirty seconds: shadow direction, damage that matches the described impact, a plate as sharp as the rest of the frame. Does the weather in the photo fit the date of loss?
Venta Capture runs this layer on gallery uploads. An uploaded file is labelled as not recorded in the session, and the case shows what was observed about it in plain language: what the metadata says and that it is unverified, whether AI traces were found, whether the image was found online, whether it closely resembles an earlier submission. Each observation carries its caveat. A photo re-saved by a messaging app, for instance, is reported as that and not as an edit.
Our red flags guide for claims handlers covers what to do once something turns up, including the innocent explanation that sits next to nearly every flag.
A checklist for one doubtful claim photo
Print this, or paste it into the claim notes.
- Where did the file come from? Recorded in a session you issued, chosen from a gallery, or forwarded by email or a messaging app. Write it down first.
- If it was chosen or forwarded, can it be recorded again? If the damage still exists, send a link and ask for a recording now. It is the only check that replaces the doubtful file instead of examining it.
- What do the session checks show? Spoken code, code in the frame, motion, device consistency. Note the observation as recorded.
- What does the receipt say? Receipt time, seal intact, independent timestamp present.
- What does the metadata claim? Note it as a claim. Compare it with the date of loss and the story.
- AI traces, reverse image search, earlier submissions. Note each result, including "nothing found".
- Does one other fact in the file disagree? A single observation is a reason to look. Two from different sources are a reason to ask the claimant a question.
- Who decides? A named person, with the notes above in front of them.
What should your photo rules say in the first place? That is a separate question, answered in photo evidence for insurance claims.
What can none of these checks tell you?
No check can show that an image is genuine. Every check in layer 3 can only fail to find a problem. "No AI traces found" and "not found online" are absences. Treat them as absences.
A recording made in the session can still mislead. It can show a neighbour's car, damage that was there before the policy started, a scene arranged for the camera. Session capture closes the route from an editing app or an image generator into the case. It doesn't settle whether the story is true.
A mobile browser has limits as a recording device. Capture through a link in the browser can establish that the file came from a recording in that session, when the server received it, that it hasn't changed since, and what the session checks measured. A web page is not given hardware-level proof of which camera produced the frames. Signs of camera-substituting software on a device can be observed and reported, but their presence doesn't show the software was used for this recording, and their absence doesn't rule it out. That is why the session checks exist, and why their results are worded as observations and not as verdicts.
Declining is not a signal. A claimant who refuses location, or who can't complete a motion step on an old phone, should be recorded as exactly that. Debevoise makes the wider point: insurers "should take care not to overcorrect and either significantly slow down or wrongly deny legitimate claims."
A person decides. Software that marks a claim as fraudulent on the strength of an image score is making a decision it can't defend. The defensible version is smaller: here is what was performed, measured and recorded, here is what that does and doesn't support, and here is the handler who weighed it.
Where do the three layers sit in a claims process?
At first notification of loss, mostly. The handler, or the FNOL confirmation message, sends a capture link in place of a request for photos. Where the evidence already exists, the workflow allows an upload, which arrives labelled with its layer 3 observations.
At review, cases with nothing to look at move on. A case with an observation gets a named reviewer, who marks it as handled or as a real deviation, and that entry stays in the audit trail. Months later, in a dispute, the proof of seal answers "is this the file you received, and when?"
Because the claimant records on their own time, none of this needs a staffed video call. The request by link page shows how the link side works.
What happens after capture, when a reviewer, an ombudsman or a court asks about the file, is covered in what makes a photo or video hold up in a dispute.
Frequently asked questions
How can you tell if a photo is AI generated?
Often you can't tell by looking. Run an AI-trace check and a reverse image search, and compare the image with the facts of the claim. A generated image has no earlier appearance online and may show no visible flaw, so a clean result means only that nothing was found. If the damage still exists, asking for a new recording in a session settles more than any analysis of the old file.
How do you check if a photo has been edited?
Compare regions of the image for differences in noise and compression, read the metadata as a claim to be checked, and search for the original with a reverse image search. If you hold a sealed version from the moment of receipt, compare fingerprints: that shows any change since you received it. It can't show changes made before.
How can you tell if an image has been manipulated after it was submitted?
If each file was fingerprinted and the submission sealed on receipt, any later change breaks the match. It is the one question in this area with a yes or no outcome.
Is this photo real?
No tool can answer that with a yes. What you can establish is narrower: how the file came to you, when you received it, whether it has changed since, and whether any check found a reason to look closer. "Real" is a judgement a handler makes from those facts plus the rest of the claim.
How can an insurer verify that claim photos were taken in the session and not uploaded from the gallery or AI-generated?
Make the recording part of the request. The claimant opens a single-use link and the camera records inside that session, so there is no step where a file is chosen, and the server marks which files were recorded that way. Session checks (a spoken code issued for the session, a changing code in the frame, a motion step) add observations that tie the recording to that moment. Uploads, where allowed, are labelled and checked separately.
Try the first two layers on one claim type
Pick the claim type where photos cause you the most doubt. Build one workflow for it, send the link to your own phone, and look at what arrives.
Start for free, or book a demo and bring one real claim scenario. We'll build the workflow for it on the call.
Venta Capture is built by the VentaVid team.