Seal claim photos before the editing window opens.
Industry reporting through early 2026 documents a measurable rise in claims supported by synthetic or post-capture manipulated photos. Standard JPEG metadata is freely editable; EXIF timestamps can be back-dated in seconds with free tools. receipts.you stamps a cryptographic hash + ECDSA signature + externally-anchored timestamp at the moment of capture — turning a basic photo into the kind of artifact that survives Federal Rule of Evidence 901 authentication AND defeats post-hoc fabrication.
Workflows insurance actually run
- 01
Property damage capture, at the scene.
Claimant takes photo with phone camera, immediately drops it into /seal in the mobile browser. The file is hashed, signed, and submitted to OpenTimestamps in under a second. From that moment, the claim photo carries a verifiable timestamp that predates any post-incident editing window — even the claimant can no longer alter the file without the verification failing.
- 02
Adjuster intake audit.
When a claimant submits a packet, the adjuster runs each image through /verify. Three outcomes: byte-identical match (strongest); recompressed copy (the claimant emailed it to themselves and the platform re-encoded — perceptual hash still within band of the sealed file); or mismatch (the photo doesn't match what was sealed at capture — flag for investigation).
- 03
Catching the back-dated EXIF trick.
A claimant alters the EXIF timestamp on a photo to predate the incident, hoping to establish 'I had this before any dispute could've started.' receipts.you ignores EXIF entirely. The receipt's anchored timestamp is what counts, and it's externally provable via blockchain. EXIF manipulation becomes irrelevant to authentication.
- 04
Defending against synthetic claim photos.
If your policy requires sealing at capture, an AI-generated 'photo of the damage' produced after the loss event has no receipt that predates the event. You don't need to detect the AI artifacts; the absence of a pre-loss receipt is the disqualification. Cleaner, more defensible than any current 'AI image detection' approach.
What it maps to in your world
- FRE 901(a) photo authentication: byte-identity match via published key is a stronger claim than 'looks unmodified to the adjuster.'
- FRE 902(13) self-authenticating electronic records: the ECDSA P-256 signature is the cryptographic certification element.
- ISO/IEC 27037 (digital evidence acquisition + preservation): SHA-256 at capture is the integrity baseline.
- eIDAS qualified timestamp (EU): OpenTimestamps Bitcoin-anchor proof satisfies the long-term archival requirement.
- NAIC Model Bulletin guidance on AI / synthetic claim media: workflows that prove pre-event existence are a defensible baseline against fabricated post-event imagery.
- Privacy: image bytes never reach our servers, only a 32-byte hash does. The claim photo stays with the carrier's claim system end-to-end.
Questions this page answers
- “insurance claim photo fraud detection”
- “AI generated insurance claim image”
- “deepfake insurance claim”
- “tamper proof claim photo”
- “qualified timestamp insurance evidence”
- “claim photo authentication FRE 901”
- “exif manipulation insurance”
- “synthetic claim photo detection”
- “ISO 27037 insurance claim”
- “blockchain insurance claim timestamp”
Specific answers
How does this integrate with our claim management software?
Two paths. (a) Manual: the claimant pastes the receipt URL into the claim form; the adjuster verifies in the browser. (b) API integration: REST endpoint with bearer auth, batch seal, callback webhook on verification — under active development. Email [email protected] with the claim system you use (Guidewire, Duck Creek, Sapiens, etc.) and the call volume you're looking at.
What if the claimant's phone has a slow connection?
Sealing is one POST to our API: 32-byte hash + signature request. ~200 bytes one way, ~500 bytes back. Sub-second on any reasonable mobile connection. The image itself never travels.
Can adjusters seal photos after the fact (during their own visit)?
Yes — when the adjuster captures the photo, sealing at the adjuster's device records the timestamp of THAT capture, which is itself useful for chain-of-custody. The receipt records when you held the file; combine with the timestamp of original capture from claimant for full provenance.
How does the perceptual hash help here?
When claimants forward photos through email or messaging that recompresses the file (very common), the bytes change but the visual content doesn't. The pHash+dHash verdict ladder distinguishes 'platform re-encoded' (same image as sealed, just re-encoded) from 'different image entirely' (flag for investigation). The auditor-confirmed AND-gated thresholds give a low false-positive rate.
Is the source code public?
Yes. Reading the code is the recommended path to confirm the cryptography and the privacy posture meet your compliance bar.
Pricing for an insurance carrier?
Free for the public endpoint. For high-volume integration (REST API with bearer auth, dedicated rate limits, SLA, on-premise option for PHI/PII workflows), email [email protected] with your annual claim volume.
Make synthetic claim photos impossible to back-date.
A claim photo with no pre-event receipt is a claim photo that didn't exist before the incident. The verification math is older than the dispute.