Audit trail

Ce contenu n’est pas encore disponible dans votre langue.

When a regulator, an internal auditor or a court asks “why did you — or didn’t you — report this customer?”, you need to answer with evidence, not memory. SpeculaPro is built so that the evidence is always there and cannot have been altered.

Four layers of evidence

Layer	What it proves	Can it change?
Stored transactions	Exactly what data SpeculaPro received, including the original payload	Kept as received
Frozen rule versions and hits	Exactly which logic and parameters ran, and what the rule saw	Approved versions are locked; hits are kept
Case timelines	Every comment, assignment, escalation and decision on a case	Append-only — no edits, no deletes
Audit log	Every configuration change and every sensitive action, by anyone	Append-only — no edits, no deletes

The audit log

The audit log is a single, permanent record of who did what, to what, and when.

Field	Meaning	Example
When	Date and time	2026-11-03 14:22:07
Actor type	A person, an API key, or the system itself	`user`
Actor	Which one	Kofi Boateng
Action	What was done	`rule_version.approve`
Entity	What it was done to	rule version `fan_in_senders` v3
Before / after	The values before and after a change	`state: pending_approval` → `approved`
IP address and browser	Where the request came from	41.66.x.x
Request id	Ties the entry to the system’s own logs

What gets logged

Logged today (the full list is in Audit log):

Rule changes: packs installed, rules created, versions drafted, submitted, approved or rejected, deployed, enabled and disabled.
Case and alert actions: dismissing an alert, opening or joining a case, comments, assignment, escalation, closing, approval and reopening. Alerts the system links to a case by itself are recorded too, with the system as the actor.
Sign-ins and security events — sign-in, sign-out, password changes, two-factor set-up, API keys created and revoked.
Risk controls: designations added and revoked, suppressions proposed, approved and revoked, lists created and values added or removed.
Access to protected personal data: when someone opens a customer’s profile with the phone, email, national ID and date of birth shown in clear (customer.view_pii), at most once per person and customer every 30 minutes.
People and access: people added, roles changed, access disabled or enabled, two-factor and password resets.
Workspace creation — the very first entry for every workspace is tenant.create.
Settings, reports and connections: workspace settings, regulatory reports from draft to the FIC’s answer, webhooks, data sources, single sign-on, licences and rule-pack updates.
Approvals and roles: every change request from proposal to decision, approval-policy changes, and custom roles created, changed or deleted.

Every action is listed in the audit log reference, and people with audit.view can read it under Settings → Audit log.

Who can read the audit log

Reading the audit log needs audit.view. With the built-in roles, the MLRO, the Auditor and the Administrator have it. The Auditor role is read-only throughout, so you can give it to internal audit or to an examiner on site without risk.

Reconstructing a decision

To answer “why was this customer reported?”, you can show:

The transactions — as SpeculaPro received them, with the original payload.
The hits — which rule versions fired, the exact parameters, and the feature values each saw (for example “21 distinct senders in 72 hours”).
The rule versions — the frozen logic, who wrote it, who approved it, and the change note.
The case timeline — every comment, escalation and decision, by whom, and when.
The report — who drafted it, who approved it, when it was submitted and the regulator’s reference.
The audit log — anything else that touched the customer, the rules or the case, including who looked at the customer’s personal data.

To answer “why was this customer not reported?”, the same trail shows the disposition and its note, any suppression that applied — and every hit that suppression swallowed — and the designations in force at the time, including revoked ones.

How long records are kept

Each workspace decides, under Privacy → Retention & legal holds, how long its transactions, customers, alerts and cases, decisions, account events and audit log are kept. A period can’t be shorter than the AML minimum for the laws that apply (five years in Ghana), and nothing is removed until the data protection officer has looked at a dry run and switched the purge on. Until then, everything is kept.

Even with the purge on, the evidence an examiner relies on stays:

Regulatory reports are never deleted, nor the transactions, decisions and cases behind them.
Open cases, and anything under a legal hold, are never purged.
The audit log is removed only as whole months, once every workspace with entries in that month is past its period. Each purge, and each month removed, is itself written to the audit log.

See Retention and legal holds.