Fraud & Anomaly Detection
Find it while it is still an anomaly, not after it is a loss
Fraud rarely looks wrong on the document in front of you. It looks like a supplier you know with details that changed last week, a credit note that is only unusual next to the others, or a partner claim that is only inflated when the channel is compared with its neighbours. VapusFin connects vendors, buyers, orders, payments and transaction patterns across payables, receivables and distribution, and holds what does not fit while somebody confirms it.
The problem
Each system sees its own slice, and the fraud lives between them
Payables checks whether an invoice is arithmetically correct, and it is. Receivables sees a credit note approved by someone with authority to approve it. The channel team sees a claim supported by the volumes submitted with it. Every control passes, because each one is looking at a fragment. The common attacks — a domain with one character changed, a bank detail updated days before a due date, a customer identity duplicated so a write-off has somewhere to go, a partner claiming the same incentive under two entities — are only visible when the same counterparty is examined across all of it. Controls that run weekly find them after the payment run, and recovery is mostly a question of how fast somebody noticed.
Surface one
Payables
The money going out, and the people who would like it to go somewhere else.
Vendor impersonation and lookalike domains
Sender domains and vendor details on inbound documents are compared against what is on record — character substitutions, transpositions, added or dropped words, alternative top-level domains and recently registered lookalikes. A near-match to a known vendor is treated as more suspicious than an unknown one, not less.
Payment-redirect detection
A change to a vendor's bank details is held and verified out of band before any payment can use it, and a change arriving close to a due date is escalated rather than processed quietly. Old details, new details, who asked and through which channel are shown together.
Duplicate and altered invoices
The same invoice submitted twice under a different number, a resubmission with amended amounts or dates, and near-identical documents split across entities are matched on substance rather than on an exact reference.
Behavioural drift against a vendor's own history
Each vendor is compared against itself — typical amounts, invoice frequency, day of month, currency, entity billed and what they usually supply. A vendor that has billed a steady monthly amount for two years and suddenly raises a large one-off is flagged on that basis, with the comparison shown.
Surface two
Receivables
The money coming in, and the adjustments that quietly stop it arriving.
Manipulated credit notes and write-offs
Credit notes and write-offs are examined as a pattern rather than one at a time: who raises them, against which customers, at what point in a cycle, and how often just under an approval limit. A single credit note is unremarkable; the shape of a hundred of them is not.
Duplicated customer identities
The same customer created twice — a spelling variant, a second registration, a shared address or bank account — is surfaced, because a duplicate identity is where a limit is reset and a bad debt is moved rather than resolved.
Receipts applied against the wrong invoice
Cash applied to an invoice it does not belong to keeps an ageing report looking healthy while the underlying balance moves. Application is checked against the remittance and the customer's own pattern, and a receipt covering a gap elsewhere is raised.
Concentration in a collection cycle
Unusual concentration — one collector, one customer group, one period, one settlement route — is measured against the rest of the book rather than reported as an average that hides it.
Surface three
Distribution and channel
Partner networks, where the counterparty is both a customer and a claimant, and where the same activity can be presented twice.
Inflated claims and incentives
Claims and incentives are tested against the entitlement they rest on and against comparable partners in the same programme, so a claim inflated across a network is visible as a pattern rather than argued one submission at a time.
Orders and settlements that disagree
What was ordered, what was shipped, what was invoiced and what was settled are reconciled along the chain. A settlement that does not agree with the order behind it is an exception with a named cause, not a rounding difference.
One activity, two entities
The same transaction claimed under two partner codes, two legal entities or two territories is detected by connecting the counterparties rather than by trusting the identifier each submission carries.
Patterns that only appear side by side
Channels, regions and geographies are compared against each other, because a distribution pattern that looks normal inside one territory is often only anomalous next to the others.
Why one model
The signal is in the connection, not the surface
A counterparty is rarely only a vendor. It buys, it sells, it claims, it settles — sometimes under more than one identity. Fraud that is invisible inside payables alone becomes obvious when the same counterparty is examined across payables, receivables and channel activity at once: a vendor whose bank details changed the same week a customer account with a matching address was created, a partner whose claims rose exactly as its settlements slipped, a write-off in one entity against an invoice raised in another. Each of those looks defensible on its own surface. Together they are a case. That is the argument for this being one model rather than three separate features that never compare notes.
How it works
From counterparty to decision
- 01
Connect the counterparties
Vendors, customers and partners are resolved into single counterparties across entities, systems and geographies, so the same organisation is one subject rather than four records.
- 02
Establish the baselines
Each counterparty's own history is built from your records — amounts, frequency, timing, currency, entities involved, categories, claim rates and settlement behaviour — alongside the pattern of the population it belongs to.
- 03
Check identity and change
Inbound documents and requests are checked against what is on record: domain, bank details, registration identifiers, contact identity, and the channel the request arrived through.
- 04
Compare across surfaces
Transactions are compared against the counterparty's own baseline, against its peers, and against its activity on the other surfaces, and the specific deviation is named rather than scored.
- 05
Hold and route
Anything that fails a check is held before the money moves or the credit is granted, and routed to a named approver with the evidence and the comparison that triggered it attached.
- 06
Resolve and learn
The decision and its reasoning are recorded against the person who made it. A confirmed legitimate change updates the counterparty record so the same check does not fire twice; a confirmed attempt is retained as evidence.
Questions
Frequently asked
- Is this only about supplier payments?
- No. Payables is one of three surfaces. Receivables covers credit notes, write-off patterns, duplicated customer identities and misapplied receipts. Distribution and channel covers inflated claims and incentives, orders that do not agree with settlements, and the same activity appearing under two entities. The three run on one connected view of counterparties, which is where most of the value is.
- Why does connecting the surfaces matter?
- Because a counterparty that is only ever examined as a vendor cannot be compared with itself as a customer or as a channel partner. A bank-detail change is a routine event in payables; the same change in the week a matching customer identity was created is not. Holding all three in one place is what turns a set of individually defensible events into something worth a phone call.
- Will this stop legitimate transactions?
- Some, deliberately. A held payment costs a confirmation call; a redirected one costs the payment. Holds are targeted at the events where fraud actually happens — bank-detail changes, first payments to new counterparties, near-miss domains, credit notes against the pattern, claims out of line with peers — rather than applied as a blanket delay. Thresholds are yours to set, and every hold names its specific reason so the confirmation is quick.
- What does an approver see?
- The transaction, the check that failed, and the comparison behind it — details on record beside details submitted, the counterparty's usual amounts and timing beside this one, its activity on the other surfaces, and the channel the request came through. Enough to decide without opening four systems, and the decision is recorded against their name.
- Does it replace our bank's fraud controls or our dual authorisation?
- No. It runs before a payment reaches the bank and before a credit is granted, on information neither has — your contracts, your counterparty history, the document that arrived and the channel it came through. Dual authorisation stays as it is; this decides which items deserve a second look and hands the approver the evidence.
- What detection rate can you quote?
- We do not quote one, and we would treat any vendor quoting a detection rate for fraud with caution. What we can do is run your own historical payables, receivables and channel data through in a sandbox and show you what would have been held and why.
Solutions
Built on this model
Test it against your own history
Give us a period of vendor payments and bank-detail changes, a period of credit notes and receipts, or a season of channel claims. We will show you what would have been held, on what evidence, and what would have gone straight through.
Last reviewed