When we designed Direct Banking's payment path, the first serious argument we had was about Confirmation of Payee. Specifically: should it warn, or should it block?
The UK's Confirmation of Payee scheme — and the equivalent name-match APIs the European PIS aggregators expose — will tell you whether the name on a vendor's bank account matches the account holder's name at the destination bank. It comes back with one of three verdicts: Match, Close Match, Mismatch. What the sending system does with each verdict is not prescribed.
Most implementations warn. We block.
This post is about why, and about the small piece of design that makes blocking actually workable.
The warning-doesn't-work argument
The premise behind warning is: the user knows better. If the CoP verdict comes back Mismatch and the user chooses to send anyway, that is their informed decision. The system's job is to inform, not to gate.
Two things make this argument fail in practice.
The first is that the warning gets normalised. When a Close Match comes back 20% of the time — which it does, because vendor accounts frequently belong to trading names, holding companies, subsidiaries, or personal accounts of sole traders — users learn to click through it. When a Mismatch comes back, they click through it too, because the muscle memory is the same. Every payment-fraud post-mortem I have read includes some version of the sentence "the user clicked past the warning."
The second is that in accounts payable, the person clicking through the warning is often not the person who set up the vendor bank account. They may not be positioned to make an informed decision about whether the mismatch is genuine or fraudulent. Warning them is asking them to underwrite a risk they did not create.
If a system's purpose is to prevent payment to a wrong account, warning does not fulfil the purpose.
The blocking-with-an-override design
So we block. When CoP returns Mismatch, Send via Direct Banking refuses to submit the payment. The refusal is not a soft one — the button turns disabled, the payment line carries a red gate icon, and the payment cannot leave BC.
The workaround is a single override path. The user opens the payment line, clicks "Override CoP Mismatch," and is presented with a form that requires:
- A written reason. Free-text field, minimum length enforced. "Talked to the vendor, confirmed the account is theirs" is a valid reason; "override" is not.
- The name they expect to be on the account. If it does not match what CoP returned, they are typing something the system has not seen before.
- A confirmation checkbox. "I take responsibility for this payment going to the account below."
If they complete the form, the override is granted and the payment can be submitted. The override lands as a row in SFD Verification History — insert-only, with the timestamp, the actor, the reason, the expected name, and the CoP verdict at the time of override. Every override is permanent audit history. Deleting a row is not physically possible from the app — the permission set does not allow it, and the trigger enforces it.
Why the friction works
Warnings can be clicked through in half a second. This override takes about thirty seconds. That difference matters more than any UI copy or colour choice.
A thirty-second interaction is not something you do accidentally. It requires the user to stop, read what they are doing, and type something specific. Fraud that relies on the user clicking through a warning does not survive an override form that requires them to type the name of the fraudulent account holder — because typing that name breaks the pretence.
An override form that also generates permanent audit history is not something a user does routinely. Once you know your override lands in a row that will show up in the next quarterly audit, you do not override unless you genuinely believe the vendor account is correct. Which is exactly the discipline we want.
What we cost customers
Time. In the pilot we ran with the launch customer for Direct Banking, we measured a median 42 seconds per Mismatch override, ninety-fifth percentile 3 minutes 20 seconds. Two payments a week required an override during the pilot. Roughly eight minutes a week of finance-team time.
The customer had one payment mistake caught by the gate during that pilot — a vendor's ownership had changed and their new account belonged to a different entity. The mistake would have been ₹4.2 lakh going to the wrong place. Eight minutes a week is a good trade against that outcome even if the mistake had been a hundred times smaller.
Where the design breaks
We have found one case where the gate is genuinely annoying: same-owner sole-trader payments. A one-person consultancy trading as "ACME Advisory" whose actual account holder name at the bank is "Priya Sharma" will produce a Mismatch every time. The vendor knows. The finance team knows. The vendor's own bank knows. But CoP cannot know that "ACME Advisory" and "Priya Sharma" are the same person unless the vendor's bank has a trading name alias — and many do not.
We patched this with a per-vendor "CoP known variance" field. Once the finance team has verified the mismatch is benign, they mark the vendor as such — with, of course, a written reason and audit history — and future CoP Mismatch verdicts against that specific vendor are treated as Close Match instead of Mismatch. The payment can then go through without an override every time. The variance is per-vendor and reversible; if the vendor changes accounts, the variance clears.
The point: friction is not a design goal. Correctness is. But when there is no way to guarantee correctness, thirty seconds of the right kind of friction is what stops the wrong outcome.
What we would tell another BC vendor
If you are building a payment feature for Business Central and thinking about how to handle CoP: block. Not because warning is wrong ethically, but because it does not work operationally. Provide an override path that is genuinely usable — one form, thirty seconds, permanent audit — and provide a per-vendor benign-variance escape hatch for the sole-trader cases where blocking would be pointless.
We shipped it that way in Direct Banking's v1 and it is the design decision I most want us to be judged on in ten years. Payment fraud caught is worth all the friction in the world. Payment fraud not caught is worth exactly zero of it.