Sanctions monitoring vs transaction monitoring: three different jobs

Choose the operation for the question you have

Sanctions monitoring checks saved subjects again. Transaction-party screening checks a payer or payee at a chosen point. Transaction monitoring studies activity. SanctionsKit supports the first two selected-source identity tasks; it does not study a payment ledger or behavior patterns.

For a continuing customer, create a monitor in the dashboard or with POST /api/v1/monitors. For a new payer or payee, submit that party with POST /api/v1/screenings. A customer monitor does not automatically check every person they later pay.

Send identity facts to the screening endpoint

A screening request accepts subject facts such as name, type, country, partial birth date and typed IDs, plus one coverage selector. Use reference to link it to your operation. Do not send amounts, a payment ledger or unsupported fields as if the endpoint assesses them.

Choose the required available sources and policy before Production. Keep keys on the server and customer facts out of logs. The screening API guide covers request fields, synchronous results, authentication and safe retries.

Give the sanctions result its own next step

potential_match needs review of who the party is. no_match is limited to that subject and selected coverage. An error or unavailable source leaves the sanctions step incomplete. Your payment system should keep a clear pending state and use the authorized business decision when ready.

Read the current case when review is needed. A submitted decision waiting for approval is still pending. API keys can read case state, but cannot decide a human identity finding or approve the analyst's work.

Handle changes without closing unrelated investigations

Read the Monitoring inbox, or verify a signed webhook and retrieve its event. Inspect current and previous checks, changed evidence and the linked case. Send the sanctions task to a reviewer with the right role and enough facts to act.

Acknowledgement changes inbox state only. Keep an activity case with its own evidence, owner and decision. Dismissing a name candidate does not explain an unusual payment pattern. A normal payment pattern cannot prove that a listed candidate is a different identity.

Example: one payment process, three records

Imagine a fictional payments business with three tasks. It checks a saved customer again, screens a new payee, and reviews a pattern of unusual payments. The first task asks whether new list evidence concerns the known customer. The second asks about a different party. The third asks what the payment behavior means.

The tasks can share a business reference but reach different conclusions. A customer checked this morning can still name a new payee this afternoon. That payee may need a search. A set of payments can still need investigation even when no selected party produced a list candidate.

Test situations where the outcomes disagree

Try synthetic cases with no sanctions candidate and an open activity alert, a sanctions candidate with ordinary activity, a changed payee and unavailable sanctions coverage. Each should reach the right owner without deciding the outcome of another check.

Use customer screening for saved relationship history and the webhook guide for delivery. Keep references to both the identity and activity work visible in the broader case so the next reviewer can find them.

Frequently asked questions