STUDY ON ATM-POS SWITCHING SOFTWARE FOR BANKS

1. I STUDY ON ATM/POS SWITCHING SOFTWARE FOR BANKS Submitted by: Md. Nazmul Sarker Student ID: 0805015 Md Swawibe Ul Alam Student ID: 0805080 Md Main Uddin Rony Student ID: 0805119 SUBMITTED TO: DR. MD. MOSTOFA AKBAR PROFESSOR DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING BANGLADESH UNIVERSITY OF ENGINEERING AND TECHONOLOGY DHAKA, BANGLADESH

2. II Certificate This is certify that the work presented in this project entitled “Study on ATM/POS Switching Software for Banks” is the outcome of the investigation carried out by us under capable supervision of Dr. Md. Mostofa Akbar in the Department of Computer Science of Engineering, Bangladesh University of Engineering and Technology(BUET),Dhaka.It is also declared that neither this project nor any part of thereof has been submitted or is being currently submitted anywhere else for the award of any degree or diploma. Authors ---------------------- Md. Nazmul Sarker ---------------------- Md Swawibe Ul Alam ---------------------- Md Main Uddin Rony Supervisors ------------------------------- Dr. Md Mostofa Akbar Professor Department Of Computer Science and Engineering BUET, DHAKA

3. ii Contents Candidates Declaration Certificate List of Figures List of Tables Acknowledgements Abstract 1. Introduction................................................................. ............................................................ 1 1.1. What is ATM/POS Switching Software?................................................................ 1 1.2. Motivation................................................................. ........................................................ 3 1.3. Scope of the Thesis......................................................................................................... 3 1.4. Organization of the Thesis.......................................................................................... 4 2. Preliminaries................................................................. .............................................. ............ 5 2.1. Protocols................................................................. ........................................................... 5 2.1.1. ISO 8583................................................................................................... ............. 5 2.1.1.1 Bitmap.............................................................................................. ........... 6 2.1.1.2 Data Elements................................................................................ .......... 7 2.1.2. NDC (NCR Direct Connect) ......................................................................... 11 2.1.2.1 NCR 5xxx series..................................................................................... 12 2.1.2.2 NCR 66XX series.................................................................................... 13 2.1.2.3 NCR Self-Serv 20 & 30 series........................................................... 13 2.1.3. DDC........................................................................................................................ 14 2.2. SCMS/CMS....................................................................................................................... 15 2.3. CBS................................................................. .................................................................... 17 2.4. MTI................................................................. ................................................................... 18 2.4.1 ISO 8583 version............................................................................................... 18 2.4.2 Message class...................................................................................................... 19 2.4.3 Message function............................................................................................... 20 2.4.4 Message origin.................................................................................................... 21 3. Working Principle of ATM/POS Machine.................................................................... 22 3.1. ATM/POS to ATM/POS switch................................................................................ 22 3.2. ATM/POS Switch to ATM/POS................................................................................ 23 3.2.1 Status Descriptor Field.................................................................................... 24 3.2.2 Status Information Field................................................................................. 24

4. iii 3.3. ATM/POS Switch to CBS ........................................................................................... 24 3.4. CBS to ATM/POS Switch............................................................................................ 25 4. Analysis of ATM/POS Implementation........................................................................ 27 4.1 Survey in Bank................................................................................................................ 27 4.2 Questionnaire for Survey........................................................................................... 27 4.3 Conclusion of Survey................................................................................................... 29 5. Guideline to implement ATM/POS interface............................................................ 30 5.1 Architecture of Interface Software........................................................... 30 5.1.1 How the terminal operates.................................................................. 30 5.1.2 Creating an Advance NDC System..................................................... 31 5.1.2.1 Customization Data.............................................................. 31 5.1.2.2 Creating the Central Control Application............................ 32 5.1.3 Detailed Description of the components............................................. 33 5.1.3.1 State Tables.......................................................................... 33 5.1.3.2 Screen Interface................................................................... 40 5.1.3.3 Printer Data.......................................................................... 42 5.1.3.4 Supervisor Messages........................................................... 42 5.1.3.5 Configuration Parameters.................................................... 45 5.1.3.6 Financial Institution Tables................................................ .51 5.1.3.7 Terminal to Central Messages............................................. 55 5.1.3.8 Central to Terminal Messages............................................. 64 5.1.3.9 Transaction Reply Command.............................................. 67 5.1.3.10 Interactive Transaction Response...................................... 67 5.2 Identification of challenges and Solutions....................................................... 68 5.3 Time and Manpower Estimation............................................................. 70 5.4 Hardware and software required............................................................ 71 6. Findings............................................... ............................................... ............ 72 7. Future Development............................................... ....................................... 74 8. Conclusion....................................................................................................... 75 Glossary................................................................................................................. 76 References............................................................................................................. 78

5. iv List of Figures 3.1 Working flow of ATM/POS to ATM/POS Switch............................................. 22 3.2 Working flow of ATM/POS Switch to ATM/POS............................................. 23 3.3 Working flow of ATM/POS Switch to CBS...................................................... 25 3.4 Working flow of CBS to ATM/POS Switch...................................................... 26 5.1 Screen layout....................................................................................................... 41 5.2 Time estimation................................................................................................... 70

6. v List of Tables 2.1 Data elements of ISO 8583............................................. 8 2.2 ISO 8583 data fields........................................................ 8 2.3 ISO 8583 version............................................................18 2.4 ISO 8583 Message class.................................................19 2.5 ISO 8583 Message function...........................................20 2.6 ISO 8583 Message origin...............................................21 5.1 Components of Customization Data..............................32 5.2 Different State Types.....................................................34 5.3 Limitations of screen size..............................................43 5.4 Value of three configuration options.............................45 5.5 Option and codes of configuration parameters.............50 5.6 Different type Timers...................................................50 5.7 Contents of FIT Data....................................................53 5.8 Solicited device fault status messages......................... 56 5.9: Device Fault Status Information Field....................... 57 5.10 Unsolicited Message Format..................................... 59 5.11 Status Information Field in Unsolicited message..... 60 5.12 Device Status Information........................................ 61 5.13 Manpower Estimation.............................................. 70

7. vi Acknowledgements Firstly, we would like to give thanks to almighty ALLAH and then express our heartiest and sincere gratitude to our supervisor Professor Dr. Md. Mostofa Akbar for his guidance and supervision. This project work was done under his supervision. With his patience and inspiration and great efforts to explain things clearly and simply helped to make this project work a lot easier for us. His enthusiasm helped in every stage of the accomplishment of this work. Secondly, we would like to express our gratitude to the Director of Islami Bank Bangladesh (IT) - Md Jamal Uddin and General Manager of Pubali Bank Bangladesh (IT) - Mohammad ALI. Finally, we would like to thank all the Faculty members and stuff of Department of CSE, BUET.

8. vii Abstract Every year our local banks spend a lot of money for installing and maintaining switching software provided by foreign vendors. Is it possible to implement ATM/POS switch software in Bangladesh cost effectively? We did requirement analysis of implementing ATM/POS switching software. We tried to find out shortcomings of implementing ATM/POS switching software in Bangladesh. We did survey in 2 Banks IT sector and talked with Vendor of Switching software to study details of Switching software. Finally we tried to estimate manpower and time needed to implement Switching software in Bangladesh.

9. 1 Chapter 1 Introduction 1.1 What is ATM/POS Switching Software? ATM / POS Switch software is an enterprise transaction processing and management system that adheres to open system concepts and client/server architecture. The transaction processing engine resides proven and robust UNIX platforms while the user interfaces reside on Windows client workstations. System data is stored in an ANSI compliant relational database. u/SWITCHWARE software from CSFi is the foundation for the advanced ATM/POS terminal driving and transaction switching system, coupled with unparalleled customer service and 24/7 monitoring and support. In a typical environment, ATM/POS Switching Solution provides hosted ATM/POS terminal support, an interface to Core Banking Solution (CBS) or another core financial system and connectivity to regional, national or international networks. Other interfaces may include a host security module, card output device, automated notification system and ancillary applications for credit card, telephone or Internet banking functions. The primary purpose of the system is to perform transaction processing and routing decisions. Functions include sending on-us transactions to a primary authorizer, switching foreign transactions to EFT net-works, performing PIN validation, standing in when the primary authorizer is unavailable and performing processing decisions according to predetermined financial institution settings. Some of the general functions of ATM/POS switch are:  Hosted ATM and POS terminal driving.  Real-time or batch interface to core financial system for authorization.  Stand-in authorization when the core financial system is unavailable.  Card file management.

10. 2  Gateway to regional, national and international EFT networks including Visa, MasterCard, NYCE, and STAR.  Interfaces to ancillary application software such as credit card, telephone or Internet banking systems.  Supports industry-standard data security methods including DES, 3DES, MAC-ing and verification functions such as CVV, CVC and AVS.  Interfaces to a host security module (HSM) used for secure key storage for cryptographic functions.  Currency conversion functions  Processing issuer transactions from regional, national or international networks.  Unattended continuous transaction processing, with stand-in authorization when the primary authorizer is offline.  Stand-in authorization using a negative, velocity or positive card file.  All transactions authorized in stand-in mode are stored and then forwarded to the host authorizer when it becomes available. An ATM / POS switching Systems architecture consists of a UNIX- based transaction switching engine and a Windows® user interface. A multi-layered security scheme is employed at the operating system and application level. Each user attempting to gain access to the system must enter a valid user ID and password. Customizable user permissions determine the accessibility and functions available to each valid user. The permission levels determine whether the user will have access to the specific client application, and if so, whether the access will include inquiry only or full editing capabilities. The authorization steps are:  Real-time Authorization  File Authorization (Hot Card)  Stand-In Authorization  Positive Card File Authorization  Positive Balance File (PBF)  Negative File Authorization (Hot Card)  CAF or Velocity File Authorization  Store and Forward (SAF)

