Payroll Diversion Fraud: Stop Direct Deposit Scams

Payroll diversion fraud happens when a criminal changes an employee's bank details in the payroll or HR system so the next salary payment lands in an account the criminal controls. It arrives two ways: an email or call that impersonates the employee and asks payroll staff to update direct deposit details, or a takeover of the employee's own HR self-service login, where the criminal makes the change themselves and hides the alerts. The FBI has warned about both since 2018, and US ACH rules that took effect in 2026 now name payroll impersonation as a fraud type that payment originators must monitor for. This guide covers how the scheme works, the verification flow that stops it, hardening HR and payroll portals, detection, and what to do when a salary has already gone. It is written for payroll and HR operations leads, identity and security teams, and the people who run HR platforms. For the wider finance picture, see the Business Email Compromise Awareness for Finance Teams Guide.

Key takeaways

A bank detail change is a payment instruction. Treat every change to an employee's direct deposit account with the same care as releasing a payment, because that is its effect on the next pay run.
Email is never the verification channel. A change requested by email, chat or phone is confirmed by calling the employee on a number already held in the HR record, or in person, never through contact details in the request.
Self-service portals need phishing-resistant sign-in. The FBI's original warning described criminals phishing payroll logins and then adding mailbox rules so employees never saw the change alert; passkeys or security keys on the HR portal remove most of that path.
Timing controls catch what people miss. A cooling-off period before a new account receives pay, a notification to the old contact channels, and a hold on changes made just before payroll cut-off stop most losses even when verification fails.
Speed decides recovery. Diverted salaries are usually moved on within hours, so the employer, the paying bank and the receiving bank need to be contacted the day a missing salary is reported, with a report to IC3 or the national fraud service.

How payroll diversion works

Payroll diversion is a form of business email compromise aimed at a narrower target: the employee master record rather than a supplier invoice. The FBI's 2018 public service announcement (I-091818-PSA) described criminals phishing employees for their login credentials, signing in to the employee's payroll account, changing the bank account, and adding rules to the employee's mailbox so that notifications of the direct deposit change were hidden. Deposits were often redirected to prepaid card accounts. The FBI named education, healthcare and commercial air transport as the sectors most affected at the time.

A year later, the FBI's 2019 BEC announcement (I-091019-PSA) reported 1,053 complaints of this payroll variant between January 2018 and June 2019, with total reported losses of $8,323,354 and an average loss of $7,904 per complaint, and said losses from direct deposit change requests had risen more than 815% in that period. Individual losses are small next to invoice fraud, which is why the scheme persists: one salary rarely triggers the controls built for large supplier payments. The FBI's Internet Crime Report 2024 does not break payroll out separately, but records 21,442 BEC complaints and $2,770,151,146 in reported BEC losses for that year.

Route	What the criminal does	Where it is caught
Impersonation request to payroll	Sends an email from a lookalike or free webmail address using the employee's name ("I have changed banks, please update before Friday"), sometimes with a forged bank letter	Payroll verification callback to a number on file; sender checks; external email tagging
Compromised employee mailbox	Sends the same request from the employee's genuine mailbox after phishing it, and sets inbox rules to hide replies	Callback (the email itself looks genuine); inbox rule alerts
HR self-service account takeover	Phishes the HR or payroll portal login, or reuses a leaked password, and edits the payment election directly	Phishing-resistant MFA; change notifications to old channels; cooling-off period; sign-in risk monitoring
Help desk password or MFA reset	Calls the IT or HR help desk as the employee, gets the password or MFA reset, then edits pay details	Help desk identity verification; alert when a reset is followed by a bank change
Insider or payroll operator	A payroll user changes a record without a request from the employee	Segregation of duties; second-person approval; change reports reviewed outside payroll

The help desk route deserves attention. CISA's advisory on Scattered Spider (AA23-320A) describes the group persuading help desk staff to reset passwords and MFA, then registering its own MFA factors for persistence. The same technique works against an HR portal. The Marks and Spencer cyberattack shows how impersonation through an outsourced help desk can defeat otherwise strong passwords and MFA. See the Account Recovery and Help Desk Security Guide.

The verification flow that stops it

The single control that defeats the impersonation routes is an out-of-band confirmation with the real employee, using contact details that existed before the request arrived. The FBI's 2019 announcement recommends verifying account change requests through a secondary channel or two-factor authentication. Build it as a written procedure, not a judgement call:

Accept changes only through approved channels: the HR self-service portal (preferred) or a defined form. Requests by email, chat, text or phone are not actioned; the payroll team replies pointing to the portal and starts the verification below.
Call back on the number held on file: use the phone number in the HR record as it stood before the request, or confirm face to face or through the line manager on a video call where the employee is recognised. Never use a number, link or attachment from the request.
Ask questions the employee can answer and a fraudster cannot easily look up: avoid date of birth and address, which are often already compromised. Asking the employee to confirm the request from within the portal while on the call is better still.
Record the evidence: who called whom, on which number, at what time, and who approved. A second payroll user approves before the change is saved.
Apply the cooling-off rule: new bank details take effect from the next pay run after a set period (many organisations use several working days), and changes inside the payroll cut-off window go to the following cycle unless a manager and payroll lead approve an exception after a second verification.
Notify the old channels: send a confirmation to the employee's previous personal email and phone and to the work mailbox, saying a change was made and how to report it if they did not make it.

