Automatically run sanctions screening when a new user signs up

Instead of checking each new account separately, set up automatic sanctions screening on signup so account creation starts a screening request, possible matches reach a reviewer, and access follows your approval policy. Keep signup, screening completion, and account approval separate so an unfinished check never becomes an approval.

Why this matters

A new account proves that someone completed your signup form. It does not prove that screening finished, that the submitted identity is correct, or that a possible sanctions match refers to that person. Your workflow must preserve those distinctions.

Checktiv provides link-based identity verification and background/fraud screening. Checktiv guest verification is best for independent hosts who want a professional shared-link experience without writing code. An application-triggered sanctions workflow is a different implementation task: it requires documented screening capabilities and control over account access.

For a 2026 implementation, start with the decision your application needs to make. Decide which actions remain available during screening, which require approval, and who resolves a possible match. Then connect the signup event to that policy.

The important outcome is not simply sending a request. It is knowing which identity was screened, which result belongs to that identity, and which decision currently governs access. Those connections make the workflow useful to an operator instead of creating another queue to reconcile.

Before you start

• Application access: You need permission to change signup handling, store screening states, and enforce access rules. Keep screening credentials on a trusted server, not in browser code.
• Screening access: Confirm that your selected service documents sanctions screening, required identity fields, result delivery, and supported sources. Checktiv's shared-link guest experience does not establish the behavior of a signup-triggered sanctions integration. Use the ID verification API integration guide for developers for the separate technical context.
• The gotcha: A signup event can arrive more than once, and a screening result can arrive after the account exists. Prepare a stable user identifier, duplicate protection, and a pending state before connecting either event.

Set the screening policy with the person responsible for your business's obligations. Name matching, identity verification, sanctions screening, politically exposed person checks, and adverse-media searches answer different questions. Do not substitute one result for another.

For your 2026 setup, verify the provider's current documentation before mapping fields or enabling account access. The field names below are proposed application fields, not claimed provider settings or dashboard labels.

Signup trigger configuration

The signup trigger should create a durable screening task. It should not approve the account or wait indefinitely for an external response.

1. Choose the event. Start from successful account creation, not a page visit or an incomplete form submission. Define whether signup means account creation or completion of the identity information your screening service requires.
2. Assign the identity. Store a stable user_id with the account. Add a separate identity_version whenever the identity details used for screening change.
3. Create the task. Save a screening task tied to the user and identity version. Use a durable queue or equivalent retryable job mechanism so a temporary service interruption does not discard the request.
4. Prevent duplicates. Build a stable screening_key from the user, identity version, and screening purpose. Reuse that key when retrying the same task; do not generate a fresh screening case for every delivery attempt.
5. Set the initial state. Store screening_status as pending before starting the external request. Apply your pending-access policy immediately.

Expected result: One signup produces 1 active screening task per identity version, even when the signup event is delivered repeatedly. The account exists, but its approval state remains separate.

This separation also helps customer support. A person waiting for a result needs a clear status and next step, not a generic message that their account failed. Explain that a review is in progress without promising a completion time you cannot support.

Identity request configuration

Sanctions matching depends on the information submitted and the service's matching rules. Send the fields required by the documented screening method, and preserve the relationship between those fields and the account.

1. Validate required details. Check that the required identity fields are present before sending the request. Depending on the service and screening scope, these can include a legal name, date of birth, or nationality. Do not assume every field is required or supported.
2. Preserve the original name. Keep the submitted spelling, including accents and non-Latin characters. Apply any normalization only as the screening service documents it; do not replace the source identity with an improvised transliteration.
3. Limit the payload. Send only the information needed for the screening purpose. Keep unrelated booking notes, support conversations, and payment details out of the request.
4. Connect request and account. Save the provider's request or case identifier alongside user_id, identity_version, and the submission timestamp.
5. Record the scope. Retain the screening configuration or policy version used for the request. Store source coverage and result metadata when the service supplies them.

Expected result: Every screening request can be traced to the identity details and policy used when it was submitted. A result cannot silently attach to a different user or an edited identity.

For a 2026 rollout, review the service's documented source coverage with your policy owner. The U.S. Treasury's Office of Foreign Assets Control administers U.S. sanctions programs, but selecting relevant sources remains a business-specific decision. A generic screening label is not a statement of coverage.

Result handling configuration

Treat result delivery as a separate workflow. Receiving a notification and understanding its decision are different operations.

1. Validate the delivery. Follow the service's documented authentication method for incoming results. If results are retrieved rather than pushed, use the documented retrieval process and trusted credentials.
2. Match the case. Find the stored request identifier and verify its user and identity version. Keep an unmatched response out of the approval path until it is reconciled.
3. Translate documented outcomes. Map the service's actual response meanings to your application states. A useful internal model distinguishes pending, no_match, needs_review, and error; these are your states, not assumed provider response values.
4. Protect against stale results. Do not let a result for an older identity version overwrite the current decision. Retain it as history and resolve the current version separately.
5. Store decision evidence. Keep the response details your policy requires, the receipt timestamp, and the identity version. Restrict access to authorized staff and apply a defined retention policy.

