Vendor Bank Account Fraud in India: The One Field That Lets Money Walk Out

Your vendor changed their bank account details. The email looks exactly like their previous correspondence — same email domain, same tone, same signature. The attached invoice references a real PO. Your AP team updates the vendor master and schedules the next payment. Two weeks later, the actual vendor calls to ask when payment is coming. The money went to an account that was never theirs.

Bank detail manipulation is the most common AP fraud vector in India. It does not require breaking into your systems. It requires one email that looks plausible and one AP team member who updates the vendor master without secondary verification.

How the Attack Works

The attacker gains access to a vendor's communication channel — email, WhatsApp, or both. In some cases this is a compromised vendor email account. In others, it is a spoofed domain that looks nearly identical (vendorname-india.com instead of vendorname.com). The request arrives during a normal billing period with a plausible reason: "We've changed our banking partner," "Our previous account has processing delays," "GST-registered account for compliance purposes."

The attached invoice or PDF looks genuine. The GST number matches. The invoice number follows the vendor's sequence. The amounts are accurate. The only thing that changed is the account number and IFSC code — and since the AP team isn't in the habit of comparing current bank details against historical records, nothing triggers.

The RBI has added a beneficiary name lookup facility for NEFT and RTGS transfers, where the remitter can verify that the account number and IFSC match the expected beneficiary name before initiating the transfer. This is a useful final check — but it only works if someone thinks to use it, and it does not protect against a fraudster who has opened an account in a company name similar to your vendor's.

The Control Gap and the Fix

The root cause is structural: AP teams validate invoice amounts and formats, but rarely compare the bank account on a current invoice against the bank account on file from previous invoices. The check that would catch this fraud is straightforward — does the bank account number on this invoice match the vendor master, and does it match the last six invoices from this vendor? If it does not, hold the payment and verify by phone using a number sourced from your vendor master, not from the email.

The maker-checker process needs to be applied to vendor master changes specifically. An AP team member who processes invoices should not be the same person who can update bank details. The update should require a second authorizer, and that authorizer should be required to confirm via a secondary channel — a phone call to a number already on file, not a reply to the email that requested the change.

The documentation trail matters too. Every bank detail change should be logged with the date, the previous account number, the new account number, and the name of the authorizer. This creates an audit trail and, more importantly, creates friction that discourages casual updates without proper verification.

What Repeated Changes Signal

A vendor who has updated bank details twice in 18 months is not automatically suspect — companies change banks. A vendor who has updated bank details three times in 6 months, or whose bank detail changes consistently precede large invoices, warrants scrutiny beyond the standard change process.

The companies that have eliminated this fraud vector share one practice: they treat every bank detail change request as a high-severity event requiring out-of-band verification, regardless of how convincing the email looks. The cost of making one verification phone call is never higher than the cost of discovering the fraud six weeks after the payment cleared.