IBAN India Integration and Structure Guide

Memorandum

1. Constitution of Technical Committee to examine uniform routing code and A/c number structure

Two national payment systems, RTGS and NEFT make use of IFSC in routing of transactions. The IFSC is an 11 digit alpha numeric code, with the first four digits identifying the bank, fifth is numeric (kept 0) and the last six digits represent the bank branch. With the roll out of Core Banking in almost all major banks, there is a demand for doing away with branch identifier in IFSC and to route all transactions only on banks’ IFSC. To study the matter in detail before arriving at any decision in the matter, a technical committee is being constituted to examine the feasibility of same leading to centralized processing of transactions.

2. The Committee will be headed by CGM, DPSS and will comprise officials from the following:

(i) Department of Payment and Settlement Systems, RBI;
(ii) Department of Information Technology, RBI;
(iii) Department of Banking Operations and Development, RBI;
(iv) Department of Statistics and Information Management, RBI;
(v) Rural Planning and Credit Department, RBI;
(vi) Urban Banks Department, RBI;
(vii) IDRBT;
(viii) Indian Banks’ Association;
(ix) State Bank of India, Punjab National Bank, Canara Bank, Abhyudaya Bank, Axis Bank and HDFC Bank;
(x) Committee to co-opt other experts if necessary.*

3. The mandate of the Committee will be to study the following and submit its recommendations on:

(a) The need for branch identifier in IFSC in today’s CBS environment;
(b) Look into the feasibility of doing away with branch identifier in IFSC;
(c) Benefits of the proposed change that will accrue to the banks and others stakeholders;
(d) Readiness of banks and payment system operators to implement the same and time required for making systems compatible for the same;
(e) Costs associated with the same at all levels and;
(f) Positive confirmation implementation by banks;
(g) Desirability of implementing IBAN replacing multiple identifiers for all financial transactions;
(h) Harmonisation of all bank/branch codes (IFSC / BSR Code / MICR Code / SWIFT BIC etc.);

4. The Committee will submit its report in 3 months time.

(Harun R. Khan)
Deputy Governor

August 10, 2012

Executive Summary

The payment systems environment in the country has evolved, over the last decade, from a largely paper-based system to one where multiple electronic systems co-exist, seeking to meet various requirements of the users. Coinciding with the developments in payment systems, adoption of various Core Banking Solution (CBS) systems by banks provided the necessary leverage for straight-through-processing (STP) of payments, thereby enhancing the speed and efficiency of these systems. In the above process, however, various solutions developed over a period of time adopted different mechanisms to identify and sort payment instructions / instruments, and route the same to respective banks / branches. This multiplicity of sorting and routing codes had not only necessitated the building of different interfaces at bank but has also made interoperability among systems difficult. This raised the need to have a relook at these codes and their suitability to present needs. It also raised the question of relevance of branch identifiers in routing codes under core banking environments.

Another pertinent issue related to that of uniform standard of account numbering across banks, or more precisely the lack of it. With each bank devising its own account numbering structure varying in length, pattern and composition, and the absence of built-in check digits, has led to a situation where even basic validations on account numbers is not possible during origination of payment transactions which would go a long way in reducing the incidences of credit going to wrong beneficiary, especially in an STP environment handling huge volumes of transactions. Hence, the Committee recommends desirability of having a uniform account number structure across banks, preferably with suitable provision for built-in check digits.

The Committee also analysed the above issues, both from technical and operational perspective, while considering the pros and cons of all the options available. Feedback from banks was also taken into account.

Branch identifier in IFSC is being used by banks for validation, reconciliation and other purposes. Removing the same may put many banks to risk who use it along with account number to route the transactions to the intended account as many banks do not have 'check digit” built into their account numbers. As regards the difficulties being faced by originating customers in furnishing branch IFSC, other ways can be found to educate and assist the customers in obtaining IFSC required for remitting funds. The current DPSS instructions directing such assistance to be given by bank staff to those requiring help should serve the purpose. Besides individual customers, a growing number of corporate entities, including government agencies use these systems for disbursing payments, for whom the benefit of ensuring credit to the correct account far outweighs any possible inconvenience in terms of providing the IFSC inputs. Hence, it is recommended that the present system of branch identifier in IFSC may continue to be used.

While examining the feasibility of harmonising existing routing codes, it was observed that the MICR routing codes being used in cheque clearing system cannot replace and in turn cannot be replaced by IFSC due to constraints in the MICR technology as well as the coding pattern adopted. Thus, the Committee was of the opinion that IFSC is best suited for routing purposes in payment systems and it may continue to be used. It is recommended that any new payment system should use only the IFSC for routing purposes. This will also facilitate the smooth integration with the four alpha character bank identifier in the IBAN that is being recommended.

After studying the present account number structure across banks in detail and observing the absence of any uniformity in these structures, the Committee concluded that adoption of IBAN is essential not only for bringing in uniformity but also for enhancing the efficiency in systems that use account numbers as a critical input for successfully processing the payment transactions. In this regard, the most important benefit of adoption of IBAN account numbering structure would accrue in the form of its ability to facilitate validation of account number in terms pattern, fixed length and check digits at transaction originating stage itself (as the details of the pattern would be same across all banks), thus minimising the chances of wrong credit.

Four options of IBAN format were considered, i.e. longest, shortest, UIDAI based and pattern based IBAN. After evaluating these options on the basis of changes required at banks’ end and possible inconvenience to the customers, the Committee felt that longest IBAN is most suitable for the country. Longest IBAN envisages 26 digits IBAN for the banks in India with 18 digit account number, 4 digit bank code, 2 digit country code and 2 check digits. Under this system, banks can continue to use the existing account numbers, and where necessary the number will be padded with zeros to make the length of 18 digits as required.

Both the account numbers (existing number as well as the IBAN) may co-exist for about 3 years, during which period banks will make the necessary arrangements to fully migrate to IBAN for all payment and non-payment transactions, and domestic as well as international transactions. The banks will be required to modify their systems (all delivery channels) to accept both the numbers till such time.

Chapter I
Constitution of the Technical Committee and Methodology

