Best AML Software: 9 Criteria for Your Shortlist

Last updated: October 2026

The best AML software for a bank, credit union or fintech is the software that covers that institution's own money laundering risk, gives every part of the program the same view of the customer, and leaves a record an examiner can follow from alert to SAR decision. No ranked list can know that in advance, so this guide gives nine disclosed criteria instead, each with a question to ask and a way to test the answer on your own data. Oscilar wrote this guide and sells AML software. For that reason it names and ranks no products, and it holds Oscilar to the same nine criteria near the end.

TL;DR

• AML software is four jobs, not one product: customer due diligence and risk rating, transaction monitoring, sanctions and PEP screening, and case management and SAR filing.

• Decide first whether you want those jobs on one platform or spread across several tools, and be honest about where the hand-offs between tools cost you.

• Judge every provider against the same nine criteria, from coverage of your own risk to independent validation and human sign-off on anything AI recommends.

• Treat a vague answer as a weak one, and test the providers that survive on your own data before you sign.

The short answer: how to choose AML software

To choose AML software, start from your own risk assessment rather than a feature grid, decide which of the four AML jobs you are buying for, and then ask every provider the same questions against disclosed criteria. The FFIEC BSA/AML Examination Manual sets the principle for monitoring: "The sophistication of monitoring systems should be dictated by the bank's risk profile." The providers whose answers hold up become a shortlist to test on your own historical and live data before you sign.

Disclosed criteria matter because early conversations blur together. A BSA officer at a mid-sized bank described the start of an evaluation this way: "everyone kind of sounds the same in the beginning but it's really, you know, what does it actually do? What are the results?" The nine criteria below are built to answer those two questions for any provider.

This guide covers building the shortlist. Once a choice is in sight, the decisions that come with buying and switching AML software, from history migration to the parallel run and cutover, are covered in a separate guide.

What AML software covers

AML software is the set of systems a financial institution uses to know its customers, watch their activity, screen them against sanctions and politically exposed person (PEP) lists, and investigate and report what looks suspicious. Most anti money laundering software covers one or two of those jobs well, and some platforms try to cover all four. Each job produces a record that an examiner will read, which is why the record matters as much as the detection.

Each component maps to a body of rules or guidance. For customer due diligence, FinCEN's CDD rule (31 CFR 1010.230) requires a covered institution to identify each individual who "owns 25 percent or more of the equity interests" of a legal entity customer, and to verify beneficial owners "according to risk-based procedures to the extent reasonable and practicable". Customer risk rating sits on top of that work, and a BSA analyst at a community bank put its weight plainly: "customer risk management is a very important component of the aml program".

On the monitoring side, the FFIEC manual describes five interdependent components of suspicious activity monitoring and reporting: identification or alert of unusual activity, managing alerts, SAR decision making, SAR completion and filing, and monitoring and SAR filing on continuing activity. Monitoring software that only raises alerts covers the first of those five. The nine criteria for transaction monitoring software go deeper on the monitoring job alone.

Screening is one control inside a wider program. OFAC's 2019 Framework for OFAC Compliance Commitments names five essential components of a sanctions compliance program: "(1) management commitment; (2) risk assessment; (3) internal controls; (4) testing and auditing; and (5) training." A screening tool sits inside internal controls, and the Framework expects an institution to have "selected and calibrated the solutions in a manner that is appropriate to address the organization's risk profile and compliance needs". How to judge a screening tool on its own terms is covered in a separate guide to choosing sanctions screening software.

Case management and SAR filing close the loop. The FFIEC manual is direct about what examiners look at: "Examiners should focus on whether the bank has an effective SAR decision-making process, not individual SAR decisions." It also says "Banks should document SAR decisions, including the specific reason for filing or not filing a SAR."

One platform or several?

AML software can be bought as one platform covering all four components or as separate tools for each, and both choices can be right. The deciding question is where the hand-offs between components cost your team time, context or defensibility. A good evaluation makes the case both ways before it picks.

The case for one platform starts with the escalation path. A director of BSA compliance at a community bank explained why they wanted fraud and BSA work together: "I prefer that it lives under the same roof because today, they clear the alert. But if they don't clear the alert, they escalate the alert... If we have two separate systems, that whole integration is not going to exist". An SVP of FIU operations at a community bank described the goal as bringing scattered processes together "from account inception to the life, of the account".

