SITEMAP FAQs GLOSSARY OTHER  LINKS CONTACT  US  
  ABOUT  US NOTIFICATIONS PUBLICATIONS DATABASE SPEECHES PRESS  RELEASES TENDERS FORMS EVENTS APPLICATION TRACKING SYSTEM  
Search
This Section
Entire Website
Archives
Quick Search
Year
Month

Period Search
From  
To      
Currency and Finance
Select Year  
Home >> Publications >> Reports - View
   
Note : To obtain an aligned printout please download the 722 kb version to your machine and then use respective software to print the story.
Date: 16 Jan 2013
Report of the Technical Committee to Examine Uniform Routing Code and Account Number Structure

Contents

Chapter

Particulars

  Letter of Transmittal
  Memorandum
  Executive Summary

I

Constitution of the Technical Committee and Methodology

II

Routing Codes and Account Number Structures – A Perspective

III

Need for branch identifier in IFSC – A Review

IV

Harmonisation of Routing Codes

V

Uniform Account Numbers and IBAN

VI

IBAN Structure for India

Annex I - V


Letter of Transmittal

December 31, 2012

Shri H.R. Khan
Deputy Governor
Reserve Bank of India
Department of Payment and Settlement Systems
Mumbai, India

Dear Sir,

Technical Committee to examine Uniform Routing
Code and Account Number Structure

I have immense pleasure in submitting the Report of the Technical Committee constituted vide Memorandum dated August 10, 2012 to examine Uniform Routing Code and Account Number Structure in the country. The Report debates the feasibility of doing away with the existing Indian Financial Structure Code (IFSC) structure in the RTGS/NEFT systems and the way forward for introduction of a common routing code and the International Bank Account Number (IBAN) across payment systems for increasing efficiencies. Its recommendations are summed up in the Executive Summary.

I would like to place on record my sincere thanks to all members for their contribution and to Shri S. Ganesh Kumar, CGM, DGBA and Shri Subhash Chand, AGM, DPSS CO for providing expert advice and necessary support in finalising the report.

On behalf of the members of the Technical Committee, I sincerely thank you for entrusting this responsibility to us.

I1

I2

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:

SNo.

Name of Official

Institution

1.

Shri Vijay Chugh, Chairman

Reserve Bank of India

2.

Dr. Anil Kumar Sharma

Reserve Bank of India

3.

Shri Ajaya Ray

Reserve Bank of India

4.

Smt. Sujata Lal

Reserve Bank of India

5.

Smt. Scenta Joy

Reserve Bank of India

6.

Shri N. Senthil Kumar

Reserve Bank of India

7.

Dr. M.V.N.K. Prasad

IDRBT

8.

Dr. A.M. Pedgaonkar

Indian Banks’ Association

9.

Shri N. Jambhunathan

State Bank of India

10.

Shri D. Sahoo

Punjab National Bank

11.

Shri Sharad Bishnoi

HDFC Bank

12.

Shri Subhakanta Satpathy

Axis Bank

13.

Shri Sunil S. Shetty

Abhyudaya Cooperative Bank

14.

Shri N.C. Nataraja

Canara Bank

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:

000

000

000

     

City Code

Bank Code

Branch Code

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:

RBIS

0

AHPA01

(Bank Identifier)

zero

(Branch identifier)

 

(retained zero for future use)

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.

DESCRIPTION

EXAMPLE

POSITION

Country Code

IN

Char (1-2)

Check Digit

68

Numeric (3-4)

Bank Id

0027

Char (5-8)

Account Sequence Number

4324 5672 4672 1968 72

Numeric (9-26)

IN68 0027 4324 5672 4672 1968 72

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).

DESCRIPTION

EXAMPLE

POSITION

Country Code

IN

Char (1-2)

Check Digit

68

Numeric (3-4)

Bank Id

0027

Char (5-8)

Account Sequence Number

4324 5672 46

Numeric (9-19)

IN68 0027 4324 5672 46

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:

DESCRIPTION

EXAMPLE

POSITION

Country Code

IN

Char (1-2)

Check Digit

68

Numeric (3-4)

Bank Id

0027

Char (5-8)

UID

4324 5672 4658

Numeric (9-20)

Account Type

01

Numeric (21-22)

Account Number

01

Numeric (23-24)

IN68 0027 4324 5672 4658 0101

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.

DESCRIPTION

EXAMPLE

POSITION

Country Code

IN

Char (1-2)

Check Digit

68

Numeric (3-4)

Bank Id

0027

Char (5-8)

Product code

0010

Numeric (9-12)

Account Serial Number

4324 5672 46

Numeric (13-22)

IN68 0027 0010 4324 5672 46

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

Sr. No.

Bank

Feedback / Comments / Observation

 

Allahabad Bank

Branch id required

Unique account: Not known

Currently, the credits received through RTGS interbank mode is being processed to the respective GL head based upon last four digit branch identifier in beneficiary IFSC Code. Thus the STP of inward RTGS interbank transactions may get affected if IFSC Code is made uniform across the bank.