11. 3 All transaction activity processed by the ATM/POS Switching System is recorded and tallied in daily reports. These reports are produced for each financial institution, at the time of day defined by the financial institution. 1.2 Motivation At present we are importing ATM/POS Switch software from Abroad. Which is very costly and maintenance cost is too high. We have to pay 20%-25% percent of actual price of switch as maintenance cost .Currently there are no software Industries in Bangladesh who are approaching to develop switch in Bangladesh. If ATM/POS switch software can be implemented in Bangladesh and exported to other countries, it will open a new window of software business. It will be a matter of pride for Bangladesh among international switch vendors if it can be implemented in our country. Development of such software will eliminate third party transaction fees to process at us, on us transactions for our banks. Banks and Financial institution will personalize their service through system functions including; VIP limits, personal express cash, marketing messages on ATM receipt and customer notes section without any cost. From these factors we motivated to Study on ATM/POS switching software whether it is possible to implement in Bangladesh for our Banks. 1.3 Scope of the Thesis In our study we have surveyed on many banks. We gather information from their experience of using existing ATM/POS software. We do analysis whether it is feasible to implement ATM/POS switch software in local Banks of Bangladesh. We have analyzed the procedure for developing ATM/POS switch software, rather than implementing it. After a long analysis we made a outline of implementation of ATM/POS switch software.

12. 4 1.4 Organization of Thesis In chapter 2, we give some basic terminology of ATM/POS switch. We discuss about the basic definitions and problems which is necessary to understand the rest of the chapters. In chapter 3, we discuss the working principle of ATM/POS Switch. We describe the workflow of the whole ATM/POS system. In chapter 4, we do analysis of ATM/POS switch implementation for the banks. We give details of implementing a ATM/POS switch. In chapter 5, A guideline for implementing ATM/POS switch has been discussed with every details.

13. 5 Chapter 2 Preliminaries 2.1 Protocols In computer science, Protocol is a system of digital rules for data exchange within or between computers. Communicating systems use well- defined formats for exchanging messages. Each message has an exact meaning intended to elicit a response from a range of possible responses pre-determined for that particular situation. Thus, a protocol must define the syntax, semantics, and synchronization of communication; the specified behavior is typically independent of how it is to be implemented. A protocol can therefore be implemented as hardware, software, or both. Communications protocols have to be agreed upon by the parties involved.[1] To reach agreement a protocol may be developed into a technical standard. A programming language describes the same for computations, so there is a close analogy between protocols and programming languages: protocols are to communications as programming languages are to computations. 2.1.1 ISO 8583 ISO 8583 Financial transaction card originated messages and Interchange message specification is the International Organization for Standardization standard for systems that exchange electronic transactions made by cardholders using payment cards. It has three parts: Part 1: Messages, data elements and code values Part 2: Application and registration procedures for Institution Identification Codes (IIC)

14. 6 Part 3: Maintenance procedures for messages, data elements and code values An ISO 8583 message is made of the following parts:  Message type indicator (MTI)  One or more bitmaps, indicating which data elements are present  Data elements, the fields of the message 2.1.1.1 Bitmap Within ISO 8583, a bitmap is a field or subfield within a message which indicates which other data elements or data element subfields may be present elsewhere in a message. A message will contain at least one bitmap, called the Primary Bitmap which indicates which of Data Elements 1 to 64 are present. A secondary bitmap may also be present, generally as data element one and indicates which of data elements 65 to 128 are present. Similarly, a tertiary, or third, bitmap can be used to indicate the presence or absence of fields 129 to 192, although these data elements are rarely used. The bitmap may be transmitted as 8 bytes of binary data, or as 16 hexadecimal characters 0-9, A-F in the ASCII or EBCDIC character sets. A field is present only when the specific bit in the bitmap is true. For example, byte '82x is binary '1000 0010' which means fields 1 and 7 are present in the message and fields 2, 3, 4, 5, 6, and 8 are not present. For example if bitmap is 4210001102C04804,then it defines the presence of Fields 2, 7, 12, 28, 32, 39, 41, 42, 50, 53, 62. Explanation of Bitmap (8 BYTE Primary Bitmap = 64 Bit) field 4210001102C04804 BYTE1 : 01000010 = 42x (counting from the left, the second and seventh bits are 1, indicating that fields 2 and 7 are present) BYTE2 : 00010000 = 10x (field 12 is present) BYTE3 : 00000000 = 00x (no fields present) BYTE4 : 00010001 = 11x (fields 28 and 32 are present) BYTE5 : 00000010 = 02x (field 39 is present)

15. 7 BYTE6 : 11000000 = C0x (fields 41 and 42 are present) BYTE7 : 01001000 = 48x (fields 50 and 53 are present) BYTE8 : 00000100 = 04x (field 62 is present) 0________10________20________30________40________50________60__64 1234567890123456789012345678901234567890123456789012345678901234 0100001000010000000000000001000100000010110000000100100000000100 bit map 2.1.1.2 Data Elements Data elements are the individual fields carrying the transaction information. There are up to 128 data elements specified in the original ISO 8583:1987 standard, and up to 192 data elements in later releases. The 1993 revision added new definitions, deleted some, while leaving the message format itself unchanged. While each data element has a specified meaning and format, the standard also includes some general purpose data elements and system- or country-specific data elements which vary enormously in use and form from implementation to implementation. Each data element is described in a standard format which defines the permitted content of the field (numeric, binary, etc.) and the field length (variable or fixed), according to the following table: Abbreviation Meaning a Alpha, including blanks n Numeric values only s Special characters only an Alphanumeric

16. 8 as Alpha & special characters only ns Numeric and special characters only ans Alphabetic, numeric and special characters. b Binary data z Tracks 2 and 3 code set as defined in ISO/IEC 7813 and ISO/IEC 4909 respectively . or .. or ... variable field length indicator, each indicating a digit. Table2.1: Data elements of ISO 8583 ISO 8583 defined 128 data elements. These are listed below: Data Field Type Usage 1 b 64 Bit map (b 128 if secondary is present and b 192 if tertiary is present) 2 n ..19 Primary account number (PAN) 3 n 6 Processing code 4 n 12 Amount, transaction 5 n 12 Amount, settlement 6 n 12 Amount, cardholder billing 7 n 10 Transmission date & time 8 n 8 Amount, cardholder billing fee 9 n 8 Conversion rate, settlement 10 n 8 Conversion rate, cardholder billing 11 n 6 System trace audit number 12 n 6 Time, local transaction (hhmmss) 13 n 4 Date, local transaction (MMDD) 14 n 4 Date, expiration 15 n 4 Date, settlement

17. 9 16 n 4 Date, conversion 17 n 4 Date, capture 18 n 4 Merchant type 19 n 3 Acquiring institution country code 20 n 3 PAN extended, country code 21 n 3 Forwarding institution. country code 22 n 3 Point of service entry mode 23 n 3 Application PAN sequence number 24 n 3 Function code (ISO 8583:1993)/Network International identifier (NII) 25 n 2 Point of service condition code 26 n 2 Point of service capture code 27 n 1 Authorizing identification response length 28 x+n 8 Amount, transaction fee 29 x+n 8 Amount, settlement fee 30 x+n 8 Amount, transaction processing fee 31 x+n 8 Amount, settlement processing fee 32 n ..11 Acquiring institution identification code 33 n ..11 Forwarding institution identification code 34 ns ..28 Primary account number, extended 35 z ..37 Track 2 data 36 n ...104 Track 3 data 37 an 12 Retrieval reference number 38 an 6 Authorization identification response 39 an 2 Response code 40 an 3 Service restriction code 41 ans 8 Card acceptor terminal identification 42 ans 15 Card acceptor identification code 43 ans 40 Card acceptor name/location (1-23 address 24- 36 city 37-38 state 39-40 country) 44 an ..25 Additional response data 45 an ..76 Track 1 data 46 an ...999 Additional data - ISO 47 an ...999 Additional data - national 48 an ...999 Additional data - private 49 a or n 3 Currency code, transaction 50 a or n 3 Currency code, settlement

18. 10 51 a or n 3 Currency code, cardholder billing 52 b 64 Personal identification number data 53 n 16 Security related control information 54 an ...120 Additional amounts 55-56 ans ...999 Reserved ISO 57-60 ans ...999 Reserved national 61-63 ans ...999 Reserved private 64 b 16 Message authentication code (MAC) 65 b 1 Bitmap, extended 66 n 1 Settlement code 67 n 2 Extended payment code 68 n 3 Receiving institution country code 69 n 3 Settlement institution country code 70 n 3 Network management information code 71 n 4 Message number 72 n 4 Message number, last 73 n 6 Date, action (YYMMDD) 74 n 10 Credits, number 75 n 10 Credits, reversal number 76 n 10 Debits, number 77 n 10 Debits, reversal number 78 n 10 Transfer number 79 n 10 Transfer, reversal number 80 n 10 Inquiries number 81 n 10 Authorizations, number 82 n 12 Credits, processing fee amount 83 n 12 Credits, transaction fee amount 84 n 12 Debits, processing fee amount 85 n 12 Debits, transaction fee amount 86 n 16 Credits, amount 87 n 16 Credits, reversal amount 88 n 16 Debits, amount 89 n 16 Debits, reversal amount 90 n 42 Original data elements 91 an 1 File update code 92 an 2 File security code 93 an 5 Response indicator

19. 11 94 an 7 Service indicator 95 an 42 Replacement amounts 96 b 64 Message security code 97 x+n 16 Amount, net settlement 98 ans 25 Payee 99 n ..11 Settlement institution identification code 100 n ..11 Receiving institution identification code 101 ans ..17 File name 102-103 ans ..28 Account identification 1 104 ans ...100 Transaction description 105-111 ans ...999 Reserved for ISO use 112-119 ans ...999 Reserved for national use 120-127 ans ...999 Reserved for private use 128 b 64 Message authentication code Table 2.2: ISO 8583 data fields 2.1.2 NDC (NCR Direct Connect) NDC stands for NCR Direct Connect. Automated Teller Machines (ATMs) are now NCR's principal product line. NCR had made its first ATM in the late 1970s with widespread installations of the model 770 in National Westminster and Barclays Banks throughout the UK, but it was not until the Model 5070, developed at its Dundee plant in Scotland and introduced in 1983 that the company began to make more serious inroads into the ATM market. Subsequent models included the 5084, 56xx, and 58xx (Personas) series. In early 2008 the company launched its new generation of ATMs—the 662x/663x SelfServ series. NCR currently commands over a third of the entire ATM market, with an estimated $18 trillion being withdrawn from NCR ATMs every year. In addition, NCR's expertise in this field led the company to contract with the U.S. Military to support the Eagle Cash program with customized ATMs.

