API (Application

Program Interface) for

File Transfer between
CBS and SFMS

Project Guides:
Shri. G. Raghuraj Garu Shri. Sudhir Jha Garu
General Manager Manager
IDRBT, Hyderabad IFTAS, Hyderabad

Project Trainees:
Pranavi Jalapati Satya Naraparaju
GNITS, Hyderabad GNITS, Hyderabad
 Page |2

Certificate

This is to certify that Ms. Pranavi Jalapati & Ms. Satya Naraparaju,
pursuing B.Tech course at G. Narayanamma Institute of Technology and
Science (GNITS), in the Department of Computer Science (CSE) have
undertaken a project as an intern at the Institute for Development and
Research in Banking Technology (IDRBT), Hyderabad from May 25 to July 25,
2016.
They were assigned the project “API (Application Program Interface) for
File Transfer between CBS and SFMS” under the guidance of Mr. G. Raghuraj.
During the course of the project they have designed and developed an API for
file transfer between CBS and SFMS. They have understood the concept and
structured a workable model which can be deployed in production with local
configuration adjustments.
We place on record their application to the project and keen sense of
enquiry and focus.

G. Raghuraj
(Project Guide)
General Manager
IDRBT, Hyderabad.
 Page |3

ACKNOWLEDGEMENT

We would like to express our sincere gratitude to the Institute for

Development and Research in Banking Technology (IDRBT) and particularly Mr.
G. Raghuraj Garu, General Manager, IDRBT who was our guide for this project.
We would not hesitate to add that this short stint in IDRBT has added a
different facet to our lives as this is a unique organization 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.
We are extremely grateful to Mr. G. Raghuraj Garu for his advice,
innovative suggestions and supervision. We thank him for introducing us to an
excellent banking application and giving us the opportunity to study the
payment systems in detail.
We are thankful to Shri Sudhir Kumar Jha, Project Head of SFMS who
explained the work flow of SFMS and introduced us to the idea of developing
an interface between CBS and SFMS. We thank the service provider team of
TCS who reviewed the project.
We are thankful to Department of Computer Science, GNITS for giving us
supporting us to avail this golden opportunity to work in a high-end research
institute like IDRBT. We are thankful to IDRBT for providing such an amazing
platform to work on real application oriented research. Finally, I thank one and
all who made this project successful either directly or indirectly.

Pranavi Jalapati & Satya Naraparaju

Department of Computer Science
G. Narayanamma Institute of Technology and Science
Hyderabad.
 Page |4

Table of Contents
Abstract ................................................................................................................................................... 5
Objectives ............................................................................................................................................... 5
Introduction ............................................................................................................................................. 5
Definitions, acronyms and abbreviations ................................................................................................ 6
SFMS and INFINET ............................................................................................................................... 7
SFMS architecture .............................................................................................................................. 7
Bank API Server ............................................................................................................................. 8
Bank API Client .............................................................................................................................. 8
Messages flow..................................................................................................................................... 8
Outgoing message flow................................................................................................................... 8
Incoming Message Flow ................................................................................................................. 9
Payment Systems .................................................................................................................................. 10
Key Features: ................................................................................................................................ 10
NEFT .................................................................................................................................................... 10
Types of messages in NEFT system: ................................................................................................ 11
Sender Functionality: ........................................................................................................................ 11
Receiver Functionality: ..................................................................................................................... 11
RTGS .................................................................................................................................................... 12
Overview of the Project Progress ......................................................................................................... 14
Process flow of the existing system: ..................................................................................................... 14
Process flow of the designed system: ................................................................................................... 15
Code ...................................................................................................................................................... 20
ClientSend: ........................................................................................................................................ 20
ClientReceive: ................................................................................................................................... 20
Tools and software’s used: ................................................................................................................... 21
Conclusion ............................................................................................................................................ 22
 Page |5

