Six people reviewed it. Not one of them flagged it.

In July 2025, Ireland's National Treasury Management Agency — the state body responsible for managing Ireland's national debt and sovereign wealth — received a payment request. It came from a legitimate email address belonging to a real investee company the NTMA had paid the previous year. The bank details they had on file. The request format was familiar. Six separate people authorized the payment at different stages of the approval process. Every check was run. Every box was ticked.

The €5 million went to an attacker who had been quietly sitting inside the investee's real email system, monitoring correspondence, waiting for the right moment to insert a fraudulent capital call. By the time the NTMA discovered what had happened — in conversation the following day, when they realized the capital hadn't reached the investee — only €2.5 million remained recoverable. The other €2.5 million was gone. The NTMA CEO, testifying before Ireland's Public Accounts Committee in May 2026, said the attacker had gathered significant non-public information and the controls in place "didn't stand up."

Six people. A sovereign wealth management agency. A real email, from a real account, referencing a real prior transaction. And €2.5 million that nobody is getting back.

That's vendor email compromise. And it's the most financially damaging email attack running against organizations of every size in 2026 — not because it's technically sophisticated, but because it's designed from the ground up to look exactly like the normal business your accounts payable team processes a hundred times a month.

VEC surged 67% in 2025, making it the most financially damaging BEC variant tracked by enterprise security teams per Abnormal Security's annual threat data. AFP's 2026 Payments Fraud survey found roughly three-quarters of organizations experienced attempted payments fraud in the past year, with BEC as the dominant vector. CSO research on simulated VEC scenarios found that 72% of employees engaged — a rate 90% higher than engagement with other BEC types. And only 23% of fraudulent wire transfers are successfully recovered, per FBI IC3 data. This piece covers how VEC actually works at the mechanics level, what the most costly documented cases reveal about why standard controls fail, and what intent-based detection has to do differently to close a gap that content scanning and authentication checks cannot touch.

VEC vs. Classic BEC: Why the Distinction Matters for Detection

Business email compromise is a broad category. Classic BEC — CEO fraud — involves impersonating a senior executive to pressure a subordinate into an urgent wire transfer or gift card purchase. The target knows the impersonated person is real. The attacker is betting they won't pick up the phone to verify before acting.

Vendor email compromise is structurally different in a way that changes everything about how you detect it. Instead of impersonating an internal authority figure, the attacker either impersonates or genuinely compromises an external vendor, then inserts a fraudulent payment instruction into what is — up to that point — a completely real and legitimate business transaction.

The target isn't being pressured by someone they can't question. They're being deceived inside a relationship they have every reason to trust. An AP coordinator receiving an urgent wire from the CEO might pause. The same person receiving a bank detail update from a vendor they've paid every quarter for two years is processing a routine administrative task. The normalcy is the weapon.

Two Versions of VEC — Both Dangerous, One Harder to Catch

VEC comes in two distinct forms. Domain impersonation: the attacker registers a domain visually similar to the vendor's real domain — a transposed letter, a different TLD, a hyphen in the wrong place — and sends an email that looks like it came from the right source. The message mirrors the vendor's communication style and references the real project or invoice.

True account compromise: the attacker has actually gained access to the vendor's real email account through phishing, credential theft, or session hijacking, and is operating from inside the legitimate inbox. The NTMA case was this variant. The email that cost Ireland €5 million came from a real, authenticated mailbox belonging to a real business the NTMA had a real relationship with. Every authentication check passed. There was nothing technically wrong with the message. The only thing wrong was the bank account number.

The second form is significantly harder to detect and increasingly common. Hoxhunt's analysis found VEC attacks using genuinely compromised accounts were up 137% in 2023 alone, and the trajectory has continued since. When the attacker is operating from inside a real vendor inbox, there's no spoofed domain to catch, no failed authentication to flag, and no reputation signal to act on. The only available detection signal is the request itself — whether it makes sense given everything known about this specific vendor relationship.

When the attacker is inside your vendor's real inbox, every technical check passes. The only thing wrong is what they're asking for — and catching that requires understanding the relationship, not scanning the message.

