A cryptographic transaction receipt is not a prose record of what the bank observed.
It is a signed artifact with a specific structure, produced on the customer’s device, verifiable by anyone with the corresponding public key.
Six fields do the work.
The Six Fields
1. proof_id
A unique identifier for the signed artifact itself. It allows the receipt to be referenced unambiguously across systems: the ledger, the fraud engine, the dispute system, the regulator’s audit.
The proof_id is generated at signing time. It is not a database row ID assigned later by the bank.
2. actor
The stable identifier of the human who authorized the action. Paired with a monotonic counter that increments on every authorization by that actor.
The counter is what makes replay attacks detectable. A receipt with a counter value the ledger has already seen is rejected.
3. action
A canonical description of what was authorized. For a wire transfer: amount, currency, and payee identifier. For a document signing: document hash and document type. For a medical action: the prescription or the chart entry identifier.
The action field is what makes the receipt specific. Change a digit in the amount and the signature no longer verifies.
4. biometric
An attestation that a fresh biometric gesture was performed at signing time, on hardware that holds the signing key, validated by secure hardware (StrongBox on Android, Secure Enclave on iOS).
Not a stored template. Not a previous authentication. A gesture performed for this action.
5. signature
An ECDSA signature over a canonical encoding of the preceding fields. Typically ES256 (P-256 curve with SHA-256), produced offline by the device’s hardware-backed private key.
The signing key never leaves the hardware. It is generated in the secure enclave at enrollment and is used without ever being exported.
6. hash_chain
A commitment to the previous receipt in the actor’s history. Each new receipt’s signed payload includes the hash of the previous one.
This creates a tamper-evident chain: removing a receipt, reordering receipts, or inserting a receipt after the fact all break the chain visibly.
The chain is verifiable without trusting any party. The bank cannot quietly drop or reorder receipts. The customer cannot quietly insert one.
What the Receipt Is Not
It is not a session log.
It is not an OTP acknowledgment.
It is not a risk score.
It is not an audit entry produced by the bank about its own systems.
For the difference, see Why Session Logs Are Not Proof.
Why Issuers Need It — Deterministic vs Probabilistic
Every fraud system in production — Actimize, Featurespace, Sardine, Sift, Feedzai, internal models — is probabilistic. Device fingerprint, velocity, behavioral pattern, IP, and session cues are inputs to a score. The score is a likelihood, not a fact. Every mandatory-reimbursement regime (UK PSR 2024 onward), every operational-resilience audit (DORA), and every high-risk-AI oversight obligation (EU AI Act Article 14) now asks the issuer for something the probabilistic stack cannot produce on its own: deterministic evidence that a specific human authorized a specific action at a specific moment.
The six-field receipt is that artifact. It is not a replacement for the fraud stack — the stack remains the decision layer. It is the deterministic counter-signal the stack can consume as a binary input: human_verified = true | false.
How Regulators Read It
PSD2 Article 97 requires dynamic linking to amount and payee, non-repudiation, and two-factor authentication. Dynamic linking is the action field. Non-repudiation is the combination of hardware-held key, fresh biometric, and monotonic counter. Two-factor authentication is satisfied by possession (the device) and inherence (the biometric).
DORA requires tamper-evident ICT-risk evidence and operational continuity. The hash_chain field gives tamper-evident append-only structure by construction; independent verifiability through the public key gives vendor-continuity: a receipt remains verifiable without the vendor.
The EU AI Act Article 14 requires effective human oversight of high-risk AI systems — not a logged click, not an approval dialog. A receipt that proves a fresh biometric gesture from the specific enrolled human, on hardware bound to that identity, is a stronger implementation of oversight than any procedural control.
Three regulatory regimes. One artifact satisfies all three.
The receipt is not a new regulatory burden. It is the single artifact that replaces a growing number of partial, incompatible ones.
What This Looks Like in Deployment
The customer performs a biometric gesture on their device at the moment of the action.
The device produces the six-field signed receipt locally. No network round-trip is required. The signing works offline.
The receipt travels with the transaction request to the bank’s backend. The bank verifies the signature against the customer’s public key on record. If it verifies, the action proceeds. The receipt is persisted as the record of authorization.
In dispute, the bank produces the receipt. The customer, or their representative, or a regulator, or a court can verify the signature independently. The answer is the same for all of them.
For the industry view, see Financial Transactions.
Closing
A receipt is what is left when the network has stopped paying attention.
A cryptographic receipt is what the network needs when the customer and the bank disagree about what happened.
Six fields, one signature, and no party in possession of the whole truth.
That is what proof looks like.