The case against assuming one platform does everything well is just as real. A chief compliance officer at a payments company said: "I haven't seen one vendor that does it all really well. Usually one does kyt very well, and the others do a kyb kyc." A dedicated tool can be the right answer for one component, as long as its output reaches the rest of the program with context intact.

Screening is often where the consolidation question gets decided. A BSA lead who ran an evaluation at a community bank reported that "the bank preferred a more consolidated solution that would satisfy both aml monitoring and sanctions compliance." The same lead listed what a separate tool adds: "additional vendor management and third party dependency risk, additional implementation complexity and integration work".

Other buyers go the other way and keep their screening tool. A VP of fraud prevention and BSA at a credit union asked an evaluated platform whether it could take in the screening tool's hits, including cleared ones, for the rest of its AML work rather than replace the screener.

Before comparing platforms, ask what each one actually takes in and gives back. A chief compliance officer at an early-stage money transmitter put the question sharply: "Are you ingesting an entire transaction flow and coming back with hits? Are you ingesting only our hits and coming back with a dashboard? Like those are two different products." A shortlist that mixes the two kinds of product will compare answers that are not comparable.

Whatever the shape, unify the signal and keep the accountability separate. Fraud and AML should see the same customer and the same behaviour, but they answer to different obligations, different regulators and different standards of proof, so a single merged decision queue creates a governance problem. For a fintech, the sponsor bank is part of the decision too: a head of risk and operations at a fintech that offers accounts through sponsor banks noted that their sponsor bank owns SAR reporting, which limits what the fintech can consolidate on its own. Moving to one platform can also be phased, keeping existing systems in place while a new layer is added.

1. Coverage of your own risk

What it is. Risk coverage is how closely the software's detection, screening and rating logic matches the risks in your own BSA/AML risk assessment: your products, customers, channels and geographies. The FFIEC manual says monitoring should be dictated by the bank's risk profile "with particular emphasis on the composition of higher-risk products, services, customers, entities, and geographies." Coverage also means segmentation, because a sponsor bank, a bank with several lines of business or a fintech with distinct programs rarely carries one risk profile.

A chief compliance officer at a community bank asked exactly that during a demo: "If we had another branch number for a fintech that we were sponsoring, is it possible to set a different rule set for those for that particular branch or that set of transactions?"

What to ask a provider. Map your detection logic to our top typologies, and show how we would run a different rule set for one line of business or one sponsored program.

What a weak answer sounds like. A count of rules or scenarios in a library, with no mapping to your risk assessment and no way to treat one segment differently from another.

How to test it on your own data. Take your top typologies from the risk assessment and ask the provider to show, on a sample of your own activity, which rule or model would catch each one, and where a typology has no coverage at all.

2. Customer risk rating that stays current

What it is. Customer risk rating is the score or tier that tells the rest of the program how closely to watch a customer, and it should move when the customer's behaviour or circumstances change. The rating drives monitoring thresholds, screening frequency and enhanced due diligence (EDD), so a stale rating weakens every other component. It also has to be explainable, since an examiner will ask why a customer sits in a given tier.

One community bank's BSA team described the problem with a batch score that moved on its own schedule: their system re-scored customer risk each month, the high-risk list kept shifting, and the team tracked high-risk customers and EDD due dates by hand to give examiners a clean report.

What to ask a provider. What changes a customer's rating between reviews, how quickly does the change reach monitoring and screening, and what reason is recorded with each change?

What a weak answer sounds like. A periodic batch score that nobody can explain, with EDD due dates and high-risk lists managed outside the system.

How to test it on your own data. Pick a sample of your own customers, introduce an event that should raise their risk, such as a new high-risk product or an unusual pattern of activity, and check that the rating moves, the reason is recorded and the change reaches the other components.

3. Your core data, and open access to it

What it is. Data access is what the software can read from your core banking system and your other platforms, who does the work of mapping it, and whether you can get all of your data back out. Every component depends on it: a risk rating, an alert or a screening hit is only as good as the customer data behind it. A fraud strategy director at a mid-sized bank asked whether a provider had worked with banks on their particular core, because one view of the customer depends on getting data out of several platforms inside that core.

Getting data out matters as much as getting it in. A chief compliance officer at a consumer prepaid fintech said: "I just need all the data exportable to me in some manner, right? Just give me an open data window".

What to ask a provider. Which of our core and ancillary systems can you read from on day one, who maps each one, and can we export every record, including alerts, decisions and case history?