Thread Hijacking: The Mechanic That Makes VEC Uniquely Effective

Thread hijacking is what separates a sophisticated VEC campaign from a generic invoice scam. Instead of initiating a new email conversation — which would stand out as unexpected — the attacker inserts a fraudulent payment instruction into an existing, ongoing email thread between the victim organization and the vendor.

With true account compromise, this is straightforward. The attacker logs into the vendor's real inbox, reads the existing thread, understands the current invoice or project context, and replies directly from inside the thread at a moment when a banking change would seem plausible. The victim receives what looks like a continuation of a conversation already in progress — because structurally, it is.

With domain impersonation, the attacker spoofs a reply that appears to continue the thread, matching the subject line prefix, the email signature format, and the tone of prior messages they've gathered from other sources. The target sees a message that looks like it belongs to a conversation they've been having for months.

The psychological mechanism here is what researchers call context compression. A standalone fraudulent email requires the target to evaluate it on its own merits. A message arriving in an ongoing thread carries the implicit credibility of everything that came before it — the real invoices, the real project discussions, the real relationship. When six people at the NTMA reviewed the fraudulent capital call, they weren't evaluating it in isolation. They were evaluating it within the context of a prior payment they'd actually made. The attacker knew that context existed. They used it.

The Timing Advantage

Experienced VEC operators don't insert the fraudulent banking change at a random moment. They study the payment cycle. They watch when invoices are typically sent, when confirmations arrive, how many days before a due date a change request would need to land to be processed in time. The fraudulent request arrives when it's least likely to trigger scrutiny — not because urgency is being manufactured, but because the timing itself feels entirely routine.

AFP's 2026 Payments Fraud survey captured exactly this dynamic. A respondent described a case where a fraudster infiltrated a vendor's email account and began sending legitimate-looking messages requesting updated banking details. The documentation appeared valid. The request followed existing processes. The payment was initiated. The process worked exactly as designed — on a fraudulent request.

The Cases That Show the Full Scale of This Problem

Google and Facebook: $122 Million Through Quanta Computer Invoices

Between 2013 and 2015, a Lithuanian national named Evaldas Rimasauskas executed what remains one of the most documented VEC campaigns on record. He registered a company in Latvia using the same name as Quanta Computer — a real Taiwanese hardware manufacturer that both Google and Facebook regularly purchased servers and equipment from. He sent carefully crafted invoices on matching letterhead to the right contacts at both companies, referencing equipment types both companies genuinely used.

Because the invoices matched the cadence and format of real Quanta billing, AP teams at both companies processed the payments without additional verification. Over two years, Facebook paid $99 million and Google paid $23 million — a total of $122 million — to bank accounts in Latvia and Cyprus. Rimasauskas used forged contracts, fake corporate stamps, and fabricated executive signatures to provide supporting documentation when banks flagged the transactions for review.

He was arrested in Lithuania in 2017, extradited to the United States, and sentenced to five years in federal prison in 2019. He was ordered to forfeit $49.7 million and pay restitution of $26.5 million. Both Google and Facebook stated publicly they had recovered the bulk of the funds — but court records indicate roughly $50 million remains unaccounted for, likely laundered through the network of international accounts Rimasauskas used to move the money.

The lesson from this case is not that Google and Facebook had poor security. Both companies had sophisticated security programs. The lesson is that a fraudulent invoice fitting the expected context of a real vendor relationship bypasses security infrastructure that wasn't designed to evaluate payment context. Nobody at either company was checking whether Quanta had actually requested a payment. They were checking whether the invoice looked like a Quanta invoice. It did.

Ireland's NTMA: €5 Million, Six Authorizations, €2.5 Million Gone

In July 2025, the NTMA's Ireland Strategic Investment Fund received a fraudulent capital call request from a third party whose real email system had been compromised. The attacker had been inside the investee's inbox long enough to gather what NTMA CEO Frank O'Connor later described as "quite a bit" of non-public information about the fund's relationship with the agency.

