A regulated brokerage must prove after the fact who did what, to which account, and on whose authority. What must the architecture provide?

What the audit record must be

• Immutable and append-only, so that a record cannot be altered after the fact — including by an administrator. Write-once storage or a cryptographic chain, not a table with an update permission.
• Complete for the defined scope, with absence detectable. A gap in an audit log must be visible, which requires sequence numbers or chaining. A log that can silently lose entries provides no assurance, because the missing entry is exactly the interesting one.
• Attributable to a person, not to a service account. "The batch job did it" is not an answer a regulator accepts, so the human actor must be propagated through every layer of automation.
• Timestamped from a trusted source, since a clock an operator controls undermines the ordering the record depends on.
• Retained for the regulatory period, which is usually years, in a form that remains readable — including after schema changes and system replacements.

What must be captured beyond the obvious

The transaction record is the easy part. What is usually missing:

• Read access to sensitive data, which many regulations require and most systems do not log.
• Authorisation decisions, including denials. A denied attempt is often the more interesting record.
• Administrative and configuration changes, which are how controls are weakened before a loss.
• The reason, where a judgement was exercised — an override, an exception, a manual adjustment — since reconstructing intent from a state change is impossible.

The design consequence

Audit cannot be a side effect of application logging. Application logs are lossy by design, rotated by volume, and reshaped whenever a developer changes a message. An audit record is a durable business artefact with a schema, a retention policy and an owner.

Emitting it in the same transaction as the state change is what makes it complete; emitting it afterwards means a crash produces a state change with no record, which is the exact condition an auditor is testing for.

The tension with erasure

Immutability conflicts directly with a data subject's right to erasure. The resolution is to keep personal data out of the immutable record behind a pseudonymous reference, so the reference can be tombstoned while the audit trail's integrity survives.

Designing this after the fact means rewriting every audit record ever written, which is why it belongs in the first version.