1

XML Interface for

NEFT messages

By: Akanksha Gupta

Under the guidance of Shri. G. Raghuraj

6/28/2012

2

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

3

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

4

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

5

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 14th

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.

6

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.

7

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.

8

• 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

9

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

10

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?

11

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.

12

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

13

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 <FrTm> 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 like<IntrBkSttlmDt>2012/06/22</IntrBkSttlmDt> 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.

14

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

15

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.

16

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.

17

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.

- = ^ = -