Why supplier-bank verification is worth the boring work

Half the conversations I have with treasury teams about Calabash end up on bank account verification. We talk about supplier identity, payment workflows, the cash forecast. Eventually someone asks how the bank accounts are held, and the conversation slows down.

It slows down because every treasurer I have spoken to has a story. A payment that went to the wrong account. A supplier that "changed banks" but did not. A successful invoice fraud that took six months to fully unwind. The cost of those incidents is so large, and so much larger than the cost of doing the verification properly upfront, that the math is not even close.

This post is about the architectural decision we made on bank accounts, which is the boring thing that catches the bad thing.

The decision in one sentence

Calabash has two parallel tables for supplier bank accounts. One holds the accounts the supplier supplied themselves during onboarding. The other holds the accounts a treasury operator has verified and approved for payment. They do not auto-promote. Changes to the verified table require re-verification.

That is it. Everything else about the supplier bank account model in our system follows from that one structural decision.

Why two tables

The single-table version of this story is the one most AP systems run today. The supplier provides their bank details during onboarding. Those details go on the supplier record. The system uses them for payment runs.

The attack on the single-table model is simple. A malicious actor gets a foothold (compromised email, social engineering, an insider with the wrong access) and changes the bank account on the supplier record. The change is silent. The next payment run sends money to the attacker's account. The supplier complains a month later when they did not get paid. The investigation takes a quarter. The money is usually gone.

The two-table model breaks the attack. The supplier can provide whatever details they want on their profile. Those details do not become payable. A treasury operator promotes the account into the verified table after running an out-of-band verification step. The verification is logged with the operator's name, the timestamp, and the verification method.

To execute the same attack against the two-table model, the attacker has to either compromise a treasury operator's account, or compromise the verification process itself. Both are harder. Both leave more evidence. Both reduce the blast radius dramatically.

What "verified" means

Verification at Calabash is not a checkbox. It is a workflow step with structured fields. Method (callback to a known phone number, in-person, third-party verification service, others). Verifier (the treasury operator's identity). Evidence (a stored artefact, usually a recorded call or a confirmation email from a known address). Date. Expiry.

The expiry matters. A verified account that has not been used or re-verified in twelve months goes back into a re-verification queue. This catches the long-tail accounts that were verified once and then forgotten about, which is the second-most-common path for the attack to succeed.

The cost

The two-table model costs you a treasury operator's time. Specifically, about thirty minutes per supplier at onboarding, and about ten minutes per re-verification. For a business with three hundred suppliers, that is somewhere between forty and sixty hours a year of treasury operator time spent on bank verification.

The cost of one invoice fraud incident at a mid-market business is anywhere from fifty thousand to two million dollars depending on the scale. The cost of an unnoticed fraud that runs for three months can be much higher.

Sixty hours a year is much less than the expected value of the loss you are preventing. The math is not close.

Why we will not budge

The most common feedback we get from prospects in the first call is "can the verified account auto-promote if the supplier confirms via the portal". The answer is no. It will always be no. The whole defensive value of the model comes from there being a deliberate, attributable human step between supplier-provided data and payable data.

If the auto-promote saves you treasury operator time, it saves it by removing the defensive value that the model exists for. We are not going to make that trade.

If you are evaluating our system and the friction of two-table bank verification is the objection, sign up for Calabash Business at calabash.app/b2b and we will walk you through the threat model with your treasury and security teams. The suppliers your treasury team will be verifying register on the supplier portal at connect.calabash.app.