Part 8 · 1 chapters · ~8 min
Audit, Regulators and Reporting
Audit trails that answer who did what and why, immutable logs and maker-checker approvals for manual entries, regulatory reporting and returns, data retention, segregation of duties, and preparing for an audit.
17
Audit trails and maker-checker
| control | implementation |
|---|---|
| who, what, when, why on every change | actor, action, before/after, reason and request id in an append-only audit log (separate store, restricted access) |
| maker-checker | manual adjustments created by one person, approved by another, posted only after approval; the system refuses self-approval |
| segregation of duties | engineers cannot post entries in production; operations cannot change code; database access is break-glass and logged |
| tamper evidence | hash-chain audit records or write to WORM storage (object lock) |
| retention | keep ledger and audit records for the regulated period (often 5-10 years), then delete or anonymise on schedule |
Regulatory reporting (central bank returns, AML suspicious transaction reports, tax filings) should be generated from the ledger and reconciled data, never from ad hoc queries on production replicas. Build them as versioned, tested jobs whose outputs are archived with the inputs that produced them.