Never pay on changed bank details until a named member of staff has phoned the client on a number held before the request, and a second person has confirmed the call on the file. Do not trust a voice, an email or a link as proof. A cloned voice can pass a casual call, so the procedure must depend on records, not recognition.
Most public guidance on this topic warns homebuyers to be careful. This tutorial is for the firm: the written steps, who does what, what the client is told at the start, and what happens when a call feels wrong. Copy the structure and replace the examples with your own systems and thresholds.
What the fraud looks like when it reaches a conveyancing file
The pattern is simple. Someone gets into an email account, or builds a convincing copy of one, watches a transaction, and at a key moment sends new payment details to the firm or the client. The message arrives on the right thread, in the right tone, and often just before a payment is due. Variants worth training for:
- The client's message to the firm. "I am changing the account for the sale proceeds. Please use the details below."
- The firm's message to the client. A copy of your email, with your account details swapped, arrives at the buyer a day before completion.
- The other side's message. The seller's firm appears to ask for the deposit to go to a new account.
- The phone call. A caller who sounds like the client, perhaps a cloned voice built from a short clip of audio posted online, asks you to confirm the new account verbally.
- The video call. A face and voice produced by software joins a short call to approve a change.
What these share is urgency and a request to change a destination for money. That gives the firm a rule with no exceptions: any change to where money goes, from anyone, triggers the call-back. The firm does not need to judge whether the email "feels right". It runs the procedure every time.
The procedure, step by step
Write this as a numbered policy of one page. Each step has an owner and leaves a record on the file.
- Stop and log. The person who receives a request to change bank details does not reply to it. They log it on the matter, mark the payment as "held", and tell the fee earner. Nothing is paid or promised.
- Find the known number. The case handler looks up the client's phone number from the file as it stood before the request: the instruction form, the signed terms, the identity record. They do not take a number from the message that asked for the change, from its signature or from a link in it.
- Call and verify. The case handler phones the known number. They say who they are, ask the client to confirm they requested a change, and ask for the new account details to be read out. They write them down while the client speaks, rather than reading them from the email.
- Ask a record-based question. A question that only the client could answer from your files, not from public sources or the email thread. Examples: the amount of the deposit paid at the start, the date of the first meeting, the name of the person who attended the signing. Avoid questions with answers found on social media or in a hacked mailbox.
- Dual verification. A second person, not the first, reviews the file note and the details read out, and compares them against what the email said. If the second person calls the client on the same known number to confirm, even better for high-value payments.
- Test the account. Check that the account name matches the client or the expected payee, using an account-name confirmation service if your bank offers one. For large sums, a small test payment first can be agreed with the client in the call.
- Record. A structured file note: date and time, who called, the number used and where it came from, the question asked and the answer, the second person's name and sign-off, and the new details as read out.
- Release. Only then is the payment cleared for release, and ideally by a third person who processes the payment and reads the note.
Add one sentence to the top of the policy: "The call-back cannot be skipped because the client is travelling, the deadline is today, or a partner says it is fine." Every successful fraud on a firm involves someone who had a good reason to skip a step.
The call-back note, filled in
Illustrative. Here is how the record might read for a sale where the client emailed new proceeds details on a Tuesday afternoon:
MATTER: [number] DATE/TIME: [date], 15:42
EVENT: Email from client address requesting new account for sale proceeds.
STATUS: Payment held. No reply sent to the email.
KNOWN NUMBER USED: [number] from instruction form signed [date].
CALLER: [case handler] CLIENT SPOKE TO: yes
CHALLENGE ASKED: Date of first meeting. ANSWER: matched file.
NEW DETAILS READ OUT BY CLIENT: account details matched email: yes/no.
ACCOUNT NAME CHECK: matched client's name: yes/no.
SECOND PERSON: [name], reviewed note [date], 16:05. Approved / Not approved.
RELEASE: processed by [name] after approval.
If any "yes/no" is a no, the payment stays held, the fee earner is told immediately, and the firm follows its fraud-reporting process, including telling the bank and the relevant regulator or reporting body where required.