1.1 The Technical Committee was constituted by inviting nominations from Indian Bankers' Association (IBA), commercial and cooperative banks along with representatives from select regulatory departments of the Reserve Bank. Subsequently, the Chief General Manager, Core Banking Division, DGBA and nominees of two cooperative banks were inducted to broad base the expertise and representation of the Committee. The Committee comprised of the following officials:

1.2 Shri S. Ganesh Kumar, Chief General Manager, DGBA, CO was a permanent invitee to the meetings of the Committee. Shri N.V. Vartak, DGM, Saraswat Cooperative Bank along with Shri Manoj M Rane and Smt. Subbalakshmi M Shirali, AGMs from Shamrao Vithhal Cooperative Bank were also invited to a few meetings of the Committee to obtain the perspective of cooperative banks on these issues.

1.3 The Committee held five meetings to deliberate upon the issues. The broad contours of the Report and final touches were entrusted to a smaller group comprising of S/Shri N Senthil Kumar, Subhakanta Satpathy, Sunil Shetty, Sharad Bishnoi, D. Sahoo and MVNK Prasad. The Committee places on record its appreciation of their efforts in examining the details of the technical issues at hand and giving valuable insights to the Committee.

Chapter II
Routing Codes and Account Number Structures – A Perspective

Background

2.1 The payment systems environment in the country has evolved, over the last decade, from a largely paper-based system to one where multiple electronic systems co-exist, seeking to meet various requirements of the users. Coinciding with the developments in payment systems, banks’ adoption of Core Banking Solution (CBS) has provided the necessary leverage for straight-through-processing (STP) of payments.

2.2 In the above process, however, various solutions developed over a period of time adopted different mechanisms to identify and sort payment instructions / instruments, and route the same to respective banks / branches of origination and destination. This has led to a situation where both banks and users (individuals, corporates etc.) are having to contend with multiple routing codes that exist in the system. To add to this complexity, the CBS systems of banks also have disparate structures for uniquely identifying customer accounts – some with branch identification as part of numbering algorithm and check sums to ensure accuracy of input (often manual). The need to relate a customer account with a branch is anathema to the concept of CBS. In the process, it was being debated as to whether branch identifiers were necessary and whether multiple routing codes could be done away with, and whether there was a need for uniform accounting numbering system for all banks. This is one of the terms of reference for this Committee.

Existing routing codes

2.3 MICR Code – As the cheque usage increased in the country, the manual systems put in place for sorting and clearing cheques became inadequate and required mechanisation of process/procedures to complete the tasks in time and accurately. This gave birth to Magnetic Ink Character Recognition (MICR) technology-based mechanised clearing systems which use MICR code parameter on cheques as the basis for clearing. It necessitated the allotting of MICR codes to every bank branch which was then encoded on every cheque issued by a branch participating in MICR clearing. Introduced in 1986, MICR clearing still handles a large number of cheques (around 5 million) every day. The MICR code structure is as under:

2.4 Though the MICR code has served its purpose over the years, there was a limitation in the code as total number of banks that this code could accommodate was only 999 though there are more than 1780 banks operating in the country. This limitation of allotting unique codes to each bank at an all-India level was managed till date since most of the cheque-clearing systems were local in nature. Moreover, a sub membership process enabled smaller banks to participate piggy back riding on a branch number exceeding 250. This was possible as no bank had branches exceeding 200 at any one clearing house. With the introduction of grid-based Cheque Truncation System with its pan India character, this limitation of MICR enabling only 999 banks to be direct members may prove to be an issue. Besides cheque-based clearing systems, the Electronic Clearing Service (ECS), including the Regional ECS and National ECS systems also use the MICR code to identify, sort and clear the transactions according to bank of origination and destination.

Indian Financial System Code (IFSC)

2.5 The above limitation in MICR code was sought to be overcome with the introduction of the Indian Financial System Code (IFSC) as routing code. The IFSC is an eleven-digit alpha-numeric code based on the pattern followed by the Society for Worldwide Interbank Financial Telecommunication (SWIFT). The IFSC format is given below:

The IFSC code is alpha numeric comprising of 11 characters, first four identifying the bank, fifth is numeric (kept 0) and last six characters identify the bank branch. Presently, the codes are alpha-numeric, and conform to the SWIFT BIC code. In the pre-CBS era, at most of the banks, the transactions were required to be sorted branch-wise and sent to respective branches for processing. This required each branch to be uniquely identified by a code. Real Time Gross Settlement System (RTGS) introduced in 2004 and National Electronic Funds Transfer System (NEFT) introduced in year 2005 work on the basis of Indian Financial System Code (IFSC).

SWIFT Branch Identifier Code

2.6 Bank SWIFT Code is a standard format of Bank Identifier Code (BIC) and is unique for each bank. These codes are used when transferring money and messages between banks.

The SWIFT code consists of 8 or 11 characters. When 8-digits code is given, it refers to the primary office.

• First 4 characters - bank code (only letters)
  Next 2 characters - ISO 3166-1 alpha-2 country code (only letters)
• Next 2 characters - location code (letters and digits) 
  (passive participant will have '1' in the second character)
• Last 3 characters - branch code, optional ('XXX' for primary office) (letters and digits)

However, SWIFT is yet to start their operation in India for domestic transactions. As such, BIC is not being used presently for routing of transactions domestically.

Banking Statistical Record (BSR) code

2.7 BSR code is a 7 digit code with first three digits identifying the bank and remaining four digits identifying the branch. BSR code is not used in payment systems but mainly finds use in tax receipts at banks end and at Government’s end. However, a common man or a bank customer is not affected by it as he / she does not have to quote it anywhere. As such, BSR is not a routing code and can be left out of consideration by this Committee.

2.8 As seen above, each of these routing codes serve its purpose and, irrespective of their legacy and limitations and are used in various payment systems. However, in recent times, with almost complete adoption of CBS by banks, the questions are being asked as to whether these routing codes serve any useful purpose when account numbers are uniquely identifiable in a CBS environment. There is also a case for examination if only one code can suffice in place of multiple codes.

Uniform Account Number across Banks

