XML Interface for NEFT Messages

XML Interface for NEFT messages

By: Akanksha Gupta Under the guidance of Shri. G. Raghuraj 6/28/2012

CERTIFICATE

This is to certify that Ms. Akanksha Gupta, pursuing B. Tech course at Indian Institute of Technology, Guwahati with ...... as major subject has undertaken a project as an intern at the Institute for Development and Research in Banking Technology (IDRBT) , Hyderabad from April 30 to June 29, 2012.

She was assigned the project “ Creation of XML Format for NEFT Messages” under the guidance of the SFMS (Structured Financial Messaging System) Department of IDRBT . During the course of the project she has undertaken a study of the payment system.

In this project assigned to Ms. Akanksha Gupta she has done excellent work.

We wish her all the best in all her endeavours.

G. Raghuraj General Manager IDRBT, Hyderabad Project Guide

ACKNOWLEDGEMENT

I would like to express my sincere gratitude to the Institute for Development and Research in Banking Technology (IDRBT) and particularly Shri. G. Raghuraj, General Manager, IDRBT who was my guide in this project. This opportunity of learning all the nuances of a messaging platform and a major payment system application of the country was a boon to me as one rarely gets such exposure. I would not hesitate to add that this short stint in IDRBT has added a different facet to my life as this is a unique organisation being a combination of academics, research, technology, communication services, crucial applications, etc., and at the same time performing roles as an arm of regulation, spread of technology, facilitator for implementing technology in banking and non-banking systems, playing a role of an NGO (without being one) and many more varied activities.

I am extremely grateful to Shri Raghuraj for his advice, innovative suggestions and supervision. I thank him for introducing me to an excellent banking application and giving me the opportunity to approach diverse sections of people starting from bankers to general public.

I am thankful to the staff of SFMS department at IDRBT for helping me to get familiar with the application. They gave me a chance to study the application and its impact from different perspectives. I am thankful to my college, IIT Guwahati for giving me this golden opportunity to work in a high-end research institute like IDRBT. I am thankful for IDRBT for providing such an amazing platform for students to work in real application oriented research. Finally, I thank one and all who made this project successful either directly or indirectly.

I am very thankful to the TCS team with whom I worked throughout my stint at IDRBT and the project was possible only with their cooperation.

Akanksha Gupta Project Trainee Department of SFMS IDRBT, Hyderabad

Index

Seq. No. Topic Page No. 1. SFMS Overview 3 2. NEFT Overview 4 3. Project Objectives 7 4. Why ISO 20022 7 5. Project Deliverables 9 6. Why XML 11 7. Conclusion & Future Scope 13

PROJECT SCOPE:

To develop an interface for data entry for enabling the sender (originator) of an NEFT transaction to create the data (message) in XML format in SFMS instead of the present MT type format.

SFMS Overview :

Structured Financial Messaging System (SFMS) is a secure messaging solution which was deployed over INFINET (communication network) at IDRBT on 14 th December 2001, to facilitate and speed up communication between banks. It serves as the basic platform for inter-bank and also intra-bank applications and fulfils the requirements of domestic financial messaging.

SFMS has a well-defined external Application Programs Interface (API) which are used to send and receive messages using Straight Through Processing (STP) and integrate all existing and future applications with the SFMS. Bank branches on CBS can generate messages in the SFMS format. These messages are sent over INFINET (Indian Financial NETwork – connecting all member banks through communication networks) to IDRBT through MQ middelware. The messages sent/received between SFMS and CBS through the queues are in string format.

Fig 1. SFMS architecture – message flow

SFMS is an Indian messaging middleware similar to SWIFT (Society for Worldwide Interbank Financial Telecommunication) which is the international messaging system used for Financial Messaging globally. It follows SWIFT and ISO 15022 standards and is also capable of moving to new messaging standards.

NEFT Overview :

National Electronic Fund Transfer (NEFT) is an electronic funds transfer system that facilitates individuals, firms and corporates to electronically transfer funds. It uses SFMS format for messaging. This is a simple, secure, safe, fastest and cost effective way to transfer funds, especially for retail remittances. It does not have any restriction of centres or of any geographical area inside the country. NEFT has introduced the concept of centralised accounting system. Every individual’s bank account, that is sending or receiving funds transfer instructions, gets operated at one central location only which is maintained at the Reserve Bank of India, Mumbai. The individual branches participating in NEFT could be located anywhere across the country.

The RBI (NCC) sorts the transactions bank-wise and prepares accounting entries of net debit/credit for posting in the RBI books and passing on the messages to the banks participating in the system. Thus, the bank-wise messages showing the remittance received by banks along with details of the beneficiaries are transmitted to banks.

Sender Functionality:

This functionality constructs the messages meant for Core Banking Interface based on the Receiver bank IFSC Code and Application Identifier in a pre- defined BlockA and Block4 which are part of the message format. The messages are stored in the corresponding Queue of MQ connecting the CBS.

Receiver Functionality:

