Your insurer is protecting you from the wrong threat: a note on email and client information for Australian lawyers

If you handle client funds, your professional indemnity insurer probably has a policy about how to verify bank account details before transferring money. The standard version reads something like: when a client emails you bank details, call them on a known number and read the details back to confirm they have not been altered in transit.

The policy has been around long enough that most practitioners follow it without thinking about what it actually protects against. It is worth thinking about, because the threat model it addresses is narrow and the threats it does not address are much larger.

I am not a lawyer. I run a hosting business and I deal with the operational reality of how email actually works between two parties. A client of mine, who is a solicitor, mentioned this policy in passing during a support conversation last week. He was asking whether my secure information transfer system could accept bank details. The answer was yes, but the conversation surfaced something worth writing about: the read-back policy is protecting against the wrong attack.

What the policy actually defends against

The threat the read-back policy addresses is: an attacker intercepts an email in transit, modifies the bank account number to one they control, and forwards the modified email to the recipient. The recipient transfers funds to the attacker. The read-back call is meant to catch the modification, because the attacker cannot also modify what the original sender says on a phone call.

This is a real scenario. It has occurred in conveyancing fraud cases. It is not the most common scenario.

What the policy does not defend against

There are four common scenarios for how a fraudulent transfer of client funds can happen via email. The read-back policy meaningfully addresses one of them.

One: the sender’s email account is compromised. An attacker gains access to the client’s mailbox, either by phishing the client’s credentials, exploiting a weak password, or compromising the device. The attacker reads the active correspondence with the lawyer, understands the matter, identifies the upcoming transaction, and sends an email from inside the client’s trusted account with their own bank details. The email is signed off correctly because the attacker has access to the email signature, previous correspondence, and the established tone of the relationship.

The recipient lawyer calls the phone number in the email signature to verify. The number reaches the attacker, who has had time to update the signature, or who simply takes the call because they now have access to the associated mobile phone or account recovery channels. The read-back check passes. The funds are transferred to the attacker.

The only mitigation that catches this is calling a phone number obtained outside the email channel. In practice, most read-back calls are made to the number in the email signature, because that is the number the recipient has. The check is performed but provides no protection.

This is the most common pattern in modern conveyancing fraud. The attacker does not modify a legitimate email in transit. The attacker becomes the sender, using the sender’s own account, sending what looks like a normal update to a normal transaction. Every check the recipient performs against the apparent sender confirms the apparent sender, because the apparent sender is who the attacker now is.

Two: the email is intercepted in transit and read, but not modified. Email between mail servers is opportunistically encrypted. STARTTLS is used when both servers support it, but if one server doesn’t, or pretends not to in a downgrade attack, the message travels in cleartext. The sender has no visibility into the path the email took or whether each hop was encrypted. The receiving lawyer’s server might show that the final hop was secure, but the previous hops are invisible.

A passive attacker who reads bank details from an unencrypted email hop does not need to modify anything to cause harm. They have enough information to attempt fraud against the client’s bank directly, to inform a later social engineering attack, or to sell the details. The read-back check does nothing here because the email arrived unmodified.

This is the scenario I told my client about. The policy assumes the threat is modification. The far more common threat is interception. Email is a two-party system, and even if both parties use TLS on their own connections, the path between them passes through mail servers that may not. Saying “I use TLS for my email” describes how you connect to your mail provider. It says nothing about how that mail actually travels to the recipient.

Three: the recipient’s email account is compromised. An attacker accesses the lawyer’s mailbox after the email is delivered. They read the bank details at rest, along with months or years of client correspondence about active matters. The read-back call may have already occurred and confirmed nothing, because the data was correct when received and is now being read by someone it was not addressed to.

This is the attack the read-back policy most spectacularly fails to address, because the policy is built around the assumption that the unit of risk is the individual transaction. It is not. The unit of risk is the lawyer’s entire inbox.

A compromised email account does not expose one client’s bank details. It exposes every client’s bank details that have ever passed through that account, every identity document, every settlement statement, every conveyancing matter currently in flight, every piece of privileged correspondence going back as long as the lawyer has held the account. For a sole practitioner who has been in practice for fifteen years, that is potentially thousands of clients, tens of thousands of sensitive documents, and a comprehensive map of which transactions are currently active, who the parties are, and when the funds are due to move.

This is the kind of access attackers actively look for. A law firm inbox is not just a personal mailbox; it is a curated archive of high-value information about people who are about to transfer significant sums of money on predictable timelines. The economics of phishing a lawyer’s credentials are very different from the economics of phishing a random consumer’s credentials, because the payoff is orders of magnitude higher. There is no reasonable expectation that an attacker who gains access to a law firm inbox will only use what they find there to defraud one client. They will work through the archive, identify the matters with the largest transactions, and target those clients.

Multiple Australian conveyancing fraud cases in recent years have followed exactly this pattern. The fraud is not perpetrated by intercepting an email in transit and modifying it. It is perpetrated by compromising one party’s email account (sometimes the lawyer’s, sometimes the buyer’s, sometimes the agent’s), reading the active correspondence to understand the transaction, and then sending fraudulent updated bank details from inside the trusted account. The read-back call performed against the apparent sender’s phone number, listed in the apparent sender’s email signature, confirms nothing because the apparent sender is the attacker.

