RFP Evaluation for Sanctions and Compliance Tools: Operational Fitness vs. Technical Specifications

Procurement processes for sanctions and compliance technology often fail not because vendors submit poor proposals, but because institutions ask the wrong questions. The RFP becomes a specification exercise focused on feature lists and technical architecture, when the real decision is whether the vendor can support your institution's investigation methodology and governance model. A vendor with a technically inferior product but a clear understanding of your investigation workflow will deliver more value than a technically superior platform deployed into an institution that cannot use it effectively. The procurement process should measure fit for purpose, not just technical capability. Most institutions do not.

The stakes are high. A poorly designed RFP creates misalignment between the vendor's assumptions about how you will use the tool and your institution's actual operational needs. This misalignment becomes visible six to twelve months post-implementation when the tool works but your workflows do not. By then, the procurement decision is locked in, the vendor has been onboarded into your infrastructure, and the cost and operational disruption of switching are prohibitive. The only escape is expensive customisation or acceptance of a tool that does not fit.

TrustSphere's position is that the RFP should invert the traditional sequence. Instead of beginning with technical specifications and vendor capabilities, it should begin with a detailed description of your current state: what your investigation workflow looks like today, what your alert threshold assumptions are, what your governance documentation looks like. The RFP should then ask the vendor how they would support that workflow, improve it, or recommend changes to it. Vendors that can engage with your operational reality in detail, and explain their recommendations in terms of your risk appetite, are more likely to deliver successful outcomes than vendors that simply describe their technical architecture.

Where Sanctions Procurement Usually Goes Wrong

The first common failure is functional overcompliance. Institutions often specify features they do not need, driven either by cargo-cult thinking (every vendor has fuzzy matching; therefore we must specify it) or by fear of missing a hypothetical future requirement. The RFP becomes a 60-page document specifying 200 features, of which perhaps 40 will actually be used. The consequence is that vendors bid on a fully featured solution that will be expensive to implement and maintain, even though 80 per cent of the features will never be touched.

The second failure is absence of operational specification. Institutions specify technical requirements (API latency, data ingestion frequency, database architecture) without specifying operational requirements (how long should an alert investigation take? what documentation is required to close an alert? what escalation path should a suspicious finding follow?). A vendor can meet every technical requirement whilst delivering a product that does not fit your investigation process. The RFP should require vendors to propose an end-to-end workflow: how will an alert flow from detection through investigation to closure? What systems will it touch? Where will your investigators interact with it?

The third failure is insufficient detail on data governance and supplementary data. Institutions often assume that a vendor's sanctions data is complete and current. In reality, most vendors source official OFSI and OFAC lists through aggregators (like Refinitiv), and many do not include supplementary lists (historical delisted entities, regional sanctions, industry intelligence). The RFP should explicitly require the vendor to list every data source they use, the update latency for each, and the deduplication rules they apply across sources. Institutions should then verify that those data sources cover their transaction profile.

The fourth failure is underspecifying the false positive problem. Most RFPs do not mention false positives at all. They specify sensitivity (percentage of true positives caught) but not specificity (percentage of alerts that are actionable). A vendor can offer 99 per cent detection without revealing that 99 per cent of their alerts are false positives. The RFP should define what constitutes an alert for your institution, what constitutes a false positive, and ask the vendor how their platform will help you measure and manage the false positive rate.

How to Run the Stage Properly

The first step is a detailed current state assessment. Before writing an RFP, the procurement team should conduct interviews with your investigators, compliance officers, and risk managers to document: what does an alert investigation look like today? How long does it take? What documentation do you create? What escalation rules do you apply? What data sources do you consult? This assessment should yield a workflow diagram and a list of decisions the investigator makes at each stage.

The second step is a written hypothesis about what the new tool should change. Should it reduce investigation time? Improve documentation? Increase detection? Reduce false positives? You cannot pursue all simultaneously. The RFP should be explicit about priorities: if the goal is to reduce false positives, the RFP should ask vendors how they will help you tune alert thresholds and measure baseline performance. If the goal is to improve detection, the RFP should ask about fuzzy matching capability and supplementary data sources.

The third step is a structured RFP response format that forces vendors to address your operational questions. Instead of open-ended "describe your solution" sections, the RFP should ask vendors to respond to specific scenarios. For example: "You will receive 500 daily sanctions alerts from transaction monitoring. How will your platform help us determine which alerts are worth investigating? Describe your approach to alert prioritisation and give us an example of how an investigator would use your tool to decide whether to escalate an alert." This forces vendors to explain their methodology in concrete terms rather than marketing language.

