How to evaluate AML and transaction monitoring software

Begin with the problem you need the platform to solve

A platform selection should begin with documented risks and operating requirements. AML transaction monitoring, sanctions screening, customer due diligence and fraud prevention can interact, but they do not have identical objectives or decision processes. Buying a product that performs one of these well does not prove it covers the others.

FATF’s report on new technologies for AML/CFT describes opportunities to improve effectiveness and efficiency while examining implementation challenges. It emphasises responsible adoption rather than treating technology as a substitute for a sound AML/CFT framework. [1] The procurement process below is practical implementation guidance, not legal advice. Confirm applicable obligations with qualified compliance and legal advisers in every relevant jurisdiction.

1. Write a use-case and coverage register

Ask compliance, fraud operations, technology and customer-service teams to document the problems they need to investigate. Record the product, customer segment, payment channel, relevant risk, available data and intended response for each use case. Separate a rule that creates an investigation case from a control that blocks a transaction in real time.

For a proposed detection scenario, identify what evidence an investigator would need to decide whether to escalate. A scenario that generates a high volume of alerts without enough context may simply transfer cost to the investigation team. Agree success criteria before seeing vendors’ demonstrations, and record which requirements are essential, desirable or outside the first release.

2. Treat data readiness as a selection criterion

Prepare a data dictionary covering identifiers, timestamps, amounts, currencies, transaction status, customer attributes and relationships between accounts. Test for missing values, inconsistent formats and delayed feeds. Decide which system is authoritative when two sources disagree.

Ask each vendor to explain how it handles corrections, reversals, duplicate records, late-arriving transactions and changes to customer profiles. In a controlled pilot, introduce representative data problems and observe the result. The aim is to find whether the system rejects, flags or silently misinterprets them. Assign an owner to remediate each issue; a vendor cannot infer reliable context from fields the organisation does not collect.

3. Run a fair, documented pilot

Give shortlisted vendors equivalent requirements and a controlled dataset appropriate for sharing. Use de-identified or synthetic records where feasible, with privacy and contractual controls for any sensitive data. Include ordinary activity, known historical cases where usable, and designed scenarios that challenge the intended detection logic.

Keep tuning data separate from evaluation data where practical. If a system has been repeatedly adjusted to the same examples, a good result may show familiarity with that dataset rather than broader performance. Record the test period, assumptions, exclusions and scenario coverage alongside any metrics.

Be careful with claims about false positives and detection rates. Where reliable labels do not exist, you may be able to measure alert volume and investigation outcomes without proving how many suspicious cases were missed. Ask vendors to state the evidence and limitations behind every performance claim.

4. Inspect the investigator’s working day

Follow an alert from creation through triage, investigation, escalation and closure. Can the investigator see the relevant transactions, customer history and prior decisions without switching repeatedly between tools? Can a reviewer understand why an alert was generated and which configuration produced it?

• Check role-based access, assignment queues, escalation and approval steps.
• Test how notes, attachments and decision reasons are retained and exported.
• Ask how changes to rules or models are approved, versioned and audited.
• Confirm the handling of reopened cases and corrections to source records.

5. Cost the implementation and ongoing operation

Build a total-cost view that includes licences, data ingestion, integration, migration, tuning, analyst training, support and change requests. Clarify whether usage is priced by transaction, customer, account, data volume or another measure. Model growth scenarios using the same assumptions for every supplier.

Ask who will own feed monitoring, alert tuning, release testing and incident escalation after launch. Set acceptance criteria for data completeness, processing timeliness, investigation workflows and operational support. Include an exit plan: what data, rules, case records and audit history can be exported, in what format, and at what cost?

Make the decision traceable

Use a weighted scorecard, but keep material gaps visible outside the total. A low price should not hide a missing essential capability. Record the evidence for each score, the people involved in the assessment and any conditions attached to selection. Treat unproven sales claims as questions to resolve before signing.

Evo’s AML & Fraud Detection Consulting service helps organisations match solutions to business needs and coordinate implementation. Bring your use-case register, integration constraints and operating model to the discussion. The useful outcome is a defensible vendor choice and delivery plan, with compliance responsibility and operational ownership clearly assigned.

Frequently asked questions