Abstract
Banking technology has emerged into an essential medium having considerably made
inroads into most of banking activities but the journey of reaching all citizens is not yet
complete. It is estimated that a majority of the 1.3 billion Indians today, have no access to
financial services, and have to resort to cash payments for all transactions. There have been
significant developments in the way trading and business are conducted especially in terms of
e-commerce through digitisation. Most trade associated with currency has to pass through an
online transaction at some stage of the processing cycle. Though, relatively convenient,
efficient and fast, online transactions are no exceptions in avoiding impediments. In the last
decade, India has seen a shift from traditional payment methods, i.e., cash/paper-based
payments to modern electronic payment systems. According to the current statistics, 3% of
payment transactions for public and private sector banks are paper based. Some of the main
issues associated with such systems are ensuring security and convenient access to better
automation.

This project focuses on the later aspect by providing an API (Application Programme
Interface) which enables bridging the gap between a banks internal CBS platform and the
external messaging interface. Every interbank transaction initiated at the source level (CBS)
is a message that carries the required information to the intermediary destination (Hub). The
project aims to develop an API which generates a corresponding file for the message at the
bank CBS and pushes it onto the SFMS server. The API ensures secure file transfer by
leveraging network protocols and files encryption along the transfer path and has added
features like transmitting multiple files.

Objectives
The objectives of this project are as follows:

 Generation of file containing the messages received from the CBS of banks.
 To build an interface that generates, processes and transfers NEFT transaction
messages and uploads the files on to the SFMS ‘member interface’.

Introduction
Trade is one of the primary revolutions in the progress of the human race. It has
evolved all the way from barter system in which goods are traded for goods to the modern
trade where goods are traded for money. With the increase in frequency and volume of trade,
efficient and automated processes are continuously innovated and established. With the
advent of electronics, it has lead to the development of banking technology.

The RBI (Reserve Bank of India) is the central bank of India which frames the
monitory policy for the country. Institute for Development and Research in Banking
Technology (IDRBT) an autonomous institution for research was established by the RBI in
1996. The IDRBT developed and implemented the SFMS.
 Page |6

The Structured Financial Messaging System (SFMS) which runs on the closed user
group network, INFINET is one of the major contributions of the IDRBT to the Indian
Banking sector as a secure financial messaging platform.

Definitions, acronyms and abbreviations

S. No Key Abbreviation / Definition
1. API Application Program Interface
2. CA Certifying Authority
3. CCA Controller of Certifying Authorities
4. IDRBT Institute for Development and Research in Banking
Technology
5. IFSC Indian Financial System Code
6. INFINET INdian FINancial NETwork
7. LAN Local Area Network
8. MI Member Interface
9. NEFT National Electronic Funds Transfer
10. RA Registration Authority
11. RBI Reserve Bank of India
12. RTGS Real Time Gross Settlement
13. SFMS Structured Financial Messaging System
14. SFTP Secure File Transfer Protocol
15. SWIFT Society for Worldwide Inter-bank Financial
Telecommunication
16. TCP/IP Transmission Control Protocol / Internet Protocol
17. SMAC This is the MAC generated with node server certificate
18. UMAC This is the MAC generated with Authorizer’s signature
19. UNAK This is the User NAK and is generated when the UMAC
verification fails at the receiving branch
Table 1: Definitions, acronyms and abbreviations

In the recent past, the RBI has taken multiple steps to promote e-payment systems such as:
 Framing the Payment & Settlement Systems Act, 2007 to provide for the regulation
and supervision of payment systems in India
 Providing robust RTGS/NEFT platform, establishing National Payments Corporation
of India (NPCI) to act as an umbrella institution for all the retail payment systems
 Regulation and promotion of acceptance channels including ATMs, POS and payment
gateway policy
 Issuance guidelines and security measures for all card transactions.
 Page |7

SFMS and INFINET

SFMS (Structured Financial Messaging System) was developed by the IDRBT to
provide a secure domestic platform for intra-bank and inter-bank applications messaging. The
system defines message formats and authorization process for the banking and financial
applications. The SFMS API is a part of SFMS Online/Offline Server Software for external
bank applications to send and receive messages.

SFMS messaging is on a CUG proprietary network called INFINET. Participation in

