STUDY ON ATM-POS SWITCHING SOFTWARE FOR BANKS

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

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

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

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

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

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

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.

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.

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.

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)

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.

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.

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)

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)

7
BYTE6 : 11000000 = C0x (fields 41 and 42 are present)
BYTE7 : 01001000 = 48x (fields 50 and 53 are 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

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

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

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

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.

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

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.

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.

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

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

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,

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
3xxx Reserved for ISO use
8xxx Reserved for National use
9xxx Reserved for Private use

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

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

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

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

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

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.

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.

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

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?

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 ?

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.

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

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.

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.

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.

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.
the FIT number on the card does not match the
number in any FIT.
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

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.

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

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.

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:

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

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.

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

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.

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

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.

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.

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

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 left-
most 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

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

49
are allowed.
Option 37 Print Track 2 to
Journal
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

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.

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.

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

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

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.

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.

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

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

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

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

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.
e3 Var (14) Error Severity. As ‗g3‘ in Solicited messages.
e4 Var Diagnostic Status. As ‗g4‘ in Solicited
messages.
e5 Var (8) Supplies Status. As ‗g5‘ in Solicited
messages.
Table 5.11: Status Information Field in Unsolicited message

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
completed successfully.

62
Electronic
Journal Printer
Unsolicited This message indicates whether or
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

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
message.
Barcode Reader - This message gives details of a
barcode reader response to a
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.

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.

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

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.

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.

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

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.

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

71
5.4 Hardware and software required
 32 GB Ram
 1TB Hard disk
 Sun solaris/Spark(Processor)
 Database: Oracle
 Programming Language: C/C++
 Operating System: Windows/Linux

72
Chapter 6
Findings
We have studied the basic architecture of switching software and
make an estimation of time and manpower requirements. After going
through the whole architecture we have identified the interfacing software
and necessary protocol. We also studied how switching software integrates
its functionalities with the Core Banking System and other interfacing
software. We also analyzed the possibility whether it is possible to
implement the switching software in Bangladesh with its present
technology and resources. Here, we describe the outcome of our study in
brief:
 Switch is a routing software. It must be capable of handling
thousands of transactions in a minute correctly. So, its
implementation should be done carefully.
 It is a huge software. So, part by part implementation will be helpful
to make it risk free.
 Advanced NDC is a complex interface. It has so many fields and
data format which are tough to design. So, it is needed to give more
attention and time while designing it.
 Integration of different parts is competitively complex. Proper
technical knowledge about it can bring a positive result.
 Long time assessment and testing are needed to make it a complete
and reliable one.
 Due to implementation complexity, it may take a long time to design
and implement a reliable system. But it is fair enough.
 Long time investment is needed.
 There is no local vendor company to provide this switching software.
So, successful implementation can grab the local market as it is
highly recommended by Bank authorities.
 E-commerce activities are supposed to be easy if all local banks
would have their own switching software.

73
 Well developed organizational and skilled manpower will enhance
switching performance
 From Bangladesh government , no impediment is existing now for
implementing this.
 So, a switching software can be implemented by Bangladesh using
its present technology and resources within a reasonable time

74
Chapter 7
Future Development
 We have just identified the required fields of interfacing software
and their functionalities. A proper design (Use case diagram, state
diagram etc ) is needed for implementing the software.
 Integration plan of switching software with CBS and other interface
is not completed. It should be done before implementation.
 Switch must be capable of handling huge load. So, an efficient
design must be found out to ensure the capability of handling huge
transaction load.
 Performance of switch depends on its accuracy and it can be ensured
by continuous assessment and testing. Suitable testing methods
should be found out.
 Security is a big concern for switching software. It needs more study
on security issues to make it risk free.

75
Chapter 8
Conclusion
A successful implementation of switching software can bring an end
of dependency on foreign vendors and save a lot of money. It can also add
a new dimension to our software industry. Survey and analysis have
suggested that it is very possible for Bangladesh to make its own Switching
software within a reasonable time and eliminate the third party
dependencies. As it is highly recommended by local Bank authorities,
steps should be undertaken to implement it as soon as possible and take the
pride of having own switching software.

76
Glossary
Advance NDC NCR‘s Advance implementation of NDC.
API Application Programming Interface.
ATM Automated Teller Machine
BNA Bunch Note Acceptor
Cardholder The SST customer.
CDM Cash Dispenser Module.
CPM Cheque Processing Module.
DIG Device Identifier Graphic.
Device ID Device Identifier. Another term for DIG.
EJ Electronic Journal
EMV Euro pay, MasterCard, VISA
Exit A general term covering user-defined states, Supervisor
features, virtual controllers, and special synchronization
routines called hooks.
Exit State A state defined and programmed by the user.
FDK Function Display Key.
FIID Financial Institution Identification number.
FIT Financial Institution Table
GBNA Global Bunch Note Acceptor
ID Identifier
ISO International Standards Organization
LUNO Logical Unit Number.
MAC Message Authentication Code.
MSR Magnetic Stripe Reader
NDC NCR Direct Connect

77
PIN Personal Identification Number
PVV PIN Verification Value
Smart Card Common name for a card which uses an integrated
circuit (microchip) rather than a magnetic stripe.
Standard Cash Handler A four-cassette stacking dispenser.
Supervisor The Supervisor application performs the out-of-
service operations needed to maintain and run
SSTs.
TCM Terminal Control Module.

78
REFERENCES
[1] Bangladesh Bank Publication - ―Developmental Central Banking in
Bangladesh Recent Reforms and Achievements (2009-12)‖, 2012.
[2] Y. Wang, Y. Zhang, ―The Formal Design Model of an Automatic
Teller Machine (ATM)‖, International Journal of Software Science and
Computational Intelligence, vol. 2, issue 1, pp. 102-131, 2010
[3] S. Al-amin, and S. S. Rahman, ―Application of electronic banking in
Bangladesh: an overview‖, Bangladesh Research Publications Journal, Vol.
4, Issue 2, pp. 172-184, 2010.
[4] M. S. N. Khan, M. K. Hassan, and A. I. Shahid, ―Banking Behavior of
Islamic Bank Customers in Bangladesh‖, Journal of Islamic Economics,
Banking and Finance pp. pp. 160-194, 2010.
[5] S. Singh, T. M. Yahyabhoy, ―Dynamics Of Innovation In E-
Banking‖, proceedings of international conference ECIS, 2002,
Gdańsk, Poland.
[6] S. H. Amit, F. Siddiqui, ―Bank Sector Update: Nine New Banks
for Bangladesh‖,
www.bracepl.com, 2012
[7] Manual of Atlantis ATM Net,
―http://www.pspcorp.net/downloads/ATMNET03.pdf‖

STUDY ON ATM-POS SWITCHING SOFTWARE FOR BANKS

More Related Content

What's hot

Viewers also liked

Similar to STUDY ON ATM-POS SWITCHING SOFTWARE FOR BANKS

Recently uploaded

STUDY ON ATM-POS SWITCHING SOFTWARE FOR BANKS