2.9 Bank account number identifies a relationship between a customer or an entity and a bank. The banks are not following any uniform format / standard in allotting account numbers to their customers and each bank has devised its own structure with length varying from 9 to 18 digits. The account number may or may not be unique across a bank. A few banks use branch code as a part of account number while other may be having a running serial number without any pattern built into it. Also some banks have check digit as a part of account number whereas other banks allot a running number without any check digit built in. Banks not having a check digit in the account number and not using any other additional field for identification of transaction run considerable risk of crediting wrong accounts. The electronic payment systems handles large volumes everyday and transactions get settled in real time or near real time leaving very less or no time for stopping a wrong credit.

2.10 Affording credit to correct account is the prime requirement of any payment system and has to be met to mitigate risk and ensure customer satisfaction. Different account number structure across banks rules out possibility of a common validation method across banks for preventing mistakes in crediting the beneficiaries’ accounts.

2.11 It is hence desirable that account number structure is uniform across the banks, preferably with suitable provision of check digit(s) built in. This will prevent credit going to wrong accounts and also facilitate STP. International Bank Account Number (IBAN) which is being used in many countries can be one of the options to be considered for standardising the account number across banks.

2.12 Any change in account numbers will involve a lot of changes / modifications at the banks’ end - both technical and operational. It will be huge task for the banks to allot and intimate the new account number to customers. The customers will take some time to gradually adjust to these changes in account numbers forcing the banks to build interfaces to accept both the account numbers for some time. Moving to IBAN will provide long term benefits to the banks and payment systems by bringing in standardisation across banks and interoperability in payment systems but any change happening across all the banks at the same time may also pose systemic risk.

Chapter III
Need for branch identifier in IFSC – A Review

Introduction

3.1 Under RTGS and NEFT, the customers originating the funds transfer are required to provide the details of beneficiary including the IFSC of the beneficiary branch to the originating bank branch to initiate a transaction. In order to facilitate customers in obtaining the IFSC of their branch, the code is printed on cheque leaves, pass book and banks also display these codes on their website. The list of IFSC of all the bank branches participating in NEFT is also available in public domain on the RBI website.

3.2 The NEFT rides on the Structured Financial Messaging Solution (SFMS) which is basically designed for both inter-bank and intra-bank exchange of messages between the bank branches. As such, every branch is required to have the unique branch IFSC to enable the systems to route the message to the intended branch. All NEFT messages flow to National Clearing Cell (NCC), Nariman Point, Mumbai (from originating banks through the Hub) for netting and thereafter are segregated and sent to respective banks by NCC for affording the credit to beneficiary’s accounts. The branch code is not relevant at NCC for arriving at a settlement or for routing the messages to the beneficiary bank. However, it is relevant at the bank level as explained below.

3.3 In the initial years of NEFT / RTGS, when all the member banks’ branches were not on CBS, banks used to segregate the inward messages based on branch IFSCs and forward the same to respective branches for onward credit to beneficiary customers’ account through mail / internal arrangements. Gradually, as banks moved to CBS platforms , they also centralised the processing of NEFT / RTGS transactions (STP-based), without the need for routing the transaction to the concerned branch. This development, along with the need for increasing customer convenience of not providing beneficiary bank branch's IFSC, raised the demand from some quarters for doing away with branch identifier in IFSC.

3.4 The group examined the above in the light of existing use of branch identifier in IFSC in systems where it is being used.

Utility of branch identifier in IFSC

3.5 An informal study of practice followed by a few banks revealed that although most of the banks on CBS had centralised processing of transactions without referring to branch identifier in IFSC, some banks were still using it for validation. Feedback received from NEFT member banks (Annex I) revealed that 67 out of 78 banks have branch identifier built in their account numbers and are in a position to afford the credit to beneficiary account without referring to branch identifier in IFSC. Initial examination of the matter indicated that there was no distinct benefit to large users of NEFT systems as initial creation of data base had already incorporated the complete IFSC code. The study also indicated that no distinct benefit or problem accrues to the informed users of the system as they are aware of the need to provide full details (11 characters instead of 4). Moreover, users carrying out NEFT transactions over the internet were assisted by respective banks in indicating the right IFSC number by a built in drop down menu.

Benefits of not having branch identifier in IFSC

3.6 The most important benefit of doing away with the IFSC would be that it would facilitate the customer originating the funds transfer transaction at the branch counter to no longer provide the 11 digit IFSC of the beneficiary’s bank branch. He does, however, have to provide the receiving bank’s name. Beyond, this there does not seem to be other significant benefits of not having the branch identifier.

Risks of doing away with branch identifier in IFSC

3.7 On the other hand, doing away with the branch identifier may pose certain problems and risks such as–

• The banks which are using branch identifier for validating the inward transactions would lose this validation measure (some banks’ CBS account numbering system includes branch codes for uniquely identifying customers)
• Some banks refer to branch identifier for locating the branch in case of mismatch in any field of the transactions, for further investigation.
• 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.
• It is useful in processing the failed transactions, especially in the case transactions originated by walk-in customers (non-account-holders), knowing the branch would greatly help in returning the funds if the beneficiary’s account cannot be credited for any reason whatsoever.
• It helps in resolving the disputed transactions.
• The banks which recently migrated to CBS continue to get a large number of transactions on old account numbers which are generally processed on the basis of branch identifier.
• Branch identifier helps in generating MIS reports - branch wise / region-wise information.
• Non-financial transactions (LCs/BGs) necessarily need IFSC as these are meant for a particular branch / office and cannot be handled with the bank IFSC.
• Inter-bank RTGS messages (R-42 messages) are also IFSC dependent as there is no account number in these messages.
• Scheduled commercial banks act as sponsor banks of RRBs. Non-availability of branch identifier in IFSC in RTGS/NEFT transactions will make processing of incoming transactions difficult as the receiving bank may not be able to identify whether the transaction pertains to its own branches or its sub-member banks as account number may not be unique across member bank and sub-members in the current scenario.

3.8 The Committee was of the view that detailed examination of costs was not possible as it involved discussions with various vendors and each bank would have its own complexities to enable estimates being obtained. However, back-of-the-envelope costing indicated huge costs, besides effort, without attendant benefits.