The mitigation is not in the message channel. It is in account security: multi-factor authentication on every email account, monitoring for unusual access patterns, fast revocation if compromise is suspected, and limiting what sensitive information sits in the email archive in the first place. If bank details, identity documents, and other regulated personal information are routed through secure channels rather than email, then a compromised inbox exposes correspondence but not the systemic treasure chest the inbox would otherwise contain.

Four: the entire transaction is fraudulent. The bank details are correct, in the sense that they match what the sender intended to send. The sender is a party to a fraud. The read-back call confirms the numbers match what the sender said. It cannot confirm that the sender is who they claim to be, that the underlying transaction is legitimate, or that the funds will not disappear after transfer.

This is a know-your-client problem rather than a technical one, but it is worth naming because it falls entirely outside the read-back policy’s scope.

”What if I just delete the emails after I’ve used them?”

When lawyers first absorb the inbox-as-archive problem, the natural response is reasonable and intuitive: delete the sensitive emails after they have served their purpose. If the inbox is the treasure chest, empty the chest. The remaining attack surface shrinks to whatever is currently in flight, which is much smaller than the cumulative archive of every transaction the firm has ever handled.

This is a partial mitigation at best, and worth understanding why.

First, deletion in modern email systems is not what it appears to be. When you delete an email in Office 365, Google Workspace, or any equivalent enterprise email platform, the message moves to a deleted-items folder, where it remains for some period. After that, depending on the platform’s retention settings, it moves to a longer-term recovery system. After that, depending on the platform’s retention settings, it moves to a backup tier. The lawyer who has clicked delete has performed a user-facing action that does not directly map to “this data is no longer recoverable from anywhere.” Recoverability is the entire point of how enterprise email is designed. It is supposed to be hard to lose mail.

Second, enterprise email is distributed by design. When you send an email through Office 365, copies exist on Microsoft’s servers across multiple data centres for redundancy and compliance reasons. Some of those copies are explicitly designated as backups; some are operational replicas; some are intermediate caches that are supposed to be transient but may persist longer than expected. The lawyer cannot enumerate where their email actually exists at any given moment, because the platform deliberately abstracts that from them. Deletion through the lawyer’s interface affects the lawyer’s view of the data. It does not necessarily affect every replica, snapshot, backup, or audit log the provider maintains.

Third, even if every controlled copy of the email is fully purged, the data has already left the lawyer’s system. It travelled through internet infrastructure to get there. It may have been logged, archived, captured, or read at any number of points along the way that are entirely outside the lawyer’s control. Deleting the email after the fact does not retrieve the data from wherever else it may have ended up. If the message was readable in transit, the integrity of the message after delivery is irrelevant. The damage was already done before the message reached the lawyer’s inbox.

Fourth, and most importantly: deletion as a strategy depends on remembering to delete. It requires every member of the firm to perform a manual hygiene action consistently, over years, across thousands of messages, with no errors. The first time someone forgets, or is in a hurry, or leaves the firm without cleaning out their mailbox, the strategy fails. Human behaviour at scale is not a reliable security control.

The correct response to the inbox-as-archive problem is not to delete the archive afterwards. It is to never put the sensitive information into the archive in the first place. If bank details, identity documents, and other regulated personal information are transmitted through secure channels rather than through email, then the email archive contains correspondence about transactions but does not contain the high-value data that makes the archive a target. The lawyer can keep their email history, which is valuable for case management and professional record-keeping, without the email history being the systemic exposure that justifies the attacker’s effort.

This is the conceptual shift the post is really arguing for: stop using email as a vehicle for the information that must not be exposed, and the question of how to protect that information from interception, modification, post-delivery compromise, and accidental retention becomes much simpler. Email returns to being correspondence. Sensitive data lives somewhere appropriate for sensitive data. The two are kept separate by design.

What the lawyer is actually trying to do

Step back from the policy for a moment and look at what the read-back call is really attempting. The lawyer has received a piece of data. They want to confirm that the data they received is the same data the sender intended to send. They use their voice to read the numbers out, and the client confirms each digit, and the lawyer knows that the numbers match what the client said.

This is an integrity check. The lawyer is doing manually, with their voice and the client’s ear, what computers have been doing automatically for decades. It is called a checksum, and in modern systems it is implemented with a cryptographic hash function like SHA-256.

The read-back call is a checksum performed by voice. Computers have done this automatically, with cryptographic certainty, for decades.

The way a cryptographic checksum works is straightforward in principle. The sender computes a short, fixed-length fingerprint of the data they are sending. They transmit the data and the fingerprint through separate channels, or they sign the fingerprint with a key only they hold. The recipient computes their own fingerprint of the data they received, compares it to the sender’s fingerprint, and if the two match, the data is the same data the sender sent. If they do not match, even by a single bit, the recipient knows the data was modified in transit.