The fraudulent payment request was designed and timed to pass as a legitimate capital call — the kind of request the NTMA had processed for this same investee the previous year. Six people authorized the payment at different stages of the approval process. All of them checked it. None of them caught it. The NTMA discovered the fraud the following day in conversation, when they realized the capital hadn't reached the investee company.

Of the €5 million paid, €2.5 million has been recovered. The remaining €2.5 million had moved far enough through the international banking system to be unrecoverable. The NTMA's CEO testified to Ireland's Public Accounts Committee in May 2026 that the controls in place "didn't stand up to the threat actors." An independent forensic investigation by Deloitte was commissioned. The NTMA processes more than half a trillion euros in payments in some years. The CEO was direct: "We are a target." This is the same account takeover pattern that mid-market organizations face daily — applied against a sovereign wealth management agency with professional treasury controls. If six authorized approvers at the NTMA couldn't catch it, the question for every organization is what your verification process would actually look like against the same attack.

The M&A and Legal Transaction Pattern

Mergers, acquisitions, and legal settlements create ideal conditions for VEC for a specific reason: large, infrequent, time-sensitive wire transfers to parties the paying organization may not have an extensive payment history with. An acquiring company paying into an escrow account for the first time, or a law firm processing a settlement payment on a compressed timeline, has less established baseline to compare against and more pressure to move quickly.

Palo Alto Networks Unit 42 documented this pattern across multiple investigated BEC cases, noting that attackers specifically monitor M&A announcement filings, court records, and regulatory disclosures to identify high-value transactions in progress. The fraudulent banking change arrives during the transaction window — after both parties have established communication but before the payment relationship has generated enough history for an anomaly to be obvious.

Why AI Has Made VEC Significantly More Dangerous in 2026

The 67% surge in vendor email compromise in 2025 isn't primarily explained by attackers developing better tradecraft at the technique level. The core mechanic — compromise or impersonate a vendor, insert a banking change into a real thread — has been stable for years. What changed is the cost and quality of everything around it.

Crafting a convincing vendor impersonation used to require real effort: studying the target vendor's communication style, replicating their formatting, matching the terminology and register of their industry. That effort created a natural ceiling on how many targets a single campaign could address and how polished each impersonation could be.

Generative AI removed that ceiling. Given a sample of the vendor's legitimate emails — from a compromised account, from prior correspondence, from public sources — a language model generates an impersonation that matches the source's style, vocabulary, and tone in minutes. An attacker who previously ran two high-quality VEC campaigns per month can now run dozens, each individually tailored to the specific vendor relationship, payment cycle, and communication style of the target organization.

The convergence with legitimate service abuse compounds this further. When VEC lures arrive through compromised SendGrid accounts, real SharePoint notifications, or vendor inboxes taken over via AiTM session hijacking, the combination of AI-quality content and legitimate sending infrastructure defeats every layer of technical detection simultaneously.

72% of employees engage with a simulated vendor email compromise attempt — 90% higher than other BEC types — CSO Research

Why Standard Detection Misses VEC Almost Entirely

VEC is the attack that the email security industry was least prepared for, because its defining characteristic is using legitimate infrastructure to deliver legitimate-looking content inside a legitimate relationship. There's rarely a technical signal to catch — by design.

Authentication Checks Pass Cleanly

In the true account compromise variant, SPF, DKIM, and DMARC all pass, because the email is genuinely coming from the vendor's real, authenticated mailbox. In the domain impersonation variant, sophisticated attackers configure authentication on their lookalike domains specifically to pass these checks. A domain with correct SPF and DKIM that is visually similar to a legitimate vendor domain is not distinguishable from the real domain by any authentication-based filter.

Content Scanning Has Nothing to Flag

A VEC email typically contains no malicious link, no malicious attachment, and no known phishing template. It contains a bank account number and a request to update payment details. The content of a fraudulent banking change request is structurally identical to the content of a legitimate banking change request. Content scanning cannot tell them apart because there is nothing technically different about them.

Reputation Systems Trust Known Vendors

A vendor your organization has been emailing for three years has an excellent sending reputation in your mail environment. Their domain is almost certainly in your implicit or explicit safe sender list. A reputation-based filter seeing an email from a domain with years of legitimate sending history has no basis to flag it — even if the specific mailbox it's coming from was compromised yesterday afternoon.