Recommendation

3.9 From the above, it can be concluded that the disadvantages and problems accruing to the system in the absence of branch identifier in IFSC far outweigh the few benefits of doing away with it. The single risk of wrong credits in the absence branch identifier will do more harm to customer service than the benefits put together that this change is expected to bring to customers. Other ways can be found to educate and assist the customers in obtaining IFSC required for remitting funds. The present instruction of the Reserve Bank to all banks to proactively assist customer at the counter to correctly identify the bank branch (and IFSC code in full) appears to meet the requirement of that segment of customers. In view of the above, it is recommended to continue the use of IFSC in the present form.

Chapter IV
Harmonisation of Routing Codes

Introduction

4.1 As noted earlier, different payment systems in the country use different routing codes for identifying the bank / branches for routing transactions. Cheque clearing / ECS suite of products use MICR code whereas NEFT and RTGS use IFSC. BSR codes are also being used to identify branch in some instances (tax payments), though not for payments processing. SWIFT will be using BIC for this purpose. Multiple routing codes hinder Straight Through Processing (STP) and also interoperability among different payment systems. Hence, it was felt desirable to have a common routing across systems to address this issue. The question arising from that need was to examine which among the existing codes can be used as the most appropriate code? Alternately, whether a new code needs to be identified as a standard to be adopted across the industry.

Can existing codes be merged into a single code?

4.2 From the structure of MICR codes, it can be seen that there are only 3 digits for banks which can be allotted to a maximum of 999 banks. There are more than 1600 banks in India and allotting MICR code to these many banks would not be feasible in the existing scheme of MICR code structure. BSR code also has the same issue of 3 numeric digits identifying a bank and is again not practical as a replacement for all other codes. Moreover, BSR is not used in processing payment transactions by the banking industry. The only option remaining is that of IFSC and the same is examined below.

4.3 In case of ECS, there would be certain problems if the MICR codes have to be replaced by IFSC, and these are:

• The ECS software application is a legacy system developed nearly 15 years ago. At present, the ECS (including RECS and NECS) system is operating in about 80 centres (after certain local ECS centres have subsumed with RECS centres). The replacement of MICR code-based processing and routing of transactions by IFSC would call for wide software changes in a legacy system.
• The ECS system is used for bulk payments and receipts by various institutional users (corporates, businesses, governments etc.) which hold the necessary bank details of the end-customers. Unless these institutional users are willing to take the complete responsibility of changing the customer-detail database and replacing the MICR code with IFSC code, the task of asking the customers to approach each institutional user to get the bank details replaced would be very huge and impractical.

4.4 Further, the National Payments Corporation of India (NPCI), which has been set up as the umbrella organisation for retail payments in the country, has recently launched the National Automated Clearing House (NACH) product which provides inter-operability between various codes such as MICR code, IFSC, IIN (Issuer Identifier Number), etc. Presently, for Aadhaar linked transactions, the routing identifier is IIN. The system has a single bank master to capture all 3 routing values, where either one of the value is mandatory for bank to register and to participate in clearing. Brief capabilities of the NACH are given at Annex II.

Recommendation:

4.5 Keeping in view the constraints listed above, the Committee recommends the following:

1. That existing routing codes are serving their purpose and may be continued. The MICR code being used in existing systems, cheque clearing and ECS suite of products cannot be replaced by IFSC. The ACH of NPCI is designed to handle files with MICR, IFSC and IIN (Issue Identifier Number being used in card transactions routing) codes.
2. IFSC suits the new payment systems (RTGS and NEFT) and may continue to be used.
3. To ensure the inter-operability among the payment systems, it is recommended that any new payment system being rolled out in the country should be based only on IFSC.

Chapter V
Uniform Account Numbers and IBAN

Introduction

5.1 Bank account number identifies a relationship between a customer or an entity and a bank. The Committee observed that there is no uniform format / standard structure followed by banks in allotting account numbers to their customers. Each bank has devised its own structure with varying lengths and structure. Further, the account number may or may not be unique within the bank. A few banks use branch code as part of account number to achieve account number uniqueness and use both the account number and branch code fields to correctly identify the customer.

5.2 Non-standardisation of account numbers across banks proves a hindrance towards moving to STP of electronic transactions. In the absence of standardisation and check digit in account number, errors in feeding account number go unnoticed leading credits being afforded to wrong accounts. Without standardization of account numbers in terms of length, check digits and structure, it is not possible to ascertain the correctness of account number at the time of initiating transactions (including basic checks such as length of the account number field cannot be incorporated). With electronic mode of remittances taking the lead and handling of increasingly large number of transactions every day on STP basis in order to adhere to processing timelines, it is imperative that account numbers have built in checks to prevent any wrong processing.

5.3 It is therefore desirable that account number structure is uniform across the banks, preferably with suitable check digit(s) built in. This will facilitate STP and also prevent credit going to wrong accounts. In this regard, IBAN can be one of the options to be considered for implementation as an option which meets the above requirements.

Existing Account Number Structure in Banks

5.4 The existing account number structure across banks was analysed (Annex III) and the following points emerged from the analysis:

• Most of the banks have unique account numbers.
• Account number length varies from 9 digits to 18 digits.
• Most of the banks (67 out of 78) have included branch code as part of the account number structure. Some banks have product code as part of the account number structure.
• 40 out of 78 banks do not have check digit as part of the account number structure.
• All banks have purely numeric account numbers, except one or two foreign banks.
• Only in the case of 20 banks, account numbers are formed without any pattern with a unique running serial number.

5.5 As can be seen above, there are lot of variations among the account numbers allotted by the banks – in terms of length (varying from 9 to 18 digits), contents (alpha / numeric) and structure. There is hence a case for standardization of account numbers across the system. As part of the structure, various characteristics such as account type, account status, product code, bank code, branch code, check digits, year of opening etc., are embedded. A few banks have built branch code and other intelligence in the account number where as some banks have used a running number. Again, some banks have built check digit in their account numbers where as others do not have any check digit as a part of account numbers.

Challenges for changing account number

