## TL;DR
Vendor email compromise succeeds because the mail often comes from the real vendor account, taken over, so authentication passes and only content and process signals remain: a bank detail change, urgency, and a thread hijacked mid-conversation. The BEC rule needs those behavioural signals, but the decisive control is procedural: no bank change is actioned from email alone. Tune detection, then verify the live request out of band before any payment moves.

```text
vendor email compromise wire-fraud phish failed to trigger bec rule
```

## Use this when
- Finance received a bank-detail change or urgent payment request from a vendor address.
- A known vendor account was later confirmed compromised and its mail passed your filters.

## Not for this skill when
- The request is a routine invoice on existing bank details. Normal AP handling applies.
- The vendor domain is a lookalike, not the real account. That is domain impersonation with different evidence.

## Steps
1. Freeze any pending payment tied to the request until verification completes. Verify: finance confirms the hold in writing.
2. Inspect the message for BEC signals: reply-to mismatch, thread hijack position, new bank details and pressure language, and record which your rule should have caught. Verify: the missed signals are listed.
3. Verify the request by calling the vendor on a number from your records, not from the email. Verify: the vendor confirms or denies the change through the independent channel.
4. Tune the BEC and anti-phishing policy: enable vendor and finance impersonation protection and first-contact safety tips, and add a rule flagging bank-detail language from external senders to finance. Verify: the tuned settings are active for finance users.
5. Hunt for other mail from the vendor account in the compromise window and review each payment-adjacent thread. Verify: no other fraudulent instruction is pending.

## Variant phrasings
### vendor email compromise bank details change bec detection
The bank change variant.
### bec rule missed wire fraud supplier impersonation tuning
The tuning variant.

Compatibility: Defender anti-phishing BEC signals, finance payment verification procedures.

## Why it happens
Authentication proves the account, not the intent. A compromised vendor account passes SPF, DKIM and DMARC, so filters must score behaviour and content, which are weaker signals, and process controls carry the real weight.

## Edge cases / pitfalls
- A callback procedure only works if the number predates the suspicious mail. Numbers in the message are attacker-controlled.
- Thread hijacking means the early messages are genuine. Judge the specific instruction, not the thread history.
- Report the compromise to the vendor through your independent contact; their other customers are targets too.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Y2ItMJljqlDNXPGbx31x2A