How to keep payment details out of a compromised inbox

There is a moment in almost every professional settlement — a commercial property closing, an OTC block trade, a cross-border acquisition — when someone types the final payment details into an email and presses send. An account number. A routing number. A destination for several hundred thousand, or several million, dollars. That moment is one of the most dangerous things a professional can do.

Not because email is inherently broken. Because email is a surface that adversaries have had twenty years to learn how to exploit, and the stakes in B2B transactions are high enough to reward patience, research, and surgical precision. The question settlement professionals, closing attorneys, escrow officers, title companies, and OTC desks face is not whether their inbox will be targeted. The question is whether their payment workflow has been designed so that the inbox does not matter.

This article walks through the specific mechanics of inbox-based payment fraud, the exact moment at which the attack becomes possible, and the structural change — not just the procedural one — that removes the exposure entirely.

The size of the problem, in plain figures

In 2025, business email compromise cost US businesses $3.046 billion in reported losses — the second-highest loss category the FBI tracks, behind only investment fraud — up from $2.77 billion the year before. The word "reported" is doing quiet but important work in that sentence. Businesses that discover fraud weeks after the fact, or that absorb losses without filing complaints, do not appear in the FBI's count. The real number is larger.

The average complaint involved more than $122,000, and 86% of that money moved by wire transfer or ACH — fast, and usually gone before anyone notices.

Fraud tactics continue to evolve, with business email compromise becoming an increasing threat: 74% of organizations experienced BEC in 2025, up sharply from 63% a year earlier. That is not a niche problem affecting careless organisations. Three in four professional businesses dealt with at least one BEC incident last year. The professionals reading this article are not bystanders to a trend — they are in the target group by definition.

The reason settlement professionals face disproportionate exposure is structural. Law firms are particularly attractive targets because they routinely handle large trust account transfers, settlement proceeds, escrow funds, and real estate transactions. The same logic applies to title companies, escrow officers, and OTC desks: they are nodes through which large amounts of money pass, they deal with multiple parties simultaneously, and they operate under time pressure that discourages the kind of deliberate verification that would stop most attacks cold.

How the attack actually works

Understanding the mechanics matters because most defences are aimed at the wrong layer. BEC is not really a hacking scam. Most of the time, nobody breaks anything. It is a con that uses real email accounts, real vendor relationships, and real company processes, and just quietly redirects one step in a transaction that would have happened anyway.

The anatomy of a typical attack runs as follows.

The two categories of defence — and why one is not enough

Once the mechanics are clear, the standard advice reads differently. The usual checklist — call to verify wire instructions, use multi-factor authentication, watch for domain lookalikes, never click attachments from unfamiliar senders — is correct, and every professional firm should follow it. But it addresses Stage four of the attack, and only partially.

In most business cases the decisive failure is not a deepfake or a sophisticated technical exploit. It is the lack of a mandatory out-of-band verification step before the payment, bank-change, or sensitive data action is approved.

At its core, any sound protocol should reduce reliance on email, verify through out-of-band communications, and document the verification.

That protocol layer — call to verify, dual authorisation, secure portals for wire instructions — represents the current best practice, and it genuinely reduces losses. Essential prevention measures include multifactor authentication, never sending wire instructions via email, and implementing documented verification procedures for every wire transfer. A closing wire verification system provides three core functions: identity verification through government ID checks and fraud indicator detection; business verification to confirm legitimacy of organisations; and secure wire instruction exchange through protected channels rather than vulnerable email or phone communications.

These are valuable controls. But notice what they are still defending: a payment workflow in which the destination account is a mutable piece of information communicated before the transaction. The underlying architecture is one in which payment instructions live in a document, a thread, or a portal — and therefore remain changeable, interceptable, and forgeable up to the moment the wire is authorised.

The procedural defence asks people to slow down and verify. That works until the day that the attacker spoofs the verification call. Until the day that a team member skips the callback because the deadline is two hours away. Until the day that the verified-looking instruction was verified against a compromised source. Procedure is necessary. It is not sufficient.

The structural alternative is to remove the payment details from the communication channel entirely.

What that structural shift looks like in practice

Consider a specific scenario: a commercial property deal with a purchase price of USD $4,200,000 (AUD ~$6,500,000). The parties are a buyer, a seller, a listing broker, a selling broker, a closing attorney, and a title company. Under a standard wire-based workflow, the closing attorney sends wire instructions to the buyer. The brokers' commissions are handled in separate disbursements. The title company coordinates each outgoing wire. There may be six to eight separate payment communications over the course of the closing, each one representing an opportunity for interception.

Every one of those communications is a surface. Every email thread is a potential attack vector. Every instruction that lands in an inbox is a piece of information that can be altered in transit, forged in advance, or redirected by anyone who has access to any one of the six to eight inboxes involved.