5.6 However, any change in account numbers will involve a lot of changes / modifications at the banks’ end. Banks in their feedback, compiled by IBA, (Annex IV) indicated that changing account structure entails major software changes and may have operational implications. Change efforts may be maximum where the banks have built account numbers with meaningful patterns (account type/branch code etc.) and such patterns are used in various modules, MIS and as input to business logics.

5.7 Further, it would also entail a lot of operational issues - new account number allotted to customers would need to be intimated to account holders, a gigantic task in itself. As the customers will take some time to gradually adjust to new account numbers, the banks will be required to have systems / interfaces which can implement both the account numbers for some time. Any change occurring across all the banks at the same time may also pose systemic risk (in case of wrong or incomplete implementation) and this has to be kept in view before arriving at any conclusion on the issue. Nevertheless, moving to uniform account number structure will provide long term benefits to the banks and payment systems alike by bringing in standardisation across banks and interoperability in payment systems.

5.8 However, the members of the Committee expressed the view that since standardizing account number structure is a one-time event involving high costs, this opportunity should be utilized to achieve broader objectives with long term perspectives.

Issues in Replacing the Existing Account Number- Technical Perspective:

5.9 The Committee debated that in terms of technical implementation, there are two options available to banks for adoption of uniform account structures – (a) creation of uniform account number as another attribute to system/database-generated internal primary key without affecting the database structure, and (b) creation of a mapping table at the periphery of their payment systems to convert the IBAN into existing account number to route the message to database.

5.10 Option A – All CBS systems internally identify an account with its own system / database-generated internal primary key, and the account number (with its uniqueness) would merely be one such attribute. As such, the CBS may have the option to generate more than one such unique attribute and its implementation will not a big challenge for the CBS systems. Once such attribute is created at the database level, it can be used by various module interfaces to retrieve the concerned account record and act on it. Existing modules can continue to access the account record based on existing attribute / old account number while payment system related modules can access the record through the new attribute (for instance, the IBAN). Thus, this technical approach provides the way to migrate module by module to the new account structure smoothly, if required.

5.11 Option B – Since banks have already established some sort of uniqueness of account numbers across branches, banks could set up a mapping table at the periphery of their payment systems to convert the incoming new account number (IBAN) into the combination of existing account number and branch IFSC, and route the messages through the existing interfaces. Banks should develop an algorithm to generate IBAN which could support the IBAN based look up from the mapping table. The main technical advantage of this approach is that the objective of supporting IBAN can be implemented with least amount of software changes as neither the CBS core module nor the existing payment services modules need to be changed. Only an IBAN generator and a “mapper” module need to be developed and implemented. The main technical disadvantage of this option is that the currency, availability and reliability of mapping services become very critical.And, the main business disadvantage is that customers will continue to hold both the original account number and IBAN and implementation of IBAN may not have any meaningful purpose except for providing uniformity in account number structures.

5.12 In view of the above technical options for software changes at banks’ CBS level, the Committee deliberated and suggested that banks could co-ordinate with the CBS vendors to decide on appropriate technical work suitable for their respective bank to implement IBAN based processing of payment system messages. Further, banks could also make their own arrangements for routing messages pertaining to sub-members sponsored by them in various payment systems based on the bank code identifier in the IBAN system.

Guiding Principles for bringing in changes in account numbers

5.13 The guiding principles behind recommending suitable options are:

• Any change in account number across banks will affect three stake-holders directly, viz. banks, customers and payment systems operators.
• At the banks' end, the change will affect the software being used and also the processes deployed by them. Software changes will be complex, large and expensive for banks as well as payment systems operators. Similarly, the customers would also require to undergo usual process of change management. In case of customers, the issue of remembering large numbers can be overcome by adopting various means, for instance, having the same pasted/printed on Debit cards.

5.14 Any proposal should hence be capable of addressing the interests of all the stake-holders and have the following features:

• It should be easy to implement across banks – requiring least amount of changes in existing database structures and seamlessly integrate with various modules;
• Not very expensive or time-consuming for the banks to introduce ;
• Should not cause too much inconvenience to the customers;
• Should be suitable for implementation in a gradual way - not a big bang approach which could put existing systems/ operations of banks at risk.

5.15 One of the options to achieve standardisation in account numbers is implementation of IBAN which will bring uniformity in the account number across banks. IBAN can be of different lengths and can be based on various parameters. The Committee’s task was to consider various proposals of IBAN that can be implemented and recommend the option which will suit Indian conditions the best.

Case for IBAN in Indian Banks

5.16 One important aspect of an efficient payment mechanism is its ability to route payment messages efficiently, each and every time, to the appropriate destination. Such routing can be at two levels – (i) at the system level where messages are routed between participants, and (ii) at destination bank level where messages are routed and processed to appropriate destination account numbers. While an identifier of a bank/participant is required to achieve the first, in case of the second typically, the destination account number should facilitate such routing. In this context, it would be worthwhile to note the salient features of the IBAN system.

5.17 IBAN is an international standard for identifying bank accounts across national borders. It was originally adopted by the European Committee for Banking Standards, and was later adopted as an international standard under ISO 13616.

5.18 IBAN's primary purpose is to:

• facilitate domestic/cross-border inter-bank electronic payment
• avoid routing errors in domestic/cross-border payments
• facilitate straight through processing
• making payment in a reliable manner as remitter can validate the beneficiary account number

5.19 Further, due to its standardised format, the use of IBAN based account number can also facilitate validation of account numbers – in terms of its pattern, fixed length parameters and check digits (calculated on basis of ISO 7064 definitions) - at the time of initiating a payment transaction. This will help in preventing the errors in credits being afforded to wrong beneficiary accounts. This becomes more important in view of the following: (i) credits being afforded solely on the basis of account number, (ii) large number of transactions being processed in electronic modes of payments using straight-through-processing making it difficult for the banks to subject them to any manual check towards verification of other account details (iii) possibility of withdrawal / transfer of funds in very short time thus reducing the chances of recovery in case of credit being routed to wrong account. These important benefits make a strong case for recommending IBAN for banks in India.

