Identity & KYC/AML

What an IDV/KYC session receipt proves, and what it doesn't

For fraud and compliance teams, KYC/AML program owners, and platform engineers who need to know exactly what a hash-chained identity-verification session receipt attests, given how routine injection attacks against remote IDV flows have become.

🔒 All inputs are processed locally in your browser. No data is transmitted. Do not enter real personal data -- use synthetic or anonymised inputs only.
Scope. This guide covers a two-step workflow: a camera-provenance check on the capture's C2PA manifest, then a session receipt builder that hash-chains that result together with the platform's own declared verdicts. Neither tool re-runs detection, re-scores liveness, or judges whether the person is who they claim to be.

Camera-Provenance Check

Structural check on a capture's C2PA manifest: claim well-formedness, hard-binding hash, and a digitalSourceType read that flags declared AI-generated media.

Open tool →

IDV/KYC Session Receipt Builder

Hash-chains session metadata, capture-chain attestation, and injection/liveness/document/device verdicts into one tamper-evident record.

Open tool →

Why injection attacks make this evidence gap matter

A remote IDV session doesn't have to defeat liveness detection or document forensics to break the process -- it can bypass the camera entirely. Injection attacks feed a virtual camera, a replayed video, or a synthetically generated face directly into the verification pipeline's input stream, downstream of wherever the platform's detectors actually look. A platform can run flawless liveness and document checks against a feed that was never a real camera capture in the first place, and every detector along the way will report a clean pass, because the injected input was built to satisfy them. The gap isn't detection accuracy: it's that most verification records don't carry independent evidence of where the capture came from, so a downstream reviewer has no way to check the platform's "this was a live camera" claim against anything.

C2PA capture-provenance metadata closes part of that gap when present: a camera or capture app can bind a hard-binding hash and a `c2pa.actions` digitalSourceType assertion to the file at the moment of capture, before an injection attack has any surface to act on. Checking that manifest structurally, separate from and prior to the platform's own detector output, gives a session receipt something to attest beyond "the platform's software said pass."

How the two tools fit together

  1. Run the camera-provenance check against the capture file's C2PA manifest. The check verifies claim well-formedness and hard-binding hash assertion (reusing the art-123 structural validator), then reads the `c2pa.actions` digitalSourceType assertion to flag whether the source is declared `trainedAlgorithmicMedia` (AI-generated) rather than a live capture. This is a structural read of the manifest as supplied, not a trust-list or chain-of-custody determination about the signer.
  2. Build the session receipt with the IDV/KYC Session Receipt Builder, feeding it the camera-provenance verdict as the capture-chain field alongside the platform's own declared injection-detection verdict, liveness verdict, document-check digest, and device-signal summary. The builder hash-chains all of it -- session metadata, verifier identity and version, timestamp -- into one tamper-evident receipt, with every verifier-sourced field labeled asserted.
What this chain proves, and what it never proves. The receipt attests the session record as declared: that a capture-provenance manifest existed with these structural properties, and that the platform's detectors returned these specific verdicts, all hash-chained so the record can't be silently edited after the fact. It does not attest detection quality (whether the liveness or injection detector was actually correct), and it does not attest subject genuineness (whether the person in the capture is who they claim to be). Every field in the receipt is exactly as strong as the verifier that asserted it -- the chain adds tamper-evidence to the record, it does not upgrade the underlying detector's accuracy. This workflow processes zero PII: only digests, booleans, and scores are consumed, never images, documents, or biometric templates.

Family linkage

This chain sits alongside AINumbers' broader KYC/AML compliance family -- see the AML/KYC & Financial Crime Compliance Hub for the full set of verification, screening, and monitoring tools. A related, separately built browser tool, the Verification-Failure Incident Composer, composes a signed incident record when a session's verdicts indicate a failure worth escalating to fraud, regulatory, or insurance teams -- it draws on the same session-record honesty boundary described above.