AML software for banks: what to ask before you sign anything

First, separate the three products you are being sold

Questions that reveal the product

• Show me one complete case file exported in one action, including approvals, attachments and the policy version in force at the time.
• Who changes a rule, a threshold or a queue routing, and what does the approval look like?
• What happens when your service is unavailable during our business day, and what does the SLA actually promise?
• Which parts of the workflow can be configured by our team, and which require your professional services?
• How is segregation of duties enforced between the analyst and the approver?
• What is the data residency, and can we choose it?
• What does the implementation actually consist of, week by week, and who is doing it?

Claims to push back on

• Guaranteed false positive reduction. Nobody can promise that without your data and your tuning.
• Fully automated AML. Determinations require a human. A vendor claiming otherwise is describing a compliance risk, not a feature.
• Certified compliant. Software is not compliant. Your program is, or is not. Ask what controls the product supports, not what badge it wears.
• Pre-built integrations with every core. Ask which ones are in production at a bank of your size, and ask to speak to them.
• Implementation in days. Ask what day one means: a login, or a queue your team is actually working.

What an implementation really consists of

Implementation timelines in this category are quoted in weeks and delivered in quarters, and the gap is almost never the software. It is the decisions: which alert types get which required evidence, what the approval chain is for each disposition, how the refresh cadence maps to risk ratings, and who owns each queue. Those are your decisions, and no vendor can make them faster than your own governance allows.

1. 01Ask for the week by week plan and identify which weeks are yours rather than theirs.
2. 02Ask what has to be true before day one: a data feed, a role model, a signed policy, a nominated approver.
3. 03Ask what day one means concretely. A login is not the same as a queue your analysts are working.
4. 04Ask which configuration your team can change afterwards and which requires their professional services, because that ratio is your running cost.

Designing a pilot that proves something

A pilot that runs on sample data in the vendor's environment proves that the product exists. A pilot worth running takes one real queue, for a defined period, with your own evidence requirements enforced, and it is judged against criteria written down before it starts.

• One queue, chosen because it is painful rather than because it is tidy.
• Success criteria agreed in writing before the first day, by the person who owns the control.
• A comparison against how the same period was handled before, item by item, not as a headline number.
• A named exit date, so a pilot cannot quietly become the operating model without a decision.
• One exam style test at the end: pull a case from the middle of the period and time how long the complete file takes to produce.

Cost beyond the licence

The subscription is the visible number and rarely the largest one. Ask early about the cost of adding a queue or an entity, whether professional services are required for routine configuration changes, what data egress or export costs look like if you leave, and what your own team will spend maintaining feeds and role mappings. A product that is cheap to licence and expensive to change is a familiar shape in this category, and it is the shape that becomes hard to leave.

The triage problem

Alert volume is a function of tuning, and tuning is slow to change because every change is a model risk conversation. In the meantime the queue arrives every morning. The operational questions are which alerts get looked at first, how consistently similar alerts are dispositioned, and whether the reasoning survives contact with an examiner nine months later.

What the workflow layer does with an alert

Consistency is the control examiners test

Two analysts, two similar alerts, two different outcomes, no recorded reason. That is the finding. Required evidence sets, a shared disposition vocabulary and approval separation make similar cases look similar, and make the exceptions visible on purpose rather than by accident.

The scope line: triage, not detection

Detection decides that an alert should exist. Triage decides what happens to it. These are different products with different risks, and conflating them is how banks end up buying a workflow tool to fix a tuning problem, or tuning a model to fix a backlog caused by duplicates.

This page is about triage only. Nothing here scores a transaction, changes a threshold or asserts that an alert should or should not have fired. What it does is take the alerts your monitoring platform produces and make the work on them consistent, owned, aged and provable.

When an alert should become a case

Alerts and cases are different objects and treating them as one is a common source of both backlog and inconsistency. An alert is a signal about a period of activity. A case is an investigation about a customer, and it can gather several alerts, a history and a set of documents. Promoting an alert to a case too early creates administrative overhead on work that will be closed in ten minutes. Promoting too late means an analyst is looking at one fragment of a pattern with no way to record what they learned.

• Define the promotion rule per alert type rather than leaving it to individual judgement.
• Let a case absorb later alerts on the same customer, so the investigation accumulates rather than restarting.
• Carry the prior disposition onto the case, because a repeat alert with a known explanation is a different piece of work.
• Age the case from the earliest alert it contains, not from the day it was opened, or promotion resets the clock.

Grouping, which is the largest single improvement available

Monitoring platforms alert per rule and per period, so a single pattern of activity can produce several alerts on one customer over a few weeks. Worked separately they consume several times the effort and produce dispositions that can disagree with each other, which is a finding in itself. Grouping alerts by customer and by pattern, and presenting the prior disposition alongside the new alert, reduces both the volume and the inconsistency without touching detection at all.

The required evidence set

The most reliable way to make dispositions consistent is not more training, it is defining what must be present before a disposition can be recorded, per alert type, and having the system refuse an incomplete one. It sounds bureaucratic and it has the opposite effect in practice: analysts stop deciding how much is enough on every case, and the review of a closed case takes minutes because the file is always the same shape.

• The activity that triggered the alert, in the form the analyst saw it.
• The customer context: expected activity, risk rating, and the reason for the rating.
• Prior alerts on this customer and how each was disposed.
• The analyst's reasoning, written at the time rather than reconstructed.
• The approver, who must not be the proposer, and the date of approval.

Case packaging, and the honest limit

When a case proceeds to a report, the supporting file has to be assembled: the activity, the accounts, the customer information, the analysis and the chronology. Assembling that file from records already captured is logistics and can be automated safely. Drafting a first version of the narrative from those structured facts is also reasonable, for a person to edit. The determination itself, and the filing, are decisions by named individuals at the institution and no part of this product performs them or recommends performing them.

The program context around this queue is on AML compliance software, and the customer side of the same operation is KYC automation.

Questions about aml software for banks