Before the Payment Leaves: A Client Money Control That Survives a Busy Friday
Photo: Marketingifs, CC BY-SA 4.0, via Wikimedia Commons
A payment instruction arrives late on a Friday afternoon. The client is known, the amount is familiar and the fee-earner wants it released before the bank cut-off. The bank details, however, are new. In that moment, a firm's client money controls are tested not by the wording of its policy but by whether the person at the keyboard has a routine that is quick enough to follow and clear enough to trust.
Dual authorisation is often described as a two-signature rule. In practice, it is a sequence of small decisions: who may instruct, who may release, what must be checked before release and what the file should show afterwards. For UK firms that move client money, the objective is not to slow down every payment. It is to make the exceptional payment visible without making ordinary payments unworkable.
Start with the payment routes, not the policy
A control designed only around the bank mandate will miss the places where payments actually begin. Before changing thresholds, map the routes by which money leaves the firm: online banking, Faster Payments, CHAPS, international transfers, standing payments to counsel or experts, and any card or direct debit arrangements. Note who can initiate, who can approve and who can release. Check whether the same person can perform more than one step, whether credentials are shared and whether temporary cover has created informal workarounds.
The map should be short enough to be read by a busy partner and specific enough to be tested. It should also identify the payments that carry the greatest risk: new payees, changes to existing bank details, payments to third parties, payments outside the UK and any instruction that arrives with unusual urgency. These are the points at which a second pair of eyes earns its place.
Design thresholds around risk, not only value
A common weakness is to set a single high-value threshold and treat everything below it as routine. Fraud and error rarely respect that line. A modest payment to a changed account can be more dangerous than a large payment to a long-standing payee. A better design uses bands.
Low-value, repetitive payments to established payees may be covered by a pre-approved schedule reviewed at fixed intervals. Mid-range payments might require one authoriser plus a confirmation of payee check. Higher-value payments, new payees and any change of bank details should require two independent authorisers, with the second able to see the supporting instruction and the callback record. The person who initiates should not be the person who releases, and the two authorisations should use separate credentials rather than a shared login.
Thresholds should be reviewed against actual payment data rather than assumed. A firm that rarely makes large payments may still need a low trigger for changed bank details. A firm with high volumes of small disbursements may need a scheduled approval route so that the control does not become a bottleneck. The aim is proportionate friction, not uniform delay.
The callback rule: a known number, not a number in the email
The most important operational rule is simple: never verify changed bank details using a telephone number supplied in the instruction that announced the change. Use a number already held on the client file, in the engagement letter, in the CRM record or in previous signed correspondence. If the only available number sits in the email, the payment should wait until an independent source can be found.
A call-back should be more than a request to confirm the account number. Ask the client to confirm the payee name and the reason for the change, and compare that with the instruction. Record the number used, its source, the time of the call and the person spoken to. Where confirmation of payee is available, retain the result. If the client cannot be reached, the payment should be held and escalated rather than released on the basis of an email trail alone.
This rule protects against authorised push payment fraud, but it also protects against ordinary error. A client may have changed banks legitimately; the control is not an accusation. It is a routine check that applies to everyone, which makes it easier to enforce and less likely to be treated as an insult.
Make the control fast enough to be used
A control that adds a day to every payment will be routed around. Firms should publish a short service standard for approvals during business hours, name deputies for each authoriser and set a clear escalation route for out-of-hours requests. Where a payment is genuinely urgent, the answer should be a faster controlled process, not an exemption from control.
A one-page protocol helps. It should state who can authorise which band, what the second authoriser must see, how to obtain a known number and what to do when verification fails. It should also set cut-off times so that fee-earners know when a request must arrive to be processed the same day. The test is whether a new joiner could follow it during a busy afternoon without needing to ask a partner.
The record that shows judgement, not routine
Regulators and insurers rarely ask only whether a firm had a dual-authorisation policy. They ask how it operated. A payment control log should show the date, amount, payee, initiator, authorisers and the verification method. For changed bank details, it should also show the source of the callback number, the person contacted and any discrepancy. A tick box is weak evidence. A short note explaining why the check was done and what it confirmed is stronger.
Exceptions should be recorded, not hidden. If a callback could not be completed, the log should show who approved the hold, what alternative evidence was considered and when the payment was released. Over time, the exception report becomes a useful management tool: it shows where pressure is building and whether the protocol needs adjustment.
Thirty days to embed the routine
In the first week, map payment routes, pull a sample of recent instructions and agree risk bands. In the second, draft the one-page protocol and the payment log, and build a known-number directory from client files. In the third, brief fee-earners and finance staff, test the routine on new payees and changed details, and confirm that bank mandate permissions match the design. In the fourth, sample the results, review exceptions and report the position to the risk committee or management board.
The evidence pack should include the protocol, the threshold table, the log, the training record and a sample of completed checks. That pack is useful for an insurer, a regulator or a new head of finance. More importantly, it gives the firm a control it can operate on a Friday afternoon, when the pressure is real and the payment is waiting.