A blog on financial markets and their regulation
Pamper the consumers or the computer programmers?
January 25, 2013Posted by on
In case you thought that the answer to this question is obvious, you should read the report of the Reserve Bank of India’s Technical Committee to Examine Uniform Routing Code and A/c Number Structure. While recommending 26-digit bank account numbers (IBAN) in India, the Committee has this to say:
6.5.3 The main disadvantage (if we really have to pamper to customers as the information can be easily displayed/stored on debit cards and cell phones, besides the traditional paper diary/chit of paper) of this IBAN option is that though it entails least effort from banks and facilitates faster IBAN implementation, it provides a more complex payment system interface to customers due to long IBAN string. In other words, while efforts at banks’ end will be minimized, the customers will still have to remember and provide the long IBAN, including check digits, for their payment system activities. (emphasis added)
In other words, the convenience of the banks’ computers and their programmers trumps the convenience of hundreds of millions of consumers.
Another troubling passage in the report is the following discussion about why the branch code cannot be omitted in the bank code (IFSC) that is used for electronic fund transfers:
Upon enquiring with banks, it is learnt that many banks have not built any check-digit in their account numbers. Thus, any inward remittance which comes to a bank will be processed even if there is any mistake in account number, as long as that account number exists in the beneficiary bank. In the absence of check digit in account numbers, many banks depend on the branch identifier to avoid credit being afforded to wrong accounts. This is a significant irreversible risk where wrong beneficiary would get the credit and customer would have no recourse – legal or moral
The idea that a branch identifier is a substitute for a check digit is a serious mistake. Any reasonable check digit should catch all single digit errors and most (if not all) transposition errors (where two neighbouring digits are interchanged). These are the most common errors in writing or typing a long number (the other common error of omitting a digit is easily caught even without a check digit because the number of digits in an account number is fixed for each bank). The use of the branch identifier on the other hand is not guaranteed to catch the most commonly occurring errors – many single digit errors would lead to a valid account number at the same branch. With the increasing use of electronic fund transfers (which ignore the name of the account holder and rely only on the account number), I would have thought that it would make sense to insist that all account numbers should have a check digit instead of insisting that the IFSC code should include a branch code. But that would place a greater burden on some overworked computer programmers in some banks – and regulators apparently think that systems people (unlike consumers) must be pampered at all costs.
The problem is not confined to banking. In the financial markets also, the convenience of the programmers often dictates the nature of market regulation, and the systems people are able to hold the regulator to ransom by simply asserting that software changes are too difficult. On the other hand, whenever I go to websites like stackoverflow in search of answers to some computing problem, I am constantly amazed that there are so many people able and willing to find solutions to the most difficult problems. In an ideal world, I think regulators would require every systemically important financial organization to have senior systems people with a reputation of say 10,000 at stackoverflow or some such metric of competence and a “can do” attitude.
While we have “fit and proper” requirements for the top management of banks and financial organizations, Basel and IOSCO do not impose any “fit and proper” requirement on the systems people. I think this needs to change because so much of risk comes from poorly designed and poorly maintained software.