Now consider what happens when the payment routing is defined onchain before any money moves.

Before closing, the parties — through their attorneys and settlement professionals — agree on the distribution: seller proceeds, broker commissions, attorney fees, title charges. Those amounts and their respective destinations are encoded as preset shares in a routing contract on Ethereum. The contract itself is public, auditable, and immutable once deployed. The routing logic does not live in an email. It does not live in a PDF attached to an email. It lives on the blockchain, where no inbox compromise can alter it.

On closing day, the buyer sends a single payment to the contract address. The contract executes simultaneously: the seller receives their proceeds, both brokers receive their commissions, the attorney receives their fee, the title company receives its charge. One transaction in, simultaneous payout out, in the agreed proportions, with finality. For blockchain transactions, no consumer protection statute provides a reversal right: legal finality coincides with technical finality.

This is what shaka.deal is built to do. It is a non-custodial onchain payment router on Ethereum. It routes the total deal amount and distributes it instantly to every party at their preset shares, in a single transaction. It never holds funds. There is no intermediate custody, no staging account, no "funds are en route" period during which a reversal or misdirection is possible. The payment either executes as programmed or it does not execute.

The critical security property is this: there are no wire instructions to intercept. There is no account number to redirect. The destination addresses are fixed in the contract. An attacker who compromises every inbox in the deal simultaneously has nothing to change.

The specific vulnerabilities this eliminates

It is worth being explicit about which attack surfaces disappear under onchain routing and which ones require separate attention.

Eliminated: last-minute wire instruction changes. The most common attack vector in real estate BEC is the fake "updated wiring instructions" email sent close to closing. A common pattern involves fake emails that appear to come from a trusted party, providing altered wiring instructions. These messages can look legitimate and often arrive close to closing when timing matters most. When payment routing is encoded in a smart contract ahead of closing, there are no wiring instructions to update. An email claiming to update them has no operational effect.

Eliminated: account number spoofing. The attack works because account numbers are text — they can be copied, edited, and re-sent. An Ethereum address is verified by the contract, not by a human reading a PDF. The contract will only distribute to the addresses that were set when the deal was configured. A spoofed address in an email does not affect what the contract does.

Eliminated: social engineering around timing. The attacks are unglamorous, rely on human judgment rather than zero-day exploits, and succeed because the environments they target — luxury real estate closings, private placements, cross-border transactions — are built on speed, trust, and discretion. When the routing logic is set before the pressure of closing day, there is no high-urgency moment at which a well-timed social engineering message can redirect funds.

Eliminated: the multi-party coordination problem. The larger the deal, the more inboxes are involved. In a deal with a buyer, seller, two brokers, an attorney, a title company, and a lender, that is at least seven email accounts, any one of which may be the entry point. A single onchain transaction removes the need for any of those parties to exchange payment details with each other at closing. The routing is already known to everyone, because it is on the public ledger.

Remaining: pre-contract setup. The configuration phase — where parties agree on addresses and percentages before the contract is set — still involves communication, and that communication must be protected. This is where the procedural layer continues to matter: verifying wallet addresses through out-of-band channels, using secure portals for the initial configuration, and confirming addresses directly before finalising the routing setup. The attack surface does not disappear entirely; it compresses from the entire lifecycle of the deal to a single, well-defined configuration event.

The finality argument

Settlement professionals understand finality. A closed deal is a closed deal. The title transfers, the funds disburse, the obligation extinguishes. What many professionals have not had to confront until recently is that the traditional wire infrastructure does not provide genuine finality at the moment of execution.

In ACH, settlement is explicitly provisional, and reversals for fraud or error are permitted long after the transaction posts. In North America, most card transactions still settle on a T+1 to T+3 basis. Reconciliation across networks, banks, and currencies remains largely batch-based, and reversals can surface days or weeks after the original transaction.

Even Fedwire, which settlement professionals regard as the gold standard of domestic wire finality, operates within a legal framework in which post-transaction clawbacks remain possible under certain circumstances. Finality in traditional rails is always a legal determination layered atop technical execution — and legal determinations take time.

Onchain finality is different. When a transaction executes on Ethereum and the block is confirmed, every party's balance updates simultaneously. The seller does not wait to receive while the broker waits to receive while the attorney waits to receive. The distribution is atomic: all outputs occur in the same transaction, or none occur. There is no period of uncertainty in which one party has settled and another has not.

For a closing attorney, this means there is no disbursement queue. For an escrow officer, there is no "funds received — will disburse by end of day" window during which fraud could theoretically reverse an inbound wire before the outbound disbursements clear. For an OTC desk settling a large block, there is no overnight exposure between receipt and distribution. The settlement is the routing, executed once.