The Gap Is Relational Context

What can actually catch VEC is evaluating whether the specific request fits the established pattern of this vendor relationship — whether banking change requests have ever come through this channel before, whether the timing fits the known payment cycle, whether the request deviates from how this vendor has communicated for years.

That evaluation requires modeling the relationship, not scanning the message. It requires understanding organizational context — who pays whom, through what process, on what cadence — and evaluating each message against that context in real time. This is precisely the reasoning layer that's absent from gateway-based detection, and that how TRACE powers real-time email threat prevention.

How TRACE Reasons About Vendor Relationships

TRACE's approach to VEC detection is built around a question no rule-based system can answer: does this request fit what we know about how this vendor and this organization actually interact?

To answer it, TRACE builds and continuously updates a relational model of every external communication relationship in the organization. For each vendor relationship, it tracks established communication patterns: which contacts communicate, through which channels, at what frequency, about what topics, using what terminology — and critically, what types of requests have historically come through email versus through other verification channels.

When a banking change request arrives, TRACE evaluates it against that relational model. Has this vendor ever changed banking details through this channel before? Does the request arrive at a point in the payment cycle where a banking change would be plausible? Does the phrasing match how this vendor typically writes? Is the sending domain the exact domain this vendor has always used, or a variant that hasn't appeared in any prior correspondence?

None of those questions can be answered by scanning a single email in isolation. All of them can be answered by a system that has modeled the relationship over time and is reasoning about this specific message within that context. That's the detection signal that catches the NTMA-style attack — the one where the email is technically real, the relationship is technically real, and the only thing anomalous is the request itself.

Pre-Delivery Infrastructure Detection

TRACE's pre-campaign threat hunting layer adds a second dimension specific to the domain impersonation variant of VEC. Attackers registering lookalike domains weeks before a campaign leave a trackable signature in passive DNS, certificate transparency logs, and hosting provider patterns. Continuous monitoring of domain variants associated with your known vendor list — watching for registrations of domains visually similar to your vendors' real domains — surfaces impersonation infrastructure before the first fraudulent email is ever sent. It's the same pre-campaign layer that provides early detection for whaling campaigns and quishing infrastructure — one capability serving multiple attack categories across the cluster.

The Industries Where VEC Concentrates

VEC is a universal threat, but its financial impact concentrates in sectors where external payment volume is high, transaction sizes are large, and email has historically been the primary channel for coordinating those payments.

Professional Services and Legal

Law firms and professional services organizations handle large client payments and regularly communicate payment instructions over email as part of their normal practice. The confidential nature of many of these transactions — M&A closings, litigation settlements, estate distributions — creates pressure against extra verification steps, because doing so can feel like it violates the confidentiality of the matter. Attackers specifically exploit this by framing fraudulent payment instructions inside a confidential legal context that makes out-of-band verification feel inappropriate.

Construction, Real Estate, and Title

This sector is structurally over-exposed. Large, infrequent payments to vendors with whom a buyer may have limited payment history, combined with publicly available project information — permit filings, planning records, contract announcements — that makes targeted reconnaissance straightforward. A buyer at a real estate closing has never wired money to this title company before. A construction company paying a new subcontractor for the first time has no baseline. FBI documented BEC cases feature real estate transactions prominently, specifically because a large wire to an unfamiliar account is normal in this context and therefore hard to flag as anomalous.

Manufacturing and Supply Chain

Manufacturers paying dozens or hundreds of vendors on recurring cycles create both opportunity and complacency. AP teams processing high invoice volume develop a rhythm that's genuinely difficult to interrupt for individual verification, especially when the request arrives from a known vendor in a known format at a known time in the cycle. Supply chain disruptions in recent years have also normalized vendor banking changes as companies restructured operations — which attackers have exploited by timing fraudulent change requests to coincide with periods when such changes are expected. StrongestLayer's full email attack taxonomy tracks VEC at trajectory 3.2 and rising, with manufacturing supply chains among the sectors seeing the sharpest increase in targeting through 2026.

