Tamper-Evident Audit Log Service with Merkle Proofs for Fintech Apps

The problem with audit logs in fintech and health apps

Regulators, auditors and enterprise customers ask fintech and health startups the same questions: who accessed this customer's record, who changed this payout account, and can you prove the log was not edited afterwards? Most startups store audit events in an ordinary database table. Anyone with database access, including an attacker or an insider covering their tracks, can delete or change a row, and nobody can tell.

A log that is only trustworthy if you trust the database administrator is weak evidence. The problem is sharper in small companies, where the same two engineers have access to everything.

What already exists and the gap

• Trillian (Google, via transparency.dev): an open source verifiable log based on Merkle trees, the foundation of Certificate Transparency. Proven and powerful, but a general building block with a learning curve.
• Certificate Transparency: shows the model at internet scale: browsers check certificates are included in public logs, and anyone can verify the log's history was not rewritten.
• immudb: an open source immutable database with cryptographic verification of records.
• Amazon QLDB: a managed ledger database that AWS has since deprecated, leaving users to migrate.

The gap is a focused audit log service for application teams: a simple API for "record this admin action", receipts, independent witnessing, and a verifier an auditor can run, packaged so a startup can adopt it in a day.

What you build

Roles: client app (sends events), operator (runs the service), auditor (verifies).

1. The client app sends an audit event. The service queues it, appends a batch to the tree, and returns a receipt with the entry index.
2. At intervals the service signs the current tree head (size and root hash) and sends it to a witness, which stores it and countersigns.
3. An auditor asks for an entry and its inclusion proof, plus a consistency proof between an old tree head they saved and the current one. The verifier checks both locally.
4. If any entry was changed, deleted or reordered after being logged, the proofs fail.

The technically interesting part

The centre of the project is implementing and proving the Merkle log correctly: leaf and node hashing with domain separation, inclusion proofs, consistency proofs between tree sizes, and storage that stays efficient at millions of entries. Russ Cox's "Transparent Logs for Skeptical Clients" and the transparency.dev article on tile-based logs describe how to store the tree as fixed-size tiles so that proofs need few reads. Implement it, then test it against known vectors and with property-based tests (every inclusion proof for every size verifies; any single-bit change fails).

The second part is the threat model: what a malicious operator can and cannot do. They can refuse to log an event, which receipts expose. They can show different histories to different people, which witnesses expose. Write this down clearly; it is what evaluators will probe.

How to evaluate it

• Correctness: pass published test vectors for the hashing scheme; property tests for proofs across thousands of random tree sizes.
• Tamper detection: a table of attacks (edit, delete, insert, reorder, fork) and whether each was detected, with how.
• Performance: append throughput and proof generation latency at 1 million and 10 million entries; proof size in bytes.
• Integration effort: lines of code and time for a classmate to add audit logging to a sample app using your SDK.

Suggested plan

1. Weeks 1 to 4: read RFC 6962, the Trillian and transparency.dev material and "Transparent Logs for Skeptical Clients"; write the threat model.
2. Weeks 5 to 10: Merkle tree, proofs, test vectors and property tests.
3. Weeks 11 to 15: API, batching, tile storage, signed tree heads.
4. Weeks 16 to 20: witness service, verifier tool and page.
5. Weeks 21 to 24: SDK and sample fintech or clinic app.
6. Weeks 25 to 28: tamper tests, benchmarks, write-up.

Path to a product

The first customer is a fintech or health startup preparing for a bank partnership, regulatory inspection or enterprise security review, where "our audit log is cryptographically verifiable" is a strong answer. Offer an open source core and a hosted service with an independent witness, priced by events per month. Auditors and compliance consultants become advocates if the verifier is easy for them to run.

Scope warning

Do not use a blockchain; a Merkle log with witnesses gives the guarantees you need without consensus overhead. Do not invent new cryptography; use standard hashes and signatures. Do not build a general database; the log stores audit events and nothing else.

Learn what you need on Sefism

• System design roadmap : append-only storage, batching and service design.
• System design cheat sheet : quick reference for consistency and storage trade-offs.
• DSA roadmap : trees and hashing, the core data structure of this project.
• Go Documentation : the language Trillian and much of the transparency tooling use.
• OWASP ASVS : logging requirements your client apps should meet.

Get help with this idea

Scoping a security project is mostly about deciding what you will not defend against and how you will prove the rest works. If you want a second opinion on scope, stack or your evaluation plan, a mentor can review it with you; you still build it yourselves. New to Sefism? Create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session