The Complete Excel Course with AI Integration
From formulas and pivot tables to Power Query, DAX, VBA and AI with Copilot, ChatGPT and Claude — hands-on from the first lesson.
By Sagnik Bhattacharya and Virginia Thorn, Primetime Emmy Award winner
Buy nowDual verification without slowing every file
Firms resist two-person rules because they fear delay. The honest answer is that the second check takes five minutes and happens only when bank details change, which on a typical file is rare. A practical split:
| Situation | Required checks |
|---|---|
| Details unchanged since onboarding | Normal payment approval |
| Any change of destination account | Call-back by case handler, review by second person |
| Change within 48 hours of completion | As above, plus fee earner or partner sign-off and account-name check |
| Change requested through a new channel (new email, new number) | As above, plus a fresh identity check of the person asking |
| Payment above the firm's set limit | All of the above, plus a test payment where possible |
Set the limit yourself with your insurer or compliance adviser in the room, and write it down. The rule that matters is that the person asking cannot be the person approving, and no one can both receive the change request and release the payment.
What to say to the client at the start
The best fraud control is a client who expects the call-back and is suspicious of anything else. Send a short message at instruction, repeat it in the first status update, and again a week before completion. Ask AI to draft versions in different lengths, then approve the wording.
Subject: How we will ask you about bank details
Hi [first name],
One important point about your purchase. Criminals try to intercept
property payments by sending fake emails with new bank details.
Our rule: we will never change our account details by email, and we will
never accept changed details from you by email alone. If you ever receive
an email, text or call, even from our own address, asking you to pay a
different account, do not pay. Phone us on [number] from your own contact
list and ask for [case handler].
If you ask us to change where we send your money, we will always phone you
on the number you gave us at the start. Please do not be surprised or
annoyed by that call; it is how we protect you.
[your name]
Check one detail when the AI drafts this: it must not invent a phone number, and it must not say "never" about something the firm sometimes does. If your firm does send account details by secure portal, say that, so the message is accurate and not just alarming.
The client script for the call-back itself
A short script avoids two failures: staff who are too apologetic to ask a hard question, and staff who accidentally give away the answer. Here is an illustrative version.
- "Hello, this is [first name] from [firm]. Is it a good moment to confirm something about your payment?"
- "We received a message asking us to change the account for your funds. Did you send that?"
- "Thank you. Could you read the new account details to me, slowly, and I will write them down?"
- "For security, could you tell me [record-based question]?"
- "I will send nothing to the new account until a colleague has reviewed my note, which usually takes about [time]. I will phone you back on this number when it is done."
Never read the details back from the email and ask "is that right?", because a person under pressure or a cloned voice will say yes. Never tell the client the answer to the record-based question to nudge them. If they cannot answer, say you will have the fee earner call them, and hold the payment.
Voice-clone and deepfake risk: what changes in the procedure
AI voice tools can copy a voice from a short recording, and video tools can make a face say words it never said. Neither makes the call-back worthless, but they make three assumptions unsafe.
- "I recognise the voice." Recognition proves nothing. Rely on the known number and on records.
- "They know the matter details." A criminal in a hacked mailbox knows the thread. Ask questions that are not in emails.
- "We saw them on video." A video call is useful but is not identity proof on its own. For a change request, a call to the known number takes precedence.
Add signals that suggest manipulation, and train staff to treat them as a reason to pause: pressure to act now, resistance to a call-back ("I am in a meeting, just send it"), a request to keep the matter private, an unusual call-in number, a voice that sounds slightly flat or repeats phrases, or a caller who cannot be interrupted. None proves fraud. Together they justify telling the fee earner.
A realistic scene, as an illustration: the case handler phones the known number the day before completion. The call connects and a voice that sounds like the client says, quickly, that they are boarding a flight and the new account is urgent. The case handler follows the script, asks the record-based question, and the voice answers vaguely and tries to move on. The handler says the payment stays held until the fee earner speaks to the client in person, ends the call politely and records every detail. Later the client confirms by a separate channel that they never called. The procedure worked because it did not depend on how the voice sounded.
Consider a family code word, agreed face to face or by letter at instruction, for clients who are high-value or vulnerable. It is optional, and it must never be sent by email. For deepfake and call-back wording in a sister sector, the call-back script for real estate wire fraud shows a similar pattern, and the tutorial on AI voice cloning rules explains the technology side.
Where AI helps the firm defend itself
AI is a useful lookout, not a gatekeeper. Three uses fit a small firm:
- Flagging unusual requests. Rules or AI features in your email security can flag messages that mention "new account", "changed details" or "urgent" from an address that is not on the matter. The flag adds a banner and alerts the fee earner.
- Checking senders. Compare a sender's domain with the client's usual one, catching "rn" in place of "m" or an extra word. Many email security tools do this; a case handler can also paste a suspicious address (not the message itself) into an approved tool and ask which characters differ from the known one.
- Drafting training and warnings. Generate quiz scenarios, update the client message, and write a one-page reminder for the team after each new variant appears.
Do not use AI to decide whether a caller is genuine, and do not paste client emails or account numbers into a general chat tool. Keep the data inside approved systems. When assessing vendors, ask about audit trails and fraud flags using the questions in the conveyancing software demo tutorial.
Testing the procedure before a criminal does
A procedure that nobody has tried is a document, not a control. Run a drill each quarter, with the partner's agreement and no warning to the case handlers. Send an email from a lookalike address, to a case handler, in the voice of a client on a live (or mock) file: "I have changed banks, please use these details for completion." Observe what happens.
| Outcome | What it tells you |
|---|---|
| Case handler holds payment and calls the known number | Procedure understood |
| Case handler replies to the email asking "is this right?" | Retrain; the reply tells the attacker the address is live |
| Case handler calls the number in the email | The most common failure; train on "known number" until it sticks |
| Second person approves without checking | Dual verification is a signature, not a check |
| Payment processor releases funds without seeing the note | Control gap in the payment step |
Run the drill without blame. The aim is to find the step where a busy person on a Friday afternoon would take a shortcut, and make that step harder to skip. Also drill the unhappy path: what does the team do if the client says they never sent the request? That should trigger an incident routine: stop all payments on the file, change passwords, tell the bank, tell the insurer, tell the regulator or reporting body if required, and preserve the emails.
Three more variations to rehearse with the team
Staff handle the standard case well and stumble on the variations, so rehearse these in a ten-minute team meeting. Each is illustrative.
The change that comes from the other side. The seller's firm emails to say the deposit should go to a different account because of a bank merger. Your known contact for that firm is the switchboard number from their letterhead on the first correspondence, or a number you verify independently from a professional directory, never a number in the new email. The call goes to a named person at that firm, and the same note is completed. Say it plainly to the other side: "Our policy is to confirm every change of account by phone."
The client who changes the number and the account together. An email says "I have a new phone and a new bank". Both changes are red flags at once, because the number you would normally call back is the thing being replaced. Treat it as a fresh identity check: ask the client to attend in person or complete a video call with identity documents shown to a person, then compare against the original onboarding record. Delay the payment until that is done.
The friendly insider. A message appears to come from a colleague or partner: "Please release the completion funds to this account, I have already spoken to the client." Internal instructions to move money get the same call-back as external ones, to the colleague on a known internal number. Attackers use an inside-looking name because staff rarely challenge their own firm. Make it a stated rule that challenging such a message is expected and never counts against anyone.
Responding when fraud is suspected or has happened
Speed matters. Write the incident steps next to the call-back policy so nobody has to improvise.
- Stop any pending payments on the matter and any related matters for the same client.
- Phone the bank's fraud line at once, with the payment details, and ask for a recall request. Note the time.
- Tell the fee earner and the partner responsible for compliance. Tell the insurer according to the policy conditions, which often set a short notice period.
- Secure the mailboxes involved: reset passwords, end active sessions, and check inbox rules. Microsoft's security guidance describes attackers adding forwarding rules to a mailbox after stealing a password, so look for any rule nobody on the team created.
- Tell the client by phone, on a verified number, and put a warning on the file that their email may be compromised.
- Report to the regulator or reporting body where required, and keep a timeline.
Practise the first two steps. A firm that knows the bank's fraud number and has the payment reference to hand loses minutes, not hours. The onboarding tutorial shows where to capture the known contact details and a second contact method at the start, which is what makes the call-back possible later.
Keeping the policy alive
Review the procedure whenever a new variant appears in the news or from your bank, after every drill, and after any near miss. Keep a short log of near misses, because a flagged request that turned out genuine still teaches something about how clients phrase changes. Put a one-line reminder in the payment system, if it supports one: "Bank details changed? Check the call-back note." And give new starters the policy on their first day, with a five-minute walk through the filled-in note above. A control the whole firm can recite is stronger than a longer document nobody opens.
Questions about call-backs and voice-clone fraud
Which number do we call back on?
Only a number you already held before the request, such as the one captured at onboarding or on the client's signed instruction. Never use a number in the email or message that asked for the change, and never one supplied alongside new bank details. If no earlier number exists, use a different verified channel, not the new one.
Can a voice-clone call pass a call-back?
A cloned voice can fool a call, which is why the call-back must not rely on recognising a voice. Add a challenge only the real person could answer from your own records, use two staff members, and treat any pressure or urgency as a reason to slow down, not speed up.
Does AI help detect fraud here?
It can help spot patterns, such as a sudden change of bank details, mismatched account names or an email domain that differs by one letter, and it can draft client warnings. It cannot confirm that a person is genuine. The decision rests on the human call-back and the written record.
What if the client is abroad or unreachable?
Wait. Delay is cheaper than a lost deposit. Agree at onboarding a second contact method and a named alternate contact. If neither works, the payment holds until a verified conversation happens, and the fee earner tells the other side why in writing.
Further reads
- AI for UK Conveyancers: Reports on Title and the Checks You Keep — The checks a firm keeps even when AI helps.
- Best AI for Conveyancing: ID Checks, Searches and Client Chasing — AI help with ID, searches and chasing, with limits.
- AI Tools for Landlords: Messages, Lease Checks and Application Fraud — Spot document and application fraud in lettings.
- AI Readiness Checklist for Accountants, Solicitors, Consultants — Check policies are ready before adopting more AI.
- How Small Law Firms Use AI to Answer Client Status Questions — Keep clients on known channels with regular updates.
- AI for Small Law Firms: What to Automate First — Decide what to automate without weakening controls.
- AI Answering Service for Title Companies: Cost and Status-Call Rules — Closing-status calls, wire requests and identity checks: what an AI answering service may handle for a title company, and what it costs a month.
- AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.
Sources: general payment-verification and anti-fraud practice for client money; check your regulator's current warnings and your insurer's conditions.