From Treasury Masterminds
Verification of Payee was introduced as an important new weapon against payment fraud. The principle sounds reassuringly simple: before releasing a payment, check whether the beneficiary’s name matches the bank account.
For consumers making individual payments, that can work remarkably well. For corporate treasury teams processing thousands of suppliers, multiple systems and large payment batches, the reality is considerably messier.
During the webinar “VoP in Practice: Where It Actually Works and Where It Fails,” three specialists examined the subject from different angles:
Their conclusion was not that VoP is ineffective. Far from it. But it is not the complete fraud-prevention solution that some organisations may hope it to be.
You can watch a replay of the webinar below:
Matthieu explained that VoP forms part of the EU’s Instant Payments Regulation and must be performed at payment level for relevant SEPA payments within the European Economic Area.
The original intention was to give users more confidence when making instant payments. That makes sense for a consumer creating a beneficiary and sending a single transaction through a banking app.
Corporate payments are different.
Treasury teams usually submit large payment files rather than individual transactions. A single batch might contain hundreds or thousands of suppliers, each potentially returning a match, close match, no match or inconclusive result.
According to Matthieu, no-match rates can reach “up to twenty percent” in some geographies. That clearly does not mean that 20% of payments are fraudulent.
“It should be more taken into account by corporate as a warning mechanism,” he explained.
A no match may indicate an attempted fraud, but it could also result from outdated information, spelling differences, subsidiary names, abbreviations or inconsistencies between legal and commercial names.
VoP therefore provides an important signal, but that signal still needs to be interpreted.
As Matthieu put it, VoP is “definitely not by itself alone a fraud prevention mechanism, because alone this data would not be sufficient.”
From a treasury perspective, Mari described the reaction to VoP as “cautious optimism really rather than just excitement.”
Treasurers have seen controls introduced with considerable fanfare before, only to discover that they do not fully address the operational reality.
The immediate questions are therefore practical:
What does VoP cover?
How reliable is the result?
What happens when the answer is inconclusive?
Who investigates the exceptions?
Can a small treasury team realistically review every mismatch?
The problem becomes particularly visible when a payment batch is ready for release.
Blocking an entire payment run because a small number of beneficiaries return a no match creates its own risks. Suppliers may not deliver goods, invoices may become overdue and relationships may be damaged.
“The payment goes out based on good faith, based on controls, based on banks processing payments overseas,” Mari said when describing the traditional payment process.
VoP adds another layer of information. But when that information only appears immediately before payment, the treasury team is being asked to solve the problem at the latest possible moment.
Maxime argued that waiting until payment is inherently risky.
If an issue is discovered at the end of the process, treasury must choose between delaying the entire payment campaign or accepting the warning and proceeding. Neither option is particularly attractive when suppliers are waiting and commercial deadlines are approaching.
“There is commercial risk because if sometimes you don’t pay, you cannot get the goods to produce what you need to produce,” he explained.
There may also be financial consequences, including late-payment fees.
That is why the panel repeatedly returned to one central idea: verification should start earlier.
Supplier information should ideally be checked when the supplier is onboarded, when bank details are changed and again when the payment is made.
As Maxime summarised it: “Recurrence is the key.”
A supplier may have been valid when it was first created, but circumstances can change. Accounts can be closed, details can be amended, internal systems can be compromised and fraudsters can intervene at different stages of the purchase-to-pay process.
One successful check at onboarding does not create permanent protection.
Checking a supplier before it enters the vendor master sounds logical. In practice, however, onboarding often crosses several departments.
Procurement may own the supplier relationship. Accounts payable may manage invoices. Another team may maintain the master data. Treasury releases the payment. IT controls system access. Compliance or KYC teams may perform additional checks.
That creates a familiar corporate phenomenon: everyone is involved, but no one clearly owns the complete process.
Mari described the problem bluntly:
“There’s no clear end-to-end accountability.”
In that environment, adding another validation step can easily be viewed as additional friction. Each department assumes someone else has completed the check, while the supplier record continues its journey through the organisation with the quiet confidence of data nobody has actually verified.
The scale of vendor databases makes matters worse. Large organisations may have thousands of supplier records, often spread across multiple ERP systems and legal entities.
Without clear ownership, clean data and agreed escalation procedures, VoP simply adds another output that someone must investigate.
During onboarding, Maxime recommended checking three main areas:
First, the company itself. Does it exist, is it active and are there any relevant sanctions or warning signs?
Second, the bank details. Do they make sense in relation to the supplier? A company registered in one country but using an account in an unexpected jurisdiction may deserve additional scrutiny.
Third, the relationship between the two. Does the bank account genuinely belong to the company being onboarded?
He also stressed that information shown on an invoice should not be trusted automatically.
“Never rely on data you will find on an invoice,” he said. Information should be compared with reliable internal records and independently sourced data.
The traditional four-eyes principle remains important, but manual controls have limits. People become tired, rushed or distracted. If employees must perform hundreds of repetitive checks, errors become inevitable.
“The key is to automate everything,” Maxime said.
The objective is not to eliminate human judgement. It is to automate routine confirmations so employees can focus their attention on the smaller number of genuinely suspicious cases.
The discussion became particularly practical when it moved to changes in vendor master data.
Requests may arrive through email and be sent to several people at once. In some organisations, only a designated department can amend supplier records. In others, someone in accounts payable, IT or another function may make the change.
The real vulnerability appears when the request is marked urgent.
“Everything is always urgent,” Mari observed.
An invoice may already be overdue. There may have been a commercial dispute. A supplier may threaten to stop deliveries. Someone senior may appear to demand immediate payment.
That is precisely the pressure fraudsters exploit.
“And that’s where the vulnerability comes in,” Mari said.
Under pressure, employees may bypass the normal callback, approval or verification process. During holiday periods, fraudsters may also target employees who know that managers are unavailable.
Maxime’s advice was straightforward: do not abandon established controls because someone creates a sense of emergency.
One of the webinar’s most important warnings concerned the false reassurance created by a successful match.
VoP largely depends on matching a beneficiary name with an account. But fraudsters may create companies with names that closely resemble legitimate suppliers. They may also use commercial names that imitate familiar brands.
In that situation, the bank may correctly confirm that the account belongs to the stated name. The problem is that the stated name belongs to a fraudulent or misleading entity.
“A match should not be a sign that there is absolutely no fraud,” Matthieu warned.
It only confirms an alignment between the information provided and the information held by the bank. It does not prove that the organisation intends to pay the correct legal entity or that the payment request itself is legitimate.
This creates what Matthieu called the “VoP paradox.”
The control intended to make users safer may also make them less cautious. A green match can discourage further investigation, even when the underlying payment instruction has been manipulated.
Matthieu highlighted the potential value of checking unique corporate identifiers, such as local company-registration numbers or global identifiers, rather than relying only on names. Names can be copied or manipulated. Identifiers are more difficult to imitate.
However, he also noted that support for identifier-based matching remains optional and is not yet consistently available across payment platforms and service providers.
Several audience members mentioned callback procedures as an existing safeguard.
Callbacks can certainly help, but only when they are conducted independently using trusted contact information. Calling the telephone number shown on a suspicious invoice or change request merely gives the fraudster an opportunity to confirm their own fraud with admirable efficiency.
The panel’s message was not that callbacks should be abandoned. It was that no single measure is sufficient.
VoP, callbacks, dual approval, restricted system access, clean master data and automated verification all contribute different layers of protection.
Maxime also pointed to the wider cost of a successful fraud. A €100,000 loss does not merely require €100,000 in additional revenue to recover. A business operating at a 20% margin would need to generate substantially more sales to replace that lost profit.
There are also reputational, commercial and psychological consequences, particularly for the employee who released the payment.
The webinar closed with a discussion about whether vendor master data is the weakest link in the payment process.
Mari’s answer captured the central limitation of VoP:
“It is a check. It’s not a control environment.”
Without reliable vendor data and cross-functional governance, the organisation is simply attempting to catch problems at the end of the process.
Maxime agreed that technology alone cannot solve the issue.
“Fraud isn’t prevented by technology on its own, not by policy alone either,” he said. “It happens when strong governance is backed by trusted and automated verification of the payment data.”
Matthieu added another perspective. The weakest link may not be the master data itself, but the absence of connections between systems and teams.
Treasury may not know that a supplier’s details were recently changed. Accounts payable may not see the warnings available to treasury. Procurement may have information about the supplier relationship that never reaches the payment approver.
Better integration and a clear audit trail can therefore be just as important as the verification result.
VoP gives treasury teams another useful layer of protection. A no match can expose errors or trigger an investigation before money is lost.
But VoP cannot determine intent. It cannot solve poor governance. It cannot clean an unreliable vendor database. And it cannot guarantee that a matching name belongs to the supplier the company genuinely intended to pay.
The most effective approach is therefore continuous rather than transactional:
VoP is not the final answer to payment fraud. It is one part of a wider control environment that must combine people, processes, data and technology.
Fraudsters will continue to adapt. Treasury teams, inconveniently, will have to do the same.
Treasury Masterminds is a community of professionals working in treasury management or those interested in learning more about various topics related to treasury management, including cash management, foreign exchange management, and payments. To register and connect with Treasury professionals, click the button below.
This article is written by our partner, Nilus
Cash flow forecasting in treasury fails structurally, not occasionally. Here are the 5 root causes, what driver-based AI forecasting actually does, and what a 30% accuracy improvement is worth in dollar terms.
Cash flow forecasting is the process of predicting a company’s cash inflows and outflows over a defined horizon – typically 13 weeks (short-term operational) or 12 months (strategic planning). Accurate forecasting requires integrating data from A/R, A/P, payroll, FX, and banking sources – and knowing which inputs are most likely to shift.
Here’s an uncomfortable truth most treasury professionals already know: the forecast is wrong. Not occasionally. Structurally, predictably, every single week. The question isn’t whether it’s wrong – it’s whether you can explain why it’s wrong before someone else points it out.
In 2026, that question has become significantly more consequential. Rising interest rates mean idle cash carries a real opportunity cost. PE sponsors and senior lenders require covenant-compliant forecasts as a contractual obligation, not a best-practice exercise. And boards – having watched CFOs get blindsided by cash crunches in 2022 and 2023 – are holding finance leaders accountable not just for forecast direction, but for forecast variance. “We were directionally right” doesn’t land the same way it used to.
This piece is an honest attempt to explain why forecasting fails, what driver-based AI forecasting actually does (as opposed to the breathless marketing claims you’ve already dismissed), and what a 30% improvement in accuracy is actually worth in dollar terms. No crystal balls. No transformation promises. Just the math.
The 13-week cash flow forecast is the workhorse of treasury operations – and one of the most misunderstood documents in finance. Let’s be precise about what it actually is, because the details matter for everything that follows.
The 13-week horizon isn’t arbitrary. It spans exactly one fiscal quarter – short enough that the inputs are grounded in real transaction data (not budget assumptions), and long enough to support covenant monitoring, revolver management, and operational liquidity planning. If you’re running tighter, you can’t see around corners. If you’re running longer, you’re kidding yourself about the precision.
A complete 13-week forecast includes:
One thing that trips people up: the 13-week forecast uses the direct method – it models actual cash transactions, not accounting income. FP&A typically builds their forecasts using the indirect method, starting from net income and adjusting for non-cash items.
These two methods answer different questions. Treasury needs to know when cash actually moves; FP&A needs to know what the P&L looks like. Translating between them is one of the most friction-generating handoffs in corporate finance – and a root cause of forecast error we’ll return to shortly.
When is a 13-week forecast required?
Always, ideally. But contractually, it’s typically required in three scenarios: PE portfolio company covenant packages (weekly submission is standard), revolving credit facility compliance monitoring, and IPO readiness (SOX preparation requires demonstrable financial controls, and a documented weekly cash forecasting process is part of that).
The 13-week forecast connects to the 12-month rolling forecast – the strategic layer used for board reporting, M&A planning, and long-range liquidity modeling. Best practice is to run both, integrated, so actual weekly cash signals continuously inform the strategic model. Most mid-market companies only have one or the other. That’s a gap worth closing.
Here’s the thing: your forecaster is probably quite good at their job. The forecast is wrong because of architecture, not ability. Here are the five structural reasons it keeps happening:
The bottom line
The problem isn’t the forecaster. It’s the architecture. A skilled treasury analyst running a manually-collected, weekly-batch forecasting process is operating at a structural disadvantage – not because of skill gaps, but because the data pipeline they’re working with was designed for a world that no longer exists.
Let’s put the comparison on paper, because the differences aren’t cosmetic.
| Dimension | Excel / Manual | AI-Native (Nilus) |
|---|---|---|
| Data freshness | Weekly batch | Real-time, continuous |
| A/R input source | Manual submission from A/R team | Automated from ERP + bank data |
| FX rate updates | Weekly manual refresh | Live market rates |
| Forecast horizon | 13-week only (usually) | 13-week rolling + 12-month integrated |
| Variance explanation | Manual post-mortem (if it happens) | Automated driver attribution |
| Accuracy vs. baseline | Baseline | 30%+ average improvement |
| Build time per week | 4-8 hours | <30 minutes (exceptions-based review) |
| Board-readiness | Manually formatted and summarized | Auto-generated board summary |
| Audit trail | None – spreadsheet history is not an audit trail | Full input lineage and approval timestamps |
| Multi-entity / multi-currency | Painful consolidation | Native support |
The column that matters most to most CFOs: variance explanation. Not because they can’t do a post-mortem manually – they can – but because the post-mortem happens after the board meeting, not before it. Driver attribution turns that sequence around. You walk into the room already knowing why the forecast changed. That’s a different conversation.
If you’ve made it this far and you’re still skeptical about AI forecasting claims, good. That skepticism is well-earned – the space has been oversold relentlessly. So let’s be very specific about what driver-based forecasting does and doesn’t do.
It does not predict the future. No system does. Your customers’ payment behavior is influenced by factors no model will ever fully capture.
What it does do is systematically identify which inputs changed and quantify their impact on the forecast. That’s the entirety of the value proposition – and it turns out that’s worth a great deal.
Traditional forecasting tells you: “The week 6 cash position forecast is down $2.1M versus last week.”
Driver-based forecasting tells you: “The week 6 position is down $2.1M. Here’s why: three enterprise A/R invoices totaling $1.4M have shifted 10 days right based on updated payment timing from your ERP. GBP depreciated 1.8% against your hedged position, generating a $390K FX variance. One new A/P outflow of $310K was approved and added to the schedule this morning.”
The number is the same. But the second version tells you which levers to pull – call the three enterprise accounts, review your GBP hedge ratio, confirm the A/P approval is correct. You’re managing drivers, not outcomes.
A well-designed AI forecasting system doesn’t just output a number – it outputs a range and a confidence level for each input driver, based on the historical accuracy of that driver across comparable periods.
A customer that has paid within 3 days of terms for 24 consecutive months gets a different confidence weight than a customer with erratic payment history. The aggregate forecast inherits those confidence levels, which means you know where the uncertainty lives before it becomes variance.
You can walk into the board meeting and explain variance before you’re asked. The forecast is defensible, not just directional. When a board member asks “why was cash $3M lower than forecast last month,” you have a prepared, data-backed answer – not a post-hoc rationalization constructed at midnight before the meeting.
The core framing
This is not a black box. The AI surfaces the math. The CFO makes the call. A forecast that shows its reasoning isn’t just more accurate – it’s categorically more useful than one that only tells you what it predicts.
This is where we put the numbers on the table. Across Nilus customers, the average improvement in cash flow forecast accuracy is 30%+. That’s not a projected improvement from a vendor model – it’s measured against each customer’s pre-implementation baseline.
At StackAdapt, 95% of transaction auto-tagging now feeds directly into forecast inputs, eliminating the manual categorization step and saving more than 30 hours of treasury analyst time per month.
At Optibus, automated real-time cash visibility surfaced $5.5M in stagnant cash that had been sitting in suboptimal positions – undetected by the prior manual process – and enabled its redeployment.
Time saved is meaningful. But the bigger return is the variance reduction. A 30% improvement in forecast accuracy doesn’t sound like much until you do the math on what a cash forecast miss actually costs.
What changed in your last forecast? See the drivers – not just the delta. Ask Nilus →
These two forecasting tools answer different questions and serve different audiences. Conflating them is a common source of organizational friction – and running only one when you need both is a gap that creates blind spots in both directions.
| 13-Week Cash Forecast | 12-Month Rolling Forecast | |
|---|---|---|
| Purpose | Operational liquidity management | Strategic planning, covenant monitoring |
| Frequency | Weekly refresh | Monthly refresh |
| Input basis | Direct cash transactions | Actuals + budget assumptions |
| Primary user | Treasurer, Cash Manager | CFO, FP&A |
| When critical | Covenant compliance, tight liquidity, revolver management | Board reporting, M&A planning, IPO prep |
| AI advantage | Real-time transaction data, automated driver attribution, instant refresh | Scenario modeling, sensitivity analysis, variance attribution across longer horizon |
The integration gap
Most mid-market finance teams run only one of these – typically the 13-week, because it’s required. What they’re missing is the feedback loop: weekly actuals that continuously re-anchor the 12-month model, so the strategic forecast doesn’t drift from operational reality. Nilus supports both, integrated – the 13-week feeds the 12-month automatically.
If you’re a CFO at a PE-backed company, you already know that “best practice” is not the right frame for cash forecasting. It’s a contractual obligation with financial penalties attached.
PE sponsors typically require weekly 13-week cash forecasts as a condition of the credit agreement – submitted to the sponsor, and sometimes to the senior lender, by end of business Monday. The forecast is covenant evidence. It’s not a management tool; it’s a legal document.
Debt covenants – leverage ratio, interest coverage, minimum liquidity threshold – are triggered by actual cash positions.
But the point of the forecast is to see trouble coming 4 to 8 weeks ahead, not the week it hits. That’s the early warning system that keeps treasury out of a technical default conversation.
The consequences of getting it wrong aren’t academic. A covenant breach triggers fee clauses, accelerated lender scrutiny, potential cross-default provisions, and in some structures, acceleration of the debt. Even a near-miss – where treasury identified the risk late and had to scramble – damages the CFO’s credibility with the sponsor in ways that are hard to recover.
Nilus builds a covenant tracking layer directly on top of the cash forecast – automatically flagging when projected cash positions approach threshold levels, so treasury has 4-6 weeks of runway to take corrective action before a breach becomes visible.
That’s not a nice-to-have for PE-backed companies. That’s table stakes. Learn more about how this fits into a broader treasury management system.
The market for cash forecasting software is crowded, and the demos are polished. Here’s how to cut through the noise and ask the questions that actually differentiate systems. (Spoiler: competitors like Kyriba and Trovata have very different answers to some of these)
Treasury Masterminds is a community of professionals working in treasury management or those interested in learning more about various topics related to treasury management, including cash management, foreign exchange management, and payments. To register and connect with Treasury professionals, click the button below.
This article is written by Palm
Categorisation is one of the oldest jobs in treasury. Tag every transaction so the data downstream actually means something: forecasts, Variance Analysis, Cash Positioning, board reporting. For years, treasurers have done it one of two ways: by hand, or with rules. AI is replacing both.
The interesting argument isn’t AI vs manual. Most teams gave up on tagging thousands of transactions a week by hand long ago. The real argument is AI vs rules, because rules are what most TMSs and Excel-based processes still run on. That’s the layer AI is taking out.
Rules look elegant on paper. If the counterparty contains “HSBC” and the amount is negative, tag it as a bank charge. If the description starts with “PAYROLL”, tag it as payroll. Easy.
Reality is messier. Counterparty names change when a vendor rebrands. Payment descriptions get truncated by the bank. A new entity is acquired and starts paying into the same account with a different reference format. A subsidiary in another country sends a tax payment no rule has ever seen. Each of those breaks the rule silently. The transaction either falls into “Uncategorised,” or gets miscategorised and quietly distorts the forecast.
Then there is the maintenance burden. Every new counterparty needs a rule. Every edge case needs an exception. The person who built the engine left two years ago, and nobody is sure which rules are still in use. The library grows, contradictions multiply, and the rules never quite catch up with how the business actually moves money.
Rules work on the world you’ve already seen. They collapse on the one you haven’t.
AI categorisation is pattern recognition with feedback.
The model trains on your historical transactions and the categories a human assigned to each one. It learns the signals that distinguish a customer payment from an intercompany transfer, a one-off bonus from a payroll run, a tax settlement from a supplier payment. Not just the counterparty name, but the amount, the description, the account pair, the currency, the timing, all weighed together.
When a new transaction lands, the model doesn’t ask “does this match any rule?” It asks “which pattern does this look most like?” and outputs a category with a confidence score. Above the threshold, it tags automatically. Below it, the transaction goes to a treasurer for review. Their decision feeds back into the model.
That feedback loop is the key difference. Rules don’t learn. AI does. Every correction makes the next prediction sharper. New counterparties get classified the moment they appear. Description changes don’t break anything. The model handles ambiguity because it doesn’t need an exact match.
Rules need explicit logic. AI captures patterns you’d never think to encode: that a particular customer always pays on the 27th, that a supplier’s invoices come in two amount bands, that a certain intercompany flow only happens at quarter-end. Those signals improve accuracy in ways no rule library could.
And rules don’t scale across entities. AI does. One model categorises transactions across every subsidiary, in every currency, with consistent logic.
The fear with AI is the black box. A good system isn’t one. Every prediction comes with a confidence score and a visible reason. The treasurer can override any tag, and the model learns from that override. Transactions can be marked as System Outliers so they don’t pollute future training. The taxonomy can be set at any level of hierarchy: entity, account, subsidiary.
You keep the control rules gave you. You lose the maintenance burden.
Rules-based categorisation was a step forward thirty years ago. It is now the bottleneck: the library nobody owns, the edge cases nobody covered, the silent miscategorisations nobody catches until the forecast misses.
AI categorisation handles the messy reality of real treasury data, learns from every correction, and stays accurate as the business changes. It isn’t a faster rules engine. It’s what rules engines were trying to become.
Treasury Masterminds is a community of professionals working in treasury management or those interested in learning more about various topics related to treasury management, including cash management, foreign exchange management, and payments. To register and connect with Treasury professionals, click the button below.
This article is written by Trustpair
Imagine discovering that one of your trusted employees had spent years editing real supplier invoices to redirect payments into their own account. That’s exactly what happened at Miami University, which lost over $2.3 million to an internal fraudster. Vendor fraud is a severe and growing threat to UK businesses. The Home Office estimates fraud cost UK businesses £5.2 billion in the year ending March 2024, while fake invoice fraud alone affected 11% of UK businesses in the same period.
In this article, learn the most common types of vendor fraud and how to fight against it with Trustpair.
Phishing emails involve the impersonation of a genuine third party in order to gain access to sensitive information or divert a payment. In the vendor fraud context, this is often called Business Email Compromise (BEC) or Vendor Email Compromise (VEC).
There are different levels of sophistication. Spear phishing involves detailed prior research: fraudsters identify the payment approver’s name, the company’s standard invoicing process, and the real vendor’s email format, often spoofing it convincingly. Busy procurement teams are unlikely to spot the difference.
Pharming goes further, directing victims to malicious websites designed to harvest employee login credentials and gain access to confidential company systems.
A significant and growing threat is AI-enhanced phishing. According to Abnormal Security’s 2026 Attack Landscape Report, 63% of organisations report an increase in email attacks using AI-generated content — text with no spelling errors, accurate tone, and contextually appropriate personalisation. In controlled testing, AI-generated phishing emails achieve a 14% click rate, nearly double the 8% rate for human-crafted attacks.
BEC attacks rose 38% year-over-year in 2025, with Vendor Email Compromise (VEC) — where fraudsters operate from inside a compromised supplier account — growing 67% in the same period (Abnormal Security).
These attacks rely on social engineering tactics. A typical scenario: fraudsters impersonate a known supplier mid-contract and submit a convincing invoice for legitimate-sounding services. Because the supplier relationship exists and no automated verification is in place, the payment goes through unchallenged.
Fraudsters frequently target payments made via Faster Payments and BACS, requesting account detail changes that re-route funds to mule accounts. Given the near-instant settlement of Faster Payments and the direct debit capabilities of BACS, funds can be irrecoverable within minutes. CHAPS payments for high-value transfers carry similar risk.
Internal fraud, also known as employee fraud, is another example of vendor fraud.
In this scheme, an employee exploits their access to submit and conceal fraudulent invoices. They may siphon payments to a shell company, inflate the price of goods or services, or redirect funds to an account they control. Because the employee understands exactly how invoices are normally processed, the fraud can remain invisible for extended periods.
With hundreds or thousands of suppliers in a typical organisation, accounts payable staff are unlikely to flag an invoice that looks and behaves like all the others.
The fraud triangle explains why employees commit fraud through three converging factors:
One example of employee fraud at a British business illustrates this precisely. The financial controller, facing personal financial pressure after her partner became redundant, noticed an existing supplier had ceased trading. She edited a previous invoice, replaced the bank details with those of her own shell company, and deliberately kept each transaction below the co-authorisation threshold. The CFO, busy and trusting of a long-standing colleague, only scrutinised payments to new suppliers. The fraud went undetected, costing the business approximately £20,000.
Under the PSR’s APP fraud reimbursement rules, which came into force in October 2024, banks and payment service providers must reimburse victims of authorised push payment fraud up to £85,000. The PSR reported that in the first three months of the rules being in force, 86% of money stolen through in-scope APP fraud was returned to victims (UK Finance, Fraud Report 2025). While this applies primarily to personal accounts, it is increasing scrutiny on corporate payment controls and reinforcing the need for businesses to demonstrate pre-payment due diligence.
Invoice fraud is a third attack vector. Here, the communication genuinely appears to come from a real supplier, because that supplier’s email or systems have been hacked.
The attacker, operating from inside the compromised supplier account, requests a change in bank account details. They may also submit invoices for goods or services never delivered. These attacks are particularly dangerous because businesses are far less suspicious of established supplier relationships, typically concentrating verification efforts on new vendors only.
According to the Home Office’s Economic Crime Survey 2024, mandate fraud — where fraudsters trick a business into changing bank details to divert payments — affected 7% of UK businesses in the preceding 12 months, while fake invoice fraud was the most common type of fraud, affecting 11% of all businesses.
Sade Telecom, an electrical network company, fell victim to this type of fraud before partnering with Trustpair. Their accounts payable team received a payment detail change request from what appeared to be an existing supplier. Without an automated verification system, they processed the change and sent subsequent payments to the fraudulent account. It was only when the genuine vendor issued a late-payment notice that the fraud was discovered.
Following the incident, Sade Telecom implemented Trustpair to automatically validate payment details before every transaction. The result: 100% of subsequent fraud attempts were blocked, with the solution live within 72 hours.
For UK organisations, mandate fraud most commonly targets BACS Direct Credit and Faster Payment instructions. Because Faster Payments settle in seconds, early detection before payment authorisation is the only reliable defence. Trustpair’s pre-payment validation integrates directly into your payment workflow to prevent fraud at source.
Vendor account validation is the most effective way to prevent all three types of vendor fraud and detect vendor fraud red flags before a payment is ever released.
The process involves cross-checking the details on a supplier invoice against international and domestic databases, verifying:
By automating this validation across every payment cycle, UK finance teams can confirm they are paying who they believe they are paying, not fraudsters who have intercepted the relationship.
Manual checks are slow, inconsistent, and easily circumvented. Automated vendor account validation removes human error and scales to match the size of your supplier base, whether you have 200 or 200,000 vendors.
The three most common vendor fraud schemes are:
Protect your business by validating supplier accounts against verified databases in real time, before every payment. With Trustpair, you can demonstrate the due diligence required under current UK payment regulations while blocking 100% of fraud attempts.
Treasury Masterminds is a community of professionals working in treasury management or those interested in learning more about various topics related to treasury management, including cash management, foreign exchange management, and payments. To register and connect with Treasury professionals, click the button below.