20. 12 2.1.2.1 NCR 5xxx series The NCR 5xxx-series is the range of (ATM's) produced by NCR from the early 1980s. Most models were designed and initially manufactured at its Dundee factory in Scotland, but later produced at several other locations around the world. There have been several distinct generations:  50xx-series: The initial models introduced were the 5070 (interior vestibule) and 5080 (Through The Wall or TTW) introduced a number of features which have become standard among ATM's— chiefly the individual functions of the ATM are divided among discrete modules which can be easily removed and replaced for repair or replenishment. The 5080 featured the standard anti-vandal smoked perspex screen which covered the keypad and screen until the cardholder inserted their card. The enhanced 5084 TTW model appeared in later and had an improved anti-vandal fascia and was the first ATM to dispense with the need for the retracting perspex screen. The 5085 offered the first crude deposit function; with the machine supplying the deposit envelopes which were subsequently stored in the machine's safe for subsequent back office processing.  56xx-series: Enhanced functions such as colour displays and improved security and usability functions became available. The introduction of Media Entry Indicators (MEI) which highlight the card entry slot to the customer was also a part of this series. Some 56xx machines produced between 1994–1996 were badged as "AT&T" rather than "NCR", mirroring the company's brief ownership under the telecoms giant in the mid-1990s. 56xx models have included the 5670 (interior lobby cash dispense only), 5675 (interior lobby multifunction—dispense & deposit), 5684 (exterior TTW dispense only), 5688 (exterior TTW drive-up multifunction) and 5685 (exterior TTW multifunction).  58xx-series marketed as Personas from 1998 to the present. These models were characterized by the gradual move towards greater ATM functionality including intelligent, envelopeless deposit by

21. 13 means of automated cheque recognition modules, coin dispense, and electronic cash recognition functions which allows bank customers to deposit cash and cheques with instant processing of the transaction. The 58xx series has also been characterised by the gradual introduction of LCD displays instead of the traditional CRT monitor. Models have included the 5870 (compact interior lobby dispense only), 5873 (interior lobby with cash accept & deposit only), 5874 (Exterior TTW cash dispense), 5875 (Multifunction TTW). The latest TTW versions of the Personas line, introduced in 2000 and marketed as M-Series added functions such as cash recycling, coin dispense, barcode reading, a larger 12" LCD display with touch screen option, and for the first time, a common wall footprint for both the Multifunction (5886) or single function (5887). 2.1.2.2 NCR 66XX series NCR's 6th generation of ATMs has been noted for the further move towards intelligent deposit and the expansion of secondary functions such as barcode reading.  667x-series marketed under the Personas M-Series brand were introduced in 2005 to the present. These models consist of the 6676 (interior lobby multifunction) and 6674 (through-the-wall multifunction). The outlook design is very different from the Personas model; on the front-access 6676s the front cover is opened upwards which claim to be saving the services area. 2.1.2.3 NCR Self-Serv 20 & 30 series NCR's latest ATM services, introduced in 2008.This series is a complete redesign of both outlook and technological contents. It is also a cost down product. Self-Serv 20 series are single-function (e.g. cash-out) ATMs, while Self-Serv 30 series are full-function (cash-out and intelligent deposit) machines.

22. 14 2.1.3 DDC It is a messaging protocol and management of ATMs and other self- service banking terminals, systems developed by Diebold (previously operated on the market within a strategic alliance with the corporation IBM). Protocol emerged as a means of standardization system messages and commands for automated self-service banking devices during the development of applications built on client-server technology. Since mid- 1970 CHG. protocol was constantly improved, reflecting the development of functionality of terminals means protecting information and computing power bank servers. At the beginning of 2007. virtually all control controllers ATM networks support different dialects implement the protocol of which the most modern - Diebold 912 (DDC 912). At the same time the scope of the protocol does not fully meet the new requirements and the specifics of modern terminal applications. In this regard, Diebold, Incorporated develops so-called expansion protocol (Protocol Extensions) to support the functionality of EMV, deposit cash and web-interfaces. Currently, the implementation of modern specifications DDC is handled within Diebold AGILIS. Diebold Decoder is a small utility to decode Diebold DDC messages and extract the information from the DDC messages into readable form. For example, you can read Track-2 data, PIN buffer, Operation Key Buffer (opcode). Diebold Decoder supports string mode, ascii-hex mode and Base24 NETADRD as an input.

23. 15 2.2 SCMS/CMS A smart card, chip card, or integrated circuit card (ICC) is any pocket-sized card with embedded integrated circuits. Smart cards are made of plastic, generally polyvinyl chloride, but sometimes polyethylene terephthalate based polyesters, acrylonitrile butadiene styrene or polycarbonate. Since April 2009, a Japanese company has manufactured reusable financial smart cards made from paper. Smart cards can provide identification, authentication, data storage and application processing. Smart cards may provide strong security authentication for single sign-on (SSO) within large organizations. These are the best known payment cards (classic plastic card):  Visa  MasterCard  American Express  Discover A Smart card management system (SCMS or CMS) is a system for managing smart cards through the life cycle of the smart cards. Thus, the system can issue the smart cards, maintain the smart cards while in use and finally take the smart cards out of use (EOL). Chip/smart cards provide the foundation for secure electronic identity, and can be used to control access to facilities, networks or computers. As the smart cards are security credentials for authenticating the smart card holder (for example using two- factor authentication) the security requirements for a smart card management system are often high and therefore the vendors of these systems are found in the computer security industry. Smart card management systems are generally implemented as software applications. If the system needs to be accessible by more than one operator or user simultaneously (this is normally the case) the software application is often provided in the form of a server application accessible from several different client systems. An alternative approach is to have multiple synchronized systems. Smart card management systems connect smart cards to other systems. Which systems the smart card management system must connect

24. 16 to depends on the use case for the smart cards. Typical systems to connect to include:  Connected smart card reader  Unconnected (RFID) smart card reader  Card printer  User directory  Certificate authority  Hardware security module  Physical access control systems During the smart card lifecycle, the smart card is changing state (examples of such states include issued, blocked and revoked), the process of taking a smart card from one state to another, is the main responsibility of a smart card management system. Different smart card management systems call these processes by different names. Below a list of the most widely used names of the processes are listed and briefly explained.  Register – Adding a smart card to the smart card management system  Issue – Issuing or personalizing the smart card for a smart card holder  Initiate – Activating the smart card for first use by the smart card holder  Deactivate – Putting the smart card on hold in the backend system  Activate – Reactivating the smart card from a deactivated state  Lock – Also called block; smart card holder access to the smart card is not possible  Unlock – Also called unblock; smart card holder access to the smart card is re-enabled  Revoke – Credentials on the smart card are made invalid

25. 17  Retire – The smart card is disconnected from the smart card holder  Delete – The smart card is permanently removed from the system  Unregister – The smart card is removed from the system (but could potentially be reused)  Backup - Backup smart card certificates and selected keys  Restore - Restore smart card certificates and selected keys 2.3 CBS Core banking solutions(CBS) are new jargon frequently used in banking circles. The advancement in technology, especially Internet and information technology has led to new ways of doing business in banking. These technologies have cut down time, working simultaneously on different issues and increasing efficiency. The platform where communication technology and information technology are merged to suit core needs of banking is known as core banking solutions. Here, computer software is developed to perform core operations of banking like recording of transactions, passbook maintenance, interest calculations on loans and deposits, customer records, balance of payments and withdrawal. This software is installed at different branches of bank and then interconnected by means of communication lines like telephones, satellite, internet etc. It allows the user (customers) to operate accounts from any branch if it has installed core banking solutions. This new platform has changed the way banks are working. Gartner defines a core banking system as a back-end system that processes daily banking transactions, and posts updates to accounts and other financial records. Core banking systems typically include deposit, loan and credit-processing capabilities, with interfaces to general ledger systems and reporting tools. Strategic spending on these systems is based on a combination of service-oriented architecture and supporting technologies that create extensible, agile architectures. Many banks implement custom applications for core banking. Others implement/customize commercial ISV packages. While many banks run core banking in-house, there are some which use outsourced service providers as well. There are several Systems integrators like Capgemini,

26. 18 Accenture, IBM and HP which implement these core banking packages at banks. 2.4 MTI Message type indicator (MTI) is a 4 digit numeric field which classifies the high level function of the message. A message type indicator includes the ISO 8583 version, the Message Class, the Message Function and the Message Origin, each described briefly in the following sections. The following example (MTI 0110) lists what each digit indicates: 0xxx -> version of ISO 8583 (1987 version) x1xx -> class of the Message (Authorization Message) xx1x -> function of the Message (Request Response) xxx0 -> who began the communication (Acquirer) 2.4.1 ISO 8583 version Position one of the MTI specifies the versions of the ISO 8583 standard which is being used to transmit the message. Table 2.3: ISO 8583 version Position Meaning 0xxx ISO 8583-1:1987 version 1xxx ISO 8583-2:1993 version 2xxx ISO 8583-3:2003 version 3xxx Reserved for ISO use 4xxx Reserved for ISO use 5xxx Reserved for ISO use 6xxx Reserved for ISO use 7xxx Reserved for ISO use 8xxx Reserved for National use 9xxx Reserved for Private use

27. 19 2.4.2 Message class Position two of the MTI specifies the overall purpose of the message. Position Meaning Usage x1xx Authorization Message Determine if funds are available, get an approval but do not post to account for reconciliation, Dual Message System (DMS), awaits file exchange for posting to account x2xx Financial Messages Determine if funds are available, get an approval and post directly to the account, Single Message System (SMS), no file exchange after this x3xx File Actions Message Used for hot-card, TMS and other exchanges x4xx Reversal and Chargeback Messages Reversal (x4x0 or x4x1):Reverses the action of a previous authorization. Chargeback (x4x2 or x4x3): Charges back a previously cleared financial message. x5xx Reconciliation Message Transmits settlement information message x6xx Administrative Message Transmits administrative advice. Often used for failure messages (e.g. message reject or failure to apply) x7xx Fee Collection Messages x8xx Network Management Message Used for secure key exchange, logon, echo test and other network functions x9xx Reserved by ISO Table 2.4: ISO 8583 Message class

28. 20 2.4.3 Message function Position three of the MTI specifies the message function which defines how the message should flow within the system. Requests are end- to-end messages (e.g., from acquirer to issuer and back with timeouts and automatic reversals in place), while advices are point-to-point messages (e.g., from terminal to acquirer, from acquirer to network, from network to issuer, with transmission guaranteed over each link, but not necessarily immediately). Position Meaning xx0x Request xx1x Request Response xx2x Advice xx3x Advice Response xx4x Notification xx5x Notification Acknowledgement xx6x Instruction (ISO 8583:2003 only) xx7x Instruction Acknowledgement (ISO 8583:2003 only) xx8x Reserved for ISO use. (Some implementations use for Response acknowledgment) xx9x Reserved for ISO use. (Some implementations use for Negative acknowledgment) Table 2.5: ISO 8583 Message function

29. 21 2.4.4 Message origin Position four of the MTI defines the location of the message source within the payment chain. Position Meaning xxx0 Acquirer xxx1 Acquirer Repeat xxx2 Issuer xxx3 Issuer Repeat xxx4 Other xxx5 Other Repeat Table 2.6: ISO 8583 Message origin

30. 22 Chapter 3 Working Principle of ATM/POS Machine 3.1 ATM/POS to ATM/POS Switch ATM/POS machine Request messages which contain the data that Central requires in order to authorize a cardholder transaction at the terminal. The message is sent during a cardholder transaction, either on entry to the Transaction Request state or as part of an Interactive Transaction message sequence. Figure 3.1: Working flow of ATM/POS to ATM/POS Switch When the Transaction Request message is sent in reply to an Interactive Transaction Response, it differs from the previous description in that it consists only of the following fields. b - Message Class c - Message Sub-Class Field Separator d - Logical Unit Number 2 Field Separators

31. 23 e - Time Variant Number Field Separator f - Top of Receipt Transaction Flag g - Message Co-Ordination Number 6 Field Separators 3.2 ATM/POS Switch to ATM/POS: The terminal (ATM/POS Machine) responds to a command from Central by sending a solicited status message. The information in the status message depends on the Command received, and whether or not the terminal can perform the instruction. Following things are performed when ATM/POS is initialized. a) Key Download (For Encryption and Decryption) b) Configuration Download 1. State download (Which state will go after pressing button in ATM machine) 2. Screen download (Which screen will show in ATM machine when certain button is pressed) 3. Financial Institution Tables (FIT) download (FIT contains all types of Related data) c) Timer (Timer is used for control each process like waiting time, Transaction time ,Card store time etc) The following fields in the status message contain this information: Figure 3.2: Working flow of ATM/POS Switch to ATM/POS