Mid-Market Organizations Across All Sectors

The targeting data for VEC follows the same pattern as other BEC attack categories: mid-market organizations are disproportionately targeted because they combine meaningful transaction volume with thin verification infrastructure. A 200-person professional services firm where one AP coordinator processes invoices and a banking change from a known vendor is a routine administrative task is a significantly easier target than an enterprise with dual-approval requirements and dedicated fraud review. The fraud amount scales with transaction size — but the barrier to executing the attack scales down with verification sophistication.

Building a VEC Defense That Actually Works

Defending against vendor email compromise requires five distinct layers, because no single control addresses the full attack surface. Each layer closes the gap the previous one leaves open.

Layer One: Verify Banking Changes Out of Band, Every Time

Any request to change vendor banking details must be verified through a phone call to a pre-registered number for that vendor — not a number provided in the suspicious message — before the change is processed or any payment goes to the new account. No exceptions. AFP's 2026 survey documented exactly how this fails in practice: organizations bypassed callback procedures or used email-based confirmation from the same thread that initiated the request. The policy has to be unconditional. Urgency doesn't override it. Relationship doesn't override it. If six people at the NTMA checked a fraudulent capital call and missed it, out-of-band verification through a channel the attacker can't access is the only control that would have caught it.

Layer Two: Formal Vendor Onboarding for Banking Details

Capturing banking details through a controlled channel during vendor onboarding — a secure portal, a dual-signature process, a video-verified confirmation — establishes a verified baseline that makes any subsequent change request through email automatically anomalous. If the onboarding captured banking details properly, any change to those details through an uncontrolled channel is a deviation from the established process. That deviation is the detection signal, independent of any technical tool.

Layer Three: Deploy Detection That Models Vendor Relationships

The technical detection layer needs to evaluate whether a request fits the established pattern of the specific vendor relationship, not just whether the email passes authentication. A system that has modeled the communication history between your organization and each vendor, and can flag a banking change request as anomalous relative to how that relationship has historically communicated, provides the signal that gateway scanning cannot produce.

Layer Four: Monitor Your Vendor Domain Ecosystem

Continuous automated monitoring of domain registrations similar to your known vendors' domains — typosquatting variants, homoglyph substitutions, subdomain constructions — surfaces domain impersonation infrastructure before it's used in an active campaign. This is practical and specific: a watchlist of your top 50 vendors, monitored for lookalike registrations, gives early warning of the impersonation variant of VEC without requiring any analyst to manually scan threat feeds.

Layer Five: Train the AP Function Specifically on This Scenario

The 72% engagement rate on simulated VEC scenarios tells you something important: this specific attack type deserves its own dedicated training, not a paragraph in a general BEC module. AP staff need to practice the exact scenario of a banking change request arriving in a real vendor thread — the specific red flags, the exact verification procedure to follow, and a culture where flagging a suspicious request from a known vendor is encouraged rather than seen as slowing down a normal process.

The Invoice That Was Real in Every Way That Mattered — Except One

There's a reason VEC keeps working at the scale it does, despite years of awareness campaigns and vendor onboarding policies and email security investment. The attack is specifically designed to defeat every layer of scrutiny organizations typically apply to inbound mail.

It uses a real vendor relationship as cover. It arrives inside a real email thread as context. It makes a request that, in isolation, is entirely routine — banks change processing partners, payment details get updated, businesses have administrative needs. Nothing looks wrong. The only thing wrong is the account number at the bottom, and verifying that account number requires a step that happens entirely outside the email.

Six people at the NTMA didn't miss obvious red flags. They checked what was checkable and missed the one thing that couldn't be checked without picking up the phone. The attacker counted on that. They'd been inside the inbox long enough to understand the verification process, and they designed a request that passed it.

Stopping VEC requires three things working together: a technical detection layer that models vendor relationships and flags requests that don't fit established patterns, a procedural control that takes banking change verification completely outside the email channel, and training aimed at the specific people who handle payments — not at the executive team. None of those three alone is enough. The NTMA had controls. They didn't stand up. StrongestLayer's email attack taxonomy tracks VEC at trajectory 3.2 and rising for 2026 — because right now, for most organizations, the attack is still working. The organizations that stop adding to that number are the ones who've accepted that the email itself cannot be the only place you look.

