Verifying supplier bank details

The single highest-ROI fraud control in the UK: when a supplier's bank account on file is edited, Blankitt requires a callback verification before the change saves. The fraud pattern this stops:

"Hi, we've switched banks — please update our payment details. New IBAN attached. Thanks, [supplier finance]"

That email is the most common UK invoice fraud vector (~£35B annually). The attacker has spoofed the supplier's sender domain. If you blindly update the bank details and pay the next invoice, the money goes to the attacker.

How the verification works

1. Go to Contacts → [supplier name], find the Supplier bank details card.
2. Click Edit & verify (or Add bank details for first entry).
3. Make changes. The instant you change any bank field on an existing supplier, an orange Verify the new bank details panel appears.
4. Pick up the phone and call the supplier on a number you ALREADY have on file (their main switchboard, your usual contact — NOT a number from the email asking to change). Confirm the new details verbally.
5. Fill in the phone number you called and who confirmed ("Spoke to Sarah Williams in finance, she confirmed the IBAN matches their April statement").
6. Click Verify & save.

The change log

Click Change log on the bank details card to see every change ever made to this supplier's bank details — old → new diff, who changed, who confirmed, what number they called, free-text notes. Append-only; the masked-snapshot rendering means the log itself isn't a credential leak.

What the controls protect

• Account number and IBAN are masked at the display layer (****1234) so the audit log doesn't expose the full number.
• The verification token never lives in the page URL — it's in the request body.
• Changes to a non-supplier contact's bank details are allowed without the verification gate (the supplier-pay fraud pattern doesn't apply to customers).

When to NOT trust the email

Always. Bank-detail change requests via email should ALWAYS trigger the callback verification, even if:

• The email comes from your usual contact's address (the address has been spoofed in many real-world cases)
• The email includes a phone number to "verify" (the attacker also controls that number)
• There's schedule pressure ("we need this updated today or your next payment will go to the old account")