Further, the bank acts as a sponsor bank for two RRBs viz. Allahabad Gramin Bank and Sharda Gramin Bank for which different IFSC codes are being allotted. However, since there is only one IFSC permitted between IDRBT and the bank, the messages for our bank and two sponsored RRBs are routed through common IFSC of SFMS gateway and thus differentiating and routing of RRB’s and the bank’s RTGS / NEFT messages to the respective core banking system may get affected at SFMS gateway level. Further, the routing of inward and outward LC / BG messages to / from SFMS to the concerned branch also has to be looked into.

However, it would be feasible to process inward and outward RTGS / NEFT messages in seamless and STP manner under proposed mode, if the above mentioned issues are addressed.

 

Bank of Maharashtra

Branch id required

Unique : OK

In case of NEFT and RTGS transactions, bank can process both inward and outward transactions without branch identifier in IFSC Code in a seamless and STP manner. However, we would like to bring the following points to notice:

(a) Inter-bank RTGS messages (R-42 messages) are IFSC dependent. As there is no account number in these messages, they are parked in the concerned branch's RTGS suspense account. The branch code is identified based on the IFSC code for R42 message. Thus, IFSC code with branch identifier is very much needed in case of inter-bank RTGS messages (R-42 messages).

(b) In case of outward cash NEFT messages, if there is return of NEFT cash messages by the receiving bank due to any reason, the amount is parked in NEFT suspense account. The present logic for identifying the original branch (which first sent the message) is dependent on the IFSC code of the return message. Hence, in case of outward cash NEFT messages also, IFSC code with branch identifier is very much needed.

 

Canara Bank

Branch id required

Unique : OK

With reference to your above email we wish to inform that technically it is feasible to process both inward and outward transactions related to NEFT, RTGS, SFMS, etc., without branch identifier in IFS Code in a seamless and STP manner.

However we wish to inform that the present application architecture for the NEFT, RTGS and SFMS in the bank is as follows:

  1. The sender should provide the IFSC and account number in CBS 13 digit format (mandatory fields) for credit to beneficiary account.

  2. If the 13 digit account number provided is available in CBS the amount gets credited to customer account through STP. For the purpose of credit to the customer account unique 13 digit account number is used.

  3. However if due to some reasons the credit to customer account fails even though the 13 digit account number is correct (memo field like KYC warning etc.) the customer account may not be credited but will be credited to Branch General Ledger account of the respective branch and branch is identified by the branch identifier in IFSC code.

  4. For RTGS remittance if the account number is not in 13 digit CBS format (as customer has given the account number in old format etc.) the amount will be credited to the Branch General Ledger account identified by the branch identifier in IFSC. Branch will decide either to accept or reject the remittance within the RTGS time norms.

Hence with the introduction of Uniform routing code there need be operational level changes (from decentralised to centralised accounting) and customization in Core Banking module is required to support the above changes.

 

Indian Bank
Unique : OK

The bank is technically capable of processing both inward and outward transactions without branch identifier in IFSC code

 

Oriental Bank of Commerce

Unique OK
Branch id required

  1. In case of Inward remittances viz. NEFT, RTGS – R41, the bank can process the same as IFSC code is used as bank identifier and does not require branch identifier. However in case of inward remittances through RTGS – R42 (inter-bank remittances), branch identifier is required in IFSC code for giving credit in STP mode.

  2. In case of outward remittances viz. NEFT, RTGS, in our bank IFSC is mandatory to identify the destination bank and branch to process the same.

 

Punjab and Sind Bank
Branch id required

Unique : not known

It requires major changes in Core Banking software. Detailed guidelines / format shall be helpful to deliberate and give feedback

 

Punjab National Bank

Branch id required

Unique : OK

IFSC code contains initial 5 characters relating to the bank and the remaining 6 characters relating to branch identifier. However, all our accounts have a branch identifier. Even in the absence of branch identifier in IFSC code with the availability of account number the transactions can be passed in a seamless and STP manner. It is worth mentioning that in case of Inter Bank transactions generally account number of the beneficiary is not mentioned which causes delay in crediting the remittance in STP manner. If account number of the beneficiary is made mandatory this challenge can be obviated.

 

Syndicate Bank
Branch id required

Not Known

As of now, there is a dependency on valid Branch IFSC code in some of the processes in our systems, including accounting entries. Hence, if we have to move to using IFSC code without branch identifier in a seamless and STP manner, it will need changes in our systems.

 

UCO Bank
Unique : OK

Banks can process both inward and outward messages related NEFT, RTGS, SFMS, etc. without identifier in the IFSC code in a seamless and STP manner.

However presently under systems (Finacle) we have a process to verify the Branch identifier in the IFSC System integrator to provide a solution on the lines above.

The outward message for some reasons is returned, the message so received is processed based on the branch identifier in the IFSC in our current process. However if the branch identifier is eliminated, the banks can process the same on the lines of inward messages.

 

Union Bank of India
Unique : OK

