AML Software Buyer's Guide for Financial Institutions: What to Know Before You Switch

Last updated: September 2026

Buying AML software is mostly a switching project. The demo shows what a new system can detect, but the risk sits in moving a live compliance program onto it without losing its history or its standing with examiners. This AML software buyer's guide covers the five decisions to settle before signing: the regulatory proof to ask for, what history moves, how the old and new systems run side by side, who validates the new system, and how examiners stay informed. A provider that cannot help with all five is not ready to be bought.

TL;DR

• Most of the risk in buying AML software sits in the switch itself, and a wrong choice means migrating twice.

• Ask for the proof an incumbent already has: exam history at peer institutions, independent validations, and validator access to the system's logic and your data.

• Inventory the history that lives only in the old system, decide what moves and what stays for record retention, and assume nothing moves one for one.

• A parallel run compares outputs; validation proves the data and the method. Exit criteria agreed in advance decide when the run ends.

• Commission your own validation, check both systems in the lookback, and brief examiners before the old system is retired.

The five decisions that make or break an AML software purchase

An AML software purchase turns on five decisions made before the contract is signed: what regulatory proof the provider can give, what history moves, how the old and new systems run side by side and when that ends, who validates the new system, and when examiners hear about the change. None of them shows up in a demo, and each leaves a document behind that an examiner can ask to see.

A decision is finished only when the document in the last column exists.

A wrong choice means a second switch. A chief compliance officer at a payments company said: "I don't want to jump into something and then have to migrate again... because we picked the wrong one." A BSA quality control officer at a business bank called switching vendors "an incredibly long runway."

This guide covers the purchase after the shortlist and the evaluation. Building the shortlist, by product type and the criteria providers disclose, is covered in a separate guide to comparing transaction monitoring software. Testing that shortlist on your own data, judging alert quality and workflow together, is covered in a guide to evaluating AML transaction monitoring platforms.

Why buying AML software is really a switching project

Buying BSA/AML software is a switching project because the incumbent has advantages a new system has to earn. Examiners already know it, and the institution's contracts, budget and configuration are built around it. A BSA/AML compliance lead at a community bank described what an established system sells: "In the examiners' world, it has already been vetted. So... they can question whether you fine tune this, you fine tune that. But they don't question the system, right? So, you're paying for that, you're paying for like peace of mind."

The switch starts on the contract calendar. A VP and AML risk officer at a community business bank declined to look at alternatives because the incumbent contract had just been renewed, and said hearing from providers before the renewal would have been in time. The budget may not sit with compliance either: a director of financial crimes operations at a large regional bank said that "technology owns our budget." Map the renewal dates and the budget owner before the evaluation starts.

A buyer who has lived through a failed implementation wants proof first. One stakeholder who owned contracts and regulatory exposure for a purchase said their team did not want to repeat "the last time that we purchased a tool and kind of got into the implementation and then realized that there were things that we just couldn't do."

A switch also needs more approvals than a demo suggests. A BSA/AML and OFAC officer at a regional bank listed "our enterprise risk management group, our data group, our IT and infosec group... model risk management." A fintech has one more approver, since, as a risk and compliance lead at a consumer fintech put it, "Our sponsor bank requires us to approve every single vendor we use." Write up the evaluation so each of those groups can review it, and bring the sponsor bank in at the start.

Whether to build instead of buying is a separate decision, covered in a guide to build versus buy for AI agents in regulated risk operations.

The regulatory proof to ask a provider for

The regulatory proof to ask an AML software provider for is the evidence an incumbent already has: exam history at institutions like yours, validations by independent parties, and assurance that your own validators can see and test how the system works. A BSA/AML compliance lead at a community bank named the first two: "if you get a few banks to back up that they went through an exam and... you were the system of record and they were OK with it, or validations of the system done by third parties like independent auditors."

Ask what your validators will get, because a validator needs both the system's logic and the institution's data. A BSA manager at a credit union described external model validators asking the incumbent vendor for data extracts and being told it could not provide them: "how is it that we cannot get extracts of our own data?" Put access to the logic, query access to the data and full data extracts into the contract.

