Who changed the bank account

Every payment redirect fraud starts as a polite change request. May’s ledger shows 23 master changes, four touching bank details: three verified by callback, one held when nobody answered. The held one is the control doing exactly its job.

RuleLedger every supplier master change, and treat bank and remit-to changes as payments waiting to happen: verified by callback to a known number, or held.

Neververify a bank change by replying to the email that requested it. That email is the fraud; the callback to the number you already had is the control.

Most changes are housekeeping. The four that redirect money get the phone call, every time, before any run.

◆ May, the change ledger23 changes, partitioned by what they touch.

Change type	Changes
Bank details	4
Remit-to address	3
Contacts, terms, and other fields	16
Supplier master changes	23

The four bank changes	Changes
Verified by callback to the number on file	3
Held, callback unanswered	1
Bank detail changes	4

The held one is the control working: no verified voice, no changed account, no payment. Business email compromise is patient and polite, and every fraudulent redirect starts life as an ordinary-looking change request. The Oracle catalog parks the same page under a blunter name: who changed the bank account. Sample values are illustrative, never client data.

◆ The two dates, againrequested and effective, kept apart.

Like every change ledger in this catalog, from pay changes to the tenant ledger, each row keeps who requested, who approved, when it was keyed, and when it took effect. A redirect discovered after a payment is an investigation; the same redirect caught at the ledger is a Tuesday.

◆ The owned answerthe master as history, the risk rows gated.

dim_supplier on the supplier star is versioned, so every change is a row and the bank-touching subset is a standing filter feeding the callback queue. The payment runs read only verified versions; an unverified change can exist without ever being paid against.

Use case

Problem

Supplier bank changes arrive by email, get keyed in good faith, and the fraud surfaces as a supplier asking where their payment went weeks later.

What we build

A versioned supplier master where every change is a ledgered row, bank and remit-to changes feed a callback queue, and runs pay only verified versions.

What you get

Redirect fraud stopped at the ledger instead of investigated after the loss: every risky change verified by a voice you called, or held without drama.

Would your process catch a polite bank-change email?

We build the versioned master and the callback gate that make redirects boring.

Talk to us

Terms on this page

AP: Accounts payable, the money owed to suppliers.
supplier master: The record of who suppliers are and how they are paid.
bank change: A payment redirect waiting to happen; the risk row.
callback control: Verification by phoning the number already on file.
business email compromise: Fraud by plausible email; the reason for the callback.
verified version: The only supplier version a payment run may read.