Hacker News Reader

Comment by really3452 | Hacker News Reader

This is why all account numbers should end in a 6 to 12 digit checksum verification, to protect against human input error. If this bank had implemented this simple precaution then the entire situation would have never occurred.

View on HN

This system already exists and is called the IBAN (although it has only two checksum digits, mod 97). I thought it was used for all bank transfers in the EU now, but apparently the old system is still in use in the UK.

https://www.xe.com/ibancalculator/sample/?ibancountry=united...

Almost all the UK banks still use sort code and account for transfers, even though the accounts have IBANs.

It is often possible to perform foreign transfers using destination IBANs, but they seem to prefer (or require) the traditional approach for UK Sterling transfers.

I can understand why they retain the old system, but it would be useful if they in addition offered the ability to specify the target via IBAN for domestic transfers, since they already do for transfers to the rest of the EU.

Even when doing a SWIFT transfer, the IBAN (if one has it) is useful.

I do not understand why they retain the old system? What possible good effect can this have?

Japan has the same system of sort/branch codes and account number, but when I enter those here the recipient name is automatically filled out, making incorrect transfers pretty much impossible (unless, I guess, your mis-entered transfer to Mr. Sato is transferred to a different Mr. Sato instead)

It's baked into various systems, protocols and conventions? Sweden and other EU countries which didn't adopt the Euro also retain their traditional account numbering systems

A part of the Eurozone transition was that all local systems were replaced by SEPA SCT/SDD, which are inherently IBAN based. But SCT/SDD only apply to Euro transfers, and so in non-eurozone locales the existing infrastructure and nomenclature is retained

> Japan has the same system of sort/branch codes and account number, but when I enter those here the recipient name is automatically filled out, making incorrect transfers pretty much impossible (unless, I guess, your mis-entered transfer to Mr. Sato is transferred to a different Mr. Sato instead)

There is a Confirmation of Payee system coming soon in the UK (which most of the large banks have, unfortunately, delayed). It works slightly differently: it will compare the name, but not _generally_ tell you the name of the recipient because that comes with privacy concerns

>Sweden and other EU countries which didn't adopt the Euro also retain their traditional account numbering systems

These could be compatible though. e.g. in Poland numbers used for local bank transfers are just IBANs with country code trimmed from the front.

Especially because the IBAN can be unpacked automatically to country, bank name, short code, account number and (apparently) a checksum.

Why the 'apparently'? The numbers in the third and fourth place are the checksum, it is there by design.

I didn't know of the checksum until I looked it up today. A better choice of word would have been "evidently".

It was actually the "same" account number at a different Barclays branch. The account-holder may even have been largely unaware that the sort-code was a critical part of the unique identifier for his Barclays account.

Yeah, so the problem is that the account number plus short code had no checksum validation. This is the banks fault for implementing a rubbish account system. A proper system would look more like this sudo code:

1234567890-1234-checksum(1234567890-1234).substring(0, 6)

where 1234567890 is the account number, 1234 is the short code, and then 6 characters are typed in at the end are a checksum.

The short code is unique. So if you type in the correct checksum but not the correct short-code the fully-qualified unique identifier does not pass the validation step. Like-wise, if you type in the correct short-code but not the checksum then the unique identifier also does not pass the validation step. Thus, the user is protected against typing in an incorrect short code.

UK Sort Code + Account Numbers _do_ have check digits (Its not precisely a check digit as such: they have rules that they have to obey to be valid). Because of the age of the system, there isn't one _consistent_ rule for all sort code and account numbers, but instead a document listing the various methods and a couple of tables saying which rule(s) to apply and how

In most cases the sort code is included in the checksum

https://www.vocalink.com/media/3513/vocalink-validating-acco...

6 digits are far, far too extreme from a usability perspective. We have IBANs as world wide unique account identifiers. They are very unwieldy with up to 34 digits, depending on country. And only 2 of them are checksum digits. Most mistakes are one or two wromg digits or missing/extra digits and that can be caught with 2 properly designed checksum digits.

This s unbelievable. My Norwegian bank account number has a check digit as does my Norwegian social security number.

The bank account numbers have had check digits since 1967!

Good luck rewriting all the COBOL to support the new number scheme :)

Reply on news.ycombinator.com