API (Application Program Interface) for File Transfer between CBS and SFMS

Transcription

1 API (Application Program Interface) for File Transfer between CBS and SFMS Project Guides: Shri. G. Raghuraj Garu General Manager IDRBT, Hyderabad Shri. Sudhir Jha Garu Manager IFTAS, Hyderabad Project Trainees: Pranavi Jalapati GNITS, Hyderabad Satya Naraparaju GNITS, Hyderabad

2 P a g e 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, 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.

3 P a g e 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.

4 P a g e 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 Key Features: NEFT Types of messages in NEFT system: Sender Functionality: Receiver Functionality: RTGS Overview of the Project Progress Process flow of the existing system: Process flow of the designed system: Code ClientSend: ClientReceive: Tools and software s used: Conclusion... 22

5 P a g e 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 The IDRBT developed and implemented the SFMS.

6 P a g e 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.

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

8 P a g e 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.

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

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

11 P a g e 11 Types of messages in NEFT system: The following are the types of messages in NEFT: Message Identifier IFN298N06 Description 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 IFN298N03 IFN298N04 IFN 298N05 Inward Credit Message originated at the RBI to destination banks/branches of receiving banks (298N02 Message) for credit to the beneficiary accounts. Outward Debit Return or Rejection Transaction Message from RBI Service Centre to the Banks (298N03 Message). End-of-Day or End-of-Batch Message from RBI to destination banks/branches of participating Banks (298N04 Message). 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 IFN298N09 IFN298N10 Nil Transaction or Nil Rejection Transaction Message from RBI to destination banks (298N08 Message). Outward Debit Return or Rejection Transaction Message from Bank Service Centre (298N09 Message). 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:

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

13 P a g e 13 Message Identifier Message Name Description pacs FI To FI Payment Status Report Multi-net settlement batch (MNSB) response and Own account transfer. pacs Payment Return Undo previously settled payment. pacs FI To FI Customer Credit Transfer Customer credit transfer. pacs Financial Institution Credit Transfer Interbank transfer, MNSB request and Own account transfer. camt Bank To Customer Statement End-of-day NG-RTGS statements. camt Bank To Customer Debit Credit Notification admi.004 System Event Notification Customer Credit / Debit Notification. Ack / Nack messages exchanged between ISO compliant systems upon delivery of messages. camt.998 Broadcast Message Not an ISO messages. It is SWIFT proprietary MX message which is free to use under certain terms and conditions. head.001 Business Application Header Each financial message i.e. Pacs.008, Pacs.009, 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

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

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

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

17 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

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

19 P a g e 19 Figure 13: Transactions logged in file Figure 13: Transfers logged in database

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

21 P a g e 21 Figure 15: ClientReceive() code Tools and software s used: Eclipse for JAVA MySql for database

22 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. - = ^ = -

23 P a g e 23