The fourth step is a vendor presentation focused on operational workflow, not technical features. The RFP evaluation should include a working demo where the vendor walks through a realistic investigation scenario using their tool. This demo should be conducted by someone who understands your institution's investigation process, and the evaluation should focus on: does the tool support the way your investigators work? Does it require them to work differently? If yes, is the change an improvement? Too many institutions accept a demo focused on the vendor's preferred workflow without asking whether that workflow matches their operational reality.

The fifth step is a reference check process focused on implementation and operations, not just vendor reputation. Contact three references from institutions in your peer group and ask: did the implementation go to plan? What were the surprises? Are you using the tool in the way you planned, or did you have to change your processes? What is the false positive rate, and how do you manage it? How much vendor support do you need?

How to Evaluate What Comes Back

The RFP responses should be evaluated against two dimensions: technical capability (does the tool do what we specified?) and operational fit (will our investigators use it in the way we envision?). Most procurement teams weight technical capability heavily and operational fit as secondary. This is backwards. A technically excellent tool that does not fit your workflow will be rejected by your users or will force you to change your workflow to fit the tool.

The evaluation should include a scoring matrix that explicitly weights operational factors at 40 to 50 per cent of total score: does the vendor understand our investigation workflow? Do they propose realistic changes to it? Have they deployed in similar-sized institutions? Do their references report successful adoption? These factors should carry significant weight.

Your second line and technology risk team should assess whether the vendor's proposal will support defensible governance and audit. The tool is only as good as the documentation and decision records it creates. If the vendor's platform does not enforce or support documentation standards you will require (for example, noting the reason an alert was closed, and by whom, with a timestamp), it will not satisfy your second line's requirements.

Cost analysis should include implementation (configuration time, professional services), training (team ramp-up), operational support (vendor engagement required), and opportunity cost (time until improvement). A more expensive vendor with faster implementation may deliver lower total cost of ownership.

What This Means for Each Stakeholder

Compliance and investigators: You will be primary users. Engage early and describe your current workflow in detail. During vendor evaluation, insist on a demo that walks through your actual workflow. Your feedback should carry significant weight; if the winning vendor's tool does not support how you work, implementation will be painful.

Technology and operations teams: Assess implementation risk and feasibility. Understand vendor integration requirements and implementation timelines. Get three strong references and speak with their technical teams about implementation challenges, support requirements, and dependencies. Your input on feasibility should be a major selection factor.

Risk and second line: Assess whether the vendor's tool supports defensible governance and audit. Understand what documentation the tool creates and whether it enforces investigation process standards. If the tool allows investigators to close alerts without recorded reasoning, it will not meet your requirements regardless of technical capability. This should be a disqualifying factor.

Vendors: Engage with the institution's current operational state and explain how your tool will improve it. Avoid generic feature descriptions; focus on their specific workflow and risk appetite. Be honest about limitations; vendors that acknowledge what they do not do are more credible than vendors claiming to solve every problem.

Suggested Next Steps

* Conduct a detailed current-state assessment of your sanctions screening workflow, documenting the sequence of investigator steps, time required, documentation created, and escalation decisions. Deliver this as a workflow diagram to your procurement team.

* Define your operational priorities for the new tool: are you primarily trying to reduce false positives, improve detection, improve efficiency, or improve documentation and audit capability? Communicate this priority order clearly to procurement.

* Develop a vendor evaluation matrix that weights operational fit (40 to 50 per cent of total score), technical capability (30 to 40 per cent), and cost and implementation risk (10 to 20 per cent). This rebalancing drives vendor selection towards better operational outcomes.

* Build a reference check process that asks previous customers about implementation challenges, operational adoption, false positive management, and vendor support requirements. Schedule calls with at least three peer-group references and focus your questions on operational reality, not vendor reputation.

Sources: Financial Conduct Authority operational resilience guidance (2024), Prudential Regulation Authority third-party risk management framework (2024), European Banking Authority outsourcing guidelines (2022), FATF standards on sanctions compliance and enforcement (2020), TrustSphere Risk Index, April 2026.

TrustSphere helps financial institutions design and deploy intelligent fraud and financial crime detection solutions. Visit www.trustsphere.ai