# What is social engineering in payment fraud?
Social engineering in payment fraud is deceiving a person into making or approving a payment. Process controls stop it; training alone does not.
---
Social engineering in payment fraud is the use of deception to get a person who can approve, release or change a payment to do so for someone who has no right to the money. Nothing is broken into: the payment system works exactly as designed, and a genuine, authorised member of staff sends a genuine payment to the wrong place because a request looked and sounded legitimate.
The National Institute of Standards and Technology, in its digital identity guidelines, defines social engineering as "the act of deceiving an individual into revealing sensitive information, obtaining unauthorized access, or committing fraud", achieved by gaining the person's confidence and trust. The last of those three outcomes is the subject here. This article is written for the people who prepare, approve and release payments, and for those who audit them. It describes what a deceptive request looks like from the recipient's side and which organisational controls answer it. Rules on liability and reimbursement differ from one country to the next; the one national rule described in detail is the United Kingdom's, and it is named as such. This is general information, not legal advice.
$123,005reported loss per business email compromise complaint in the United States in 2025
58%of the money in incidents handled by the FBI's recovery process in 2025 was frozen
£85,000maximum reimbursement per claim under the United Kingdom's authorised push payment rule
First two figures from the FBI Internet Crime Complaint Center's 2025 annual report (the first computed from its totals); third from the Payment Systems Regulator's consumer page on reimbursement.
## What does social engineering mean when the target is a payment?
Social engineering aimed at a payment means that the control being defeated is a person's judgement, not a password or a firewall. The request reaches someone with real authority over money, and the aim is that this person uses that authority willingly.
That distinction matters for how you audit the risk. A technical intrusion leaves a system doing something it was not meant to do, and the evidence is in logs. A socially engineered payment leaves every system doing what it was meant to do: the user logged in with their own credentials, the approval was given by an approver, the bank received a valid instruction. Authentication confirmed the employee; nothing confirmed the party who made the request.
Regulators draw the same line with the word "authorised". The Payment Systems Regulator in the United Kingdom describes authorised push payment scams as those that "happen when someone is tricked into sending money to a fraudster posing as a genuine payee". The payer pushed the payment themselves. That is different from unauthorised fraud, where a card or account is used without the holder's knowledge, and the difference usually decides who bears the loss.
Two kinds of request make up most of the exposure in a business. The first asks for a payment: an invoice, an urgent transfer, a deposit. The second asks for a change to where a future payment will go: new bank details for a supplier, an employee or a party to a deal. The second kind is quieter, because the payment that follows is a routine one that nobody examines.
## Why are payments the target of social engineering?
Payments are the target because the last step before money moves is a human being who can be asked. However strong the technical defences around a payment system, someone inside the organisation has legitimate power to instruct it, and a persuasive request reaches that person through ordinary channels.
Three features of payment work make the request easier to pass off as normal.
- **Requests arrive from outside all day.** Accounts payable exists to receive instructions from other organisations.
- **The work is routine and time-bound.** Payment runs have cut-off times and closings have dates. A request timed just before a deadline gets less scrutiny.
- **Many payments cannot be pulled back.** A bank transfer that has been collected by the recipient, or an onchain payment once confirmed, is not reversed by the payer changing their mind. The check has to happen before release.
The figures published by the FBI's Internet Crime Complaint Center show what this means in money. Its report for 2025 recorded 1,008,597 complaints and $20.877 billion in reported losses across all categories. Business email compromise, which the report describes as "a scam targeting businesses or individuals working with suppliers" and businesses that regularly make wire transfers, accounted for 24,768 complaints and $3,046,598,558 in reported losses. Phishing and spoofing, a far more common complaint at 191,561, accounted for $215,843,126.
Reported loss per complaint, by categoryUnited States, 2025, US dollars; reported losses divided by number of complaints
Computed from the complaint counts and reported losses in the FBI Internet Crime Complaint Center's 2025 annual report. A loss that began with a phishing message is often recorded under the category of the fraud that followed, so the last bar understates what phishing leads to.
The pattern is the useful part. Requests aimed at a business payment are rare compared with mass phishing, and each one that succeeds costs about a hundred times more.
## Which levers of persuasion do deceptive payment requests rely on?
Deceptive payment requests rely on a small set of ordinary human responses: deference to authority, reaction to urgency, trust in the familiar, willingness to keep a confidence, and consistency with a step already taken. These are the habits that make a finance team cooperative and efficient, which is why awareness of them does not switch them off.
The practical response is to pair each lever with a control that does not depend on the recipient resisting it. The table gives the pairing.
| Lever | What the recipient experiences | Control that neutralises it |
| --- | --- | --- |
| Authority | A request in the name of a director, a lawyer, a regulator or a bank | The approval matrix applies to every requester; a senior name never replaces a second approver |
| Urgency | A deadline today, a penalty, a deal that will fail | A written rule that verification is completed before release, with a named person who can accept the delay |
| Familiarity | A known supplier's name, logo, tone and invoice layout, or a known voice | Identity is confirmed through contact details already on file, never through the message itself |
| Secrecy | "Keep this confidential", "do not involve the usual team" | Confidential payments follow the same path; a request to bypass colleagues is itself a reportable signal |
| Prior commitment | A small, harmless request first: confirm you are at your desk, confirm the balance, send a form | Each request is assessed on its own; earlier replies create no obligation to complete the next step |
Two points follow from this pairing. First, the levers are usually combined: a senior name, a confidential matter and a deadline in the same message. The site's article on rushed-closing pressure looks at the urgency lever alone, in the setting of a closing. Second, every control in the right-hand column is a rule about process, written down in advance. The person under pressure does not have to win an argument with the requester; they only have to say that procedure requires a call back.
## What forms does social engineering take, channel by channel?
Social engineering reaches payment staff through five channels: email, telephone and voice, messaging, in person, and a supplier whose own systems have been compromised. The channel changes what the recipient sees; the request underneath is the same.
National agencies define the main terms in plain language. The Federal Bureau of Investigation describes spoofing as "when someone disguises an email address, sender name, phone number, or website URL", and says phishing schemes "often use spoofing techniques to lure you in". It defines vishing as scams that "happen over the phone, voice email, or VoIP (voice over internet protocol) calls" and smishing as scams that "happen through SMS (text) messages". The United Kingdom's National Cyber Security Centre describes phishing as scam emails or text messages containing links to malicious websites, describes targeted phishing as messages that use information about your staff or your company to be more convincing, which is what the term spear phishing refers to, and defines whaling as "a type of spear phishing that targets a 'big phish', such as a board member who has access to valuable assets".
| Channel | What the recipient sees | Control at the point of receipt |
| --- | --- | --- |
| Email | An invoice, a change-of-details notice or an executive instruction, often inside a real thread | Check against the supplier record; confirm any change by calling a number on file |
| Telephone and voice | A caller who knows names, amounts and timing, and asks for action during the call | End the call and ring back on a number held before the call |
| Messaging | A short text or chat message from a "new number" of a colleague or a director | Treat a new number as unverified until confirmed through the old one or in person |
| In person | A visitor, courier or contractor asking for access, a document or a signature | Visitor procedure; payment documents accepted only through the normal intake route |
| Compromised supplier | A message from the supplier's real mailbox, with correct history, carrying new bank details | Bank details change only after verification outside email, whatever the sender address shows |
The last row deserves the most attention from an auditor, because it defeats inspection of the message. When a supplier's mailbox is being used by someone else, the address and the thread are real, and no amount of careful reading reveals it. The articles here on business email compromise and on spoofed domains cover the email forms in detail, and the article on deepfake voice calls covers the case where the voice on the telephone is synthetic. What they have in common is the conclusion of this section: the recipient cannot reliably tell a genuine request from a well-prepared false one by examining the request.
## Why is staff training alone not enough?
Staff training alone is not enough because it asks people to detect, under time pressure and every time, something that is designed to be undetectable. Training raises the share of false requests that are noticed; it cannot raise it to all of them, and one missed payment request can cost more than a year of the training budget.
The National Cyber Security Centre says this plainly in its phishing guidance for organisations. It states that phishing mitigations "often place too much emphasis on users being able to spot phishing emails", and that "no training package, including phishing simulations, can teach users to spot every phishing attempt". Its recommended approach is layered, in four parts: make it difficult for such messages to reach users, help users identify and report suspected messages, protect the organisation from the effects of the ones that go undetected, and respond quickly to incidents. The third layer is where payment procedure sits. The guidance asks organisations to ensure staff are familiar with the normal ways of working for key tasks, giving how payments are made as its example, and that "all important email requests are verified using a second type of communication".
Training still earns its place, with a narrower purpose than detection. It should teach three things: what the normal process is, so that a departure from it stands out; that the levers in the table above are a signal in themselves; and how to report in under a minute.
## What do process controls add?
Process controls add a check that works even when the recipient is fully convinced. Three of them do most of the work: verification out of band, separation of the power to change details from the power to pay, and a no-blame reporting rule.
**Verification out of band.** Any new payee, any change of bank details and any payment outside the normal pattern is confirmed through a different channel from the one the request arrived on, using contact details the organisation already held. The second half of that sentence is the control. Calling the telephone number printed on the new invoice, or replying to the email, confirms nothing. The article on verifying that you are paying the right person sets out the call-back procedure step by step.
**No single person able to both change details and pay.** The person who can edit a supplier's bank details in the master file should not be able to release a payment to that supplier, and the reverse. With the duties separated, a deceptive request has to convince two people through two different procedures, and the second person sees a change they did not make. This is the long-established audit principle of segregation of duties applied to the two actions that matter most. In a small organisation where one person does both, the substitute is an independent review of every change of details by the owner or an outside bookkeeper before the next payment run.
**A no-blame reporting rule.** Staff must be able to say "I think I acted on a false request" the moment they suspect it, without fear of the consequence. The National Cyber Security Centre is direct on this: "blaming users for clicking on links doesn't work", and organisations should avoid "a punishment or blame-oriented culture". Recovery depends on speed, and a member of staff who expects discipline will spend the first hour hoping they were wrong.
A further control applies where one payment is shared among several parties, such as a deal with a broker, a referrer and a seller: fixing the destinations before the payer acts. Shaka, a payment router, works this way. Each party's share is set as a percentage of the deal and can be signed by each recipient before the client pays, the client pays once, and every party is paid at the same moment. Because destinations are fixed and signed before the payment, they cannot be redirected by a last-minute message. That narrows one window; it does not replace establishing who each recipient is when the deal is set up.
## Which signals in a payment request should prompt verification?
The signals that should prompt verification are departures from the normal process, not flaws in the message. A request can be perfectly written, come from a real address and still be false; what it usually cannot avoid is asking for something the normal process would not ask for.
Use the following as a checklist at the point of preparing or approving a payment. Any single item is enough to stop and verify.
- The request changes where money goes: new bank details, a new account name, a new country or a new bank for an existing payee.
- The account name does not match the legal name of the party you owe, or a personal account is given for a business.
- The request arrives close to a cut-off, a closing date or the start of a holiday, and says so.
- The requester asks you not to call, says they are unreachable by telephone, or supplies a new number for verification.
- The request asks for confidentiality or for a named colleague to be left out.
- A senior person asks directly for something that normally comes through a department.
- The amount sits just under an approval threshold, or a payment is split so that each part does.
- The supplier's invoice is correct in every respect except the payment details.
- You feel hurried, flattered or uneasy. The Cybersecurity and Infrastructure Security Agency lists "urgent or emotionally appealing language" first among its signs of phishing, and advises looking up another way to contact the organisation directly.
The list is about the request, not about spelling or logos: a well-prepared request contains no presentation errors, so their absence is not evidence of anything.
## What should an organisation measure?
An organisation should measure whether its payment controls were actually applied, not how many staff completed a course. Four measures cover it: the share of detail changes verified out of band, the number of users who can both change details and pay, the reporting rate on suspicious requests, and the time from suspicion to report.
A worked example, with illustrative figures, shows how the measures read. Take an accounts payable team that releases 4,800 supplier payments a year at an average of $18,500, receives 96 requests to change supplier bank details in that year, and has 40 staff who can receive payment-related requests.
| Measure | Illustrative figure | How to read it |
| --- | --- | --- |
| Detail changes per 100 payments | 96 on 4,800, or 2.0 | The size of the population to verify; it is small |
| Changes verified out of band | 91 of 96, or 94.8% | 5 exceptions; each is an unverified destination for an average $18,500 |
| Cost of verifying every change | 96 calls of 12 minutes: 19.2 hours, $864 at $45 an hour | 4.7% of one average payment, for the whole year |
| Users able to change details and pay | 3 | The target is zero; each one is a single point of failure |
| Reporting rate on test requests | 92 of 160, or 57.5% | 40 staff, four exercises; 14 acted on the request (8.75%) and 54 did neither |
Three readings matter. The five unverified changes are the finding, not the 94.8%: together they represent $92,500 of payments sent to destinations nobody confirmed, and an auditor should ask who approved each exception and why. The cost line shows why "we have no time to call" is rarely true, since verifying every change in the year costs less than a twentieth of a single average payment. And the 54 test requests that were neither acted on nor reported are a gap in the reporting habit: those staff recognised something and told nobody, which in a real case leaves the next recipient unwarned.
Time from suspicion to report governs recovery, and it can only be measured if reports are logged with a time through a single, simple route.
## What does the United Kingdom's reimbursement rule for authorised push payment fraud cover?
In the United Kingdom, payment firms must reimburse victims of authorised push payment fraud for payments made on or after 7 October 2024, up to £85,000 per claim, under a requirement set by the Payment Systems Regulator. The rule covers individuals, microenterprises and charities; it does not cover larger businesses.
The regulator's own page for consumers gives the terms. The payment must be a bank transfer between accounts in the United Kingdom made over Faster Payments or CHAPS. Victims can expect reimbursement within 5 business days of making a claim, and firms have up to 35 business days to reach an outcome where they need to gather more information. A claim should be made as soon as possible and within 13 months of the payment. Firms may apply an excess of up to £100, which cannot be applied to vulnerable consumers. The cost of reimbursement is split 50:50 between the sending firm and the receiving firm. The regulator states that the £85,000 maximum covers over 99% of claims.
The limits are as important as the cover. Card, cash and cheque payments fall outside the rule and have their own protections. So do civil disputes, where a genuine supplier was paid and the goods or services were not delivered or were defective. A firm can refuse a claim where the customer was complicit in the fraud or grossly negligent, which the regulator calls a high bar and which does not apply to vulnerable consumers.
For a finance team the conclusion is narrow. A company above microenterprise size that pays a false invoice by bank transfer is outside this rule, and so is any payment sent abroad. Other countries allocate the loss differently. Reimbursement rules protect some payers in some places; they are not a reason to relax the checks before release.
## What should you do on realising a request was not genuine?
On realising a request was not genuine, contact your bank or payment provider at once to ask for the payment to be recalled, then report, preserve the evidence and warn colleagues. The first hour matters more than anything done later.
The FBI's Internet Crime Complaint Center gives the same order in its annual report: "Immediately, contact your financial institution and request a recall of the funds", then file a complaint with full transaction details whatever the amount. Its report for 2025 shows why speed matters. The recovery process it runs with financial institutions handled 3,900 incidents involving $1,163,919,846 of attempted theft and froze $679,013,183, a success rate of 58%. In the United Kingdom the Payment Systems Regulator directs victims to report first to their bank or payment firm.
Response in outlineThe order matters; the first two steps are done within minutes
Call the bank or payment providerUse the fraud line or your relationship contact, give the payment reference, amount, time and recipient account, and ask for a recall and for the receiving institution to be notified.
Tell the person responsible internallyUnder the no-blame rule, report to the named contact straight away so that pending payments to the same recipient are stopped.
Report to the authoritiesFile with the national reporting body for your country and keep the reference number; your bank and insurer may ask for it.
Preserve the evidenceKeep the original messages with their technical headers, call records, the invoice and the approval trail. Do not delete or forward-and-delete anything.
Contain the channelIf a mailbox, yours or a supplier's, appears to be in someone else's use, have it secured and tell the supplier through a number on file.
Review the control that did not operateRecord which check was skipped or absent, and correct the procedure before the next payment run.
The site's article on responding after a payment fraud attempt takes each of these steps further, including notification duties and insurance. A recall request made in the first minutes depends on a member of staff who felt able to say, without delay, that something was wrong.