Wire Fraud Protocols for Law Firms: Show the Check Happened Before Trust Funds Moved

After a loss, the question is what the firm did

A settlement disbursement goes to an account that turns out to belong to someone else. The money is gone or frozen, and three parties ask the firm the same question in different words. The client asks why. The insurer asks what verification was done and whether it met the policy's conditions. A bar investigator, if it gets that far, asks whether the firm took reasonable care of property it held for a client.

The duties behind those questions are familiar. Under ABA Model Rule 1.15 a lawyer safeguards client property. Rule 1.6(c) asks for reasonable efforts to prevent unauthorized access to client information. Comment 8 to Rule 1.1 makes understanding the risks of relevant technology part of competence, and ABA Formal Opinion 477R (2017) says the security a communication needs depends on how sensitive it is. Wire instructions for client funds are about as sensitive as a law firm's email gets. Your own jurisdiction's rules and opinions are what apply to you, and this post is not legal advice.

What these duties have in common is that they are judged after the fact, from evidence. And the evidence most firms have is thin: a line in the matter notes saying "verified by phone", a call-back sheet, an email to a colleague. All of it was written by the firm, about itself, in systems the firm can edit.

Two directions, two different problems

Money comes in to the trust account: retainers, purchase deposits, settlement funds from the other side. Here the firm is the issuer. It sends clients and counterparties its own account details, and the attack is a fake of the firm's instructions reaching the person who pays.

Money goes out of the trust account: disbursements to sellers, lenders, title companies, claimants, the client. Here the firm is the payer. It acts on instructions someone else sent, and the attack is a fake reaching the firm.

The protocols most firms publish focus on the second, because that is where the firm's own hand releases the money. The first deserves the same care, because a client who wires their deposit to a fraudster on the strength of an email in your name will ask you, not their bank, what went wrong. The tools differ by direction, so the rest of this guide takes them one at a time.

Money in: send your trust account details through a room

Open an Evidence Room for the matter and put the firm's payment instructions in it instead of attaching them to an email. Your browser fingerprints the file and anchors that fingerprint, signed with the firm's key, before it encrypts the file and uploads only the encrypted copy. Invoance holds no key that opens it.

Name the client as the recipient. They get their own link, open it with a 6-digit code sent to the address you named, and need no account. Their device decrypts the file, hashes it and compares it with your fingerprint before saving it, so the version they pay from was checked against yours on their own machine. The room log records each step as a signed entry: the file added, the link opened, the download.

Then make the room the only channel, in writing. The engagement letter and the first email of every matter that will involve funds can say it plainly: payment instructions from this firm arrive only through our evidence room, we will never change them by email, and any copy can be checked on its public proof page before you pay. A client who receives an email in your name with different details has a rule to apply and a check to run, without having to decide whom to believe.

• Evidence Rooms A room per matter: named recipients, a device check on every download, a signed log.

Money out: fix the file you are about to verify

Instructions for a disbursement arrive from a title company, opposing counsel or the client. Before anyone picks up the phone, anchor the file exactly as received. From the dashboard, drop it on the document upload page; the browser hashes it and only the hash is sent. The record is signed with the firm's key and shows the time.

Be clear about what that record says. It does not say the sender issued the file; only the sender can say that. It says the firm held these exact bytes at this moment, which is what makes the call-back that follows refer to one specific file rather than to "the instructions". If a different PDF turns up later in the matter folder, its hash will not match, and the firm can show which file it actually checked.

If the sender uses Invoance, there is a better check available before the call. Drop the file on the sender's proof page: a match means it is the file they issued, signed by their organization, and the page shows whether their domain is verified. A sender who delivers through a room gives you the same check on your own device at download.

• Document Anchor The signed fingerprint of a file, and its public proof page.

Record the call-back as a signed event

The call-back itself is the protocol most firms already have, and it is right. Use a number from the firm's own records, an earlier verified contact or the counterparty's official website, never one from the email or its signature. Speak to someone you know. Read the beneficiary name and the full account and routing numbers aloud and have them confirmed, rather than asking whether the instructions are genuine.