This functionality continuously polls on the MQ queue connected to the CBS and gets the available messages. It also verifies and validates the messages and updates the same in the SFMS database. After verification and validation of the messages, they are forwarded to the next processing stage or if the validation fails it is returned with by giving the reason for failure. The return messages are sent in a pre-defined message format to the corresponding CBS.

The flow of N06 message in a typical NEFT transaction is as follows:

• Step1: Each settlement participating bank creates 298N06 Message and sends it to the service centre. • Step2: At service Centre, all 298N06 Messages from the branches are consolidated and converted to bank-level 298N06 Messages to form lots of messages which contain 10 transactions in one 298N06 Message. This Message is sent to RBI-NEFT Branch through the IDRBT Hub. • Step3: Once Message reaches at RBI-NEFT centre, it checks for proper settlement batch-time and sends it to RTGS/DAD for accounting purposes.

• Step4: After accounting the RTGS sends confirmation Message to RBI- NEFT. • Step5: On receiving the message, RBI-NEFT system sends 298N02 Message to destination bank’s service centre which gives details of the beneficiary accounts. • Step6: 298N02 Message is consolidated and grouped branch-wise at the destination bank service centre and sent to the respective branches. • Step7: At every batch-end and day end, every bank service centre is sent a 298N04 Message which consists of all details about the hourly settlements of the day.

The receiving banks process the remittance messages and effect the credit to the beneficiaries' accounts.

Fig 2. Types of NEFT messages

Project Working Details

Structured messages containing information about the funds to be transferred are transmitted from the sender bank’s system to receiving bank’s system through IDRBT. Each NEFT message consists of two Blocks: Block A and Block 4. They have certain fields identified by a given ‘field number’ and every field number has a unique meaning. The message creator is required to fill the transaction related information beside the corresponding field number present in Block 4. For e.g. ‘Field 2020’ refers to the message transaction reference number.

Fig 3. NEFT message flow diagram

PROJECT OBJECTIVES :

The present NEFT message format has certain issues like application specific messaging structure, method of standardization is based on ISO 15022 which is getting phased out, interoperability is based on bank’s architecture which is based on pre-core banking status, etc. In order to understand the information exchange, one needs to be familiar with the details of specific syntaxes (field names) used in the NEFT message. This requires a significant investment of time and technology. However, today’s B2B scenarios require more flexibility, especially when dealing with growing demands for process improvement efforts across the entire value chain. This is leading to an increased adoption of multiple XML-based B2B options. Enterprise architects should strive to create a B2B support infrastructure that is designed to take advantage of both old and new technology, as each can provide unique value in meeting the full range of external integration needs. SWIFT was based on the ISO 15022 standards. But SWIFT and some other financial communities have begun migrating to ISO 20022 standards (which is an upgraded version of ISO 15022) which use XML based syntax for messages. It has become the industry standard for syntax in financial messages, as messages formatted to SWIFT standards can be read and processed by many well-known financial processing systems. SWIFT cooperates with international organizations for defining standards for message format and content.

Many firms use ISO 15022 but it doesn’t actually match their needs – they end up having to put lots of the message data into the “free-format text” fields, which means that they cannot be processed automatically. More room for data in the message means more STP. In order to meet the increasing diverse needs of agile organizations of the future, NEFT messages also need to be enabled to accept XML format.

Why ISO 20022?

The ISO 20022 standard provides the financial industry with a common platform for the development of messages in a standardized XML syntax, using:

• A modelling methodology (based on UML) to capture in a syntax independent way financial business areas, business transactions and associated message flows. • A set of XML design rules to convert the messages described in UML into XML schemes.

ISO 20022 has been at the core of discussions in the financial industry for the past few years, as it aims to increase the efficiency and the interoperability of financial institutions, market infrastructures and end users. The industry automation ROI rate depends on how many and how quickly fund players start implementing ISO 20022 as it is costly to maintain multiple standards with clients & service providers.

It is recognized that at this stage, since fund players are leading the market evolution towards wide scale use of ISO 20022, the first-time implementation of this standard may require large-scale efforts from some institutions – especially when they are not yet XML enabled. This initial investment will be however rapidly amortized with ISO 20022 messages’ use extending gradually across instruments and markets (payments, securities, funds) in the coming years. This builds the case for ISO 20022 compared to any other message standard currently used and is the reason why the industry should converge towards it as soon as possible.

This trend towards ISO 20022 is not limited to the financial services industry as XML is recognized as a technology that provides increased productivity of IT resources (thanks to its ease of use and the shorter implementation timeframes), the possibility to use a wide variety of affordable off the shelf products and the capability to support complex information exchanges.

Fig 3. Sectors moving towards ISO 20022

PROJECT DELIVERABLES :

This project was undertaken to provide a solution for improving the flow of NEFT messages by providing XML interface for them. Software has been developed to convert NEFT messages containing information stored in SFMS format into XML format. Some of the languages and applications used for this purpose are JAVA, XML, JDBC, SQL, etc. The coding for the program written to carry out this conversion is in Java.