A vendor's model is still the institution's to validate. SR 26-2, the revised model risk management guidance the Federal Reserve issued with OCC Bulletin 2026-13 and FDIC FIL-15-2026 on April 17, 2026, says banking organizations "may not receive from the vendor the underlying code, data, or methodology," yet "the principles of model risk management remain applicable." The guidance names "the validation of vendor products, either by internal or outside parties" as an important element of model risk management.

Third-party due diligence is where the institution's understanding of the system gets tested, so bring the person who will defend it in the exam room into the evaluation now. A product manager at a sponsor bank told a provider: "You don't have to sell me on it. I get it, but I don't have to defend it to the examiners." How to test a provider's claims about its AI is a separate question, covered in a guide to evaluating AI-powered AML risk platforms.

What history moves to the new system, and what stays behind

History that lives only in the old monitoring system, such as SAR and CTR records, alert and case files and the models built inside it, has to be planned for before signing, because whatever cannot move keeps the old system running for record retention. A BSA and fraud analyst at a community bank with a partner-banking program described what has to come out: "There will be things that we extract from [the incumbent] that aren't going to be in our core, right? So that's like SARs, CTRs, that type of information."

When history cannot move, the old system stays on: a QA lead at a prepaid card program manager said an old on-premises instance of the incumbent was still running for record retention because its history could not be migrated to the new edition, and that what did migrate was moved by hand, "which if I can avoid doing that again, I would like to." Models can stay behind as well. An operations lead at a sponsor bank said the bank's customer risk rating model runs inside its incumbent monitoring system and is validated there.

The data work starts upstream, in the core banking system, where a project manager at a bankers' bank expected "an awful lot of data mapping." Rule logic needs the same inventory, and a BSA officer at a community bank with a partner-banking program said "[The incumbent] does not give us the rule logic." Rules nobody can see cannot be carried over or compared.

Before signing, inventory at least:

• SAR and CTR history, including the documented reason behind each decision to file or not to file

• alert and case files, with dispositions and the evidence gathered

• customer risk ratings and the models that produce them, with their validation

• rule and scenario configurations, with the documentation behind each threshold

• the audit trail of who changed what, and when

Do not assume any provider moves SAR and case history one for one. Ask what moves, in what form, what stays readable in the old system, and how the two will be reconciled so that no alert or case is lost.

How to run the old and new systems side by side

A parallel run keeps the old and new AML systems working on the same activity at the same time, so their outputs can be compared before the old one is switched off. A parallel run is not validation: it compares outputs, while validation proves the data going into the new system and the method it applies. A risk advisory director at a consulting firm drew the line during a switch: "The parallel run piece, that's not really the validation piece, that's alert analysis and review, that's output comparison. But the validation piece is the data and ensuring that... we validate the source data into [the new system] and we're doing the data quality and the data reconciliation."

Retire the old system only when both columns are complete, since neither substitutes for the other.

Run a parallel test even when the old system is simple, because the institution has to be able to show it happened. As a chief compliance officer at a community bank said, "I think from a regulator perspective, we want to be able to say we did [a parallel run]."

How to design the parallel run

1. Agree the exit criteria before the run starts. Write down which differences must be explained, what counts as explained, and who signs off. The run ends when those criteria are met.

2. Compare outcomes, and expect alert counts to differ. A system built differently will not raise the same alerts, and an implementation lead at a cross-border B2B payments company called comparing alert counts "apples to oranges." Matching an incumbent with known gaps would prove little in any case.

3. Reconcile what crosses between the systems. Outputs can differ, but no transaction, alert or case that should reach the new system can go missing.

4. Spare investigators the double work. An AVP of compliance risk strategy at a regional bank wanted "a parallel test with what we have today and your system without duplicating the alerts." Decide in advance which system's alerts analysts work.

5. Explain every difference in writing, in both directions: what the new system caught that the old one missed, and the fix for anything it missed.

The agencies' 2018 joint statement on innovation, in effect as of September 25, 2026, treats testing of this kind as legitimate. It calls pilot programs run alongside existing processes "an important means of testing and validating the effectiveness of innovative approaches," and says that when an AI-based monitoring system finds suspicious activity existing processes missed, "the Agencies will not automatically assume that the banks' existing processes are deficient." The statement leaves the timing to management, which should judge "whether, and at what point, innovative approaches may be considered sufficiently developed to replace or augment existing BSA/AML processes."

