Set up Payment Screening
Before you start
Make sure you have the following:
Access to the RiskOS™ Dashboard with the Payment Screening solution enabled.
- Your account owner or administrator can enable this for you. If you're unsure who to contact, reach out to support for assistance.
A basic understanding of RiskOS™ workflows and components.
- If this is your first time working with workflows, review the Workflow overview to understand inputs, enrichments, routing logic, and decisions.
How it works
Payment Screening evaluates payment transactions in real time by screening all participants (sender, beneficiary, and intermediaries) and transaction attributes against global watchlists (Sanctions, PEP, AML).
At a high level, the workflow:
- Screens names against sanctions and PEP watchlists
- Evaluates bank identifiers (IBAN, BIC/SWIFT, routing numbers)
- Screens crypto wallet addresses
- Checks countries and jurisdictions for sanctions exposure
- Aggregates results across all entities in the transaction
- Applies decisioning logic based on matches and policy
Depending on your configuration, final outcomes include:
- Accept
- Manual Review
- Reject
How Payment Screening fits into a workflow
In RiskOS™, you build workflows by connecting reusable components. Payment Screening is a preconfigured use-case workflow composed of enrichments, conditions, and decisions.
Once triggered, the workflow screens all relevant entities and transaction attributes in a single API call and returns a unified decision outcome.
For more detail on workflow components, see Workflow Steps.
Execution flow in RiskOS™
Payment Screening runs synchronously, returning watchlist matches and match scores in real time.
API call to RiskOS™
RiskOS™ receives the input data and triggers the Payment Screening workflow to screen the input identifiers against your selected watchlists.
Payment screening
For each entity in your workflow, the Payment Screening step screens the input identifiers against your selected watchlists, scores the matches, and returns likely matches that meet your filters, Name Match or Entity Correlation Score threshold criteria.
Monitoring logic
The workflow implements your logic to enable monitoring for screened entities based on the screening results.
Final decision
RiskOS™ applies decisioning logic (Accept, Manual Review, or Reject) to complete the Payment Screening workflow.
Workflow components used by Payment Screening
| Component | Purpose |
|---|---|
| Input | Collect transaction, source, destination, intermediary, and account information |
| Enrichment | Screen each individual, business, account, and crypto address identifier against watchlists |
| Condition | Apply tags and monitoring logic |
| Decision | Emit final screening outcome |
Configure Payment Screening
Enable required enrichments
Your Socure account team provisions a standard Payment Screening workflow with the following entitlements:
- Payment Screening
Configure Allow / Deny lists
Configure allowlists and denylists for:
- Email addresses
- Phone numbers
- IP addresses
- Devices
The workflow evaluates these lists early in the process.
Configure inputs and routing
Typical configuration steps include:
- Risk-policy conditions [Coming in June 2026]
- Determine which jurisdiction, product, or transaction amount to apply which Watchlist policy
- Review conditions
- Review when there is an OFAC or other Sanctions hit
- Accept and Monitoring conditions
- Accept and monitor when there is no OFAC or other Sanctions hit
If you’re unsure how to tune thresholds or routing, reach out to support with context about your use case.
Save and publish
Once your workflow is configured, publish it to go live.
Most customers start with a Socure-provided best-practice workflow and iterate over time.
Quick start checklist
Use this checklist to validate readiness before production launch.
Workflow setup checklist
Watchlist screening
Sanctions, PEP, and AML watchlists are enabled for screening
Name matching thresholds are configured for expected sensitivity
Entity correlation or match scoring thresholds are defined
Entities and attributes
Sender and beneficiary entities are included in screening
Bank identifiers (IBAN, BIC/SWIFT, routing number) are configured for screening
Countries and jurisdictions are evaluated for sanctions exposure
Crypto wallet addresses are included if applicable to your use case
Decisioning
Conditions route sanctions matches to Reject or Manual Review
Non-matching transactions are routed to Accept
Monitoring logic is applied to entities that require ongoing review
Updated 3 days ago