In this article
You prevent payment fraud in a business by making every outgoing payment pass four gates, each with its own control: who asked for the payment, who is being paid, who approved it, and how it was sent. A request is checked against an order or a contract, the payee's bank details are verified through a channel the requester does not control, a second person approves above a set amount, and the instruction leaves through a banking channel that only named people can use with strong authentication. Daily reconciliation then catches what the four gates missed while the money can still be recalled.
A second approver who sees only a tidy invoice approves a payment to the wrong account; a perfect bank-detail check does nothing against an employee who can create a vendor and pay it alone. The framework below describes the controls one by one, with what each prevents and what each costs in time, for whoever owns the payment process: a finance director, a controller, an office manager, a founder.
Bank tools and their names vary by country and by bank, and the article says which country a tool belongs to. It is general information, not legal, audit or insurance advice.
Illustrative worked example detailed in the last section: a business making 300 supplier payments a month, staff time valued at $60 an hour. The figures are invented for the calculation.
What are the four gates every outgoing payment passes?
Every outgoing payment passes four gates: the request, the payee, the approval and the release. Payment fraud succeeds when one of the four is open, and a control framework is nothing more than a named check, a named owner and a piece of evidence at each of them.
The request gate asks whether the business owes this money at all. The payee gate asks whether the account about to be paid belongs to the party the business owes. The approval gate asks whether someone other than the person who prepared the payment has looked at it with the documents needed to judge it. The release gate asks whether the instruction that reaches the bank is the one that was approved, sent by a person allowed to send it.
An invoice for goods never ordered is a request-gate failure, a genuine invoice paid to a substituted account a payee-gate failure, a payment pushed through by one person under time pressure an approval-gate failure, and a payment file altered between approval and upload a release-gate failure. The matrix below is the framework on one page; the sections after it take the controls in turn.
| Gate | What can go wrong | Control | Evidence kept |
|---|---|---|---|
| Who asked | Payment for something never ordered or never delivered; a request that only appears to come from a manager | Match invoice to order and receipt; requests accepted only through the normal channel | Order, receipt, invoice, name of requester |
| Who is being paid | Bank details that do not belong to the supplier; details changed by an unverified message | Verification at onboarding; call-back on a known number for every change; payee-name check | Call-back log: date, number called, person spoken to |
| Who approved | One person creates, approves and releases; approver sees no supporting documents | Segregation of duties; dual approval above a threshold; limits per person | Approval record with both names and time |
| How it was sent | File altered after approval; banking access shared or taken over; payment by an unusual method | Locked payment file with control totals; individual access with strong authentication; bank limits and filters | File totals, bank user log, release record |
| After release | An error or a diversion found weeks later, when recall is unlikely | Daily reconciliation of bank activity to approved payments | Reconciliation sign-off, list of exceptions |
Where are payment fraud losses concentrated, according to official figures?
Reported payment fraud losses are concentrated in a small number of high-value diverted transfers and, by frequency, in paper checks. The two sources below measure different things and are not to be added together.
The FBI's Internet Crime Complaint Center recorded 859,532 complaints and $16.6 billion in reported losses in its 2024 report, covering individuals and businesses in all categories of internet-enabled crime. Business email compromise, the category in which a payment is redirected through a falsified or taken-over email, accounted for 21,442 of those complaints and $2,770,151,146 in losses, the second-largest category by loss after investment fraud. Dividing the report's own figures gives the shape of the risk: about 2.5% of complaints, about 17% of losses, and roughly $129,000 per complaint on average. Few events, large amounts.
The same report gives the one statistic that justifies daily reconciliation. Its Recovery Asset Team, which works with banks to freeze transfers reported quickly, acted on 3,020 complaints in 2024 with $848.4 million at stake and placed a hold on $561.6 million, a 66% success rate.
The Association for Financial Professionals, the professional body for corporate treasury and finance staff, publishes a yearly survey of its members. Its 2026 Payments Fraud and Control Survey, based on 465 corporate professionals, reports that 76% of organisations experienced attempted or actual payments fraud in 2025 and that checks remain the payment method most often affected, with 58% of organisations reporting check fraud. The survey counts attempts as well as losses, so 76% describes exposure, not the share of businesses that lost money.
How do you control who is being paid?
You control who is being paid by verifying a supplier's bank details once, at onboarding, through a source independent of the invoice, and by treating every later change of those details as a new verification. The payee gate is where the largest reported losses occur, so its controls come first.
Vendor onboarding. A new supplier enters the vendor master file only with a legal name, a registered address, a tax or company registration number checked against the public register where one exists, a named contact, and bank details supplied on the supplier's own document. Whoever enters the record is not the person who requested the supplier, and a second person reviews the record before the first payment. An account in a personal name, or in a country where the supplier has no presence, is a question to ask before paying, not after. Time: about 20 minutes per new supplier.
Call-back on any change of payment details. A request to change bank details, whether it arrives by email, letter, portal message or phone, is confirmed by calling the supplier on a number already held on file from before the request. Never a number given in the request itself. The person calling records the date, the number dialled, the name of the person who confirmed, and reads back the last digits of the new account. The FBI's guidance on business email compromise makes the same point: verify payment requests in person or by calling the person, and verify any change in account number or payment procedures with the person making the request. Time: about 15 minutes per change.
A cooling period. Many finance teams add a hold of a few business days between a confirmed change and the first payment to the new account, and send a notice of the change to the supplier's previous contact address.
Vendor master hygiene. Access to create or edit a vendor is limited to named people, every edit is logged, and a periodic report lists all bank-detail changes for review by someone who makes none of them. Dormant vendors are deactivated: an unused record with live bank details is a payee nobody is watching.
How do you control who asked and who approved?
You control the request and the approval by separating four tasks among at least two people, and by requiring a second approval above an amount the business chooses. The four tasks are setting up a payee, preparing a payment, approving it and reconciling the bank account.
The request. A payment starts from a document, not from a message. For purchases, that is the three-way match: the invoice agrees with the order and with the record of what was received. For payments with no order behind them, such as fees, refunds, deposits and transfers between the company's own accounts, the request names who asked and under what agreement. A request arriving outside the normal channel, such as a direct message from a senior manager asking for a transfer today, is confirmed with that manager by a route already known.
Segregation of duties. In a team of two, one person sets up payees and prepares payments, the other approves and releases, and the owner or an outside accountant reviews the bank reconciliation. In a team of one, the compensating control is review after the fact by someone independent, with bank alerts on every outgoing payment sent to the owner's phone.
Dual approval with thresholds. Two approvals on every payment sounds safest and tends to fail, because the second approver, faced with hundreds of small items, stops reading. A threshold keeps the second look meaningful: single approval below an amount, two approvers above it, and a third or a director above a higher one. The amount is set from the business's own payment history so that the upper tiers cover most of the value with a small share of the volume. The second approver sees the invoice, the order and, for a new or changed payee, the call-back record; an approval screen showing only a name and an amount is not a control. Time: about three minutes per payment for the second approver.
Limits. Each approver has a personal limit, each bank user a daily limit, and each account a ceiling agreed with the bank. Limits do not prevent a fraud; they cap it.
How do you control how the payment is sent?
You control the release by making sure the instruction the bank receives is the one that was approved, sent by a named user through a channel protected by strong authentication. Release is the gate where the bank's own tools do part of the work.
Payment-file integrity. Where payments are exported from accounting software and uploaded to a bank portal, the file is the weak link: between export and upload it sits on a drive where account numbers can be edited. The file is generated and uploaded by different people or passed directly from system to bank without a manual step. A control total, the number of payments and the sum of the amounts, is recorded at approval and compared with what the bank portal shows before release. The releaser checks the account numbers of the largest items against the vendor master. Time: about 10 minutes per payment run.
Access management and strong authentication. Every person who uses the banking portal has their own login; shared credentials make the bank's log useless as evidence. Access is granted by role, reviewed every quarter and removed on the day someone changes job or leaves. Multi-factor authentication is switched on for banking, for the accounting system and, just as important, for email, because that is where requests to change payment details arrive. The FBI's guidance is blunt on this point: set up two-factor or multi-factor authentication on any account that allows it, and never disable it.
Bank tools by payment type. Banks offer controls that sit on their side of the instruction. Names and availability differ by country and by bank, and some carry a monthly fee; the table lists the main types.
| Payment type | Bank-side control | What it checks |
|---|---|---|
| Paper checks | Positive pay, offered by banks in the United States | Each check presented is matched to the list of checks the business issued: number and amount, and payee name in the fuller version |
| Direct debits and ACH debits | Debit blocks and filters | Only pre-authorised originators may pull money from the account, up to a set amount |
| Outgoing bank transfers | Payee-name check before sending | The name entered is compared with the name on the destination account, and a mismatch is flagged to the payer |
| All electronic payments | Dual release, user and daily limits, alerts | A second bank user must release; amounts above limits are stopped; each release triggers a notice |
The payee-name check exists under different names. In the United Kingdom, the operator of the retail payment systems describes Confirmation of Payee as an account name-checking service designed to help reduce misdirected payments. In the euro area, the European Payments Council's Verification of Payee scheme lets a payer check that the name and IBAN of a payee match before making a payment, with answers of match, close match, no match or check not possible. A match confirms that the account bears the name typed in. It does not confirm that the business owes that party money, so it supports the call-back and never replaces it.
Unusual methods. A request to pay by a method the business does not normally use is treated as a change of payment details and goes through the same verification.
What does daily reconciliation catch that the other controls miss?
Daily reconciliation catches the payment that passed every gate and was still wrong, on the day after it left and not at month-end. It compares what the bank shows as paid with what was approved, line by line, and treats any difference as an exception to explain before the day closes.
Recall of a transfer depends on the funds still being in the destination account, and the FBI figures cited above show how much can be frozen when a report is made quickly. Monthly reconciliation gives a diverted payment up to thirty days' head start; daily reconciliation gives it one.
A daily reconciliation covers outgoing items against the approved payment list, debits pulled by third parties against known mandates, checks cleared against checks issued, and transfers between the company's own accounts. It is done by someone who neither prepares nor approves payments. It takes about 15 minutes a day once the bank feed is connected to the accounting system, and it catches plain errors too: duplicate payments, wrong amounts, a payment sent to a supplier's old account.
How do you protect incoming payments?
You protect incoming payments by confirming that funds are real, received in your own account and final before you release goods, services or a refund. On the receiving side the loss is value handed over against a payment that never completes or is later reversed.
Three checks cover most cases. First, the evidence is the business's own bank or account record, never a screenshot, a confirmation email or a remittance advice supplied by the payer. Second, "received" is not "final": a deposited check can be returned after the balance shows as available, a card payment can be disputed for months, and a direct debit can be reversed within the period its scheme allows, while a bank wire or an onchain payment is far harder to reverse once it has settled. The release rule for high-value goods is tied to the method's finality, not to the balance on screen. Third, an overpayment followed by a request to refund the difference is handled only after the original payment is final, and the refund returns to the account the money came from.
How mature are your payment controls?
Payment controls mature in four recognisable stages, from informal trust to tested and measured routines. Each stage is defined by what would be discovered, and when, if a payment went wrong.
| Stage | What is in place | What would happen to a diverted payment |
|---|---|---|
| 1. Informal | One person pays from a shared login; bank details taken from invoices; monthly bank review | Found when the real supplier chases, often weeks later |
| 2. Basic | Individual logins with multi-factor authentication; second approver above a threshold; call-back on changes by habit | Usually stopped at the payee gate; if not, found at month-end |
| 3. Documented | Written policy; call-back log; segregation of the four tasks; daily reconciliation; bank filters and limits | Stopped at one of two gates, or found the next business day and reported the same day |
| 4. Tested | Quarterly access review; periodic test of the call-back on a sample; exception reports reviewed; response plan rehearsed | Stopped, and the attempt recorded and used to adjust the controls |
For a business at stage one or two, the step that changes the outcome most is from two to three: writing the rules down, keeping the evidence and reconciling daily. Stage four matters when volumes grow or when an auditor, insurer or lender asks for proof that the controls operate.
What do you do in the first hour after a suspected fraudulent payment?
In the first hour after a suspected fraudulent payment, you call your bank to request a recall, stop further payments to the same payee, preserve the evidence and report to the authorities. The bank call comes first because recall depends on speed. The steps below are an outline only.
- Call the bank's fraud lineGive the amount, date, destination account and reference, and ask for a recall and for the receiving bank to be contacted. Use the number on file in the response plan, not one found in a message.
- Freeze the payee and the queueBlock the payee record, hold any pending payments to it and pause the current payment run until the scope is known.
- Preserve the evidenceKeep the emails with their full headers, the invoice, the change request, the call-back log, the approval record and the bank confirmation. Change nothing in the mailbox concerned.
- Secure accessReset the credentials and sessions of any mailbox or banking user that may be involved, and check for forwarding rules.
- Report and informFile a report with the police or national reporting centre, which in the United States is the FBI's Internet Crime Complaint Center, and inform management, the insurer and the genuine supplier.
The plan has to exist before the event, since the person who discovers the problem is rarely the person who knows the bank's fraud line.
What goes in a one-page payment policy?
A one-page payment policy states who may do what, above which amounts, with which check, and what happens when a rule cannot be followed. A workable version is a plain list:
- Payments are made only to payees in the approved vendor file; nobody pays from details on an invoice alone.
- A new payee is entered by one person and reviewed by another before the first payment.
- Any change of bank details is confirmed by call-back to a number held before the request, logged, and reviewed by a second person.
- Every payment has a supporting document: order, receipt and invoice, or a named requester and agreement.
- The person who prepares a payment does not approve it. Payments above the stated threshold need two approvers.
- Each approver and each bank user has a stated limit. Amounts are not split to stay under a limit.
- Bank logins are personal, protected by multi-factor authentication, reviewed quarterly and removed on departure.
- The bank account is reconciled every business day by someone who neither prepares nor approves payments.
- Goods and refunds are released only against funds confirmed as final in the company's own account.
- Urgent requests follow the same steps. An approver may refuse to approve without the evidence, and is backed by management for doing so.
- A suspected fraudulent payment is reported at once to the named person, who calls the bank's fraud line.
Controls fail under pressure from someone senior or from a deadline, and a policy that says in writing that delay for verification is correct behaviour protects the employee who causes the delay.
What do payment controls cost compared with one avoided loss?
In the worked example below, the full set of payment controls costs $11,130 a year and one avoided loss is worth $87,400, so a single prevented diversion pays for about 7.9 years of controls. The figures are illustrative, and the calculation can be redone with a business's own numbers.
The example is a business making 300 supplier payments a month, 3,600 a year, with finance staff time valued at $60 an hour all-in. It takes on 60 new suppliers a year, receives 48 requests to change bank details, sets its dual-approval threshold at $10,000, which captures 900 payments or 25% of the volume, runs payments weekly on 48 weeks, and reconciles on 250 business days.
Illustrative figures. Time per task is an assumption for the example, not a measured industry average.
At $60 an hour, 155.5 hours cost $9,330. Bank-side tools are assumed at $150 a month, or $1,800 a year, bringing the total to $11,130: about $928 a month, or $3.09 per payment made.
The loss side takes one supplier payment of $85,000 sent to a substituted account and not recovered, plus 40 hours of staff time for the bank, the police report, the insurer and the supplier, worth $2,400. That is $87,400 before any legal cost. Dividing $87,400 by $11,130 gives 7.9: the controls pay for themselves if they prevent one such loss in about eight years; put the other way, they are worth their cost if the yearly chance of that loss without them is about 13% or more.
The control aimed at the largest reported losses, the call-back on changed details, is among the cheapest at 12 hours a year; it is the control to start with. The two most time-consuming controls, reconciliation and second approval, are the ones most reduced by tooling: a bank feed that pre-matches transactions, and an approval workflow that puts the documents in front of the approver.