Could bank account numbers be portable like mobile numbers?
The Independent Commission on Banking recently published an interim report on their Consultation on Reform Options. This interim report raises the subject of bank account number portability. Section 5.17, to be specific, says that:
Beyond improvements to the existing system, full account number portability would enable customers to change banking service providers without changing their bank account number. This would remove the need to transfer direct debits and standing orders, which remains the main area where problems may arise. In the past, portability has been rejected as overly costly, but if no other solutions appear effective and practicable, it should be reconsidered to see if this remains the case given improvements in IT and the payments system infrastructure.
It seems reasonable for the Commission to wonder why customers cannot port their account number from one bank to another the way that they can port their mobile phone number from one network to another. That seems a plausible request for 2011, but phone numbers and account numbers aren’t quite the same thing. A phone number is an indirect reference to your phone (well, your SIM card actually) whereas the account number is the “target”. Thus, we shouldn’t really compare the account number to the phone number, but think of it more as the SIM. Each SIM card has a unique identifier, just as each bank account has an international bank account number (IBAN). When you turn on your phone, essentially, your SIM tells your mobile operator which phone it is in and then “registers” with a network. I am writing this in Singapore, where I just turned on my iPhone, so now my O2 SIM card is registered with Singtel. When you call my number, O2 will route the call to Singtel, who will then route it to my phone. But how does the call get to O2 in the first place?
In most developed nations there is what is called an “All Call Query” or ACQ system: there is a big database of mobile phone numbers that tells the operators which mobile network each number is routed by. In order to make call connections as fast as possible, each operator has their own copy of this database that is regularly updated. Note that for reasons that are too complicated (and boring) to go into there, in the UK there is a different scheme, known as indirect routing, whereby when you dial my phone number 07973 XXXXXX it is routed to Orange (because that’s where all 07973 numbers originated from) and then Orange looks XXXXXX number up in its own database to see where to route the call to (in this case to O2). This is why calls to ported numbers in the UK take longer to connect than they do in other countries.
It’s entirely possible to envisage a similar system working for banks, whereby we separate the equivalent of the mobile phone number — let’s call it the Current Account Number (CAN) — from the underlying bank account and have an industy database that maps CANs to IBANs. This database would be the equivalent of the ACQ database. (I rather like the branding too: if the banks decided to operate this cross-border, they could label it the international current account number, or iCan.) So the bank sends your salary via FPS to the iCan, and the database tells FPS which actual IBAN to route it to. No matter which bank accounts you use or change to throughout your employment, the employer always sends the salary to the iCan and thus reduces their own costs.
There is an analogy to this is in the way that some of the new contactless payment cards work. In the US, American Express credit cards give up what is called an “alias PAN”. The PAN, or primary account number, is the 16-digit number on your credit card. When you use your Amex card via contactless, the 16-digit number it gives up is not the actual plan but an alias PAN. Only Amex know which actual PAN this alias PAN refers to. The advantage of doing this is that if criminals get hold of the alias PAN, they can’t use it to make a counterfeit magnetic stripe card, because the alias PANs are only valid for the contactless cards (which they can’t counterfeit, because the contactless cards have computer chips in them).
In the UK, we route by sort codes. Any account number beginning 20- is known to be Barclays, so a payment switch will send the payment through to Barclays. We might decide, say, that sort codes beginning with 00 are iCans. When you get your first bank account, the bank sets up the IBAN and iCan. For your salary, direct debits, standing orders and so forth, you give the iCan. BACS and FPS will be told about iCans, so when a payment to an IBAN beginning “UK00-” enters one of those systems, they go to a shared database and look up the IBAN to route the payment to.
In the world of payments, a related discussion has already sprung up. This is the discussion about Legal Entity Identifiers (LEIs) that have been going on recently. Many interbank payment messages have account identifiers only and the some law enforcement agencies want to stop this and have banks validate the names as well (it will help to track funds to and from suspects I guess).
A global standardized Legal Entity Identifier (LEI) will help enable organizations to more effectively measure and manage counterparty exposure, while providing substantial operational efficiencies and customer service improvements to the industry ... The LEI Solution is a capability that will help global regulators and supervisors better measure and monitor systemic risk.
I’m sure I’d heard somewhere before, possibly at the International Payment Summit, that the plan was to use the SWIFT business identifier codes (BICs), but apparently that’s no longer the case. Fabian Vandenreydt, the new Head of Securities and Treasury Markets at SWFIT, recently said that the International Standardization Organization’s Technical Committee 68 (ISO TC68) has concluded that developing a new code would help avoid ambiguities that might be involved if existing codes are used. The BIC is made up of eight to 11 alphanumeric characters with four letters for the bank, two letters for the country, two digits for the location, and three digits for the specific branch but ISO TC68 want we we nerds call an MBUN (a “meaningless but unique number”).
I don’t think this is way forward for people, though. LEIs are unique corporate identifiers: a corporate identity has one, and only one, LEI. Fortunately, or unfortunately, depending on your view, there is no unique identifier for British persons (and nor is there likely to be under the present administration), nor Europeans, nor citzens of the world. And I don’t think we would want the financial services industry to develop its own sort-of-identity card scheme. We just want a simple, portable, pointer to a person that can be used to index into their KYC’d persona.
The easiest way to do this would be to assign a unique financial services identifier (FSI) to a person or other legal entity the first time that they go through a KYC process. I might have the FSI “citizendave!barclays.co.uk”, for example. One someone has one of these FSIs, then there would be no need to drag them through “know your customer” (KYC) again. This would greatly reduce industry costs and make the process of obtaining a new financial service — a new bank account, a new credit card, a new insurance policy, a new accountant — much simpler. Imagine the simplicity of applying for in-store credit for that new sofa by just giving them your FSI and watching the application form magically populate by itself on screen.
It doesn’t matter if a person has multiple FSIs, because each FSI will have been obtained as the result of a KYC process. If the FSI Directory ends up with two “Dave Birch” entries, so what? It’s not an ID card scheme, it’s a “save money for the financial services sector and make life easier for consumers” scheme. And it wouldn’t matter either if both of my FSIs point to different iCans: I might, for example, have a personal persona and a small business persona—lets say citizendave!barclays.co.uk and citizendave!rbs.co.uk and that point to my personal and my small business accounts—and I want to use them for different purposes.
Picture this. You are fed up with the appalling service you get from your bank, so you walk into a branch of New Bank. You ask to open an account, and are directed to the ATM in the lobby and asked to request a balance from your existing current account. You put in the card and enter the PIN. While the ATM is carrying out the balance enquiry, the FSI (obtained from your card) is sent to the Directory and within a couple of seconds both your account balance (from your bank) and your picture (from the FSI Directory) are on the screen. The New Bank agent presses a button and a pre-filled application form is printed out for you to sign and, once you have, the existing system for transferring accounts is triggered.
There might be another useful spin-off from the FSI as well. Suppose you could designate a default account against the FSI: generally speaking, your iCan, but it could also be a prepaid account somewhere, or your PayPal account or whatever. Then someone could send you money by giving your FSI: no need to type in names, sort codes, account numbers. Anyone could pay anyone by entering the FSI into the ATM, or their internet banking screen, or (most likely) their mobile. Simple.
These are personal opinions and should not be misunderstood as representing the opinions of
Consult Hyperion or any of its clients or suppliers
The English language version of this work is licensed under Creative Commons Attribution-ShareAlike 3.0 Unported License. If you wish to acquire the rights to make a foreign language translation of the work, please contact Consult Hyperion.
Please note that by replying in this Forum your comments become the property of Consult Hyperion and you assign all rights in your comment to us. Your comments may be edited for length and used online and in print but will always be attributed.
Meet us at:
- December 2013
- November 2013
- October 2013
- September 2013
- August 2013
- July 2013
- June 2013
- May 2013
- April 2013
- March 2013
- February 2013
- January 2013
- December 2012
- November 2012
- October 2012
- September 2012
- August 2012
- July 2012
- June 2012
- May 2012
- April 2012
- March 2012
- February 2012
- January 2012
- December 2011
- November 2011
- October 2011
- September 2011
- August 2011
- July 2011
- June 2011
- May 2011
- April 2011
- March 2011
- February 2011
- January 2011
- December 2010