Insider threat

The principal firm operates the workspace. The principal firm is also, in principle, the actor with the strongest incentive and the deepest access to manipulate the supervisory record against an AR they want to off-board cheaply or against an AR who has filed an awkward complaint. This is the central insider-threat shape the product holds against.

The defence is structural, not procedural. The audit log is immutable. Every event is attributed to a named actor. Past records cannot be rewritten. The AR sees their own record. The AR has a Challenged affordance on completed file reviews. None of these depends on the principal firm’s good behaviour.

The threat

A principal-admin or a principal-compliance-officer at a regulated firm has plausible motives to:

• Re-write the findings of a completed file review to support a pre-decided off-boarding.
• Fabricate a file review or a breach report against an AR whose conduct the firm finds inconvenient.
• Re-tune risk-scoring weights specifically to push one AR into the critical band ahead of an annual review.
• Alter or delete a breach report that, if surfaced honestly, would trigger a SUP 15 notification the firm preferred not to make.
• Backdate a supervisory event to claim earlier action than was taken.
• Suppress an AR’s view of their own audit trail to prevent the AR from contesting findings.

Each of these is materially harder under the product’s design than under the alternative the firm would otherwise use (a spreadsheet, an email thread, a hated SaaS with edit-anywhere semantics).

Mitigations

1. The audit log is append-only at the storage layer

Postgres audit_events table grants the application role INSERT only. UPDATE and DELETE are revoked. A trigger blocks TRUNCATE. Every write to a substantive entity (AR, breach, file review, MI return, annual review, conduct event, risk-weight change, role change) emits an AuditEvent synchronously inside the same transaction; if the audit write fails, the substantive write rolls back.

A daily integrity-check job reads every event in chain order and verifies that hash(event_n) == event_(n+1).prevHash. A mismatch raises a P1 incident and shows a banner in the affected tenant’s workspace. Detail in tampering and replay.

2. Findings are immutable once a file review is complete

The file review state machine is scheduled → in-progress ↔ awaiting-evidence → complete. The complete transition locks findings, score, notes, and writes a review.completed audit event. There is no API path that mutates a completed review’s findings. To re-open a review, the principal-side compliance officer schedules a fresh review (a new FileReview row, with a new id). The original sits in the audit chain, unaltered.

The same shape applies to MI returns (submit is terminal; subsequent transitions are queried and accepted on the principal side, neither of which alters the AR’s submitted figures), to breach reports past Resolved, and to annual reviews past signed-off.

3. Every event is attributed to a named actor

AuditEvent.actorUserId and AuditEvent.actorRole are non-null on every write. The system role is reserved for scheduled jobs (anomaly recompute, retention purge); it cannot edit findings or sign off reviews. Step-up authentication on terminal actions (FCA notification, annual-review sign-off, AR off-boarding) records the second factor as a separate event and binds the terminal action to a specific authenticated session within the last 5 minutes.

Director sign-off on an annual review carries the director’s name, the firm’s FRN, the verbatim signOffNotes, and a step-up event id. A director cannot later deny having signed off, and a compliance officer cannot sign off in a director’s name.

4. The AR sees their own audit log

AR-user accounts have read access to events scoped to their own AR via the RLS predicate tenant_id = $tenant AND ar_id = $ar. The events visible to the AR include:

• File reviews scheduled, in progress, and completed against them.
• Breach reports filed against them by the principal (if any), with the named principal-side actor.
• Risk-band changes with the named actor and the audit-event id of the underlying weight change or recomputation.
• Annual review packets opened and signed off, with the named director.
• Off-boarding events.

An AR who suspects the firm has fabricated a finding has the chronology in their hands without needing to ask. They can also export their own audit log as a JSONL bundle plus SHA-256 manifest.

5. The AR can challenge a completed file review

Within 10 working days of review.completed, the AR’s chrome shows a Challenge affordance on the review. Clicking it transitions the review state to challenged and writes a review.challenged audit event with the AR’s note. The principal-side compliance officer must respond by reopening the review (state returns to in-progress) and either upholding, amending, or withdrawing the findings. The original complete snapshot remains in the audit log; the new complete event sits next to it.

This is structural, not advisory. There is no UI path on the principal side to dismiss a challenge without re-opening. The AR’s challenge is itself a regulatory artefact: a SUP 12 dispute by an AR is a fact the principal firm must address.

6. Risk-score changes are themselves audited

The risk-scoring weights are tunable by principal-admin in the firm-settings panel. Every change writes a RiskWeightChange audit event with the prior and new vectors and triggers a full recompute. Old score snapshots are immutable; the recomputed scores are written as new history rows. The AR’s risk-trajectory chart shows a band shift at the change date with a tooltip linking to the audit event and the actor. A retroactive “always was a critical AR” narrative is impossible to construct.

A principal-admin who tries to push one AR into critical by skewing the weights triggers a band shift across the entire AR estate, which is visible to other principal-admins, to the compliance officer, and (in any tenant that has enabled it) to the FCA-auditor read-only role.

7. FCA-auditor role

A per-tenant feature flag exposes a read-only FCA-auditor role. The principal firm decides whether to enable it. When enabled, the FCA-auditor sees the live AR register, the breach triage queue, the file reviews, the annual review packets, and the audit log. The auditor cannot write. The auditor’s reads are themselves audit-logged.

This is not a primary defence but it is a credible deterrent: a principal firm that has enabled FCA-auditor access cannot manipulate records without the regulator seeing the manipulation in the chain.

Residual risk

A determined principal-admin with database-level access (the operator of the production database, not a workspace user) could in principle alter the underlying rows. The prevHash chain detects this within 24 hours; the off-platform durable copy (S3 object lock, ten-year compliance mode, see tampering and replay) preserves the unaltered evidence even if the live database is compromised. A regulator-led restoration from the durable copy is the recovery path.

Collusion between two principal-side directors to sign off on a fabricated annual review is bounded by the AR’s view of their own packet (an AR who reads their packet immediately after sign-off and finds it inconsistent with their own records can challenge it under SUP 12 dispute machinery), and by the verbatim record of what was signed.

The product cannot prevent a principal firm from making a bad supervisory decision. It can prevent the firm from rewriting the record afterwards to make the decision look better than it was.