The price of AML software is not the cost of operating it. Two products with similar licence fees can create very different costs once implementation, integrations, alert volumes, manual investigation, upgrades and internal support are included.
For that reason, AML technology should be compared using total cost of ownership rather than a single annual subscription or licence number.
A practical AML TCO formula
Total cost of ownership = licence/subscription + implementation + integration + infrastructure + internal operations + alert/investigation workload + change/support + assurance/testing + exit/migration.
1. Software licence or subscription
Understand the pricing unit. It may be based on users, customers, checks, transaction volumes, modules, environments, data sources or a combination. Ask what happens when volumes grow and which capabilities are optional.
2. Implementation
Include configuration, workshops, data mapping, migration, testing, training and production cutover. For complex institutions, internal staff time can be as significant as external implementation fees.
3. Integration
Estimate the cost to connect onboarding, customer master data, transaction feeds, case-management tools, identity providers, reporting and data warehouses. Include ongoing maintenance when source systems change.
4. Infrastructure and environments
For on-premise solutions, include hardware or cloud infrastructure, databases, operating systems, backups, monitoring, disaster recovery and environment management. For SaaS, identify what is included in the subscription and what still requires client-side infrastructure.
5. Analyst workload
This is often the hidden cost. Estimate the volume of screening matches and transaction alerts, average review time, escalation rate and number of staff involved. A cheaper system that creates materially more false positives can be more expensive operationally.
6. Tuning and change
AML settings and scenarios require controlled review. Include the time required to analyse performance, change thresholds, test new configurations, document approvals and monitor the result.
7. Support and upgrades
Understand the support model, release process, upgrade charges and whether major versions or new modules require projects. SaaS and on-premise systems allocate this cost differently rather than eliminating it.
8. Control testing and assurance
Budget for the people and data required to test whether the system is operating effectively. FSA material on effectiveness validation reinforces that institutions need to understand and explain whether AML/CFT frameworks work in practice.
9. Exit and migration
Include data export, historical evidence, parallel running, contract termination, archive requirements and the effort needed to move rules or workflows to another platform. Exit cost is easy to ignore at purchase and expensive to discover later.
Model the cost of operational noise
False positives and unnecessary review activity should be represented explicitly in the TCO model. For example, estimate annual alert or match volumes, multiply by average review time and loaded analyst cost, then run sensitivity scenarios. Even without publishing any vendor price, this shows how a change in alert quality can outweigh a modest difference in licence fee.
Apply the same logic to manual re-keying, duplicated evidence collection and reconciliation between systems. If a platform removes a hand-off, quantify the activity that disappears. If it adds another hand-off, include that cost.
Build a five-year model
| Cost category | Year 1 | Years 2 to 5 question |
|---|---|---|
| Software | Initial annual licence/subscription | How does pricing change with growth? |
| Implementation | Configuration, migration, training | Are recurring professional services required? |
| Integration | Build and test interfaces | What maintenance is expected? |
| Operations | Analyst and administrator time | Will alert/customer volumes grow? |
| Infrastructure | Environment setup where applicable | What ongoing hosting/DR cost remains? |
| Change & assurance | Initial tuning and validation | How frequently will reviews/testing occur? |
| Exit | Usually low in Year 1 | What would it cost to retrieve evidence and migrate? |
Ask vendors to expose the assumptions behind the price
- Which volumes are included and what happens above them?
- Are screening data sources or modules priced separately?
- Are test, disaster-recovery or non-production environments included?
- Which implementation activities are included versus client responsibility?
- Are upgrades and major releases included?
- What support tier is assumed?
- What data-export or termination assistance is chargeable?
Do not monetise benefits that cannot be evidenced
A business case can include reduced manual work, faster onboarding or lower false-positive volumes only where the assumptions are credible and measurable. Avoid presenting “AI efficiency” or automation as a guaranteed saving without testing it against your own data.
Compare cost per control outcome
The most useful question is not “which vendor is cheapest?” It is “what does it cost to operate the required control to the standard we need?” That keeps price in context with risk coverage, evidence and operational quality.
Use this TCO model to compare MemberCheck with your current AML technology using your actual customer, alert and integration volumes.