How long the systems overlap is therefore a matter of exit criteria. A BSA/AML compliance lead at a community bank described the trade-off: "The more time you run both systems, the more comfortable you become with the new system. But again, to run ... both systems comes at a cost." Buyer and vendor can also expect different lengths: a VP and BSA officer at a bankers' bank expected parallel testing to run longer than the vendor had assumed. Criteria agreed before signing settle that with evidence.

Validating the new system before you retire the old one

Before the old system is retired, the new one should be independently validated. The FFIEC BSA/AML examination manual says a monitoring system's "programming methodology and effectiveness should be independently validated to ensure that the models are detecting potentially suspicious activity," and that management "should document and be able to explain filtering criteria, thresholds used, and how both are appropriate for the bank's risks."

Validation at the switch runs in both directions, as a regulatory compliance manager at a BSA audit and model-validation firm described: "We had to make sure that the old system was triggering the right alerts and then run it through the new system and make sure the new system wasn't missing anything."

A vendor's validation does not replace the institution's own. A BSA officer at a community bank who commissioned a separate one after taking on a new system said: "obviously they give you a model validation but we actually did a separate one... That was the best thing we ever did... because we learned so much." A validation is an exercise, not an attestation: its deliverable is a summary of the work actually done.

Whether a scenario counts as a model under SR 26-2 is itself a decision to document. The guidance, which replaced SR 11-7 and SR 21-8 and remains in effect as of September 25, 2026, defines a model as "a complex quantitative method, system, or approach that applies statistical, economic, or financial theories to process input data into quantitative estimates." It excludes "deterministic rule-based processes and software where there are no statistical, economic, or financial theories underpinning their design or use," so the exclusion is conditional: on one reading, a rule whose threshold was statistically derived can fall inside the definition.

The guidance is expected to be most relevant to banking organizations with over $30 billion in total assets, and it places generative and agentic AI models outside its scope. Neither point removes the exam manual's expectation that the monitoring system be independently validated. How validation works in depth is covered in a guide to AML model validation after the April 2026 guidance.

Keeping examiners with you through the change

Examiners judge a change of AML system on the institution's written evidence of where the new rules came from and why the change is an improvement. A BSA and compliance lead at a sponsor bank, preparing for an exam on a newly adopted system, expected examiners to "want to know where the rules come from. ... Where'd you go off of for tuning?"

A BSA officer at a money transmitter described the second part as proving "to our examiners and our bank partners that it's a change for the better." A VP of credit operations and compliance at a fintech lender with partner banks was blunter: "You have to prove that you did it, right? It's not just doing the right thing."

An SVP and director of financial intelligence at a regional bank described how familiarity can pull against flexibility: examiners were comfortable with the incumbent "because so many of the shops that they examine use [it]. ... But at the same time, it's absolutely not customizable." The system examiners know best may be the one an institution cannot tune to its own risk.

The FFIEC manual tells examiners to "focus on whether the bank has an effective SAR decision-making process, not individual SAR decisions," and says banks "should document SAR decisions, including the specific reason for filing or not filing a SAR." A switch has to keep that decision record unbroken across both systems.

Plan the timing of examiner communication as a matter of practice. Brief examiners before the switch on the plan and the design of the parallel run, share its results and the independent validation before the old system is retired, and keep a written record of each briefing. Whether formal notice is expected depends on the regulator, any supervisory agreement and, for a fintech, the sponsor bank agreement, so confirm it with counsel before the plan is final.

Cutover, and what 'done' looks like

A clean cutover lets each open alert and case finish in the system that raised it and starts every new alert in the new system. The hard part is activity that spans the cut date, because a scenario that aggregates activity over a lookback period needs history from before the cut to evaluate activity after it. Plan those aggregations explicitly, and keep investigators out of two systems any longer than the remaining open cases require.

The old configuration is someone's work, so treat it as knowledge to carry over. A BSA officer at a community bank said of the system they had taken on: "I feel like it's my baby. So, if anyone bad mouths it like, yeah, I just spent a lot of time getting the configurations right." The people who tuned it know why each threshold exists, which is the documentation an examiner will ask for.

