Compare sanctions screening workflows
Decide what your team needs to operate: a manual list-checking process, monitoring through Reliance Risk Registry, or another provider’s service.
This guide compares the work involved in a manual process with documented Reliance Risk Registry functionality. Use the evaluation questions to request evidence from any vendor you shortlist.
Platform behavior reviewed .
Compare the workflow, not just the first name search
A manual process can use official publications, but your team must arrange repeat checks, review records, and operational follow-up. The table describes those responsibilities; it is not a performance or price benchmark.
Scroll horizontally to read all four columns on smaller screens.
| Decision area | Manual workflow | Reliance Risk Registry | Ask any provider |
|---|---|---|---|
| Source coverage | Choose official lists and maintain a record of which ones were checked. | Supported EU, UK, OFAC SDN/non-SDN, Canada, and UN imports; Ukraine NSDC individuals through XLSX upload. Enabled, successfully imported sources determine actual coverage. | Which exact lists, formats, and jurisdictions are included? Which need a separate process? |
| Data freshness | Arrange downloads or lookups and record the publication/update context for every check. | Configurable daily import job, defaulting to 00:00 UTC, with per-source outcomes. Upload-based data needs its own update process. | What is the actual update schedule? How are failed or delayed refreshes exposed? |
| Name matching | Define a consistent way to consider aliases, reordered names, spelling differences, and identity context. | Normalized name/alias and name-part matching, plus bounded approximate spelling comparisons. No automatic cross-script transliteration; similarity scores require review. | Can you test representative cases? What do scores mean, and where does matching stop? |
| Ongoing monitoring | Maintain the population to check and schedule repeat work after data changes. | Subscriptions, queued initial API screening, and checks after completed import attempts. Administrators can trigger screening separately. | What triggers a recheck? Can you inspect pending, failed, and completed outcomes? |
| Backend integration | Build the process that connects your records, check outcomes, and follow-up systems. | Versioned subscription API, organization keys, idempotent creation, external references, and signed webhooks. | Can you inspect the API contract and test retries, ownership boundaries, and signature verification? |
| Delivery operations | Arrange notification handling, failure detection, and retry records. | Webhook attempt history, response details, delivery status, and eligible retries. Delivery status is separate from screening status. | How do you detect an exhausted delivery? What happens if the same event arrives twice? |
| Review and evidence | Record the identity review, decision, source context, and retention policy in your own process. | Candidate/source details, screening timestamps, job history, and webhook request monitoring support investigation. A complete review/retention process remains your responsibility. | Which evidence and reviewer actions are recorded? What retention and export requirements are met? |
Which approach fits your team?
Consider a manual process when
You can assign reliable ownership for the required lists, repeat checks, decisions, and evidence. Assess the effort against your volume and update needs rather than assuming the first lookup is the whole task.
Evaluate Reliance Risk Registry when
You need its supported sanctions data in a shared workspace, ongoing name subscriptions, and backend notifications, and its current coverage and matching limits fit your review process.
If you need additional jurisdictions, PEP/adverse-media data, a particular certification, service commitment, or a full case-management workflow, obtain explicit evidence for those requirements. They are not established by the features described here.
Run a fair evaluation before choosing
- Write down non-negotiable requirements. Include required lists, update expectations, integration behavior, access controls, and review evidence.
- Use the same test cases. Include aliases, reordered names, short names, spelling changes, different scripts, and names that should not match.
- Test operational failures. Inspect source refresh failures, pending checks, webhook downtime, duplicate events, and recovery.
- Request a complete cost basis. Ask each provider what its quote includes: data scope, monitoring, API volume, delivery, support, and any usage or contract limits. This guide publishes no unverified prices or savings estimates.
- Record the decision. Retain the source material and date behind each capability claim, along with gaps your team must cover.
Evidence and comparison scope
The platform column is based on the implemented workflows described in our source and freshness reference, monitoring and matching guide, and developer documentation, including the public OpenAPI contract. These first-party references describe current behavior; they are not independent performance testing.
No named competitor’s features, pricing, or service levels are asserted here. Compare any provider’s current primary documentation and written terms against the questions above before making a purchase decision.