32. 24 3.2.1 Status Descriptor Field The status descriptor field identifies which of the following conditions is being reported:  Ready : The command has been performed successfully  Device Fault : A device fault has occurred  Command Reject/Specific Command Reject : The command has been rejected  Terminal State : The values of supply counters or terminal 3.2.2 Status Information Field: The status information field contains additional information when a Device Fault, Specific Command Reject or Terminal State descriptor is used. Additional information is contained in the Status Information field when the following status descriptors are used:  ‘C’ - Specific Command Reject  ‘F’ - Terminal State  ‘8’ - Device Fault. 3.3 ATM/POS Switch to CBS: ATM/POS Switch sends data to Core Banking System for various purpose. Before sending data there is an extra module called HSM (Hardware security module). This is used for encryption and decryption of data. Most Banks used 512bit encryption. Each Banks uses its own method to send data from switching server to CBS. They can use their own protocol but it is convention to use ISO 8583.they can change some of fields of ISO 8583.

33. 25 Following fields are switching validator. These fields are sent from switch to Core banking system for checking:  Card Number  Status of Card(Cold,Hot,Warm)  Expired Date  Linked Account Number with card  Pin Validation Number Figure 3.3: Working flow of ATM/POS Switch to CBS 3.4 CBS to ATM/POS Switch: After checking Information of Users CBS sends message to ATM/POS Switching server. From this message switching software decides to go which states, or decide what to do now.CBS has all the data need for any users. It contains all core things of banks.

34. 26 Figure 3.4: Working flow of CBS to ATM/POS Switch

35. 27 Chapter 4 Analysis of ATM/POS Implementation 4.1 Survey in Bank: For studying on ATM/POS Switching Software we have to Survey in Banks. We visited IT Branch of 2 Important bank of Bangladesh. a. Islami Bank Bangladesh (Motijheel) b. Pubali Bank Bangladesh (Motijheel) 4.2 Questionary for Survey: We made questionary for Surveying in banks. Our main target was to know whether we are able to implement switching software in Bangladesh. So our questionary pattern was on how we can implement Switching Software with our own resource, how many coder needs to implement, Number of tester, Performance analysis etc. Our questionary was: 1. Is it possible to implement Switching Software In Bangladesh? a) Possible b) Possible but Time Consuming c) Possible but its not helpful d) Not possible 2. For implementing Switching software Engineer should be trained from abroad. So still it is suitable to implement in Bangladesh?

36. 28 a) Yes b) Yes But it is costly c) yes but it is time consuming d) No 3. If switching software is making from scratch (Beginning) in Bangladesh then for maturity it needs following time: a) 1-2 years b) 2-4 years c) 4-5 years d) 5-10 years 4. Security problem will be happen if switching software is developed by Bangladeshi Engineers. Is It right? a) Yes b) Yes but it can be Resolved by Government steps c) Yes so 3Rd party Vendor should be come d) No 5. Initially merging of our produced Switching Software and imported ATM/POS machine will be a problem? a) Yes it will be a problem b) Yes but it can be solved by using different interface c) Trial and Error will be good choice for this problem d) No its not possible to merging 6. Time needs for implementing switching software which will serve for just own bank? a) 3-4 months b) 6-7 months c) 9-10 months d) 12-15 months 7. Time needs for implementing switching software which will serve among all banks ?

37. 29 a) 3-4 months b) 6-7 months c) 9-10 months d) 12-15 months 8. Time needs for implementing switching software which will serve Master Card and Visa Card Service ? a) 3-4 months b) 6-7 months c) 9-10 months d) 12-15 months 4.3 Conclusion for the Survey: From our surveying we found that, 61 percent IT expert says Yes it is possible to implement Switching software In Bangladesh , 23 percent IT expert says yes but its time consuming, 10 percent Says yes but it won’t be helpful to implement in Bangladesh and 6 percent says it’s not possible to implement in Bangladesh.

38. 30 Chapter 5 Guideline to implement ATM/POS Interface 5.1 Architecture of Interface Software: Advance NDC software system is made up of two parts, as follows: a) Terminal application b) Central application. Terminal Application: The terminal application gathers transaction details from the cardholder and sends these details in a Transaction Request message to Central. When the terminal receives a Transaction Reply command from Central, it completes the transaction. The terminal application responds to Terminal commands from Central, such as Go-In-Service or Go-Out-Of- Service, and requests for information by sending Solicited Status messages to Central. Central Application: The Central application receives Transaction Request messages from the terminal, and determines whether the transaction should be approved or declined. It controls the terminal by sending Terminal commands to it and acting on responses received. The Central application must be able to decode and act on the messages it receives from the terminal. The Central application must also be able to code messages in the form that the Advance NDC software in the terminal understands. 5.1.1 How the terminal operates: When the terminal is switched on, after loading it with the Advance NDC terminal software, a power-up message is sent to Central. Central downloads any necessary data to the terminal in a series of messages. After each message is sent, the terminal sends an acknowledgement to Central. When Central has sent all the download data successfully, it will put the

39. 31 terminal in service. When the terminal processes a transaction, it gathers the details from the cardholder and card, and sends the information in a Transaction Request message to Central. Central sends a Reply command, and the terminal completes the transaction. If a fault occurs, the terminal sends a message to Central and waits for a further Transaction Reply command before completing the transaction. Once the transaction has been completed successfully, the terminal sends a message to Central to confirm it. 5.1.2 Creating an Advance NDC System: There are two distinct tasks involved: a) Creating the customisation data b) Creating the Central control application. 5.1.2.1 Customization Data: The customisation data consists of the following: Components Function State Tables These contain the sequence of states that determine how the terminal processes transactions Screens These are displayed while the cardholder is using the terminal. Printed Screens These are printed while the cardholder is using the terminal. Supervisor Messages These are the supervisor messages that are output to the cardholder screen, the enhanced operator panel, and the receipt and journal printers. Configuration Parameters These are local configuration parameters such as Amount Buffer size, card reader/writer error thresholds, and timers.

40. 32 Financial Institution Tables (FITs) These define which institutions the terminal supports. For each institution, the table defines whether PIN verification is local or remote, the type of data encryption, and the position of details on the card. Table 5.1: Components of Customization Data 5.1.2.2 Creating the Central Control Application: The Central control application uses the following commands and messages: Terminal Commands: These send instructions to the terminal. Transaction Reply Commands: These are sent in response to a Transaction Request message from the terminal. They tell the terminal how to complete the transaction. Customisation Data Commands: These download customisation data to the terminal. Interactive Transaction Response: This option allows you to send a message to the terminal to prompt the cardholder for more information.

