How to Write a Sanctions Screening RFP That Works

A sanctions screening procurement that drags on for six months, involves three rounds of vendor re-engagement, and concludes with a contract that the compliance team has to work around is not a procurement failure in isolation. It is a signal that the requirements were not specified precisely enough at the start to make vendor comparison meaningful. Most sanctions screening RFP processes share the same structural problem: the requirements gathering phase produces a list of capabilities that every vendor can claim to satisfy, the demos confirm what the vendor wanted to demonstrate rather than what the buyer needed to test, and the evaluation framework does not weight the factors that actually matter for the buyer's specific risk profile and operating model.

This article sets out a structured RFP approach that avoids these problems, from requirements gathering through to the questions that separate vendors in a live demo.

Phase 1: Requirements Gathering Before the RFP Goes Out

The most important work in a sanctions screening procurement happens before the RFP is written. Requirements gathering should answer the following questions with specificity:

• What lists must the system cover? This is not the same as asking "does the system cover OFAC and the EU?" Every vendor covers those. The question is whether the system covers the specific lists relevant to the buyer's jurisdictional exposure, including domestic lists in operating markets, criminal watchlists such as Interpol red notices and FBI most wanted, and regional PEP databases with adequate coverage depth for the buyer's customer base.
• What transaction volumes and entity types need to be screened? A system that performs well at 10,000 screens per day may not be suitable for 10 million. The RFP should specify peak screening volumes, the mix of individual and entity screenings, whether real-time API performance is required at the point of transaction or whether batch screening is acceptable for some use cases, and what acceptable response time looks like.
• What is the buyer's false positive tolerance? This question forces the compliance team to articulate what they are willing to accept in terms of manual review volume. A buyer that cannot handle more than 200 manual review alerts per day needs a vendor whose matching accuracy can deliver that volume at the buyer's transaction scale. Specifying this in the RFP allows vendors to be evaluated against a quantified standard.
• What are the integration requirements? The RFP should specify the buyer's existing technology stack, the systems that need to be connected to the screening tool, and whether the buyer requires an API integration, a no-code integration, or a platform with a native user interface for manual review. Integration failure is one of the leading causes of post-deployment compliance program underperformance.
• What are the regulatory obligations the system must satisfy? This should be explicit: which regulators supervise the buyer, what audit trail requirements those regulators impose, and whether the buyer has experienced a regulatory examination that identified specific screening gaps the new system must address.

Phase 2: The RFP Structure

List Coverage

Ask vendors to provide the specific list sources they cover, the update frequency for each list, and the mechanism by which updates are delivered to the screening system. "Covers OFAC" is insufficient. The RFP should ask: how frequently is the OFAC SDN list updated in the vendor's system after a OFAC publication? What is the SLA for list updates? How does the system handle the OFAC 50 percent rule for entities that are not themselves designated but are majority-owned by SDN-listed parties?

For PEP coverage, ask for the number of PEP profiles in the database, the geographic distribution, the frequency at which PEP status changes are captured, and how the vendor handles PEP status changes for individuals who are no longer in covered positions.

Matching Technology

The matching technology section of the RFP should require vendors to describe their matching approach in technical detail, not marketing language. Specific questions:

• What matching algorithms are used? Exact match, fuzzy match, phonetic matching, and which specific implementations?
• How are non-Latin script names handled, including transliteration variants from Arabic, Russian, Chinese, and Korean?
• What is the configurable match threshold? Can the buyer adjust sensitivity, and what is the documented impact on false positive and false negative rates at different threshold settings?
• Can the vendor provide documented false positive and false negative rates from production environments comparable to the buyer's use case?

Integration Model

The integration section should specify the API architecture, documentation quality, and sandbox environment. Ask for:

• API documentation quality and completeness
• Availability of a sandbox environment with realistic test data
• Native integrations with the buyer's CRM, onboarding platform, or case management system
• Webhook support for list update notifications that trigger re-screening
• Average API response time at specified volumes under load

Security and Data Residency

For regulated buyers, data residency is often a hard requirement. The RFP should ask specifically: in which jurisdictions are customer data and screening results stored? Can the vendor provide SOC 2 Type II certification? How are data breaches handled and notified?

