How to keep a tamper-evident audit trail without inventing one
Examiners and sponsor banks increasingly ask for tamper-evident audit logs. Here is what that phrase actually means, the three mechanisms that satisfy it, the three failure modes that quietly break them, and what to check for in a record beneath your stack.
What “tamper-evident” actually means
Append-only and tamper-evident sound similar; they are not. Append-only means new records cannot overwrite old ones at the storage layer. That is necessary but not sufficient. A database with INSERT-only permissions is append-only, but an examiner has no way to prove that a privileged user did not back-date or alter a record. Tamper-evident is stronger: any modification of a past record (even a single byte) is cryptographically detectable by anyone with the public key.
The bar comes from how compliance evidence is used. When an examiner subpoenas a customer's decision history from March 14, 2026, the question is not just “what did you say happened that day?” It is “can you prove this is what your system actually held on that day, unaltered?” A tamper-evident log answers that question. An append-only log only answers half of it.
The three mechanisms that satisfy the bar
Three cryptographic patterns, individually or in combination, produce a tamper-evident audit trail. Most production systems use all three.
- Hash chains. Each record contains the SHA-256 hash of the previous record. Modify any record retroactively and every hash from that point forward becomes invalid. Examiners verify by walking the chain. Implementations include AWS QLDB's journal, transparency logs (Certificate Transparency, Sigstore), and the per-Subject hash chains FinQub uses.
- Cryptographic signatures. Each record (or batch) is signed with a private key your service holds. The signature proves authenticity (this record was emitted by your service) and integrity (the bytes have not changed). The examiner verifies with the public key, which can be published or notarized. Common: HSM-backed signing for keys, RSA-PSS or Ed25519 for the algorithm.
- WORM storage (Write Once Read Many). Storage that physically prevents modification. AWS S3 Object Lock in compliance mode is the practical example: once a record is written with an Object Lock retention period, even AWS administrators cannot delete or modify it during the retention window. WORM is the substrate; hash chains and signatures are the math on top of it.
The combination an examiner most often sees in fintech compliance: WORM storage of the underlying records, hash chains across them per Subject, and signed batched exports when an exam packet is produced. Each layer reinforces the others.
What examiners actually check
Examiners do not look at the cryptography itself in most cases. They check three things that the cryptography makes provable:
- Completeness. Does the record contain every signal and every decision that touched the customer? Gaps in the record are the most common audit failure, and they happen when a vendor outputs land in a vendor console but never reach the consolidated record.
- Continuity. Does the record show an unbroken timeline from the customer's onboarding to today, with no missing periods? Gaps in the chain (rather than gaps in the data) suggest the system went down and the chain restarted without bridging.
- Provenance. Can the record show where each piece of evidence came from (which vendor, which API call, which list version) and that the issuer of that evidence has not been altered? This is what the cryptographic signatures answer.
When all three properties hold, an examiner can ask “what did you know on date X?” and get a single signed export that answers it. When any one of the three breaks, the answer becomes “here is what we currently think we knew on date X, reconstructed by hand.” That gap is what costs compliance teams weeks per exam.
Three failure modes that quietly break tamper-evidence
Most implementations get the cryptography right and the operational details wrong. Three patterns recur:
- Gaps in the chain. A record at time T+1 hashes the record at T+0. If the system loses a record between them (a queue drops, a write fails, a node reboots) the chain breaks, and every record from that point forward inherits a broken link. The fix is atomic appends, idempotent retries, and a separate continuous verifier that runs against the live chain, not just at export time.
- Key rotation without rollover. Signing keys must rotate (lifetime, compromise, policy). A naïve rotation invalidates everything signed by the old key, the moment the new key takes over. The correct pattern is to sign the rotation event itself with the outgoing key, so the chain of trust is unbroken across rotations. Few in-house implementations get this right on the first try.
- Clock drift and time without notarization. The timestamp on each record needs to be trustworthy on its own. A local clock that drifts (or worse, that can be set by an administrator) is not. The remedy is to anchor the chain to an external time source periodically: RFC 3161 timestamps, a public ledger, or a notary service. The cost is small; the audit improvement is large.
Reconstructing the chain across a vendor swap
The most common reason a real-world chain breaks is not the cryptography but a vendor migration. When you switch from one KYC vendor to another (Persona to Sumsub, for instance), the old vendor's console history stays in the old vendor. Whatever happens after the switch lives in the new vendor. The customer's compliance history becomes two disconnected logs, each tamper-evident inside itself, neither tamper-evident across the gap.
The fix is to put the chain on the record, not on the vendor. Every signal the old vendor produced lands on the customer record before the switch, with hashes forward. Every signal the new vendor produces lands on the same record after the switch, hashes continuing the chain. The chain survives because the chain was never tied to the vendor in the first place. See switching a KYC or KYB vendor without losing your audit history for the practical version.
Where the record sits in your stack
FinQub is the single source of truth for fintech risk decisions, with tamper-evidence built in. Every vendor signal that lands on a Subject is hashed into that Subject's chain. Every decision your rulebook or your analyst makes is hashed and signed. Exam packets are produced by walking the per-Subject chain and signing the export. The cryptography is invisible to your engineers and your analysts; only the examiner ever needs to see it, and when they do, the proof is in the export.
A checklist for tamper-evident readiness
- Append-only is not enough; require hash chains or signed exports on top.
- Verify the chain continuously, not just at export time. Most breaks show up between exams, not during them.
- Plan for key rotation before you launch. Use a key-rollover protocol that signs each rotation with the outgoing key.
- Anchor your clock externally. RFC 3161 timestamps or periodic notarization to a public ledger.
- Keep the chain on the record, not on any one vendor. Vendor swaps should not break the audit history (see vendor migration without losing history).
- Test an exam packet end-to-end with a simulated subpoena before you need to produce one for a real exam.
Frequently asked questions
Is append-only the same as tamper-evident?
No. Append-only means new records cannot replace old ones. Tamper-evident means any modification to past records is cryptographically detectable. A simple database with INSERT-only permissions is append-only; an examiner has no way to prove a record was not edited by a privileged user or a database administrator. Tamper-evident requires a cryptographic mechanism (hash chains, signed exports, or notarization) on top of append-only storage.
Do I need blockchain to be tamper-evident?
No. The cryptographic primitives that make blockchains tamper-evident (hash chains, signatures, Merkle trees) work without distributed consensus. A hash-chained log signed by your service's key, with periodic notarization to an external time source, satisfies the same audit bar without the operational complexity. Examiners care about the property (detect any modification of a past record), not the implementation (chain or no chain).
What is the most common failure mode?
Gaps in the chain. A record at time T+1 hashes the record at T+0. If the system goes down between T+0 and T+1 and a record is lost or written out of order, the hash chain breaks and every subsequent record carries a broken link. Most implementations get the cryptography right and the operational continuity wrong. The fix is a careful write path (atomic append, idempotent re-tries) and continuous verification that runs against the live chain, not just at export time.
How does key rotation affect a tamper-evident log?
Signing keys rotate. A naïve implementation invalidates older signatures the moment a key rotates. The right pattern is to publish each rotation as a signed event in the chain itself, with the previous key signing the rotation. The examiner sees an unbroken chain of trust from any historical record forward to the current key. Cryptography papers call this a key-rollover protocol; the practical name is ‘sign every key change with the key it replaces.’
Can FinQub be the tamper-evident log for vendor signals my team did not write?
Yes; that is the design. FinQub captures every vendor signal that touches a Subject, the rule that fired, the decision your team made on it, the override if there was one, and the policy version that applied. Each event is hashed into a per-Subject chain and signed by FinQub's key. Exam packets are produced by walking the chain and signing the export. The vendor itself does not have to support hash chains; the record beneath the vendor does.
Tamper-evidence is a property of the record, not of any one vendor. See how a point-in-time replay uses the chain, or book a short walkthrough below.