IFSC is basically a bank branch identifier, while account number is identifier for specific account of a customer. In the pre-CBS era, both IFSC and account number were needed for making STP of Inward RTGS / NEFT transactions. Similarly the same are mandated in outward transactions also, as that will facilitate STP at the beneficiary bank end. However, while introducing CBS many banks have adopted different account numbering patterns, whereby the branch, type of account and account identity also could be found from account number itself. However, as has been rightly mentioned in your communication, no uniform method is followed across the banks in defining the account numbering pattern. Hence, it cannot be surely said whether the account number alone will suffice STP without IFSC.

In our bank, we can identify the branch, account type and account identity from the account number. Thus, we can do STP of inward RTGS and NEFT without IFSC.

 

United Bank of India

Software change needed

Unique : OK

1. We can process inward and outward transactions related to RTGS and NEFT without branch identifier in IFSC Code in a seamless and STP manner. But for this certain customization in CBS and change in business process will be required. Such changes will take 2-3 months to implement, once it is decided to implement the same and the related guidelines are received.

2. RBI has allowed connectivity to Centralized Payment System through sub-membership route. Sub-members are given IFSC having bank code (i.e. first four characters) identical with the bank code of sponsoring bank. Removing branch identifier from IFSC of sub-members will make it very difficult for distinguishing from member bank branches, because account number may not be unique across member bank and sub-members. So it is required to continue with the present structure of IFSC with the last six characters identifying the sub-member and not the branch.

3. It will be very difficult to process non-financial message (e.g. LC and LG) without branch identifier in IFSC. We need to have detailed guidelines on how to handle such messages in the changed scenario.

 

State Bank of Mysore

Not OK for RTGS
Unique : OK

  1. The bank’s Core Banking Solution can process NEFT transactions without branch identifier in IFSC Code in a seamless and STP manner

  2. With regard to processing of RTGS transactions, system validates IFSC codes and hence processing of RTGS transactions without branch identifier is not possible

  3. IFSC code validations are built in for SFMS transactions also.

 

State Bank of Travancore

Unique : OK

Our payment systems, namely, NEFT and RTGS are capable of handling inward and outward transactions without branch identifier in IFSC Code in a seamless and STP manner. In our Bank, credit to the beneficiary account is done based on account number field in line with RBI directive.

However, as far as SFMS is concerned, the branch identifier in IFSC is essential, both for outward and inward (both for LCs and BGs), so that the message reaches the branch to which it pertains.

Private Sector Banks

Sr. No.

Bank

Feedback / Comments / Observation

 

Axis Bank

Unique : OK

Uniform Routing Codes:

MICR:

MICR band requires a change in CTS scenario.

The available length in MICR band is 64 characters out of which 40 characters are currently used.

We should add the 16 to 20 digits account number on the MICR Band.

ACH and ECS can work on new MICR code.

IFSC:

A single generic IFSC code may me introduced to facilitate customer NEFT/RTGS. Customer need not be asked to quote the IFSC code but only the name of the bank. Banks' systems of origin for teller or customer should show drop down list of the name of the bank only and assign the generic IFSC code to facilitate the remittance.

All banks in CBS already have unique customer account numbers. And IFSC code for the branch may not be needed.

IFSC code for bank/branch combination may continue and will serve trade finance related messages and inter bank remittances.

IBAN:

The simplest way of introducing the IBAN is as under:

Introduce the Country, Bank and Check Digit.

This should be padded to the existing customer account numbers to represent the IBAN.

Each bank may modify their IT systems by introducing a layer above the existing account numbers and handle the conversion from existing account to IBAN by customisation.

Each bank should be asked to restrict their customer account number to a certain maximum to have the standard.

Views of The Lakshmi Vilas Bank Ltd.

Sr. No.

Query

LVB’s views/reply

 

What is the present set up we have in LVB- to process both inward and outward transactions related to

  1. NEFT
  2. RTGS
  3. SFMS
  4. Any other txns

Unique : OK

NEFT INWARD TRANSACTIONS: All NEFT inward transactions from RBI will be received based on IFSC code through SFMS, SFMS will send the same to CBS. In CBS, inward transactions will be processed based on account number, but as of now system will identify branch code based on IFSC code only.

NEFT OUTWARD TRANSACTIONS:
All outward transactions are sent to beneficiary bank based on IFSC code only.

RTGS CUSTOMER INWARD TRANSACTIONS:
All inward customer receipts will be accounted based on account number only.

RTGS BANK INWARD TRANSACTIONS: By default all inward Receipts, including Inter Bank transactions will to credited to respective branch GL’s ,which will be identified based on IFSC code mentioned by Remitter .

RTGS OUTWARD CUSTOMER AND BANK TRANSACTIONS:
All outward transactions are sent to beneficiary bank based on IFSC code only

Trade Finance related messages like LC’s and BG’s received through SFMS Beneficiary branch will be identified based on IFSC code only.

2

Whether the bank can process both inward and outward transactions related to NEFT, RTGS, SFMS, etc., without branch identifier in IFSC Code in a seamless and STP manner?

NO. For both inward and outward transactions IFSC code is mandatory. Since all the banks are under CBS and as customer’s account number is unique across bank, we can make suitable changes in the work flow with the help of CBS vendor, to identify the relevant account, without the help of IFSC code. However the possibility of making such customisation in the CBS application has to be discussed with the application vendor.

