Академический Документы
Профессиональный Документы
Культура Документы
net/publication/307582973
CITATIONS READS
0 1,788
1 author:
Md Swawibe Ul Alam
Queen's University
7 PUBLICATIONS 1 CITATION
SEE PROFILE
Some of the authors of this publication are also working on these related projects:
All content following this page was uploaded by Md Swawibe Ul Alam on 03 September 2016.
Submitted by:
Md. Nazmul Sarker
Student ID: 0805015
Md Swawibe Ul Alam
Student ID: 0805080
SUBMITTED TO:
DHAKA, BANGLADESH
I
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
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
ii
3.3. ATM/POS Switch to CBS ........................................................................................... 24
3.4. CBS to ATM/POS Switch............................................................................................ 25
8. Conclusion....................................................................................................... 75
Glossary................................................................................................................. 76
References............................................................................................................. 78
iii
List of Figures
iv
List of Tables
v
Acknowledgements
vi
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.
vii
Chapter 1
Introduction
1
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.
2
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.
3
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.
4
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.
5
Part 3: Maintenance procedures for messages, data elements and
code values
An ISO 8583 message is made of the following parts:
Message type indicator (MTI)
One or more bitmaps, indicating which data elements are present
Data elements, the fields of the message
2.1.1.1 Bitmap
Within ISO 8583, a bitmap is a field or subfield within a message
which indicates which other data elements or data element subfields may
be present elsewhere in a message. A message will contain at least one
bitmap, called the Primary Bitmap which indicates which of Data Elements
1 to 64 are present. A secondary bitmap may also be present, generally as
data element one and indicates which of data elements 65 to 128 are
present. Similarly, a tertiary, or third, bitmap can be used to indicate the
presence or absence of fields 129 to 192, although these data elements are
rarely used. The bitmap may be transmitted as 8 bytes of binary data, or as
16 hexadecimal characters 0-9, A-F in the ASCII or EBCDIC character
sets. A field is present only when the specific bit in the bitmap is true. For
example, byte '82x is binary '1000 0010' which means fields 1 and 7 are
present in the message and fields 2, 3, 4, 5, 6, and 8 are not present.
For example if bitmap is 4210001102C04804,then it defines the
presence of Fields 2, 7, 12, 28, 32, 39, 41, 42, 50, 53, 62. Explanation of
Bitmap (8 BYTE Primary Bitmap = 64 Bit) field 4210001102C04804
BYTE1 : 01000010 = 42x (counting from the left, the second and seventh
bits are 1, indicating that fields 2 and 7 are present)
BYTE2 : 00010000 = 10x (field 12 is present)
BYTE3 : 00000000 = 00x (no fields present)
BYTE4 : 00010001 = 11x (fields 28 and 32 are present)
BYTE5 : 00000010 = 02x (field 39 is present)
6
BYTE6 : 11000000 = C0x (fields 41 and 42 are present)
BYTE7 : 01001000 = 48x (fields 50 and 53 are present)
BYTE8 : 00000100 = 04x (field 62 is present)
0________10________20________30________40________50________60__64
1234567890123456789012345678901234567890123456789012345678901234
0100001000010000000000000001000100000010110000000100100000000100
bit map
Abbreviation Meaning
a Alpha, including blanks
an Alphanumeric
7
as Alpha & special characters only
ns Numeric and special characters only
ans Alphabetic, numeric and special characters.
b Binary data
ISO 8583 defined 128 data elements. These are listed below:
8
16 n4 Date, conversion
17 n4 Date, capture
18 n4 Merchant type
19 n3 Acquiring institution country code
20 n3 PAN extended, country code
21 n3 Forwarding institution. country code
22 n3 Point of service entry mode
23 n3 Application PAN sequence number
24 n3 Function code (ISO 8583:1993)/Network
International identifier (NII)
25 n2 Point of service condition code
26 n2 Point of service capture code
27 n1 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
9
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 b1 Bitmap, extended
66 n1 Settlement code
67 n2 Extended payment code
68 n3 Receiving institution country code
69 n3 Settlement institution country code
70 n3 Network management information code
71 n4 Message number
72 n4 Message number, last
73 n6 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
10
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
11
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
12
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).
13
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.
14
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
15
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
16
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,
17
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)
18
2.4.2 Message class
Position two of the MTI specifies the overall purpose of the message.
19
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
xx2x Advice
xx4x Notification
xx5x Notification Acknowledgement
21
Chapter 3
22
e - Time Variant Number Field Separator
f - Top of Receipt Transaction Flag
g - Message Co-Ordination Number 6 Field Separators
23
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
24
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
25
Figure 3.4: Working flow of CBS to ATM/POS Switch
26
Chapter 4
Analysis of ATM/POS Implementation
a) Possible
b) Possible but Time Consuming
c) Possible but its not helpful
d) Not possible
27
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?
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
28
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
29
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.
30
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.
Components Function
31
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.
Terminal Commands:
These send instructions to the terminal.
32
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.
33
Standard state types:
The following table lists each of the supported standard state types
that control transaction processing:
38
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 Under state table control, the Cheque Accept
State 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 1.The Barcode Read State allows an application
State 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
39
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.
40
The programmatic screen layout for cardholder screen and operator panel is
as follows:
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
41
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.
Character Sets:
All display/print characters are obtained from the Single Size
Alphanumeric 1 character set.
42
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).
43
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.
44
5.1.3.5 Configuration Parameters
This message contains the parameters used in NDC+ for Diebold
emulation.
Value Description
45
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‘
46
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 This parameter determines
Reject whether the SST transmits
Specific Command Reject
options.
Option 15 Transaction Status This parameter determines
Information whether the transaction status
information from the last
command is appended to
Transaction Request messages.
Option 16 Journal Printer This parameter sets the maximum
Backup Time time in hours that journal printer
backup is allowed before all
journaling is discontinued. It is
not supported when dual mode
47
journal printing is active.
Option 17 Journal Printer This parameter sets the maximum
Backup Print number of print operations (in
Operations 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 This option determines whether
Status envelope dispenser status
messages are sent, remote status
indicators are set, and the remote
relay is activated.
Option 24 Enhanced/TI Sensor This option determines whether
Status Unsolicited the Enhanced TI/Sensor Status
Message 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 This parameter sets the flash rate
Indicators for the Media Entry/Exit
Flash Rate 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 This option simulates Supervisor
Mode mode entry/exit after safe door
Entry/Exit 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 This option controls the reporting
& Hardcopy B/U to Central of unsolicited device
Unsolicited Messages status messages for dual mode EJ
and hardcopy backup.
Option 36 Enhanced EJ Backup This option determines whether
multiple or standard EJ backups
48
are allowed.
Option 37 Print Track 2 to This option determines whether
Journal the first 22 characters of data
from card track 2 are
automatically journalled when a
card is read.
Option 44 BNA Journal Vaulted If the Bunch Note Acceptor
Notes Count (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 Inclusion of BNA last transaction
Settings status counts in the Transaction
Request message sent to Central
49
number to go to from the initial
Card Read state for consumer
cardless transactions.
Option 78 GBRU MStatus This option controls the reporting
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 This option controls which
Entry number system is used to
interpret state number fields.
Option 83 Cheque Processing This option allows the
Module modification of the message
format to support the reporting of
bins in the CPM.
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.
50
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
51
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.
53
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.
54
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.
55
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 Card Reader/Writer, Cash Handler,
and Print Coin Dispenser
Print Statement and Wait Statement Printer and Receipt in
56
sideways mode
Print Statement and Set Next Statement Printer and Receipt in
State sideways mode
Refund Bunch Note Acceptor
Encash Bunch Note Acceptor
Process Cheque Cheque Processing Module
57
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
58
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.
59
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 Descriptions
Characters
e1 1 Device Identification Graphic.
e2 Var Device Status. Used for recording any
(154 max) transaction exception of
change of state of the device. For devices
which report both
Solicited and Unsolicited Status messages, a
common set of
Transaction/ Device Status codes are defined
for use in either type
of message.
FS 1 Field Separator
e3 Var (14) Error Severity. As ‗g3‘ in Solicited messages.
FS 1 Field Separator
e4 Var Diagnostic Status. As ‗g4‘ in Solicited
messages.
FS 1 Field Separator
e5 Var (8) Supplies Status. As ‗g5‘ in Solicited
messages.
60
Device Status Information
Solicited or unsolicited status information can be reported for
devices as described in the following:
Name Type Descriptions
Time-Of-Day Unsolicited This message indicates that the
Clock 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 Solicited/Unsolicited This message gives details of any
Reader/Writer exception condition that is
detected during card processing.
Solicited device faults are only
reported on Card Before Cash
transactions.
Cash Handler Solicited/Unsolicited This message gives details of a
dispense operation in response to
a Transaction Reply Command
message.
Depository Solicited/Unsolicited This message gives details of a
deposit operation in response to a
Transaction Reply Command
message
Receipt Printer Solicited/Unsolicited This message indicates whether or
not a print operation has been
successfully completed.
Journal Printer Unsolicited This message indicates whether or
not a print operation has been
completed successfully.
61
Electronic Unsolicited This message indicates whether or
Journal Printer not a print operation has been
completed successfully.
Night Safe Solicited/Unsolicited The solicited status message is
Depository 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 Unsolicited This message indicates that the
Keyboard keyboard has detected an error
Supervisor Unsolicited This message is sent to inform
Keys Central of the functions selected
by the operator after entry to
Supervisor mode.
Statement Solicited/Unsolicited A solicited status message is sent
Printer 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 Solicited/Unsolicited This message gives the status of
Acceptor the BNA in the following
situations:
In response to a Transaction
62
Reply Command message
As a result of a BNA error
Envelope Unsolicited Status messages are sent when the
Dispenser envelope
dispenser is detected as being
low/out or an envelope failed to
be presented or retracted
Cheque Solicited/Unsolicited This message gives details of a
Processing Cheque Processing Module
Module (CPM) response to a Transaction
Reply Command message
Coin Dispenser Solicited/Unsolicited This message gives details of a
Coin Dispenser response to a
Transaction Reply Command
message.
Barcode Reader - This message gives details of a
barcode reader response to a
Transaction Reply Command
message
63
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
64
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
65
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.
66
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.
67
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)
69
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
About 6 months
70
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
71
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.
72
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
73
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.
74
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.
75
Glossary
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
76
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.
77
REFERENCES
78