What a bot actually automates
A bot automates a sequence of clicks and keystrokes against a user interface. It has no concept of a value date, a correspondent, an FX rate source or a settlement cycle. It knows that a field is at a position on a screen and that a number should be typed into it. Everything the bot appears to understand about banking lives in the head of the person who recorded it.
That works, sometimes for years, and it is why RPA got into so many banks. It also means the automation is coupled to the most volatile layer of the stack, and that the business logic is undocumented outside the recording.
The three costs that show up later
- 01Maintenance. Every core upgrade, every screen change, every new field is a bot to re-record and re-test. The team that was automated away becomes a team that maintains bots.
- 02Exceptions. A bot stops when reality does not match the recording. What happens next is almost always a human, an email and a spreadsheet, which is the process you were replacing.
- 03Evidence. Bot logs record clicks. An auditor asks what business decision was made, by whom, under which rule. A click log cannot answer that.
Bank-native automation compared
| Dimension | RPA bot | Bankautomation |
|---|---|---|
| Interface | The user interface of another system | The data: statement, ledger and settlement files |
| Domain knowledge | In the recording, and in a person | In the product: value date, references, FX, settlement |
| When reality differs | The bot stops or does the wrong thing | A classified exception with an owner and an age |
| Change control | Re-record and re-test the bot | A versioned rule change under maker-checker |
| Evidence | Click and step logs | Business decisions, approvals and attachments |
| Breaks on a core upgrade | Frequently | Only if the export format itself changes |
Where RPA still earns its place
This is not an argument that bots are useless. For a stable internal system with no API and a low volume, repetitive task, a bot is a perfectly rational answer, and ripping one out that works is a waste of money. The argument is narrower: reconciliation, exception handling and compliance workflow are data problems with a domain model, and automating them by pretending to be a user is the expensive way to solve them.
The trouble is that neither of those conditions holds for long in a bank. Core systems get patched, vendors redesign screens, regulatory changes add fields, and each of those is a bot outage rather than a configuration change. The cost is not the licence, it is a maintenance obligation that grows with the estate and never shrinks.
The specific reasons bots break in reconciliation work
- No data model. A bot copies characters. It has no concept of a value date, an FX rate source or a charge bearer, so it cannot decide whether a difference is expected.
- No exception state. When something does not fit, a bot stops and emails a person. The item then lives in an inbox with no age and no owner.
- Brittle by construction. A field that moves twenty pixels, an extra confirmation dialog or a slower response breaks the script, and the failure is silent until somebody notices the output missing.
- Weak evidence. A bot log records that a step ran. An auditor asks who decided, on what basis, under which rule version, and a step log answers none of that.
- Credential and access risk. A bot holds credentials to several systems and acts as a user, which makes segregation of duties considerably harder to demonstrate.
Where the maintenance cost actually accumulates
| Event | Effect on a bot | Effect on a configured reconciliation |
|---|---|---|
| Core system upgrade | Scripts re-recorded and retested | No change, the file format is unchanged |
| New source or account | A new bot, built and maintained | Configuration: format, tolerances, owner |
| Tolerance change | Code change and release | An approved change in the interface, versioned |
| Audit request | Step logs plus a manual reconstruction | A filtered export of work already recorded |
| Staff turnover | Knowledge of scripts leaves with the builder | Rules are visible and readable in the product |
A migration path that does not require a big bang
Nobody should switch off a working estate to make an architectural point. The sequence that works is to take one process line where the exception volume is highest, run the configured reconciliation alongside the bot for two or three closes, compare break populations rather than headline counts, and retire the bot for that line only when the comparison is clean. Repeat by line. The bots covering genuinely stable processes can be left alone until they break on their own schedule, at which point replacing rather than repairing them is an easy decision to justify.
If bots are your incumbent, the practical migration is one process line at a time. Start where the exception volume is highest, usually bank reconciliation, and leave the stable bots alone until they break on their own schedule.
Where a bot is still the right answer
This page argues against screen-scraping bots for reconciliation and exception work, and it would be dishonest to extend that into a claim that RPA is never appropriate. A bot is a reasonable tool when a system genuinely has no export and no interface, when the task is short-lived and a permanent integration would cost more than the problem, or when a migration needs a bridge for a defined period with a date on which it is switched off.
The distinction that matters is between a bridge and a foundation. A bot built as a bridge has an owner, an end date and a known replacement. A bot that quietly becomes the way a daily control runs is a foundation, and it is a foundation that fails whenever a screen moves, with no audit trail explaining what it did on the day it failed. The failure mode is not that the automation stops. It is that it appears to continue while producing nothing, which is considerably worse for a control.
- Reasonable: a genuinely closed system, a defined bridging period, a task nobody depends on for evidence.
- Unreasonable: a daily control, anything an auditor will sample, anything where the record of what happened matters as much as the outcome.
- The test: if the bot stopped working silently this morning, how long until somebody noticed, and what would you show for the days in between.
Questions about robotic process automation in banking
We already own RPA licences. Does that change the maths?
It changes the licence line, not the maintenance line, and maintenance is where the cost usually is. Compare the fully loaded cost of keeping the bots current against a product where the banking logic is maintained by the vendor.
Can Bankautomation trigger our existing bots?
Exceptions and outcomes are exportable and can be picked up by other systems, including an RPA platform, so a bot can keep doing the keystroke work in a system with no API while the decision and the evidence live here.
Is this just RPA with a different name?
No. There is no screen recording and no user interface simulation. The product reads bank data formats, applies versioned matching rules and manages exceptions as workflow objects.
What about agentic AI replacing both?
A model that can click is still coupled to the screen, and a model that decides without an approval step is a control problem. The useful role for a model here is drafting classifications and narratives from structured facts, with a person approving.