41. 33 5.1.3 Detailed Description of the components: 5.1.3.1 State Tables: States control the information-gathering part of cardholder transactions. A state table is made up of :  state number  state type  table data (a screen number, next state number) The terminal performs the action specified by the state type, and the transaction flow continues from the specified next state. If the next state specified is invalid or undefined, the transaction flow continues from a default Close state. When the default Close state is executed, it completes the cardholder transaction by delivering a receipt or statement, and delivering or capturing the card, as specified. Customising States: We customize a state by assigning values to its parameters. To build a state flow, you select different state types and place them in the application flow by linking the states together—one state references another with one or more of its parameters or entries. When we have finished customising the state tables, Central downloads the information to the terminal in Customisation Data commands.

42. 34 Standard state types: The following table lists each of the supported standard state types that control transaction processing: State Table Type Description Function A Card Read 1. It is the first table used during transaction processing. 2. Displays the screen that you have selected to prompt the cardholder to enter a card. 3. Displays the error screen that you have selected if the card cannot be read. 4. Sets the Media Entry Indicator flashing while the card reader is waiting for the cardholder to enter a card. The indicator is switched off when the card is entered. 5. The next state number the terminal goes to if the card is read successfully. 6. The next state number the terminal goes to if the FIT number on the card does not match the number in any FIT. 7. The next state number the terminal goes to if the card is a smart card, and the read condition being evaluated has the chip connects bit set. B PIN Entry 1. The terminal should not enter this state unless the Financial Institution number on the card matches a Financial Institution number in a FIT during the Card Read State. 2. When specified in the FIT, PIN verification can take place at either the terminal or Central. 3. If verified at Central, you can transmit the PIN either in an encrypted form or as clear text. C Envelope Dispenser 1. If the state is entered on a terminal without the dispenser, it performs no action and takes the next state exit immediately. 2. On a terminal with an envelope dispenser, an

43. 35 envelope is presented before the exit is taken. 3. If the envelope is not taken by the cardholder, it is retracted when the terminal enters the Close state. D Pre-Set Operation Code Buffer This state will either clear the Operation Code buffer by filling selected bytes (to a maximum of eight) with the graphic character ‗space‘, or it will pre-set the buffer with graphic characters ‗A‘, ‗B‘, ‗C‘, ‗D‘, ‗F‘, ‗G‘, ‗H‘ or ‗I‘. These characters correspond to the eight Function Display Keys. E Four FDK Selection Function 1. This state reads which one of the four Function Display Keys (FDKs) to the right of the cardholder screen (‗A‘, ‗B‘, ‗C‘ or ‗D‘) has been selected by the cardholder. 2. If the cardholder selects one of these keys, the key code for that function is stored in the Operation Code buffer as key ‗A‘ to ‗D‘. The transaction then goes to the next state. F Amount Entry 1. This state reads the amount entered by the cardholder, displays it on the cardholder screen, and saves it in the Amount buffer. 2. The terminal exits from the Amount Entry state once the cardholder presses an active FDK or the Cancel key. 3. It also exits from this state if the cardholder does not press a key within the specified time limit. G Amount Check This state checks whether the amount entered can be dispensed. This does not check for coins. Two checks are performed: Whether the amount held within a specified buffer is a multiple of an identified value. Whether the amount held within a specified buffer is dispensable when taking into account the currency required, denominations available, dispenser status and cassette status. Note counts are ignored. H Information Entry 1. When the cardholder enters numeric data at the keyboard, this state reads in the data and saves it in one of two general-purpose buffers.

44. 36 2. You specify in table entry which buffer is to be used, and whether the actual data the cardholder enters is displayed on screen. 3. The terminal exits from this state once the cardholder presses an active FDK or the Cancel key. 4. It also exits from this state if the cardholder does not press a key within the specified time limit. I Transaction Request 1. This state sends a Transaction Request message to Central, and executes the Transaction Reply command received from Central. 2. The information that is to be included in the Transaction Request message is defined in this state table. J Close 1. This state terminates the cardholder‘s current terminal session. 2. All document data is flushed from the system when this state is executed. K FIT Switch Expanded FIT Switch 1. Each FIT contains a next state index number. 2. This index number refers to the next state number that the terminal goes to when it exits from the FIT Switch state, if the Financial Institution number on the card matches a Financial Institution number in a FIT. 3. The FIT Switch state table contains a list of these next state numbers, together with an index which matches the index numbers of the FITs. 4. Each FIT designates a next state according to the member institution to which it applies. Expended FIT Switch state table is a list of these states and contains indexing data referenced in the FIT for selecting the appropriate next state. L Card Write 1. During the Card Write state, the terminal writes the contents of the Track data buffers onto the magnetic stripe of the card. 2. You specify which screen is to be displayed on the cardholder screen while writing takes place. 3. Writing only takes place if the Track data buffers contain data obtained from a successful

45. 37 Track 3 read during a Card Read state or updated Track data from a Transaction Reply command. M Enhanced PIN Entry 1. This state performs the same functions as the PIN Entry state. 2. It also supports Track 3 retries if the FIT specifies local PIN check and indicates that there is a Track 3 retry field on the card. 3. If the FIT specifies Track 3 retries but there is no data in the Track 3 buffer, the Cancel Next State exit is taken. R Enhanced Amount Entry 1. Use this state if you wish to use multi-language screens for enhanced amount entry. 2. This state reads the amount entered by the cardholder, displays it on the cardholder screen, and saves it in the buffers specified by the state table. 3. Exit from the Enhanced Amount Entry state occurs when an active FDK is pressed, the Cancel key is pressed or a time-out occurs. S Language Code Switch In this state, the flow of a transaction is switched depending on whether a language code is present in the card data or not. T Card Read - PIN Entry Initiation 1. You can use this state instead of the Card Read state, if you want to initiate PIN entry by the cardholder at the same time as the terminal reads the card. 2. If you use the Card Read State table, ensure it is the first table used during transaction processing by assigning state number 000 to it. The terminal automatically enters state 000 when put into service. 3. This state performs the same functions as the Card Read state. V Language Select From Card 1. In this state you can use one set of state tables to display screens in different languages within the same transaction. 2. This is determined by a code on the cardholder‘s card. The code is a one-character field and is located using the Language Code Index parameter (PLNDX) in the FIT.

46. 38 W FDK Switch Data is placed in the FDK buffer during the Eight FDK Selection Function state or the FDK Information Entry state. This data is read by the FDK Switch state in order to identify which next state the terminal should go to. X FDK Information Entry This state translates the FDK selected by the cardholder into a value that is placed in the specified buffer .The FDK key code is stored in the FDK buffer for use by an FDK Switch state. Y Eight FDK Selection Function This state reads the FDK selected by the cardholder, stores the key code in an FDK buffer for use by an FDK Switch state, and updates the Operation Code buffer. Z Extension State - B Customer Selectable PIN State This state allows the cardholder to input a new PIN. It differs from the PIN entry state in the number of retries. The state will prompt for the new PIN twice and will take a good exit if both are the same and the terminal checking feature is enabled. d…g Available as identifiers for Exit States State identification letters d to g are reserved for Exit States K Smart FIT Check State 1. This state is required when chip data is to be used in a FIT check. 2.The Smart FIT Check state is designed to be entered from your own C-Exit state 3. It is possible to create more than one Smart FIT Check state to accommodate multiple FIT checks. This would allow different FIT checks to be performed on data from the same card. m PIN & Language Select State This state performs the same functions as the PIN Entry state (state 'B' or 'M') combined with the functionality of the Eight FDK Selection Function State (state 'Y'). This state allows language selection from an FDK following the PIN entry. All the functionality and conditions of PIN Entry and Eight FDK Selection states apply to this state > Cash Accept Under state table control, the Cash Accept State:

47. 39 State 1. Accepts a bunch of notes into the escrow Identifies the notes 2. Checks the note type and denomination are active, that is accepted by Central 3. Returns invalid notes to the cardholder 4. Refunds requested notes, or if there are more notes than the escrow capacity 5. Retracts returned notes not taken W Cheque Accept State Under state table control, the Cheque Accept State: 1. Accepts cheques 2. Returns physically unacceptable cheques 3. Returns incorrectly orientated cheques 4. Lifts full front and/or rear images 5. Reads the codeline, for Central authorisation 6. Captures ejected cheques that are not taken 7. Reports unsolicited events. & Barcode Reader State 1.The Barcode Read State allows an application to read a barcode. 2. When this state is entered, the screen identified by table entry 1 is displayed and the barcode reader is enabled Table 5.2: Different State Types Time Out States: In addition to the above states, the terminal has a fixed Time-Out state. This is entered under one of the following conditions:  Timer 00 expires on a Keyboard Entry state  Timer 04 expires during a Deposit transaction (envelope not inserted)  Timer 08 expires during a Night Safe Deposit transaction  Timer 61 expires during a barcode reader scan

48. 40  Screen timer from Interactive Transaction Response message expires when numeric keypad or FDKs are active  The cardholder fails to remove an envelope or a cheque within the period specified by timer 94  The cardholder fails to enter notes in a Cash Accept State before timer 77 expires  The cardholder fails to remove returned notes from a BNA or GBXX without the retract option set before timer 78 expires. State Numbers: Alphanumeric (base 36) numbers in state table entries are supported as well as decimal (base 10). Using alphanumeric data provides support for up to 46655 state numbers, without changing the table entry length. Decimal based data providers support 999 state numbers. Decimal numbers are in the range ‗000‘ to ‗999‘. Alphanumeric numbers are in the range ‗000‘ to ‗ZZZ‘. The value ‗255‘ is always reserved unless stated otherwise in the table entry. 5.1.3.2 Screen Interface: A screen is a string of characters, including control characters, that defines what is to be displayed and where to display it (cardholder screen, operator panel or printer). There are two types of screen:  Customer screens—defined by the user  Reserved screens—already defined within the terminal software.

