What automating a payment run actually involves

Three times, a custodian bank checked the Financial Services Register to see whether a wealth manager on its platform held the permissions it needed. Three times the answer was that it did not. The accounts were migrated and opened anyway.

That is the finding at the centre of the Final Notice the FCA issued to CACEIS Bank’s UK branch on 19 June 2026. The regulator recorded that the bank identified the permissions problem before a 2020 migration, again in March 2021, and again on a further check in December 2022, and that on each occasion no other step was taken to ensure that the accounts were only made operational once the position was proved. Credits into the client accounts concerned exceeded £314m over the period. The FCA imposed a public censure rather than a fine, having taken account of the bank’s cooperation and its agreement to pay £31,714,068 for the benefit of investors, and it noted that no criticism was made of any person other than the bank itself.

Nothing in that story is about payments technology. The check ran. The check returned the right answer. The answer never reached the process it was supposed to gate.

It is also about as close as the public record gets to a description of how money moves inside a regulated wealth business. No British wealth manager has published an account of automating its payment runs. Firms that have done it do not describe their control design, their auditors’ reports are not published, and the FCA publishes failures rather than successes. What does exist is the material any such project is bound by. The client money rules fix what the process has to produce. The final notices show what happens when it produces nothing. The Payment Systems Regulator’s directions set out what the rails will and will not check on the way out. Those constrain the design more tightly than any vendor case study, and unlike a case study they can be read by whoever has to sign the thing off.

The payment run is a client money process wearing a treasury costume

In a wealth manager, a payment run is the batch that moves money out at the end of a cycle: fee sweeps, adviser charges, income distributions, withdrawals to clients’ nominated accounts, transfers to custodians. Operations teams describe it as a treasury task. The rulebook does not.

Money received from or for a client has to reach a client bank account fast. Where a firm takes in client money as cash, a cheque or another payable order, the FCA requires it to be paid in promptly, and no later than on the business day after it receives the money. Records have to distinguish one client’s money from another’s and from the firm’s own, at any time and without delay, and they have to be maintained so that they can serve as an audit trail.

Then there is the daily obligation that dominates the operating rhythm of every firm in this business. An internal client money reconciliation must be performed each business day, using the values in the firm’s own ledgers rather than the values on the bank statements, and the firm must record the date it carried out the process, the actions it took, and the outcome of its calculation of the client money requirement against the client money resource. Those records are kept for five years.

So the automation problem is not “how do we send more payments faster”. It is: how do we move money in a way that leaves behind an evidenced, reproducible account of why each item was released, that a skilled person could reconstruct in three years without asking anyone who was there.

The rulebook also decides the shape of the working day, which is the constraint most automation designs discover late. A firm on the normal approach to segregation uses its daily reconciliation to check whether its client money resource at the close of business on the previous business day equalled its requirement on that day. A firm on the alternative approach uses it to work out how much needs to be segregated now, against yesterday’s requirement. Those are different calculations with different timing, and an automation built for one does not become an automation for the other by changing a parameter. Anyone specifying a payment run has to know which approach the firm operates before they draw a single box, and a surprising number of specifications do not say.

What is genuinely automatable, and what only looks it

Four things in a payment run automate well, because they are deterministic and their outputs are checkable.

Assembly is one. Pulling the payable items from the ledger, applying the fee schedule, netting where netting is permitted and producing a file is arithmetic with a paper trail. Validation is the second: sort code and account number format, mandate currency, duplicate detection against the previous cycle, threshold checks against the client’s own instruction. The third is the reconciliation itself, which is a comparison of two datasets against a defined method and is closer to a report than a decision. The fourth is evidence capture, which is the part most projects treat as a by-product and which the rulebook treats as the deliverable.

What does not automate is the release. Somebody has to be accountable for the moment the file leaves the building, and that accountability has to be attached to a person who could have stopped it and did not. The CACEIS notice is instructive precisely because the failure sits in the seam between an automated check and a human process. A control that produces a finding nobody is obliged to act on is not a control. It is a log entry.

The design rule that follows is unfashionable and worth stating plainly. Every automated check in a payment run should have exactly one of two outcomes: it passes, or it blocks. A check whose failure produces an alert into a queue has been downgraded to advice, and advice is what accumulated for over two years in the case above, where the FCA recorded a first transaction monitoring alert and fifteen subsequent ones without sufficient remediating steps.

