Appearance
Audit trail
Audit activity, needing audit_event.view. An append-only record of who did what.
What is recorded
| Area | Events |
|---|---|
| Merchants | entity.created, entity.details_updated, entity.document_added |
| Reviews | entity_review.approved, .rejected, .escalated, .escalated_to_aml, .assigned, .checks_queued |
| Screening | screening_match.false_positive, .adjudication_reverted, .adjudication_voided |
| API keys | api_key.created, api_key.revoked |
| Provider settings | provider_configuration.changed |
| Team | team_member.invited, team_member.invitation_resent, team_member.access_updated |
| Webhooks | webhook_endpoint.created, .updated |
Each carries the account, the auditable record, the actor, a human-readable summary and structured metadata.
Decisions carry their context
An approval made while a PEP match was present records that fact and the matched names. The trail therefore shows the decision was informed — which is the question an auditor actually asks.
Record versioning
Verity also keeps versions of changed records (via PaperTrail) with the acting user attributed, so field-level history is available beyond the event summaries.
What the trail is for
Three questions, in practice:
- Who decided this, and what did they know?
- When did this access change, and who changed it?
- Was this check actually run, or is the state inherited? — the audit trail plus the provider fetch runs answer this together