6 ms·

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 sim

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.

zozbot234 7y ago
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.
- really3452 7y ago
  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.
  - gmueckl 7y ago
    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.
  - kwhitefoot 7y ago
    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!
  - erincandescent 7y ago
    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-account-numbers-v580.pdf https://www.vocalink.com/media/3513/vocalink-validating-acco...
wcoenen 7y ago
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%20kingdom https://www.xe.com/ibancalculator/sample/?ibancountry=united...
- dfawcus 7y ago
  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.
  - Aeolun 7y ago
    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)
    - erincandescent 7y ago
      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
rhinoceraptor 7y ago
Good luck rewriting all the COBOL to support the new number scheme :)

zozbot234 7y ago

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.

really3452 7y ago
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.
- gmueckl 7y ago
  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.
- kwhitefoot 7y ago
  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!
- erincandescent 7y ago
  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-account-numbers-v580.pdf https://www.vocalink.com/media/3513/vocalink-validating-acco...

wcoenen 7y ago

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%20kingdom https://www.xe.com/ibancalculator/sample/?ibancountry=united...

dfawcus 7y ago
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.
- Aeolun 7y ago
  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)
  - erincandescent 7y ago
    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

rhinoceraptor 7y ago

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