Payroll Direct Deposit Fraud Prevention: Verify Bank Changes Before Release
Updated: Oct 25
An email asks payroll to replace an employee's deposit account before Friday. The attachment looks convincing, the name matches the employee record, and the account passes a basic validity check. None of those facts establishes that the employee authorized the new destination.
A safer process confirms the instruction through a trusted route, checks the account information separately, and ties approval to the exact destination used in the payment. A saved profile change should remain distinguishable from permission to send wages there. If a suspected diversion has already reached the payment process, establish its status and contact the bank or payroll provider immediately.
This playbook is for U.S. employers controlling payroll direct-deposit additions and changes. It includes a copyable Bank-Change Release Card, three fictional requests and a response sequence for money already sent. The suggested controls are an operating design to adapt with your bank, provider, security team and legal reviewer. They do not guarantee recovery or determine who bears a fraud loss.
When choosing a payroll provider, use bank-change controls as a selection requirement. SelectSoftware Reviews offers a free conversation to help you identify providers to evaluate. Bring your independent-confirmation, destination-approval and payment-status questions to the discussion.
Table of contents
Separate the employee's instruction from the bank-account check
Payroll diversion can enter through two different doors. Someone can impersonate an employee and persuade an administrator to change the account. Someone can also compromise an employee or administrator account and make the change inside the real payroll system. The second route can produce a genuine system audit entry even though the instruction is fraudulent.
Ask two questions independently: did the employee authorize this particular instruction, and do the destination details meet the bank's account-checking requirements? A routing-number check does not establish who owns the account or whether the employee authorized the change. An account that can receive money may still belong to a fraudster.
Nacha's ACH developer guidance describes several account-validation methods, including prenotifications and services that may verify different account attributes. Record what your method actually checks. Account status, routing validity, ownership information and possession of small test deposits are different results. Do not label all of them simply “verified.”
A prenotification is a nonmonetary ACH entry used to check account information before a live payment. It can support the account-checking step under your bank's process. It should not be treated as independent proof that the employee requested the change. Confirm the applicable waiting period, responses and handling of failures with the bank or provider rather than assuming an instant pass.
Likewise, an uploaded voided check or bank letter supplies information for review but does not authenticate the person submitting it. A reviewer should explain what the document established, where it came from and what remains unresolved. Avoid collecting additional identity documents merely to make the folder look stronger; use the employer's secure collection process and collect only what it needs.
For a split deposit, verify the whole instruction. A small fixed amount can be diverted while the remaining wages continue to the usual account. The employee might notice a smaller deposit rather than a missing paycheck. Record the account additions, removals, allocation amounts or percentages, priority and remainder destination as one version.
Shared or joint accounts need an explanation under the employer's account policy, not an automatic fraud conclusion. Similarly, an unfamiliar financial institution, a new employee or an urgent request can justify review without proving misconduct. Establish the relevant facts before accepting the instruction or accusing anyone.
Two checks before release: confirm the employee's instruction and check the destination attributes. A successful account check does not replace employee confirmation.
Give each request a trusted route
Publish a clear place to request changes and a separate way to report a suspicious change. Employees should reach the real payroll portal through an established bookmark or the employer's known internal route. An unexpected message inviting them to log in should not become the route used to decide whether that same message is authentic.
For an administrator-assisted change, contact the employee using a previously established number or another independent channel documented by the employer. Do not use a new number supplied in the change request. The FBI's business-email-compromise guidance recommends verifying payment changes directly and looking up contact information independently when an unsolicited message is involved.
Prepare a short confirmation conversation: identify the employee through the identity check documented by the employer, establish that they requested a deposit change, and confirm the destination and allocation through the secure procedure. Do not ask for passwords, one-time login codes or full bank details in an ordinary email reply. Never instruct an employee to read you an authentication code so you can complete their login.
A callback loses its independence when the same request also replaces the employee's phone number. Put a combined contact-and-bank change through a separate identity-resolution path using records established before the disputed changes. A manager's familiarity with the employee can help locate them, but a forwarded email or “I know this person” approval does not establish the new payment instruction.
Self-service needs its own design. Require the authentication controls selected by the employer's security team and supported by the system, protect recovery methods, and restrict the permissions that can change accounts or disable safeguards. The IC3 warns that attackers can capture credentials and one-time codes through fake sites and social engineering. A successful login is useful evidence, but it is not a guarantee that the employee made the request.
Where the system supports notifications, send a change notice through the established contact route and give the employee a clear way to dispute it. Check whether a contact change can redirect or suppress that notice. A notification that goes only to the newly supplied address is a weak opportunity for the original employee to detect an unauthorized update.
Keep a practical route for employees who cannot use the portal, including accessibility needs, leave, travel or lost devices. That route should provide a controlled identity and instruction check, not a blanket rejection of legitimate requests. A consistent process lets payroll explain the next step without forcing an employee to disclose sensitive information through an unsuitable channel.
Bind approval to the destination that will actually be paid
Approval should identify an instruction version, not merely an employee name. Record the masked destination, the secure source holding its complete details, the allocation, the effective run and the evidence supporting the decision. An approver should be able to distinguish an approved old account from a newly entered account awaiting review.
Separate authority to enter bank information from authority to authorize its first use wherever the operating model permits. A second reviewer should examine the destination and evidence independently, rather than only approve a batch total. Nacha's payroll-origination checklist includes independent confirmation and a second person confirming and releasing the transaction.
For a small team, define a backup approver before the usual reviewer is absent. Give that person the necessary secure evidence and release authority. A review performed after wages have been sent can detect a defect, but it does not provide the same prevention as approval before first use. Document any remaining gap honestly.
Before payroll release, compare the changed-account population with the approved instruction versions. Include employee self-service edits, administrator changes, imports, provider support changes and any other route capable of changing the destination. If the review sees only one channel, its reassuring total may hide changes made through another.
The actual preview or payment output matters. Suppose the approved instruction sends a fixed amount to one account and the remainder to another. A profile screen can look correct while an imported allocation or a generated payment uses an older remainder account. The release reviewer needs the destination information available in the output, not just the current employee screen.
Limit complete bank-data access to people whose work requires it. Use masked references in the general release log and store the full instruction in the restricted source record. Masking is a display safeguard, not a reason to skip the secure comparison of the full details when authorized reviewers need it.
Treat any destination edit after approval as a new version needing review. Apply the same rule when a file is regenerated or a provider changes an instruction while handling a support ticket. Record which output was approved and prevent a later output from inheriting permission without a comparison.
Set the cutoff and exception route with the provider's actual processing calendar. There is no universal cooling period in this playbook. A waiting period can create time for checking and employee dispute, but it does not prove identity. A request near cutoff should receive an explicit decision about verification, first use and a safe payment alternative.
Use the Bank-Change Release Card
Copy one card for an account addition or change, including a changed split deposit. Keep it in a restricted payroll workflow. Use secure record references and masked account identifiers rather than placing full banking details in a broadly shared spreadsheet.
The card follows the instruction from intake to its first actual payment. Complete the relevant fields as the work advances. “Pending” is an honest state; a blank field should not be interpreted as a passed check. Record who owns the next action and when it is due.
Request and independent confirmation
1. Employee and employer: Record the employee identifier, employing entity and responsible payroll team. Confirm that the instruction applies to the correct employment record.
2. Original request: Record the intake channel, receipt time and secure evidence reference. Preserve the original message or submission rather than replacing it with a rewritten summary.
3. Instruction version: Identify what changes: account, allocation, priority, remainder destination or removal. Assign a version and keep the full details in the restricted source record.
4. Independent contact source: Record how the employee was reached and where that contact information came from. State whether contact details changed recently or in the same request.
5. Employee confirmation: Record the documented identity method, reviewer, time and confirmed instruction. State unresolved discrepancies or a denial explicitly.
Destination and first-use decision
6. Account-checking result: Name the validation method, date, result and attributes actually checked. Record any waiting period, unresolved response or failure under the bank/provider process.
7. Masked before-and-after reference: Identify the old and proposed destination versions and complete allocation. Include joint-account or other policy exceptions that require an authorized decision.
8. First eligible payroll: Record the intended pay date, run identifier and actual processing cutoff. Distinguish an employee's requested date from the run approved for first use.
9. Entry and approval: Record who entered the version and who independently approved it. Capture the approval evidence and any authorized exception, rather than just “manager approved.”
10. Hold or release decision: Select HOLD, APPROVED FOR SPECIFIED RUN or INCIDENT ESCALATION. A hold blocks use of the proposed destination; it does not decide whether wages can be delayed.
11. Payment alternative: If the new destination cannot be approved in time, record the authorized wage-payment route, its owner and deadline. Confirm that an older account remains usable before proposing it.
Output, notice and closure
12. Actual output comparison: Record the preview or payment-output version and reviewer. Confirm the complete destination and allocation against the approved instruction, with no later unreviewed edit.
13. Employee notice: Record the trusted notification route and time, plus a clear dispute contact. State whether the employee disputed or acknowledged the change; do not invent an acknowledgment.
14. First-use outcome: Record transmission status and the provider or bank evidence available for settlement, return or another result. “Submitted” alone is not proof the employee received wages.
15. Follow-through: Record unresolved action, responsible person and next checkpoint. Close only after the intended change and any incident or replacement work have documented outcomes.
Before releasing the first payment, the reviewer should be able to answer:
Was this exact instruction independently confirmed with the employee?
Does the recorded account check support the claimed result?
Is the actual output the approved destination version and allocation?
Is first use authorized for this run, with no open dispute or unreviewed change?
Can a different operator locate the evidence and explain the decision?
Do not average these checks into a fraud score. An unanswered authorization question should remain unanswered even if several technical checks passed. If the instruction cannot be established, hold the proposed destination and route the unresolved pay decision to the authorized reviewer.
Handle three awkward requests without losing the control
A convincing email arrives at cutoff
A fictional employee, Maya, appears to request a new account an hour before the provider cutoff. The message includes a bank letter and says her phone is broken. Payroll receives a second message from a supervisor asking for quick help.
The bank letter may support a destination check, but the employee's instruction is still unconfirmed. Payroll uses an established contact route or the employer's alternative identity process. It records the supervisor's message as context, not as a substitute for Maya's confirmation.
If the employee cannot be reached in time, the new destination stays on hold. The payroll owner must decide a timely authorized payment route with the appropriate legal or HR reviewer. Continuing to use the old account also needs confirmation that it is usable; an account reported closed is not a safe default.
A real portal change follows a contact change
Another fictional employee, Luis, has a genuine portal audit entry showing a new phone number, a password reset and a changed remainder account shortly before payroll. Only $100 continues to his usual account, which makes the proposed split seem less disruptive.
Payroll reviews the sequence as a possible compromise and independently contacts Luis using information established before those changes. It checks who initiated the recovery and whether notifications were redirected. The normal-looking $100 destination does not authorize the remainder instruction.
If Luis denies the change, stop first use of the disputed version and involve the security team. Preserve the audit events and affected output. Restoring an older account screen does not establish whether a payment file containing the disputed account has already been sent.
An import changes a previously approved allocation
A third fictional employee, Erin, confirmed a joint account through the documented identity and instruction checks. The account review and policy exception are documented. After approval, an HR integration replaces the split allocation using older data.
Here, the problem is the output version rather than an unverified employee request. Compare the imported instruction with Erin's approved version, resolve the difference and review the regenerated output before release. Do not reject the joint account merely because it is shared.
The three cases lead to different actions: unresolved confirmation, incident escalation, and correction of a mismatched output. Use the card to preserve that distinction. A single label such as “bank details checked” would conceal what each reviewer still needs to decide.
If payroll has already been sent, act by payment status
On a suspected diversion, immediately contact the payroll provider or originating bank through a trusted established route. Supply the relevant employee, employer, run, amount, destination reference, transmission time and available trace information through its secure incident process. Ask what has actually happened and what action remains possible now.
The FBI advises contacting the financial institution immediately after suspected business email compromise. Do not wait for the next payroll cycle or for every internal approval to finish before notifying the people who can investigate the payment. Assign an incident owner to coordinate updates without turning the coordination step into a delay.
Not transmitted: Prevent the disputed instruction from entering a live output. Identify and replace or cancel affected files and scheduled instructions through the authorized process. Verify the resulting state; an edit to the employee profile does not cancel a file that already exists.
Transmitted, settlement not established: Ask the bank or provider whether stopping or deleting the instruction is still possible. Record its answer and confirmation. Do not mark a payment stopped merely because someone requested a stop, or assume that scheduled settlement guarantees time to act.
Settled or status unknown: Request urgent fraud handling and ask the originating bank which recovery process applies. Nacha permits an originating bank to request a return for any reason under its request-for-return process, but the receiving bank's compliance is optional. A request is not recovered money.
Returned or recovered: Confirm the actual credit, returned amount and related reference. Track any shortfall and fees separately. Then verify the employee's intended payment and any replacement; a return can resolve part of the bank incident while leaving the wage-payment question open.
An ACH reversal is not a general undo button. Nacha identifies permitted erroneous-entry reasons and states that a qualifying reversal must reach the receiving institution within five banking days following settlement. Ask the bank to determine eligibility and timing rather than calling every suspected fraud an incorrect-receiver reversal.
Preserve relevant messages, instruction versions, approvals, portal events, payment outputs and bank communications. Coordinate security containment with preservation: revoke compromised access and review affected recovery methods, sessions and notifications without needlessly destroying the evidence needed to establish what happened. Follow the security team's incident process.
Report the incident through the appropriate law-enforcement route, including IC3 where applicable. Involve the authorized legal, HR and payroll decision makers in the employee-payment and notification questions. This guide does not decide wage liability, reimbursement, deduction authority or a jurisdiction's replacement-pay deadline. Bank recovery and the decision about wages require separate owners and recorded outcomes.
Payment-stage response: identify the actual stage with the bank or provider. A profile correction, stop request, return request and recovered credit are different outcomes.
Choose provider controls that survive exceptions and imports
Ask a current or proposed provider to demonstrate how bank information moves into the payment, using fictional data. A feature name such as approval workflow does not show whether an import, support administrator or employee recovery process can bypass it. Obtain the applicable package scope and responsibility split in writing.
Give the provider these proposed demonstrations:
Enter a legitimate change and show which person can approve its first use.
Change contact information and the bank destination together; show authentication, notices and review.
Approve one allocation, then import a different version; show whether approval is invalidated or the difference is surfaced.
Have the normal reviewer absent; show the backup route and retained evidence.
Generate an output, edit the destination afterward and show what changes in the transmitted instruction.
Report a suspected diversion after transmission; identify the support route, status evidence and bank handoff.
Use these cases when discussing a shortlist. SelectSoftware Reviews can help you identify payroll providers to compare. Ask each provider to show its specific bank-change approval path and the evidence it supplies when a payment is disputed.
These are acceptance cases to request, not claims that a provider has passed them. Record the observed behavior, unanswered questions and commitments. In particular, ask what account-validation results mean, whether they include ownership information and who handles inconclusive results.
A small organization may be able to run a restricted change log and independent first-use review without buying another tool. Higher change volumes or multiple import channels make complete reporting and enforceable permissions more important. Choose the control that closes the observed bypass; purchasing a general fraud feature does not automatically establish a trustworthy instruction path.
Review access for provider staff and integration identities as well as employer administrators. Ask who can change a destination, reset authentication, change notification details or release an output. Establish the evidence available after each action and the support process for restricting access during an incident.
If changing providers, settle responsibility for instruction versions, pending validations and held accounts before the first live run. An exported current account list can lose the reason an instruction was held. Carry the decision state into the new workflow and compare the first actual output with approved destinations rather than silently treating all migrated accounts as newly approved.
Keep a small monitoring routine that catches bypasses
Assign a reviewer to examine changed destinations before each release and disputed or returned payments after processing. Use a population that includes all change channels, not only requests submitted through the preferred form. Match changes to release cards and investigate unmatched first uses.
Review patterns that warrant explanation: repeated contact-and-bank changes, many employees pointing to one newly introduced account, changes after approval, unexpected support edits or notices that did not reach established contacts. These are review triggers, not proof of fraud. Household accounts and authorized shared arrangements can create legitimate matches.
Use case results to find the failed boundary. Was the employee never contacted independently? Did a recovery method permit takeover? Did an import overwrite approval? Was the wrong output reviewed? Assign a specific repair and check it on the next relevant case. Counting completed requests alone will not reveal those differences.
The 2026 Nacha fraud-monitoring requirements extend under Phase 2 to all non-consumer ACH Originators, Third-Party Senders, and Third-Party Service Providers performing ACH processing for an Originator, sender or originating bank, regardless of volume. They require risk-based procedures appropriate to the party's role, reviewed at least annually and updated for evolving risks. The rule does not prescribe this card or a universal waiting period.
The stated Phase 2 effective date was June 19, 2026; Nacha's operations bulletin explains that the practical date was June 22 because of the federal holiday. Confirm your employer's role, bank agreement and provider responsibilities. Outsourcing processing should lead to a documented allocation of the required work rather than an assumption that the employer has no remaining role.
Keep secure evidence under the applicable retention and incident-preservation requirements. Avoid indefinite duplicate collections of full bank details in email attachments or personal folders. The release card should point to the controlled evidence, while permissions and deletion decisions remain with the authorized record owner.
Finally, tell employees how to recognize the real signup or login route, how legitimate account changes are confirmed, and where to report a change they did not request. Practice the response with fictional information before an incident. The useful outcome is a team that can identify the disputed instruction, stop its next use where possible, and explain the actual payment status without guessing.
If the review reveals a bypass your current setup cannot close, document that requirement before replacing software. SelectSoftware Reviews offers a free advisor conversation about possible provider options. Keep the required demonstration and responsible bank contact explicit.
Explore more payroll operating controls. Browse the Decision Guides.
About the author
Ben Scott writes and maintains payroll decision guides for founders and operators. His work focuses on execution realities and how decisions hold up under growth, complexity, and controls and documentation pressure. He works hands-on in HR and leave-management roles that intersect with payroll-adjacent workflows such as benefits coordination, cutovers, and compliance-driven process controls.
