AML Software RFP Checklist: 25 Questions to Ask Vendors
25 questions to ask AML software vendors in an RFP, grouped by detection, explainability, model risk, data, security, pricing, and proof.
TL;DR: Switching compliance platforms in AML means moving transaction monitoring, case management, or screening to a new system without losing records, coverage, or SAR deadlines along the way. Federal BSA rules require most records to be kept for five years under 31 CFR 1010.430, and SAR supporting documentation for five years from filing under 31 CFR 1020.320(d), so the old system's data has to outlive the old contract. A team is ready to switch when it has exit terms, a data inventory, a validated and re-tuned new system, a parallel run, and an examiner who has already heard the plan.
What switching means in AML
Switching compliance platforms in AML is a regulated migration, not a software swap. Move a transaction monitoring system, a case manager, or a sanctions screening engine and the worst case is a stretch of activity nobody reviewed, a SAR filed late, or an examiner asking for a 2022 case file that now sits in a vendor's deleted tenant.
The checklist below covers the part most switching guides skip: what happens to alerts, cases, and SAR history, how to prove the new system detects at least what the old one did, and how to cut over without missing a SAR deadline.
Why examiners care about the switch
Examiners care because the monitoring system is where the BSA program either works or does not. The FFIEC BSA/AML Examination Manual's suspicious activity reporting section says parameters and filters should be reviewed before implementation to identify gaps, that management should document and be able to explain filtering criteria and thresholds, and that the monitoring system's programming methodology and effectiveness should be independently validated. A new platform resets all three: every rule is new, every threshold needs a rationale, and the validation report on file describes a system about to be turned off.
Vendor choice does not move accountability. The Revised Guidance on Model Risk Management, issued April 17, 2026 by the Federal Reserve, OCC, and FDIC as SR 26-2, replaces both SR 11-7 and the 2021 interagency statement on BSA/AML model risk. Its section on vendor products says model risk principles still apply when the vendor withholds code or data, that vendor products should be validated by internal or outside parties, and that customizations made to fit the institution should be documented, justified, and evaluated as part of validation. A new monitoring platform configured for one institution is exactly that kind of customized vendor model.
The cost of a coverage gap is not theoretical. According to the Department of Justice's summary of United States v. TD Bank, the bank excluded all domestic ACH transactions, most check activity, and other transaction types from automated monitoring, leaving 92% of total transaction volume unmonitored from January 2018 to April 2024, roughly $18.3 trillion in activity. TD Bank agreed to pay a combined $1.8 billion in penalties. That gap was deliberate. A migration can produce the same result by accident, through a feed never connected or a transaction code mapped to nothing.
The migration checklist
The steps run in order. Each one produces something worth keeping in the migration file, because the next examiner or independent tester will ask how the institution got from the old system to the new one.
1. Write down what better means before anyone demos
A switch needs a baseline, or nobody can say whether it worked. Pull twelve months of alert volume by rule, false positive rate, alert-to-case and case-to-SAR conversion, median time to disposition, and backlog age from the current system. If the reason for switching is analyst workload rather than detection coverage, the answer may not be a new platform at all.
2. Read the exit terms in the current contract
Check the notice period and auto-renewal date, the export format the vendor commits to (full relational export with case notes and attachments, or a CSV of alert headers), any fees for bulk export, read-only access after termination, and whether the vendor will certify deletion. Negotiate the export before giving notice. Put the same clauses into the new contract.
3. Inventory every record and decide where it lives
Under 31 CFR 1010.430(d), records required by the BSA regulations must be retained for five years and stored so they are accessible within a reasonable period of time. Under 31 CFR 1020.320(d), a bank keeps a copy of each SAR and its supporting documentation for five years from the date of filing, so a SAR filed last month keeps its file alive until 2031 regardless of when the old vendor goes away.
The inventory should cover alerts and their dispositions, case files with analyst notes and attachments, SAR decisions including documented decisions not to file, continuing activity reviews, 314(a) and subpoena responses, customer risk ratings and their history, rule configurations, and the system's own audit log of who changed what. For each category, decide whether it migrates into the new platform as live data or moves to a read-only archive. Test retrieval by pulling a full case file the way an examiner would ask for it.
4. Map feeds and transaction codes, then reconcile the counts
Most coverage gaps start here. Every source system (core banking, card processor, ACH, wires, RDC, P2P, crypto rails) must feed the new platform, and every transaction code must map to a type the new rules understand. Reconcile record counts and dollar totals by transaction type between the source system and the new platform for the same period. A code that maps to "other" or to nothing is a rule that will never fire.
5. Translate the rules, then re-tune them
Copying thresholds from the old system rarely works, because the new system aggregates, segments, and scores differently. Translate each detection scenario by intent (the typology it targets), rebuild it in the new platform, and set thresholds from data. The FFIEC manual's example is a structuring filter that fires only above $10,000 in daily cash and misses the activity just under the CTR line. Transaction monitoring rule tuning with above-the-line and below-the-line sampling gives each threshold a written rationale that survives an exam.
6. Validate the new system independently
The FFIEC manual expects the monitoring system's methodology and effectiveness to be independently validated, and SR 26-2 says validation generally occurs before a model's first use. When urgency forces go-live first, the guidance calls for closer attention to the model's limitations and controls such as tighter monitoring. A vendor's own validation is useful due diligence, but the vendor that configured the rules is not independent of them, and neither is the implementation team. Scope the validation to data integrity and mapping, scenario logic, threshold rationale, and outcomes analysis. Sphinx's guide to AML model validation requirements covers what that report should contain.
7. Run both systems in parallel
A parallel run is the only proof that the new system catches what the old one did on live traffic. Run the new platform in shadow mode, generating alerts that are logged but not worked, through at least one month-end cycle. Then compare the alert populations. Alerts only the old system raised need a reason: a deliberate tuning decision, a mapping gap, or a missed typology. Alerts only the new system raised need a worked sample. AML rule backtesting and shadow mode explains how to set up the comparison so it does not flatter either side.
8. Tell the examiner and the board before cutover
Brief the examiner-in-charge on the timeline, the parallel-run results, and the validation plan before cutover. Institutions under a consent order or written agreement should check whether the order requires regulator non-objection for changes to monitoring systems. Take the plan to the board or its designated committee and update the BSA program document and risk assessment. Teams heading into an exam soon after go-live can use Sphinx's BSA exam preparation guide to plan the document request.
9. Plan the cutover so no SAR clock stops
Under 31 CFR 1020.320(b)(3), a SAR is due 30 calendar days after initial detection, extendable to 60 only when no suspect was identified, and those clocks do not pause for a migration. Decide whether open alerts are finished in the old system or migrated with their full history and original detection dates; finishing them in place is usually cleaner. Overlap the first monitoring window in the new system with the last day of the old one so no transaction falls between them. Clear the existing backlog before cutover rather than carrying an aged queue into an unfamiliar tool.
10. Update procedures, training, and access
Rewrite alert handling, escalation, and QA procedures for the new workflow, and train analysts on real cases from the parallel run. The FFIEC manual expects limited access to monitoring systems, with changes approved by the BSA officer or senior management.
11. Review the first 90 days against the forecast
Compare production alert volume and mix against the parallel-run forecast weekly, re-tune rules that drift, and point the next independent test at the new system.
12. Decommission last
Switch off the old platform only after the archive passes a retrieval test and the vendor certifies deletion in writing. Keep the migration file as long as the records it describes.
When switching is not the answer
Many teams start shopping for a new platform because the queue is unmanageable, not because detection is broken. A twelve-step migration does not shrink a backlog. Often it adds one, since analysts learn a new tool while the old alerts keep aging.
Sphinx takes a different path for that problem. Its AI compliance agents work inside the systems a team already runs, logging into the same transaction monitoring and case management tools analysts use, reviewing alerts against the same data, and documenting each decision with reasoning an examiner can follow through the Interpretable Agentic Framework. Detection logic, records, and validation history stay where they are, so there is nothing to migrate. Teams that do switch can run the agents across both systems to keep the queue clean through cutover.
Frequently Asked Questions
How long does it take to switch AML compliance platforms?
Timelines depend on data volume, the number of source feeds, and whether the institution is under regulatory pressure. The parallel run alone should cover at least one month-end cycle, and independent validation, examiner briefings, and backlog work add to that. Contract notice periods often set the outer limit, so read them first.
How long must AML records be kept after switching vendors?
Records required under the BSA regulations must be kept for five years under 31 CFR 1010.430(d), and SAR copies with supporting documentation for five years from the filing date under 31 CFR 1020.320(d). Those obligations stay with the institution when a vendor contract ends. The records must also remain accessible within a reasonable period of time, which is why retrieval from the archive should be tested before decommissioning.
Do I need to tell my regulator before changing transaction monitoring systems?
Institutions under a consent order or written agreement should check whether it requires regulator non-objection for monitoring system changes. Outside an order, informing the examiner-in-charge before cutover is common practice and avoids the change surfacing mid-exam. The board or its designated committee should approve the change and the updated BSA program.
What is a parallel run in an AML system migration?
A parallel run operates the new monitoring platform on live transactions alongside the incumbent, logging its alerts without routing them to analysts. Comparing the two alert populations shows coverage gaps, mapping errors, and noise before the new system becomes the system of record. The divergence analysis belongs in the migration file and the validation report.
Does a vendor AML platform need independent validation?
Yes. SR 26-2, the Revised Guidance on Model Risk Management issued April 17, 2026, says vendor products should be validated by internal or outside parties and that customizations should be documented, justified, and evaluated as part of validation. The FFIEC BSA/AML Manual separately expects a monitoring system's methodology and effectiveness to be independently validated.