SLAs and Support

The SLA section should ask for:

• Uptime guarantee with specific percentage, for example 99.9% or 99.99%
• Response time SLA for API calls at specified volumes
• Support availability, especially for compliance incidents that occur outside business hours
• Escalation process for urgent regulatory queries

Pricing

 In the RFP, require vendors to disclose all cost components: per-screen fees, platform or subscription fees, setup fees, sandbox access costs, premium support tier costs, fees for adding additional lists, and pricing for additional PEP or adverse media modules. Require vendors to provide a total cost of ownership model for the buyer's specified annual screening volume, not a per-call rate that requires the buyer to do the arithmetic.

{{snippets-guide}}

Phase 3: Scoring Rubric by Buyer Profile

FinTech (High Volume, API-First)

API performance at stated volumes carries the most weight at 25%, reflecting the non-negotiable need for reliability under load. False positive rate at the buyer's threshold and both integration speed and documentation quality each account for 20% — because poor accuracy or a painful integration erodes value regardless of how fast the API runs. List coverage and update frequency round out the core criteria at 20%, while pricing at scale is a secondary consideration at 15%.

iGaming Operator (Unpredictable Traffic, Multi-Jurisdiction)

List coverage — including domestic and regional lists — is the top priority at 25%, given the complexity of operating across multiple jurisdictions. The ability to handle traffic spikes without performance degradation and PEP database depth for relevant markets each account for 20%, as both operational resilience and market-specific intelligence are essential. Audit trail completeness for regulatory reporting carries equal weight at 20%, reflecting the scrutiny operators face. Pricing model flexibility is weighted at 15%, acknowledging that iGaming volumes can be hard to forecast.

InsurTech (Lower Volume, Deep Due Diligence)

Data depth and adverse media coverage take the largest share at 30%, consistent with InsurTech's emphasis on thorough background checks over speed. PEP and SOE relationship mapping and audit trail and evidence generation each account for 25%, underscoring the importance of both investigative quality and defensible documentation. Integration with the onboarding workflow rounds out the rubric at 20%, ensuring due diligence outputs feed cleanly into downstream processes.

Each profile's weights add to 100% and are sequenced from highest to lowest to make relative priorities immediately clear.

Phase 4: Questions That Separate Vendors in Demos

Generic demos confirm what the vendor wanted to show. These questions force vendors to demonstrate the capability the buyer actually needs:

• "Show me how the system handles a customer name that is a common Arabic name with three plausible transliterations. What does the alert look like and what does the analyst see?"
• "Show me the audit trail for a screening event from six months ago. What can I retrieve, in what format, and how long does it take?"
• "Simulate a new OFAC designation being published. How long until my existing customer base is re-screened against the new entry? Show me the process."
• "Show me the false positive rate from a production client with a similar profile to our business. How is that measured?"
• "What happens if your API is unavailable during a transaction I am trying to screen? What is the fallback and how does it affect my regulatory position?"
• "Walk me through how your system handles the OFAC 50 percent rule for a customer entity that is 40 percent owned by an SDN-designated party."

The vendors that answer these questions with working product demonstrations rather than feature slides are the ones worth evaluating seriously.

{{snippets-case}}

Conclusion

A well-structured screening procurement produces a contract with a vendor whose capabilities are matched to the buyer's specific risk profile, volume, and regulatory obligations, not the vendor with the best website or the cheapest per-call rate. The time invested in specific requirements gathering, structured RFP design, and demo preparation is returned in reduced false positive volume, lower compliance team workload, and a system that can demonstrate compliance to a regulator rather than simply claiming it.

sanctions.io is a highly reliable and cost-effective solution for real-time screening. AI-powered and with an enterprise-grade API with 99.99% uptime are reasons why customers globally trust us with their compliance efforts and sanctions screening needs. To learn more about how our sanctions, PEP, and criminal watchlist screening service can support your organisation's compliance program: Book a free Discovery Call. We also encourage you to take advantage of our free 7-day trial to get started with your sanctions and AML screening (no credit card is required).

‍