In SFMS messages, especially in trade finance messages (both in IFN 400 AND IFN 700 SERIES), CBS account number is seldom referred. At present the identifier is the IFSC code only. With the help of the name of the beneficiary/applicant in the message, branch identifies the customer.

3

The number of digits in the present LVB account Number and identifiers

There is total 16 digits in account number. First four digits identifies Branch code. Next Three digits identifies Product Code, next eight digits sequence number and last digit check digit.

Foreign Banks

Sr. No.

Bank

Feedback / Comments / Observation

 

The Royal Bank of Scotland N V

The bank do not expect an impact on processing both inward and outward transactions related to NEFT, RTGS, SFMS, etc., without branch identifier in IFSC Code in a seamless and STP manner.

Should you require any further details please contact us at the below mentioned coordinates.

 

Standard Chartered Bank

The bank can process both inward and outward transactions related to NEFT, RTGS, SFMS, etc., without branch identifier in IFSC Code in a seamless and STP manner

Co-operative Banks

Sr. No.

Bank

Feedback / Comments / Observation

 

The Kalyan Janata Sahakari Bank Ltd.

Presently around 40% of the messages are being received without CBS account numbers, if this percentage comes to nil it is possible to post the NEFT messages without branch identifier. But for RTGS we need to go with branch identifier as amount involved is substantial.


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:

No

Bank

Total
Length

Branch

Prod

Ext
Count

Ac No

1

Catholic Syrian Bank

18

4(n)

6(n)

0

8(n)

2

Nagpur Nagrik Sahakari Bank Limited

15

3(n)

4(n)

0

8(n)

3

Dena Bank

16

4n

2n

0

12(n)

4

Andhra Bank

15

4 (n)

2 (n)

0

8 (n)

5

Almora Urban Co-operative Bank Ltd

15

3(n)

4(n)

0

8(n)

6

Bank of India

15

4(n)

4(n)

0

7(n)

7

The Bharat Co-operative Bank (Mumbai) Ltd

15

3(n)

4(n)

0(n)

8(n)

8

United Bank of India

13

4(n)

2(n)

0

6(n)

9

Bank of Maharashtra

11

0

0

0

10(n)

10

The Federal Bank Ltd.

14

4(n)

2(n)

0

7(n)

11

The Cosmos Co-Op Bank Ltd

16

3(n)

5(n) to 6(n)

NIL ( already covered under br code)

2(n) to 8(n)

12

South Indian Bank

16

4(n)

3(n)

0

9(n)

13

Bank of Baroda

14

4(N)

2(n)

0

8(N)_

15

ANZ Bank

14

0

5(n)

0

14(x)

16

Corporation Bank

15

4(n)

3(n)

2(n)

6(n)

17

Indian Bank

17

0

0

0

16(n)

18

Jalgaon Janata Sahakari Bank Ltd. Jalgaon

11

2(n)

3(n)

0

6(n)

19

Punjab National Bank

16

4(n)

2(x)

2(n)

7(n)

20

Credit Agricole Corporate And Investment Bank

14

2(n)

3(n)

0

6(n)

21

HSBC

12

3(n)

3(n)

0

5(n)

22

IOB

15

4n

2n

0

9n

23

Capital Local Area Bank Ltd.

12

3(n)

3(n)

0

6(n)

24

UCO Bank

14

4(n)

2(n)

0

8(n)

25

Rajkot Nagarik Sahakari Bank Ltd.

14

2(n)

4(n)

0

8(n)

26

NKGSB Co-op Bank Ltd.

15

3(n)

2(n)

2(n)

8(n)

27

Lakshmi Vilas Bank

16

4(n)

3(n)

No

8(n)

28

Tamilnad Mercantile Bank Ltd

15

3(n)

5(n)

1(n)

6(n)

29

State Bank of Hyd

11n

5n

0

0

11n

30

The Shamrao Vithal Co-operative Bank Ltd

15

3(n)

4(n)

0

7(n)

31

Kotak Mahindra Bank

10

0

0

0

10(n)

32

The Ahmedabad Mercantile Bank Ltd.

15

3(n)

3(n)

3(x)

0

33

Union Bank of India

15

5(n)

3(n)

0

7(n)

34

Karur Vysya Bank

16

4

3

NA

9

35

Allahabad Bank

11

0

0

0

10(n)

36

ING Vyasya Bank

12

4(n)

2(n)

0

1000-10-123456

37

Yes Bank

15

4(n)

3(n)

0

7(n)

38

Credit Suisse AG

13

NA

NA

NA

7

39

The Karad Urban Co-Op Bank Ltd. Karad

13

4(n)

3(n)

0

6(n)

40

Dhanlaxmi Bank Ltd

15

4(n)

3(n)

0

07(n)

41

Mehsana Urban Co-op Bank Ltd.

14

4(n)

4(n)

0

6(n)

42

Apna Sahakari Bank Ltd

12

2

0

0

10(n)

43

Karur Vysya Bank

16

4

3

NA

9

44

Karnataka Bank

16

3(n)

5(n)

0

6(n)