Frequently Asked Questions (FAQs)

Q1: What is vendor email compromise and how is it different from regular BEC?

Classic BEC impersonates an internal authority figure — a CEO or CFO — to pressure a subordinate into a wire transfer or gift card purchase. Vendor email compromise targets the external side of the business relationship. The attacker either impersonates or genuinely compromises a vendor your organization already pays, then inserts a fraudulent payment instruction into what is, up to that point, a completely legitimate business transaction. The target isn't being pressured by someone they can question. They're being deceived inside a relationship they have every reason to trust — which is why the engagement rate in simulated VEC scenarios is 90% higher than other BEC types.

Q2: What is thread hijacking and why does it make VEC so hard to catch?

Thread hijacking is the technique of inserting a fraudulent payment instruction into an existing, ongoing email thread between the victim organization and the vendor — rather than initiating a new conversation. When an attacker has genuine access to a vendor's compromised inbox, they can reply directly from inside the real thread at a moment when a banking change would seem plausible. The target receives what looks like a continuation of a conversation already in progress. A standalone fraudulent email requires the target to evaluate it on its own merits. A message arriving in an ongoing thread carries the implicit credibility of everything that came before it — the real invoices, the real project discussions, the real relationship. That context compression is what makes thread hijacking psychologically so effective.

Q3: What actually happened in the NTMA case?

In July 2025, Ireland's National Treasury Management Agency received a fraudulent capital call request from a third party whose real email system had been compromised. The attacker had been inside the investee's inbox long enough to gather significant non-public information about the fund relationship. The fraudulent request was designed and timed to look like a legitimate capital call — identical in format to a real payment the NTMA had processed for the same investee the previous year. Six separate people authorized the payment at different stages of the approval process. All of them checked it. None caught it. Of the €5 million paid, €2.5 million was recovered. The remaining €2.5 million is gone. The NTMA CEO testified to Ireland's Public Accounts Committee in May 2026 that the controls in place simply didn't stand up.

Q4: How did Evaldas Rimasauskas steal $122 million from Google and Facebook?

Between 2013 and 2015, Rimasauskas registered a company in Latvia using the exact name of Quanta Computer — a real Taiwanese hardware manufacturer that both Google and Facebook regularly purchased servers and equipment from. He sent fraudulent invoices on matching letterhead referencing equipment types both companies genuinely used. Because the invoices matched the expected format and cadence of real Quanta billing, AP teams at both companies processed the payments. Facebook paid $99 million. Google paid $23 million. The total was $122 million. Rimasauskas used forged contracts, fake corporate stamps, and fabricated executive signatures to satisfy bank scrutiny. He was sentenced to five years in federal prison in 2019 and ordered to forfeit $49.7 million — but approximately $50 million remains unaccounted for.

Q5: Why does SPF, DKIM, and DMARC not protect against VEC?

Authentication protocols verify that a message came from a server authorized to send on behalf of a domain. In the true account compromise variant of VEC, the email is genuinely coming from the vendor's real, authenticated mailbox — so SPF, DKIM, and DMARC all pass cleanly, because nothing was spoofed. The attacker is using the real inbox. In the domain impersonation variant, sophisticated attackers configure authentication on their lookalike domain specifically to pass these checks. Either way, authentication protocols answer the wrong question. They verify infrastructure. They cannot evaluate whether the specific request being made fits the established pattern of this vendor relationship.

Q6: How has AI made vendor email compromise worse in 2026?

The 67% surge in VEC in 2025 isn't primarily about attackers getting better at the technique — the core mechanic has been stable for years. What changed is the cost and quality of the social engineering layer. Before AI, crafting a convincing vendor impersonation required studying the target vendor's communication style, replicating their formatting, and matching their industry register. That effort limited campaign scale. Now, given a sample of the vendor's real emails, a language model generates an impersonation matching the source's style and tone in minutes. An attacker who previously ran two high-quality VEC campaigns per month can now run dozens, each individually tailored to the specific vendor relationship, payment cycle, and communication style of the target organization.