What a weak answer sounds like. A fixed set of reports in place of an export, or a mapping project priced and scoped only after the contract is signed.

How to test it on your own data. Ask for a full extract of one test month, including alerts, dispositions and case notes, and reconcile it against what your current systems hold for the same month.

4. One path from alert to case to SAR decision

What it is. The alert-to-SAR path is the route a piece of unusual activity takes from the first alert, through investigation in a case, to a documented decision to file or not file a SAR. The FFIEC manual treats alert management as its own component: "Alert management focuses on processes used to investigate and evaluate identified unusual activity." It adds that "investigators should document conclusions including any recommendation regarding whether or not to file a SAR."

The path starts with an alert that carries its context. An alert that only reports that something looked anomalous is not actionable; what makes it actionable is the context attached, such as what the account normally does and what is linked to it. From there, case management handles the deeper investigation: linking alerts and entities, gathering evidence, recording rationale and coordinating approvals.

Filing belongs on the same path. A director of BSA compliance at a community bank listed the questions a demo should answer: "Can I file sars? Can I file ctrs? ... Can I respond from the platform or do I need to ... go and respond to the, through a different system? Because that's the day to day job".

What to ask a provider. Show an alert becoming a case, two related alerts linked into one investigation, and a SAR decision recorded with its reason, including a decision not to file.

What a weak answer sounds like. Cases tracked outside the system. A compliance director at a payments company described a team with no central case management, pulling information from several platforms, writing decisions into notes and tracking cases in a spreadsheet.

How to test it on your own data. Replay a closed investigation from your own history, from the first alert to the SAR decision, and check that every step and its reason is recorded in one place.

5. Rules your team can change, with a change record

What it is. Change control is who can change detection rules and thresholds, how a change is tested before it reaches production, and how the reason, test result and approval are recorded. A director of BSA compliance at a community bank described the record they keep today on paper: "We have to put like this is why we want to make the change. These are the results of our testing and then you send it for somebody else to approve". Good software keeps that record for you.

Buyers want analysts, not engineers, to make the change. A head of risk and operations at a fintech that offers accounts through sponsor banks wanted "non engineers that, you know, my analyst ... can build rules and alerts on the go". When every change goes through IT, an AML and KYC analyst at a digital bank said, "There is no, no way to, you know, to do a quick change."

Testing before release is the other half. A chief compliance officer at a consumer prepaid fintech described a slow tuning cycle: "We have to wait for a monthly process to finish before we can see the rule output... you put greater than, instead of greater than or equal to. And now your results are off and you have to wait a full month to see that". A director of BSA compliance at a community bank recalled a rule change at a previous institution that set off a flood of alerts, and asked whether the provider offered a test environment.

What to ask a provider. Can our analysts change a rule without your engineers or a paid change request, test it against our history the same day, and record who approved it and why?

What a weak answer sounds like. Rule changes that need a ticket to the provider, or a change whose effect you only see after the next monitoring cycle has run.

How to test it on your own data. Make one real threshold change during the evaluation, backtest it on your historical data the same day, and check that the change record shows the reason, the test result and the approver. A BSA analyst at a community bank summed up the standard: "for compliance and audit purpose, we will need to have traceability of all the changes we do to the system."

6. Explanations an examiner can follow

What it is. Explainability means every alert, rating and decision can be explained in writing, months later, to someone who was not there. The FFIEC manual says "Management should document and be able to explain filtering criteria, thresholds used, and how both are appropriate for the bank's risks." A director of BSA compliance at a community bank described the stakes: "an examiner will ask me like, how did you determine? Like how did the system determine this? And if I don't have it in writing, I won't be able to defend it."

The explanation has to cover change as well as the current state. A BSA program owner at a credit union said: "I'm going to have to speak intelligently to be able to explain how my system is alerting and if it's changed in that time period, how I ensure that change is sound". A record an examiner can reconstruct shows the alert and the rule or model version that fired it, the data the reviewer saw, the evidence gathered, the recommendation and its reasoning, the analyst's decision, and who confirmed it and when.

What to ask a provider. Pull up a decision from several months ago and show us why it was made, which rule or model version applied, what data the reviewer saw and who approved it.

What a weak answer sounds like. A risk score with no reasons attached, or a reconstruction that only the provider's own staff can produce.

