What is a restricted-party screening audit trail, and why it matters

A screening tool without an audit trail is a search engine. A screening tool with an audit trail is a compliance program. The difference matters the first time a bank, auditor, or regulator asks the question every sanctions program eventually gets: "prove it."

Informational only, not legal advice.

What an audit trail is

An audit trail is a durable, tamper-evident record of the screening decisions your organization has made. At minimum, for each screening event, it captures:

• What was searched — the exact query string
• When — an immutable timestamp
• Against what — the list sources and their version or ingestion timestamp
• By whom — the user or system identity that performed the search
• What matched — the returned entities and their confidence scores
• What was decided — clear/potential/confirmed adjudication and the reason
• What happened next — if a hit was confirmed, the escalation and any blocking or reporting action

The audit trail is not the same thing as your CRM notes or your Slack conversations. It has to be reconstructable — six months later, on demand.

Why it matters

Regulators expect it. OFAC enforcement actions consistently cite the absence of adequate records as an aggravating factor. A program without an audit trail is treated as no program at all.

Banks and sponsors require it. If you are a fintech riding on a sponsor bank, your BSA/AML and sanctions questionnaires will ask about record retention (typically five years). "We do screening but do not log it" is not an acceptable answer.

Auditors need it. SOC 2, ISO 27001, and vendor-risk reviews increasingly probe sanctions controls. An auditor cannot verify a control that produces no records.

Insurance cares. Cyber, professional liability, and E&O policies with financial-crime endorsements sometimes ask about screening programs during renewal.

Your future self cares. The first time a customer relationship goes bad and someone asks "did we know when we onboarded them?", you want an answer.

What "defensible" looks like

The audit trail has to survive scrutiny. That means:

Immutable. Once written, records cannot be edited to change the historical fact of what was screened and decided. Corrections happen as new entries, not overwrites.

Complete. Every screening event is logged — not just the interesting ones. Selective logging looks like curation, which looks like hiding things.

Time-stamped precisely. UTC timestamps, ideally with server time rather than client time. "Screened around lunchtime" is not a record.

Linked to identity. Every event is tied to a user or system principal. Shared logins destroy the audit trail.

Retrievable. You can pull the record on demand, six months or five years later. Exportable to CSV or PDF for regulator or bank requests.

Retained for the required period. For OFAC purposes, five years past the last transaction with the counterparty is a defensible default.

Where teams get it wrong

• Logging only "positive" hits. If you only log confirmed matches, the record does not show that you screened at all for the 99.9% of counterparties who were clear.
• Using screenshots as evidence. Screenshots are trivially fabricated and not auditable at scale.
• Storing logs in the same system that could be manipulated. If the same admin who approves customers can also edit the audit trail, it is not tamper-evident.
• Not versioning the list. Screening "against OFAC SDN" is not enough — you have to be able to show which version of the list, as of what time.
• Relying on team memory. Screening decisions made by a person who has since left the company evaporate if they only lived in that person's head or DMs.

What good enough looks like at SMB scale

You do not need an enterprise GRC platform to keep a defensible audit trail. A modest, honest setup works:

1. Every screening event is written to an append-only log table with the fields above.
2. Users authenticate with a real identity (no shared accounts).
3. The log is exportable to CSV.
4. List versions are recorded (ingestion timestamp is a defensible proxy).
5. Retention is documented in policy (five years is a safe default).

How Kleerance handles this

Every authenticated Kleerance search — free or paid — writes an audit-log entry with the query, matched entities, confidence scores, list versions, and user identity. The log is per-account, exportable, and immutable from the user's side. Anonymous searches from the homepage are still logged in aggregate so unauthenticated usage does not create a gap.

See how to screen vendors against OFAC SDN for the workflow, or start a free trial and inspect the audit log directly.