INFINET and National Payment System Applications is authorised by the Reserve Bank of
India (RBI), Department of Payment and Settlement Systems (DPSS), Central Office,
Mumbai. DPSS assigns a unique bank code to each authorised participant in INFINET and
payment applications. This code is referred to as the IFSC code (Indian Financial System
Code). It is of eleven (11) character alpha-numeric length with the first four being the unique
bank code and the fifth being a mandatory numerical ‘zero’ followed by six characters of
branch or function code. The bank itself assigns the branches or functions with a unique code
as per the predefined number of characters. In order to enable interoperability between
domestic and cross border messaging applications, the SFMS system is modelled on the
broad messaging architecture of the SWIFT (Society for Worldwide Interbank Financial
Telecommunication), as it was already established in the international market.

Message series Description of Series

IFN 1XX Customer payments & cheques
IFN 2XX Financial Institution Transfers
IFN 3XX Treasury Markets - Foreign Exchange,
Money Markets and derivatives
IFN 4XX Collections and Cash Letters
IFN 5XX Securities Markets
IFN 6XX Precious Metals and Syndications
IFN 7XX Documentary Credits and Guarantees
IFN 8XX Travellers Cheques
IFN 9XX Cash Management and Customer Status
IFN 298GXX Government Account Transactions
IFN 298NXX NEFT messages
IFN 298RXX RTGS Messages
IFN 298MXX Miscellaneous series
IFN 298CXX Currency Chest Transfer
Table 2: IFSC Codes

SFMS architecture
SFMS is customized and deployed in a multi-tier architecture consisting of a central
HUB, Bank Gateways and the Branch Front-ends. The branch front-ends have been
consumed after all banks implemented centralised accounting through their core banking
 Page |8

applications. The INFINET connectivity is a mix of different communication technologies

with the flexible MPLS (multi protocol label switching), leased lines, RF (line-of-site Radio
Frequency) and also to some extent VSAT (very small aperture terminal). These
communication links / leased lines connect the SFMS HUB and the Gateway sites. The
transaction message is generated by the SFMS On-line. For internal purposes like organizing
the message in a format compatible with the server software, banks use third party
applications. To transmit the message to the destination, Bank API Interface provided by
SFMS is the platform which serves as a secured messages interface application riding on the
IBM Web Sphere MQ middleware.

The security structures embedded in the SFMS enables the RBI and the banks to
leverage this messaging platform for funds or trade-based applications such as National
Electronic Funds Transfer (NEFT), Real Time Gross Settlement System (RTGS), Delivery
Versus Payments (DVP), the now defunct Centralized Funds Management System (CFMS),
letters of credit and bank guaranty.

The components of SFMS Bank API are:

Bank API Server

The Bank API Server sends and receives messages corresponding to requests from Bank
API Client. This server runs continuously as a daemon process and waits for a request from
Bank API client. The features of Bank API Server are as follows:

 Bank API Server validates incoming messages (IFN N06 in the case of NEFT
outward messages) and acknowledges the receipt to the Bank API Client.
 Bank API server validates user signature with Block 4 content of the SFMS message.
After successful validation, the message is processed.
 In case the validation fails, transaction is aborted and an error message is displayed.
 Bank API Server sends set of messages to Bank API client in case the client requests
for a message.

Bank API Client

The Bank API client software uses third party API’s to call the server and enable
transactions. The functions of Bank API Client are as follows:

 Send message using file.

 Send message as a string.
 Receive messages as a string.

Messages flow
The message flow from SFMS Bank API server to external applications is as follows:

Outgoing message flow

 External Application re-organises the message in a format receivable by SFMS.
 Page |9

 External Application invokes SFMS Bank API Server with message as a string or a
file passed as an argument. At a time, only one message is allowed from the Bank API
client to the Bank API server.
 SFMS Bank API Server process running at SFMS Online server validates message
and populates the data into SFMS Online Server on successful validation and also
sends corresponding response message.
 During the validation of the message, system verifies for the User Signature (UMAC).
If a message is not signed, then that message will be kept in “PENDING
AUTHORIZATION” state. The user needs to authorize the message at SFMS online /
server manually (using SFMS Application).
 If the message is signed, on successful verification of UMAC the message will be
kept in “TO BE SENT” state in SFMS. If the verification fails, SFMS API returns the
error code to the external application.

Incoming Message Flow

 External application invokes SFMS Bank API Client with receive option.
 SFMS Bank API Server verifies External application request and sends the messages
as a string.
 Incoming messages are sent by the Bank API server to the client as a batch of ten
transactions.
 Incoming messages are returned in the form of a string with a delimiter $@$.