How to test it on your own data. During the test, pick a handful of alerts at random and ask someone who did not work them to write the explanation an examiner would need, using only what the system recorded.

7. Can someone independent validate it?

What it is. Independent validation is a review, by internal or outside parties who did not build the system, of whether its detection logic does what the institution says it does. The FFIEC manual says "the monitoring system's programming methodology and effectiveness should be independently validated to ensure that the models are detecting potentially suspicious activity." That depends on the provider giving validators the logic, the documentation and access to run tests on your data.

The model risk guidance changed this year. On 17 April 2026 the Federal Reserve, OCC and FDIC issued revised model risk management guidance (SR 26-2, OCC Bulletin 2026-13 and FDIC FIL-15-2026), superseding SR 11-7 and SR 21-8, the 2021 interagency statement on model risk management for BSA/AML systems. On products from vendors, it says that institutions "may not receive from the vendor the underlying code, data, or methodology... Nevertheless, the principles of model risk management remain applicable."

Three details of the new guidance shape a validation plan. It excludes "deterministic rule-based processes and software where there are no statistical, economic, or financial theories underpinning their design or use" from its definition of a model, so statistical and machine learning scoring falls inside it and simple rules may not. It "is expected to be most relevant to banking organizations with over $30 billion in total assets", and it "does not set forth enforceable standards or prescriptive requirements". And it places generative and agentic AI outside its scope, leaving their governance to the institution's own risk management practices.

What to ask a provider. What documentation, data and test access will our validators get for each model and rule set, and how is each model monitored after it goes live?

What a weak answer sounds like. A methodology described as proprietary, with nothing offered in its place.

How to test it on your own data. Have your validator, or the firm you would use, request the documentation package during the evaluation and run one test of their own on your data. Validation at the point of switching systems is covered in the buyer's guide linked above.

8. Human sign-off wherever AI is used

What it is. Human sign-off means that wherever the software uses AI, including agents that review alerts or draft dispositions, a person makes the decision and the record shows where. AI can recommend, gather evidence and draft a rationale, but closing an alert, escalating it or filing a SAR stays with an analyst. A chief compliance officer at a community bank put the regulatory reading simply: "I don't think regulators are ready yet for autonomous decisions by agents".

What to ask a provider. Where in each workflow does a person confirm the AI's recommendation, and how does the record show the recommendation, its reasoning and the person who confirmed it?

What a weak answer sounds like. AI that closes alerts on its own, or a record that cannot separate what the AI recommended from what the analyst decided.

How to test it on your own data. Run AI recommendations alongside your analysts on the same alerts, compare the two, and check that no alert in the test was closed or escalated without a recorded human decision.

9. A real test on your own data

What it is. A real test runs the software on your own history and then beside your live process, before you sign. A director of BSA compliance at a community bank gave the reason: "a POC might be very important because you work on data". The agencies' 2018 Joint Statement on Innovative Efforts to Combat Money Laundering and Terrorist Financing says pilot programs "are an important means of testing and validating the effectiveness of innovative approaches" and "should not subject banks to supervisory criticism even if the pilot programs ultimately prove unsuccessful."

Check what a provider means by shadow mode before you rely on it. An AML team member at a consumer prepaid fintech asked: "Is that a true shadow mode where we can test rules and see what the impact would be? Or is that essentially a uat environment where data has to be loaded for us to do any testing?"

What to ask a provider. Will you backtest on our historical alerts, then run in true shadow mode on our live activity, and show us the misses as well as the catches? Which examiners have already seen your system? As a BSA manager at a credit union put it: "I'm just curious like which examiners you've worked with."

What a weak answer sounds like. A demo on the provider's own data, a test environment that needs your data loaded by hand, or results reported only as totals.

How to test it on your own data. Backtest first, then shadow, then compare decisions case by case with your analysts. The full method for evaluating AML transaction monitoring platforms on your own data is covered in a separate guide.

Where Oscilar fits, judged by the same criteria

Oscilar is one platform for risk decisions across onboarding, credit, fraud and AML, and it should be judged on the nine criteria like any other provider. This section uses only what Oscilar's public pages and approved claims support, and it says where Oscilar relies on another tool. Treat it as a starting point for your own questions, not as a verdict.

