Three kinds of automation, in the order to try them

Payments operations teams often come at automation from the most advanced end: a model to triage the exception queue, a bot to feed it, and only much later a question about why half the items were in the queue at all. We would work in the opposite order, and in our view the first stage alone often changes the size of the problem.

There are three kinds of automation available to an operations team. They differ in cost, and more importantly in how much they depend on the process underneath being sound.

1. Remove steps and fix the rules in systems you already have

   Change the matching tolerance, routing rule or approval threshold that creates needless work, and delete steps that exist because of a problem solved years ago. This needs someone who understands the configuration and has permission to change it, and very little budget.

2. Add workflow tools, integration and RPA

   Move data between systems automatically and route cases to the right queue when they are created. Use RPA where there is no API, knowing that a bot breaks whenever the screen it reads changes.

3. Bring in machine learning or AI models for judgment calls

   Classify dispute reasons, or suggest the likely cause of an unmatched item. These need a clean history to learn from and a human review step for the cases where the model is unsure.

The first kind is the least glamorous, and it rarely comes with a vendor or a business case, so it gets skipped. Typical examples: a reconciliation rule that only matches on exact amount and reference, so every one-cent FX rounding difference becomes an exception; a KYC rule that sends every application with a PO box to manual review, set up for a concern nobody can now explain; two approvals of the same refund, one in the case tool and one in the payment system, because the systems were connected after the process was designed; a daily report three people prepare and nobody opens.

Finding these takes a sample. Pull a couple of hundred items from the queue and tag each with the reason it is there. The tags cluster, and some of the clusters turn out to be rules nobody would defend if asked. The copy-paste steps that grow around the spreadsheet that runs your operation are the natural target for the second kind, once the first has done its work.

Why skipping ahead fails

Automating a step that shouldn't exist makes it permanent. Once a bot performs the pointless step, the step has a maintenance cost, an owner and a change process, and removing it has become a project with a budget.

Putting RPA on top of bad rules moves the noise faster. If a matching rule creates 1,000 false exceptions a day, a bot that copies them into the case tool gives your analysts 1,000 well-formatted false exceptions a day. The dashboard may even look better for a while, since items are created and assigned more quickly.

Models have the same problem in a different form. A model's training data is the history of decisions made under the current rules, so if a third of the queue is rounding differences, the model gets very good at recognizing rounding differences, which a tolerance rule would have handled for nothing. The accuracy figures look impressive and the operation hasn't changed much.

Each kind also needs more specialist upkeep than the one before. The operations or platform team can maintain a configuration change. A bot needs a developer or a vendor every time the screen changes. A model needs monitoring, periodic retraining and an explanation your sponsor bank will accept when it asks how a decision was made. You want the expensive kinds working on the smallest possible pile of hard items.

One queue, worked through in order

Say an e-money firm's reconciliation exception queue receives 1,500 items a day, and a sample shows that 40 percent are timing differences that clear the next day and 25 percent are FX rounding within a cent. These figures are illustrative. A next-day automatic rematch and a small tolerance rule, approved by finance, take out about 975 items, leaving around 525 a day.

For those 525, the sample shows analysts spending most of their handling time looking up the transaction in the processor portal and then in the ledger. An integration that attaches both records to the case when it is created cuts that time substantially, and it is ordinary, well-understood work for an integration team.

Only then is a model worth discussing, perhaps one that suggests a likely cause for each remaining item. The history is cleaner by now, because the easy categories have gone, and you can compare the model's suggestions against several months of analysts' decisions. You can also price it properly. With a unit cost per item, built the way we described in measuring operational cost per transaction, and a queue about a third of its original size, the business case becomes arithmetic.

Before approving any automation budget, ask for that sample: a couple of hundred items from the queue, each tagged with the reason it is there. It takes an analyst two or three days, and it tells you which of the three kinds of work you need and how much of each.

Discuss your operations