5.20 As IBAN is a system which is being used across the world by the banks, there is merit in considering the same for implementation in India instead of inventing something new.

Format of IBAN

5.21 IBAN mainly consists of two parts - first part consists of country code (2 characters) check digit (2 numeric) bank ID (4 characters) and second part consists of BBAN which can be decided by banks (max up to 26 characters). Thus, IBAN can be of maximum 34 digits with BBAN up to a maximum 26 characters long. However, the length of Basic Bank account Number (BBAN) and IBAN should be uniform across the banks in the country.

5.22 The format of the IBAN (Country Code + Check Digit + Bank Code + Account number) shall be 2!a2!n30c where:

(i) first two letters(2!a) shall always be the two character country code(alpha-2 code) of the country in which the financial institution servicing the account resides;

(ii) third and fourth characters (2!n) shall be the check digits, as calculated from the scheme defined in ISO 13616;

(iii) remaining part of the IBAN (up to 30c), the BBAN, shall only contain upper and lower case letters ( A to Z and a to z) and numeric characters (0 to 9), without special characters such as separators and punctuation that may be used in national account number schemes;

(iv) BBAN shall in addition: have one fixed length per country, and include within it a bank identifier with a fixed position and length per country.

Basic Bank Account Number (BBAN) is a standard for identifying bank accounts across a country.

Chapter VI
IBAN Structure for India

Broad Considerations for type of IBAN

6.1 The format of the IBAN has certain parts which are fixed by definition, while for the BBAN, the length and format can be decided by the respective countries. In this context, initially the following views were expressed by the participant members while deciding the type of IBAN that can be considered for the Indian banks.

1. Any attribute which might change with time in the course of existence of an account (example: branch code, account status, etc.) should not be part of the account number structure.
2. Alphabets as part of BBAN may not be acceptable considering the exposure of general public to English language, while numbers are readily identifiable by all. Also, remembering numerals may be easier than remembering alphanumeric characters in random order.
3. It is better to have BBAN formed with known pattern (parts) instead of random sequence numbers. This will help in remembering and enhancing the human-usability of IBAN. Such pattern should be followed across banks.
4. BBAN should be, at the very least, portable across branches of a bank. It is recognized that various attributes relating to account number such as branch codes, bank specific product codes, bank code, location codes etc., tend to change over time periods and therefore it is not advisable to fit in such information as part of the BBAN.
5. Although BBAN could accommodate up to 30 characters (including 4-digit bank code), the length of BBAN should be minimal while maintaining uniqueness at the same time. While shorter BBAN enhances ease of use, the BBAN should have sufficient length to ensure account numbers can be accommodated uniquely for a foreseeable future.
6. Ability and ease of creating BBANs for existing and new accounts is another important consideration. Implementation road map will also provide options in choosing the BBANs. If BBAN is to be envisaged to replace existing account numbers eventually for all types of transactions so that customers can operate his account with a single identifier, BBAN will have to be shorter or formed with patterns well known to customers and tellers.
7. Other than payment system related objectives, if BBAN is envisaged to facilitate other broader objectives that arise out of standardization, options of BBAN will be different. For example, if account number portability across banks is envisaged, account number structure recommended will be different.
8. Prevailing structures and lengths of account numbers in use in various banks need to be looked into before deciding the BBAN.
9. Account numbers may already have been disseminated by the account holders to various systems (banks, payment institutions, intermediaries, etc.) for payment purposes, and these cannot be changed to new numbers overnight.

6.2 Thus, in order to minimize any problems that might arise due to incompatibility of numbers or non-proliferation of new numbers across the systems, the Committee felt that IBAN implementation should be done in a phased manner where the payment systems at RBI and at bank levels should support both the existing account numbers and the new IBAN account numbers for a minimum period of 3 years. Till such time, customer should be able to operate his account through the existing account number as well as the new account number. The BBAN scheme should ensure that each account number created as per the scheme is unique within the bank across different types of accounts, branches and lines of businesses. This will enable each bank to identify uniquely a given BBAN number.

Format of IBAN for India- Four broad options

6.3 A perusal of IBAN formats implemented in various countries showed (Annex V) that the IBAN number size varies from 15 to 31 digits. Most of the IBANs include branch codes, national check digits in addition to bank code, long account serial number and IBAN check digits. The IBAN has been implemented by keeping the local conditions in mind. Similarly, we need to decide on type of IBAN that will suit Indian banks’ and systems’ conditions best. As there is no uniformity in account numbers presently, efforts at uniform account numbers using IBAN have to be made from scratch, for which various combinations of IBAN need to be examined.

6.4 The Committee examined the technical aspect of IBAN and debated the following four types of IBAN, along with the advantages and disadvantages of each type.

1. Longest IBAN
2. Shortest IBAN
3. Aadhaar Based IBAN
4. Pattern Based IBAN

6.5 Longest IBAN

6.5.1 This scheme specifies an IBAN with sufficiently larger length of 26 digits (total length 26 = 2 for country code + 2 for check digits + 4 for bank code + 18 for account number). The idea is to have an IBAN that can be created readily by using the existing account numbers of banks. A study of existing account numbers with banks operating in India revealed that the longest account number is of 18 digits, and hence this length has been retained for the BBAN part of the IBAN. All other existing account numbers of varying lengths can be padded (prefixed / suffixed) with zeroes to arrive at the fixed-length BBAN of 18 digits. Thus, the IBAN can be readily arrived at by prefixing country code, check digits and bank code to the BBAN so arrived at. Such a system would also facilitate making the IBAN mandatory after some time for all payment transactions.

Advantages of Longest IBAN: 26 Characters (4 + 22 BBAN):

6.5.2 In this scenario all banks can continue to use existing accounts and no significant software changes are required in non-payment transaction interfaces. Software changes are required only in payment interfaces to process IBAN based messages. Under this approach, least efforts are required from banks. Following advantages are seen in this format of IBAN.

1. Customers have to deal with their old account number prefixed by some more digits thus retaining a major part of old account number.
2. Banks will be required to make minimum changes in their systems. Thus this can be implemented in a short time and without much expenditure at banks’ end.
3. This will meet the requirement of all the banks including those who have allotted lengthy account numbers.
4. Since existing account numbers are part of IBAN, existing interfaces of other non-payment system modules and related data access layers need not be modified to provide to implement IBAN in the bank.

