Will this bury us in false positives?

The baseline is per vendor rather than global, which is the main source of noise in threshold-based controls. Checks are also weighted towards changes that carry money — bank details, new payees, first-time senders — rather than towards every invoice that happens to be large.

Does it stop a payment on its own?

It can hold one, and the hold is routed to a named approver with the evidence attached. Whether a given check holds or only flags is your configuration. What is not configurable is that a release is a recorded decision by a person.

What signals does it use for impersonation?

The sending domain against the vendor's registered domain, near-matches to that domain, the relationship between a display name and the address behind it, and whether the contact has ever been associated with the vendor before.

How do you treat a legitimate bank detail change?

As an event to be confirmed rather than as an edit to be applied. It is scored against its timing and the payments it affects, and confirmation is recorded against the vendor, so the next change has a history to be read against.

Does it need our ERP data, or can it work from documents alone?

It works better with both. Documents carry the identity signals, the ERP carries the vendor master and payment history that behavioural comparison depends on. Reading only one of the two limits it to the checks that source supports.

Has this been delivered for a customer?

Not as a standalone engagement. The document reading, vendor resolution, rule engine and approval routing behind it are running in delivered payables and claims work; the fraud checks are a use of that same engine, and we would rather say so than imply a case study exists.

← All solutions

Solutions

The payment you stop is worth more than the one you investigate

Impersonation from a domain that reads almost right, bank details changed days before a large payment, and invoices that do not resemble anything the vendor has sent before — checked while the payment can still be held, and routed to a person by name.

Book a demo

Lookalike domain detectionPayment-redirect checksBehaviour against the vendor's own history

Payables

RetailFinancial servicesFraud & anomalyAgentic workflowAudit trail

The problem

Payables fraud rarely looks like fraud at the moment it succeeds. It looks like a familiar vendor, a plausible invoice and an email asking that this month's payment go to a new account. The domain is one character out. The bank change arrives shortly before the largest invoice of the quarter. The amount is a little above what that vendor normally bills, which nobody notices because nobody holds a picture of what that vendor normally bills. Controls that check whether an invoice is arithmetically correct pass all of this, and the loss is discovered when the real supplier asks where their money went.

What the platform does

Three checks run alongside the ordinary payables validation. Sender and vendor identity is tested against the registered domain and the known contacts, so a lookalike domain or a display name that does not match its address is surfaced rather than read past. Bank detail changes are treated as events in their own right, scored against their timing and against the payments they would affect. Behaviour is compared against the vendor's own history of amount, timing and frequency rather than against a generic threshold. Anything that trips a check can be held in real time and routed to a named approver.

What you get

The question is asked while it still matters. A payment-redirect attempt surfaces as a bank change that arrived shortly before a large invoice from the same vendor, with both facts on the same screen. An impersonation attempt surfaces as a domain that differs from the one on file. An invoice unlike the vendor's own history is flagged as unlike it, with the amount, timing and frequency shown against that vendor's pattern rather than against an industry rule of thumb. Each hold names an approver, so it is a decision waiting on a person rather than an alert waiting on nobody.

Process

How it works

Four stages, running against the payables flow rather than beside it, so a finding arrives while the payment can still be stopped.

01
Watch what changes
Invoices, vendor master changes and payment runs are watched together. Fraud in payables is usually a relationship between two of those — a bank detail change and the invoice it was made for — and a control that looks at each in isolation cannot see it.
02
Check identity
The sending domain is compared against the vendor's registered domain and its known contacts, with near-matches treated as suspicious rather than as a match. A display name that does not agree with the address behind it is reported, since that is the form most impersonation actually takes.
03
Score behaviour
Amount, timing and frequency are compared against the vendor's own history rather than against a global threshold. A vendor that always bills monthly and modestly is a different baseline from one that bills irregularly and large, and a single threshold is wrong for both.
04
Hold & route
A payment that trips a check can be held in real time and routed to a named approver with the evidence attached: what changed, when, and what it would have affected. Releasing it is a recorded decision, which is what distinguishes a control from a notification.

What it does

Inside the solution

Lookalike domain detection

Sending domains are compared against the vendor's registered domain, with near-matches treated as a risk rather than as a match. A domain one character out passes a human read precisely because it is meant to.

Sender and contact verification

A display name that does not agree with the address behind it, or a request arriving from an address never previously associated with the vendor, is surfaced with both the expected and the observed contact shown.

Payment-redirect detection

Bank detail changes are events, not edits. Each one is scored against its timing and against the payments it would affect, so a change made shortly before a large invoice from the same vendor is treated as the pattern it is.

Behavioural baseline per vendor

Amount, timing and frequency are compared against the vendor's own history. A generic threshold flags every large supplier and misses the small one billing three times in a week for the first time.

Duplicate and near-duplicate invoices

The same invoice under a different number, or the same amount and date against a slightly different vendor name, is caught by comparing the substance of the document rather than only its identifiers.

Real-time hold

A finding can stop the payment rather than annotate it. The check runs while there is still something to prevent, which is the only point at which detection has more value than an investigation.

Routing to a named approver

Every hold has an owner by name, with the evidence attached and a decision recorded either way. An alert addressed to a queue is an alert that will be found during the post-incident review.

Evidence retained for investigation

What changed, when, who requested it and what it would have affected are retained with the case, so an investigation reads the record rather than reconstructing it from mailboxes and memories.

Foundations

The VapusFin models behind it

Fraud & Anomaly Detection

Fraud & anomaly detection

Vendors, buyers, orders, payments and transaction patterns connected across payables, receivables and distribution networks, so suspicious activity is exposed across entities, channels and geographies before it becomes a financial or compliance problem.

Details

Accounts Payable Automation

Accounts Payable

Capture every invoice however it arrives, match it line by line against the PO and the goods receipt, and pay only what the contract says you owe.

Details

Questions

Frequently asked

Will this bury us in false positives?: The baseline is per vendor rather than global, which is the main source of noise in threshold-based controls. Checks are also weighted towards changes that carry money — bank details, new payees, first-time senders — rather than towards every invoice that happens to be large.
Does it stop a payment on its own?: It can hold one, and the hold is routed to a named approver with the evidence attached. Whether a given check holds or only flags is your configuration. What is not configurable is that a release is a recorded decision by a person.
What signals does it use for impersonation?: The sending domain against the vendor's registered domain, near-matches to that domain, the relationship between a display name and the address behind it, and whether the contact has ever been associated with the vendor before.
How do you treat a legitimate bank detail change?: As an event to be confirmed rather than as an edit to be applied. It is scored against its timing and the payments it affects, and confirmation is recorded against the vendor, so the next change has a history to be read against.
Does it need our ERP data, or can it work from documents alone?: It works better with both. Documents carry the identity signals, the ERP carries the vendor master and payment history that behavioural comparison depends on. Reading only one of the two limits it to the checks that source supports.
Has this been delivered for a customer?: Not as a standalone engagement. The document reading, vendor resolution, rule engine and approval routing behind it are running in delivered payables and claims work; the fraud checks are a use of that same engine, and we would rather say so than imply a case study exists.

See it against your own payment history

Give us a period of invoices, vendor master changes and payment runs and we will show you what would have been held, on which signal, and what a reviewer would have seen.

Book a demo

Last reviewed 4 September 2026

The payment you stop is worth more than the one you investigate

The problem

What the platform does

What you get

How it works

Watch what changes

Check identity

Score behaviour

Hold & route