45

Mizuho Corporate bank, Ltd.

12

3(n)

3(x)

0

6(n)

46

Punjab & Sind Bank

14

4

2

 

8

47

Kallappanna Awade Ichalkaranji Janata Sah Bank Ltd

16

0

8(x)

0

8(n)

48

The Saraswat Co-operative Bank Ltd.

15

3(n)

4(n)

0

8(n)

49

Societe Generale

15

0

2(n)

0

6(n)

50

ICICI Bank Ltd.

12

4(n)

2(n)

0

6(n)

51

Axis Bank (NEW A/c Number)

15

1(n)

2(n)

2(n)

9(n)

52

Development Credit Bank

16

3(n)

3(n)

3(n)

14(n)

53

Bank of America N.A.,

12

4

0

0

8

54

Dombivli Nagari Sahakari Bank Ltd.

15

3(n)

4(n)

0

8(n)

55

The West Bengal State Co operative Bank

16

5

8

NA

17

56

Malda DCCB

16

5

8

NA

17

57

Tamluk Ghatal CCB

16

5

8

NA

17

58

Darjeeling DCCB

16

5

8

NA

17

59

Jalpaiguri DCCB

16

5

8

NA

17

60

Raiganj DCCB

16

5

8

NA

17

61

Dakhin Dinajpur DCCB

16

5

8

NA

17

62

Murshidabad DCCB

16

5

8

NA

17

63

Nadia DCCB

16

5

8

NA

17

64

Howrah DCCB

16

5

8

NA

17

65

Mugberia CCB

16

5

8

NA

17

66

Vidyasagar CCB

16

5

8

NA

17

67

Bankura DCCB

16

5

8

NA

17

68

Purulia DCCB

16

5

8

NA

17

69

Barclays Bank PLC

12

0

0

0

12(n)

70

The Tamilnadu State Apex Co-op Bank

9

0

0

0

8(n)

71

TJ Sahakari Bank Ltd.

15

3(n)

4(n)

0(n)

8(n)

72

UBS AG

10

0

0

0

10(n)

73

Canara Bank

13

4(x)

3(n)

0

6(n)

74

Pragathi Gramin Bank

14

2(n)

3(n)

2(n)

6(n)

75

Shreyas Gramin Bank

14

2(n)

3(n)

2(n)

6(n)

76

South Malabar Gramin Bank

14

2(n)

3(n)

2(n)

6(n)

77

Central Bank of India

10

0

0

0

09(n)

78

The Bank of Tokyo-Mitsubishi UFJ Ltd.

17

4(n) Unique for each branch

0

0

13(n)

**40 out of 78 banks do not have check digit as part of the account number

Annex IV

Response from Banks on IBAN

Public Sector Banks

Sr. No.

Bank

Suggestion / Remarks

 

Andhra Bank

The bank is using Finacle solution (version 7.x) provided by M/s. Infosys. Currently IBAN is not supported in Finacle 7.x version. We understand that Finacle 10.x version supports the same but presently the same is being used only by Axis Bank in India.

But after studying the requirements and preliminary discussions with our System Integrator, we understand that a workaround solution is feasible through suitable customization in existing version of Finacle in use in our Bank.

However we feel that only a small percentage of customers (Exporters / Importers / NRIs etc.,) would require this facility. We will explore the customization route, as and when the same is implemented.

 

Bank of Baroda

We are of the opinion that without changing the existing account number pattern prevailing in different banks, IBAN can be introduced as under.

  1. First two letters - Country Code i.e. IN (INDIA)

  2. Third and fourth character - Check digit

  3. Fifth to seventh character - three digit Bank Code (use of existing MICR code)

Rest digits will be formed by suffixing sufficient 0’s to the existing account number thus making the total length of IBAN as 34.

Present pattern of generating account number will continue along with generation of IBAN based on the above mentioned logic with mapping being maintained between these two numbers. IBAN will be generated for existing account number also and the same maintained in the system.

Domestic payment system can continue to use existing account number only, to avoid any changes in ECS, clearing where old number exists.

IBAN can be used for international financial messages for customer convenience (only IBAN is sufficient for remittance) and building STP, especially for interbank payment, will be easy. Single IFSC code per bank will further facilitate STP.

IBAN will be populated in the pass-book / statements etc. of the customers. In all the inward / outward remittance message, IBAN is to be populated by the system for cross country transactions.

As it requires major change in our core system, we may have to rope in our technology vendor for providing solution. If existing account number exists in IBAN, implementation may not cause major changes in the system. Banks may have build STP to take full advantage of IBAN.

 

Central Bank of India

In this context, we have to inform you that the above facility is not available in our CBS system at present. Since functionality is complex, the implementation of this facility will take some time.

 

Oriental Bank of Commerce

 

The bank is using Finacle ver. 7.0.19 for Core Banking operations. The bank has implemented the concept of 14 digits account number for an Account holder. The first 4 digits of account number refer to Sol id, next 3 digit reflects scheme code and the remaining digits are incremental numbers with inbuilt check digits. Accordingly, complete CBS system including validations, customizations, reports etc. have been developed using 14 digits account. In case of any change in the structure of account number would have major impact on the CBS operations. We are of the view that complete technical feasibility of shifting to new structure or format is required to be done before finalizing the approach to migration complete CBS data to new system.

 