Judge the implementation team as well as the sales team. A technology lead at a payroll technology company with a banking arm said that once a vendor is chosen, "we switch to their implementation team, which sometimes in the past has really fallen down for us." A VP of compliance at a crypto payments company, reopening a search after an earlier switch, called "the lack of transparency and communication" the final straw, so ask references how the provider behaved after signing.

After go-live, keep monitoring the new system for drift in its data, features and outcomes, and retire the old one only once lookback and record retention needs are met.

Common ways a switch goes wrong

• Treating the parallel run as the validation

• Judging the new system by how closely its alert counts match the old one's

• Assuming SAR, case and risk rating history will move one for one

• Relying on the vendor's validation instead of commissioning an independent one

• Letting examiners meet the new system for the first time at the next exam

• Choosing on the sales team and meeting the implementation team after signing

• Bringing in model risk, information security or the sponsor bank at the end

Can you modernize without replacing everything at once?

A switch does not have to replace everything at once, and the first choice is whether to stay, overlay or replace. A senior manager of IT delivery for financial crimes systems at an asset manager set out the paths: "stay where we are and do nothing; stay where we are and overlay something on top of it; or get something else that replaces our workflow system and alerting system."

A staged path spreads the change out, which is its appeal. A director of AML compliance at an online gaming operator wanted to "baby step into it" rather than face "a full cutover and training." A partner at a regulatory consultancy advising banks offered an adviser's view for AML: regulators are "not usually comfortable with brand new TM systems," but they can be brought along "by having it sit on top and then slowly using your system to take over functions."

How a bank can phase that modernization while keeping its upstream systems is answered on Oscilar's page on modernizing monitoring without replacing every upstream system. A staged path changes one thing about this guide: each stage that moves a function to the new system needs its own evidence, validation and examiner briefing.

How Oscilar approaches a switch

Oscilar's approach follows the same five decisions, and every question in this guide applies to Oscilar as much as to any other provider. Before a commitment, Oscilar structures pre-production evaluation as a design partnership: data setup, a backtest against the institution's historical alerts, shadow mode alongside the existing process, and a human-in-the-loop readout. Whichever provider you evaluate, set the acceptance criteria for a proof of concept before it starts.

Agents can run as a standalone layer on top of infrastructure you already have, or as part of the unified platform. Oscilar supports backtests, A/B tests and unit tests for risk workflows, keeps a full audit trail per decision with stored reasoning, and is human-in-the-loop by design. After go-live, Oscilar monitors data, feature and concept drift alongside outcome KPIs by segment. The institution still owns its validation standards, approval authority and regulatory accountability.

Ask Oscilar the same history questions as any other provider, starting with what moves and in what form.

Chartis Research named Oscilar to the 2026 FCC50, with category wins for Agentic AI Innovation and Low-Code/No-Code Customization.

Frequently asked questions

What should a financial institution know before buying AML software?

A financial institution should know that most of the risk in buying AML software sits in the switch from the old system to the new one. Before signing, settle the regulatory proof the provider can give, what history moves and how it is reconciled, how the old and new systems run side by side and when that ends, who validates the new system, and how examiners stay informed.

How long should the old and new AML systems run in parallel?

The old and new AML systems should run in parallel until the exit criteria agreed before the run are met, so evidence sets the length rather than a fixed period. The criteria say which differences must be explained, what counts as explained, and who signs off.

What happens to historical alerts, cases and SARs when you change AML systems?

Historical alerts, cases and SARs either move to the new system or stay readable in the old one, which then keeps running for record retention. Open alerts and cases can finish in the system that raised them while new alerts start in the new one. Ask each provider what moves, in what form and how it is reconciled, and assume nothing moves one for one.

When should examiners hear about a change of AML system?

Examiners should hear about a change of AML system before the switch. Brief them on the plan, share the results of the parallel run and the independent validation before the old system is retired, and keep a record of each briefing. Whether formal notice is expected depends on the regulator, any supervisory agreement and, for a fintech, the sponsor bank, so confirm it early.

What should you ask a provider's references before you switch?

Ask a provider's references whether they have been through an exam with the system in place and whether independent parties have validated it. Aim the other questions at the implementation rather than the sales process: who ran the switch, how problems were handled, and how openly the provider communicated after signing.

The five decisions in this guide are the same whichever provider you choose, and the documents they leave behind are what examiners will read after the switch. For the investigation side of a switch, read about case management on Oscilar.