Troubleshooting and FAQs

Payment Screening is a pre-configured use-case workflow in RiskOS that screens every entity and identifier in a payment transaction against global sanctions lists, PEP data, and Adverse Media in real time.
It evaluates source and destination parties — individuals, businesses, bank accounts, and crypto addresses — and returns an ACCEPT, REVIEW, or REJECT decision with detailed match data.

Payment Screening evaluates individual transactions at the point of execution to catch sanctioned parties or high-risk entities before a payment is processed.
Transaction Monitoring analyzes patterns of behavior over time — velocity, anomalies, structuring — to detect suspicious activity across a portfolio.
Payment Screening doesn't replace Transaction Monitoring. They serve complementary purposes.

Payment Screening is available globally and supports a wide range of industries, including:

• Payment Service Providers
• Banking
• Fintech and Crypto
• Marketplaces and Gig platforms
• E-Commerce
• Insurance
• Government

Common use cases include cross-border payments, domestic wire screening, account funding validation, and crypto on-ramp/off-ramp screening.

Payment Screening uses the standard RiskOS evaluation endpoint:

• Sandbox: https://riskos.sandbox.socure.com/api/evaluation
• Production: https://riskos.socure.com/api/evaluation

Set the workflow field to the value assigned to your Payment Screening workflow in the RiskOS Dashboard.

Include a Bearer token in the Authorization header. Obtain your API key from RiskOS Dashboard > Developer Workbench > API Keys.
You can optionally include an X-API-Version header to pin a specific API version (for example, 2025-01-01.orion).

Every request requires four top-level fields:

• id — a unique identifier for the evaluation (must not be reused)
• timestamp — a valid RFC 3339 timestamp
• workflow — your environment-specific workflow identifier
• data — the transaction data, including at least a source or destination entity with a plausible full name

Payment Screening supports two entity types:

• INDIVIDUAL — requires individual sub-object with name fields (given name and surname)
• BUSINESS — requires business sub-object with entity name

Both source and destination entities can be either type, independently.

Two instrument types are supported:

• BANK_ACCOUNT — requires an account sub-object with fields like IBAN, BIC/SWIFT, and account number
• CRYPTO_ADDRESS — requires a crypto_address sub-object with the wallet address, currency, and network

Supported crypto currencies include BTC, ETH, USDT, XMR, ZEC, XRP, LTC, SOL, and others. Supported networks include bitcoin, ethereum, tron, solana, polygon, and others.

Yes. A single API call screens all entities and instruments provided in the request — source individual or business, destination individual or business, and their associated bank accounts or crypto addresses. RiskOS returns enrichment results for each screened component.

Payment Screening returns one of three decisions:

• ACCEPT — no material matches found; allow the payment to proceed
• REVIEW — potential matches found; hold the payment and route to manual review
• REJECT — high-confidence matches found; block the payment

The response includes:

• Decision and routing — the final decision, tags, and review queue assignment
• Enrichment results — match details for each screened entity and instrument, including list name, match score, entity correlation score, matched fields, and source URLs
• Case history — events such as case creation and status changes
• Lifecycle metadata — eval_status, timestamps, and execution context

These scores indicate the strength of a watchlist match:

• matchScore — measures how closely a specific field (for example, name) matches a list entry
• entityCorrelationScore — measures overall confidence that the screened entity corresponds to a specific list entry, combining multiple matching signals

Higher scores indicate stronger matches. Your workflow conditions and thresholds determine how these scores influence the final decision.

eval_status tracks the lifecycle state of an evaluation:

• evaluation_completed — processing is finished
• evaluation_paused — evaluation is paused (for example, awaiting input)
• evaluation_in_progress — evaluation is still running

Use eval_status for monitoring only. Base business decisions on the decision field.

Payment Screening provides real-time sanctions screening with response times under 200 ms.

Yes. The Payment Screening workflow in RiskOS is fully configurable. You can:

• Enable or disable specific enrichments
• Configure allow/deny lists for email addresses, phone numbers, IP addresses, and devices
• Set conditions for tagging, monitoring, and routing
• Adjust match score and entity correlation thresholds

A Payment Screening workflow consists of four components:

• Input — collects transaction data from the API request
• Enrichment — screens entities and instruments against watchlists
• Condition — applies tags and monitoring logic based on results
• Decision — emits the final ACCEPT, REVIEW, or REJECT outcome

Yes. Use the Sandbox endpoint (https://riskos.sandbox.socure.com/api/evaluation) with your Sandbox API key. Sandbox responses are mocked and may not reflect the full range of Production list coverage.