The photographs were notarized. Notary seal on the cover letter. The insurance company denied the claim anyway, arguing the photos couldn't be verified as pre-loss.
The notary hadn't been at the loss site. The notary certified the signature. That's all a notary does.
This confusion costs claimants money and costs attorneys credibility. Evidence gets submitted with notarized cover sheets and everyone assumes authentication is solved. It isn't. At least not for the question that usually matters most: when was this evidence created?
---
What Notarization Actually Proves
A notary public certifies one thing: that the person who signed a document is who they claim to be. Under FRE 902(8), a document bearing a notary seal is self-authenticating. The court accepts it without additional testimony about the notary's identity.
That's genuinely useful. An affidavit. A power of attorney. A property deed.
What notarization doesn't establish: when the underlying evidence was created, whether photographs depict pre-loss conditions, or whether files were modified between creation and submission.
FRE 902(8) answers "who." It doesn't answer "when." In pre-loss documentation disputes, "when" is the question.
---
The Timestamp Problem
Every camera writes a timestamp. So does every phone, every dashcam, every telematics device.
Courts have stopped treating this as reliable authentication.
EXIF data is editable with free software. File timestamps change on copy, move, or backup. Device clocks can be wrong, and often are. These fields reflect what software reported, not what actually happened.
FRE 901(b)(9) authenticates "evidence about a process or system and showing that it produces an accurate result." A camera's internal clock doesn't meet that bar unless you can establish, through expert testimony or other foundation, that the clock was accurate at the time of capture. Metadata alone doesn't do it.
Submitting photographs and pointing to the EXIF timestamp is an authentication problem waiting to be exploited. The field exists. That's not the same as proving the field reflects reality.
---
What a Blockchain Timestamp Proves
A blockchain anchor doesn't store your file. It stores a SHA-256 hash of your file, anchored to a public ledger at a specific timestamp.
The mechanism: your file is hashed on your device. Only the hash goes on-chain. That hash is deterministic. The same file always produces the same output. Change one byte and the hash changes completely. A matching hash confirms the file hasn't been modified since anchoring.
The anchor timestamp is written into the blockchain by network consensus across thousands of independent nodes. It can't be retroactively altered. Polygon confirms within seconds. Bitcoin anchoring via a daily batch with a merkle proof adds verification against the most scrutinized ledger in existence.
For authentication under FRE 901(b)(9), the process is the argument. Hash function, network consensus, cryptographic verification. These are the mechanisms a practitioner lays foundation for with expert testimony or technical certification. The process produces an accurate result. That's what the rule requires.
---
FRE 902(13) and 902(14): Removing the Expert Witness Requirement
FRE 901(b)(9) requires foundational testimony. Someone explains the process before the evidence comes in, usually an expert.
Two 2017 amendments change that calculus.
FRE 902(13) covers "a record generated by an electronic process or system that produces an accurate result, as shown by a certification of a qualified person that complies with the certification requirements of Rule 902(11) or (12)." Written certification. No live testimony required.
FRE 902(14) covers "data copied from an electronic device, storage medium, or file, if authenticated by a process of digital identification, as shown by a certification of a qualified person that complies with the certification requirements of Rule 902(11) or (12)." This is directly on point for hash-verified file integrity. When opposing counsel or an auditor verifies that the current file's hash matches the on-chain anchor, they're doing exactly what 902(14) contemplates.
The certification requirements under 902(11) and 902(12) are specific: attest to the accuracy of the process, provide advance notice to opposing counsel, make the certification available for inspection. A generic cover letter doesn't satisfy this. A proper technical certification attesting to the anchoring mechanism, hash function, and verification procedure can.
Used together, 902(13) and 902(14) let you bring blockchain timestamp evidence in without putting an expert on the stand. That's a real advantage in cost and trial scheduling.
---
The Key Distinction
Notarization and blockchain timestamps authenticate different things.
Notarization under FRE 902(8): the signer is who they say they are.
Blockchain timestamp under FRE 901(b)(9) and FRE 902(13): this file, in this exact state, existed at this specific time.
For pre-loss evidence disputes, you need the second one. The question isn't who submitted the document. It's whether the photographs were taken before or after the loss date.
A notarized photo with no timestamp authentication doesn't establish pre-loss existence. A blockchain-anchored hash establishes exactly that, with a mechanism courts can evaluate under the Federal Rules.
This isn't either/or. A notarized affidavit describing the circumstances of capture, combined with a blockchain anchor of the underlying files, gives you both: identity verification and temporal proof. Use both when the stakes warrant it.
---
Monday Morning
If you're submitting evidence in a dispute: Don't assume notarization solves authentication. It handles the identity question. For timestamp integrity, you need a process courts can evaluate under FRE 901(b)(9), or a certification that satisfies FRE 902(13) and 902(14).
If you're challenging evidence: The absence of verifiable timestamp authentication is a legitimate basis for a motion to exclude. EXIF metadata alone doesn't satisfy FRE 901(b)(9). Ask what process produced the timestamp and how opposing counsel plans to establish that process was accurate.
If you're building a documentation workflow: Anchor files at capture, not submission. A blockchain anchor created well before any dispute carries a timestamp that predates any adversarial incentive. One created the week before trial is technically valid but harder to defend under cross.
FRE 902(8) is useful. FRE 901(b)(9), FRE 902(13), and FRE 902(14) are the rules that matter for temporal authentication. Know the difference before the motion gets filed.