The rails have their own rules, and one of them exempts you

British payment runs go out over Faster Payments or CHAPS, and both now sit inside a consumer protection regime that changes the economics of getting a payment wrong.

Since 7 October 2024, reimbursement for authorised push payment fraud has been mandatory for payments between UK accounts over those two systems. The Payment Systems Regulator’s published position is that most victims are reimbursed within 5 business days of making your claim, with a longstop of 35 business days where firms stop the clock to gather information, an optional excess of up to £100 that cannot be applied to vulnerable consumers, and a maximum claim of £85,000. What the consumer page does not say is who bears it. The PSR’s consolidated policy statement does: receiving PSPs must pay sending PSPs 50% of the reimbursement that the sending firm paid to the consumer, subject to stated limits. That is the part that changed behaviour, because the receiving institution now has a financial interest in the payment being correct.

Confirmation of Payee is the control that sits in front of that risk. Under Specific Direction 17 the first group of payment service providers had to implement it by 31 October 2023 and the second group by 31 October 2024, and the PSR states plainly that the deadlines are legally binding.

Here is the detail that matters for anyone automating a batch. The direction carries exemptions, and one of them covers an indirect payment service provider sending payments in batch files to its sponsor at the end of the day, where the customer is not present. That is a bulk payment, and it is exempted. In other words, the single largest name-checking control in British payments has a hole in it shaped exactly like a payment run.

That is not an argument against automating the run. It is an argument for putting the name check somewhere else in your own process, at the point the mandate is created or amended, rather than assuming the rails will catch a misdirected item on the way out. Firms that discovered this after a change of bank details went unchallenged have generally rebuilt the mandate process rather than the payment process.

The reimbursement rules push in the same direction. A wealth manager sitting behind a bank does not receive that reimbursement bill directly, but it will receive the consequences of it, in the form of a bank that asks harder questions about batch files, mandate changes and new payee patterns than it did five years ago. Automating the run without automating the evidence that supports it is a way of generating more questions and fewer answers.

What breaks these systems, in practice

Three things, none of them the payment engine.

The first is the mandate. Every serious misdirection incident in this business traces back to a change of bank details that was accepted through a channel with weaker controls than the payment itself. An automated run executes whatever the mandate says with perfect fidelity, at scale, on time. That is the risk, not the mitigation.

The second is the exception path. A run of ten thousand items will produce a handful that fail validation, and the handling of those items is almost always manual, urgent and performed by whoever is available. The controls that apply to the automated ninety-nine per cent frequently do not apply to the one per cent that a person pushed through at half past four. Any review of an automated payment process should start with the exceptions, because that is where the residual risk concentrated when the rest of it was industrialised.

The third is change. A fee schedule is amended, a new share class is added, a custodian changes its file format. Each of those is a change to the rules the run applies, and each will be made by someone who does not think of themselves as changing a payment system. Whether that change is tested before it moves money is a question about release management rather than about payments, and it is the question the firm will be asked afterwards.

What a good implementation looks like on paper

The test is not whether the run completes. It is whether the firm can answer four questions about any single item in it, months later, from records rather than recollection.

Which client’s money was this, and where was it held immediately before it moved. What rule authorised the payment, and where is that rule written down. Which checks ran, what did they return, and what would have happened had any of them failed. Who released it, and what were they looking at when they did.

A firm that can answer those four has automated a payment run. A firm that can only answer the first two has automated a file transfer and has moved its control environment into the heads of the operations team, where it will stay until one of them leaves.

They are also the reason no benchmark exists. Nobody publishes how long a run takes, what share of items drop into the exception path, or how many mandate amendments survive a second check. Anyone quoting a market figure for those is estimating. What is knowable is what a supervisor will ask for, and that is written down.

The same structure applies wherever software sits between an obligation and a transaction, which is why the run cost of these systems tends to be dominated by assurance rather than licences, a pattern set out in our intelligent automation guide. Foundry4 covers the wider category in its AI and automation section, and the pattern of what survives in regulated back offices is set out in the five RPA applications that lasted.

The uncomfortable implication of the CACEIS notice is that the firm had the control. It ran it. It filed the result. What it did not have was a rule saying that a particular answer stopped the next step from happening, and no amount of automation supplies that. It has to be written by someone who is prepared to be told no by their own system.