What Oscilar covers. Oscilar is a unified platform: real-time data fabric, device and behavior intelligence, rules, and case management in one stack, with agents native to it. Agents can run inside the full platform or as a standalone layer on top of an existing stack, which is how a bank can phase a move rather than replace everything at once. For detection, Oscilar's AML for banks page describes monitoring that "combines configurable rules with behavioral baselines, anomaly detection, customer risk, network context, and alert prioritization" (criteria 1 and 2).

Screening. Oscilar does not position itself as the sanctions screener. Screening hits come from a screening tool, and Oscilar's Agent Hub lists a Sanctions Screening agent that provides "Explainable, pre-filled disposition guidance for every sanctions hit." Buyers who want list ingestion and name matching on the same platform should ask that question directly and weigh the answer under the one-platform-or-several decision above.

Alert, case and SAR (criterion 4). Oscilar's case management links alerts and entities, gathers evidence and records rationale and approvals, and its AML for banks page describes SAR preparation and e-filing to FinCEN from pre-populated templates.

Change, explanation and validation (criteria 5 to 7). Oscilar supports backtests, A/B tests and unit tests for risk workflows, and keeps a full audit trail per decision with stored reasoning, and human-in-the-loop by design. Oscilar monitors data, feature and concept drift alongside outcome KPIs by segment, and the platform is designed to fit the interagency model risk management guidance. Oscilar's own page is explicit about the limit: "The bank still owns validation standards, approval authority, and regulatory accountability."

Human sign-off (criterion 8). Oscilar's Agent Hub states: "Agents never autonomously close or escalate alerts — every recommendation is reviewed and confirmed by a human analyst before any action is taken."

A real test (criterion 9). Oscilar structures pre-production evaluation as a four-week 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. A bank in deployment shows 92% agent agreement with its analyst team on alert disposition, and 75% less time per review.

Core data and export (criterion 3). No public claim answers this one for you. Ask Oscilar the same mapping and export questions you ask every provider, and hold the answer to the same test.

Third-party recognition. Chartis named Oscilar to the 2026 FCC50 with category wins for Agentic AI Innovation and Low-Code/No-Code Customization. That is an analyst's view, not the ranking on this page, which ranks no one.

The nine criteria at a glance

Use this scorecard to ask every provider the same questions and score the answers side by side.

Buyers already score systems this way. One digital bank's AML team scores each system it reviews against a fixed set of points before passing the result up; this table gives that kind of review its rows.

Frequently asked questions

What does AML software include?

AML software usually covers four jobs: customer due diligence and risk rating, transaction monitoring, sanctions and PEP screening, and case management and SAR filing. Some products cover one job and some platforms cover all four. Each job leaves a record an examiner will read, so judge the record as well as the detection.

Which rules and guidance apply when a financial institution chooses AML software?

The FFIEC BSA/AML Examination Manual sets expectations for monitoring, alert management and SAR decisions, and OFAC's 2019 Framework sets them for sanctions compliance. Model risk guidance now comes from SR 26-2 and its OCC and FDIC equivalents, issued 17 April 2026. Vendor selection falls under the 2023 interagency guidance on third-party relationships, which remains in force while a replacement proposed on 11 September 2026 is open for comment. FinCEN's AML/CFT program rule is still a proposal, not a final rule.

How do you test AML software on your own data before you buy?

Backtest the software on your historical alerts, then run it in true shadow mode on live activity beside your current process, and compare its decisions with your analysts' case by case. Confirm that shadow mode runs on live data rather than a test environment loaded by hand. Ask to see the misses as well as the catches.

Does SR 11-7 still apply to AML software?

No. SR 11-7 was superseded on 17 April 2026 by SR 26-2, with OCC Bulletin 2026-13 and FDIC FIL-15-2026, which also replaced the 2021 interagency statement on model risk for BSA/AML systems. Vendor models are still the institution's to validate under the new guidance, while deterministic rule-based processes fall outside its definition of a model and generative and agentic AI are outside its scope.

What is the best AML software for banks?

The best AML software for a bank is the one that covers that bank's own risk profile, keeps the customer view consistent across components, and leaves a record its examiners can follow. No list can rank that in advance. Score each provider against the same disclosed criteria, then test the shortlist on your own data before you sign.

Is Oscilar an AML software provider?

Yes. Oscilar is one platform for onboarding, credit, fraud and AML risk decisions, with transaction monitoring, case management, SAR e-filing and agents that recommend while a human analyst decides. Sanctions screening hits come from a screening tool, and Oscilar's agents work on those hits. Judge Oscilar against the same nine criteria as any other provider.