Punjab Sind Bank

Adopting of International Bank Account Number will definitely reduce the problems faced by the customers as the amount will credited on the basis of IBAN through STP mode.

However, adoption of ISO 20022 Standard in CBS, is a big challenge for banks in India and shall involve considerable implementation cost.

 

State Bank of India

  1. The proposal for use of IBAN in the lines of the system prevailing in European Union / Middle East / US countries to identify and regulate the cross border payments and receipts across all the banking channels of the country can be made feasible for implementation in our Bank. First of all, a country specific uniform policy regarding the structure and nomenclature of the proposed IBAN number should be formulated, as the very purpose of putting in place a IBAN is to obviate the possibility of data transcription errors.

  2. We have examined the technical feasibility part of the requirement. The structure of account number presently in use at our bank and the logistics thereof is as under Consist of 11 digit numerical characters. Can be extended up to 17 digit (inclusive of the check digits) It is possible to have the composition of the number as alpha numeric Presently, the account number is non-intelligent, sequentially system generated unique account number for each State Bank Group.
    Inward remittances and other credits to the account are validated presently against any posting restrictions, status of the account etc., before the beneficiary account is credited based on the unique account number alone.

  3. As already pointed out, formulation of a unique, uniform and specific country wide policy for implementation of IBAN number will enable us to have a closer look at the whole issue to determine the development involved towards implementation of the evolving IBAN policy. We may add that, it will call for changes in all banking remittances / settlement related products/services as well.

 

UCO Bank

M/s. Infosys Technologies Limited, the original software developer has informed that this feature is available only with finacle 10.x version whereas currently bank is using Finacle 7.0.x version.

As per bank technology roadmap, bank intends to upgrade to Finacle 10.x. Therefore with the implementation of Finacle 10.x bank will comply to the requirement of IBAN

 

State Bank of Bikaner & Jaipur

The bank is using BIC code plus account number for account identification. But the BIC code has been allotted to 'B’ category branches only. For other branches, we deal through BIC enabled branches. We are consulting with our IT Department to explore the possibility of using IBAN.

 

State Bank of Patiala

As a part of State Bank Group, we share a common technology platform with SBI. Accordingly a group approach will be taken in this regard.

Private Sector Banks

Sr. No.

Bank

Suggestions / Remarks

 

Axis Bank

Our initial views on the use of International Bank Account Number (IBAN) are as follows:

(a) At present our Core Banking System (Finacle) supports maximum account number length of 16 characters. This can be alphanumeric. Any IBAN logic that will enable unique number to accounts can be supported within this.

(b) However, account number in our core banking comprises of several components including module codes for type of accounts viz. SB/TD/CC/OD/ etc., and any change in these components shall seriously impact our CBS.

(c) For a complete change in account number structure, there would be a big challenge in change management, as under:

(i) Informing customers and make them accept the change,

(ii) Handling internal surround systems with which the core banking system interacts, and

(iii) Handling and supporting external systems like RTGS, NEFT, SWIFT, MICR etc.

(d) There can be some legal issues especially the contracts where account numbers are specifically mentioned.

(e) Dealing with account related inventory - like Cheque books etc.

(f) Dealing in payment mandates like ECS etc.

 

ICICI Bank Limited

While ICICI Bank has successfully implemented the IBAN solution for some of its foreign offices through customisation, we believe that doing it for India would need lot of effort. There would be changes in the surrounding support systems also. At this point in time it is difficult to assess the impact and the work involved in IBAN implementation.

The functionality would be supported in the Base Product with our new CBS implementation of Ver 10.x of Finacle Core Banking solution to which we are yet to migrate.

Foreign Banks

Sr. No.

Bank

Suggestions / Remarks

 

Bank of America

We would like to inform you that Bank of America N.A, in certain overseas regions, supports IBAN account format and has full payment processing support. While there is limited support available currently in the India core-banking system, (due to this format not in use in the local market), we can definitely evaluate the level of support and timeline required to extend this for India, based on additional details on the requirements, specification and formats for the proposed IBAN usage in India. We shall be grateful if you could provide us the same so that we can evaluate and let you know

 

Barclays Bank PLC

  1. At Barclays account number format is 12 digit and cannot be ascertained with reference to branch or any product

  2. Since this may result in changes to the structure of the account number - alpha numeric and length, its essential we need to evaluate the changes which need to be done to our application to accommodate incoming payments, validate the account. Similar exercise needs to be done for outward payments as well.

  3. There could be a requirement of having additional tables with bank + branch details for self and other banks based on which validations can be done and our account numbers can be automatically appended with prefixing content to complete the IBAN number - for outward payments

  4. We will also have to do gap analysis / potential changes required in consultation with OFSS & IT based on our current status, pots the guidance from RBI / IBA on the subject.

 

Deutsche Bank

As a bank we are not yet in a position to implement IBAN on inward remittances. However, we do make outward payments for our customers basis IBAN that they specify typically for countries like UAE and UK.