49. 41 The programmatic screen layout for cardholder screen and operator panel is as follows: Figure 5.1: Screen Layout Customer Screens: A customer screen is a screen that you create.The data is downloaded to the terminal in a screen data load message.All the screens that are accessed by the state tables are stored in the Screen Table. Each screen in the table has a unique number from 0000 to 9999. It is this number that is referenced by parameters in the state tables during transaction processing. Two customer screen groups are used, as follows:  Screen group ‗u‘ for language-independent screen numbers  Screen group 'l' for language-dependent screen numbers Reserved Screens: A reserved screen is a screen that is already defined within the terminal software. Reserved screens have fixed functions, such as displaying Supervisor prompts and menus, and are only displayed at

50. 42 predefined times, such as when the terminal is in Out-of-Service or Off- Line mode. Some reserved screens consist of control sequences and are used to manage different aspects of the display, for example, character sets and logos. 5.1.3.3 Printer Data: The Advance NDC SST software supports printing on the following devices:  Receipt (SDC, RS232, USB)  Journal (SDC, RS232, USB)  Statement (SDC, Parallel)  Programmable Printing Depository (PPD) (SDC, USB)  CPM endorse cheque The data to be printed on a particular printer, or printers, must be placed in a printer data field contained in a Transaction Reply Command message. The length of the printer data field is variable, and depends on the amount of data and data compression performed , the printer characteristics, and the overall message length limitation. There are 13 printer data fields. 5.1.3.4 Supervisor Messages: Formatting rules apply to the following: Character Sets: All display/print characters are obtained from the Single Size Alphanumeric 1 character set.

51. 43 Control Codes: The following control codes are supported:  CR - causes the next character to be displayed at the beginning of the next line. CR must appear on each line  SO - the same as printer control (multiple spaces). Screen Size Limitations: Screen Type Usage No. Of Rows No. Of Columns ‗A‘ Cardholder/Enhanced Operator Interface Acknowledgement Lines 1 32 ‗E/e‘ Error Messages 1 32 ‗I‘ Cardholder/Enhanced Operator Interface/Printer Information Output 14 32 ‗M/m‘ Cardholder/Enhanced Operator Interface/ Printer Menus 13 32 ‗P/p‘ Cardholder/Enhanced Operator Interface Data Entry Prompts 1 27 ‗S/s‘ Media Status Lines 1 32 ‗T/t‘ Journal Trace 15 32 ‗i‘ Supervisor TCP/IP Screens 15 32 ‗i‘ Supervisor Bunch Note Acceptor (BNA) Screens 14 32 ‗i‘ Supervisor VISA 2 screens 15 32 Table 5.3: Limitations of screen size

52. 44 Cardholder Screen /Enhanced Operator Interface Layout: If Supervisor functions are selected from the fascia keyboard or the enhanced operator interface, all screens are displayed from the leftmost column. Printer Layout: All printing of reserved screens starts at column 6 and extends as far as column 37. The fixed format security trace header starts at column 1. Automatic Screen Editing: Certain reserved screens are edited by the terminal prior to display or print in order to include information held by the terminal. These screens contain a percent (%) character as a placeholder to indicate the start location of the generated data. Media Status Messages: The Media Status message is built by the terminal from the Media Status header (screen ‗I05‘) and Media Status lines (‗S‘ or ‗s‘ screens). Screen ‗I05‘ is overlaid from line 3 onwards with Media Status lines. If a media exception condition exists, the appropriate message is displayed. Otherwise, nothing is displayed. Test Cash Report: This report is built by the terminal from the Cash Test Header (screen ‗I07‘) and Cassette Operational lines (screens ‗S15‘ - ‗S18‘). Screen ‗I07‘ is overlaid from line 3 onwards with Cassette Operational lines. If a cassette is operational, for example, a note has been successfully picked and purged, the appropriate line is displayed. If it is not operational, nothing is displayed.

53. 45 5.1.3.5 Configuration Parameters This message contains the parameters used in NDC+ for Diebold emulation. Supply Mode, Ready Status & Amount Buffer Length (Field ‘m’): This single parameter is used to set three configuration options and the value to be downloaded is formed by adding the values for the three options together. The values for the three options are as follows : Value Description 000 No option selected 001 Ready Status Send a separate Ready (‗B‘) status message to Central in response to a Transaction Reply message 002 Supply Mode Return the SST automatically to the previous mode when it leaves Supply mode 008 Amount Buffer Length Set the amount buffer length to twelve digits. The default is eight digits Table 5.4: Value of three configuration options Configuration Parameters Load Message Logical Unit Number – LUNO (Field ‘o’) This parameter determines whether the logical unit number, LUNO, will be transmitted in Transaction Request, Solicited and Unsolicited Status messages.

54. 46 Timer Number (Field ‘p’) This parameter sets the time-out value for each of the timers that the SST application uses. The timers available are the same for both configuration load and enhanced configuration load. Number of 800 Millisecond Ticks per Timer Field (Field ‘q’) This parameter sets the time-out intervals for the timers in 800 millisecond ticks. The number of ticks can be 000-255. This provides a time-out range of up to 204 seconds. Unsupported Parameters The following parameters are not supported in Advance NDC but are reserved in the message:  Camera Control (Field ‗h‘)  Card Read Error Threshold (Field ‗i‘)  Card Write Error Threshold (Field ‗l‘) Reserved Parameters The following parameters are reserved for future use:  Field ‗j‘  Field ‗k‘  Field ‗n‘ The Enhanced Configuration Parameters Load message The following parameters are common to both Configuration Parameters Load and Enhanced Configuration Parameters Load message formats, and have the same values:  Supply Mode, Ready Status and Amount Buffer Length  Logical Unit Number – LUNO  Timer Number

55. 47 Most enhanced configuration parameters are defined by an option number in field ‗i‘ of the message, with field ‗j‘ holding the option code. This section describes the options and codes: Options/Codes Description Function Option 02 Auto Voice If the SST is fitted with an automatic voice feature, this parameter sets auto voice on or off Option 03 Date Format This parameter sets the date format to either MMDDYY or DDMMYY Option 04 Roll Width This parameter defines the number of columns used in receipt and journal print screens in messages sent from Central. An automatic new line occurs if this limit is exceeded. Option 05 Left Print Column This parameter defines the leftmost column used in receipt and journal print screens in messages from Central. Options/Codes Description Function Option 07 Track 1 Format This parameter sets the method of extracting the name and title from Track 1 data on the card Option 12 Specific Command Reject This parameter determines whether the SST transmits Specific Command Reject options. Option 15 Transaction Status Information This parameter determines whether the transaction status information from the last command is appended to Transaction Request messages. Option 16 Journal Printer Backup Time This parameter sets the maximum time in hours that journal printer backup is allowed before all journaling is discontinued. It is not supported when dual mode

56. 48 journal printing is active. Option 17 Journal Printer Backup Print Operations This parameter sets the maximum number of print operations (in hundreds) to be buffered while the journal printer is fatal. It is not supported when dual-mode journal printing is active. Option 23 Envelope Dispenser Status This option determines whether envelope dispenser status messages are sent, remote status indicators are set, and the remote relay is activated. Option 24 Enhanced/TI Sensor Status Unsolicited Message This option determines whether the Enhanced TI/Sensor Status unsolicited message is sent from the SST when tampering is suspected on devices not supported in the existing TI/Sensor Status unsolicited message. Option 25 Media Entry/Exit Indicators Flash Rate This parameter sets the flash rate for the Media Entry/Exit Indicators. The flash rate can range from 4.0 Hz to continuously. Option 27 Remote Relay This parameter determines when the remote relay is active. Option 33 Simulate Supervisor Mode Entry/Exit This option simulates Supervisor mode entry/exit after safe door activity. Option 34 MCN Range This option controls the range of the Message Coordination Number (MCN) and extends it. Option 35 Report Dual Mode EJ & Hardcopy B/U Unsolicited Messages This option controls the reporting to Central of unsolicited device status messages for dual mode EJ and hardcopy backup. Option 36 Enhanced EJ Backup This option determines whether multiple or standard EJ backups

57. 49 are allowed. Option 37 Print Track 2 to Journal This option determines whether the first 22 characters of data from card track 2 are automatically journalled when a card is read. Option 44 BNA Journal Vaulted Notes Count If the Bunch Note Acceptor (BNA) is present, this option determines whether vaulted note counts are automatically printed to the journal printer following a transaction reply. Option 45 BNA Message Settings Inclusion of BNA last transaction status counts in the Transaction Request message sent to Central Note reporting configuration Retract option configuration Extended message format option. Option 46 MCRW Enhanced Card Device Security Jitter If the Enhanced Card Device (ECD) is present, this parameter sets the level of ECD Jitter to be applied during card entry/exit Option 48 Barcode Reader If the barcode reader is present, this option defines whether the barcode reader-specific fields are included in the messages sent to the host. Option 69 EMV Smart Card Extended Status This option is reserved for use with EMV Exits. Option 70 EMV Smart Card If an EMV Smart Card Reader/Writer is present, this option enables EMV smart cards to be accepted. Option 76 Cash Handlers This option specifies the cassette type support and message format. Option 77 Next State Number This option determines whether cardless transactions are permitted and sets the state

58. 50 number to go to from the initial Card Read state for consumer cardless transactions. Option 78 GBRU MStatus Reporting This option controls the reporting of the M-Status for a GBRU used as a dispenser Option 79 Coin Dispenser This option allows the modification of the message format to support up to eight coin hopper types. Option 80 Alphanumeric State Entry This option controls which number system is used to interpret state number fields. Option 83 Cheque Processing Module This option allows the modification of the message format to support the reporting of bins in the CPM. Table 5.5: Option and codes of enhanced configuration parameters Number of Seconds per Timer Field – Field ‘l’ This parameter sets the time-out value in seconds for the timer number specified in field ‗k‘. The maximum number of seconds is 255. There are some unsupported parameters too. Timers The same timers are available in both configuration load messages and enhanced configuration load messages. There are different timers described as follows: Timers Description Timer 00 Cardholder keyboard response time. Timer 01 Cardholder time-out response. Timer 02 Close state or eject failure cardholder screen display time- out interval. Timer 03 Communication message time-out interval.