Presently data from a NEFT message is extracted and stored into an Oracle database. Connection to this database is made with the help of JDBC (Java Database Connectivity). Driver and class used for this purpose are "oracle.jdbc.OracleDriver" and “classes12.jar” respectively. One more table has been created in the database as per the requirement which includes columns named – ‘Type of the message’, ‘NDT table’s column name (Field number description)’, ‘Tag name’, ‘Parent tag name’ and ‘Sequence number’.

The mapping of the field names with XML tags has been done according to the SWIFT standards. For e.g., ‘Field 3535’ which refers to batch time is mapped to according to the SWIFT standards.

The developed software interface takes information from this database and converts it into XML format. For e.g. Field ‘3380-2012/06/22’ is converted to a format like2012/06/22 in XML.

One message can be formed by consolidating one or more than one transaction details. The format of the output XML document will be as follows:

Root tag will have two children:

-Group header

-The second child’s name will change according to the message type.

Group header will be present only once while the second child will be repeated according to the number of transactions. The information common in all the transactions will be present in Group Header and the specific information pertaining to a given transaction will be stored in the second child. The written code will take care of the opening and closing of all the complex tags.

Any realistic solution to text to XML has to be both customisable, to address the specific needs of each organisation, and maintainable, to allow for future changes in the standards. These things have been taken care off in the solution provided.

Fig 4. Conversion done by the software

Why XML?

It's difficult to define XML (eXtensible Markup Language) in one sentence because of its dual function as a scripting language and a file format. It is a technology that has evolved from HTML, which is the language used by Internet web pages. Both HTML and XML are file formats that allow interaction with their user. This interactive feature separates XML from other file formats like X12 and UN/EDIFACT. The main difference is that the existing

structure has a record-field-like layout of data segments and elements, which makes the file shorter, but not easily understandable; while the XML format has tags, which is more easily understood, but making the file bigger and verbose.

The process of upgrading to ISO 20022 standards by SWIFT involved the development of new protocols that facilitate efficient messaging, using existing and new message standards. The adopted technology chosen to develop the protocols was XML, where it now provides a wrapper around all messages legacy or contemporary.

SFMS transactions are very structured and difficult to change. That’s fine for standard business documents, but it won’t suffice for meeting the increasingly diverse needs of agile organizations of the future. This is where a wide range of XML-based transactions will come to bear, supporting flexible transaction exchanges that represent an enhancement to, but not replacement of, the older technology. XML based solutions will provide increasing levels of support for more complex, process-improvement related transactions. The usage of tags is the most defining aspect of XML.

In an XML message, the information is explicitly labelled using standardized tag names. Reference may be made via Internet to a Document Type Definition (DTD) which contains structure declaration and relevant sets of code values. This illustrates the commonality – X12 and XML are both data with tag schemes.

Associated with this is a goal to establish a standard for commercial electronic data interchange that is open and accessible to all, and which delivers a broad spectrum of capabilities suitable to meet the full breadth of business needs. To achieve this requires the use of a methodology that it is not only extensible enough to meet future requirements but also adaptable enough to incorporate new technologies and requirements as they emerge. To ensure broad adoption the technology selected needs to be widely and freely available. The Extensible Markup Language (XML) developed by the World Wide Web Consortium (W3C) provides such a freely available, widely transportable, methodology for well-controlled data interchange.

XML was designed principally for the exchange of information in the form of computer displayable "documents". Not all commercial data is interchanged in a displayable format. In particular data designed for electronic data interchange typically needs to be processed before it can be displayed. For this to be possible the data must be mapped, using some form of template, to a set of processing rules.

These XML guidelines provide a standardized way in which such rules templates can be added to the interchanged data. With existing structure, the infrastructure was built from the ground up, without being able to share resources with other programs. This paradigm is no longer appropriate in today's world of shared software development. By adopting XML, the SFMS community can get to share the cost of extension and future development.

XML allows message type creators to optionally identify which pieces of information should occur in each interchanged set of data and, where relevant, the order in which individual fields should occur in a particular message stream. XML documents can be given metadata fields that can be used to identify who is responsible for creating, transmitting, receiving and processing each message, and can have built-in facilities for identifying the storage points of programs that should be used to control processes. XML can make use of facilities provided by the latest version of the Internet Hyper Text Transfer Protocol (HTTP), which can identify when a message should be moved from one stage of the interchange process to another, and to check that the relevant forms of interchange have taken place.

Conclusion & Future Scope :

The present format is not easily understandable; while the XML format has tags, which are more easily understood. Introduction of XML format will reduce development and implementation cost as the programming languages have already included functionalities to parse XML documents. The structure of the information exchanged must be in a format that is agreed upon by the communicating parties and that is easily manipulated through program. The first requirement necessitates the presence of industry standards, and the second points to the use of XML as the data transport language.

Transactions based on the ISO 20022 standards will increase the reach of NEFT to more customers in more locations with less concern for national boundaries. XML provides an ideal methodology for electronic business as it allows message type creators to clearly identify the role and syntax of each piece of interchanged data using a definition that is both machine process able and human interpretable. - = ^ = -