Figure 1: Message Flow hierarchy

 P a g e | 10

Payment Systems
Payments Systems witnessed frequent changes, post 1991, due to the market
dynamics and increasing consumer demands. The reliability on payment systems
infrastructure is based on the four vital components, including, safety, security, soundness
and efficiency. Furthermore, RBI established IDRBT’s Closed User Group Network
(INFINET) which provides a communication channel to participating member banks and
financial institutions a stringently managed system to enable high value financial message
transmission.
Key Features:
 3-tier architecture which can be extended to n-tier with Central Hub, Bank level and
Branch Level modules connected with intra and inter-bank financial messaging.
 Establishment of powerful as well as user configurable payments infrastructure.
 Template builder for creation of new message types and modification of
existing message types.
 Inter and Intra-bank Secure file transfer.
 Automated and centralized proliferation of changes to message versions.
 Centralized message syntax and rule engine.
 Centralized addition of new banks and branches and management directory services.
 Interfacing with other payment structure components such as settlement systems of
RTGS, NEFT, etc.
 Store and forward principle at each module with complete traceability of messages.
 Multiple network connectivity options-, MPLS, leased line, VSAT and ISDN.
 End-to-end PKI based security thereby encompassing confidentiality.

NEFT
Nation Electronic Fund Transfer (NEFT) facilitates individuals, firms and corporate
to electronically transfer funds especially retail remittances. It is available 24x7x365 for a
retail customer without any limit of amount. It is a cost and time effective way to transfer
funds without at geographical restrictions across the country. The NEFT rides on the SFMS
messaging platform. Being a financial transaction system, the format of the message which
holds the details required, has a mandated structure.

NEFT operates on the concept of centralised accounting system. Every individual

bank that is sending or receiving funds transfer instructions, gets accounted for, in a batch
mode on net basis, at one central location which is maintained at the Reserve Bank of India,
Mumbai. The individual branches participating in NEFT could be located anywhere across
the country. The NEFT settlement system at the RBI 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.
 P a g e | 11

Types of messages in NEFT system:

The following are the types of messages in NEFT:
Message Identifier Description
IFN298N06 Outward Debit Message (298N06 Message). This message is
initiated from branch of the bank. It is generally not initiated from
Service Centre of Banks.

IFN298N02 Inward Credit Message originated at the RBI to destination

banks/branches of receiving banks (298N02 Message) for credit to
the beneficiary accounts.

IFN298N03 Outward Debit Return or Rejection Transaction Message from RBI

Service Centre to the Banks (298N03 Message).

IFN298N04 End-of-Day or End-of-Batch Message from RBI to destination

banks/branches of participating Banks (298N04 Message).

IFN 298N05 Settlement Confirmation or Rejection Message from RTGS to NEFT

(298N05 Message).

IFN298N07 Inward Credit Return or Rejected Transaction Message (298N07

Message). This message is initiated at the branch of the banks.

IFN 298N08 Nil Transaction or Nil Rejection Transaction Message from RBI to
destination banks (298N08 Message).

IFN298N09 Outward Debit Return or Rejection Transaction Message from Bank

Service Centre (298N09 Message).

IFN298N10 Credit Confirmation Message from beneficiary bank to originating

bank (298N10 Message).

Table 3: NEFT Message Formats

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 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:
 P a g e | 12

 Step1: Each settlement participating bank creates 298N06 Message in the CBS 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 which contain a maximum of 10
NEFT transactions in one 298N06 Message. This Message is sent to RBI-SFMS-MI-
NEFT module through the IDRBT Hub.
 Step3: Once Message reaches at RBI-SFMS-MI-NEFT centre, it gets net settled
according to the settlement batch-time (8.00 AM to 7.00 PM, twelve settlements in
all). The net settlement is forwarded to the RBI’s CBS (e-Kuber) maintained by the
Deposit Accounts Department for accounting purposes.
 Step4: After accounting in the RBI’s books a confirmation Message is sent to RBI-
SFMS-MI-NEFT system.
 Step5: On receiving the message, RBI-SFMS-MI-NEFT system sends 298N02
