Money Sent to the Wrong Account
A payment to the wrong account is frequently unrecoverable, usually preventable, and increasingly the result of somebody impersonating an employee.
Nobody elseif the person who does this is away
A payment sent to the wrong account is frequently unrecoverable, almost always preventable, and increasingly the result of somebody pretending to be an employee rather than of a typing error.
The exception in “Money Sent to the Wrong Account” needs evidence that can be checked rather than one unexplained total. Used for employee scheduling software, open the current product description can provide time and project context, but a payroll correction should still rely on approved records, the payroll ledger and a documented human review.
It is the one payroll error where the prevention is genuinely worth more than the cure, because the cure often does not exist.
For an outside reference relevant to “Money Sent to the Wrong Account”, consult NI Business Info payroll guidance. Compare general guidance with the employer’s jurisdiction, contracts and current payroll process.
The two causes
A transcription error when details were entered, and a fraudulent change request. The first is old and shrinking; the second is now the more common and the more expensive.
The two causes, and the shift between them:
- A transcription error when details were entered. Old, shrinking, and prevented by reading back once at the moment of adding.
- A fraudulent change request. Now the more common and the more expensive, and prevented only by confirming through a second channel.
How the fraudulent version works
A message arrives, apparently from an employee, saying they have changed bank and giving new details. It is timed near a pay date, it is polite, and it asks for the change to be made before the run.
The money goes, the real employee is unpaid, and the account is emptied before anybody notices.
Why small businesses are targeted
Because the request goes to one person who knows everybody, which feels like a safeguard and is not. Familiarity makes the message plausible rather than making the sender verifiable.
The defence, entire
Confirm every bank change through a different channel from the one it arrived on. A known telephone number, or in person.
Not a reply to the message. Not the number in the message. One minute, every time, without exception.
Why "without exception" matters
Because the request will arrive at the worst moment, phrased urgently, from somebody you know. The exception is the entire attack.
A rule applied when convenient is not a rule.
Telling people the rule exists
Once, at induction and in writing: we will always ring you to confirm a bank change. It makes the real requests smoother and tells anybody attempting the other kind that the route is closed.
The transcription version
Entering details from what the person supplied, read back character by character, once, at the moment of adding.
Retyping from a message you have already retyped once is where digits move.
What happens when it has gone
Tell the bank immediately — speed is the only variable that matters — and understand that recovery depends on whether the funds are still there and on the receiving bank's cooperation.
It is frequently not possible.
Paying the person
They are owed their wages regardless of where the money went. A business that treats this as the employee's problem has misunderstood both the obligation and the situation.
Pay them, today, by a verified route.
Reporting it
To the bank, and to whatever authority handles this where you are. Worth doing even when recovery looks unlikely, because patterns are how this gets stopped for other people.
Checking for the others
Check whether other change requests have been received recently and not scrutinised, and whether anybody else was targeted.
These attempts usually arrive in batches.
The internal version
Rarer and real: someone with access changing details to an account they control. It is one of the arguments for separate logins and for a record of who changed what, which a shared login destroys.
What to put in the written sequence
Bank changes verified by a second channel, and new account details checked at the approval step.
Two lines, and they close the most expensive single failure available in this subject.
Why familiarity is the vulnerability
In a small business the person handling the change knows the employee personally, and that feels like a safeguard. It is the opposite: the message is plausible precisely because the relationship exists, and the request arrives phrased the way that person would phrase it.
Knowing somebody does not verify that a message came from them, and the entire attack depends on those two things feeling like the same thing.
Making the rule survive pressure
The request will arrive urgently, near a pay date, from somebody you like, with a reason. That is the design.
A rule that holds has no exception for urgency, no exception for seniority, and no exception for "I spoke to them about it last week". One minute on a known number, every time.
Telling people the rule at induction
A sentence when somebody joins: if you ever change your bank details, we will ring you on your known number to confirm before changing anything.
It makes genuine requests smoother, because the call is expected rather than insulting. It also closes the route, and anybody attempting the other kind finds out that the business has a procedure.
The attempt that was not actioned
Worth noting and worth mentioning to whoever else handles payroll or finance. These arrive in batches, aimed at several businesses at once and sometimes at several people in the same one.
A message that was spotted and ignored is information rather than a non-event.
The request never actioned on its own say-so
A bank change is the only routine payroll request that should never be actioned on the strength of the message that asked for it.