Q7: Which industries are most exposed to VEC?

Any sector where external payment volume is high, transaction sizes are large, and email has historically been the primary channel for coordinating those payments. In practice: professional services and legal firms, where large client payments and settlement funds flow regularly and out-of-band verification can feel like a confidentiality breach; construction and real estate, where large infrequent payments to new vendors are structurally normal and hard to distinguish from fraud; and manufacturing and supply chain, where high invoice volume creates AP team rhythm that's genuinely difficult to interrupt for individual verification. Mid-market organizations across all sectors are disproportionately targeted because they combine meaningful transaction volume with thin verification infrastructure — one AP coordinator processing invoices is a very different target than an enterprise with dual-approval requirements and dedicated fraud review.

Q8: What's the single most effective control against VEC?

Out-of-band verification — unconditionally. Any request to change vendor banking details must be confirmed through a phone call to a pre-registered number for that vendor, using contact information captured during onboarding, not provided in the suspicious message. No exceptions. Urgency doesn't override it. Relationship doesn't override it. AFP's 2026 Payments Fraud survey documented exactly how this fails in practice: organizations bypassed callback procedures or used email-based confirmation from the same thread that initiated the request. The out-of-band requirement is the one control that would have caught the NTMA case — because the attacker, however long they'd been inside the investee's inbox, could not answer a call to the investee's pre-registered number.

Q9: Why does VEC have a 72% employee engagement rate in simulations?

Because the attack is designed from the ground up to look exactly like the normal business an AP coordinator processes dozens of times a month. A banking change request from a vendor you've paid for three years, arriving in an ongoing thread, referencing a real invoice or project, at a routine point in the payment cycle — that is not a scenario that triggers the 'this looks suspicious' instinct that phishing training is designed to build. The 72% engagement rate in CSO Research simulations, 90% higher than other BEC types, reflects how well VEC exploits the normalcy of the scenario rather than any failure of the employees being tested.

Q10: How does TRACE detect VEC when the email is technically legitimate?

TRACE builds a relational model of every external communication relationship in the organization — tracking which vendor contacts communicate, through which channels, about what topics, at what frequency, and critically, what types of requests have historically come through email versus other verification channels. When a banking change request arrives, TRACE evaluates it against that model: Has this vendor ever changed banking details this way before? Does the request arrive at a plausible point in the payment cycle? Does the phrasing match how this vendor actually writes? Is the sending domain the exact domain this vendor has always used? None of those questions can be answered by scanning a single email in isolation. How TRACE powers real-time email threat prevention covers the full architecture — but the core logic is: if the request doesn't fit the established relationship pattern, it gets flagged regardless of whether every technical check passed.

Q11: What should an incident response plan for VEC look like?

Five steps in order. First, freeze the payment — contact your bank immediately. The recovery window is narrow: AFP data shows only 23% of fraudulent wires are successfully recalled. Second, preserve the thread — don't delete or alter the email thread; it's evidence. Third, notify the real vendor through a verified channel (not the compromised thread) to confirm their account details and whether their email was breached. Fourth, assess the vendor's compromise — if their real account was used, they may need to notify other customers who could be targeted with the same access. Fifth, review all recent payments to this vendor for the preceding 30-90 days to determine if this was the first fraudulent instruction or part of a pattern. Then conduct a process review to identify which verification step the attack bypassed — and close it before the next payment cycle runs.

Q12: Can VEC happen to companies that already have a formal vendor onboarding process?

Yes — if the onboarding process captured banking details in an uncontrolled way, or if the process allows updates through email without out-of-band verification. The Quanta Computer case happened at Google and Facebook, two companies with sophisticated security programs. The NTMA case happened at a state body with six-person approval chains. Formal processes are necessary but not sufficient. The specific gap VEC exploits is the update channel — even if the initial banking details were captured properly, a VEC attacker only needs to successfully submit one fraudulent update through an uncontrolled channel to redirect all future payments. The onboarding process has to be paired with an equally controlled process for any subsequent banking changes.

‍