Payments fraud · for every business
Pay the vendor. Not the impostor.
Every business pays suppliers, and fraudsters know it. An email from a lookalike domain changes a vendor's bank details, and the next invoice goes to a fraudster's account. Omnareth checks every bank change and payment against the vendor master before money moves, and recognizes the same account when it turns up on another vendor.
| # | Event | Decision |
|---|---|---|
| 1 | Genuine Northwind Steel invoice to its verified account | ALLOW |
| 2 | 'Northwind' emails new bank details from northwlnd-steel.com | DENY BANK_CHANGE_UNVERIFIED · LOOKALIKE_DOMAIN |
| 3 | A clerk keys the new account and requests payment ▲ Repeat offender opened for the account; account watched |
DENY UNKNOWN_BANK_ACCOUNT |
| 4 | Same account sent to Fabrikam Logistics from another lookalike | DENY BANK_CHANGE_UNVERIFIED · LOOKALIKE_DOMAIN · WATCHLIST_MATCH · REPEAT_OFFENDER |
| 5 | Same account on a Tailspin Packaging payment ▲ One account across three vendors: case opened |
DENY UNKNOWN_BANK_ACCOUNT · WATCHLIST_MATCH · REPEAT_OFFENDER · ACCOUNT_HOPPING |
| 6 | Fabrikam invoice submitted a second time | DENY DUPLICATE_INVOICE |
| 7 | A clerk approves their own payment | DENY SOD_VIOLATION |
| – | Analyst confirms the case ▲ Account blocked for every vendor |
analyst · state |
| – | An insider adds the account to Tailspin's verified accounts | analyst · state |
| 8 | Payment to the now "verified" account | DENY WATCHLIST_BLOCK · REPEAT_OFFENDER · ACCOUNT_HOPPING |
| 9 | Genuine Tailspin invoice | ALLOW |
How it fits
A check before the payment run
Your ERP or payment platform sends each vendor bank change and each payment request to Omnareth, and releases only what it allows. Nothing else in the process changes.
The vendor master
Each vendor carries its verified email domain, the bank accounts verified by callback, its usual invoice limit and the invoices already paid.
Bank changes and payments
A bank change must be verified by callback and come from the vendor's own domain. A payment must go to a verified account, once, approved by someone else.
One account, many vendors
Omnareth holds the fraudster's account responsible, never the vendor or the clerk, and recognizes it when it is pushed onto another vendor.
Reference rules
11 rules for vendor payments
Ready to adapt to your approval policy. Authorization checks fail closed: an account that is not on the verified list is not paid.
| Threat | What Omnareth checks | Rule code | Decision |
|---|---|---|---|
| Bank detail change fraud | New bank account not verified by callback to a known contact | BANK_CHANGE_UNVERIFIED | DENY |
| Business email compromise | Change request from a domain other than the vendor's verified domain | LOOKALIKE_DOMAIN | DENY |
| Payment diversion | Payment to an account that is not a verified account of the vendor | UNKNOWN_BANK_ACCOUNT | DENY |
| Duplicate invoice | Invoice number already paid | DUPLICATE_INVOICE | DENY |
| Self-approval | Requester and approver are the same person | SOD_VIOLATION | DENY |
| Paying a vendor on hold | Vendor is on hold or blocked | VENDOR_NOT_ACTIVE | DENY |
| Unusual amount | Invoice above the vendor's limit | OVER_LIMIT | FLAG |
| Known fraud account | A bank account, domain or person blocked on the watchlist | WATCHLIST_BLOCK | DENY |
| Watched identity | An identity under watch, added by an analyst or automatically | WATCHLIST_MATCH | FLAG |
| Repeat offender | An identity implicated in 2 or more denied events in the last 30 days | REPEAT_OFFENDER | FLAG |
| One account, many vendors | An account or domain implicated in denials on 2 or more other vendors in 24 hours | ACCOUNT_HOPPING | FLAG |
The insider case
Marked verified. Still not paid.
In the reference scenario, after the analyst confirms the case, someone adds the fraudster's account to a vendor's verified accounts. The next payment passes every vendor check. Omnareth refuses it on the watchlist, and the audit record, anchored on chain, shows the block it acted on.
Vendors are victims
A payment to a fraud account counts against the account, not the vendor it was meant for, and not the clerk who keyed it.
Policy as rules
Callback verification, segregation of duties and invoice limits run on every request, with the reason recorded.
For auditors and insurers
Every refused change and payment is sealed with what was known at the time, and verifiable later.
Beyond vendor payments
The same platform takes refunds, payouts or any approval flow: define the record, the events and which fields identify people and accounts.
Pilot program
Put payments fraud prevention to work in 90 days
One lane, facility or process, in shadow mode, with results measured against criteria we agree with you. Qualified companies and organizations can apply.