The change to an IBAN kind of structure will require a detailed analysis and clarity on how will it work both in the domestic and the international context.

Some observations on our retail banking platform: It runs on CBS and we have unique 15-digit numeric bank account numbers for our customers. We believe that if this is prefixed by a two digit country code (IN) and a four digit bank identifier (similar to what is being done in case of MMID), we can achieve a structure compliant IBAN - this will not only allow us to transfer money within the country without IFSC but also allow seamless international transfers.


Annex V

IBAN format in Other Countries

Country

Chars

BBAN Format

IBAN Fields

Comment

Albania

28

8n, 16c

ALkk bbbs sssx cccc cccc cccc cccc

b = National bank code
s = Branch code
x = National check digit
c = Account number

Andorra

24

8n,12c

ADkk bbbb ssss cccc cccc cccc

b = National bank code
s = Branch code
c = Account number

Austria

20

16n

ATkk bbbb bccc cccc cccc

b = National bank code
c = Account number

Azerbaijan

28

4c,20n

AZkk bbbb cccc cccc cccc cccc cccc

b = National bank code
c = Account number

Belgium

16

12n

BEkk bbbc cccc ccxx

b = National bank code
c = Account number
x = National check digits

Bahrain

22

4a,14c

BHkk bbbb cccc cccc cccc cc

b = National bank code
c = Account number

Bosnia and Herzegovina

20

16n

BAkk bbbs sscc cccc ccxx

k = IBAN check digits (always 39)
b = National bank code
s = Branch code
c = Account number
x = National check digits

Bulgaria

22

4a,6n,8c

BGkk bbbb ssss ddcc cccc cc

b = BIC bank code
s = Branch (BAE) number
d = Account type
c = Account number

Costa Rica

21

17n

CRkk bbbc cccc cccc cccc c

b = bank code
c = Account number

Croatia

21

17n

HRkk bbbb bbbc cccc cccc c

b = Bank code
c = Account number

Cyprus

28

8n,16c

CYkk bbbs ssss cccc cccc cccc cccc

b = National bank code
s = Branch code
c = Account number

Czech Republic

24

20n

CZkk bbbb ssss sscc cccc cccc

b = National bank code
s = Branch code
c = Account number

Denmark

18

14n

DKkk bbbb cccc cccc cc

b = National bank code
c = Account number

Dominican Republic

28

4a,20n

DOkk bbbb cccc cccc cccc cccc cccc

b = Bank identifier
c = Account number

Estonia

20

16n

EEkk bbss cccc cccc cccx

b = National bank code
s = Branch code
c = Account number
x = National check digit

Faroe Islands

18

14n

FOkk bbbb cccc cccc cx

b = National bank code
c = Account number
x = National check digit

Finland

18

14n

FIkk bbbb bbcc cccc cx

b = Bank and branch code
c = Account number
x = National check digit

France

27

10n,11c,2n

FRkk bbbb bggg ggcc cccc cccc ckk

b = National bank code
g = Branch code (fr:code guichet)
c = Account number
x = National check digits (fr:clé RIB).

Georgia

22

2c,16n

GEkk bbcc cccc cccc cccc cc

b = National bank code
c = Account number

Germany

22

18n

DEkk bbbb bbbb cccc cccc cc

b = Bank and branch identifier (de:Bankleitzahl or BLZ)
c = Account number

Gibraltar

23

4a,15c

GIkk bbbb cccc cccc cccc ccc

b = BIC bank code
c = Account number

Greece

27

7n,16c

GRkk bbbs sssc cccc cccc cccc ccc

b = National bank code
s = Branch code
c = Account number

Greenland

18

14n

GLkk bbbb cccc cccc cc

b = National bank code
c = Account number

Guatemala

28

4c,20c

GTkk bbbb cccc cccc cccc cccc cccc

b = National bank code
c = Account number
Effective 1 July 2014

Hungary

28

24n

HUkk bbbs sssk cccc cccc cccc cccx

b = National bank code
s = Branch code
c = Account number
x = National check digit

Iceland

26

22n

ISkk bbbb sscc cccc iiii iiii ii

b = National bank code
s = Branch code
c = Account number
i = holder's kennitala (national identification number).

Ireland

22

4c,14n

IEkk aaaa bbbb bbcc cccc cc

a = BIC bank code
b = Bank/branch code (sort code)
c = Account number

Israel

23

19n

ILkk bbbn nncc cccc cccc ccc

b = National bank code
n = Branch number
c = Account number 13 digits (padded with zeros).

Italy

27

1a,10n,12c

ITkk xaaa aabb bbbc cccc cccc ccc

