Cross-Border KYB: How to Verify International Businesses
How to verify foreign businesses: registry access by jurisdiction, non-Latin names, UBO thresholds, apostilles, FATF lists, and a coverage test.
TL;DR: An AML software RFP checklist is a set of questions a bank or fintech sends compliance vendors to test detection coverage, explainability, model risk, data integration, security, pricing, and proof before it signs. The 25 questions below are grouped by those seven areas and written to produce evidence the institution can put in its third-party due diligence file. Coverage questions come first because coverage is where programs fail quietly: TD Bank left 92% of its transaction volume unmonitored for more than six years, according to the Justice Department.
What an AML software RFP is for
An AML software RFP is a due diligence document before it is a buying document. The answers a vendor gives become part of the record an examiner reads when asking why the institution chose this system, how it knows the system works, and what it does when the system is wrong. A feature grid cannot answer those questions. A well-built RFP can.
Responsibility does not move to the vendor. The FDIC's summary of the 2023 interagency third-party guidance states that a banking organization's use of third parties does not diminish its responsibility to operate safely and soundly and in compliance with applicable laws. Every question below is written with that in mind. Each one asks for something the institution can verify, file, and defend, not for a yes or no.
This checklist is not a vendor ranking. Buyers who want a shortlist first can start with Sphinx's overviews of financial crime prevention software and compliance software for financial services, then use the questions here to test whoever makes the list.
The guidance under the RFP changed in 2026
Model risk questions in most AML RFP templates still cite SR 11-7 and OCC Bulletin 2011-12. Both were replaced on April 17, 2026. Federal Reserve SR 26-2 and OCC Bulletin 2026-13 issued revised interagency model risk guidance that supersedes SR 11-7 and the 2021 interagency statement on model risk for BSA/AML systems (SR 21-8, OCC Bulletin 2021-19).
Three changes matter for an AML software RFP. The revised guidance is expected to be most relevant to banking organizations with more than $30 billion in total assets. Its definition of a model excludes deterministic rule-based processes with no statistical, economic, or financial theory behind them, which describes many legacy transaction monitoring scenarios. And generative AI and agentic AI models are explicitly outside its scope, although the agencies state that an institution's broader risk management and governance practices should still guide controls for tools the guidance does not cover.
The practical effect is that a buyer can no longer copy a validation clause from an old template and assume it fits. The RFP has to ask what kind of system the vendor is selling, whether the institution will treat it as a model, and what governance applies if it is not one.
Third-party risk guidance is also in motion. The 2023 Interagency Guidance on Third-Party Relationships remains in effect, and its due diligence factors map closely onto the security and resilience questions below. On September 15, 2026 the OCC, Federal Reserve, FDIC, and NCUA published proposed replacement guidance that emphasizes tailoring oversight to the assessed risk of each relationship. An AML system that dispositions alerts or drafts SARs is a high-risk relationship under either version, so the depth of diligence below is warranted regardless of how the proposal is finalized.
Detection and coverage
Detection questions establish what the system actually looks at. They come first because the most expensive AML failures are coverage gaps, not tuning errors. In the TD Bank resolution, the Justice Department found the bank did not automatically monitor all domestic ACH, most check activity, and numerous other transaction types, leaving 92% of total transaction volume, about $18.3 trillion, unmonitored from January 2018 to April 2024. The bank also launched products such as Zelle without ensuring monitoring coverage.
1. Which transaction types, channels, and payment rails does the system monitor out of the box, and which require configuration or custom work? Ask for a list mapped to your own product catalog: ACH, wires, checks, cards, RTP, FedNow, Zelle, internal transfers, and crypto where relevant.
2. Which typologies and red flags does each scenario or model target? Ask for a typology-to-scenario map, so the institution can trace each risk in its BSA/AML risk assessment to at least one detection control.
3. How is coverage maintained when the institution launches a new product? Ask who identifies the gap, how long a new scenario takes to deploy, and whether the vendor flags unmonitored transaction codes automatically.
4. How does the system handle sanctions and watchlist screening alongside monitoring? Ask which lists are supported, how often they refresh, and how name-matching thresholds are set and documented.
Explainability and audit trail
Explainability questions test whether an examiner, a validator, or a new analyst can reconstruct why the system reached a decision. A score with no reasoning does not meet that bar, and neither does a disposition that lives only in an analyst's memory. Sphinx has written about what an auditable decision record looks like in an agentic system, and the same standard applies to any vendor.
5. For a single alert, what does the system show about why it fired and what data it used? Ask for a real, redacted alert record rather than a screenshot from a demo environment.
6. If the system recommends or makes a disposition, is the reasoning recorded step by step and linked to its source data? Free-text notes written after the fact are not an audit trail.
7. Are configuration changes, threshold changes, and overrides logged with user, timestamp, and rationale? Ask whether the log is immutable and how long it is retained.
8. Can the institution export the full case file, including evidence, reasoning, and approvals, in a format an examiner can read without vendor access? Exit and exam readiness both depend on this answer.
Model risk and validation
Model risk questions establish how the institution will validate a system it did not build. The revised guidance says vendor products can be harder to validate because code, data, or methodology may be proprietary, and that the principles of model risk management still apply. It describes sound practice as understanding the vendor model's conceptual soundness, design, development data, and performance, plus ongoing monitoring and outcomes analysis. Sphinx's guide to AML model validation requirements covers the validation work itself.
9. Which components of the system does the vendor consider a model, and which are deterministic rules? The answer determines which governance framework the institution applies, especially now that the revised guidance excludes deterministic rule-based processes and leaves generative and agentic AI outside its scope.
10. What validation documentation will the vendor provide: conceptual design, development data description, testing results, and known limitations? Ask whether an independent validator can receive it under NDA.
11. What ongoing performance data does the system produce for outcomes analysis? Alert-to-case and case-to-SAR conversion by scenario, drift indicators, and tuning history are the minimum. Sphinx's piece on transaction monitoring rule tuning explains why these numbers matter.
12. When the vendor updates a model, scenario library, or AI component, how is the institution notified and what testing evidence comes with the change? Silent upgrades break validation.
Data and integration
Data questions find the work the demo hid. Most AML implementations stall on data mapping, not on the software. Sphinx's overview of AML and KYC integration with core banking systems covers the common failure points.
13. Which core, card, payments, and KYC systems does the vendor have production integrations with today? Ask for named systems in production, not a roadmap.
14. What data fields are required for each scenario or model, and what happens when a field is missing or malformed? Ask how the system reports data quality failures so they do not become silent coverage gaps.
15. Where is institution data stored and processed, and is it used to train models for other customers? Ask for data residency, retention, and deletion terms in writing.
16. Does the system require an API integration, or can it work inside the institution's existing tools? The answer changes implementation time and who on the institution's side has to be involved.
Security and resilience
Security questions follow the due diligence factors the 2023 interagency guidance lists, including information security, operational resilience, incident reporting, and reliance on subcontractors. The guidance notes that an institution may review SOC reports and independent certifications, and also consider whether their scope is relevant to the activity the vendor will perform.
17. Does the vendor hold a current SOC 2 Type II report, and does its scope cover the systems that will process the institution's data? A SOC 2 report for a corporate IT environment says little about a separate production platform.
18. Which subcontractors, cloud providers, and AI model providers touch institution data, and where are they located? The interagency guidance treats subcontractor reliance and geographic location as part of due diligence.
19. What are the vendor's incident notification timelines, and do they support the institution's obligations under the computer-security incident notification rule? Ask for the contractual commitment, not the policy summary.
20. What are the recovery time and recovery point objectives, and when were they last tested? Ask for test results, including performance during any real disruption.
Implementation and pricing
Implementation and pricing questions expose the total cost of ownership that a license quote leaves out. Sphinx's comparison of transaction monitoring pricing, features, and ROI covers the common pricing models in more detail.
21. What is the pricing basis: per account, per transaction, per alert, per case, per seat, or flat? Ask the vendor to price your actual volumes and to show how the bill changes if alert volume doubles.
22. What is the implementation timeline to production, and which tasks fall on the institution's staff? Ask for the named roles and hours the vendor expects from compliance, IT, and data teams.
23. What happens at termination? Ask how case history, audit logs, and configurations are returned, in what format, and within what period.
References and proof
Proof questions replace marketing claims with evidence the institution can check. The 2023 guidance notes that relying on prior experience with or knowledge of a third party is not an adequate proxy for due diligence, and that reviewing a vendor's marketing materials can help determine whether its claims accurately represent its capabilities.
24. Can the vendor provide two references at institutions of similar size, charter type, and product mix that have been through an exam with the system in place? Ask those references what the examiner asked about the system and how the vendor supported them.
25. Will the vendor run a proof of concept on the institution's own historical data, with success criteria agreed in writing beforehand? Good criteria include detection of known SAR cases, alert volume, and analyst time per case. A vendor that will only demo on synthetic data has answered the question.
Scoring the responses
A scoring model keeps the evaluation from collapsing into whichever demo was most impressive. Weight each area to match the institution's risk assessment, score answers on evidence rather than assertion, and record why each score was given, since that record becomes part of the third-party due diligence file. Institutions that plan to rely on an independent party for validation or annual testing can coordinate the RFP with their independent testing requirements so the evidence collected once serves both purposes.
The proof of concept usually decides the outcome. Run it on a sample of historical alerts where the institution already knows the right answer, including alerts that led to SARs, and score each vendor against the same sample. Vendors that perform well on curated data and poorly on the institution's own data are common, and the RFP stage is the cheapest time to find out.
Where Sphinx Fits
Sphinx sells AI compliance agents that work at the investigation and disposition layer, so several questions above apply to it directly and buyers should ask them. Sphinx agents work inside the screening, monitoring, case management, and onboarding systems analysts already use, with no API integration required, and record step-by-step reasoning linked to source data on every recommendation, with analyst override. Across customers including Equals Money, Alviere, and Conduit, 98 percent of cases are resolved the same day and case review time falls by 80 percent. Sphinx is SOC 2 Type II certified and GDPR compliant. Because agentic AI sits outside the scope of the revised model risk guidance, buyers should also ask Sphinx, as they would any agentic vendor, how its controls fit the institution's own governance framework.
Frequently Asked Questions
What should an AML software RFP include?
An AML software RFP should cover detection coverage, explainability and audit trail, model risk and validation, data and integration, security and resilience, implementation and pricing, and references with a proof of concept. Each question should ask for evidence the institution can file, such as a typology map, a redacted alert, or a SOC 2 Type II report, rather than a yes or no answer.
Is SR 11-7 still the standard for validating AML software?
No. On April 17, 2026 the Federal Reserve, OCC, and FDIC issued revised model risk management guidance (SR 26-2 and OCC Bulletin 2026-13) that superseded SR 11-7, OCC Bulletin 2011-12, and the 2021 interagency statement on BSA/AML model risk. The revised guidance excludes deterministic rule-based processes from its model definition and places generative and agentic AI outside its scope.
How long should an AML software evaluation take?
Guidance does not set a timeline. The length depends mostly on how much of the evaluation is evidence-based: collecting documentation, checking references, and running a proof of concept on the institution's own data take longer than a demo-based evaluation, and they produce the record an examiner will ask for.
Does a SOC 2 report satisfy security due diligence for an AML vendor?
A SOC 2 Type II report is a useful input, not a complete answer. The 2023 interagency third-party guidance says an institution may review SOC reports and should consider whether their scope is relevant to the activity the vendor performs, and it also lists subcontractors, incident reporting, and operational resilience as separate due diligence factors.
Who is responsible if a vendor's AML system misses suspicious activity?
The institution. Interagency third-party guidance states that using a third party does not diminish a banking organization's responsibility to operate safely and soundly and comply with applicable laws, which includes its BSA obligations. That is why the RFP should collect evidence the institution can use to monitor and challenge the vendor after go-live.
