Payroll diversion fraud is rarely a complex cyberattack. It usually involves attackers manipulating staff via phone or email to change bank details. Relying solely on technical controls fails because the breach occurs in human process. You must implement strict verification protocols and segregation of duties to stop these losses.
Myth: This requires sophisticated hacking skills
Reality: Payroll diversion is primarily a social engineering campaign, not a technical exploit. Attackers rarely breach your network perimeter to alter databases directly. Instead, they manipulate employees into making the changes themselves.
The adversary poses as a legitimate stakeholder, such as a supplier or a senior executive. They use persuasion to bypass your technical defences. The complexity lies in psychology, not code.
You might assume that strong firewalls and intrusion detection systems will stop this. They will not. The attacker never touches your infrastructure. They simply convince a trusted employee to update a vendor’s bank account details in your accounting software.
This mirrors the mechanics described in our guide on pretexting, where a fabricated scenario is used to extract information or actions. The goal is to create a sense of urgency that overrides standard caution.
Myth: We only need to protect our email systems
Reality: Email is often just the entry point for the conversation, not the final vector. Attackers frequently move the discussion to instant messaging or phone calls. This isolates the request from email security tools.
Your email filters may catch the initial phishing attempt. However, the attacker then calls the victim, citing the previous email as context. This technique is known as spear-phishing followed by voice-based social engineering.
The request to change bank details arrives verbally. No malware is present. No suspicious attachment is opened. Your email security posture is irrelevant to the final action.
This is why understanding attack vectors is critical. The vector shifts from digital to human interaction mid-campaign. If you only monitor email traffic, you miss the actual compromise.
Myth: Multi-factor authentication stops these attacks
Reality: Multi-factor authentication (MFA) protects account access, not the integrity of actions taken within that account. If an employee willingly changes a bank account number, MFA has already succeeded.
The authentication system confirms the user is who they say they are. It does not validate whether the request is legitimate. The attacker relies on the employee’s authority to make changes.
This is distinct from MFA fatigue attacks, where bombardment forces a user to approve a login. Here, the user approves the action themselves. They believe they are helping a colleague or supplier.
MFA prevents unauthorized access to the finance system. It does not prevent authorised users from making erroneous or manipulated decisions. You need process controls, not just access controls.
Myth: Automated bank verification solves the problem
Reality: Automated verification checks if the account exists, not if it belongs to the correct entity. Attackers open legitimate bank accounts in the victim’s name or use compromised accounts.
The payment passes the initial validation because the details are technically correct. The money lands in a real account. This delays detection until the supplier complains or the transaction is reviewed manually.
Relying on automated checks creates a false sense of security. The system sees a valid IBAN or sort code. It does not see the intent behind the change.
This is similar to how DNS spoofing can redirect traffic to a valid-looking but malicious server. The destination is real, but the context is wrong. You must verify the intent, not just the syntax.
Myth: Small changes are harmless and can be batched
Reality: Attackers often request small, incremental changes to avoid triggering fraud alerts. A slight alteration to a sort code or account number may look like a typo.
Security teams often ignore minor discrepancies to avoid disrupting business operations. The attacker counts on this tolerance. They test the waters with small requests before moving the entire payroll.
Batching changes without individual verification increases risk. A single unchecked error can cascade into a massive financial loss. Each change must be treated as a high-risk event.
This relates to account lockout policies in a broader sense. Just as you limit login attempts to prevent brute force, you must limit unverified changes to prevent process abuse.
Myth: Internal staff are immune to this pressure
Reality: Internal employees are frequent targets because they have the authority to make changes. Attackers impersonate CEOs or board members to command immediate action.
This is known as Business Email Compromise (BEC) or CEO fraud. The attacker exploits the hierarchical structure of your organisation. Subordinates are conditioned to obey senior leadership.
The request is often framed as confidential or urgent. The employee is told not to inform others. This isolation prevents collateral verification.
You must establish a culture where questioning authority is standard procedure for financial changes. Trust must be verified, not assumed, regardless of the requester’s perceived rank.
Summary of Myths and Realities
| Myth | Reality |
|---|---|
| Requires sophisticated hacking | Relies on social engineering and human error |
| Email security is sufficient | Attackers move to phone or chat to bypass filters |
| MFA stops the fraud | MFA verifies identity, not the legitimacy of the action |
| Automated checks are enough | Checks validate format, not ownership or intent |
| Small changes are safe | Incremental changes avoid detection thresholds |
| Internal staff are safe | Impersonation of leadership exploits hierarchy |
Key takeaways
- Attackers target the human element of finance processes, bypassing technical security layers entirely.
- Segregation of duties prevents a single individual from executing and approving payment changes.
- Out-of-band verification requires confirming changes through a separate, trusted communication channel.
Payroll diversion is a process failure, not a technical breach. Implement strict out-of-band verification for all financial changes, regardless of the source.
Frequently asked questions
How do I verify a bank change request securely?
Contact the requester using a known, trusted phone number or email address that you have on file, not the one provided in the request. Confirm the details verbally before making any changes.
What is out-of-band verification?
It is a security practice where you confirm a transaction or request through a different communication channel than the one used for the initial request. For example, if a change is requested via email, you verify it via a phone call.
Can AI tools detect payroll diversion attempts?
AI can flag unusual language or urgency in communications, but it cannot replace human judgment. It serves as an additional layer of alert, not a definitive block. Human verification remains the final control.
Why do attackers target payroll specifically?
Payroll involves large sums of money and regular, predictable transactions. Once bank details are changed, the funds are moved quickly before the error is noticed, making recovery difficult.
How this guide was produced: written by the Breach Observer editorial team with AI assistance, checked against the public references listed below, and reviewed when the facts change. See our editorial policy or report an error.