Three invoices, one supplier, two thresholds
A finance director is about to approve 822,990 US dollars in one click. The question this page is about is not whether they are allowed to. It is what the screen owes them before they do.
Three invoices from one construction supplier, sitting in the queue on the same value date. The bank applies two thresholds: above 3,000 USD a payment attracts elevated authentication, above 500,000 USD it attracts enhanced authentication. Change any amount, change a payee, add a line — the chain below moves with it.
| Invoice | Payee | Amount (USD) | Alone | In this batch |
|---|
tier(batch) = max( tier(sum of lines), max over lines of tier(line) )The same three invoices, submitted separately and submitted as one batch. The comparison people expect is fewer approvals. The comparison that is actually true is fewer submissions, and a higher bar on the smallest line.
Batching is a decision made by the payer that lands on the payee's ledger. One credit of 822,990 against three open invoices is an unallocatable payment — which is a worse outcome for the supplier than three separate credits would have been. ISO 20022 structured remittance information is what makes the trade even, and the failure state below is the one worth designing for.
remt.001 for the advice itself and remt.002 for advising where the advice can be
found. This removes the length limit. Its cost is that the money and the explanation now travel on separate
paths and may not arrive together, which turns a formatting problem into a timing problem.The friction in corporate banking is usually described as too many fields. That is the symptom. The defect is that the credential is bound to a device rather than to a role, in a process that requires six different people.
Three of these — company identifier, company number, banking number — are lookup keys, not secrets. They are asked for at every login because the system resolves who you are and which organisation you act for in the same transaction.
Separating identity from intent is what lets biometrics finally do useful work here. A fingerprint is a poor answer to which company do you act for and an excellent answer to is this the payment you meant. Signing over the payload rather than logging into a session is the difference between what-you-see-is-what-you-sign and a session someone else can steer.
A six-gate chain on device-bound credentials has no legitimate path for absence. Somebody is travelling, somebody has a new phone, somebody is on leave at quarter end and the payment run cannot wait. What happens next is not that the payment waits. What happens is that a credential gets shared, and the system records six distinct approvals that were not made by six distinct people.
That is worse than a slow process. A slow process is visible. A control that has been quietly delegated produces a log that looks perfect and means nothing — and the log is the artefact everything downstream trusts. A design that adds a seventh gate to a chain people are already working around has made the record less true, not the bank safer.
Three published figures survive checking. They are stated here with enough provenance to be disagreed with.
McKinsey reports that the average onboarding process for a new corporate client can take up to 100 days, drawn from quantitative surveys and interviews with two dozen global banks.
McKinsey & Company, Winning corporate clients with great onboarding, 5 October 2022. Source. Read as an upper bound on an average, not a typical duration.
Panko's synthesis of field audits conducted between 1995 and 2004 found that 94% of the 88 spreadsheets examined contained at least one error, with a mean cell error rate of 5.2% across the 43 for which it was reported.
Raymond R. Panko, What We Know About Spreadsheet Errors. The figure is at least one error, not serious error, and the audited sample is small and old — which is exactly why the number is quoted at 94 rather than rounded to a friendlier 90.
Pol's peer-reviewed assessment puts a defensible indicative mid-point at about 0.05% of criminal funds intercepted, against private-sector compliance spending of roughly 300 billion US dollars a year and around 3 billion recovered — compliance costs many tens to hundreds of times greater than the amounts recovered.
Ronald F. Pol, Anti-money laundering: The world's least effective policy experiment? Together, we can fix it, Policy Design and Practice, vol. 3 no. 1, 2020. DOI. This is the figure that makes the credential argument above matter: the apparatus generating the friction is not, on this evidence, catching much.
These appeared in my own first draft. None of them survived a search for a primary source, so they are listed here rather than deleted. Removing an unsourced number is not the same as being honest about it — and a reader who has seen these figures elsewhere deserves to know where the trail stops.
Traceable only to vendor marketing material from companies selling alert-reduction software. No regulator publication or peer-reviewed study found stating this range. The incentive of the only available source is to make the number large.
Traces to vendor-commissioned surveys with undisclosed sampling. Not independently reproducible.
The closest figure I could find is 55%, in trade-press coverage rather than a primary study. The 90 appears to be a repeated rounding of something else.
Cut entirely, along with the distributed-ledger section it belonged to. Not because the claim is impossible, but because neither number traces to a primary source, and because the section argued the wrong thing: a payment run of this kind fails on counterparty risk, custody and legal structure long before it fails on seconds. Speed was never the binding constraint here.
The observations behind it come from real production work on institutional banking software under confidentiality. Nothing proprietary appears here, no client is identified, and the thresholds, payee, invoice numbers and routing labels are illustrative. That is a real limit on what you can verify, and it is the reason this is published as a concept rather than a case study.
3,000 and 500,000 are chosen so the arithmetic is legible, not because any institution uses them. The
max() rule is the transferable part; the specific numbers are not.
No usability testing, no error-rate measurement, no comparison against an existing approval screen. The claim that showing constituent lines improves approval quality is an argument, not a finding.
Truncation is modelled at a common field length to make the failure visible. Real behaviour depends on the specific channel, scheme and correspondent chain, and would need to be measured per corridor rather than assumed.
Whether a supervisor accepts aggregate-level authentication at all is a legal question with a jurisdiction-specific answer. This page argues about what the interface must show once the rule exists; it does not argue that any particular regulator would permit the rule.