Disadvantages:

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.

6.6 Shortest IBAN

6.6.1 This scheme specifies an IBAN with a lower width of 18 digits which includes 10 digits for account number (supporting 10 billion account numbers).

6.6.2 In terms of customer friendliness, this would necessitate the customer to remember a shorter length number for providing the same for payment purposes. Further, since this BBAN number is far shorter than the existing account numbers of most banks, it would necessitate all banks to generate the IBAN from scratch. In this process, all banks can generate new account numbers with a uniform pattern, thus replacing the existing system of account numbering across banks in one go. In this context, it may perhaps be the fastest one to implement.

6.6.3 However, there would be many disadvantages in considering this option of IBAN:

1. Within the shortest length, known and meaningful pattern cannot be accommodated as patterns will severely reduce the total number of available account numbers.
2. Since most of the bank’s account numbers are pattern based and more than 10 digits, IBAN cannot be created by using existing account string. Customers may have to deal with entirely distinct 16 digit IBAN (68 0027 4324 5672 46) in a payment system transaction.
3. Even though the total number of digits in the IBAN is smaller as compared to other schemes, lack of meaningful patterns make this number less user friendly.
4. Since the account number part of IBAN is merely a sequence number, (unlike UID based scheme explained below), this scheme does not provide any additional benefits.
5. It may not support portability of account number across banks as there will be significant number of common sequence numbers between account numbers in use in any two banks. If part of IBAN is required to be used for all transactions for giving a single account number to customers, in most of the banks, customer interfaces of other non-payment system modules and related data access layers would need to be modified to accept the new number for over the counter transactions.
6. It provides a more complex payment system interface to customers due to entirely distinct IBAN string. Customer will have to use two distinct numbers (without any common pattern); one for carrying out payment transactions and the account number for other purposes.

6.7 Aadhaar Based IBAN

6.7.1 Aadhaar number is the Unique ID being allotted to all residents of the country by UIDAI (Unique Identification Authority of India). This number will be of use in many instances and there are possibilities of people getting used to remembering this number easily. The IBAN can be based on this number thus making it easier for the account holders to remember their account numbers.

This option of IBAN would have an overall length of 24 digits as indicated below:

6.7.2 Some advantages of having an UID-based account numbering system are:

1. Identity related numbers conceptually qualify to be part of the account number as it uniquely identifies entities which can have bank accounts. Only an entity which has an Aadhaar number will be able to open an account with banks thus serving the banks in preliminary identification of the customers. Legal entities would need to be addressed separately.
2. As individuals tend to use UID in their day-to-day life, UID part of IBAN will be eventually in the minds of people. Standardisation of account type will make the second part “0101” uniform for all primary saving bank accounts of individuals. Bank code is intelligible to tellers and will become intelligible to customers. Only the two digit check digits are unconnected to the customer. Hence the IBAN formed with the UID will be easier to remember as compared to IBAN which is formed entirely of unconnected sequence of digits.
3. Long term benefits of using UID are enormous in the future , where many databases will be integrated through common IDs. This will also support Government direct payment schemes, reduce transaction costs in matching codes across different databases, facilitate generation of banking and social statistics, bank’s credit risk management processes, fraud prevention, KYC efforts, effective Financial Inclusion assessments, increased level of authentication etc.
4. It supports, portability of account number across banks, i.e., most of the customer can retain 89% of their old account, i.e., 16 digit of 18 digits (underlined portion 68 4324 5672 4658 0101) and all customers can retain 78% of their old account, i.e., 14 digit of 18 digits (68 4324 5672 4658 0101). Only the last four digits of the account number identifying account type and account number will be required to undergo a change making it easy to port an account number across banks.
5. It provides to the banking system a solid account numbering structure with huge amount of indirect and long term benefits and provides a personal and easy way to remember account number for carrying out payment and other transactions.

Disadvantages:

6.7.3 The main disadvantages of this options are:

1. This option will need a complete overhaul of the existing account numbers across the banks, for which widespread software and process changes of banks’ systems and payment systems modules will be required. Changing account number for millions of customers across banks will be a gigantic task and very difficult to manage. Hence, this scheme does not support quick start of IBAN implementation across the banks and phased approach is necessary for implementation.
2. If part of IBAN is required to be used for all transactions for giving a single account number to customers, customer interfaces of other non-payment system modules and related data access layers ( teller module for over the counter transactions) should be modified.
3. However it provides to the banking system a solid account numbering structure with huge amount of indirect and long term benefits and provides a personal and easy way to remember account number for carrying out payment and other transactions.

6.8 Pattern Based IBAN

6.8.1 Under the scheme, a pattern based IBAN is suggested. Patterns could be 4 digit product code + 10 digit serial number, where product code could be standardized with respect to information and operational objectives.

6.8.2 As we can see, such IBANs are not user friendly, though they may have some benefits due to standardization of product code in terms of generating statistics and monitoring.

They do not support account number portability and do not provide a single view of account to customer. Some part of the IBAN may be same as that of existing account numbers but remaining part of the IBAN may be distinct due to standardization. However, this scheme will not be easy to start as it would entail a fresh creation of account numbers across all banks for all their customers.

Conclusion

6.9 After a lot of deliberations on type of IBAN best suited for Indian banks, the Committee recommends ‘Longest IBAN’ option/scheme. Under any other type of IBAN, all the existing account numbers will undergo change which is a very huge change both in terms of cost and efforts. The banks have implemented CBS recently and in most of the cases, customers were allotted new account numbers under CBS. Changing account number again for them is not advisable and it will be better if existing account number is retained. This is possible only under Longest IBAN format, even though the users may have to remember a longer account number.

6.10 The main reasons for recommending the longest IBAN are as follows:

1. The existing number of the customer will be retained as it is. As such, customer will not face much inconvenience in the changed scenario.
2. Banks will be required to make minimum changes in their systems in comparison to other options. Thus this can be implemented in a short time and without much expense at banks’ end. Any other option will be requiring change in account number for all the existing customers which will be a very huge task and can be quite arduous for the banking sector.
3. This will meet the requirement of all the banks including those who have allotted lengthy account numbers.