59. 51 Timer 04 Cheque/envelope insertion response time-out. Timer 05 Cash retract time-out. Timer 06 Communications connection sample interval Timer 07 Present time-out Timer 08 Night safe deposit time-out Timer 09 Cardholder time-out interval before card capture attempt Timer 10 Additional present time-out. Timer 61 Barcode reader scan timer Timer 68 Statement MEI duration timer Timer 69 Receipt MEI duration timer. Timer 72 DASH card eject timer Timer 77 BNA/GBXX cash acceptance timer Timer 78 GBXX cash rejection timer Timer 87 Cheque Capture screen time-out Timer 92 Fault display time-out Timer 94 Cheque/envelope removal response time Timer 95 Statement retract time-out Timer 96 Statement present time-out Table 5.6: Different type Timers 5.1.3.6 Financial Institution Tables The Financial Institution Table (FIT) is an important part of the customisation data. FITs may also be downloaded to the terminal by a message from Central. The FIT contains specific information about how a particular institution‘s transactions should be processed.Every institution the terminal supports must have a FIT. Institutions which have more than one type of card must have a FIT for each card type.When a card is read, the FIT is searched to find the FIT entry which matches the Financial Institution Identification number (FIID) on the card. Parameters in this FIT entry and following linked FITs are then used for all subsequent PIN processing.

60. 52 FIT Data Each FIT contains the fields described here, and each field defaults to zero if not specified. Some fields hold information on how transactions will be processed for that institution. Other fields contain an offset to where information required for transaction processing is stored on the card. Field Contents Acronym Definition No of Digits Offset a Institution ID Index PIDDX Index for Financial Institution ID number on card 2 Yes b Institution ID PFIID Financial Institution ID number 10 No c Indirect next state index PSTDX Index for entries in the Indirect next state table 2 No d Algorithm/ Bank ID index PAGDX Algorithm index for Diebold Not supported by Advance NDC as Local Diebold PIN verification is not supported. 2 Yes e Maximum PIN digits entered PMXPN Maximum number of PIN digits allowed for the cardholder to enter 2 No f Maximum PIN digits checked PCKLN Number of digits used for local PIN check 2 No g PIN pad PINPD Character used to pad PIN for transmission to Central and the encryption method used 2 No h PAN data index PANDX Index for location of PAN (Personal 2 Yes

61. 53 Account Number) on card i PAN data length PANLN PAN data field length 2 No j PAN pad PANPD Character used to pad PAN field for encryption 2 No k Track 3 PIN retry count index PRCNT Index for PIN retry count field on card 2 Yes l PIN offset index POFDX Index for PIN offset field on card 2 Yes m Decimalisation table PDCTB Decimalisation table used in encryption process 16 No n Encrypted PIN key PEKEY DES - Encrypted PIN key 16 No o Index reference point PINDX Track and index reference point information for all card-related entries in FIT 6 Yes p Language code index PLNDX Index for language code on card 2 Yes q CIM86 sensor flag PMMSR Flag to identify the location of the CIM86 sensor in the FIT Not supported by Advance NDC 2 No r Reserved - - 6 No s PIN Block format PBFMT Selects PIN block format for remote PIN verification 2 No Table 5.7: Contents of FIT Data

62. 54 Linked FITS Data relating to PIN verification can appear in different locations, depending on the type of card used. For this reason, if a financial institution allows more than one position to be used, the customisation data must include one FIT for each variation. These FITs are referred to as linked FITs. A linked FIT is identified by the following FIT entries:  PIDDX  PFIID  The PIN verification algorithm bits in PCKLN  The track designator parameters of PINDX. You must ensure that these entries are identical to the corresponding entries in the base FIT, and that the base FIT and associated linked FITs have consecutive FIT numbers. The following FIT entries are used for local PIN verification:  PCKLN  PANDX  PANLN  PANPD  POFDX  PDCTB  PEKEY  PRCNT - only valid in the base FIT  The index reference points in PINDX.

63. 55 5.1.3.7 Terminal to Central Messages Transaction Request Messages Transaction Request messages contain the data that Central requires in order to authorize a cardholder transaction at the terminal. The message is sent during a cardholder transaction, either on entry to the Transaction Request state or as part of an Interactive Transaction message sequence. Solicited Status Messages Content of Solicited Status Messages: The terminal responds to a command from Central by sending a solicited status message. The information in the status message depends on the command received, and whether or not the terminal can perform the instruction. The following fields in the status message contain this information:  Status Descriptor  Status Information Status Descriptor Field The status descriptor field identifies which of the following conditions is being reported:  Ready. The command has been performed successfully  Device Fault. A device fault has occurred  Command Reject/Specific Command Reject. The command has been rejected  Terminal State. The values of supply counters or terminal configuration are included in the message.

64. 56 Status Information Field The status information field contains additional information when a Device Fault, Specific Command Reject or Terminal State descriptor is used. Status Information Additional information is contained in the Status Information field when the following status descriptors are used:  ‗C‘ - Specific Command Reject  ‗F‘ - Terminal State  ‗8‘ - Device Fault. Solicited Device Fault Status All solicited status device fault messages require Central to reply with a Transaction Reply command. The cash handler and depository devices are used only in response to a Transaction Reply (TR) command, and only give unsolicited statuses during Transaction Reply processing. The first character in the Status Information field identifies the device by means of a Device Identification Graphic (DIG). Devices are identified by the same code in Solicited and Unsolicited messages. Device Fault Status Responses The following table shows the solicited device fault status messages which may be returned for each Transaction Reply command. Transaction Reply Command Device Faults Deposit and Print Depository Dispense and Print Cash Handler, Coin Dispenser Print Immediate None Set Next State and Print None Night Safe Deposit and Print None Card Before Cash Card Reader/Writer, Cash Handler, Coin Dispenser Fast Cash Cash Handler, Coin Dispenser Card Before Parallel Dispense and Print Card Reader/Writer, Cash Handler, Coin Dispenser Print Statement and Wait Statement Printer and Receipt in

65. 57 sideways mode Print Statement and Set Next State Statement Printer and Receipt in sideways mode Refund Bunch Note Acceptor Encash Bunch Note Acceptor Process Cheque Cheque Processing Module Figure 5.8: Solicited device fault status messages Device Fault Status Information Field: Field Number of Characters Descriptions g1 1 Device Identification Graphic g2 Var(17) Transaction Status. Contains information required to make a transaction completion decision. FS 1 Field Separator g3 Var(14) Error Severity. Contains information required to decide whether to shut down or continue to use the SST FS 1 Field Separator g4 Var Diagnostic Status. Used for logging errors. The field length may be omitted if there is no error condition to be reported. The field will always be present if preceded by an Error Severity field with a value of 1 or greater. FS 1 Field Separator. g5 Var(8) Supplies Status. Contains information about the state of supplies (paper, currency, magnetic cards, envelopes, inkwells, documents) in the terminal. This field contains 1 character for each supplies container managed by the device. Table 5.9: Device Fault Status Information Field

66. 58 Other Solicited Messages Other solicited messages that can be sent from the terminal to Central are as follows:  EncryptorInitialisation Data  Upload EJ Data Message Unsolicited Status Messages Unsolicited Status messages are used to report any change of condition at the terminal. These include:  Recognition of an external event  Device errors  Supplies problems. Unsolicited status messages do not require a reply from Central. They are sent under the following conditions:  Power failure: a message is sent on power-up  An external event is detected. This includes bin inserted/ removed, alarm activated, supervisor keys and switches. The reporting of supervisor switch changes is delayed if a card is inserted  A device fault is detected as a result of processing a Transaction Reply command, but the fault condition does not require Central recovery action. This means that Transaction Reply processing can continue as if no fault had occurred.  A device fault is detected which is not the result of processing a Transaction Reply command.  If an alarm is activated during a power failure or communications loss, a message is sent when power or communications are restored  If supervisor/supply switch values are changed while off-line, the last change of both switches is reported when communications are restored

67. 59  If the message mode option is set to enable the Cancel key while a Statement and Wait function is being carried out and the cardholder presses the Cancel key.  Errors in the Close state. Unsolicited Status: Message Format Field Number of characters Descriptions a Var Header. Protocol-dependent. b 1 Message Class c 1 Message Sub-Class FS 1 Field Separator d 3 or 9 Logical Unit Number (LUNO). This number is defined in a field transmitted to the terminal in a Configuration Parameters Load message. The default is 000. If the data security feature is configured, an additional six characters are present. These contain the security terminal number FS 1 Field Separator FS 1 Field Separator e Var Status Information. The content of this field varies according to the message mode selected at installation time f Var Trailer. Protocol-dependent. Table 5.10: Unsolicited Message Format Unsolicited Status Information Field One of the following conditions must be satisfied before an unsolicited message is sent:

68. 60  Device status is non-zero  Error severity is 2 (warning) or greater  Supplies status is 2, 3, or 4. A routine error does not generate an unsolicited status message. The following table shows the structure of the Status Information field in unsolicited status messages: Field Number of Characters Descriptions e1 1 Device Identification Graphic. e2 Var (154 max) Device Status. Used for recording any transaction exception of change of state of the device. For devices which report both Solicited and Unsolicited Status messages, a common set of Transaction/ Device Status codes are defined for use in either type of message. FS 1 Field Separator e3 Var (14) Error Severity. As ‗g3‘ in Solicited messages. FS 1 Field Separator e4 Var Diagnostic Status. As ‗g4‘ in Solicited messages. FS 1 Field Separator e5 Var (8) Supplies Status. As ‗g5‘ in Solicited messages. Table 5.11: Status Information Field in Unsolicited message

