Sanctions screening for payment workflows.
Screen beneficiaries before payment execution with structured decision context. Batch support is plan-gated; monitoring notifications depend on your plan and configuration.
Decision contract
A zero-match result is not enough on its own.
The API returns the conditions a caller must check before treating a screening result as clear. A retrieved candidate is not a confirmed identity, and an unavailable, partial, or capped result is not complete coverage.
- screening_mode
- An `exact_only` result may never be read as a clearance. The mode deliberately skips fuzzy, phonetic, transliteration and typo recovery, so “no exact candidate” is not evidence the party is unlisted.
- clearance_eligible
- When false, no combination of other fields makes the result clean. Treat it as unresolved regardless of `risk_level`.
- coverage_status
- Partial or unavailable coverage cannot clear. Absence of a hit in the sources that answered says nothing about the ones that did not.
- candidate_set_complete
- A truncated set cannot clear. No-hit inside a capped set is not no-hit — it is no-hit in the part that was examined.
From payment initiation to compliance decision.
Payment initiated
Customer submits a payment with beneficiary details
Screening response
POST /v1/screen with beneficiary name, country, and type
Decision context
Read the served verdict, review requirement, source coverage, and candidate completeness together
Payment routed
Apply your own policy only after the result meets its clearance contract or the required review occurs
Evidence state
Use a capsule only when the response reports durable evidence as available
What the API delivers.
Payment-flow screening
Screen a beneficiary before your system moves value. Measure latency against your own integration and operating requirements.
Batch screening
Submit up to 100 entities in one request, subject to plan and feature availability. Apply the clearance contract to each result before an automated route.
Monitoring notifications
Add entities to continuous monitoring and configure available notifications for changed screening results. Notification delivery depends on your plan and configuration.
Structured decision context
Results carry decision, source scope, coverage, candidate completeness, and review fields. A candidate is not a confirmed identity.
Single and batch workflows
Use individual screens for a payment party or the batch endpoint for up to 100 entities. Validate capacity in your own production-like environment.
Evidence status
The response states whether an evidence record is available, pending, or unavailable. Pending or unavailable is not a durable evidence claim.
One call per beneficiary.
Integrate at the payment initiation point. The response explains its decision, review requirement, and the limits of any zero-match result.
curl -X POST https://api.verifex.dev/v1/screen \
-H "Authorization: Bearer vfx_your_api_key" \
-H "Content-Type: application/json" \
-d '{
"name": "Beneficiary Name",
"type": "person",
"country": "US",
"mode": "broad"
}'Explore the full platform
Transaction Screening
Screening for payment parties before your system routes value.
AML Screening
Screening infrastructure for fintech and payment workflows.
Continuous Monitoring
Monitor entities and configure available notifications.
API Documentation
Developer docs, quickstart, and OpenAPI reference.
Start screening payments today.
Start with the current plan allowance, then validate the screening and evidence contract in your payment flow.