Messages to destination bank’s service centres which further passes on the message
with details of the beneficiary accounts to the bank’s CBS for credit to the respective
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 after credit to the beneficiaries'
accounts the net position is tallied with the CBS balances.

RTGS
In the area of wholesale and Inter Bank payments the legacy system suffered from a
lack of scalability and features needed for the current banking and treasury operations. In this
context, RBI decided to implement a new RTGS system that would be scalable, interoperable
with other National Banking Systems and across the globe. Real-time gross settlement
systems (RTGS) are specialized funds transfer system in which the transfer of money takes
place from one bank to another on a “real time” and “gross” basis. In other words, payment
transaction is not subjected to any waiting period nor the amount of the transaction is netted
with any other amount.

The transaction is settled on one to one basis without bundling or netting with any
other transaction and once they are processed, the payments are irrevocable. Hence, this
payment system is generally used for high-value transactions that require immediate clearing.
Under normal circumstances the beneficiary branches are expected to receive the funds in
real time as soon as funds are transferred by the remitting bank and settlement process is
completed in the Reserve Bank of India. The beneficiary bank has to credit the beneficiary's
account immediately on receiving the funds transfer message. There are penalties for delayed
credit or delayed return.
 P a g e | 13

Message Message Name Description

Identifier

pacs.002.001 FI To FI Payment Multi-net settlement batch (MNSB) response and

Status Report Own account transfer.

pacs.004.001 Payment Return Undo previously settled payment.

pacs.008.001 FI To FI Customer Customer credit transfer.

Credit Transfer

pacs.009.001 Financial Institution Interbank transfer, MNSB request and Own

Credit Transfer account transfer.

camt.053.001 Bank To Customer End-of-day NG-RTGS statements.

Statement

camt.054.001 Bank To Customer Customer Credit / Debit Notification.

Debit Credit
Notification
admi.004 System Event Ack / Nack messages exchanged between ISO
Notification 20022 compliant systems upon delivery of
messages.
camt.998 Broadcast Message Not an ISO 20022 messages. It is SWIFT
proprietary MX message which is free to use under
certain terms and conditions.
head.001 Business Application Each financial message i.e. Pacs.008, Pacs.009,
Header Pacs.004, Pacs.002, Camt.054 will have Header
which contains sender and receiver information
along with Digital Signature of sender of the
financial message.
pacs.009 IDL Request Fund request from RTGS to Central Bank Security
Settlement System (SSS).

pacs.009 IDL Response IDL response from Security Settlement System

(SSS) to RTGS.

pacs.004 IDL Reversal IDL reversal from RTGS to SSS.

Table 4: RTGS Message Formats

 P a g e | 14

NEFT operates on a Deferred Net Settlement (DNS) basis which settles transactions
in batches. In DNS, the settlement takes place with all transactions received till the particular
cut-off time. These transactions are netted (payable and receivables) in NEFT whereas in
RTGS the transactions are settled individually. Moreover, in DNS any transaction initiated
after a designated settlement time will be kept on hold till the next designated settlement time
Contrary to this, in the RTGS, transactions are processed continuously throughout the RTGS
business hours. RBI decided to implement ISO-20022 standard messages and use the
dependable SFMS platform provided by IDRBT as the messaging backbone of the new
RTGS.

Overview of the API Project

This project proposes an interface between the SFMS (Structured Financial Messaging
System) and CBS (Core Banking System) which invokes two primary functions of the
SFMSBankAPI namely ‘Send’ and ‘Receive’. The message sent can either be a file or a
string. The 'Receive' option receives the incoming messages in the string format. The
interface dynamically connects to the server using the port specified at the client end.
Network Congestion due to multiple file transfer is avoided using congestion control
mechanism in the application. The server acknowledges successful transfer or reports a NAK
(Negative acknowledgment) in case of failure. On receiving a positive acknowledgment, the
files at the parent location are deleted to avoid duplication. All the transactions and login
activities are logged using a database for ensuring accountability.

Process flow of the existing system:

The flow of the current system is as follows:
 All the class files are setup in the required location to maintain the valid package
hierarchy.
 The Clients can run the objects through the command prompt.
 The BankAPIServer is invoked as a daemon thread. Using RMI registry call and the
port number, request is sent to the server to establish a connection.