This is what the lawyer is trying to do with their voice. It is also what every reasonable file transfer system, every secure messaging app, and every code distribution channel on the internet does as a matter of course, without human effort, in microseconds, with cryptographic certainty.

The reason this matters for the read-back policy is that the manual version is enormously weaker than the automated version, and yet only the manual version is required. A computer comparing two SHA-256 hashes will detect any modification, however subtle, with effective certainty. A human reading numbers over the phone will catch obvious changes but is prone to fatigue, distraction, and confirmation bias. Lawyers reading back long strings of digits in their fifth verification call of the day are not as reliable at this task as they imagine they are.

More importantly, the manual integrity check still requires the data to be transmitted insecurely first. The hash function does its job after the file has already arrived. The lawyer’s voice does its job after the email has already been read by anyone who happened to be reading email in transit. The check confirms integrity but does not provide confidentiality, and confidentiality is the thing that matters when the data is bank details and the threat is interception.

Using a secure transmission channel solves both problems at once. The data is encrypted in transit, so interception fails. The channel uses cryptographic integrity protection automatically, so modification is detected without human effort. The read-back call, if still performed, becomes a sanity check on top of the cryptographic guarantees rather than the only line of defence.

The correct mitigation

The actual problem is that email is being used to transmit information for which email is not appropriate. The mitigation is to move the sensitive transmission to a channel that is end-to-end controlled, with authentication of both parties and confirmed encryption.

In practical terms, this means one of the following.

A one-time secret link. The sender uses a service that generates a single-use URL containing an encrypted secret. The link is sent through email, but the secret it points to is held on a server with TLS to the recipient, decrypts only on access, and self-destructs after one read. If the link is intercepted in transit, the attacker can use it once, but the recipient will then see that the secret is no longer available and will know the transmission was compromised. There are several products that provide this service. The one I use with my own customers is password.link, which is free for occasional use and inexpensive for higher volumes. There are alternatives if password.link does not suit. The point is the pattern, not the specific tool.

Encrypted file transfer with out-of-band password. The sender encrypts the file containing the bank details with a strong passphrase. The encrypted file is sent by email. The passphrase is communicated through a separate channel: a phone call, an SMS, an in-person meeting. An attacker who intercepts the email cannot decrypt the file without the passphrase. An attacker who intercepts the SMS cannot read the file without the email. Compromising both channels simultaneously is materially harder than compromising email alone.

Secure document portal. The lawyer’s firm provides a client portal with authenticated access and TLS throughout. The client uploads the bank details to the portal. The lawyer logs in to retrieve them. No sensitive information ever travels via email. This is the option most large firms use and most small firms have not yet implemented. It is the most robust, the most expensive to set up, and increasingly the expected baseline for handling client funds.

The verification call, after the secure transmission, becomes meaningful. The lawyer reads the bank details back over a phone call placed to a number obtained from outside the email channel, ideally one the firm has held since onboarding the client. The check is now verifying that the secure transmission delivered the right data, not that an inherently insecure transmission was not tampered with. This is a different and stronger check.

Why this matters under Australian law

Lawyers handling client funds operate under multiple overlapping obligations. The professional ones (Legal Profession Uniform Law, state-based equivalents, professional conduct rules, trust account regulations) require reasonable care in handling client information and money. The privacy ones (Privacy Act 1988, Australian Privacy Principles, Notifiable Data Breaches scheme) require protection of personal information and notification when serious breaches occur.

The Notifiable Data Breaches scheme is the one most likely to surface a problem. An unauthorised access to or disclosure of personal information, where serious harm is likely, must be notified to the Office of the Australian Information Commissioner and to affected individuals. Bank details qualify as personal information capable of causing serious harm. If a client’s bank details are intercepted because they were transmitted in cleartext, the firm may have a notifiable breach on its hands even if no actual fraud occurs. The mere fact of unauthorised disclosure can be enough.

A lawyer who relies on the read-back policy is not protected from this exposure. The policy addresses modification in transit. The exposure is unauthorised disclosure in transit. These are different problems with different mitigations.

The insurer’s policy is not bad faith. It is residue from a period when most fraud cases involved active modification, and the read-back check was an acceptable mitigation against that specific attack. The threat landscape has shifted. Passive interception is now more common than active modification, and the regulatory framework has changed to make passive interception a notifiable event. The policy needs updating to match.

What I would do

If I were running a small Australian law firm today, I would:

A final note on whose advice to take

I am a hosting operator. I am not a lawyer. The professional and regulatory questions raised here should be discussed with a colleague, a compliance consultant, or the relevant state Legal Services Commission as appropriate.

What I can tell you with confidence is the technical reality: email between two parties is not a secure channel for sensitive information, the standard read-back policy was designed for a different threat than the one most firms are now exposed to, and the alternatives are widely available and cost very little.

If your insurer’s standard policy is the only thing protecting your clients’ bank details from being intercepted in transit, your clients’ bank details are not adequately protected. That is true regardless of how diligently the read-back call is performed.

---

Iain Noy runs Momentum Hosting, an Australian managed hosting business operating since 2015. He has spent years dealing with the operational realities of how email actually moves between two parties, and the gap between what users assume about email security and what is actually true.