A concrete scenario: broker commission interception

One of the most documented categories of BEC targeting settlement professionals involves broker commission diversion. The mechanics are worth walking through in detail because they illustrate precisely where onchain routing provides protection that procedural controls alone cannot.

A commercial deal closes at USD $2,800,000 (AUD ~$4,330,000). The listing broker is owed a commission from the seller's proceeds. Standard practice is for the closing attorney to disburse the commission by wire after the main transaction funds. The broker's wire instructions were provided by email earlier in the transaction, confirmed by phone callback at the time.

Two weeks before closing, an attacker who has access to the broker's email account — or has created a convincing lookalike domain — sends "updated banking details" to the closing attorney's office. The update looks routine. It arrives in an existing thread. It references the correct property address, correct deal amount, and correct parties. The attorney's assistant notes the change in the disbursement file.

On closing day, the buyer's funds arrive and the attorney disburses according to the file. The seller receives their proceeds. The title company receives its fee. The "broker" — actually the attacker's account — receives USD $84,000 (AUD ~$130,000). The legitimate broker, expecting the wire, calls after two days to inquire. By then, the funds are gone.

Funds are frozen only in cases reported within hours. In this scenario, the report would not come until days later. The money is unrecoverable.

Under an onchain routing workflow: the broker's Ethereum address was set in the contract at the beginning of the deal, verified through a separate channel. "Updated banking details" sent via email two weeks before closing have no operational pathway. There is no disbursement file to amend. The contract executes to the preset addresses and no others. The attacker's email, however convincing, touches nothing.

What settlement professionals should do now

The transition to onchain routing is not a switch that flips overnight. In most jurisdictions, certain transactions still require traditional wire rails for regulatory or institutional reasons. The practical posture is to build the procedural defences now, understand where onchain routing is viable for your deal flow, and treat the structural shift as a near-term priority rather than a future option.

On the procedural side, the fundamentals matter and should be non-negotiable:

• Wire instructions are never communicated solely by email. They are confirmed through an independent channel — a phone number sourced before the deal starts, not from the instruction email itself.
• Any change to payment instructions, regardless of how it arrives or from whom it appears to come, triggers a fresh out-of-band verification before it is acted on.
• High-risk transactions demand dual approvals and enhanced verification regardless of relationship history.
• Staff are trained to treat urgency as a red flag, not a reason to skip verification. Wire transfer scams succeed when urgency defeats verification.
• Microsoft's research shows inbox rules, OAuth abuse, session persistence, and MFA-method registration can all extend attacker access after the first compromise. Inbox hygiene is not just about password strength — it includes reviewing forwarding rules, connected app permissions, and active sessions regularly.

On the structural side, any deal involving multiple disbursements to multiple parties is a candidate for onchain routing through shaka.deal. Commercial real estate closes, multi-party OTC settlements, acquisition disbursements, and fee-sharing arrangements among co-operating brokerages all fit the pattern: one inbound payment, preset shares, simultaneous outbound distribution, with a public and auditable record of what was agreed and what executed.

The configuration conversation — agreeing addresses and percentages before the contract is deployed — is the remaining security moment, and it should be treated with the same rigour as any wire instruction verification.

The professional's advantage

There is a point worth making directly to the settlement professionals and closing attorneys who will read this: onchain routing does not change what you do. It changes where the payment instructions live.

The title company still coordinates the closing. The attorney still manages disbursements. The escrow officer still ensures that conditions are met before the transaction executes. The OTC desk still confirms counterparty details and deal terms. What changes is that the final payment routing is not a set of account numbers living in an email thread — it is a set of addresses and percentages living in a smart contract that executes exactly as agreed, without anyone in the middle needing to manually disburse, sequence, or confirm individual wires.

As technology evolves, fraudsters are getting increasingly sophisticated with their methods to steal funds, especially in high-stakes transactions. The professional who understands the attack surface and has structurally reduced it is not just protecting their clients. They are protecting their own professional liability exposure, their firm's reputation, and the trust that makes multi-party settlement possible at all.

With increasing frequency and higher financial stakes, it is imperative for professionals across the real estate industry — including title agents, brokers, and closing attorneys — to recognise the signs of BEC and implement prevention. The same imperative applies across every professional category that handles large multi-party payments.

The inbox has been a liability in payment workflows for as long as payment details have been communicated through it. The structural answer is to move the payment routing off the inbox and onto the chain — where the terms are visible to every party, the execution is atomic, and there is nothing left in an email thread for an attacker to change.

That is the premise behind shaka.deal: preset, split, simultaneous, final. The inbox stays for everything else. The payment details go onchain.