In some payment systems a zero-value test entry or account validation service can confirm that the new account exists and, where name checking is available, that it is in the employee's name. Account validation confirms the account, not the requester, so it complements the callback rather than replacing it. The Invoice Redirection and Supplier Bank Detail Fraud Guide covers the same callback discipline for suppliers, and the Authorised Push Payment (APP) Fraud Guide explains payee name checks.

Hardening HR and payroll self-service

Self-service portals reduce the load on payroll and remove email from the process, but they move the risk to the login. The FBI's 2018 recommendations include separate credentials for payroll and for other services such as staff surveys, monitoring logins outside normal hours, and two-factor authentication on sensitive systems. In practice:

Put the portal behind single sign-on: the HR and payroll application should use the workforce identity provider so that MFA, conditional access, device checks and session controls apply, and so that leavers lose access when their account is disabled. See the Identity Lifecycle Event Design Guide.
Require phishing-resistant MFA for payment changes: CISA's phishing-resistant MFA fact sheet classes FIDO/WebAuthn and PKI-based MFA as resistant to phishing, while one-time codes and push are not, and SMS and voice are also exposed to SIM swap. Where the whole portal cannot move yet, require a passkey or security key as step-up authentication for the payment election page. See the Phishing-Resistant MFA Guide.
Lock down MFA registration: registering a new MFA method should itself require a strong existing factor, raise an alert, and block payment changes for a period afterwards. Attackers who reset MFA through a help desk register their own factor first.
Protect personal contact fields: treat changes to personal email and phone numbers with the same step-up and notification as bank details, because they control where change alerts go. A change of phone number followed by a change of bank account within days is a strong fraud signal.
Send alerts the attacker cannot suppress: notify through more than one channel, including the work mailbox and an SMS or app notification, so a mailbox rule alone cannot hide the change.
Limit payroll operator power: payroll users who can edit bank details should not also approve their own changes or run the payment file. Review admin and integration accounts in the HR platform; integration users that write to payment elections are high-value non-human identities. See the Workday Integration System Users Guide and the Workday Security Guide for one platform's model.

Decision guidance: small and large organisations

Situation	Recommended approach	Trade-off
Small organisation, outsourced payroll bureau, no self-service	Written rule: bank changes only on a signed form handed in or confirmed by phone call from the owner or office manager to the number on file; bureau told never to act on email instructions	Slower for staff, but the number of changes is small
Mid-size, payroll SaaS with self-service	SSO and MFA on the portal, step-up on payment changes, notifications to old channels, cooling-off period, weekly change report reviewed by someone outside payroll	Some support load when employees change phones
Large or multi-country, enterprise HCM	Phishing-resistant MFA, risk-based conditional access, change velocity rules, SIEM correlation of sign-in risk with payment changes, help desk verification standard, segregation of duties enforced in the HCM role model	Needs identity, HR systems and SOC to share ownership
High-risk population (frontline, shift or seasonal staff without corporate devices)	Allow change only in person or via a kiosk, or through a manager-verified video call; delay effective date to the next full cycle	Less convenient, but these groups are often targeted with weak, reused passwords

Where an organisation must choose between strict email rules and fast self-service, self-service with phishing-resistant MFA is safer than any email-based process, because it removes the impersonation route entirely. The worst position is a portal with password-only sign-in plus a payroll team that also accepts email requests: two routes, both weak.

Detection and measurement

Most payroll diversion leaves traces in three places: the identity provider, the mailbox and the HR system. Correlating them is where detection works.

HR audit log: changes to payment election, personal email, personal phone and address, with the source (self-service, payroll operator, integration), IP address and session. Alert on a payment change within a set number of days of a password reset, MFA registration or contact detail change.
Identity provider: risky sign-ins, unfamiliar locations or ISPs, sign-ins outside the employee's normal hours (named in the FBI's 2018 advice), new MFA registrations, and help desk resets.
Mailbox: new inbox rules that delete messages, move them to obscure folders such as RSS and mark them read, or filter on words like "direct deposit", "payroll" or "bank". Microsoft's alert grading playbook for inbox manipulation rules lists the audit operations New-InboxRule, Set-InboxRule, UpdateInboxRules and Set-Mailbox as the events to review.
Payment file: several employees changed to accounts at the same bank or the same account number, accounts at prepaid card or neobank issuers when the employee previously used a high-street bank, and changes clustered just before cut-off.

In the US, Nacha's 2026 fraud monitoring rules (Phase 1 from 20 March 2026, Phase 2 from 19 June 2026) require non-consumer originators, third-party senders and service providers to run risk-based processes to identify entries suspected of being unauthorised or authorised under False Pretenses, which Nacha defines to include payroll impersonation. Nacha suggests originators may focus on account takeover and payment-change controls for payroll and vendor payments. Receiving banks must also monitor incoming credits, and Nacha lists a rapid series of similar credits, such as several payroll payments, and new or dormant accounts as red flags.

