AML and sanctions screening RFP questions: how to run the evaluation
Compliance leaders evaluating AML and sanctions screening RFP questions are in a hard position: they must show examiners that transaction monitoring and sanctions screening work, and they are about to hand part of that work to an implementation partner. The questions in this section test whether a partner can own the rules, the watchlist data, the evidence and the ongoing support for a self-hosted Jube and yente stack. Ask every bidder to answer in writing and to tie each answer to your own environment, your typologies, your list sources and your hosting constraints. A generic answer that could describe any AML product is a signal in itself. These questions are vendor neutral, so use them the same way whether the bidder proposes Jube, yente, a commercial suite or a mix.
DeployOpen plans, implements, tunes, documents and supports self-hosted open-source platforms in the client's own infrastructure, and runs security testing on them. It does not issue audit reports, attestations or certifications, and independent auditors and examiners make their own judgments. For that reason, weight answers by the evidence they would leave behind: rule and model change logs, tuning and validation records, alert disposition data, list version histories, failover test results and runbooks. Ask each bidder to name the artifact that would prove a claim, who in your organization would receive it, and how often it would be refreshed. A partner that cannot describe its evidence trail in these terms is unlikely to support an examination well.
Score the answers against a short written scope and keep the scoring sheet with the RFP file. Before issuing the RFP, confirm with your compliance and legal teams which list sources and licenses apply to internal commercial use, which regulator reports your team must file, and which retention periods your policy requires. Then ask bidders to price the parts that recur, such as list licensing, support hours and model revalidation, separately from the one-time build. Any bidder that will not commit to a written scope and to named deliverables before work starts should be treated as a risk, whatever its technical depth.
Which questions reveal whether a partner can run AML and sanctions screening
How should a partner approach rule and model tuning for self-hosted Jube?
A credible partner starts from a documented typology inventory and a written tuning plan, not from default thresholds. Ask for the typology list mapped to each rule or model, the training and validation data split, the tuning log showing which parameters changed and why, and the sign-off record from your compliance officer. Ask who owns each change after go-live: the partner may build and test rules, but your BSA officer or model risk owner should approve them in writing. Ask how a rule is retired, how versions are kept, and how a change is rolled back in a test environment before production. Good answers name these artifacts and roles rather than describing tuning as an ongoing black box.
What methods do partners use to reduce false positives in sanctions and transaction alerts?
Expect a partner to explain both the matching configuration and the alert design. For yente, ask how score thresholds were set, which name normalization and schema filters are applied, and how decisions on near matches are recorded so the same alert is not re-reviewed without new information. For Jube, ask how alert suppression, segmentation by customer type or product, and threshold testing against historical data are done, and what false positive rate was measured before and after tuning. Ask for a written before-and-after test report with the dataset description. A partner who promises a specific reduction without a baseline is not answering the question.
How should a partner handle watchlist data licensing for OpenSanctions data?
The partner should confirm which OpenSanctions datasets you will load, whether your use is covered by the license for internal commercial use, and who signs the license. Ask for a data inventory listing each source, its license terms, the version or snapshot loaded, and the date of last refresh. Ask how upstream government lists such as OFAC's SDN list are sourced and checked against the authoritative publication, and how changes are logged. Ask whether the partner will document license obligations for your legal team, and whether attribution or redistribution limits affect any downstream reporting. Confirm these points directly with OpenSanctions and your counsel, since terms can change.
How does a partner design high availability for a self-hosted screening and monitoring stack?
Describe the failure modes first: a failed screening call can stall payments, and a failed monitoring pipeline can create a gap in coverage. Ask for the architecture showing redundant yente and Jube nodes, the database and queue design, and the recovery time and recovery point objectives agreed in writing. Ask how a payment is handled when screening is unavailable, whether it is queued, blocked or released under a documented exception, and who approves that choice. Ask for failover test results and the date of the last test. Confirm that alert backlogs are monitored so a silent outage cannot hide missed alerts.
What validation and documentation should a partner provide for examiners?
A good partner provides a model or rule validation package: scope, methodology, data lineage, performance testing, limitations, and an independent review record. Ask for the documentation set examiners typically request, including rule descriptions, parameter rationale, change logs, testing evidence, and ongoing monitoring results. Ask who prepares the package, who approves it, and how it is kept current after each change. DeployOpen prepares systems, controls and evidence for compliance assessments, but examiners and independent auditors reach their own conclusions. Ask the partner to confirm that exam readiness covers the BSA and OFAC obligations your institution actually has.
How should case handling and records be designed for BSA and OFAC obligations?
The partner should show a case workflow with alert triage, escalation, investigator notes, and disposition codes, plus a record of who acted and when. Ask how a suspicious activity report or a blocking report is prepared, and how the 30-day filing clock and the 10-business-day reporting rule are tracked in the system. Ask for the retention design, including five-year retention of SARs and supporting documents, and how audit logs are protected from edits. Confirm that the partner will not decide filing outcomes, and that your compliance staff remain accountable for each decision.
What security and data location controls should a self-hosted AML partner prove?
Screened and monitored data is personal and financial, so ask where every copy lives, including logs, backups and test environments. Ask for the hosting map, encryption design in transit and at rest, access control with multi-factor authentication for every user, change management records, and centralized logging. For EU customers, ask how GDPR principles such as data minimization and purpose limitation are applied to screened names and transaction data. Ask for the most recent independent penetration test summary and the cadence of vulnerability assessments. Where the institution is subject to the FTC Safeguards Rule, ask how each requirement maps to a named control.
What does ongoing support, upgrade and exit look like for this stack?
Ask for a written support scope covering monitoring, patching, Jube and yente upgrades, list refresh, and rule tuning requests, with named response roles and escalation paths. Support can be fixed-scope or a retainer, and the cost depends on the number of environments, the frequency of list and rule changes, and the testing required before each release. Ask about exit: a documented exit strategy, a full export of rules, configurations, case data and logs, and a transition plan. Under DORA, a contract for ICT services that supports critical or important functions must state where data is processed and cover data return on termination, so ask for that language if EU entities are in scope.
How to tell a credible answer from a sales answer
A credible answer names the artifacts the partner will hand over and who signs off on each one. For a self-hosted AML stack built on Jube and yente, ask for tuning logs that record each rule and threshold change with its reason and approver, backtesting results that show how a proposed rule would have behaved on historical transactions, model documentation covering inputs, training data and known limits, license terms for every watchlist dataset, and runbooks for alert handling and list refreshes. A vendor that answers with a promise to "tune the system" without naming these outputs is describing effort, not evidence. Equally important is the list of decisions that stay with your compliance team: risk appetite, the threshold at which an alert becomes a case, which typologies matter for your customer base, and who accepts a model change. A partner that claims to make those decisions for you is overstating its role.
The clearest test is whether the partner configures a tool or owns outcomes. A configuration partner installs the software, loads rules and hands over a working environment. An outcome-owning partner also defines how false positive rates will be measured, reports them against an agreed baseline, and states which results it is accountable for and which depend on your data quality and staffing. Ask each bidder to walk through a worked example labeled as illustrative: a hypothetical batch of 1,000 transactions from a payments customer, showing how a new velocity rule is drafted, backtested, reviewed, deployed and later adjusted. Look for the steps, the owner of each step, the documentation produced and the point where your team signs off. Vague examples, or examples that skip the review step, usually signal the same gap later. Finally, confirm that licensing and regulatory interpretation rest with you. Have counsel review the license terms for each watchlist source before any screening data is loaded, including whether internal commercial use is covered. Ask your BSA or AML officer and your supervisors how they expect alert thresholds, record retention and model changes to be documented, because examiner expectations differ between institutions and jurisdictions. Any partner that offers a legal opinion on these points should be asked to put the scope of that opinion in writing, and you should still take it to your own counsel before relying on it.
Answers that should worry you before you shortlist a partner
A partner's answers to the questions below will show how it runs a self-hosted AML stack in practice. The warning signs in these cards share one pattern: a claim that sounds confident but cannot be tested, documented or priced against a written scope.
Promises of zero false positives
No monitoring or screening system delivers zero false positives or a guaranteed detection rate, and a partner that promises either has not run tuning against your transaction history. Detection quality depends on your typologies, data quality and thresholds, and it changes as customer behavior changes. Ask the partner to describe how it measures alert precision and miss rates on your data before go-live, and what results it would show an examiner. Ask for the tuning test plan and the metrics it reports.
Claims of certification or approval
Neither Jube, yente nor OpenSanctions is certified or approved by a regulator, and no AML platform is endorsed by a supervisor as such. A partner that says the platform is "regulator approved" is misdescribing how examiners assess a program, which looks at your policies, model governance and evidence. Ask which parts of the program the partner can document for examiners, and which parts remain your responsibility.
Vague watchlist data licensing
Sanctions and PEP data comes from sources with their own license terms, and internal commercial use, redistribution and on-premises hosting can each be licensed differently. A partner that says the data is free for any use has not checked those terms against your business. Ask which dataset versions it will load, who holds the license for each, and what your legal team must sign before the first screening run.
No plan for rule change control
Rules, thresholds and model versions change during tuning and after examiner feedback, and each change needs an approval record. A partner without a documented change process cannot show which rule was live on a given date or why an alert was suppressed. Ask how changes are proposed, tested against historical data, approved by a named owner, deployed and rolled back, and whether the record of each change is kept in the case store.
Untested backup and restore
Case files, alert history and screening logs are records you may need to produce for years, so an unrestored backup is not evidence of recoverability. Ask the partner to show when it last restored the case store into a separate environment, how long the restore took, and whether it verified record counts and audit logs afterward. Ask who owns the restore test and how its results are documented.
Refusing to name tuning sign-off
Tuning decisions change which suspicious activity is seen, so someone accountable must approve them. A partner that will not name who signs off on tuning, whether your BSA officer, model risk function or a delegate, is leaving your governance gap open. Ask the partner to draft the approval roles in a RACI table and to state which decisions it will make, which it will only recommend, and which it will never make alone.
How to score partner responses
This table lists seven criteria that separate a credible self-hosted AML and sanctions partner from one that only sounds confident. Each row shows what full credit requires and what should lower the score, so reviewers can compare answers on the same basis. Compliance and security owners should set the weights and scoring thresholds before responses arrive, so the scoring is not shaped by the answers they receive.
| Criterion | Full credit requires | Triggers a low score |
|---|---|---|
| Tuning method and governance | A documented tuning process for rules and models, tied to named typologies, with approval steps, version history and a model or rule owner on the client side | Tuning described as a one-off setup, no approval workflow, or changes made directly in production without records |
| False positive approach | Measured alert quality metrics, a defined review cycle for thresholds, and a stated method for tuning matching sensitivity with reviewed outcomes | Claims of low false positives with no baseline, test data, or method for measuring alert quality over time |
| Data licensing clarity | Written identification of each watchlist source, its license terms for internal commercial use, and who holds the license for the client's deployment | Vague references to open data, unclear license scope, or no statement on who must renew or pay for data sources |
| High availability design | Described failover for screening and monitoring services, documented recovery targets agreed with the client, and tested restore procedures | No description of failure behavior for screening calls, or availability claims with no architecture or test evidence |
| Examiner evidence | A sample audit trail, rule and model documentation pack, change logs, and a mapping of outputs to the client's regulatory obligations | Documentation promised after go-live, no sample artifacts, or evidence that depends on the partner staying engaged |
| Support model | Named response roles, defined service hours, a patch and upgrade cadence, and clear responsibility split between partner and client teams | Support described only as available on request, no upgrade policy, or no clarity on who handles incidents affecting alert queues |
| Exit and data return | A written exit plan, export formats for cases, alerts and configuration, and contract terms covering data return and transition support | No exit plan, data stored in proprietary formats without export, or termination terms silent on data return |
Running the evaluation from RFP issue to contract
This sequence turns a set of vendor questions into a comparable set of written answers, a tested demonstration and a fixed-scope statement of work that your compliance and technology teams can both sign off. Each step produces a record you can show an examiner later.
Issue a written requirements pack
Your compliance lead and head of technology prepare one document that states expected transaction volumes, peak rates, latency targets, the typologies and rules you need, the list sources you screen against, case handling expectations and retention periods. Send the same pack to every shortlisted partner so answers can be compared on equal terms. The step is complete when the pack has a named owner on your side and a version number that appears on every later document.
Send the questions and request written responses
Send the question set on rule and model tuning, false positive reduction, watchlist data licensing, high availability, validation evidence, documentation for examiners and ongoing support. Ask each partner to answer in writing, to name who on their team will do the work and to state which items depend on your own data or licenses. The step is complete when every question has a written answer, and gaps are logged as clarifications rather than resolved verbally.
Run a scripted demonstration on your sample data
Provide a sample dataset, prepared by your team with personal data masked or synthetic, and ask each partner to run a scripted scenario against it. The script should include alert generation for known typologies, a sanctions match with close name variants, a case being opened, escalated and closed, and a report showing the decision trail. Record the outputs, the rule versions used and any manual steps. The step is complete when each partner has run the same script and you hold the logs and outputs.
Check references and evidence samples
Ask for references from comparable self-hosted deployments and request sample artifacts such as model documentation, validation reports (redacted where needed), change records and an example examiner pack. Confirm with each reference what was delivered, what the partner supported after go-live and how issues were handled. Confirm your own legal and procurement requirements for references before you ask. The step is complete when your team has reviewed the samples against the requirements pack and noted any gaps in writing.
Agree a fixed-scope written statement of work
Select a partner and agree a statement of work that lists scope, deliverables, acceptance criteria, responsibilities for data and licenses, the support model and the exit and data return terms. Ask the partner to confirm timing in writing, since schedules depend on your environment and approvals. The step is complete when both parties have signed the statement of work and the evaluation records are filed with the project documentation.
What examiners will ask the partner to show
Examiners and auditors judge a self-hosted AML stack by its paper trail as much as by its detection logic. Before the first review, the partner should be able to show documented rule and model rationale for every scenario in Jube, tied to the typology it addresses, along with who approved it and when. Expect requests for a change log covering each threshold adjustment, model retrain and configuration change, with the before and after values, the reason, and the approver. Validation results should show how alerts were tested against known typologies and historical cases, and how any tuning affected alert volume and missed-activity risk.
On the screening side, the question is whether every list was current, licensed for the way it is used, and loaded on a known date. For yente and OpenSanctions data, ask the partner to produce the dataset version and load timestamp behind each screening decision, the license terms that cover internal commercial use, and the log showing how stale or failed updates were handled. Alert and case records need the same discipline: each alert, disposition, escalation and sign-off should be traceable to a named analyst. Under US rules, the five-year retention of SARs and supporting documents, which the partner should help configure in storage and backups, sets the baseline for how long these records must remain retrievable. EU customer due diligence documentation carries its own retention expectations under the EU rulebook.
The client should confirm the exact retention periods, record formats and documentation duties with counsel and its supervisor before scoping the work. Ask the partner to propose a records map that lists each record type, where it is stored, who can alter it, and how it is exported for examination. Ask for a sample examiner package built from test data, so the gaps appear before a real request arrives.
Which questions the CISO, compliance lead and procurement team should own
The compliance lead owns whether alerts, rules and screening decisions will hold up when an examiner or an independent model validator reviews them. Ask partners to show how tuning is governed, measured and documented, and to produce examples from a past engagement rather than a generic methodology.
- Rule and model tuning: Ask how typologies map to rules and models, who approves each threshold change, and whether changes are back-tested against historical cases before release. Request the tuning methodology and a sample change log with approvals.
- False positive reduction: Ask how alert volumes, hit rates and analyst dispositions are measured before and after each tuning cycle, and how screening match thresholds are set and reviewed. Request the alert disposition report template and a before and after tuning summary.
- Independent validation: Ask who performs model validation, what scope it covers, and how findings are tracked to closure. Request the validation plan and the most recent validation report, with any sensitive detail redacted.
- Examiner evidence: Ask what each rule and screening decision produces as evidence: rationale, data lineage, test results and decision logs. Request an illustrative evidence binder for one rule and one screening hit.
Check that the partner can explain every threshold in writing, in terms your own risk appetite and model governance policy would accept.
Security and platform leads own the environment where customer and payment data is screened and scored, so their questions cover hosting, access, availability and recoverability. Architecture diagrams are a starting point. Ask for runbooks, configuration baselines and test records that show the design works under failure and attack.
- Hosting and isolation: Ask where each component runs, how screening and monitoring services are separated from other workloads, and how outbound connections to watchlist sources are restricted. Request the reference architecture with data flow and network diagrams.
- Access and multi-factor authentication: Ask how administrator and analyst access is authenticated, how multi-factor authentication is enforced for every individual with access to an information system, and how changes to rules and configuration follow change management. Request the access control matrix and the change procedure. The FTC Safeguards Rule text at 16 CFR 314.4 sets these expectations for covered non-bank financial institutions.
- High availability and backup: Ask how screening continues during node loss, what recovery point and recovery time the design targets, and how restores are tested. Request the high availability design and the record of the most recent restore test.
- Logging and monitoring: Ask which user and system actions are logged, where logs are stored, how long they are kept, and how they are protected from alteration. Request the logging specification and a sample audit trail export.
- Testing cadence: Ask how penetration tests and vulnerability assessments are scheduled and whether continuous monitoring is in place to meet the testing requirements. Request the latest test summary and the remediation tracker.
Confirm that every control named here has a named owner, a runbook and a dated test record.
Procurement and legal decide who holds the watchlist licenses, who supports the platform after go-live, and how the institution leaves the arrangement if it has to. For entities in scope of the EU's DORA regulation, which has applied since 17 January 2025, several of these points are mandatory contract content, not negotiating preferences.
- Watchlist data licensing: Ask which sanctions and PEP data sources are used, which license covers internal commercial use, and who is party to that license. Request the data license terms and an inventory of list sources with their usage rights.
- Support scope: Ask what fixed-scope delivery includes, what falls under an ongoing retainer, and what response commitments are written into the contract. Request the statement of work and the support schedule.
- Exit and data return: Ask for a documented exit strategy and transition plan covering configurations, rule histories and case records, and the process for returning data on termination or provider insolvency. DORA Article 30(2) expects the contract to state where services and data are located and to cover data return. Request the draft exit plan and the relevant contract clauses.
- Register and subcontractors: Ask how the arrangement will appear in the register of information on ICT contracts and which subcontractors can access data. Request the subcontractor list and the register entry the partner expects you to maintain.
- Open source licensing: Ask for a license inventory of every component, including any components that carry a commercial license. Request the software bill of materials.
Check that each contract clause matches what the technical team was told during the proposal.
Ongoing support questions that decide the first year after go-live
The first year after go-live is decided by who owns the stack once the project team leaves, so ask every partner to put the support boundary in writing before signing. Ask which components are covered (Jube, yente, the data pipeline, the case management layer and the hosting), which versions are supported, and what is excluded, such as rule changes made by your analysts or model retraining requested by your model risk team. Ongoing support, upgrades and continuous testing are available as DeployOpen retainers, and their price follows from the written scope, so the boundary question is also the pricing question.
Ask how upgrades to Jube and yente will be handled in your environment. Request a written upgrade procedure that covers a staging run against your own rules and thresholds, regression checks on sample alerts and sanctions matches, rollback steps, and who approves the change under your change management procedure. For list refresh, ask who pulls the OpenSanctions data, how often it runs, who checks that the refresh completed and that the expected source files were loaded, and who signs off when a list changes thresholds or match volumes. Confirm the refresh cadence against your own licensing terms for the data before you agree to it.
Ask for the incident response plan for a screening outage, including how the partner is paged, the response targets written into the contract, and whether a documented fallback exists while yente is down, such as a queued manual review. For exit, ask in writing how case data, alert history, rule and threshold configuration, model documentation and audit logs are exported, in what formats, and within what timeframe. Your records retention obligations continue after the contract ends, so confirm who holds the archive and how it stays readable. Tuning reviews are where false positive rates shift most, so the retainer should name how often reviews happen, what evidence they produce, and who receives it.
How DeployOpen runs AML and sanctions screening evaluations and implementation
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For AML and sanctions screening RFP questions, we start by turning the questions a partner must answer into a written scope, then build, test and document the stack so your team can evaluate proposals against the same evidence.
How we scope
- Written scope lists which monitoring, screening and case functions are covered, agreed before work starts.
- We map your RFP questions to deliverables, owners and acceptance criteria for tuning, data licensing and availability.
- Engagements are fixed-scope, so the list of documents, tests and integrations is agreed in writing up front.
How we build
- We deploy self-hosted Jube and yente in your cloud accounts, data centers or air-gapped networks, under your control.
- Rule and model tuning runs against your typologies and historical data, with false positive results recorded for review.
- Security testing covers applications, APIs and infrastructure, and the watchlist update pipeline is tested end to end.
How we hand over
- Handover includes configuration records, rule and model documentation, runbooks and the evidence set your examiners will request.
- We document list sources, licensing terms, update schedules and the audit trail for every screening decision.
- Your team receives walkthroughs so staff can operate, tune and explain the stack without depending on a single person.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover version upgrades, list refreshes, backup checks and re-validation after rule or model changes.
- We do not issue audit reports or certifications, so we prepare the evidence and your independent assessor reviews it.