What changes is the record of it. Instead of a note in the matter file, record the call-back as an event in the Event Ledger, from the dashboard or from Claude or ChatGPT through the Invoance connector. Name the matter, the document record you anchored, the number called and where it came from, who answered, what was read back and the outcome. The event is hashed, signed with the firm's key and stored where it cannot be edited or deleted, and it has its own proof page.

Record the last four digits of the account, not the full number. The anchored file holds the rest, and the record will be kept and may be shown to people who do not need the whole number.

{
  "event_type": "wire_instructions.verified",
  "payload": {
    "matter": "2026-0417 Halvorsen purchase",
    "instructions_record": "9549c332-a52b-4f7e-9b1a-7d2e6c0f4a8b",
    "counterparty": "Meridian Title & Escrow",
    "number_called": "+1 555 0142",
    "number_source": "firm contact record, verified 2026-02-11",
    "spoke_to": "closing officer, known contact",
    "read_back": ["beneficiary name", "routing number", "account number"],
    "account_last4": "4471",
    "outcome": "confirmed",
    "verified_by": "paralegal r.chen"
  }
}

• Event Ledger Signed, append-only records of the business events that get questioned.

The second approver checks independently

Dual authorization works when the second person checks the instructions themselves, not when they confirm that the first person did. Give the approver the same tools: the anchored record of the file, the proof page if the sender has one, and the verification event. If the file in front of them hashes to the anchored fingerprint and the read-back in the event matches it, they release; if not, the wire waits.

Record the release as its own event, by the approver, naming the verification event it relied on. The two records now show a sequence: this file was received and fixed at 10:02, verified by phone at 10:40 by one person, released at 11:15 by another. Each record carries the time the ledger received it, so none of them can be added afterwards and pass for one written at 10:40.

One detail matters for honesty. The signature is the firm's, applied by Invoance with the firm's key; the payload says which person did each step. The records prove what the firm recorded and when, and that nothing in them has changed since. They do not prove that the phone call went the way the payload says. That is still a statement by your staff, but one fixed at the time rather than reconstructed after a loss.

When the voice on the call can be faked

Call-backs rest on recognising the person at the other end. That is getting weaker. In early 2024 a finance employee at the engineering firm Arup paid about 25 million US dollars, across fifteen transfers, after a video call in which the chief financial officer and other colleagues were all deepfakes. A cloned voice on a call-back number is a much smaller task than that.

Keep calling back, because a known number still beats a number from the email. But move the weight of the check off the conversation. A fingerprint comparison does not depend on recognising anyone: the file you hold matches what the issuer anchored, or it does not. When the counterparty delivers through a room, that check runs on your own device before the file is saved. The call then confirms a file that has already been checked, and asks a question specific enough ("the instructions I hold end in 4471; do yours?") that a confident voice cannot answer it by being confident.

• CNN on the Arup case The deepfake video call, as reported in May 2024.

What the records do and do not establish

They establish which exact file the firm sent or verified, when it was fixed, who received it through a room and when they opened and downloaded it, and what the firm recorded about each call-back and release at the time. Anyone can check them without trusting the firm or Invoance: the proof pages need no account, and a room's evidence package can be checked offline against the firm's public key.

They do not decide what reasonable care requires in your jurisdiction, and they do not stand in for your insurer's conditions; ask your broker what the policy expects and whether client funds held in trust are covered. They do not check bank accounts or account ownership. They do not stop a person at the firm from deciding to wire anyway. And the emailed code that opens a room is as strong as the recipient's inbox, which is why a room can require a passkey.

A protocol to adopt this week

Money in: put the firm's payment instructions in a room per matter, name the client, and state in the engagement letter that instructions only arrive that way.

Money out: anchor every set of instructions the moment it arrives. Check it on the sender's proof page if they have one. Call back on a known number and read the details aloud. Record the call-back as an event. Have a second person check the file against the record and release it as their own event.

At the end of the matter, export the room's evidence package and keep it with the file alongside the event records.

The first room is free on Developer and Builder: one room at a time, 100 MB and up to ten recipients. Evidence Rooms is included from Growth, and the Event Ledger and Document Anchor run from the same dashboard with no developer needed.

• Wire transfer best practices: what each control checks The standard checklist sorted by what it looks at.
• Verify a file Drop any copy on the public proof page.