A proposal for idiot-proofing bank account details
Take a valid credit card number, such as 4111-1111-1111-1111, change it slightly, to 4111-2111-1111-1111, and it ceases to be valid. This is because the last digit of the number is a checksum calculated from the preceding digits via the Luhn algorithm. It’s not particularly clever; it’s not cryptographically secure. It’s not meant to be. What it’s intended to do is to protect against accidental data entry errors, and it does that very well.
Now, compare the system for bank transfers in the UK. You enter a six-digit sort code (usually given as three pairs, e.g. 11-22-33). This corresponds to the branch. To this you add an eight-digit account number.
If you get one of the digits wrong, one of two things happens. If you’re lucky, the transfer is rejected and the sum is returned to the originating account.
If you’re unlucky, the sum disappears into BACS and you have to fill in forms and wait six weeks to try to get it back.
There may even be a third case, in which a typo generates an alternative valid bank account, making it even harder to reclaim the lost funds. I don’t know how likely this is, as I don’t know how banks distribute account numbers.
Having been a victim of the second case (due to an estate agent sending me the bank details that were off by one digit), I feel like simple transcription errors could and should be prevented, and I think we could do it pretty easily.
Here’s my proposal: create a transfer format for bank account details that includes a checksum, allowing the detection of errors before monetary loss ensues.
In fact, we don’t need to. It already exists! The IBAN, or International Bank Account Number, specifies a format that does exactly this.
Instead of:
12-34-56 98765432
You use something like:
GB82 WEST 1234 5698 7654 32
It’s not too much longer, and you can be reasonably confident that no one’s made a typo somewhere.
Although intended for cross-border transactions, there’s no reason why we shouldn’t use IBANs for domestic payments. The functionality could be added to online banking systems fairly trivially (I’d optimistically quote half a day’s work) without needing any change to the back-end systems.
We can’t stop estate agents screwing up, but this might be the next best thing.
2009-10-26 22:00 UTC. Comments: 6.
Tim
Wrote at 2009-10-26 23:41 UTC using Firefox 3.5.3 on Windows XP:
6 weeks ago I set up a direct debit over the phone to pay off my credit card. One month later Virgin sent me a statement explaining my payment was late and my 0% interest rate had therefore been cancelled so I owed them lots (and climbing).After several protracted telephone calls it turned out Virgin had taken down my account number wrongly, my bank had therefore declined to set up a direct debit (on an unrecognised account), and Virgin had failed to tell me there was any problem, hence the issue. Virgin did, at least, rectify the problem after some harrasment from me.
Perhaps your suggestion would help here too? It would certainly make life easier on the odd occasion when I do need to make international payments online (my bank’s website doesn’t currently support IBANs).
Oddly, Virgin wrote to me straight away when the direct debit worked OK, and I didn’t need to know…
MikeB
Wrote at 2009-10-30 22:50 UTC using Opera 9.80 on Windows 7:
Spot on. I’ve had exactly the same experience, where my new landlord emailed me her bank details incorrectly and then wondered where the rent was…Worringly, I got notice from my bank a couple of weeks back of a variation of terms. Chief amongst them was that if you are responsible for entering the wrong details on a transfer then the bank has no responsibility to attempt to retrieve the money.
Given the clear inadequacies of the current account numbering system, I’d love to see that stand up in court!
Jesús Roncero
Wrote at 2009-11-09 00:25 UTC using Firefox 3.5.4 on Mac OS X:
Interesting, as I’ve always thought of this being a problem in the UK (well, it’s always intrigued me). In Spain, where I come from, bank accounts use two digits (control digits they are called) that prevent these things from happening. Why such an easy thing has not been done here yet?Now that you mention this, I think I’m becoming more and more paranoid about my transfers in the UK.
Jon F
Wrote at 2009-11-16 15:42 UTC using Internet Explorer 6.0 on Windows XP:
What about UK 6-digit account numbers? I believe these are older account numbers and that at some point the UK switched to the current 8-digit account numbers. I understand that to bring these 6-digit numbers up the the required length that a couple of 0s were simply added in front.I have a situation from the end of 2007 where suddenly now I am being told that payment was never received to a 6-digit account number. The payement in questions was a CHAPS payment. If you only gave the 6-digits would a bank automatically insert the 0s in front? The money was never returned but based on all the account number (minus the 0s) and the sort code being right the payment should have been received. It seems unlikely that situation 2 you mention above should have happened.
I have now got my bank doing a trace on the payment so we shall see what we find out as to where it ended up.
James McCarthy
Wrote at 2009-12-13 17:16 UTC using Chrome 4.0.249.30 on Mac OS X:
Great idea. I’ve experienced several such errors at the hands of the banks themselves. Lloyds online business banking isn’t even really online, they re-key all the transactions to set-up new payment details ‘to ensure accuracy’. In the first 6 months of running a business using Lloyds Business banking I had several inbound and outbound payments from Lloyds disappear into the ether for weeks at at time due to wrong information being manually re-entered.Martin Vlietstra
Wrote at 2009-12-16 21:50 UTC using Internet Explorer 7.0 on Windows XP:
The UK banks started standardising on eight digit account codes and six digit sort codes (branch codes) soem fifteen years ago. Prior to that there was no standardisation. Most banks had some form of check digits, but again there was no standardisation.