Figure 2: Command to start the server using RMI Registry

 Once the connection is established, the client object with two primary functionalities
is called using the BankAPIClient object. The functionalities of a client object are
‘Send’ and ‘Receive’.
 P a g e | 15

Figure 3: Send and Receive functionalities offered by BankAPIClient

 The send function initiates a message transfer at the Client-side. The server accepts
messages only if they are in the file (i.e. .txt) format.
 To initiate the transaction at the Client-side, the command given must be in a specific
structure maintaining the package hierarchies, the source location (of the message)
and the corresponding password for the AppId of the initiated transaction.

Figure 4: Command to call the sent function

Command Structure: java sfmsbr.bankapi.BankAPIClient filesend filename.txt

<Bank Application Password> <filename>

 The receive function initiates a message transfer at the Server-side. The client can
accept messages either in the file format or as a string.
 If the transfer is aborted due to any failure, the server acknowledges with a NAK
(negative acknowledgment).

Process flow of the system (as designed):

The designed API is a user-friendly interface which is independent of the command prompt
usage. It displays a GUI with functionalities like multiple file transfer and transaction
logging.

The flow of the designed system is as follows:

 The GUI is a compilation of 5 classes designed for user authentication, connection

establishment, multiple file transfer initiated at the client-end, receiving the files and
string messages pushed by the server.
 Once the API is launched, it first authenticates the user using a password mechanism.
The username and the corresponding password are stored in a MySql database.
 P a g e | 16

Figure 5: User authentication frame

 If the access is authenticated, the user can choose between Send and Receive
functions which create the ClientSend and ClientReceive objects respectively.

Figure 6: Functionalities GUI

 On creating a ClientSend or ClientReceive object, the application prompts for IP

address and port number using which it establishes a connection and checks whether
the socket of the server is ‘alive’ by using the ping function.

Figure 7: Prompt for IP address Figure 8: Prompt for Port no.

 In the case of ClientSend, if the connection is successfully established, the function

reads the location of the target files using the JBrowser. The function prompts for the
corresponding password for the AppId of the target files. If the password matches the
AppId, the database is scanned to check for duplication and the files are transferred
across LAN (Local Area Network) and are stored at the destination directory specified
in the code. In case of duplication, it returns an error. On receiving an
acknowledgment from the server, the transaction is logged in SQL database and the
target files are deleted.
 P a g e | 17

Figure 9: Prompt for password to authenticate the file

Figure 20: Setup to select and send the file

 In the case of ClientReceive, if the connection is successfully established, the function

prompts for the destination location where the message is to be saved. On successfully
receiving the message, the destination counter-part which in this case is the server is
 P a g e | 18

acknowledged after which the port is closed and connection is terminated. The
transaction is logged using SQL database.
 The login details are logged in a log file located at C:\FileTransfer\Login.log.

Figure 11: Login details logged using log handler

 Also the transactions are logged in MySql database and a text file located at
C:\FileTransfer\File_Log.txt. This makes the API portable and also compatible with
systems not using MySql database.
 P a g e | 19

Figure 13: Transactions logged in file

Figure 13: Transfers logged in database

 P a g e | 20

Code
ClientSend:
ClientSend() constructor initializes the GUI for transferring the files. In general, to detect when the
user clicks an onscreen button (or does the keyboard equivalent), a program must have an object
that implements the Action Listener interface.

Figure 14: ClientSend() code

ClientReceive:
ClientReceive() initializes the GUI for receiving the files. In general, to detect when the user clicks an
onscreen button (or does the keyboard equivalent), a program must have an object that implements
the Action Listener interface.
 P a g e | 21

Figure 15: ClientReceive() code

Tools and software’s used:

 Eclipse for JAVA
 MySql for database
 P a g e | 22

Conclusion
The application is a user friendly and cost effective solution that facilitates the client with a
user interface. The Multiple transfer facility enhances the current methodology by saving
time. The API ensures secure file transfer by leveraging network protocols offered by
transport layer and files encryption along the transfer path and has added features like
transaction logging. Currently, some banks are using manual creation of RMI interface to
transfer the messages received from the CBS to SFMS hub. The API is targeted for such
banks to provide a better user interface supplemented by multiple file transfer and transaction
logging.

-=^=-
P a g e | 23