The $100k Fraud That Beat Every Security Rule

The transfer had already cleared when the client called.

"I never requested this," she said. "What wire are you talking about?"

The broker pulled up the transaction record. Authorization form: signed. Email address: verified against the file. Internal checklist: complete. Every box checked. Every protocol followed, yet $100,000 was gone.

Both the broker and the client were telling the truth.

In this scenario we are going to walk through a common way business email compromise attacks occur and why they are so effective and profitable.

Day One: The Invisible Entry Point

Six days before the fraudulent transfer, the broker received an email. It looked like a standard login prompt the kind that shows up dozens of times a week when a session expires or when accessing a shared document. Nothing unusual.

He clicked the link. Entered his username and password. Got prompted for the multi-factor authentication code. Entered the six-digit number from his phone. Everything worked. His email loaded normally. He went about his day.

But he wasn't the one who logged in.

What actually happened: the phishing site captured his credentials in real time and immediately relayed them to the actual login server. When the MFA prompt appeared on the broker's screen and the broker entered the code, the attacker's system passed it through within the brief window it was valid. One session was created, for the attacker. This is a very standard phishing tactic against all multi-factor solutions that fail to do domain binding.

From the broker's perspective, nothing looked wrong. No alerts. No locked account. No suspicious activity warnings. Just another login on another Friday.

The attacker was inside their inbox.

Days Two Through Five: The Surveillance Period

The attacker read, no actions other than reading all the brokers emails.

For the next few days, they went through the broker's inbox systematically. They read client correspondence. They studied how the broker handled signatures and authorizations. They identified which clients had money in motion, account rollovers, property sales, planned distributions. They learned the tone the broker used with different clients. They saw which clients the broker had strong relationships with and which were newer or more distant.

They looked for patterns in how transfers were initiated, who asked questions, who trusted easily, and what the standard back-and-forth looked like when money was about to move.

They found a client who had recently sold a commercial property and was planning to reinvest the proceeds.

Then they made their move.

Day Six: The Setup

The attacker created an email address that looked almost identical to the client's real address. Easy to miss if you weren't looking carefully, but even then the attacker knew that the broker would send a new email to the client and not reply to that email address. They just needed to trigger the process.

They sent the broker an email pretending to be the client. The request was urgent but not panicked. They needed to move money quickly for a time-sensitive investment opportunity. They apologized for the short notice. And critically: they mentioned they were traveling and couldn't take a phone call.

That last detail appears in nearly every successful business email compromise. It preempts the one thing that would immediately break the fraud a live conversation.

The broker followed the firm's protocol exactly: he generated a authorization form and sent it to the client's email address on file, not the address the request came from.

This is the step that's supposed to catch fraud. This is the step compliance officers point to when they say the process works.

The attacker knew it was coming.

The Email Rule Attack

They created an rule inside the broker's mailbox. The rule was simple: any email from that specific client gets automatically moved to a folder the broker doesn’t normally check.

When the client saw the brokers email she was confused. She didn't recognize the request. She replied to the broker: "Did you mean to send this? I didn't request anything."

The broker never saw that email. The rule moved it instantly.

The attacker saw it. And they replied from the broker's actual email account, using his tone and his signature: "Sorry about that we had a technical glitch on our end. The system auto-generated some paperwork. You can ignore it, nothing to worry about."

The client deleted the email and went about her day.

Meanwhile, the attacker clicked the signature link from the email the broker had sent. The attacker signed it as the client. The broker received the signed authorization. Everything looked legitimate. He processed the transfer.

$100,000 moved to an account controlled by the attacker.

Why Following the Rules Didn't Matter

Let's be clear about what the broker did right:

• He sent the authorization form to the verified email address on file
• He required written documentation before moving money
• He followed the firm's checklist completely

The fraud succeeded anyway.

It succeeded because every single verification step relied on email being trustworthy. The broker verified the email address but email addresses don't prove identity, they just prove someone has access to an inbox.

The client was supposed to confirm the request but the attacker controlled whether that confirmation ever reached the broker.

The signature was required but the attacker could access the signature request because it was delivered via email.

The entire security process assumed that email could be trusted to deliver messages between two verified parties. That assumption is wrong.

Email was never designed to prove identity. It was designed to deliver messages. When you send an email to verify something, you're not confirming who someone is, you're confirming that someone has access to an inbox. And if an attacker has access to that inbox, they have access to everything you're using to verify them.

This is the core vulnerability that makes business email compromise so effective. It's not that the controls don't exist. It's that the controls all depend on the same channel the attacker has already compromised.

The Only Real Solution: Break the Dependency on Email

You cannot solve this problem by making email more secure. Email is fundamentally not designed to verify identity. You can add encryption. You can implement SPF and DKIM and DMARC. You can train your team to spot phishing. None of that matters once an attacker has a valid session inside your mailbox.

The only way to stop this pattern is to verify identity outside the channel the attacker controls.

