AegisAI Perspectives · 131
A SaaS startup with no security team should verify each vendor bank change by calling a known number and require dual approval for payments over a limit.
See it on your own Google Workspace or Microsoft 365 tenant. No MX change.
Or get the Q3 2026 State of the AI Attack report (free, instant download)
Not ready for a demo? Check your domain (free, about 10 seconds).
A SaaS startup with no security team should confirm every vendor bank change outside email, with a strict call-back verification process for any change in bank details8. BEC losses reported to the FBI reached $3,046,598,558 in 20251.
AegisAI reads the thread the way an analyst would: the sender’s history, the change being asked for, and where the reply actually goes16. If you run IT for a SaaS startup of 20 to 500 people on Microsoft 365 or Google Workspace, with a lean IT or security team and no SOC, this is the payment process for you. The FBI says to verify all payment changes in person or via a known telephone number3, and NCSC Ireland advises dual approval for financial transactions over a set threshold9. The email side is on the inbound email security page. How vendor email compromise works in general is in how to protect against vendor email compromise, and the wider tool choice is in email security for SaaS companies.
A bank detail change arrives in three places: an email thread, your billing or bill pay tool, and the vendor's own portal. At a startup with no finance team, the person who pays vendors is often a founder, an operations lead or an outside bookkeeper.
NCSC Ireland names supplier fraud as a common scenario: a vendor's email is compromised and used to send fake invoices or change payment details7. The request arrives as a reply inside a real conversation, from a compromised mailbox22.
A change there often starts with an email that says the details were updated and asks you to refresh them. Treat that email as the request itself.
Nacha advises a two-step process with vendors: any change to account information or payment instructions is confirmed outside the channel that asked for it4. The owner of each channel reports any suspicious payment request to the person who pays vendors before anything changes.
Write down the three channels and one named owner for each this week.
Short on time? Watch the explainer, or book a demo.
Build a vendor contact sheet with one phone number per vendor, taken from the signed contract or the onboarding call, never from an email. Keep it in the billing tool's vendor record with change history on, where an email cannot edit it.
Write one rule: every change to bank details or payment instructions is confirmed outside the channel that asked for it.
Call the vendor back on the number in the sheet. The FBI says to verify all payment changes in person or via a known telephone number. When a phone call requests the change, Nacha says to call the requester back on a known phone number5.
Never use a phone number, link or contact name from the change email. When the vendor's mailbox is compromised, that number can reach the attacker.
Ask the contact one question only the real account manager can answer, such as the last invoice amount. Some victims report they were unable to distinguish the fraudulent phone conversation from legitimate ones15.
Require a second person to approve the change and the first payment to the new account. NCSC Ireland advises dual approval for financial transactions over a set threshold. For bank changes, set that threshold at zero.
Turn off automatic forwarding to outside addresses, and review mailbox forwarding rules after any suspicious request. Nacha lists email forwarding rules among the gaps to scan and scrub6.
Log every change: who asked, through which channel, who called back and who approved. The FBI calls verifying all requests for a change in payment type or location the best defense14.
Print the eight steps and give them to whoever pays vendors today.
A hijacked vendor mailbox signs as itself, so SPF, DKIM and DMARC pass18. Microsoft notes that impersonation can pass those checks too, when the attacker creates a lookalike domain and publishes valid DNS records10. Lookalike senders are covered in vendor impersonation email detection.
Google Workspace can protect against messages where the sender's name is in your directory but the email is not from your domain12. Its default action keeps the email in the inbox and shows a warning13.
AegisAI research found 3 in 10 confirmed phishing emails cleared native Gmail and Microsoft filters in Q3 202625. Attackers also use AI: in 2025, businesses reported losses over $30 million to BEC scams involving AI2.
Turn on the impersonation settings in Microsoft 365 or Google Workspace anyway, then judge your email layer on the case they skip.
| Check | What it catches | When the real vendor mailbox sends it | Inbound email security |
|---|---|---|---|
| SPF, DKIM and DMARC | Senders that fake your vendor's domain | Pass, because the mailbox signs as itself | Does not rely on authentication19 |
| Microsoft 365 impersonation protection | Impersonation of people and domains you list | A lookalike domain with valid DNS records passes SPF, DKIM and DMARC | Weighs what this sender has sent you before and the request |
| Google Workspace name spoofing setting | Outside senders using a directory name | A vendor is not in your directory | Catches fake vendors and payment requests with no link or file21 |
| Call-back on a number from the sheet | Payment changes verified in person or via a known telephone number | Still works, because it never touches email | Not an email control. Keep it either way |
| Blocking before delivery | Mail stopped in the mail path | Depends on what the filter flags | No edge. It connects by API and works after delivery, with a median verdict of 1.9 seconds20 |
| Real bank changes flagged | Not measured by the filter | Not measured | Occasionally, with the evidence attached so an analyst can clear it in seconds23 |
The before-delivery row gives the inbound layer no edge: it works after delivery. Keep the call-back and the second approver whatever email layer you run.
AegisAI investigates every email for what it is trying to do, and removes the ones that fail from every mailbox they reached17. Authentication passes, so the verdict does not rely on it: it rests on what this sender has sent you before and on the request itself. Run it in monitoring mode on live mail with no MX change, then turn on removal24.
Illustrative example, figures are fictional: Fernlight Analytics (fictional) is a 70 person SaaS startup on Google Workspace. Its operations lead pays vendors, and there is no security team. At 16:40 on a Friday, a reply lands in a six month thread with its cloud data vendor: new bank details from the 1st, signed by the usual account manager. Every sender check passes, because the vendor's mailbox was taken over. The email offers a "direct line" for questions. The operations lead ignores it and calls the number from the signed contract. The real account manager sent no such email. The second approver never sees a change to approve, the payment goes to the old account, and the vendor resets its mailbox.
Run this walk with your own top three vendors this month.
Track three numbers, each from a record you already keep.
To see which change requests reach your inboxes today, start a monitoring-mode trial. Put the three numbers in front of the person who pays vendors on day 30.
Use a strict call-back verification process for any change in bank details, on a known telephone number. Require dual approval for financial transactions over a set threshold. On the email side, AegisAI reads the thread the way an analyst would: the sender’s history, the change being asked for, and where the reply actually goes.
Then sender authentication passes, because the mailbox signs as itself. A call-back on a known telephone number confirms the change. An email layer has to judge the request and the sender's history, not the authentication result.
Two people: the one who pays vendors and a founder or finance lead. NCSC Ireland advises dual approval for financial transactions over a set threshold. For bank changes, set that threshold at zero.
BEC losses reported to the FBI were $3,046,598,558 in 2025, against $2,770,151,146 in 2024. In 2025, businesses also reported losses over $30 million to BEC scams involving AI.
Microsoft notes that impersonation can pass email authentication checks when the attacker creates a lookalike domain and publishes valid DNS records. Google Workspace's default action for these settings keeps the email in the inbox with a warning.