69. 61 Device Status Information Solicited or unsolicited status information can be reported for devices as described in the following: Name Type Descriptions Time-Of-Day Clock Unsolicited This message indicates that the Time-of-Day Clock is not available. Central can either keep the terminal out-of-service or return it to service. Power Failure Unsolicited This message is sent during power-up to tell Central that a power interruption has occurred. Central can use the configuration ID contained in this message to check if a download is needed before sending a Start Up Terminal Command message to put the terminal in-service Card Reader/Writer Solicited/Unsolicited This message gives details of any exception condition that is detected during card processing. Solicited device faults are only reported on Card Before Cash transactions. Cash Handler Solicited/Unsolicited This message gives details of a dispense operation in response to a Transaction Reply Command message. Depository Solicited/Unsolicited This message gives details of a deposit operation in response to a Transaction Reply Command message Receipt Printer Solicited/Unsolicited This message indicates whether or not a print operation has been successfully completed. Journal Printer Unsolicited This message indicates whether or not a print operation has been completed successfully.

70. 62 Electronic Journal Printer Unsolicited This message indicates whether or not a print operation has been completed successfully. Night Safe Depository Solicited/Unsolicited The solicited status message is sent in response to a Transaction Reply Command message, if the deposit was not detected. Encryptor Unsolicited This message indicates that an attempt to use the encryptor has failed. If an error status is reported, NCR recommends that you attempt to re-enter the local encryption keys. Sensors Unsolicited This message is sent on Supervisor mode entry and exit, tamper indicating bin in/out conditions and alarm conditions. Touch Screen Keyboard Unsolicited This message indicates that the keyboard has detected an error Supervisor Keys Unsolicited This message is sent to inform Central of the functions selected by the operator after entry to Supervisor mode. Statement Printer Solicited/Unsolicited A solicited status message is sent to Central if a fault which requires attention occurs during transaction processing. An unsolicited status message is sent when a statement is detected in the transport, the statement printer supplies (paper, ribbon, print-head, knife, capture bin) require attention, or an error occurs on a cut-and deliver function during a close state Bunch Note Acceptor Solicited/Unsolicited This message gives the status of the BNA in the following situations: In response to a Transaction

71. 63 Reply Command message As a result of a BNA error Envelope Dispenser Unsolicited Status messages are sent when the envelope dispenser is detected as being low/out or an envelope failed to be presented or retracted Cheque Processing Module Solicited/Unsolicited This message gives details of a Cheque Processing Module (CPM) response to a Transaction Reply Command message Coin Dispenser Solicited/Unsolicited This message gives details of a Coin Dispenser response to a Transaction Reply Command message. Barcode Reader - This message gives details of a barcode reader response to a Transaction Reply Command message Table 5.12: Device Status Information Exit to Host Messages: Advance NDC, acting as a communications gateway, can send messages on behalf of an Exit to the host using High Order Comms. Exit to host messages can be solicited or unsolicited, but the content of the Status Descriptor and Status Information fields depends on the Exit.

72. 64 5.1.3.8 Central to Terminal Messages Terminal Commands These commands are sent by Central to start up or shut down the terminal, or to request configuration, counter, or date and time information. Customisation Data Commands Central can use various Customisation Data commands to download different types of data to the terminal. The commands are:  State Tables Load  Screen/Keyboard Data Load  Configuration Parameters Load  Enhanced Configuration Parameters Load  FIT Data Load  Configuration ID Number Load  MAC Field Selection Load  Date and Time Load  Encryption Key Change  Extended Encryption Key Change  Dispenser Currency Cassette Mapping Table  XML Configuration Download State Tables Load Use this message to download state tables into the terminal. It may take more than one message to transmit the state tables, in which case each message will contain a portion of the state tables.

73. 65 Screen/Keyboard Data Load This message is used to download screen and/or keyboard data into the terminal. The maximum length of a single Screen/Keyboard Data Load message is 2000 bytes. Configuration Parameters Load This message downloads the Logical Unit Number (LUNO), parameters and timers into the terminal Enhanced Configuration Parameters Load This message supports configuration of options and timers, including additional options that are not supported in the Configuration Parameters Load message. This message does not include options and timers for the Electronic Journal (EJ) Upload feature; these are set in the EJ Options and Timers command. FIT Data Load This message downloads Financial Institution Tables (FIT) to the terminal. Each command can include as many tables as the protocol permits. One FIT is required for each member Financial Institution in the network. Configuration ID Number Load This message contains an identifier for the customisation data in the terminal. At terminal installation time, or any time customisation data is sent to the terminal, the configuration ID is set to 0000. The configuration ID number load message must be included as the last of the downloaded customisation data messages to set the configuration ID to the desired number. The configuration ID number can be any number from 0001 to 9999.The terminal holds customisation data and the configuration ID on the system disk. On receipt of a power-up status message from the terminal, Central can verify that the customisation data has been correctly loaded. Only if a configuration ID of 0000 is received does Central need to reload the customisation data. Message Authentication Field Selection Load This message is used to set the messages and fields specified for full or selective MAC verification, if a change to the default values is

74. 66 necessary. Fields are selected for inclusion in the MAC if the relevant offset byte is set to 1. Date and Time Load This message is used to set the local date and time in the terminal. Encryption Key Change For security, the Central programmer can use this message to change the Master Key (‗A‘ key), Communication Key (‗B‘ key) and VISA Master Key (‗V‘ key) initially entered by a local operator through Supervisor mode. The Encryption Key Change message may:  Include an encrypted encryption key.  Specify the current encryption key that the terminal must use to decrypt this encrypted encryption key.  Specify which of the current encryption keys to replace. A solicited status message will be returned to Central after an attempt to modify an encryption key, to indicate its success or failure. Central must encrypt the new encryption key with the same key designated to decrypt it at the terminal. PIN verification may require the use of a separate PIN key. The key used in this case is the PEKEY, contained in the FIT, which can be different for each financial institution in the system. On power failure the Master key is unchanged, but the Communications key and MAC key are changed to the locally entered B key if the Restart Mode option specifies this, or configuration data reload from disk fails. This message is not considered part of the customisation data and does not reset the configuration ID to zero.

75. 67 Dispenser Currency Cassette Mapping Table The table contained in this message is used to define currency types, which map to the configuration settings in table entry 7 of the Amount Check State defined in the Amount Check State Table. When the Data Security feature is set, all the messages sent from Central to the terminal that contain a MAC field must have this optional field present. Host to Exit Messages An Exit may use these messages for any purpose. But Advance NDC imposes the following restrictions on these messages:  Field g, the data field of the message, must contain 7-bit transmittable ASCII data  The overall length of the message must comply with any maximum message length imposed by the communications protocol that you are using. 5.1.3.9 Transaction Reply Command A Transaction Reply command is sent to the terminal once the cardholder has entered all the data necessary for a specific Transaction Request, and a request has been sent to Central.The terminal regards the Transaction Reply command as an authorisation to complete the transaction. If the transaction cannot be completed successfully, the terminal sends a device fault Solicited Status message to Central. The terminal then waits for another Transaction Reply command, authorising it to complete the transaction in another way.The maximum length of a Transaction Reply command depends on the protocol. 5.1.3.10 Interactive Transaction Response This message may be sent in response to a Transaction Request in order to obtain more information from the cardholder. This facility allows Central to communicate directly with the keyboard and display in those situations where state table sequencing is inappropriate.

76. 68 Message Validation Validation checks are performed on all messages received from Central. The situations which cause a command reject are as follows:  Illegal message class  Illegal message sub-class  Illegal message identifier  Illegal terminal command code  Illegal terminal command modifier  Field separator in illegal position  Insufficient fields in message  Insufficient memory to hold FIT entry (FIT number too large) Messages Received in Wrong Operational Mode The action taken will depend on which mode the terminal is in at the time of receiving the message. The messages include :  Customisation Data Commands  Transaction Reply Commands  Terminal Commands. 5.2 Identification of challenges and Solutions: Implementation Challenges and probable solution: The main challenge of implementing the interface is to maintain its accuracy. As, it is a big application and has many parts, we have to make a correct combination of these parts for better performance. It is very difficult to implement the whole interface directly as it may have many bugs. And if there is any bug in one part, the parts depending on it may be malfunctioned. The main challenge of implementing the interface is to maintain its accuracy. As, it is a big application and has many parts, we

77. 69 have to make a correct combination of these parts for better performance. It is very difficult to implement the whole interface directly as it may have many bugs. And if there is any bug in one part, the parts depending on it may be malfunctioned. It is recommended to design the whole interface part by part. First of all, we will implement a part which only handles the transaction for the native (for same bank‘s account) accounts and then try to remove bug from it by testing a reasonable time. Then we will implement another part that handles transactions between local Banks. After testing this, we will combine these two part . In this way, we will make switch for Master, Visa and other international cards. Security at various stages of transaction is a big concern. Testing related to ensure security must be conducted and new algorithms and technique might be introduced for better security. To implement and maintain this switch software, well trained engineers are required. Any disputes found during transaction should be solved immediately. So, training session should be introduced to handle any kind of problematic situation. Other challenges and Solutions: For Implementation it will take a large Fund and it is proved that technology change rapidly.This day is not so far when another sophisticated technology will knock at the door. So it is very needful to implement it in time as soon as possible and takes it full flavor. Bandwidth is a vital issue for transaction. Every transaction has a time limit for complete full cycle. For low bandwidth many request is time out. So, it should be kept in mind during implementation of timer. Reluctance of using new built software instead of well-established software provided by foreign vendors will be a great challenge. Various promotional offers and low maintenance cost offering may change the situation. But the new built software must be able to take the challenge of handling numerous transactions correctly and smoothly.

78. 70 5.3 Time and Manpower Estimation: After discussing with some technical officers of Pubali Bank Ltd.and analyzing the basic architecture of the system we make a rough estimation here: Estimation of manpower: Sectors Manpower Required Requirement Analysis 5-6 Design 5-7 Coding + Support 10-12 Testing 4 Table 5.13: Manpower Estimation Estimation of Time required in different stages of implementation: Figure 5.2: Time Estimation Transaction between only own Bank About 6 months Transaction between other local Banks About 3 months Transaction via Visa and Master Card About 6 months