That means creating a separate, authenticated connection between you and your client, one that exists independent of email, cannot be intercepted or redirected, and requires both parties to have verified their identity when the connection was established.

When a money movement request comes in via email, you don't verify it via email. You verify it through a separate channel the attacker cannot access, even if they're sitting in your inbox reading every message.

This is called out-of-band verification, and it's the only defense that consistently works against business email compromise.

How This Actually Works in Practice

Here's what out-of-band verification looks like in a real scenario:

You and your client establish trust during a normal meeting or review when you're both confident you're talking to the actual person. You exchange verification credentials through an app that requires both parties to authenticate their identity. This creates a secure connection between your device and theirs.

That connection lives outside your email system entirely.

Now, when a transfer request comes in via email regardless of whether it's legitimate or fraudulent you don't process it based on email confirmation. You send a verification request through the separate channel.

The request appears on your client's device with details of the transaction: amount, destination, date. Your client reviews it and approves or denies it directly in the app. You receive their response instantly. No email involved. No way for an attacker sitting in either inbox to intercept or manipulate the verification.

If the request is legitimate, your client confirms it and the transaction proceeds. If the request is fraudulent if it came from an attacker pretending to be your client they cannot respond through the verification channel because they don't have access to your client's authenticated device.

Even if the attacker has completely compromised your email, they still cannot reach your client's verification app. Even if they've buried your emails to the client under a spam flood, the client still sees your verification request clearly in the app. Even if they've created email rules to hide the client's responses, you still receive the verification response outside that compromised channel.

The attacker cannot participate in that part of the process. That's what breaks the attack.

Why We Built GetTrusted

This is the problem GetTrusted was designed to solve.

When you and a client exchange trust in GetTrusted, you create a verified connection between your actual devices. Not email addresses. Not phone numbers. Your devices, tied to your verified identities.

When a transfer request comes in via email, phone, text, or any other channel you confirm it through GetTrusted in seconds. Your client receives a push notification with the transaction details. They review it on their phone. They approve or deny it. You get their answer immediately.

No email. No forwarding. No chance for an attacker to intercept.

If an attacker sends a fraudulent request, they cannot respond through GetTrusted because they don't have access to the verified connection. If they've compromised your email and are reading your messages in real time, they still cannot reach your client's GetTrusted app. If your client's inbox is buried under spam, they still see your verification request clearly on their device.

For larger firms, this becomes a policy control: certain actions: wire transfers, account changes, beneficiary updates require out-of-band verification. The rule is enforced at the process level. Email can be used for communication, but never for final authorization.

For smaller RIAs and solo advisors, this is a straightforward way to give clients a reliable method to confirm anything involving money. You download the app. You exchange trust during a normal meeting when you're both confident of each other's identity. And you use it any time something important needs confirmation.

It's not complicated. It doesn't require changing your entire workflow. It just adds a verification step that exists outside the channel attackers rely on.

What This Looks Like Going Forward

If you implement out-of-band verification, here's what would have happened in the case we walked through:

The attacker still gets into the broker's inbox. They still conduct surveillance. They still learn the patterns. They still send the fraudulent request pretending to be the client.

The broker still follows protocol: sends the signature form to the verified email address.

The attacker still creates the email rule. Still buries the client's inbox under spam. Still intercepts the client's confused reply and responds as the broker.

But when the signed authorization comes back, the broker doesn't process it immediately. Instead, he opens GetTrusted and sends a verification request to the client's device: "Confirming wire transfer of $100,000 to [account details]. Please verify."

The client sees this on her phone. She didn't request this. She taps "Deny" and immediately calls the broker.

The fraud stops there. No money moves. The attacker has no way to approve the request because they don't have access to the client's device or the verified connection. The signed document sitting in the broker's inbox becomes irrelevant it doesn't matter that the attacker forged it, because the transaction cannot proceed without out-of-band verification.

That's the difference. The attacker can still compromise email. They can still manipulate the conversation. They can still create forged documents. But they cannot complete the fraud because the final verification happens outside the channel they control.

The Choice You're Actually Making

The question is not whether business email compromise is a real threat. You already know it is. The question is whether you're going to keep relying on a verification process that attackers have proven they can defeat.

Every day you verify transactions through email, you're assuming that email is secure enough to prove identity. It's not. It never has been. And the gap between what email can actually do and what we're asking it to do is what attackers exploit.

You can keep following the checklist and hoping your team catches the subtle signs before money moves. Or you can acknowledge that the checklist depends on a channel that can be compromised, and add a verification step that doesn't.

If someone is sitting in your inbox right now, reading this message as you read it, they still cannot access your GetTrusted verification channel. That's the point.

You can download GetTrusted for Apple and Android today. If you want to implement it across your organization and integrate verified human trust into your compliance workflows, get in touch with our team at hello@gettrusted.app.

The broker in this story did everything right according to the rules. The fraud succeeded anyway. Don't let that be your story.