x = Check char (CIN)
a = National bank code (it:Associazione bancaria italiana or Codice ABI )
b = Branch code (it:Coordinate bancarie or CAB - Codice d'Avviamento Bancario)
c = Account number

Kazakhstan

20

3n,13c

KZkk bbbc cccc cccc cccc

b = National bank code
c = Account number

Kuwait

30

4a, 22c

KWkk bbbb aaaa aaaa aaaa aaaa aaaa aa

b = National bank code
a = Account number.

Latvia

21

4a,13c

LVkk bbbb cccc cccc cccc c

b = BIC Bank code
c = Account number

Lebanon

28

4n,20c

LBkk bbbb aaaa aaaa aaaa aaaa aaaa

b = National bank code
a = Account number

Liechtenstein

21

5n,12c

LIkk bbbb bccc cccc cccc c

b = National bank code
c = Account number

Lithuania

20

16n

LTkk bbbb bccc cccc cccc

b = National bank code
c = Account number

Luxembourg

20

3n,13c

LUkk bbbc cccc cccc cccc

b = National bank code
c = Account number

Macedonia

19

3n,10c,2n

MKkk bbbc cccc cccc cxx

k = IBAN check digits (always = '07')
b = National bank code
c = Account number
x = National check digits

Malta

31

4a,5n,18c

MTkk bbbb ssss sccc cccc cccc cccc ccc

b = BIC bank code
s = Branch code
c = Account number

Mauritania

27

23n

MRkk bbbb bsss sscc cccc cccc cxx

b = National bank code
s = Branch code (fr:code guichet)
c = Account number
x = National check digits (fr:clé RIB)
Planned effective date 1 January 2012.

Mauritius

30

4a,19n,3a

MUkk bbbb bbss cccc cccc cccc cccc cc

b = National bank code
s = Branch identifier
c = Account number

Monaco

27

10n,11c,2n

MCkk bbbb bsss sscc cccc cccc cxx

b = National bank code
s = Branch code (fr:code guichet)
c = Account number
x = National check digits (fr:clé RIB).

Moldova

24

2c,18n

MDkk bbcc cccc cccc cccc cccc

b = National bank code
c = Account number

Montenegro

22

18n

MEkk bbbc cccc cccc cccc xx

k = IBAN check digits (always = '25')
b = Bank code
c = Account number
x = National check digits

Netherlands

18

4a,10n

NLkk bbbb cccc cccc cc

b = BIC Bank code
c = Account number

Norway

15

11n

NOkk bbbb cccc ccx

b = National bank code
c = Account number
x = Modulo-11 national check digit

Pakistan

24

4c,16n

PKkk bbbb cccc cccc cccc cccc

b = National bank code
c = Account number
Effective 31 December 2012

Palestinian Territory, Occupied

29

4c,21n

PSkk bbbb xxxx xxxx xccc cccc cccc c

b = National bank code
c = Account number
x = Not specified

Poland

28

24n

PLkk bbbs sssx cccc cccc cccc cccc

b = National bank code
s = Branch code
x = National check digit
c = Account number,

Portugal

25

21n

PTkk bbbb ssss cccc cccc cccx x

k = IBAN check digits (always = '50')
b = National bank code
s = Branch code
C = Account number
x = National check digit

Romania

24

4a,16c

ROkk bbbb cccc cccc cccc cccc

b = BIC Bank code
c = Branch code and account number (bank-specific format)

San Marino

27

1a,10n,12c

SMkk xaaa aabb bbbc cccc cccc ccc

x = Check char (it:CIN)
a = National bank code (it:Associazione bancaria italiana or Codice ABI)
b = Branch code (it:Coordinate bancarie or CAB - Codice d'Avviamento Bancario)
c = Account number

Saudi Arabia

24

2n,18c

SAkk bbcc cccc cccc cccc cccc

b = National bank code
c = Account number preceded by zeros, if required

Serbia

22

18n

RSkk bbbc cccc cccc cccc xx

b = National bank code
c = Account number
x = Account check digits

Slovakia

24

20n

SKkk bbbb ssss sscc cccc cccc

b = National bank code
s = Branch code
c = Account number

Slovenia

19

15n

SIkk bbss sccc cccc cxx

k = IBAN check digits (always = '56')
b = National bank code
s = Branch code
c = Account number
x = National check digits

Spain

24

20n

ESkk bbbb gggg xxcc cccc cccc

b = National bank code
g = Branch code
x = Check digits
c = Account number

Sweden

24

20n

SEkk bbbc cccc cccc cccc cccx

b = National bank code
c = Account number
x = Check digit

Switzerland

21

5n,12c

CHkk bbbb bccc cccc cccc c

b = National bank code
c = Account number

Tunisia

24

20n

TNkk bbss sccc cccc cccc cccc

b = National bank code
s = Branch code
c = Account number

Turkey

26

5n,17c

TRkk bbbb bxcc cccc cccc cccc cc

b = National bank code
x = Reserved for future use (currently '0')
c = Account number

United Arab Emirates

23

3n,16n

AEkk bbbc cccc cccc cccc ccc

b = National bank code
c = Account number

United Kingdom

22

4a,14n

GBkk bbbb ssss sscc cccc cc

b = BIC bank code
s = Bank and branch code (sort code)
c = Account number

Virgin Islands, British

24

4c,16n

VGkk bbbb cccc cccc cccc cccc

b = National bank code
c = Account number

 
 Top
 
© Reserve Bank of India. All Rights Reserved.
Best viewed in 1024x768 resolution in IE 5 and above.