XML Interface for

NEFT messages

By: Akanksha Gupta

Under the guidance of Shri. G. Raghuraj
6/28/2012

1
 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

2
 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

3
 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

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

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

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

7
 • 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

8
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

9
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?

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

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

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

13
 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

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

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

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

-=^=-

17