Expected result: A completed result updates the correct case once, while duplicate or outdated deliveries leave the current decision intact.

A transport acknowledgment only proves that a message was accepted. It does not prove that sanctions screening returned no match. Similarly, an empty-looking response is not a clearance unless the provider's documentation explicitly defines it that way.

Never translate a timeout, parsing failure, or missing result into `no_match`. Keep those cases visible and retryable.

Approval gate configuration

Your application should enforce the decision, not merely display a screening badge. Use a separate approval field so a reviewer can distinguish screening output from the business's access decision.

1. Define pending access. List the actions available while screening is incomplete. Enforce restrictions on the server wherever those actions are performed, not only by hiding interface controls.
2. Define the no-match path. Apply your approval policy when the documented result reports no match. Keep any other required onboarding checks separate.
3. Route possible matches. Send needs_review cases to an authorized reviewer with the identity details and matching evidence necessary to evaluate them.
4. Record the decision. Store who reviewed the case, when the review occurred, the outcome, and the supporting rationale. Follow your policy for confirmed matches and unresolved cases.
5. Test the boundaries. Run 3 test cases before release: a documented no-match response, a possible match requiring review, and a technical failure that must remain unresolved.

Expected result: Restricted actions depend on the current approval decision. A technical failure cannot approve an account, and a possible name match cannot reject someone without the required review.

The sequence is straightforward: create the account, submit screening, review the result, then apply the approval decision. Each stage has a separate responsibility.

*Account creation and approval are separate decisions.*

Repeat screening when identity details change

A signup check applies to the identity submitted at that time. If relevant identity details change, create a new screening task rather than treating the old result as current.

Use 2 event types in your application: account creation and relevant identity updates. Changes to a newsletter preference or display theme should not create sanctions screening work. Changes to fields used for matching should follow your documented policy.

When an identity update occurs, increment identity_version, create a new screening key, and apply the access policy for an unresolved update. Preserve the previous decision as history.

For your 2026 workflow, specify whether users retain existing access during an update review. Do not leave that behavior to whichever result happens to arrive first. Ongoing monitoring is another workflow, not an implied feature of a signup trigger.

Troubleshooting

Duplicate requests for the same signup

Repeated event delivery or a retry without a stable key can create duplicate cases. Reuse the screening key for the same identity version and check the stored task before submitting again. Keep retries separate from genuinely new screening requests.

Accounts remain pending after a result arrives

Check whether the result identifier matches the stored case and whether the identity version is current. Inspect delivery authentication, parsing, and state transitions. Reconcile the case through the documented result retrieval method instead of approving it to clear the queue.

Possible matches keep reaching approval

Inspect the response mapping and access rule independently. A match indicator must not be treated as a successful no-match result simply because the request completed successfully. Add a test that confirms a review case cannot perform a restricted action.

Older results overwrite updated identities

Compare the response's stored case identity version with the user's current version before updating approval. Retain older results in history. Only the case associated with the current identity should control the current screening decision.

Provider failures create a growing queue

Retry according to the service's documented limits and retry guidance. Keep failed tasks visible to an operator, distinguish retryable failures from requests requiring corrected information, and assign responsibility for unresolved cases. Do not make indefinite retries your only recovery plan.

Customize your workflow

Start with the smallest decision path you can explain: signup, screening, review, approval. Add complexity only when it changes a real operational decision.

Separate screening completion from identity verification completion. Checktiv's link-based guest verification offers an identity workflow; that does not make every completed verification a sanctions clearance. Keep each outcome named accurately in your application and customer communications.

For a 2026 operating plan, assign ownership for pending cases, possible matches, and technical failures. Give support staff a useful status without exposing sensitive matching information to everyone who can view an account.

Measure the workflow by whether every case reaches a documented decision, not whether every request returns quickly. Record timestamps for submission, result receipt, and review completion so your team can locate delays without inventing service guarantees.

One last thing

The failure to test first is often not a difficult name match. It is a second delivery of the same ordinary event.

Before launch, resend a signup event and then deliver an older screening result after an identity update. Confirm that neither creates a fresh approval nor replaces the current decision. These checks expose whether your workflow connects decisions to identities or simply accepts whichever message arrives last.

Make the current identity version the anchor for every approval. That single design choice keeps signup screening, retries, reviews, and later updates working toward the same decision.

Related guides

• Best sanctions screening software
• Ongoing AML monitoring for crypto exchanges
• Best AML screening software for fintech