6.11 In this context, the following is also recommended:

(a) Within the longest IBAN, the length of BBAN should be 22 digits. Those banks which have a shorter length in their existing account numbers can pad the numbers with zeros to bring the length to the required 18 digits.

Since IBAN provides for check digits, the BBAN may or may not have the check digits. As such, in case of check digits in existing account numbers, banks may discard its use or continue to use it for non-payment transactions (where old / existing account numbers may also be used). This may be left to the banks.

(b) The nature of bank code – whether numeric or alpha – within the BBAN was deliberated by the Committee. While numeric code has the advantage of being language-agnostic, the Committee felt that alpha codes help in easily remembering and identifying a bank. Further, with technological changes taking place, virtual keypads, drop down options etc. are being used at ATMs and micro-ATMs facilitating the input of alpha data as part of account number. Micro-ATMs are in any case assisted in their usage. In terms of possible combinations, alpha-based codes facilitate having larger number of bank codes in comparison with numeric codes.

First four characters of IFSC identify the bank. As bankers and customers are well versed with these codes now, the Committee recommended that same should be taken in IBAN as bank code rather than creating a separate code for this purpose which would lead to further proliferation of bank codes. The same would be the case if numeric code is opted for.

(c) IBAN is primarily used for international remittances. However, there is an advantage in using the IBAN for domestic remittances as well as it will prevent the credits being afforded to wrong account numbers. Hence it is strongly recommended that the IBAN be used for all domestic payment transactions as well.

(d) Account holders may be given an option by the banks to generate IBAN online by feeding his existing account number and other information, if required. For the customers not having internet banking facility, banks may provide the facility of generating IBAN through SMS. A SMS confirmation can be sent to account holders for such requests received which can be used by him for intimating his IBAN to other persons if necessary.

(e) Both the account numbers (existing number as well as the IBAN) will co-exist for about 3 years, during which period banks will make the necessary arrangements to fully migrate to IBAN for all payment and non-payment transactions, and domestic as well as international transactions. The banks will be required to modify their systems (all delivery channels) to accept both the numbers till such time.

(f) IBAN will be used only for identifying the account number for transaction and not for routing in payment systems. Routing will be based only on the routing codes being used for the purpose. This is for the reason that account number are a part of body of payment message and not header and payment systems do not read the body of payment messages.

6.12 In addition to above recommendations, following points are also proposed which may be considered by the banks for adoption.

• The branch code can be a part of IBAN as long as it does not hamper portability of account number within the bank.
• IBAN may also be used counter transactions also to prevent any mistake taking place in over the counter transactions.

6.13 Portability of Account Number after IBAN implementation

Despite this aspect not being a part of the Committee’s mandate, the issue was examined. During discussions of the Committee, two constraints emerged which would hamper the account number portability even after the implementation of IBAN account number structure. are (i) Bank code is an integral part of IBAN and as such, it does not facilitate account number portability across banks (ii) even if we consider portability of the account number without the bank code, it would give rise to a scenario where the said number may already be allotted to other customer of the destination bank.

Hence, the Committee concluded that account number portability may not be feasible even with IBAN implementation.

Annex I

Responses received from Member Banks on Utility of branch identifier in IFSC:- Position as on 16 th October, 2012

Public Sector Banks

Private Sector Banks

Views of The Lakshmi Vilas Bank Ltd.

Foreign Banks

Co-operative Banks

Annex II

National Automated Clearing House (NACH)

NACH system accepting multiple routing codes

Supports multiple routing codes used in India for electronic clearings – MICR, IFSC code and IIN number - so reach can be quickly expanded. While for Aadhaar the routing identifier is IIN (Issuer Identifier Number) is issued by NPCI and MICR and IFSC are issued by RBI to all banks. System has a single bank master to capture all 3 routing values, where either one of the value is mandatory for bank to register and to participate in clearing. The routing identifier for all account based transactions can be either MICR or IFSC.

Security features of ACH

– Web enabled with SSL

– Dual factor authentication for bank/institution users – user id and password with digital token/certificate

– Digital signing of transaction files before sending to take care of non-repudiation. While NPCI sends the inward file, it is digitally signed by NPCI.

– File transfer is end to end secured because of use SSL protocol (HTTPS).

– Maker checker at every stage – including the file upload at Banks/ Institutions

– Additional level security using transaction level Checksum controls – at the transaction level a checksum is present which uses critical fields to ensure non tampering of files during the processing.

Other features of NACH system are as given below:

Supports both Aadhaar and Account no based transactions
The single system can process transactions based on either Aadhaar or Account number based transactions. There are different transaction codes to identify if a transaction is Aadhaar based or Account based in credit. There is a separate transaction to identify and support debits.

File Formats and Transaction types
It supports multiple file formats in text like APB, ECS, ACH and in xml. The system has a file transformation engine and internally it uses only ISO 20022 formats for processing.

Settlement process
System has the capability to run multiple settlement sessions.

MMS - System has 'Mandate Management' (MMS) Capabilities for Debit transactions to facilitate banks to exchange and track the mandates end to end. A Unique Mandate Reference No (UMRN) is issued to each mandate request and status of the mandate is stored in central system. It can validate the UMRN in each debit transaction before accept for further processing in clearing system of banks.

DMS - It has a dispute management system (DMS) for handling and resolving disputes.

Scalability
System can process 10 million transactions in a business day in the current H/w infra. The system can scale easily to 20 + million transactions in a day with addition of H/W.

Resilience
It has complete redundancy within Primary and has got a far site DR setup. The Primary, Highly Available and DR environment of the same capacity.

Access and Reachability
System is web enabled. Banks do not have to invest in additional H/W anything like RTGS or CTS gateway to participate in the system.

Annex III

Structure of Account Numbers across banks:

Annex IV

Response from Banks on IBAN

Public Sector Banks

Private Sector Banks

Foreign Banks

Annex V

IBAN format in Other Countries