How to connect fintech onboarding to sanctions screening

Define the account-to-review handoff

Use SanctionsKit to connect a fintech customer record with a check of selected sources and the people who review it. Identify which customers, merchants and related parties your policy covers. A merchant company and the person acting for it remain separate subjects even when they share an account.

Agree sources and review duties with any regulated partner. Record them in Screening policies, including outside checks and approvals. Identity verification, ownership research and transaction-pattern monitoring remain separate work.

Send the screening from your backend

Create a scoped Sandbox key in API keys. Follow the fintech request example to call POST /api/v1/screenings with a subject, stable reference, standard retention and one coverage selector. Keep the key on the server.

Store the request and its idempotency key before sending it. Save data.id against the account-and-party reference. Production needs the approved policy version and available sources. The synthetic sandbox@1 package does not belong in a real customer check.

Give analysts the retained result

API results appear in Screening history in the same organization and environment. Candidates enter the Review queue. Outside checks required by policy can also create a no-match case. Send the reviewer the result ID and account context.

The analyst records candidate findings, required external work and a separate business decision. For a fictional merchant, the company may have no match while the person acting for it still needs review. The account workflow must account for both required parties.

Keep failures separate from approval

Accept potential_match or no_match only from a valid successful response. Timeouts, source failures and malformed responses are incomplete. Recover an uncertain request with the same key and body. If the customer's details change, make a new request with a new key.

Your account process decides when all required work is done. A name no-match does not verify documents or approve a financial product. Use error codes and request IDs in error logs, keeping subject inputs and credentials out.

Assign the work that follows onboarding

Open Monitoring. Choose a saved profile or enter the approved subject, apply the policy and create the monitor. Confirm that its first check completes. Give a team ownership of the inbox and new cases so a later alert has somewhere to go.

The policy sets how often checks run. Scheduled checks and qualified source-triggered checks add to the workload. Inspect Usage & limits and failed monitors as you add customers. Test the full onboarding path in Sandbox before using it with an approved group in Production.

Frequently asked questions