What to record so a future reviewer can understand the check, the evidence, and the decision
Audience: Developers building compliance case management and evidence trails
Sanctions screening is most useful when it is treated as a transparent workflow control rather than a hidden yes/no lookup. This article focuses on one practical design angle for teams that need to screen customers, suppliers, payees, organisations, or other counterparties while keeping human judgement, evidence, and system behaviour clear.
An audit trail is more than a timestamp
A log line saying ‘sanctions check passed’ is not enough to explain a decision months later. A reviewer needs to know who or what was screened, which data was supplied, which lists and versions were used, what threshold applied, what matches were returned, and who resolved any ambiguity.
Audit readiness should be designed into the workflow rather than added after a regulator, customer, or internal auditor asks for evidence.
Record the subject snapshot
Store the exact subject data used for the check, subject to your retention policy. If the application normalises names or dates, retain both the original and normalised forms or a clear transformation record. Otherwise, a reviewer cannot reproduce why a match appeared.
The Sanctions Screening input can include structured person or organisation attributes. Its output returns the subject and detailed matches, making it possible to link the request and result in a case record.
Record the screening configuration
Store the selected lists, threshold, fuzzy setting, entity type, mode, and relevant product or integration version. The product supports restricting lists and changing thresholds; those choices affect results and should not be lost.
If the application uses defaults, materialise them in the evidence record. ‘Default at the time’ is difficult to defend when defaults later change.
Record the source evidence
For every material match, retain source list names, entity IDs, programmes, matched names, list versions, source URLs, and confidence or match type. The product consolidates identities across lists while preserving the source collection under each match.
Source evidence lets an analyst verify the record and helps developers troubleshoot list or parsing changes. It also prevents the narrative summary from becoming the only evidence.
Record the human decision
A REVIEW or ESCALATE result should create a case with owner, timestamps, notes, disposition, and approval authority. Whitelisting or dismissing a match should require a reason. If more information was collected, record what changed the assessment.
Do not overwrite the original automated result with the final human conclusion. Keep both. The distinction between ‘system found a candidate’ and ‘analyst resolved it as a false positive’ is essential.
Certificates and exports
The product can generate an optional PDF audit certificate documenting the run. Certificates can be useful for a human-readable record, while structured JSON or dataset output is better for system queries and analytics. Retain the format that supports your policy, and avoid assuming a PDF alone is sufficient for every audit requirement.
Protect evidence with access controls and integrity measures. Define retention and deletion rules. Screening information can be sensitive even when source lists are public.
Test the evidence path
Run an internal exercise: select an old screening decision and ask a reviewer unfamiliar with the case to reconstruct what happened. Can they see the subject, configuration, sources, technical status, analyst reasoning, and final action? Can they distinguish a clean result from a failed run?
If the answer depends on a developer searching application logs, the workflow is not yet audit-ready. Build the evidence record as a first-class product feature.
Using Howth Technology Factory Sanctions Screening
The product screens names, organisations, and supported crypto addresses against official OFAC, EU, UK OFSI, and UN sanctions sources, with additional PEP and watchlist coverage described on the Apify listing. It supports single and bulk checks, structured CLEAR/REVIEW/ESCALATE outputs, match scores, source details, monitoring, and optional audit certificates. It is designed as a workflow component, not as legal advice or a replacement for a qualified compliance programme.
Product page: OFAC sanctions screening by Howth Technology Factory
Important boundary
A screening result is an input to a compliance decision. REVIEW and ESCALATE results require appropriate human investigation. CLEAR means no qualifying match was found above the selected threshold across the sources screened at that time; it is not a guarantee. Organisations should define their own legal basis, policies, reviewer authority, retention rules, and escalation procedures.
Example evidence record
A useful evidence record might contain the internal subject ID, the submitted name and attributes, request time, provider run ID, mode, selected sources, threshold, source versions, returned verdict, narrative, consolidated matches, source entity IDs, technical status, reviewer, disposition, notes, and final business action. Store links to any certificate or exported dataset rather than relying on filenames in shared folders. Use immutable event history or another method that preserves earlier states when a case is updated.
Privacy and access controls
Public sanctions lists do not make every screening case public. Subject profiles, passports, dates of birth, internal decisions, and investigation notes may be sensitive. Apply least-privilege access, retention periods, deletion procedures, and secure exports. Avoid placing full subject data in notification emails or general application logs. An audit-ready system protects evidence while also making authorised review straightforward.
Implementation takeaway
Audit readiness also improves ordinary debugging. When a reviewer disputes an alert, the team can inspect the exact input, configuration, source record, and code path without guessing. When a source changes format, historical records show whether older runs used different data. When a threshold changes, the organisation can identify which decisions were made under the prior setting. Evidence design therefore supports both compliance accountability and reliable software maintenance.
Operational ownership
Define how evidence is exported when an authorised reviewer needs it. Exports should include understandable labels, source references, and the final disposition while excluding unrelated personal data. Test that links and certificates remain accessible for the required retention period. Also test deletion at the end of that period. A system is not well governed if it can retain evidence but cannot dispose of it safely.
Top comments (0)