What this is, and what it is deliberately not
Bankautomation does not score transactions for money laundering risk, does not replace a transaction monitoring system, and does not make compliance determinations. It automates the operational workflow around the program you already run, and it makes that operation evidenced.
That distinction matters commercially as well as legally. Detection platforms are expensive, tuned over months and owned by a model risk process. The queue of work they produce, and the queue produced by periodic KYC refresh, is usually managed on the side in a way nobody would defend in an exam.
The four workflows that carry the program
Step 01
KYC refresh queues
Periodic review populations built from risk rating and last review date, assigned, aged and escalated, with the completed file attached to the customer rather than to an inbox.
Step 02
Alert and case triage
Alerts from your monitoring system arrive as work items with a disposition path, a required evidence set and a maker-checker step before closure.
Step 03
Investigation evidence
Documents, screenshots, decisions and rationale collected against the case as it is worked, so packaging is not a separate exercise at the end.
Step 04
Program cadence
Risk assessment updates, policy reviews, training and testing tracked as scheduled obligations with owners, due dates and completion evidence.
Defensible means reproducible
An examiner does not ask whether your program is good. They ask you to show how a specific decision was made on a specific day: what the analyst saw, what rule or policy applied, who approved the disposition, and whether the same case today would be handled the same way.
- Every disposition carries its rationale, its evidence set and its approver.
- Policy and rule versions are recorded against the case as it was worked, not as they stand now.
- Segregation of duties between the analyst and the approver is enforced by role, not by convention.
- Aging and escalation are visible while the case is open, which is when it can still be fixed.
- Export produces the case file whole, in one action, for a period or a population.
Where automation legitimately helps, and where it does not
| Task | Automate | Keep human |
|---|---|---|
| Building the refresh population | Yes, from risk rating and review dates | The risk rating methodology itself |
| Gathering standard documents | Yes, request, track and chase | Assessing whether the document is adequate |
| Routing and aging | Yes, by risk, entity type and workload | The decision to escalate a specific case |
| Drafting the case narrative | Assist, from the structured facts | Approving what it says |
| Disposition | Never | Always, with an approver |
| Filing a report to the authority | Never | Always, by your compliance function |
The risk assessment, and why it should not be an annual document
An enterprise-wide risk assessment is usually produced once a year, circulated, approved and then filed, and for the following eleven months the operating reality moves without it. New products launch, a channel changes its customer mix, a correspondent relationship opens in a jurisdiction that was not in scope when the document was written. The controls described in the assessment stay as written, and the gap is discovered either by an examiner or by an incident.
The practical alternative is not a more frequent document. It is connecting the assessment to the things that already change: the segments generating alerts, the refresh population by risk rating, the disposition patterns by product and channel. When those are reported continuously, the annual document becomes a summary of a picture the programme already has, and a material change in the operating environment surfaces when it happens rather than at the next review cycle. The workflow mechanics behind that reporting are covered in compliance workflow automation.
The evidence question, asked five ways
Almost every examination finding in this area reduces to one question asked in different forms: can you demonstrate that the program operated the way the policy says it does. A program that records work as it happens answers all five of the questions below from the system. A program that writes work up afterwards answers them from a reconstruction, and reconstructions attract findings because they look like reconstructions.
- Show me this case, worked, with the evidence the analyst actually had at the time.
- Show me who approved this disposition and confirm they did not also propose it.
- Show me the customers due for review this month and how many are overdue.
- Show me which policy version and which threshold applied on the date of the decision.
- Show me what independent testing found and what happened to each finding.
The risk assessment as configuration, not a document
An institution risk assessment justifies the shape of the whole program: which customers get reviewed how often, which alerts get priority, what enhanced due diligence means in practice. When it exists only as an annual document, the program drifts away from it quietly, and the drift is invisible until somebody compares the two. When its conclusions are expressed as configuration, a change to a risk rating changes the refresh population by itself, and the gap between the stated program and the operating program stays closed without anybody policing it.
Why the boundary belongs on a product page
That boundary is worth stating on a product page because the category is full of language that blurs it. A workflow tool that claims to reduce false positives is describing something a detection model does. A vendor that offers to remove a human from a disposition is offering a control finding rather than an efficiency. The honest scope is narrower and considerably more useful: make the work consistent, make it owned, make it aged, and make it provable.
Where a language model belongs, and where it does not
Drafting from structured facts is a legitimate use, and it saves real time on narratives and summaries, provided the facts are shown next to the draft and a named person edits and approves the result. Extraction from a document is legitimate on the same terms: the extracted value is a suggestion a person confirms. Deciding is not a legitimate use, at any confidence level, because a determination has to be defensible by someone who can explain the reasoning, and a probabilistic output is not a reason.
The related pages go deeper by role: KYC automation for onboarding and refresh, BSA AML monitoring workflow for alert triage, and AML software for banks for the vendor selection conversation.
Questions about aml compliance software
Does this file SARs for us?
No. It helps assemble and evidence the case that supports a decision, and it records who decided. The determination and any filing remain with your compliance function, as they must.
Do you replace our transaction monitoring system?
No. Detection stays with your monitoring platform. This is the workflow, evidence and cadence layer around the alerts it produces, which is usually where the manual effort and the exam risk actually sit.
Can it work alongside a case management module we already own?
Yes, and sometimes it should not be bought at all if that module is genuinely being used end to end. The test is simple: can you export one complete case file, with approvals and evidence, in one action?
How do you handle model risk questions?
There is no risk model here to validate. A language model drafts narrative text from structured facts that a person approves, and no automated decision changes a customer outcome on its own.
What about false positive rates?
That is a property of your detection tuning, not of this product, and any vendor promising to cut false positives from the workflow layer is selling you something it cannot deliver.