Metric	What it shows	Target direction
Share of bank changes made through self-service with phishing-resistant MFA	How much of the process has left email and weak logins	Rising towards 100%
Share of non-portal change requests with a documented callback	Whether the verification rule is followed	100%
Payment changes within 7 days of an MFA or contact change that were reviewed	Correlation coverage	100% reviewed
Attempted diversions stopped before pay date versus paid out	Control effectiveness	Stopped share rising
Time from employee report of missing pay to recall request at the bank	Response speed	Same business day

See the Fraud Metrics and KPIs Guide for building these into a wider fraud dashboard.

When a salary has already been diverted

The FBI's 2019 announcement advises victims to contact their financial institution to request a recall of funds, to notify the employer about payroll deposit irregularities, and to file a complaint at IC3 whatever the amount; the 2018 announcement asks that "payroll diversion" be noted in the complaint. A workable sequence for the employer:

Same hour: payroll asks the paying bank or payroll provider to recall or return the payment and to alert the receiving bank. In ACH, receiving banks that conclude funds should be returned can use return reason R17, or R06 at the originating bank's request, per Nacha's guidance.
Same day: lock the employee's HR and identity accounts, revoke sessions, remove any MFA methods the employee does not recognise, reset credentials, and check the mailbox for forwarding and hiding rules.
Restore the record: reverse the bank change after verifying the correct details in person or by callback, and pay the employee through an off-cycle payment if policy allows.
Look for siblings: search the HR audit log for other changes to the same destination account, from the same IP addresses, or made through the same help desk agent or integration.
Report: file with IC3 in the US (or Report Fraud (which replaced Action Fraud on 4 December 2025) in England, Wales and Northern Ireland, Police Scotland on 101 in Scotland, or the national equivalent), keep the audit logs, emails with full headers and call records, and consider whether personal data exposure triggers a privacy notification.

For the full response process, see the Business Email Compromise Response Playbook and the Account Takeover Response Playbook.

Framework mapping

Framework	Reference	How it applies
MITRE ATT&CK	T1566.002 Spearphishing Link; T1078 Valid Accounts	Credential phishing for the HR portal and use of the stolen login
MITRE ATT&CK	T1564.008 Email Hiding Rules; T1114.003 Email Forwarding Rule	Mailbox rules that hide change alerts or copy replies
MITRE ATT&CK	T1098.005 Device Registration; T1657 Financial Theft	Registering the attacker's own MFA device; the diversion itself
NIST CSF 2.0	PR.AA-01, PR.AA-03, PR.AT-01, DE.CM-03	Identity and authentication on HR systems, staff awareness, monitoring of personnel activity
NIST SP 800-53 Rev 5	IA-2, AC-2, AT-2, AU-6	MFA for organisational users, account management, awareness training, audit review of change logs
CIS Controls v8.1	6.3; 14.2	MFA for externally exposed applications; training staff to recognise social engineering
ISO/IEC 27001:2022 Annex A	A.5.17, A.8.5, A.6.3	Authentication information, secure authentication, awareness and training

Common failure patterns

Replying to the requester to "confirm": payroll replies to the email asking the sender to confirm. If the mailbox is compromised, the criminal confirms. Only a callback to a number on file counts.
Trusting a genuine sender address: a request from the employee's real work mailbox is treated as verified, when compromised mailboxes are exactly how the more convincing attempts arrive.
Alert only to the channel the attacker controls: the change confirmation goes only to the work mailbox, where a hiding rule deletes it, or only to a phone number the attacker changed the day before.
Help desk resets without strong verification: a caller who knows an employee number and manager's name gets a password and MFA reset, then edits bank details. The Marks and Spencer cyberattack shows what help desk impersonation can unlock.
No cooling-off for last-minute changes: a change made the day before cut-off goes straight into the pay run, leaving no time for the employee to notice the alert.
Payroll SaaS outside SSO: the payroll portal keeps its own password database with optional MFA, so former employees and phished users keep a working login that no identity team monitors.

Practitioner checklist

Publish a rule that bank detail changes are never actioned from email, chat, text or an inbound call, and tell staff about it.
Write the callback procedure: number on file, questions to ask, evidence to record, second-person approval.
Put the HR and payroll portal behind SSO and require phishing-resistant MFA, at least as step-up for payment and contact changes.
Alert and hold payment changes made within a set period after an MFA registration, password reset or contact detail change.
Send change notifications to the old personal contact details and the work mailbox, not only one channel.
Set a cooling-off period and a cut-off window rule for new bank details.
Monitor mailboxes for hiding and forwarding rules mentioning payroll, bank or direct deposit.
Review a weekly report of bank changes, shared destination accounts and prepaid card issuers, owned by someone outside payroll.
Agree the recall procedure with the payroll provider and bank in advance, and rehearse it.
Add payroll diversion examples to awareness training for all staff, and specific drills for payroll and help desk teams.

Payroll Diversion Fraud Guide: Stop Direct Deposit Change Scams