Sanctions screening
Sanctions list monitoring with signed webhooks
Screening answers whether an entity is sanctioned right now; monitoring tells you when that answer changes. Register the identifiers you care about and CompliAPI POSTs a signed webhook event to your endpoint whenever one is added to, removed from, or returned to any list we track.
POST https://your-endpoint.example/events (X-CompliAPI-Signature signed)
# Verify the X-CompliAPI-Signature header before trusting a payload
import hashlib, hmac, time
def verify(secret: str, body: bytes, header: str, tolerance: int = 300) -> bool:
parts = dict(p.split("=", 1) for p in header.split(","))
timestamp, signature = parts.get("t", "0"), parts.get("v1", "")
if abs(time.time() - int(timestamp)) > tolerance:
return False
expected = hmac.new(
secret.encode(), f"{timestamp}.".encode() + body, hashlib.sha256
).hexdigest()
return hmac.compare_digest(expected, signature)// Verify against the raw body Buffer — never re-serialized JSON
const crypto = require("crypto");
function verify(secret, rawBody, header, tolerance = 300) {
const parts = Object.fromEntries(header.split(",").map((p) => p.split("=", 2)));
const timestamp = Number(parts.t);
if (Math.abs(Date.now() / 1000 - timestamp) > tolerance) return false;
const expected = crypto
.createHmac("sha256", secret)
.update(`${parts.t}.`)
.update(rawBody)
.digest("hex");
return crypto.timingSafeEqual(Buffer.from(expected), Buffer.from(parts.v1 ?? ""));
}Response
{
"id": "evt_1234",
"type": "entity.listed",
"created_at": "2026-08-31T12:00:00Z",
"monitored_entity": {
"id": 42,
"entity_type": "onchain_address",
"value": "vitalik.eth",
"label": "customer hot wallet"
},
"listing": {
"list": "ofac",
"list_name": "US OFAC SDN",
"list_type": "sanctions",
"value": "0xd8da6bf26964af9d7eed9e03e53415d37aa96045",
"source_url": "https://sanctionssearch.ofac.treas.gov/Details.aspx?id=...",
"metadata": {"sdn_name": "..."}
}
}Minutes, not batch jobs
OFAC's change feed is ingested every 15 minutes and events for monitored entities are delivered within minutes of a list change landing.
Every event signed
Deliveries carry an HMAC-SHA256 X-CompliAPI-Signature header with a timestamp, so your endpoint can verify authenticity and reject replays.
Listings and delistings both
entity.listed, entity.delisted and entity.relisted events, each naming the list that changed and its list type — sanctions, crime, or risk.
Retries with backoff
Failed deliveries retry over roughly a day (1m, 5m, 30m, 2h, 12h) before being marked failed; persistently failing endpoints are disabled automatically and the owner is emailed.
Configured in minutes
Monitored entities and endpoints are managed on the dashboard — add a value from the entity search with one click, send a signed test event, and view or rotate the signing secret any time.
From point-in-time screening to ongoing sanctions monitoring
A screening call is a snapshot: the wallet you checked at onboarding was clean that day. Sanctions lists move afterwards — OFAC publishes changes on no schedule, and a counterparty that passed every check can be designated months into the relationship. The traditional answer is scheduled re-screening, which works but leaves a window as wide as your cron interval and burns quota re-checking identifiers that never change.
Monitoring inverts the model: register the identifiers that matter — customer payout wallets, counterparty emails and domains, registration numbers — and the change comes to you. When an ingestion run adds, removes, or restores a monitored value on any list, an event row is written in the same transaction as the list change itself and delivered to your endpoints within minutes. Delistings are first-class events, not silence: a counterparty coming off a list is compliance-relevant news too.
Each monitored entity's current listings are also visible at a glance on the dashboard, so the monitoring page doubles as a live status board for your watched identifiers.
Delivery you can build on
Deliveries are at-least-once and unordered by design, with a stable event id (evt_…) that is identical across retries — deduplicate on it and order by created_at. Your endpoint acknowledges with any 2xx within ten seconds; anything else retries on a backoff schedule of roughly one minute, five minutes, thirty minutes, two hours and twelve hours before the delivery is marked failed.
Every delivery is signed: the X-CompliAPI-Signature header carries a timestamp and an HMAC-SHA256 over the raw body, computed with a per-endpoint secret you can view and rotate from the dashboard. Verify with a constant-time comparison and a five-minute timestamp tolerance — the docs include ready-to-paste Python and Node verification code, and the dashboard's test button sends a signed test event so you can prove the pipeline end to end before anything real fires.
After five consecutive failed deliveries an endpoint is disabled automatically and the organization owner is emailed, so a dead endpoint is surfaced instead of silently swallowing events. Events that occur while an endpoint is disabled are not replayed — re-enable it and delivery resumes with new events.
What you can monitor
Monitoring covers the exact-match identifier types: crypto addresses (ENS names are resolved to their address when you add them), email addresses, websites, and government IDs. Matching uses the same normalization as the screening API, so a monitored www.example.com matches a listed example.com. Up to 25 entities per organization on the Developer plan and 100 on Team, with up to three webhook endpoints each receiving every event.
Events fire per list: a wallet added to both the OFAC SDN list and the UK Sanctions List produces two entity.listed events, each carrying its list, list type, the listed value, the official source record, and the list entry's metadata — the same attribution screening responses carry.
| Monitored type | Matching |
|---|---|
| Crypto address | Exact, case-insensitive; ENS names resolved at creation |
| Email address | Exact, case-insensitive |
| Website | Exact after scheme and www normalization |
| Government ID | Exact only — screening's partial ID matching does not apply |
Catch list changes without polling for them
Staying current after onboarding means re-screening your whole book on a schedule: a cron job, a stored-identifier loop, quota spent on unchanged entities, and a detection window as wide as the interval — plus your own diffing if you want to know what changed rather than re-derive it.
CompliAPI already reconciles every list change against its data; monitoring plugs your identifiers into that pipeline. Register the entities once, receive a signed event when one is listed, delisted, or re-listed, and route it to your alerting, case management, or blocking logic.
Monitoring watches the identifiers you register against the lists CompliAPI ingests — events reflect changes to that list state. It is not transaction monitoring, does not watch on-chain activity, and sends nothing about entities you haven't registered.
How it works
Register entities and an endpoint
Add the wallets, emails, websites or IDs to monitor on the dashboard — or one click from the entity search — plus an https endpoint. Send a signed test event to prove the wiring.
CompliAPI watches every list ingestion
Each reconciliation run checks its changes against your monitored entities. A match writes an event atomically with the list change itself.
Receive, verify, act
Your endpoint verifies the X-CompliAPI-Signature header, deduplicates on the event id, and routes the event — freeze a payout, open a case, or notify the compliance channel.
What you can screen
- Crypto addresses (ENS names resolved at creation)
- Email addresses
- Websites and domains
- Government-issued IDs (exact match)
Where teams use it
Customer wallet watchlists
Monitor payout and deposit addresses on file so a designation after onboarding triggers an alert instead of waiting for the next re-screen.
Counterparty change alerts
Watch supplier and partner domains, emails and registration numbers for the life of the relationship.
Automated holds
Wire entity.listed events to your payment pipeline to pause transfers involving a newly listed identifier pending review.
Delisting workflows
Use entity.delisted events to trigger re-review of previously blocked counterparties when a designation is lifted.
Case management integration
POST events into your ticketing or case system with the official source record attached, so reviewers start from the underlying designation.
Scope and limitations
Monitoring is deliberately narrow: push notification of list changes for identifiers you registered. Its boundaries:
Exact-match identifiers only
Wallets, emails, websites and government IDs — not person names. Name-based checks remain on-demand via PEP screening and the search endpoint.
Registered entities only
Events fire for values you monitor. List-wide change feeds are the public delisted endpoint and the data-source pages, not webhooks.
At-least-once, unordered
Duplicate deliveries can occur and ordering is not guaranteed — deduplicate on the event id and order by created_at.
A paid-plan capability
Monitoring is included with the Developer plan (25 entities) and the Team plan (100 entities); the free tier's screening endpoints are unaffected.
Frequently asked questions
How quickly does a webhook fire after OFAC changes its list?
OFAC's change feed is checked every 15 minutes and new publications are ingested immediately; events for monitored entities are delivered within a few minutes of ingestion. Other lists reconcile on daily or weekly schedules matched to how often they publish, and their events ride the same delivery pipeline.
How do I know a webhook event really came from CompliAPI?
Every delivery carries an X-CompliAPI-Signature header: a timestamp plus an HMAC-SHA256 over the raw request body, computed with your endpoint's signing secret. Verify with a constant-time comparison, reject stale timestamps, and never trust an unverified payload — the docs include Python and Node verification snippets.
What happens when my endpoint is down during a list change?
The delivery retries on a backoff schedule of roughly 1 minute, 5 minutes, 30 minutes, 2 hours and 12 hours before being marked failed. After five consecutive failed deliveries the endpoint is disabled automatically and the organization owner is emailed; re-enabling it resumes delivery with new events (missed events are not replayed).
Can I monitor a person's name for sanctions designations?
Not with webhooks — monitoring covers exact-match identifiers: crypto addresses, emails, websites and government IDs. For people, use the on-demand PEP screening endpoint or the free fuzzy search, and monitor the concrete identifiers (wallets, emails, registration numbers) associated with them.
Do monitoring webhooks replace periodic re-screening?
They remove the main reason for it — catching list changes — for the identifiers you register. Some compliance programs still re-screen on a schedule for audit-trail or policy reasons; webhook events and metered screening calls work from the same list data, so the two approaches agree.
Which plans include sanctions monitoring?
The Developer plan includes up to 25 monitored entities per organization and the Team plan 100, each with up to three webhook endpoints. Configuration lives on the dashboard's Webhooks page, where you can also send a signed test event and rotate an endpoint's secret.
Related
Sanctions screening
OFAC API — screen against the official SDN list
Screen crypto wallets, emails, IDs and countries against the official US Treasury OFAC SDN list, refreshed every 15 minutes.
Sanctions screening
Wallet screening API for crypto compliance
Automated crypto wallet and address screening against OFAC and global sanctions lists in one GET request.
Use case
Sanctions screening for crypto exchanges
OFAC wallet screening for exchanges: check deposit and withdrawal addresses against the SDN list, screen users at onboarding, and apply jurisdiction rules per session.
Use case
Sanctions screening for stablecoin payments
OFAC screening for stablecoin payment flows: check sender and recipient wallets against the SDN list and screen counterparty details before funds move.
Get an alert when a list changes
Sign up, register the identifiers you care about, and receive your first signed test event in minutes.
14-day free trial. No credit card required.
CompliAPI provides data and tools that support compliance workflows. It does not provide legal advice, and organizations should determine their obligations with qualified counsel.