advertisement

Study On ATM/POS Switching Software For Banks

75 %
25 %
advertisement
Information about Study On ATM/POS Switching Software For Banks

Published on June 12, 2016

Author: MdMainUddinRony

Source: slideshare.net

advertisement

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

Add a comment

Related pages

DNS Software Ltd.

Solution for Bank. Core Banking; ... SMS Banking; IST Switching Software • Introduction • IST Switch Features • Solution ... ATM/POS device handling, ...
Read more

ATM Software & ATM Switch - Innovative Solutions | CR2 EN

ATM Software & ATM Switch ... the key differentiator of our switching solution is that it ... Case Study: Fast Loans at the ATM. Bank al Etihad searched ...
Read more

Mitigation of Back-to-Back Capacitor Switching Transients ...

The basic theory concerning capacitor bank switching ... We use the software package ATP ... This is sometimes called back-to-back capacitor switching.
Read more

ATM Services - FSS - Financial Software & Systems

Software Services. Systems Integration ... management and managed services, partners with banks and financial ... from switching to deployment to managed ...
Read more

IT in Banking: Various Software Systems for Bank

Various Software Systems for Bank ... A Switching Software is an ATM/POS ... (transactions made by bank’s own cardholders at bank’s own ATM/POS) ...
Read more

Atm & Pos | LinkedIn

ATM / POS / IST Switch Technical Deputy Manager at e-finance Past ATM / POS Switch Technical Team Leader at e-finance, Sr. ATM/POS Switch Technical ...
Read more

Switching bank accounts | ASIC's MoneySmart

Switching bank accounts. Making the switch. There's no reason for you to stick with your bank account if you're unhappy. Here we explain how switching is a ...
Read more

POS Software – Credit & Debit Card Services | CR2 EN

POS Software to provide the best ... BankWorld POS enables your bank to acquire transactions from merchant POS ... Transaction switching to ...
Read more