The Second Channel: A Verification Discipline for Changed Payment Instructions
Payment instructions arrive quietly. A supplier emails a revised sort code, a client asks for an invoice to be settled to a new account, or a longstanding contact sends a short note saying the finance team has changed bank. In most cases the request is genuine. In a minority it is the opening move in an authorised push payment fraud, and the firm that acts on the request without independent verification may find that the money has moved before anyone has asked a sensible question.
This Article Directory UK guide sets out a practical control for UK professional firms: a second-channel verification discipline for any change to bank details before funds are released. It is not a substitute for legal or regulatory advice, nor for the bank’s own safeguards. It is an operational routine that can be documented, taught and reviewed.
Why the request channel is not enough
The central weakness in many payment-change processes is that the verification happens inside the same channel that delivered the instruction. A request arrives by email, so someone replies to the email to confirm. A message arrives through a portal, so the confirmation is sent through the portal. That may prove that the same account is still active. It does not prove that the person making the request is the person the firm believes them to be.
Confirmation of Payee has an important role, but it checks whether the account name and details match at the receiving bank. It does not authenticate the requester. Nor does a familiar email address, a copied signature block or a previous pattern of correspondence provide reliable assurance. The control needs a separate route to a contact point the firm already held before the request arrived.
The standard in outline
For any change to a client or supplier bank account, the firm should apply four steps before the change is made live.
First, pause the payment. No transfer, remittance or scheduling should proceed on the strength of the request alone.
Second, retrieve a telephone number from an independent source already held by the firm, such as the client or supplier master record, a signed engagement letter, a previously verified contact list or a known accounts payable contact. The number supplied in the request itself should not be used for verification.
Third, speak to a known individual at that number and confirm the change using a short, consistent script. A call-back is stronger than an email because it introduces voice contact and reduces the opportunity for a written impersonation to be sustained.
Fourth, record the verification in a payment-change log before the bank details are amended in the finance system. The log is not bureaucracy for its own sake. It is the evidence that the control operated, and it is the material a firm will need if a payment is later disputed or an incident is reviewed.
A concise call-back script
The script should be short enough to be used consistently and specific enough to prevent a vague confirmation. A suitable structure is:
- Identify yourself, your firm and the purpose of the call.
- Confirm you are speaking to a named individual at the client or supplier.
- State that you have received a request to change bank details and that you are verifying it before updating your records.
- Read back the new account name, sort code and account number exactly as received.
- Ask the individual to confirm that the instruction is genuine and that the details are correct.
- Ask whether any other payment instructions or contact details have changed at the same time.
- Record the time of the call, the number used, the person spoken to and the outcome.
If the person cannot confirm the details, or if there is any uncertainty, the change should not be made. The matter should be escalated under the firm’s incident or fraud procedure. A call that feels rushed, evasive or unusual is itself a reason to pause.
The evidence log
The payment-change log should be simple but complete. Useful fields include the date and time of the request, the requester’s name and apparent contact details, the original bank details, the proposed new details, the independent number used for verification, the source of that number, the person who made the call-back, the person spoken to, the outcome, any discrepancies and the escalation reference if applicable.
Retention should follow the firm’s general records policy and any relevant regulatory obligations. The log should be accessible to more than one person. A control that exists only in one individual’s inbox is not a firm-wide control.
Training and escalation
Training should cover the purpose of the control, the risk it addresses and the specific behaviours expected. New starters should be walked through the script and the log before they are given authority to amend payment records. Existing staff should have a short refresher at least annually, with scenario-based discussion covering urgency, secrecy, changed contact details and requests that appear to come from a senior person.
Escalation triggers should be explicit. These include a mismatch between the request and the independent record, reluctance to speak by telephone, pressure for immediate payment, a request to use a new number for the call-back, a change of contact details arriving at the same time as a change of bank details, and any language or voice anomaly that causes doubt. The payment should be frozen while the matter is reviewed. The firm’s finance lead and, where appropriate, its risk or compliance function should be informed. External reporting and bank notification should follow the firm’s incident procedure.
Reviewing near-misses
A near-miss is valuable evidence. If a call-back reveals that a request was fraudulent, or if a payment is stopped because the verification felt wrong, the firm should record it and review it. The review should ask what signal was present, whether the script elicited it, how quickly the payment was frozen and whether the log captured enough detail. The aim is not to assign blame but to improve the routine.
A monthly sample of payment-change log entries can test whether the independent number was genuinely independent, whether the script was followed and whether escalations were handled consistently. Over time, patterns may emerge: a particular type of request, a recurring supplier contact or a gap in training.
Cover when the usual person is away
Controls often fail during annual leave, sickness or staff turnover. The firm should therefore designate a deputy for payment-change verification and ensure that the log, the contact records and the escalation route are available to more than one person. The script should sit with the procedure, not in an individual’s memory. Authority limits should be clear, and no one should be able to amend bank details and release a payment without an independent check.
In 2026, payment fraud remains a practical risk for UK firms of every size. The second-channel discipline is not elaborate, but it must be applied consistently. A short call to a number the firm already trusted, recorded in a log and supported by a clear escalation route, is a modest control with a disproportionate effect.