AML: Sanctions screening with an audit trail regulators can trust
The problem
A correspondent-banking compliance analyst gets a wire transfer flagged by monitoring rules. Before it clears, they need three answers: is the counterparty (or anyone who beneficially owns it) on a sanctions list, who else in the ownership chain might be hiding exposure, and — if a regulator asks six months from now — can the bank prove exactly what was checked, when, by whom, and under what legal authority?
Today that's a spreadsheet export from a sanctions-screening vendor, a manual pull from a corporate registry, and a hope that someone remembers to log the decision. The screening tool and the audit trail live in different systems, so "prove it" means reconstructing a timeline from logs that were never designed to be evidence.
The scenario
A $2.3M wire is flagged. The receiving entity is a Cyprus-registered holding company the bank has never screened directly — but its ultimate beneficial owner might already be on the OFAC SDN list under a different legal entity. The analyst needs a single, provable action: screen the entity, trace ownership up to the natural person, and get a receipt that survives a regulator's audit request.
Screen and trace in one governed pass
Relata's SANCTIONS_SCREEN and BENEFICIAL_OWNERSHIP_CHAIN are both SQL-reachable operators — no separate screening product, no CSV round-trip. Every call carries a PURPOSE that is written to the tamper-evident audit hash chain, and WITH PROVENANCE attaches the source and confidence of every row returned.
PURPOSE 'aml_investigation:WIRE-2026-04412'
-- 1. Screen the receiving entity directly
SELECT * FROM SANCTIONS_SCREEN('Meridian Holdings Ltd')
WITH PROVENANCE;
-- 2. Trace beneficial ownership up to natural persons, then
-- screen every name the chain surfaces
SELECT chain.depth, chain.owner_name, chain.ownership_pct,
SANCTIONS_SCREEN(chain.owner_name) AS screen_result
FROM BENEFICIAL_OWNERSHIP_CHAIN('Meridian Holdings Ltd', 6) chain
WITH PROVENANCE;Typed SDK snippet
from relata import RelataClient, AuditClient
with RelataClient(
"http://localhost:9090",
bearer_token="relata-dev",
purpose="aml_investigation:WIRE-2026-04412",
) as client:
# Direct screen
hits = client.query("SELECT * FROM SANCTIONS_SCREEN('Meridian Holdings Ltd')")
for row in hits:
print(row["list_id"], row["designation_date"], row["match_confidence"])
# Walk the ownership chain and screen every name it surfaces
chain = client.query(
"SELECT * FROM BENEFICIAL_OWNERSHIP_CHAIN('Meridian Holdings Ltd', 6)"
)
for link in chain:
result = client.query(
f"SELECT * FROM SANCTIONS_SCREEN('{link['owner_name']}')"
)
if result:
print(f"Hit at depth {link['depth']}: {link['owner_name']}")
# Pull the signed, court-defensible receipt for this exact investigation
with RelataClient("http://localhost:9090", bearer_token="relata-dev", purpose="compliance_review") as client:
audit = AuditClient.from_client(client)
receipt = audit.signed_receipt(exhibit_id="WIRE-2026-04412")Why this is defensible, not just fast
- Every screen is audited, not logged.
PURPOSE 'aml_investigation:WIRE-2026-04412'is recorded against the principal, timestamp, and every row touched in the same hash-chained audit log that governs writes — see Governance. - The receipt is signed, not exported.
AuditClient.signed_receipt()returns a verifiable record of exactly what was screened and when — the same primitive used for regulatory exam responses, not a bolt-on report generator. - Ownership tracing and sanctions screening are the same engine. There's no join between a KYC vendor's API and a separate case-management tool —
BENEFICIAL_OWNERSHIP_CHAINandSANCTIONS_SCREENrun against the same governed store, so the two results are provably about the same investigation. - Bi-temporal by default. A sanctions designation added last week doesn't rewrite history —
AS OFqueries can show what was knowable at the time the wire actually cleared, which is exactly what a regulator asks about.
See also
- Governance —
PURPOSE, the audit hash chain, and signed receipts - Identity Resolution — how
IdentityIndexlinks a legal-entity name to every canonical identifier it appears under - Query Cookbook — the full operator TVF reference, including
SANCTIONS_SCREENandBENEFICIAL_OWNERSHIP_CHAIN - LEA: court-admissible investigation graph — the same audit primitives applied to a criminal case file