1

OKAFOR, CHINEDU MARTIN

PG/M.Eng/12/62783

DESIGN OF TWO-FACTOR AUTHENTICATION (PIN AND SMS

PASSWORD) FOR AN AUTOMATED TELLER MACHINE (ATM).

FACULTY OF ENGINEERING

DEPARTMENT OF ELECTRONIC ENGINEERING

Ebere Omeje Digitally Signed by: Content manager’s Name

DN : CN = Webmaster’s name

O= University of Nigeria, Nsukka

OU = Innovation Centre

2

DESIGN OF TWO-FACTOR AUTHENTICATION (PIN AND SMS

PASSWORD) FOR AN AUTOMATED TELLER MACHINE (ATM).

BY

OKAFOR, CHINEDU MARTIN

PG/M.Eng/12/62783

DEPARTMENT OF ELECTRONIC ENGINEERING,

UNIVERSITY OF NIGERIA, NSUKKA.

SUPERVISOR: DR. O. N. ILOANUSI

AUGUST, 2015.

3

DESIGN OF TWO-FACTOR AUTHENTICATION (PIN AND SMS

PASSWORD) FOR AN AUTOMATED TELLER MACHINE (ATM).

BY

OKAFOR, CHINEDU MARTIN

PG/M.Eng/12/62783

DEPARTMENT OF ELECTRONIC ENGINEERING,

UNIVERSITY OF NIGERIA, NSUKKA.

AUGUST, 2015.

4

TITLE PAGE

DESIGN OF TWO-FACTOR AUTHENTICATION (PIN AND SMS

PASSWORD) FOR AN AUTOMATED TELLER MACHINE (ATM).

BY

OKAFOR, CHINEDU MARTIN

PG/M.Eng/12/62783

DEPARTMENT OF ELECTRONIC ENGINEERING,

UNIVERSITY OF NIGERIA, NSUKKA.

5

APPROVAL PAGE

DESIGN OF TWO-FACTOR AUTHENTICATION (PIN AND SMS PASSWORD) FOR

AN AUTOMATED TELLER MACHINE (ATM).

BY

OKAFOR, CHINEDU MARTIN

(PG/M.Eng/12/62783)

A THESIS SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR

THE AWARD OF MASTER OF ELECTRONIC ENGINEERING (DIGITAL

ELECTRONICS AND COMPUTERS OPTION) IN THE DEPARTMENT OF

ELECTRONIC ENGINEERING, UNIVERSITY OF NIGERIA, NSUKKA.

OKAFOR, CHINEDU MARTIN

(STUDENT)

SIGNATURE: ………….......... DATE: ………..........

DR. O. N. ILOANUSI

(SUPERVISOR)

SIGNATURE: ………….......... DATE: ………..........

EXTERNAL EXAMINER

SIGNATURE: ………….......... DATE: ………..........

PROF. C.I. ANI

(HEAD OF DEPARTMENT)

SIGNATURE: ………….......... DATE: ………..........

PROF. E.S. OBE

(CHAIRMAN, FACULTY

POSGRADUATE COMMITTEE)

SIGNATURE: ………….......... DATE: ………..........

6

CERTIFICATION

Okafor, Chinedu Martin, a master’s degree postgraduate student in the

Department of Electronic Engineering and with registration number

PG/M.Eng/12/62783 has satisfactorily completed the requirements for the

award of Master of Engineering (M.Eng) in Electronic Engineering.

______________________ _____________________ Dr. O.N. Iloanusi Prof. C. I. Ani Supervisor H.O.D.

_____________________________________________

PROF. E.S. OBE

(CHAIRMAN, FACULTY POSTGRADUATE COMMITTEE)

7

DECLARATION

I, Okafor Chinedu Martin, a postgraduate student of the Department of

Electronic Engineering, University of Nigeria, Nsukka declare that the work

embodied in this thesis is original and has not been submitted by me in part or

in full for any other diploma or degree of this or any other University.

___________________________

OKAFOR, CHINEDU MARTIN

PG/M.Eng/12/62783

__________________

DATE

8

DEDICATION

This research work is dedicated to God Almighty for his mercy. Also to my

family, for all the support towards achieving my career goals.

9

ACKNOWLEDGEMENTS

My profound thanks go to my supervisor, Dr. O.N. Iloanusi for her accessibility,

encouragement and constructive criticism that geared me towards working

hard to achieve this work. My unalloyed thanks go to Prof. C.C. Osuagwu, Prof.

C.I. Ani and the rest of the staff of the department for their co-operation

within the time of this work.

A number of personal friends and professional colleagues, especially Engr.

Ahamdi Abarikwu and Engr. Uche Nwali, provided valuable help in the course

of this research. I wish to use this opportunity to thank them all.

My regards go to my family for the moral support throughout this programme.

Finally, I wish to acknowledge all the authors whose materials are referenced

in this research work.

Okafor, Chinedu Martin

10

ABSTRACT

Most ATMs employ one means of authentication (single factor authentication) by using the PIN. These kinds of ATMs are vulnerable to ATM frauds like Card Skimming: where a device placed at the slot for the ATM Card copies all the information stored in ATM cards including the PINs and then copies of the original cards will be made, afterwards money will be stolen from the accounts concerned. This work presents the design of ATM software that employs a two factor authentication method that utilises the PIN and a One Time Password (OTP) which will be sent to the client’s mobile phone through SMS. This process will be initiated by the ATM as soon as the user slots his ATM card and the system accepts it. By employing this technology, a fraudster who has access to someone’s ATM Card and PIN will still not gain access to their bank account if he has no access to the SMS containing the One Time Password. This work employed Object Oriented Analysis and Design (OOAD) as its methodology and this includes the use of the Unified Modelling Language (UML). In order to realise the system using the OOAD approach, C#, an oriented programming language was used. The result obtained at the end of this project is the prototype of ATM software that employs two factor authentication. Finally, the performance of the system while it was being tested shows that the objective of providing additional security using two factor authentication was achieved to a large extent.

11

TABLE OF CONTENT

Title page - - - - - - - - - - i

Approval page - - - - - - - - - ii

Certification - - - - - - - - - - iii

Declaration - - - - - - - - - - iv

Dedication - - - - - - - - - - v

Acknowledgements - - - - - - - - - vi

Abstract - - - - - - - - - - vii

Table of Content - - - - - - - - - viii

List of Figures - - - - - - - - - xi

List of Tables - - - - - - - - - xiv

CHAPTER ONE: INTRODUCTION

1.1 Background to the study - - - - - - - 1

1.2 Statement of the Problem - - - - - - - 7

1.3 Objectives - - - - - - - - - 8

1.4 Scope of Study - - - - - - - - - 8

1.5 Significance of Study - - - - - - - - 9

1.6 Proposed Methodology - - - - - - - 9

1.7 Organization of Thesis - - - - - - - 10

CHAPTER TWO: LITERATURE REVIEW

2.1 Review of the Related Works - - - - - - 12

2.2 Review of the Technologies involved in the proposed Design - 17

2.2.1 Authentication Mechanisms used in electronic banking - 17

2.2.2 The ATM System Technology - - - - - 20

2.2.2.1 The ATM Hardware - - - - - 24

2.2.2.2 The ATM Software - - - - - 25

12

2.2.3 Short Message Service (SMS) - - - - - 32

2.2.3.1 Bulk SMS Service - - - - - 33

2.2.4 Mechanism employed in this work for sending

the One Time Password (OTP) - - - - - 34

CHAPTER THREE: RESEARCH METHODOLOGY

3.1 Methods Adopted for this Work - - - - - - 35

3.1.1 Object Oriented Analysis and Design (OOAD)- - - 35

3.1.1.1 The Waterfall Model Software Development

Life Cycle - - - - - - - 40

3.1.2 Modelling and Simulation - - - - - - 45

CHAPTER FOUR: SYSTEM ANALYSIS AND DESIGN

4.1 System Specification - - - - - - - - 53

4.1.1 Requirements Definition - - - - - - 53

4.1.2 UML Modelling of the System - - - - - 55

4.1.3 Main Menu Specification - - - - - - 65

4.1.4 Input Specification - - - - - - - 65

4.1.5 Output Specification - - - - - - 66

4.1.6 Database Specification - - - - - - 68

4.1.7 Hardware and Software Requirements - - - - 69

4.2 System Design - - - - - - - - 70

4.2.1 Main Menu Design - - - - - - - 70

4.2.2 Input Design - - - - - - - - 76

4.2.3 Output Design - - - - - - - 77

4.2.4 Database Design - - - - - - - 79

CHAPTER FIVE: SYSTEM IMPLEMENTATION, TESTING AND SIMULATION

5.1 System Implementation - - - - - - - 82

5.1.1 Main Menu Implementation - - - - - 84

13

5.1.2 Input Implementation - - - - - - 85

5.1.3 Output Implementation - - - - - - 87

5.1.4 Choice of Programming Language - - - - 88

5.2 System Integration - - - - - - - 94

5.3 System Testing - - - - - - - - 95

5.3.1 Cash Withdrawal Testing - - - - - - 102

5.3.2: Change Security PIN Testing - - - - - 105

5.3.3 Balance Inquiry Testing - - - - - - 108

5.4 Debugging - - - - - - - - - 110

CHAPTER SIX: CONCLUSION

6.1 Summary - - - - - - - - - 112

6.2 Contribution of the proposed model to the Body of Knowledge - 113

6.3 Recommendations - - - - - - - - 113

References - - - - - - - - - - 115

Appendix A - - - - - - - - - - 119

Appendix B - - - - - - - - - - 126

Appendix C - - - - - - - - - - 152

14

LIST OF FIGURES

Fig. 1.1: A Classical ATM Machine - - - - - - 2

Fig. 1.2: Schematic diagram for the ATM - - - - - 2

Fig. 1.3: Typical Skimming Device - - - - - - 4

Fig. 1.4: A typical Card Trapping device - - - - - 5

Fig. 1.5: Card Trapping Device being placed on genuine card slot - 5

Fig. 1.6: A typical Pin Pad Overlay - - - - - - 6

Fig. 2.1: A Typical ATM Machine - - - - - - 21

Fig. 2.2: Diagram for the ATM Connected to a Network - - - 21

Fig. 2.3: Block diagram for the ATM - - - - - - 24

Fig. 2.4: Xpeak architecture - - - - - - - 30

Fig. 2.5: SMS network architecture - - - - - - 32

Fig. 2.6: Mechanism for sending the One Time Password - - - 34

Fig. 3.1: Typical diagram of a class - - - - - - 37

Fig. 3.2: Encapsulation hides the class’ state and implementation

from the (client) - - - - - - - - 38

Fig 3.3: Withdrawal class, Deposit class and Transfer class inherit

from Transaction class as shown with a small triangle

pointing to the superclass - - - - - - 39

Fig. 3.4: The Waterfall Model (with interstage feedback) - - - 42

Fig. 3.5: A typical Use Case Diagram - - - - - - 46

Fig. 3.6: A typical Class Diagram - - - - - - - 47

Fig. 3.7: A typical Sequence Diagram - - - - - - 48

Fig. 3.8: A typical Activity Diagram - - - - - - 50

15

Fig. 3.9: A typical Deployment Diagram - - - - - 51

Fig. 4.1: Sequence diagram of the system - - - - - 56

Fig. 4.2: Activity Diagram for the System - - - - - 58

Fig. 4.3: ATM Use Case diagram - - - - - - - 60

Fig. 4.4: Class diagram of Banking and ATM classes - - - - 62

Fig. 4.5: Deployment diagram of the system - - - - - 64

Fig. 4.6: System Block Diagram - - - - - - - 70

Fig. 4.7: Operation of One Time Password verification - - - 71

Fig. 4.8: System flowchart - - - - - - - 72

Fig. 4.9: ATM Keypad - - - - - - - - 77

Fig. 4.10: Output Design of ATM - - - - - - 78

Fig. 4.11: ATM machine input and output design - - - - 78

Fig. 5.1: The Simulated ATM system - - - - - - 84

Fig. 5.2: Transaction Menu Screenshot - - - - - 86

Fig. 5.3: ATM Welcome screen - - - - - - - 96

Fig. 5.4: ATM cards form - - - - - - - - 97

Fig. 5.5: Input Security PIN screen - - - - - - 98

Fig. 5.6: Invalid PIN screenshot - - - - - - - 99

Fig. 5.7: Account blocked screenshot - - - - - - 99

Fig. 5.8: One Time Password (OTP) verification screen - - - 100

Fig. 5.9: Invalid OTP screenshot - - - - - - - 101

Fig. 5.10: ATM machine showing transaction main menu - - - 101

Fig. 5.11: Select Account Type Screenshot - - - - - 102

Fig. 5.12: Select amount to withdraw Screenshot - - - - 103

Fig. 5.13: Input amount to withdraw Screenshot - - - - 103

Fig. 5.14: Cash withdrawal screenshot - - - - - - 104

Fig. 5.15: Cash Withdrawal Statement - - - - - - 105

16

Fig. 5.16: Input old PIN Screenshot - - - - - - 106

Fig. 5.17: Enter new PIN Screenshot - - - - - - 106

Fig. 5.18: Re-enter new PIN Screenshot - - - - - 107

Fig. 5.19: PIN changed successfully Screenshot - - - - 107

Fig. 5.20: Balance Inquiry Screenshot - - - - - - 108

Fig. 5.21: Perform another operation Screenshot - - - - 109

Fig. 5.22: Transaction Termination message - - - - - 109

17

LIST OF TABLES

Table 2.1: Comparison Table for the related works - - - - 17

Table 2.2: Windows XP System Requirements - - - - 27

Table 4.1: Input and Output Specifications - - - - - 68

Table 4.2: List of tables in ATM database - - - - - 68

Table 4.3: atm_cards– stores ATM card information - - - 79

Table 4.4: atm_cash_withdrawal– stores predefined ATM withdrawal

amount - - - - - - - - - 79

Table 4.5: atm_otp– stores one time password - - - - 80

Table 4.6: bank_account– stores customers account balance - - 80

Table 4.7: bank_minbalance– stores the bank mini balance that cannot be

withdrawn - - - - - - - - 80

Table 4.8: bank_transactions– stores contacts and inquiries - - 80

Table 4.9: customers– stores customers’ personal details - - - 81

Table 5.1: List of output screen user controls - - - - 88

Table 5.2: Comparison of C# and Java based on data type - - - 90

Table 5.3: Comparison of C# and Java based on reference type - - 91

Table 5.4: Comparison of C# and Java based on arrays and collections - 92

Table 5.5: Comparison of C# and Java based on object orientation - 94

Table 5.6: Pre-stored ATM cards - - - - - - 95

18

CHAPTER ONE

INTRODUCTION

1.1 Background to the Study

Brief History of the ATM

The concept of self-service in retail banking has evolved through various

stages. These stages include cash machines developed in the early 1960s

through independent and simultaneous efforts of engineers in Britain, Sweden

and Japan. The first of such commercial cash machines was put into use in the

UK on the 27th of June 1967 by the Barclays Bank. These and other

developments (which were championed by efforts in Asia, Europe and

America) gave rise to the automated (automatic) teller machine (ATM). The

first modern ATM came into use in December 1972 and was designed by IBM

for Lloyd Banks. The machine was called the IBM 2984 and popularly known as

the CIT: Cash Issuing Terminal. The CIT was considered the first true cash point

and is similar to what we have nowadays [1].

The ATM is a networked computer terminal that provides Bank clients with

access to financial transactions from a public space without the need for one

to visit the bank branch. Figure 1.1 shows a classical ATM Machine and figure

1.2 shows the schematic diagram for the ATM. The ATM is considered a

networked computer terminal because it is basically a computer that must be

connected to a bank server or/and network of computers such as the internet

in order to achieve its purpose (see fig. 2.1). Using the ATM, customers can

access their bank accounts in order to make cash withdrawals or check their

account balances as well as paying their bills [2].

19

Fig. 1.1: A Classical ATM Machine (Source: elprocus.com).

Fig. 1.2: Schematic diagram for the ATM.

CPU

PRINTER

KEYPAD SPEAKER

CARD

READER

DISPLAY

CASH

DISPENSER

COMMUNICATION

INTERFACE

MEMORY

20

How the ATM works

On most modern ATMs, the customer is identified by inserting a plastic ATM

card with a magnetic stripe or a plastic smart card with a chip, which contains a

unique card number and some security information such as an expiration date.

Authentication is provided by the customer entering a personal identification

number (PIN).

When the customer/card holder slots his card into the card reader, it captures

the account information such as bank details and Personal Identification

Number “PIN” that are stored on the card. The CPU, through the display, then

requests for the customer to enter his PIN. The customer then enters his PIN

using the keypad. In order to complete his transaction information, the

customer also selects the necessary options from the subsequent ones shown

by the display. The CPU then forwards this information to the bank

computer/host processor through the communication interface. All the

communication (two way) between the ATM and the bank computer/host

processor is done through the communication interface. The host processor

then enters the transaction request to the customer’s bank. If the customer

requests cash, the host processor takes the cash from the customer’s account.

As soon as the funds are transferred from the customer’s account to host

processor’s bank account, the processor sends an approval code to the ATM,

thereby instructing the machine to dispense the cash through the cash

dispenser.

In the operation of the ATM, the speaker provides feedback as audio to the

customer when a particular key is pressed. Also, all the details regarding the

customer’s transaction like the date and time and the amount involved as well

as the balance amount in the bank are printed out as a receipt by the printer

and issued to the customer.

21

Common ATM Frauds

The evolution of ATMs has resulted in the evolution of ATM Frauds. These

frauds are of various types and employ varying tactics. Amongst these frauds

we have;

Card Skimming: The card details and PIN are captured at the ATM by a device

placed at the card reader and used to produce counterfeit cards for

subsequent fraudulent cash withdrawals. Figure 1.3 shows a typical case of

card skimming.

On the left part of figure 1.3, the skimming device is shown being placed on

top of the card slot/card reader. It looks much like the card reader but it is

fake. The right part of figure 1.3 shows the skimming device fully placed on top

of the card reader. As the card holder slots his card, the skimming device

copies all the information on the card including the PIN and as such copies of

Fig. 1.3: Typical Skimming Device (Source: Google.com).

Genuine Card Slot

Skimming Device

22

the card could be made elsewhere and used to withdraw from the same

account. The customer is unaware of the card skimming and sees a normal

transaction and retains the card.

Card Trapping: In this case, the card is physically captured at the ATM by a

device placed at the card slot and the PIN is compromised. Later the card is

retrieved and used to make fraudulent cash withdrawals. The customer loses

the card. Figure 1.4 shows the card trapping device while figure 1.5 shows

how the card trapping device is placed on the card slot.

Fig. 1.4: A typical Card Trapping device (Source: google.com).

Fig. 1.5 Card Trapping Device being placed on genuine card slot (Source:

google.com).

Genuine Card Slot

Card Trapping Device

23

Pin Compromise: Here the criminal uses a Pin Pad Overlay to acquire the PIN.

The Pin Pad Overlay is a false PIN pad which is fitted on top of the existing PIN

pad. Most times the Pin Pad Overlay could be a flexible piece of circuit-

embedded plastic that fits perfectly over the ATM's genuine PIN pad. Figure

1.6 shows a pin pad overlay being placed on a genuine keypad.

Sometimes miniature cameras, remotely positioned cameras or video

surveillance could be used to accomplish Pin Compromise.

Fig 1.6: A typical Pin Pad Overlay (Source: google.com).

These frauds necessitate the need for such efforts as Two-Factor

Authentication in other to curb them.

Two-Factor Authentication

This is an authentication mechanism that utilizes a combination of two factors

such as Username and Password, PIN and SMS One Time Password, or

Username and Fingerprint. This method is used by various banks and other

financial institutions for authentication for online banking.

Pin Pad Overlay

Genuine Key Pad

24

Most ATMs employ one means of authentication (single factor authentication)

by using the PIN. These kinds of ATMs are vulnerable to ATM frauds like Card

Skimming: where a device placed at the slot for the ATM Card copies all the

information stored in the card including the PIN [3]. Since the PIN is the only

means of authentication (Single Factor Authentication), then the security of

the ATM will be compromised, duplicates of all cards copied will be made and

illegal access to the corresponding bank accounts will be achieved and money

will move to the wrong hands.

This project aims to reduce these ATM frauds by developing the prototype of

the ATM software that will employ a two factor authentication method that

utilises the PIN and a One Time Password (OTP) which will be sent by the ATM,

through SMS, to the client’s mobile phone immediately it accepts his ATM

Card. As this technology is employed, whoever then has access to somebody’s

ATM Card and PIN will fail at any attempt to gain access to their bank account,

unless the fraudulent person has access to the phone (and SMS) which bears

the One Time Password (OTP).

1.2 Statement of the Problem

The need to ensure the security of money while carrying out the automation of

banking services cannot be over-emphasised, i.e. the advantages are

overwhelming. Considering the fact that automation speeds up processes

(most especially the rolling out of services) and the banking sector is at the hub

of economic development, automating retail banking invariably speeds up an

economy and ensures economic growth provided there are means to curb the

resulting frauds.

25

1.3 Objectives

The objectives of this project are:

--To develop ATM software that will employ the Two Factor Authentication

process in its operation and thereby achieve the security of funds and the

reduction of ATM frauds.

--This project is aimed at showing that already existing infrastructure for

financial services could be further utilised to enhance the security of financial

transactions and as such save cost of additional hardware needed to achieve

enhanced security.

--To explore the viability of the GSM/SMS technology in enhancing ATM

security.

1.4 Scope of Study

The scope of this work includes the technologies, parameters and processes

that are within this research and they are listed below as follows:

-- Security of ATM transactions and the effect of Two Factor Authentication in

reducing them.

--SMS technology and the Bulk SMS Service: In this work, the SMS technology

is the medium through which the One Time Password is delivered to the

customer.

--Object Oriented Analysis and Design (OOAD): The Software Engineering

involved in this work is firmly rooted in OOAD.

--Unified Modelling Language (UML): The UML is the industry-standard

Modelling language in the field of software engineering. UML is employed in

creating visual models, specifying and constructing software systems and also,

26

non-software systems [4]. UML is found to be very useful in carrying out

OOAD.

--Object Oriented Programming (OOP): Usually OOAD gives rise to Object

Oriented Programming. C# is the Object Oriented Programming Language

employed in this research.

1.5 Significance of Study

The significance of this project is that it will provide a viable means of fortifying

the security of money in bank accounts. This project will provide a way of

reducing illegal banking transactions made with the ATM. By employing the

Two Factor Authentication procedure crime will be curtailed and financial

services will be enhanced.

1.6 Proposed Methodology

This work uses the following methodology:

Object Oriented Analysis and Design (OOAD): In this work Object Oriented

Analysis and Design (OOAD) is employed. Using OOAD, Object Oriented

Decomposition is done within the confines of the vocabulary of the problem to

be solved. Object-oriented analysis focuses on the analysis that examines

requirements with respect to the classes and objects found in the description

of the problem domain. By using this methodology requirements will be

organised around objects, which integrate both behaviours (processes) and

states (data) modelled after real world objects that the system interacts with.

Object Oriented Design employs the results obtained through Object-oriented

analysis in order to design the system.

Also, a suitable Software Development Life Cycle (SDLC) is chosen for use in

this work. The choice of the SDLC is the Waterfall Model Software

27

Development Life Cycle. At the appropriate stage of this SDLC, OOAD will be

carried out. OOAD also involves the use of graphical modelling and simulation.

Modelling and Simulation: This software system will be modelled using the

Unified Modelling Language (UML). The UML is found very useful in developing

the visual models of a whole lot of systems.

The coding (in C#) and simulation of this system will be done using Visual

Studio.

1.7 Organization of Thesis

The rest of this Thesis is organised as follows;

Chapter Two: Literature Review- In this chapter, an analytical overview of the

significant literature published on this work is provided and their strengths and

weaknesses are exposed. The reasons for this are to gain insight into the work,

to distinguish what has been done from what needs to be done and to

rationalise the significance of the work.

Also the key concepts involved in this work will be looked into and reviewed.

Chapter Three: Research Methodology- This chapter will deal with the

methods involved in carrying out this work. It aims at showing how they are

organised and structured.

Chapter Four: System Analysis and Design- This chapter provides a practical

application of Object Oriented Analysis and Design along with the Waterfall

Software Development Life Cycle in analysing and designing the system in

question.

Chapter Five: System Implementation, Testing and Simulation- Here the

different modules of the software will be implemented. The implementation

28

will be done using an object oriented programming language called C#. Also

this chapter will handle the testing and simulation of the software codes.

Chapter Six: Conclusion- Here the work will be summarised and duly

concluded.

29

CHAPTER TWO

LITERATURE REVIEW

2.1 Review of the Related Works

In the following, already existing works concerning the improvement of ATM

and Internet Banking security through various technologies are discussed.

(I) Model for Token Based Secure Transaction in ATM Networks by Sonika

Katta, Dinesh Goyal, Ruchi Dave, Naveen Hemrajani, IJCSET, August 2011,

Vol 1, Issue 7, 395-398.

Here, the authors introduce the hardware Token. The hardware Token or

simply Token is a physical device that performs or aids authentication. This can

be a secure storage device containing passwords, such as a bankcard or smart

card. This can also be an active device that yields One-Time Passcodes, either

time-synchronous (changing in synchrony with a master at the host server) or

challenge–response (responding to a one-time challenge). Token security

defences include tamper-resistant packaging and special hardware that

disables the token if it is tampered with or if the number of failed

authentication attempts exceeds a chosen threshold. The token acts like an

electronic key to access something.

In this model if a user wishes to use the ATM, he would use the Token along

with the PIN for authentication and prove that he is who he claims to be

before making any transaction. The token provides the One Time Passcode

needed for authentication [5].

30

(II) Authentication in an Internet Banking Environment by the US Federal

Financial Institutions Examination Council (http://www.ffiec.gov/)

In this work, the USB token device is introduced. This device is typically the size

of a house key. It plugs directly into a computer’s USB port and therefore does

not require the installation of any special hardware on the user’s computer.

Once the USB token (the first authenticating factor) is recognized by a

computer in which it is plugged, the customer is prompted to enter his or her

password (the second authenticating factor) in order to gain access to the

computer system and effect financial transactions.

USB tokens are one-piece, injection-moulded devices. USB tokens are hard to

duplicate and are tamper resistant; thus, they are a relatively secure vehicle for

storing sensitive data and credentials. The device has the ability to store digital

certificates that can be used in a public key infrastructure (PKI) environment.

The USB token is generally considered to be user-friendly. Its small size makes

it easy for the user to carry and, as noted above, it plugs into an existing USB

port; thus the need for additional hardware is eliminated [6].

(III) Enhancing ATM security using fingerprint and GSM technology by Ashish

M. Jaiswal and Mahip Bartere, IJCSMC, Vol. 3, Issue. 4, April 2014, pg.28 – 32.

In this design Bankers will collect the customer’s finger prints and mobile

phone number(s) while opening accounts for them, then afterwards the

customer can access the ATM machine. When the customer uses the ATM:

after inserting the card, he must place his finger on the finger print module, he

then gets automatically generated 4-digit code every time as a message to his

mobile phone through GSM modem connected through a microcontroller to

the ATM. The code received by the customer should be entered by pressing

31

the keys on the ATM screen, and only after that will he be able to make

transactions [7].

(IV) Facial Verification Technology for Use in ATM Transactions by Aru,

Okereke Eze, Ihekweaba Gozie, AJER, Vol-2, Issue-5, 2013, pp-188-193.

This paper proposes an automatic teller machine security model that would

combine a physical access card, a PIN, and electronic facial recognition. In this

model, as a user walks to the ATM (its digital camera is on 24hours a day), its

computer will automatically initiate a face recognition procedure. Whenever

the computer detects a human face, its camera obtains a picture of the face,

the computer compares the image of the face to the images of those of

registered customers in its database .If the face (as seen by the ATMs camera)

matches the picture of that in the database, then the user is automatically

recognized by the machine [8].

(V) Designing a Biometric Strategy (Fingerprint) Measure for Enhancing ATM

Security in Indian E-Banking System by Sri Shimal Das, Smt. Jhunu Debbarma,

IJICT, Vol. 1, No. 5, September 2011.

In this paper the authors propose the design of an ATM that uses the ATM card

and the customer’s fingerprint (instead of the PIN) in order to achieve

sufficient ATM security. The proposed system works as follows: at the time of

transaction (i.e., after the machine has read and accepted the ATM card),

customers enrol their fingerprint to a high resolution fingerprint scanner. The

fingerprint image is transmitted via secured channel to the central server

which contains a record of customers’ fingerprints. At the banking terminal the

minutiae extraction and matching are performed in order to verify that the

presented fingerprint image belongs to the claimed user in the bank’s

database. Then authentication is granted if the minutiae matching are

32

successful, otherwise authentication is denied. This proposed ATM biometric

authentication system consists of five main components. They are: sensor,

feature extractor, fingerprint/template database, and matcher and decision

module. The function of the sensor is to scan the biometric trait of the user.

The function of the feature extraction module is to extract the feature set from

the scanned biometric trait. This feature set is then stored into the template

database. The matcher module takes two inputs, i.e. features set from the

template database and features set of the user who it wants to authenticate

and compares the similarity between the two sets. The last module, i.e., the

verification module makes the decision about the matching of the two features

sets [9]. By doing all these, this proposed system could achieve sufficient

security for ATMs.

Comparison Table for the related works

Title and Author Strength Limitation

Model for Token Based

Secure Transaction in

ATM Networks by Sonika

Katta, Dinesh Goyal,

Ruchi Dave, Naveen

Hemrajani, 2011.

The use of Tokens is

another means of

achieving secure

transactions as against

the use of human

features in biometrics.

It is costly to implement

because of the

introduction of hardware

token.

33

Authentication in an

Internet Banking

Environment by the US

Federal Financial

Institutions Examination

Council.

(http://www.ffiec.gov/)

The USB token is a

relatively secure

vehicle for storing

sensitive data and is

generally considered

to be user-friendly

The introduction of the

USB token still adds to

the cost.

Enhancing ATM security

using fingerprint and

GSM technology by

Ashish M. Jaiswal and

Mahip Bartere, 2014.

Fingerprint biometric is

used along with GSM

technology to enhance

security.

The addition of

biometrics introduces

more complexity in terms

of hardware and

software.

Facial Verification

Technology for Use in

ATM Transactions by

Aru, Okereke Eze,

Ihekweaba Gozie, 2013.

In real time

applications, this

approach gives good

results.

Facial Verification is quite

complex.

Designing a Biometric

Strategy (Fingerprint)

Measure for Enhancing

ATM Security in Indian E-

Banking System by Sri

Shimal Das, Smt. Jhunu

Using fingerprint

biometrics ensures a

high level of ATM

security.

The proposed system is

quite complex: it contains

about five intricate

components.

34

Debbarma, IJICT, Vol. 1,

No. 5, September 2011.

Advantages of the proposed two factor authentication: Pin and SMS

Password Model over the Above Compared Models

(1) Cost Effectiveness: the proposed model employs already existing ATM,

Internet and GSM infrastructure without needing additional resources in the

form of hardware and software as is the case with designs that involve

biometrics.

(2) Less Complexity: the proposed model achieves lesser complexity because

of no additional hardware or software resources. Complexity is an obvious

disadvantage of the above compared technologies.

2.2 Review of the Technologies involved in the proposed Design

The proposed system involves various technologies that serve unique purposes

in the operation of the system. These technologies are reviewed from section

2.2.1 to section 2.2.4.

2.2.1 Authentication Mechanisms employed in electronic banking

Authentication is the process of verifying a claim made by a subject that

it should be allowed to act on behalf of a given person, computer,

process, etc. Also, Authentication can be defined as the process of

determining whether someone or something is, in fact, who or what it is

declared to be. Authentication works closely with Identification and

Table 2.1: Comparison Table for the related works

35

authorization. Identification can be defined as the process of pinpointing

(identifying) someone or something while Authorization can be defined as the

process of giving someone permission to do or have something.

Authentication can be accomplished with, for instance, a password while

Identification can be accomplished with a username, a smart card, or anything

else that can uniquely identify a subject. Once a user is identified and

authenticated, they can be granted authorization based on their proven

identity [10].

It is imperative to understand the difference between authentication,

identification and authorization. Identification occurs when a person claims an

identity (such as with a username) and authentication occurs when a person

proves their identity (such as with a password). Once the person has a proven

identity, authorization techniques can then grant or deny access to services

based on his proven identity [11].

Authorization, involves verifying that an authenticated subject has

permission to perform certain operations or access specific resources.

Authentication procedures are based on three factors related to the user:

i.e. the person who is authenticating, say a transaction in Internet

Banking [12].

They are;

What the user knows: This includes Username, Password, PIN, etc.

What the user possesses: This includes USB token, Smart Card,

SMS/Token, One Time Password (OTP), etc.

What the user is: This refers to features that are peculiar to the user

such as fingerprint, Palm print, IRIS, Retina, Voice, etc.

36

There are three kinds of authentication mechanisms, they are;

Single Factor Authentication; this authentication mechanism utilizes only one

of the factors. For example, a Username (User Knows). This is the basic

authentication method [13].

Two Factor Authentication; this authentication mechanism utilizes any two of

the factors. For example, a User using a password as the first factor (User

knows) and a One-Time Password (OTP) as the second factor (User

possesses) to gain access to their account or perform ,for instance, a funds

transfer transaction[13].

Multi Factor Authentication; this authentication mechanism utilizes more than

two of the factors and one of the factors is necessarily a “User is” type. For

example, a large value transaction authorized in a bank by using a combination

of the person’s username, a smart card and his biometric authentication factor

like fingerprint [13].

Multi factor authentication provides users higher levels of protection from

online banking fraud. By employing biometrics (User is) as one factor; Multi

factor authentication improves security for online banking customers and

reduces online fraud. This authentication can be provided for the customers

(corporate or individual customers) who make transactions beyond the

threshold value that was set up by the bank.

Usually, in online Banking a Two Way or Mutual authentication can be

provided between the user and the Organization. It refers to two parties

authenticating each other. When describing online authentication processes,

mutual authentication is referred to as website-to-user authentication. By

means of this authentication, the user knows that they are on the valid

37

banking website. Mutual authentication can be implemented by providing

some challenge questions. The customer provides the challenge questions

along with the answers and selects the image (identifiable pictures), image

title and a text phrase (optional) from a collection of images which are

provided in the banking website at the time of enrolment. The customer

can further change this image during his first login. Further when the customer

enters login id and before entering the password, the site asks these

challenge questions and when the user answers them correctly, it displays

the image, title and phrase. A typical example of a challenge question is

“what is your favourite meal?” A typical answer is “Fufu”. If the displayed

image is correct then customer can enter the password and login in. If not

the customer can stop logging in and contact the bank. This makes the

customer to know whether it is a real banking website or fake

website[8]. This facility provides the customer and server the means to

authenticate mutually so that we can reduce Phishing Attacks: this is an

attack aimed at acquiring sensitive information such as usernames, passwords,

or ATM/credit card details by masquerading as a trustworthy person or entity

in an electronic communication[14].

2.2.2 The ATM System Technology

Basically, the ATM is a computer system which grants Bank clients access to

financial transactions from a public space, thereby discarding the need for a

customer to visit any bank’s branch [2]. Figure 2.1 clearly shows a typical ATM

Machine.

38

The ATM must be connected to a network in order to achieve its purpose (see

fig. 2.2). With the aid of the ATM, customers would be able make cash

withdrawals, check the balances on their accounts or even pay their bills.

Display Screen

Card Reader

Receipt Printer

Fig. 2.2: Diagram for the ATM Connected to a Network

ATM

ATM

ATM

ACCOUNT

BANK

COMPUTER/HOST -

PROCESSOR

ACCOUNT

ACCOUNT

ACCOUNT

Fig. 2.1: A Typical ATM Machine (Source: circuitstoday.com).

Key Pad

Speaker

Cash Dispenser

39

Operation of the ATM Connected to a Network

When a cardholder wants to do an ATM transaction, they provide the

necessary information by slotting their ATM Card into the ATM’s card reader

and when requested, they provide their personal identification number (PIN)

by entering it via the keypad.

The ATM forwards this information to the Bank Computer (also known as host

processor), which routes the transaction request to the cardholder's bank or

the institution that issued the card. If the cardholder is requesting cash, the

host processor causes an electronic funds transfer to take place from the

customer's bank account to the host processor's account.

Once the funds are transferred to the host processor's bank account, the

processor sends an approval code to the ATM authorizing the machine to

dispense the cash [2].

ATMs include many other functions which are not directly related to the

management of one's own bank account, such as the functions below [2]:

• Deposit currency recognition, acceptance, and recycling.

• Paying utility bills, fees, and taxes (utilities, phone bills,

• Printing bank statements.

• Updating passbooks.

• Loading monetary value into stored value cards.

• Purchasing.

• Postage stamps.

• Lottery tickets.

• Train tickets.

• Concert tickets.

• Movie tickets.

40

• Shopping mall gift certificates.

• Games and promotional features.

• Donating to charities.

• Cheque Processing Module.

• Adding pre-paid cell phone credit.

An ATM has the following two input devices [2]:

(1) Card reader- The card reader captures the account information stored on

the magnetic stripe on the back of an ATM card. The host processor uses this

information to route the transaction to the cardholder's bank.

(2) keypad/Function buttons - These let the cardholder tell the bank what kind

of transaction is required (cash withdrawal, balance inquiry, etc.) and for what

amount. Also, the bank requires the cardholder's personal identification

number (PIN) for verification.

An ATM has the following four output devices [2]:

(1) Speaker- The speaker provides the cardholder with audio feedback when a

key is pressed.

(2) Display screen- The display screen prompts the cardholder through each

step of the transaction process.

(3) Receipt printer- The receipt printer provides the cardholder with a paper

receipt of the transaction.

(4) Cash dispenser- The heart of an ATM is the safe and cash-dispensing

mechanism. The entire bottom portion of most small ATMs is a safe, because it

contains the cash.

41

2.2.2.1 The ATM Hardware

Figure 2.3 shows the block diagram of the ATM and its component devices.

Typically the ATM hardware comprises the following devices [2].

Central Processing Unit (CPU): This is simply a computer system which is used

to control the user interface and all the other devices. Most deployments make

use of the same CPUs found in desktop computers and laptops; CPUs like Intel

Pentium 4, Intel Core i7 and AMD VISION PRO.

Card Reader: The card reader embodies the mechanism that acquires the

account information stored on the chip on the back of an ATM card in order to

identify the customer. The host processor uses this information to route the

transaction to the cardholder's bank.

Encrypting PIN Pad (EPP): This looks much like a calculator keypad. The EPP

contains the security processor, the software function, the encryption keys and

memory to locally perform the PIN-encryption function.

Fig. 2.3: Block diagram for the ATM (Source: Wikipedia.org).

CPU EPP

CARD

READER

CASH CARTRIDGE

CASH CARTRIDGE

CASH CARTRIDGE

CASH CARTRIDGE

HOUSING

VAULT

CASH HANDLING MECHANISM

DISPLAY SCREEN and FUNCTION BUTTONS

42

Secure Crypto-Processor: This is a dedicated microprocessor for carrying

out cryptographic (encrypting) operations. It is embedded in a packaging

within a secure enclosure so that it maintains a degree of tamper resistance.

The security of the machine depends heavily on the integrity of the secure

crypto-processor.

Display: This is basically a computer monitor built into the ATM and used by

the customer for performing the transaction.

Function Key Buttons: These buttons are usually located close to the display

and are programmed to perform specific actions like selecting the type of

transaction involved and the amount.

Record Printer: This prints out a record of the customer’s transaction. The

transaction record is normally printed out on a small paper slip.

Vault: This is a secure enclosure that safeguards money and parts of the

machinery that require restricted access. It is intended to protect these from

theft, unauthorized use, fire, natural disasters, and other threats, just like

a safe. Usually, the Vault contains the following Mechanisms: Dispensing

mechanism that provides the cash, Deposit mechanism which allows the

customer to make deposits, Security sensors, Locks that ensure controlled

access to the contents of the vault, Journaling systems like the record printer

or some form of electronic memory that keeps record of transactions, etc [2].

Housing: The housing provides the ATM with the necessary shelter, aesthetics

and physical security.

2.2.2.2 The ATM Software

Standard commercial "off-the-shelf" operating systems and programming

environments can be used inside of ATMs. Typical platforms previously used

43

on ATMs include Real time Multitasking Executive (RMX) or Operating

System/2 (OS/2) [1].

Today, most of the ATMs worldwide (over 95%) use Microsoft Windows XP.

Windows XP is a personal computer operating system produced by Microsoft.

The operating system was released to manufacturing on August 24, 2001, and

generally released for retail sale on October 25, 2001.

Windows XP is well known for its security, stability and efficiency due to its use

of Windows NT Kernel. Unlike its predecessors such as Windows 2000 and

Windows ME, it introduced a significantly redesigned graphical user

interface and was the first version of Windows to use product activation in an

effort to reduce software piracy.

Windows XP offers Internet features such as Internet Explorer 6, Outlook

Express 6, Windows Messenger and MSN Explorer. New networking features

were also added to XP, including Internet Connection Firewall, Internet

Connection Sharing, Quality of Services features, Internet Protocol version 6

(IPv6), network bridging, peer to peer networking, support for most DSL

modems, IEEE 802.11 (Wi-Fi) connections with auto configuration. Remote

Assistance and Remote Desktop were also added; these two allow users to

connect to a computer running Windows XP from across a network or the

internet and access their applications, files, printers and devices [15]. Table 2.2

below shows the Windows XP System Requirements.

Central Processing Unit (CPU) X86 (Intel Pentium) or compatible

CPUs (e.g. AMD Athlon).

Memory 256 MB.

Hard Drive 1.5 GB.

44

Media CD-ROM drive or compatible ones.

Display Super Visual Graphics Adaptor (VGA).

Sound Hardware Sound Card, Speakers and head

phones.

Input Devices Keyboard, mouse, etc.

ATM Vendors and financial institutions have a wide range of Application

Programs to drive their machines. These programs run on the aforementioned

Operating System. The Application Programs are developed using any of these:

Extensions for Financial Services (XFS), Java Extensions for Financial Services

(J/XFS) and XPEAK [1].

(1) Extensions for Financial Services (XFS)

The XFS standard was initiated by Microsoft in the early 90's and it was called

WOSA/XFS. The acronym stands for Windows Open Services

Architecture/Extension for Financial Services. As it became an international

standard adopted by the European Committee for Standardization (CEN), it

then became known as CEN/XFS. The CEN/XFS standard defines a common

language to speak with the hardware components of the Automated Teller

Machine (ATM).

The architecture of CEN/XFS is similar to a client-server model, where the

server knows how to drive a particular ATM hardware component. The server

must publish a standard interface which is common for all similar hardware

components. The client application programm benefits from the services

Table 2.2 Windows XP System Requirements (Source: http://en.wikipedia.org/

wiki/Microsoft_windows_xp).

45

provided by the server (also called Service Provider or SP) and uses its

standardized interface to drive hardware components from different

manufacturers with the same set of commands.

This is a huge benefit, because it virtually unifies different ATM platforms, and

creates a common environment for the ATM applications all over the world

[16].

CEN/XFS shares a common conceptual background with Microsoft Windows

device drivers. This common conceptual background with Microsoft Windows

device drivers is hinged on forward compatibility. For instance, Windows

drivers are designed to be forward-compatible such that a Windows driver can

run on a version of Windows newer than what the driver was initially written

for, but doing that would mean that the driver cannot take advantage of any

new features introduced with the new version [17]. In the same way CEN/XFS

ensures that client applications can run on a version of the server that is newer

than what the application was initially written for.

Also Windows drivers are generally not backward-compatible: a Windows

driver is not guaranteed to run on any older version of Windows. For example,

a driver written for Windows 2000 can work on Windows XP (which is higher)

but will not make use of any of the new features that were introduced in

Windows XP. However, a driver written for Windows XP may or may not load

on Windows 2000. In the same manner CEN/XFS allows that client applications

may not run on a version of the server that is older than what the application

was initially written for.

(2) XPEAK

Xpeak aims to become the standard for devices management, not only in the

financial arena, but also for all market types. It is a question of creating a

46

standard which is independent of the operating system and the programming

language, as well as of the communications interface (Sockets, Web Services,

USB, etc.) which is used to send messages in XML (Extensible Markup

Language) format.

Xpeak is not an acronym and the name itself is indicative of its main objective:

to communicate with devices (speak) using Xml. It aims to homogenise the

messaging between an application and a device; to communicate

independently of the language used by the application. In fact, it is possible

that it could achieve an architecture in which, to give one example, an

application could be developed in Java and use Xpeak Services from different

suppliers, some implemented in Java, others in C++ and still others in the

device's firmware [18].

For further illustration, the example in fig. 2.4 shows the Xpeak architecture.

The figure shows the ATM application program that communicates (speaks)

with a peripheral device such as the Encrypting Pin Pad (EPP) or Record Printer

using XML Commands like XPEAK_COMMAND_READ (which enables the ATM

to read from the EPP) or XPEAK_COMMAND_PRINT (which enables the ATM

to print from the printer). The ATM application program could be written in

any of the popular programming languages like C++, C#, Java, etc. It does not

matter who the manufacturer of the ATM or the peripheral device is. It also

does not matter the language used to write the ATM application program or

the Xpeak services/drivers that come with the peripheral devices. All that

matters is that the ATM application program sends the XML commands to the

peripheral devices of the ATM [18].

47

Fig. 2.4: Xpeak architecture

(3) Java Extensions for Financial Services (J/XFS)

Recognising the advantages of the Java language for developing finance

industry applications, representatives of Diebold, IBM, NCR, Talaris, Wincor

Nixdorf International GmbH and Sun Microsystems, embarked on an effort to

develop a set of standard Java interfaces in support of the unique input and

output peripheral devices used in the finance industry at various access

channels including Branch Teller and Platform, Self-Service and Call Centre.

This new standard is called J/XFSTM (Java eXtensions for Financial Services) for

the JavaTM platform. This initiative has produced a finance industry standard

for financial I/O devices that supports 100% pure Java applications while

leveraging existing standards [19].

Utilizing the Java language, J/XFS provides a standard for a banking device

subsystem with real platform and hardware independence which enables the

access to banking peripherals for new Java banking applications. It also

provides a migration path for current financial I/O subsystems and ensures co-

existence between current Client/Server and new Java banking applications, so

customer investments in banking device infrastructure are protected.

ATM application program

ATM’s peripheral devices

XML

48

J/XFS enables full transparency between the application and the device level

[19].

Peripheral Devices supported by the CEN/XFS, J/XFS, XPEAK specifications

The following devices are supported by the CEN/XFS, J/XFS, XPEAK

specifications:

Printers and Scanners

Identification Card Units

Cash Dispensers

Personal Identification Number Keypads

Check Readers and Scanners

Depository Units

Text Terminal Units

Sensors and Indicators Units

Cameras

Alarms

Card Embossing Units

Cash-In Modules

Card Dispensers

Barcode Readers

Item Processing Modules

49

2.2.3 Short Message Service (SMS)

Figure 2.5 shows the main components of SMS network architecture.

Fig. 2.5: SMS network architecture

When routing a mobile originated short message service, the Short Message

Service Center (SMSC) forwards the short message to the Short Message

Service Gateway Mobile Services Switching Center (SMS-GMSC). The SMS-

GMSC interrogates the Home Location Register (HLR) for routing information

when the Handset is in the HLR’s geographical area of coverage but when it is

not, the Visitor Location Register (VLR) that covers the geographical area in

question is interrogated for routing information. The SMS-GMSC then sends

the short message to the appropriate Mobile Services Switching Center (MSC).

The MSC delivers the short message to the Handset, otherwise known as the

Mobile Station (MS). On the other hand, when routing a mobile terminated

short message, the MS addresses the required SMSC according to its global

title. If roaming abroad the visited public limited mobile network (PLMN) will

route the short message to the appropriate Short Message Service

Interworking Mobile Services Switching Center (SMS-IWMSC) [20].

The SMSC identifies each short message uniquely by adding a time stamp in

the SMS-DELIVER TP-SCTS field (TP-SCTS: Transfer Protocol Service Center Time

SMSC SMS-GMSC/

SMS-IWMSN MSC MS

HLR VLR

50

Stamp). The short message arrival at the SMSC is accurate to the second. It is

the SMSC’s responsibility to assure that if two or more short messages arrive

within the same second their time stamps will be different.

The MS has to be able to receive/submit a short message Transfer Protocol

Data Unit (TPDU), and then return a Delivery report upon successful reception.

It is also responsible for notifying the network when it has memory capacity

available to receive one or more messages, if it had previously rejected a short

message because its memory capacity was exceeded [20].

2.2.3.1 Bulk SMS Service

Sending instant discrete messages is undertaken by SMS while the medium

of Bulk SMS enables an organization or institution to reach the masses with

the same notification at the same time.

There are many advantages of this technology but the most eminent one is its

time saving feature that makes it so much preferred. One can send thousands

of SMS to many people in just a few minutes.

A lot of software that allows the use of Bulk SMS directly from the personal

computer is available on the internet. Also there are numerous bulk SMS web

sites that provide the SMS Gateway for bulk SMS and also provide all the

related services necessary for any type and size of organization. The Bulk SMS

solutions include user-friendly software that makes the task of sending

messages in bulk quite easy [21].

The Bulk SMS Service relies heavily on the SMS GATEWAY. The SMS Gateway is

a service which allows a computer to send or receive SMS to or from a

telecommunications network [22]. Bulk SMS web sites (service providers)

provide the SMS Gateway. For someone to utilise the SMS Gateway, they have

51

to open an account with the Bulk SMS Service Provider on their website for a

fee. The SMS Gateway used in this work is provided by “eTextmail”. This

service provider is based in Lagos, Nigeria. Their website is

http://www.etextmail.com.

2.2.4 Mechanism employed in this work for sending the One Time Password

The mechanism that sends the One Time Password comprises the proposed

ATM software, an SMS gateway and SMS Network (GSM) as shown in figure

2.6.

Fig. 2.6: Mechanism for sending the One Time Password

During authentication, the ATM software sends the OTP and the destination

phone number, through the internet, to the SMS Gateway. The SMS Gateway

then sends the OTP and the destination phone number, through the internet,

to the SMS Network. Afterwards, the SMS Network sends the OTP to the

destination phone number, through the Global System for Mobile

Communication (GSM).

The destination phone number is the customer’s phone number, which in this

case is the number of the author of this thesis.

SMS

GATEWAY

SMS NETWORK

(GSM) MOBILE

PHONE

ATM

SOFTWARE

(OTP)

52

CHAPTER THREE

RESEARCH METHODOLOGY

3.1 Methods Adopted for this Work

The methodology for this work is Object Oriented Analysis and Design (OOAD)

along with Modelling and Simulation using Unified Modelling Language (UML)

and C# respectively. This chapter elaborately discusses the elements of OOAD

and UML. Here the key elements of OOAD are exposed and illustrated using

the ATM.

3.1.1 Object Oriented Analysis and Design (OOAD)

Object-oriented analysis is a Software Engineering method which focuses on

the analysis that examines requirements with respect to the classes and

objects found in the description of the problem domain. Object-oriented

design refers to the method of Software design which includes the process of

object-oriented decomposition and a notation for portraying the logical and

physical, as well as static and dynamic models of the system being designed. In

object oriented decomposition we identify objects from the vocabulary of

the problem domain and view them as a collection of independent

agents that collaborate to exhibit a certain higher level behaviour [23].

Normally in the design of software systems, using the object oriented

approach, the two methods above are combined; hence we have Object

Oriented Analysis and Design (OOAD). Basically, it is the products of

object oriented analysis that serve as the models from which an object-

oriented design is started; the products of object-oriented design can then be

made use of as blueprints for the complete realisation of a system using

object-oriented programming methods.

53

OOAD places data and the operations that are related to them within a single

entity called an object; this approach has eliminated many of the

problems that are associated with the procedural approach to software

development. In OOAD everything is an object and every object has

attributes and actions associated with it. Therefore each object in OOAD

models a certain object in the real world. This approach organizes programs

in a way that so-closely resembles the real world, in which all objects

are associated with both attributes and behaviour. With the use of OOAD

software reusability is very much improved and the development,

improvement and maintenance of software become remarkably easier than it

used to be under the procedural approach [23].

In Object-Oriented Analysis and Design, the following Terms are frequently

employed: Object, Class, Encapsulation, Inheritance, and Polymorphism.

I. Object: In real life, an Object is a visible and tangible thing or entity [24].

For instance, a chair is an object. Likewise a living creature like a dog is

an object. Objects have two characteristics: they

have state and behaviour. For instance, a car has states such as “current

gear, current speed” and it has behaviour such as “changing gear,

applying brakes”.

The ATM has states such as “ATM not servicing a customer, asking for

entry of PIN, displaying menu of transaction types, asking whether

customer wants to perform another transaction” and it has behaviour

such as “ATM system ejects card, system ejects cash, system displays an

error screen”. Identifying the state and behaviour for real-world objects

is a good way to start in carrying out Object Oriented Analysis and

Design.

54

II. Class: A class is a family of related objects. In other words an object is

the instance of a class. A class is the template used to create uniform

individual objects [24]. For example, there are different types of cars:

Saloon, Wagon, etc. Though these cars have different qualities and

features, they still belong to that one family of machines called cars. This

family is the class. Thus we can have a Car Class. A class is the blueprint

from which individual objects are created whereas the individual objects

are simply the instances of the class.

In the ATM, there could be many classes such as Account Information,

Banking Class, Transaction Class, ATM Class, etc. Each of these classes is

a family of related instances of the class (objects) along with

properties/attributes and behaviour/methods. For instance, the Account

Information Class could have such objects as, account type, time of last

transaction, minimum balance, date of account opening, along with

methods such as checkbalance(), checkdate() and properties such as

currency, transaction history, etc (see figure 3.1).

Fig. 3.1:

III. Encapsulation: This is an Object Oriented Concept that allows Objects of

a class to hide their internal states in fields or variables but expose their

behaviour through methods or functions [24]. It is also known as class

encapsulation. Class encapsulation is interwoven with class abstraction.

Class Name

Properties (Attributes)

Methods (Behaviour)

Account Information

Currency Transaction History

checkdate() checkbalance()

Fig. 3.1: Typical diagram of a class

55

Class abstraction is the separation of a class implementation from how

the class is used. The creator of a class describes the functions of the

class and lets the user know how the class can be used. The collection of

methods and fields (properties) that are accessible from outside the

class (public), together with the description of how these members are

expected to behave, serves as the class’s contract. As shown in Figure

3.2, the internal state of the class is hidden in variables and constants

while its behaviour is exposed through methods. Also the user (client) of

the class does not need to know how the class is implemented. The

details of implementation are encapsulated in the methods and fields

and hidden from the user. This is also known as information hiding.

IV. Inheritance: Inheritance enables a software designer to define new

classes from existing classes. It enables the definition of a general class

and later extends it to more specialized classes. Object-oriented Analysis

and Design allows classes to inherit commonly used state and behaviour

from other classes [24]. When creating a class, rather than declaring

completely new members, the software designer can designate that the

new class should inherit the members of an existing class. The existing

class is called the superclass, and the new class is the subclass. A

subclass normally adds its own fields and methods. Therefore, a subclass

is more specific than its superclass and represents a more specialized

Fig. 3.2: Encapsulation hides the class’ state and implementation from the

user(client).

Class

implementation

is like a black

box hidden from

the clients

Class

Class Contract (features of

public methods and public constants)

Clients use the

class through

the contract of

the class.

56

group of objects. Typically, the subclass exhibits the behaviours of its

superclass and additional behaviours that are specific to the subclass.

The ATM software could have such classes as “Withdrawal Class, Deposit

Class and transfer class”. These classes have some qualities in common

with each other. One common quality amongst them is that each one of

them is a type of transaction. In this case they would be subclasses that

inherit the features of a superclass that contains the qualities that they

have in common (see figure 3.3). Such a superclass could be named

“Transaction Class”. An arrow headed line points to the superclass.

V. Polymorphism: Polymorphism enables the development of software

that process objects that share the same superclass in a class hierarchy

as if they are all objects of the superclass. It is the provision of a single

interface (method) to entities (objects) of different types [24]. With

polymorphism, the same method name and signature can be used to

cause different actions to occur, depending on the type of object on

which the method is invoked. Polymorphism means “many forms”.

Fig 3.3: Withdrawal class, Deposit class and Transfer class inherit from

Transaction class as shown with a small triangle pointing to the superclass.

Deposit Class

Shared Properties

Shared Methods

Withdrawal Class

Shared Properties

Shared Methods

Transfer Class

Shared Properties

Shared Methods

Transaction Class

Shared Properties

Shared Methods

57

Consider the following example of polymorphism. In the illustration in

figure 3.3, “withdrawal class, deposit class and transfer class” are

subclasses of the superclass “transaction class”. Transaction class

contains a method “execute” which carries out a transaction. Each

subclass implements the “execute” method. When the program sends

the same message (execute) to objects of these classes, each class will

respond to the “execute” message in a unique way: withdrawal will

release money to a customer, deposit will accept money from a

customer while transfer will send money to a different account

somewhere else. Relying on each object to know how to "do the right

thing" (i.e., do what is appropriate for that type of object) in response to

the same method call is the key concept of polymorphism. The same

message (in this case, execute) sent to a variety of objects has "many

forms" of results, hence the term polymorphism.

In this chosen methodology, Software Engineering principles are employed in

analysing and designing the system in question. Basically, this involves the use

of Object Oriented Analysis and Design (OOAD) along with a suitable Software

Development Life Cycle (SDLC). The Waterfall Model is the Software

Development Life Cycle of choice in this work.

In applying the Waterfall Life Cycle to this design, Object Oriented Analysis and

Design (OOAD) is employed at the appropriate stages of the Life Cycle.

3.1.1.1 The Waterfall Model Software Development Life Cycle

Software in its nature is intangible, time consuming and requires a lot of

resources. Because of this nature of software, a haphazard approach towards

the development of software has to be avoided and a disciplined process

adopted. This process otherwise known as Software Development Life Cycle

58

(SDLC) is a collection of defined activities, actions and tasks that are performed

when software is to be created.

The Waterfall Model is the “SDLC” of choice in this project. Waterfall approach

was the first Process Model to be introduced and followed widely in Software

Engineering. In this project the Waterfall Model is preferred for the following

reasons;

Easy to understand: The stages and activities of the waterfall model are

well defined and therefore easy to comprehend·

It is widely used and known such that resources on it are readily and

easily available.

Being a linear model and progressing sequentially from one stage to the

next, it is very simple to implement.

It’s a good model to start with for someone with limited software design

experience.

Phases are processed and completed one at a time and not overlapped

with one another.

The amount of resources required to implement this model is minimal.

It ensures that all requirements and features are defined before design

and coding.

Generally, this model leads to a project being delivered on time because

each phase has already been planned in detail.

In "The Waterfall" approach, the whole process of software development is

divided into separate process phases.

The phases in Waterfall model are: Requirements Definition phase, Software

Design, Implementation, Integration and Testing, Operation and Maintenance.

All these phases are cascaded to each other so that second phase is started as

59

and when defined set of goals are achieved for first phase and it is signed off,

so the name "Waterfall Model" [24]. All the methods and processes

undertaken in Waterfall Model are more visible. Figure 3.1 clearly shows the

Waterfall model and its stages. In this figure each later stage has a bold arrow

headed dashed line that points upwards to the immediate earlier stage and

that is called interstage feedback. The interstage feedback implies that a stage

preceding an ongoing stage could be revisited for any necessary revision. The

interstage feedback is a modification on the original waterfall model which has

no feedback.

Operation and

Maintenance

Integration and

System Testing

Implementation

and Unit Testing

System and

Software Design

Requirements

Analysis and

Definition

Fig. 3.4: The Waterfall Model (with interstage feedback)

60

The stages of "The Waterfall Model" are:

Requirements Analysis & Definition: All possible requirements of the system

to be developed are captured in this phase. Requirements are set of

functionalities and constraints that the end-user (who will be using the system)

expects from the system. The requirements are gathered from the end-user by

consultation, these requirements are analysed for their validity and the

possibility of incorporating the requirements in the system to be developed is

also studied. Finally, a Requirement Specification document is created which

serves the purpose of guideline for the next phase of the model.

System & Software Design: At this stage Object Oriented Analysis and Design

(OOAD) is done. Before starting the actual coding, it is highly important to

understand what we are going to create and what it should look like. The

requirement specifications from first phase are studied in this phase and

system design is prepared. System Design helps in specifying Hardware and

Software systems requirements and also helps in defining overall system

architecture. The system design specifications serve as input for the next phase

of the model.

Implementation & Unit Testing: On receiving system design documents, the

work is divided in modules/units and the actual coding is started. At this stage

Object Oriented Programming (OOP) is done. The system is first developed in

small programs called units, which are integrated in the next phase. Each unit

is developed and tested for its functionality; this is referred to as Unit Testing.

Unit testing mainly verifies if the modules/units meet their specifications.

Integration & System Testing: As specified above, the system is first divided in

units which are developed and tested for their functionalities. These units are

61

integrated into a complete system during Integration phase and tested to

check if all modules/units work well with each other and if the system as a

whole behaves as per the specifications. After successfully testing the

software, it is delivered to the customer.

Operations & Maintenance: This phase of "The Waterfall Model" is virtually a

never ending phase (Very long). Generally, problems with the system

developed (which are not found during the development life cycle) come up

during operations, so the issues related to the system are solved after

deployment of the system. Not all the problems appear initially but they arise

from time to time and need to be solved; hence this process is referred as

Maintenance.

Advantages and Disadvantages of Waterfall Model

Advantages

The advantage of waterfall development is that it allows for

departmentalization and managerial control. A schedule can be set with

deadlines for each stage of development and a product can proceed through

the development process like a car in a carwash, and theoretically, be

delivered on time. Development moves from concept, through design,

implementation, testing, installation, troubleshooting, and ends up at

operation and maintenance. Each phase of development proceeds in strict

order, without any overlapping or iterative steps.

Disadvantages

The disadvantage of waterfall development (without feedback) is that it

does not allow for much reflection or revision. Once an application is in the

testing stage, it is very difficult to go back and change something that was not

well-thought out in the Concept/Requirements Analysis and Definition stage.

62

3.1.2 Modelling and Simulation

This software system employs the Unified Modelling Language (UML). The

UML is found very useful in developing the visual models of a whole lot of

systems.

UML is the industry-standard language for specifying, visualizing, constructing,

and documenting the artefacts of software systems, as well as other non-

software systems [4]. UML simplifies the complex process of software design,

making a "blueprint" for construction, and is now the standard notation for

software architecture.

The following UML diagrams are used in this work:

Use Case Diagram: This shows a set of use cases and actors (a special kind of

class) and their relationships. A use case is a set of functionalities provided by

an entity (system) as a service to actors. A use case shows the features of a

system [4]. Use case diagrams address the static use case view of a system,

these diagrams are important in organizing and modelling the behaviours of a

system. Figure 3.5 shows a typical Use Case Diagram, the diagram shows how

an actor (user) interacts with the system by accessing the various

functionalities. In the Use Case diagram, the use cases are displayed as ovals.

The actor is connected by lines to the use cases that he carries out. The Use

Case Diagram for the proposed system is shown in chapter 4, figure 4.3

63

Fig. 3.5: A typical Use Case Diagram

Class Diagram: This shows a set of classes and their relationships [4]. Class

diagrams are the most common diagrams used in modelling object-oriented

systems. The classes represent the things that are handled in the system.

Classes can be related to each other in a number of ways: they can be

associated (connected to each other), dependent (one class depends on or

uses another class), etc. All these relationships are shown in a class diagram

along with the internal structure of the classes in terms of attributes

(properties) and operations (methods). Figure 3.6 shows a typical Class

Diagram. In the diagram, class1 is in an association relationship with class2;

where N objects of class1 are associated with N objects of class2 as shown by

the Ns at the end of the horizontal line linking the two classes. An association

relationship basically means that objects of one class are simply connected to

objects of the other class. Class3 is in an inheritance relationship with class2 as

shown by the arrow headed line pointing up from class3 to class2. The Class

Diagram for the proposed system is shown in chapter 4, figure 4.4.

Functionality1

Functionality2

Functionality3 Actor

System

64

Fig. 3.6: A typical Class Diagram

Sequence Diagram and Collaboration Diagram: These are interaction

diagrams. Interaction diagrams address the dynamic view of a system.

Sequence diagram emphasizes the time ordering of messages between objects

in the system, while collaboration diagram emphasizes the structural

organization of the objects that send and receive messages [4]. Sequence

diagrams and collaboration diagrams are isomorphic, and can be transformed

from one into the other. Since either of them contributes to the same extent in

the understanding of our system and the sequence diagrams give more ideas

of time, which is essential for real time systems, then only the Sequence

Diagram is given and used in this work. The Sequence Diagram for the

proposed system is shown in chapter 4, figure 4.1.

Sequence diagrams describe interactions among objects by depicting the time

ordering of their communication, i.e. method invocations. The typical

sequence diagram shown in figure 3.7 consists of the following elements:

N N

Class 1

Properties

Methods

Class 3

Class 2

Properties

Properties

Methods

Methods

65

Class role represents the role an object plays. The objects at the top of

the diagram represent class roles.

Lifeline represents the existence of an object over a period of time. A

vertical dashed line extending from the object is used to denote a

lifeline.

Activation represents the time during which an object is performing an

operation. Thin rectangles placed on lifelines are used to denote

activations.

Method invocation represents communications between objects.

Horizontal arrows labelled with method calls are used to denote method

invocations.

Class Role Object1 Object2

Activation

Method1

Method2

Method Invocation

Method Invocation

Fig. 3.7: A typical Sequence Diagram

66

Activity Diagram: This a special kind of State chart diagram showing the flow

from activity to activity within the system [4]. Figure 3.8 shows a typical

Activity Diagram. The activity diagram shows a sequential flow of actions. It

depicts the dynamic behaviour of a system or part of a system through the

flow of control between actions that the system performs. It consists of

actions, which are the basic unit of behaviour that make up an activity. It is

similar to a flowchart except that an activity diagram can show concurrent

flows.

The activity diagram has a number of features such as control nodes for

showing control flows. Control nodes are used to guide the flow of control

through a group of activities and actions. Control nodes are in a variety of

forms. The control nodes are as follows [see figure 3.8];

Initial Node: A sequence of activities or actions is started with an initial node.

An initial node is shown as a large dot.

Final Activity Node: The final-activity node is used to end all control flows and

object flows in an activity. It is shown as a white circle with a large dot inside.

Action Node: The action node represents a simple piece of behaviour. The

action node is shown as a rectangle that is rounded at the edges. The name of

the behaviour is placed as text inside the rounded rectangle.

Control Flow Line: This is the arrow headed line that connects actions and

activities together. It shows the sequence of execution.

Decision Node: A decision node uses a test to make sure that an object or

control flow goes down only one path. This node is used when there is need to

construct an if-then-else selection for an execution path. A decision node is

indicated with a large diamond shape. A control-flow arrow is drawn to

67

connect the diamond with each downstream activity or action. The decision

criteria for each path is placed in square brackets on the control flow line.

Fork/Join: Sometimes it is necessary for actions to work in parallel. To split

behaviour into concurrent operations, the fork node is used. A fork node looks

like a fork. A fork node is depicted with one line going into the fork and

multiple lines coming out from the other side. A join node is the opposite of a

fork node. It is used to bring parallel flows of operations back together. Its

symbol looks like the mirror image of a fork.

The Activity Diagram for the proposed system is shown in chapter 4, figure 4.2

[Decision Criterion1]

[Decision

Criterion2]

Fig. 3.8: A typical Activity Diagram

State 1

State 2

Initial Node

Join Node

Control Flow Line

Decision Node

Action Node

Final Node

68

Deployment Diagram: This shows the configuration of run-time processing

nodes (Hardware) [4]. Deployment diagrams show the physical architecture of

a system. It is essentially a connected arrangement of hardware. The hardware

nodes are represented as three-dimensional boxes. Any type of hardware that

can execute software and talk to other hardware devices—for example,

printers, modems, scanners, and external disk drives—are represented as

nodes on a deployment diagram.

Lines are drawn between nodes to represent communication paths between

the hardware components. The communication paths represent such things as

local area networks, GSM Network, Radio Frequency (RF) Network, the

Internet, a USB cable, or any mechanism that links one node to another. Figure

3.9 shows a typical Deployment Diagram. The Deployment Diagram for the

proposed system is shown in chapter 4, figure 4.5.

Hardware1

Hardware3 Hardware4

Hardware2

Fig. 3.9: A typical Deployment Diagram

69

The aforementioned diagrams capture different information about any

particular software system. Each diagram constitutes a separate visual model

of a system. By assembling these models into one document, a clear and fully

descriptive visual model of a system is obtained and that is the UML model of

the system. The UML modelling for the proposed system is shown in chapter 4,

section 4.1.1.

The coding of this system employs C# (C Sharp) Programing Language and the

necessary simulation employs the popular Software Development tool called

Microsoft Visual Studio 2010.

70

CHAPTER FOUR

SYSTEM ANALYSIS AND DESIGN

4.1 System Specification

4.1.1 Requirements Definition

The requirements definition outlines how the ATM performs its functions. The

mode of operation of this ATM system consists of authenticating the user

based on his/her account number, PIN and OTP. This is followed by the

execution of financial transactions. To authenticate a user and perform

transactions, the ATM must interact with the database of the bank account.

For each bank account, the database stores an account number, a PIN and a

balance indicating the amount of money in the account. Upon first

approaching the ATM, the user should pass through the following steps:

Step 1: The screen displays “Welcome to our bank” and prompts the user to

slot in his/her ATM card.

Step 2: The user slot in his/her ATM card.

Step 3: The screen prompts the user to enter the PIN associated with the

specified account number.

Step 4: The user enters the PIN using the keypad. If the PIN is correct he/she

proceeds to step 5 but if not correct, he/she will repeat step 4.

Step 5: The screen prompts the user to enter the OTP.

Step 6: The user enters the OTP using the keypad. If the OTP is correct he/she

proceeds to step 6 but if not correct, he/she will repeat step 5.

Step 7: If the user enters a valid account number, the correct PIN for that

account and the correct OTP for the transaction, the screen displays the

Transaction menu (Fig. 5.2).

71

After the ATM authenticates the user, the Transaction menu contains options

such as balance inquiry, withdrawal, etc. The user will then choose the

appropriate option.

If the user chooses to make a balance inquiry, the screen displays the user’s

account balance. To do so, the ATM must retrieve the balance from the bank

account database. The following steps describe what occurs when the user

chooses to make a withdrawal:

Step 1: The screen displays a menu (Fig. 5.11) containing various types of

accounts for the user to select from.

Step 2: The screen displays a menu (Fig. 5.12) containing standard withdrawal

amounts. The menu also contains an option to allow the user to enter their

preferred withdrawal amount.

Step 3: The user chooses an amount to withdraw.

Step 4: If the withdrawal amount chosen is greater than the user’s account

balance, the screen displays a message stating this and telling the user to

choose a smaller amount. The ATM then returns to Step 2. If the withdrawal

amount chosen is less than or equal to the user’s account balance (i.e., an

acceptable amount), the ATM proceeds to Step 5. If the user chooses to cancel

the transaction, the ATM displays the Transaction menu and waits for user

input.

Step 5: The ATM debits the withdrawal amount from the user’s account in the

bank’s database (i.e., subtracts the withdrawal amount from the user’s

account balance).

Step 6: The cash dispenser dispenses the desired amount of money to the

user.

Step 7: The screen displays a message reminding the user to take the money.

72

4.1.2 UML Modelling of the System

The proposed system was modelled using the Unified Modelling Language

(UML). In chapter 3 it was discussed that the Unified Modelling Language is a

graphical language for visualizing, specifying, constructing and documenting

the artefacts of a software-intensive system. The UML offers a standard way to

write a system’s blueprints, such as its functions and components.

Modelling the system using UML involves the following:

Capturing the system’s communication using Sequence Diagram.

Specifying the system’s workflow using Activity Diagram.

Specifying the system’s features using Use Case Diagram.

Providing the structural view of the system using Class Diagram.

Specifying the system’s Hardware components using Deployment

Diagram.

The above mentioned actions capture different information about any

software system in particular. Each of the diagrams provides a distinctive visual

model of the system.

The following are the Sequence Diagram, Activity Diagram, Use Case Diagram,

Class Diagram and Deployment Diagram that make up the UML model of the

system.

73

SMS Gateway

Customer

Fig. 4.1: Sequence diagram of the system

ATM accepts the SMS

Password (OTP) and

grants him access to

his account.

Customer enters the SMS

Password.

ATM welcomes the

customer and requests

his PIN.

Customer enters his PIN.

SMS Gateway sends

One Time Password

(OTP) to GSM Phone

held by the customer.

ATM accepts the PIN

and requests for SMS

Password (OTP).

ATM sends One

Time Password

(OTP) to SMS

Gateway.

Customer slots his card.

GSM Phone ATM

System Sequence diagram

74

As discussed in chapter 3, the UML Sequence diagram shows the dynamic

communications between objects during the execution of a task. It presents

the order in which messages are sent between the objects to accomplish that

task. It also shows an interaction between objects as something that happens

at one specific point in the execution of the system.

Figure 4.1 shows the Sequence diagram for the proposed system. It shows the

Customer, ATM, SMS Gateway and GSM Phone as the entities that

communicate with each other. The communication is shown as arrow headed

lines that start from one object’s lifeline and terminate at the other’s lifeline.

The Sequence diagram of this system implies that after the customer slots his

card, the ATM sends a One Time Password (OTP) to the SMS Gateway and

afterwards the SMS Gateway sends the One Time Password to the GSM Phone

held by the customer. Then the ATM welcomes the customer and requests his

PIN. The customer enters his PIN and afterwards ATM accepts the PIN and

requests for SMS Password (OTP). The customer enters the SMS Password.

Then the ATM accepts the SMS Password and grants him access to his account.

75

[NO]

[YES]

[Genuine PIN]

[Genuine OTP]

Perform Transaction

Insert Card

Would you Perform another Transaction?

[Ingenuine PIN (Maximum number of trials is 3)]

Input One Time Password (OTP)

Input security PIN

Fig. 4.2: Activity Diagram for the System

System Activity diagram

[Ingenuine OTP (Maximum number of trials is 3)]

76

The Activity diagram shows a sequential flow of actions. It shows the dynamic

behaviour of a system through the flow of control between actions that the

system performs. The Activity diagram consists of actions, which are the basic

unit of behaviour that make up an activity. In figure 4.2, the actions are shown

in the action node (a rectangle with rounded edges).

The Activity diagram of this system tells that the first step is for the user to

insert his ATM card. The second step is for him to input security PIN.

Afterwards the system makes a decision, as shown by the decision node,

whether the PIN is genuine. If the PIN is not genuine the flow of activity goes

back to the second step through the first join node but if it is genuine then the

flow proceeds to the third step. Note that the maximum number of trials for

ingenuine PIN is 3 times. If a fourth attempt is made at entering ingenuine PIN,

the account will be blocked. In the third step, the user is going to input the One

Time Password (OTP). The system then checks to see if the OTP is genuine, as

shown by the decision node. If the OTP is not genuine the flow of activity goes

back to the third step through the second join node but if it is genuine then the

flow proceeds to the fourth step. Note that the maximum number of trials for

ingenuine OTP is 3 times. If a fourth attempt is made at entering ingenuine

OTP, the account will be blocked. In the fourth step, the user is going to

perform the desired transaction. Afterwards, the fifth action is for the system

to ask the user if he wants to perform another transaction. This will require the

user to input a Yes or No. The system then checks, as the decision node shows,

if his answer is Yes or No. If it is No, the flow of activity ends but if it is Yes then

the flow of activity goes back to the second step through the first join node.

From figure 4.2, it can be seen that an activity diagram starts with the initial

node (a large dot) and ends with the final activity node (a white circle with a

large dot inside).

77

A Use Case is a description of a functionality (a specific usage of the system)

that the system provides. A Use Case is a particular purpose that a user can

actually use the system to accomplish. The UML Use Case diagram is an

overview of all the use cases and how they are related. It provides a big picture

of the functionality of the system. Use Case diagram helps to determine the

functionality and features of the software from the user's perspective.

Withdraw Cash

Deposit Cash

Balance Inquiry

Fund Transfer

Recharge Phone

Mini Statement

Change PIN

Pay Bills

Maintenance

Bank

Customer

Fig. 4.3: ATM Use Case diagram

System Use Case diagram

78

Figure 4.3 shows the Use Case diagram for the proposed system. From the

diagram it can be seen that there are two actors, i.e. the bank and the

customer. Also there are 9 Use Cases and they are:

Withdraw Cash: this Use Case enables the customer to make a cash

withdrawal.

Deposit Cash: this Use Case enables the customer to make a cash

deposit.

Balance Inquiry: this Use Case enables the customer to know the

amount of money left as balance.

Fund Transfer: this particular one allows the customer to effect a cash

transfer to another account.

Recharge Phone: this particular one allows the customer to buy call

credit (airtime).

Mini Statement: this Use Case enables the customer to print a mini

statement of account.

Change PIN: this one permits the customer to change his PIN.

Pay Bills: this particular one allows the customer to pay utility bills.

Maintenance: this Use Case enables the bank to carry out maintenance

operations on the ATM.

The lines linking the actors to the Use Cases show that the actor called “Bank”

is concerned with the Use Case called “maintenance” whereas the actor called

“customer” is concerned with the remaining Use Cases. These Use Cases are

the functionalities or features of the system from the user’s perspective.

79

In order to identify the Classes, attributes and methods/operations involved

in the ATM system design, the requirements definition in section 4.1.1 is

examined so as to identify the key nouns and noun phrases that comprise the

system.

Not all the nouns or noun phrases are modelled as classes because some of the

nouns/noun phrases do not correspond to any parts of the system while some

are actually attributes of the classes that are modelled.

Banking Class

+accountNumber

-balance

+accountType

+ GetCustomer()

+ GetCustomerAccountBalance()

+ MinimumBalanace()

+ MiniStatement()

+ ValidateCustomerAccount()

+ VerifyAccount()

+ VerifyAccountType()

ATM Class

+accountBlocked: bool

+accountNumber: string

+accountType: string

+bank: string

+blocked: bool

+card: string

+cardNumber: long

+customerName: string

+cvv: int

+BlockAccount()

+ChangePIN()

+DepositCash()

+InsertCard()

+SendOneTimePassword()

+VerifyATMPin()

+WithdrawCash()

Fig.4.4: Class diagram of Banking and ATM classes Fig. 4.4: Class diagram of Banking and ATM classes

System Class diagram

80

The key nouns/noun phrases that are in the requirements definition are Bank

and ATM. These nouns give rise to the Banking Class and ATM Class.

From the system’s Requirements Definition, the attributes (properties) and

operation (methods) of the system are deduced. Accounting operations (such

as “account balance inquiry”) and their related attributes are grouped together

in the Banking Class while in the ATM Class, mostly security related operations

(such as “change PIN”) and their related attributes are grouped together.

Figure 4.4 shows the class diagram for the system. Each class is depicted as a

box. Each box is divided into horizontal parts. The top part contains the name

of the class. The middle section contains the attributes/properties of the class.

The third section of the class diagram lists the operations/methods of the class.

The plus (+) symbols inside the class diagrams show that the properties or

methods concerned are public. A public method or property is the one that can

be accessed from outside the class definition.

Similarly, the minus (-) symbols inside the class diagrams show that the

properties or methods concerned are private. A private method or property is

the one that can be accessed from within the class definition. An attempt to

access such method or property from outside the class triggers error.

Sequence of operations performed by the methods

The sequence of operations performed by these methods are shown in the

system flowchart of fig. 4.8, pages 72 to 75. This system flowchart

encompasses all the activities of the ATM.

81

As already discussed, the UML deployment diagram focuses on the structure of

a software system and therefore shows the physical distribution of the

software system among hardware platforms. It shows the actual devices

(nodes) that run the software, along with the connections they have to each

other.

Figure 4.5 shows the deployment diagram for the proposed system. In this

diagram, hardware components are drawn in boxes labelled with

“<<device>>”. The communication path between nodes is shown as a straight

line joining them together and the medium of communication is written near

the path.

The deployment diagram of this system implies that the proposed system runs

on the ATM and the ATM communicates with the SMS Gateway through the

internet in order to supply it with the One Time Password. The SMS Gateway

then sends the One Time Password it receives through the SMS (GSM)

Network to the mobile phone held by the customer operating the ATM.

SMS Network

Fig. 4.5: Deployment diagram of the system

Internet <<device>>

SMS Gateway

<<device>>

ATM

<<device>>

GSM Phone

System Deployment diagram

82

4.1.3 Main Menu Specification

As in the case of a typical ATM machine, the simulated ATM machine has its

main menu which is usually displayed when the ATM card is inserted. ATM has

a screen that displays all menus to the key operation/transactions available on

the machine. Common sub menus on most ATM machines are listed below

(see figure 5.2, chapter 5):

1. Withdrawal: this menu opens up the various options (such as account

type) that are necessary in making cash withdrawals.

2. Recharge Phone: this menu opens up the screen where a customer

selects their network of choice for call credit recharge.

3. Pay Bills: this menu opens up the screen through which a customer can

pay utility bills.

4. Mini Statement: this menu is used by ATMs in printing out a mini

statement of account.

5. Balance Inquiry: this menu reveals a customer’s cash balance.

6. Change PIN: this provides the screen where a new PIN is entered in

order to replace an already existing PIN.

7. Account Type Menu: this lists the types of accounts maintained by a

customer

A very good ATM should have the above sub menus. All of the menu items are

not displayed on the same screen. As the transaction progresses, the menu

items are invoked so that the user can input necessary information needed for

the transaction.

4.1.4 Keypad Input Specifications

The input to any ATM machine most times is numeric value. The machine

accepts numeric values from the keypad and acts based on the number. The

typical examples of such numeric values are amount to withdraw or transfer,

83

recharge amount, amount to pay as bill, account number etc. Other forms of

input format are pre-stored string values which are stored and displayed for

the user to select through the ATM button. These input specifications are listed

in table 4.1.

4.1.5 Display Specifications

Every information in any system is stored in the database in different fields. In

the ATM machine, information is stored as integers, strings, image and other

data formats. The ATM screen displays the information as it is stored in the

database. When an input is made through the ATM buttons or through the

keyboard, the machine displays the output in a desired format. The machine

displays strings and numbers most times. In all the 8 functionalities highlighted

in section 4.1.2, the corresponding output specifications are highlighted in

table 4.1.

Functionality Input Process Output

1 Withdraw Cash

Functionality.

Security PIN,

Account Type

and Amount.

Verify PIN. Check

Account balance

and withdraw cash.

Account Type

menu.

Take Your Cash

message.

Do You Want to

Perform Another

Operation

message.

2 Transfer Fund

Functionality.

Security PIN,

Account Type,

Bank Account

Verify PIN.

Check Balance.

Transfer Cash.

List of Banks.

Account Type

menu.

Table 4.1

84

Number and

Amount.

Success message.

3 Deposit Cash

functionality.

Security PIN,

Bank Name,

Account Type

Amount and

Cash.

Verify PIN.

Verify account.

Verify cash.

Deposit cash.

List of Banks.

Input Amount

message.

Insert Cash

message.

Cash Deposited

message.

4 Recharge

Phone

Functionality.

Security PIN,

Phone Number

and Amount.

Verify PIN.

Check balance.

Recharge Phone.

Input Phone

Number and

Amount screen.

Recharge Phone

final message.

5 Pay Bills

Functionality.

Security PIN

and Bill Type.

Verify PIN.

Check balance.

Pay bills.

Not Available

message.

6 Mini Statement

Functionality.

Security PIN

and Account

Type

Verify PIN.

Process Bank

Statement.

5 last Transactions

statement.

7 Balance Inquiry

Functionality.

Security PIN

and Account

Type.

Verify PIN.

Process and display

Balance.

Account Balance

statement.

8 Change PIN

Functionality.

Security PIN

and new

Verify Security PIN.

Match two new

PIN Changed

Successfully

85

Security PIN. PINs. Change the

PIN.

message.

In any operation that will take place on the ATM machine, the security PIN is

always required.

4.1.6 Database Specification

Database Design Specification serves as a guide to the developer. The purpose

of this document is to specify the design of the ATM database. It provides an

outline to the structure of the data, and as such, serves as a framework for the

implementation phase. The requirements for the design of the Database are

Microsoft SQL Database and Microsoft Visual studio. The design consists of

basically, table design and queries. The ATM database in this research work has

7 tables, with each having different fields in it. The tables are listed in table 4.2

below:

Table Function

atm_cards This table stores the details of all the prestored

ATM cards available in this Application.

atm_cash_withdrawal Stores pre-defined withdrawable amount from the

machine.

atm_otp Stores one time password.

bank_account Stores account balance of all the customers in

different banks for the purpose of simulation.

bank_minibalance Stores bank minimum balance.

bank_transactions Stores history of all the transactions made in the

bank.

Customers Stores bio-data of all the customers.

Table 4.1 Input and Output Specifications

Table 4.2

Table 4.2: List of tables in ATM database

86

Since this project is not a complete banking system, most of the database

requirements were considered and implemented during the implementation.

There is no direct data input to the database from the user. The only time data

is sent to the database is when there is transaction. The machine records the

transaction most times in form of numeric value and rarely string. The ATM

database depends heavily on query. Where transaction is on, different queries

are executed to retrieve, manipulate and update the database.

4.1.7 Hardware and Software Requirements

Hardware requirements

Below are the minimum hardware requirements to run the application

RAM: 256MB

Pentium: 3

Processor: 1.5GHz

Hard disk: 20GB

Resolution: 1024 by 768

Software Requirements

Below are the minimum software requirements to run this application:

Operating system: Windows XP service pack 3, windows vista,

windows 7, window 8, Linux, Macintosh.

Internet Access

Microsoft SQL server

.NET Framework

4.2 System Design

4.2.1 Main Menu Design

Systems design involves the process of defining the architecture, components,

modules, interfaces, and data for a system to satisfy specified requirements.

87

Systems design could be seen as the application of systems theory to product

development. The system process flow diagram of figure 4.6 captures all the

main functionalities of the ATM starting from the INPUT PIN screen.

The ATM machine was designed in such a way that you can only gain access to

the transaction menu if and only if the correct PIN and One Time Password are

entered. So the sequence follows thus:

Insert ATM card Input PIN Input One Time Password Transaction

Menu Perform Transaction

Fig. 4.6: System Process Flow Diagram

PIN VERIFICATION

INSERT CARD

ONE TIME PASSWORD VERIFICATION

Withdraw Cash Balance Inquiry Change PIN Transfer Fund

Cash Deposit Mini statement Pay Bills Recharge Phone

ATM MACHINE

TRANSACTION MENU

88

In figure 4.6, the “One Time Password verification” block can be broken down

as shown in figure 4.7 in order to reveal more details of its operation. In figure

4.7 it can be seen that once the One Time Password (OTP) has been entered,

the system checks to see if it is genuine. If OTP is genuine, then access to the

account is granted but if it is not genuine, access to the account is denied.

Fig. 4.7: Operation of One Time Password verification

Figure 4.8 shows the system’s flowchart. The flowchart shows the sequential

flow of events. Also, the flowchart shows the flow of control amongst the

events that occur in the system; thus defining its behaviour.

Input One Time

Password (OTP)

Check if One Time

Password (OTP) is

genuine or not genuine

If One Time Password is

genuine, then grant

access to the account but

if not genuine, deny

access to the account.

89

No

Note that Points E, X, C, D and T are points of continuation of the flowchart from one page to another.

System flowchart

START

Is PIN correct?

Yes

No

Send OTP

Input Security PIN Display error message

E

Is Trial equal to 3?

No

Yes

X Input OTP

Is OTP correct?

Yes

Is Trial equal to 3?

Yes

X

Display error message

No

Transaction Menu

Select Transaction

Yes

No

Is transaction Withdraw cash?

Display Account Menu

Input Amount

Is Balance

sufficient?

Dispense cash

Yes

No

Is transaction Mini statement?

Select Account type

Yes

No

Process mini statement

T

C

T

START

Insert ATM Card

90

No

Is transaction Change PIN

Is transaction Cash Deposit

?

No

Input Old PIN

Input New PIN twice

Is Old PIN

Correct?

Change PIN

Yes

Yes

No

New PINs

matched?

No

Yes

Select Bank

Input Account number

Is report Invalid account?

Deposit Cash

No

Yes

Is report Correct?

No

Yes

Verify Account

Insert Cash

Yes

Is transaction Recharge Phone

?

No

Input Phone number

Input Amount

Yes

Is account Balance sufficient?

Recharge Phone

Select Network

Yes

No

C

T

D

T

T

Insufficient Balance Message

91

Is transaction Balance Inquiry?

Is transaction Transfer fund ?

No Select Account type

Account Balance

Yes

Select Bank

Input Account number

Is report Invalid account?

No

Yes

Is report Correct? No

Yes

Verify Account

Yes

No

Select account Type

Select Bill type

Is account Balance sufficient?

Pay Bill

Input Amount

Check owner balance

Is account Balance sufficient?

Yes

Transfer Fund

No

Check owner balance

Yes

No

D

T

T

T

92

There are different modules that make up the ATM machine, they are as listed

below:

Withdraw Cash Module

This is a program that allows the customer to withdraw cash through the ATM

machine provided that there is sufficient balance. The algorithm/design of this

module is shown in the system flowchart of fig. 4.8 (pages 72 to 75). The

withdraw cash section of the flowchart (page 72) outlines the module

algorithm and design.

Balance Inquiry Module

This allows the customer to check their account balance. The algorithm/design

of this module is shown in the system flowchart of fig. 4.8 (pages 72 to 75). The

balance inquiry section of the flowchart (page 74) outlines the module

algorithm and design.

Fig. 4.8: System flowchart

Is choice YES?

Perform another

transaction Yes/No

No

Display transaction

termination message

STOP

Yes

T

E

X

Fig. 4.8: System flowchart

93

Change PIN Module

This module allows the customer to change security PIN. Two set of new PINs

are required through this module and both PINs must correspond for the

changes to be made. The algorithm/design of this module is shown in the

system flowchart of fig. 4.8 (pages 72 to 75). The change PIN section of the

flowchart (page 73) outlines the module algorithm and design.

Transfer Fund Module

This module allows the customer to transfer fund from his/her account to

another account in the same or different bank. This module only serves the

purpose of demonstration and was not fully implemented.

Mini Statement Module

This module displays five last transactions made to the holder’s account. This

module is usually not available in so many banks and for that reason; it was not

fully implemented here.

Pay Bills Module

This module handles Bill payment and is usually not available in so many banks

and for that reason; it was not fully implemented here.

Recharge Phone Module

This module allows the customers to recharge any phone using any network

that is resident in Nigeria. This module only serves the purpose of

demonstration and was not fully implemented.

4.2.2 Input Design

The input design of this system is not a complex one in that most of the inputs

were made by clicking. This is so because the ATM operation is menu driven.

Most times, the user is prompted to select from already stored values that

94

normally appear on the screen. There is a keypad in this work that equally

allows the user to enter only numbers into the system. This means that the

direct input to the system is usually numeric values and can be entered

through the keypad shown in fig. 4.9.

Fig. 4.9: ATM Keypad (courtesy of Wikipedia.org)

4.2.3 Output Design

The output of the ATM is very simple. The ATM screen displays the result of

every activity going on in the machine. After an input has been made either by

selection or by direct input from the machine keypad, the result of the

operation is displayed on the ATM standard screen. The output design is

represented in figure 4.10.

95

Option Selection

Buttons

The simulated ATM has 3 sources of input which are card input, option

selection and keypad direct input. The option select contains 8 function keys

that can be found on the machine, four keys by the side of the machine’s

screen as shown in fig. 4.11.The keypad contains numerical keys that can be

used to input numbers into the machine (see fig. 4.9). The design arrangement

of the machine is as shown:

Screen

Keypad

Fig. 4.8: ATM machine input and output d

Fig. 4.7: Output Design of ATM

Card Input

Option selection Keypad direct input

ATM Standard Screen

Fig. 4.11: ATM machine input and output design

Fig. 4.10: Output Design of ATM

Option Selection

Buttons

96

Some assumptions were made during the design. The 6 ATM cards were stored

in the database and 6 different pictures were used to represent them on a

form. A button named ATM CARDS is found on the main ATM simulation

screen. ATM CARDS button links one to the form that contains 6 different

cards.

4.2.4 Database Design

The database used in this work is Microsoft Structured Query Language

(MSSQL) database file. The database was designed using Microsoft Visual

studio 2010. Microsoft Visual Studio provides you with powerful means to

manage your databases without programming. There are 7 tables that control

the application. These are tables 4.3, 4.4, 4.5, 4.6, 4.7, 4.8 and 4.9.

Field Name Data Type Size

atm_id Int 11

card_number nchar 16

Cvv Smallint 3

account_number nchar 10

expiry_date nchar 7

account_type varchar 20

Bank varchar 150

Pin smallint 4

Blocked Bit

Table 4.3: atm_cards– stores ATM card information

Field Name Data Type Size

Field Name Data Type Size

leftbutton1 Int 11

leftbutton2 Int 11

leftbutton3 Int 11

leftbutton4 Int 11

rightbutton1 Int 11

rightbutton2 Int 11

rightbutton3 Int 11

Table 4.4: atm_cash_withdrawal– stores predefined ATM withdrawal amount

97

pin_id Int 11

pin int 6

card_number Nchar 16

pin_date datetime

Table 4.5: atm_otp– stores one time password

Field Name Data Type Size

account_number Nchar 10

account_type varchar 20

Balance decimal (15, 2)

Blocked Bit

Table 4.6: bank_account– stores customers account balance

Table 4.7: bank_minbalance– stores the bank mini balance that cannot be withdrawn

Field Name Data Type Size

transaction_id Int 11

account_number Nchar 10

Amount decimal (15, 2)

Balance decimal (15, 2)

Depositor varchar 50

depositor_number varchar 13

date_transaction datetime

transaction_type varchar 20

Branch varchar 50

Table 4.8: bank_transactions– stores contacts and inquiries

Field Name Data Type Size

Minbalance Decimal (15,2)

account_type Varchar 20

Field Name Data Type Size

98

Field Name Data Type Size

customer_id Int 11

account_number nchar 10

Surname varchar 20

Firstname varchar 20

middlename varchar 20

Sex varchar 6

Birthday Date

Phone nchar 13

Email varchar 160

state_of_origin varchar 20

lga_of_origin varchar 50

Nationality varchar 10

residential_address Text

bank_name Varchar 50

Table 4.9: customers– stores customers’ personal details

99

CHAPTER FIVE

SYSTEM IMPLEMENTATION, TESTING AND SIMULATION

5.1 System Implementation

The simulated ATM system is shown in figure 5.1. It appears like a real ATM.

Indeed graphical work and programming was combined to yield the design

shown. The picture of a real ATM machine was obtained from the internet and

was used as the background in the ATM machine window (designed in C#) such

that when the ATM program is run, the window will open up and display the

ATM as its background. In addition to the ATM machine window, C# was used

to design the following controls: ATM Screen, Insert Card Button, Card Slot,

Left Function Buttons, Right Function Buttons, Cash Dispenser and Pin Pad (see

figure 5.1).

The above mentioned controls designed in C# were then placed at strategic

locations on the picture of the real ATM machine that is at the background of

the ATM machine window in the following way (see figure 5.1);

The ATM Screen was placed right on top of the real ATM screen such

that it replaces it.

The Insert Card Button was placed at the top right hand corner of the

ATM machine window.

The Card Slot control was programmed to be invisible and placed at the

insert card slot of the real ATM.

The Left Function Buttons were programmed to be invisible and placed

right on top of the real ATMs Left Function Buttons such that only the

real buttons are visible and when the mouse pointer is placed on any of

100

the real buttons and clicked, the invisible Left Function Button on it is

activated.

The Right Function Buttons were also programmed to be invisible and

placed right on top of the real ATMs Right Function Buttons such that

only the real buttons are visible and when the mouse pointer is placed

on any of the real buttons and clicked, the invisible Right Function

Button on it is activated.

The Cash Dispenser was programmed to be invisible and placed on top

of the real ATMs Cash Dispenser. In the simulation C# uses animation to

show the movement of cash out of the Cash Dispenser.

The Pin Pad Buttons were programmed to be invisible and placed right

on top of the real ATMs Pin Pad Buttons such that only the real buttons

are visible and when the mouse pointer is placed on any of the real

buttons and clicked, the invisible Pin Pad Button on it is activated.

The combination of graphic and programming work gives the simulated ATM

system the feel of a real ATM.

101

5.1.1 Main Menu Implementation

The main menu was implemented using visual C# on .Net framework of

Microsoft visual studio 2010. The concept of pick and drop was used to arrange

the controls used in the project. The source codes for the implementation are

clearly written in Appendix A, Appendix B and Appendix C of this work.

The main menu contains texts arranged on screen with buttons lying side by

side of the texts. On-click events of each buttons lying side by side of the menu

were used to implement the action being performed by each menu. Apart

from the main menu, there are submenus (such as; select account type, enter

Fig. 5.1: The Simulated ATM system.

Pin Pad

ATM Screen

Left

Function

Buttons

Cash

Dispenser

Card Slot

Right

Function

Buttons

Insert Card

Button

102

old PIN, enter new PIN, select amount to withdraw) that normally come in

each selected main menu and they were all implemented the same way by on-

click events.

5.1.2 Input Implementation

It has been noted earlier that there are three main sources of input to the ATM

machine namely card input, option selection and keypad direct input. The

input was implemented using C# programming. Some operations on the

machine do not require keypad input which means that one can keep selecting

predefined options until the transaction is completed. Such operations include

mini statement, balance inquiry and pay bills. The input implementation was

achieved by segmenting the screen into different modes so that the program

will know when to perform a particular task since the keypad and selection

buttons are used for different inputs of different ATM operations and

transactions.

The ATM screen modes help to instruct the machine how the input should be

made. After PIN verification, the machine displays the main menu of the

machine which contains 8 different operations as shown in figure 5.2.

The segmentation of the screen into modes simply means that the different

operations including button press/keypad press events performed by the

machine were handled in separate block of codes. Each block of codes

represents a screen mode. For instance, the ATM card is inserted; the machine

enters Enter Pin Mode. In this mode, most of the function key by the left and

right of the machine are deactivated except for cancel, clear and proceed

buttons. Another instance of screen mode is when there is no operation being

performed on the machine; it takes welcome screen mode by default. In

103

summary, the screen mode segments help to tell the machine how to respond

to events and what to display on the screen.

When the above screen is displayed, the ATM is put into TransactionMenu

screen mode. When you select Balance Inquiry from the options, the ATM is

put into BalanceInquiry screen mode and so on. When you press the 8 buttons

lying side by side of the screen, they respond based on the screen mode,

likewise the keypad. The name of the method that allows direct keypad input

into the system is TypeCharacter(). It checks for screen mode before it inputs

any number into the system.

Fig. 5.2: Transaction Menu Screenshot.

104

5.1.3 Output Implementation

The output of the system was implemented using a special feature called User

Control. User Control allows the programmer to customize already existing

controls such as text boxes, check boxes, forms and buttons to match his own

task. Each input operation requires an output screen. The output screen may

equally contain another screen for another input. When an input is made, the

user controls created will be displayed on the screen based on the input. The

trick used in the output implementation is simply to remove and add user

control method. If the current screen is showing select account type control,

the next output screen would remove the account type control and add

another control say input withdrawal amount control. Below in table 5.1 is the

list of all the user controls used in this project:

User Control Function

AccountBlocked Displays account blocked message

AccountType Displays account type selection

ATMHomeScreen Displays ATM welcome screen

BalanceInquiry Displays account balance statement

CashWithdrawal Displays cash withdrawal process in the ATM

machine

ChangePIN Displays screen for changing security PIN

InputPinControl Displays screen for entering security PIN

MiniStatement Displays the screen that contains 5 last

transactions

PerformAnotherOperation Displays screen that prompts user to perform

another operation

RechargePhone Displays screen for recharging phone through the

machine

105

Table 5.1: List of output screen user controls .

TerminateTransaction Displays screen for terminating ATM transaction

TransactionMenu Displays the ATM main transaction menu. This is

the very first screen that appears after PIN

authentication

TransferFund Displays screen for transferring fund

WithdrawalOptions Displays the screen that contains different amount

that can be withdrawn from the machine.

5.1.4 Choice of Programming Language

So many programming languages were considered in the course of designing

this software. A lot of factors were put into consideration which includes

database management. Flexibility and speed were also considered and as a

result, C# (pronounced as C-Sharp) was chosen as the main programming

language. C# is a programming language that was developed by Microsoft and

looks somewhat like Java. In fact it competes with Java in the software market

and is arguably the best programming language. C# is very powerful in data

handling. Microsoft actually simplified C# by building one of the world’s most

powerful IDE called Visual Studio. With Microsoft Visual studio, you can

program less and achieve the best result. Apps developed with C# are usually

secure, fast and reliable and this justifies the choice of C#.

In order to show the superiority of C#, a comparison is made between C# and

JAVA (another powerful object oriented programming language. Tables 5.2,

5.3, 5.4 and 5.5 clearly show the comparison of C# and JAVA using important

criteria such as data types, reference types, arrays and collections and then

object oriented programming respectively [20].

106

Data Types Comparison

Data types C# Java

Single-root (unified) type

system.

Yes. No; but wrapper types.

Signed integers. Yes; 8, 16, 32, 64 bits. Yes; 8, 16, 32, 64 bits.

Unsigned integers. Yes; 8, 16, 32, 64 bits. No; but some method

support.

Character. Yes. Yes.

Date/time. Yes; value type. Yes; reference type.

IEEE 754 binary32

floating point number.

Yes. Yes.

IEEE 754 binary64

floating point number.

Yes. Yes.

Boolean type. Yes. Yes.

High precision decimal

number.

128-bit (28 digits)

Decimal type.

No; but see 'Arbitrary

size decimals' below.

Arbitrary size decimals. Third party library. Reference type; no

operators.

Strings. Immutable reference

type, Unicode.

Immutable reference

type, Unicode.

Arbitrary size integers. Yes. Reference type; no

operators.

Complex numbers. Yes. Third-party library.

107

Reference types. Yes. Yes.

Arrays. Yes. Yes.

Value types. Yes. No; only primitive types.

Type annotations. Yes. Yes.

Enumerated types. Yes; scalar. Yes; reference type.

Lifted (nullable) types. Yes. No; but wrapper types.

Tuples. No; but standard library

support with limited

arity.

No; limited 3rd party

available.

Pointers. Yes. No, only method

References.

Table 5.2: Comparison of C# and Java based on data type (Source:

https://en.wikipedia.org/wiki/Comparison_of_C_Sharp_and_Java).

When writing a program, data manipulation is always the target. C# has better

data types which makes data manipulation better in C#. Table 5.2 proved that

C# has better data types as compared to Java.

Reference types Comparison

In both languages, references are a central concept. All instances of classes

are by reference.

While not directly evident in the language syntax per se, both languages

support the concept of weak references. An instance that is only referenced by

weak references is eligible for garbage collection just as if there were no

references at all. In both languages this feature is exposed through the

associated libraries, even though it is really a core runtime feature.

108

In addition to weak references, Java has soft references. Soft references are

much like weak references, but the Java Virtual Machine will not de-allocate

softly-referenced objects until the memory is actually needed.

Reference types C# Java

Garbage collection. Yes. Yes.

Weak references. Yes. Yes.

Reference queue

(interaction with garbage

collection).

Yes. Yes.

Soft and Phantom references. No. Yes.

Proxy support. Yes; object contexts. Yes; proxy generation.

Table 5.3: Comparison of C# and Java based on reference type (Source:

https://en.wikipedia.org/wiki/Comparison_of_C_Sharp_and_Java).

Arrays and collections Comparison

Arrays and collections are concepts featured by both languages. C# has better

array handler.

Arrays and Collections C# Java

Abstract data types. Yes. Yes.

One-dimensional, zero-

based index arrays.

Yes. Yes.

Multidimensional arrays,

rectangular (single

array).

Yes. No.

109

Multi-dimensional

arrays, jagged (arrays of

arrays).

Yes. Yes.

Non-zero based arrays. Some. No.

Unified arrays and

collections.

Yes. No.

Maps/dictionaries. Yes. Yes.

Sorted dictionaries. Yes. Yes.

Sets. Yes. Yes.

Sorted sets. Yes. Yes.

Lists/vectors. Yes. Yes.

Queues/stacks. Yes. Yes.

Priority queue. No. Yes.

Bags/multisets. Yes. No.

Concurrency optimized. Yes. Yes.

Collections.

Object Oriented Programming Comparison

Both C# and Java are designed from the ground up as object-

oriented languages, with syntax similar to C++ (C++ in turn derives from C).

Neither language is a superset of C or C++, however.

Table 5.4: Comparison of C# and Java based on arrays and collections (Source:

https://en.wikipedia.org/wiki/Comparison_of_C_Sharp_and_Java).

110

Object orientation C# Java

Classes. Mandatory. Mandatory.

Interfaces. Yes. Yes.

Abstract classes. Yes. Yes.

Member accessibility

Levels.

Yes; public, internal,

protected, private,

protected internal.

Yes; public, package,

protected, private.

Class-level inner classes. Yes; all inner classes are

class level.

Yes; static inner classes

are class level.

Instance-level inner

classes.

No. Yes.

Statement-level

(local) anonymous classes.

Yes; Without methods. Yes.

Partial classes. Yes. No.

Implicit (inferred)

anonymous classes.

Yes. No.

Deprecation/obsolescence. Yes. Yes.

Overload versioning. Yes. Some.

Enums can implement

Interfaces.

No. Yes.

Properties. Yes. No.

Events. Built-in language

Feature.

Provided by standard

Libraries.

111

Operator overloading. Yes. No.

Indexers. Yes. No.

Implicit conversions. Yes. No.

Explicit conversions. Yes. No.

Table 5.5: Comparison of C# and Java based on object orientation (Source:

https://en.wikipedia.org/wiki/Comparison_of_C_Sharp_and_Java).

Note that the source codes for the implementation are clearly written in

Appendix A, Appendix B and Appendix C of this work.

5.2 System Integration

Each module was programmed separately and combined together to form one

complete system. The modules were tested individually to check the efficiency.

The graphic designs were brought together using the Visual studio 2010

platform. In other to integrate the newly added functionality (i.e. OTP) to the

existing system, an SMS Application Program Interface (API) was introduced to

enable the machine send One Time Password via SMS to the customer.

Without the SMS API, the sending of One Time Password will not be possible.

Although this is a simulation, in real life, the behaviour will be exactly the

same. The integration process incorporates online bulk SMS system which

works hand in hand with the machine. In the process of using the Machine, just

before PIN request and verification, the machine retrieves account bearer’s

phone number and calls up the SMS API to send the message to the user. The

user receives the message right in front of the machine and keys it in.

112

5.3 System Testing

System testing is the process of executing program with the primary aim of

viewing the output and checking for errors. This secure online system was

tested in different modules to check the efficiency of the system. The following

is table 5.6. It is a table from the database that contains important information

for testing the system.

atm_id Card_number cvv Account_number Expiry_date Account_type Bank Pin blocked

1 4000123456789123 210 1234567890 08-2018 Savings Fidelity

Bank

1234 False

2 4187888841410913 199 1122334455 12-2014 Savings Access

Bank

1122 False

3 4724570123456780 901 1122334400 01-2015 Savings Eco

Bank

8901 False

4 4000105012368608 100 1020304050 01-2019 Current First

Bank

1990 False

5 4251319050000000 291 1015101510 10-2015 Fixed Deposit Fidelity

Bank

1736 True

6 4404520151902260 300 1212121212 02-2016 Savings Union

Bank

1100 False

To test any of the ATM cards, select it from the form that contains the cards,

look for the corresponding PIN from table 5.6. The number 1 ATM card on the

table was used throughout the testing process in this simulation.

Generally the ATM starts when the ATM.exe file (executable file) is double

clicked. It starts by displaying the welcome screen (see Fig 5.1 and Fig 5.3) and

prompts the user to insert card after which “insert PIN” will be prompted.

Table 5.6: Pre-stored ATM cards.

113

After card insertion, the machine reads the card, displays the name of the

customer, sends a One Time Password “OTP” to the account holder’s phone

via SMS and prompts the user to enter his or her security PIN. To insert the

card during the ATM simulation, one must click the INSERT CARD button to

select any of the already stored cards in the simulator. The INSERT CARD

button is located at the top right hand corner of the ATM machine window

(see fig 5.1). There are six cards. For the testing of the system, the first card

was selected and it carries the name OKAFOR CHINEDU (see fig. 5.4). The name

will be displayed immediately the card is inserted. Any of the cards can be

selected by double clicking it.

Fig. 5.3: ATM Welcome Screen.

114

Fig. 5.4: ATM cards form.

After selecting a card by double clicking it using the mouse pointer, the user

then clicks the card slot on the machine to insert the card into the ATM. The

simulator shows the movement of the card into the machine and the account

holder’s name is displayed as shown in figure 5.5.

115

After successful PIN verification the machine requests for the One Time

Password that the account holder has received via SMS. It displays another

screen for the user to enter the One Time Password. In a case whereby the PIN

is wrong, the program displays invalid PIN and asks the user to re-enter the PIN

(see fig. 5.6). If the PIN is tried for 3 good times, the account is blocked (see fig.

5.7) and if the PIN is correct, the machine takes the user to One Time Password

verification screen (see fig. 5.8). Note that both the PIN and One Time

Password are entered through the simulated ATM’s Key Pad shown in figure

5.5 above by clicking on the desired keys with the mouse pointer. Also, options

on the left or right side of the screen are selected by clicking the mouse pointer

Fig. 5.5: Input Security PIN Screen.

on the corresponding function buttons.

116

Fig. 5.7: Account blocked Screenshot.

Fig. 5.6: Invalid PIN Screenshot.

117

After successful OTP verification the machine displays main transaction menu

for the user to select. In a case where the OTP is wrong, the program displays

invalid OTP and asks the user to re-enter the OTP (see fig. 5.9). If the OTP is

entered three times unsuccessfully, the account is blocked (see fig. 5.7) and if

the OTP is correct, the machine takes the user to the next screen which is the

already mentioned main transaction menu (see fig. 5.10).

Fig. 5.8: One Time Password (OTP) verification Screen.

118

Note that the options on the left or right side of the screen are selected by

clicking the mouse pointer on the corresponding function buttons.

Some other application testings were made in this project work; they are

discussed from section 5.3.1 to section 5.3.3.

Fig. 5.9: Invalid OTP Screenshot.

Fig. 5.10: ATM machine showing transaction main menu.

119

5.3.1 Cash Withdrawal Testing

To withdraw cash, Withdrawal menu is selected from the transaction main

menu. The next screen that will be displayed is account type screen which

prompts the user to select from savings, current and fixed deposit (see fig.

5.11). The machine displays the appropriate screen for the user to select

amount to withdraw (see fig. 5.12) or input the amount directly from the

keypad if the amount is not listed (see fig. 5.13).

Fig. 5.11: Select Account Type Screenshot.

120

Fig. 5.12: Select amount to withdraw Screenshot.

Fig. 5.13: Input amount to withdraw Screenshot.

121

Fig. 5.14: Cash withdrawal Screenshot.

Figure 5.14 shows the Cash withdrawal screenshot. C# uses animation to

simulate the movement of a 1000 Naira note from the cash dispenser as

shown in figure 5.14.

After the cash withdrawal, the screen displays the details of the transaction as

shown in figure 5.15.

122

Fig. 5.15: Cash Withdrawal Statement.

5.3.2: Change Security PIN Testing

To change security PIN, the Change PIN option is selected from the transaction

main menu. The first screen asks the user to input old PIN (see fig. 5.16) and

the next 2 screens ask the user to enter new PIN (see fig. 5.17 and 5.18). If the

old PIN is correct and the new PINs match each other the operation is carried

out successfully (see fig. 5.19) but if they do not match, the customer is asked

to repeat the process. Note that both the old and new PINs are entered

through the simulated ATM’s Key Pad shown in figure 5.15 above by clicking on

the desired keys with the mouse pointer.

123

Fig. 5.16: Input old PIN Screenshot.

Fig. 5.17: Enter new PIN Screenshot.

124

Fig. 5.18: Re-enter new PIN Screenshot.

After this screen, the machine ejects the card. If the user wants to perform

another operation, the card is re-inserted, another One Time Password “OTP”

is sent for authentication and the security PIN is entered for final verification.

Fig. 5.19: PIN changed successfully Screenshot.

125

5.3.3 Balance Inquiry Testing

To check account balance, balance inquiry option is selected from the

transaction main menu. The machine asks the user to select account type (see

fig. 5.11) and after that, the account balance is displayed on the screen for the

account holder to view. It is one of the simplest testing done on the machine. It

has just one screenshot.

Fig. 5.20: Balance Inquiry Screenshot.

Finally, it is worthy to note that after concluding each operation, the machine

asks the user if he or she wants to perform another operation.

126

If No is selected then the machine displays goodbye message and goes back to

the welcome screen. If Yes is selected, the machine goes back and starts the

process of authentication right from the beginning.

Fig. 5.22: Transaction Termination message.

Fig. 5.21: Perform another operation Screenshot.

127

5.4 Debugging

The debugging of the system involved checking for errors at the various stages

of its development. The errors encountered at the various stages are

enumerated as follows:

System Implementation Stage

--At this stage, a Functionality Error was encountered. This kind of error means

that the software was not functioning as expected. In this case, the user

interface failed to launch.

The measure taken to solve the problem was the correction of the flow of logic

for the system.

Integration Stage

--Syntactic Errors were observed at this stage. These errors were caused by

non-conformity to the syntax of the programming language used (C#).

In other to correct these errors, strict adherence to the syntax of C#

programming language were observed.

Testing Stage

-- At this stage, a Communication Error was encountered. This kind of error

occurs when a software application fails to communicate vital information to

the end user. In this case, the system did not deliver the OTP to the end user.

It was observed that the error was caused by a syntactic error in the SMS

Application Program Interface (API) and this was immediately corrected.

128

Simulation Stage

--A Control Flow Error was encountered at this stage. This error occurs when a

software application fails to perform, at the right conditions, the anticipated

functions. This error was detected when the simulation did not run as it

should.

It was observed that a logical omission was causing the problem and it was

resolved.

129

CHAPTER SIX

CONCLUSION

6.1 Summary

It is of paramount importance to ensure security while carrying out the

automation of banking services. This work has successfully developed and

presented the design of Two-Factor Authentication (PIN and SMS Password)

system for an ATM. With the integration of Two-Factor Authentication into the

design, security vulnerability is reasonably addressed. This is a step towards

eradicating the limitations and fears associated with the use of ATMs.

This work extensively utilised Software Engineering principles in designing the

system in question. This involved the use of Object Oriented Analysis and

Design (OOAD) along with the Waterfall Model Software Development Life

Cycle.

This work was developed using C# (pronounced as C sharp). C# was chosen as

the programming language because of the advantages that it offers in terms of

database management and flexibility.

In conclusion, by introducing the Two-Factor Authentication (PIN and SMS

Password) method in our banking sector and then making it a matter of choice

(not mandatory) for ATM users, banks in Nigeria will optimally deliver their

services at acceptable levels of security. Ensuring the security of financial

transactions will drive our banking sector to a whole new level of quality of

service.

130

6.2 Contribution of the proposed model to this Body of Knowledge

This work has successfully implemented another method of curbing some ATM

frauds. This work uses SMS to increase security of ATM transactions. It is a cost

effective technology because it employs already existing ATM, Internet and

GSM infrastructure without the need for additional resources in the form of

hardware. Also, this model has lesser complexity than some existing designs

because of the absence of additional hardware.

Therefore this work has added, to this body of knowledge, a cost effective and

less complex technology for reducing ATM frauds.

6.3 Recommendations

Further work in this area should endeavour to enhance the reliability and short

delay of SMS by exploring the usage of dedicated SMS servers.

Considering the confidential nature of the SMS Password further work in this

area should also strive to provide encryption to the information before its

transmission so as to ensure secure communication through SMS between

the ATM and the user and therefore prevent various attacks such as the

following;

SMS disclosure: This kind of attack capitalises on the fact that the

transmission of SMS does not provide end-to-end protection of

confidentiality and integrity. Thus, the SMS message can be tracked and

intercepted during its transmission thereby compromising privacy and

revealing the content.

Over the air modification: SMS messages are sent through the air interface

(radio interface) between the Mobile Station (phone) and the Base Transceiver

Station. In GSM network, all traffic and signalling data across the air interface

131

are sent encrypted. The choice of encryption as well as its effectiveness is

network specific. In a situation where the encryption is not adequately

effective, such SMS messages are vulnerable to being modified over the air by

attackers.

Replay Attack: A replay attack is a form of network attack in which a valid data

transmission is maliciously or fraudulently repeated or delayed. This is carried

out either by the originator or by an adversary who intercepts the data and

retransmits it.

Man in the middle attack: This requires an attacker to have the ability to both

monitor and alter or inject messages into a communication channel. It can be

seen as a form of eavesdropping, in which the attacker makes independent

connections with the victims and relays messages between them to make

them believe they are communicating directly to each other over a private

connection, when in fact the entire communication is controlled by the

attacker.

Impersonation attack: This occurs when an SMS sender manipulates the

address information of an outgoing SMS. Often it is done in order to

impersonate another person, a financial institution or even another sender in

order to make it appear as if the SMS was sent by them. In this case the

receiver receives an SMS that bears the name of, for example, a bank as the

sender whereas the SMS was actually sent by a fraudulent impersonator.

132

REFERRENCES

1. “Automated Teller Machine”, retrieved on 7/7/14 from

http://en.wikipedia.org/wiki/Automated_teller_machine.

2. “How ATMs Work”, retrieved on 1/7/14 from www.pg.gda.pl

/~mickowal/IE/bankomaty_eng.pdf.

3. “All-about-skimmers”, retrieved on 3/7/14 from

http://krebsonsecurity.com/all- about-skimmers/.

4. Eriksson, H. et al, UML™ 2 Toolkit, Wiley Publishing, Inc., 2004.

5. Katta, S. et al., “Model for Token Based Secure Transaction in ATM

Networks”, IJCSET, August 2011, Vol. 1, Issue 7, 395-398.

6. Federal Financial Institutions Examination Council, “Authentication in an

Internet Banking Environment ”, retrieved on 5/4/14 from

http://www.ffiec.gov/.

7. Jaiswal, A. M. et al., “Enhancing ATM security using fingerprint and GSM

technology, IJCSMC, Vol. 3, Issue. 4, April 2014, pg.28 – 32.

8. Aru, O. E. et al., “Facial Verification Technology for Use in ATM

Transactions”, AJER, Vol-2, Issue-5, 2013, pp-188-193.

9. Das, S. et al, “Designing a Biometric Strategy (Fingerprint) Measure for

Enhancing ATM Security in Indian E-Banking System”, IJICT,

September 2011, Vol. 1, No. 5.

10. “Authentication”, retrieved on 4/7/14 from

http://searchsecurity.techtarget.com/definition/authentication.

11. “Identification, authentication, authorization”, retrieved on 4/7/14 from

http://blogs.getcertifiedgetahead.com/identification-authentication-

authorization/.

133

12. “Authorization”, retrieved on 4/7/14 from http://searchsoftwarequality.

techtarget.com/definition/authorization.

13. Prasad, M V N K et al., “Authentication factors for Internet banking”,

IDRBT Working Paper No. 11.

14. “Phishing”, retrieved on 6/7/14 from http://www.ask.com/wiki/

Phishing?o=2802&qsrc=999&ad=doubleDown&an=apn&ap=ask.com.

15. “Microsoft Windows XP”, retrieved on 7/7/14 from

http://en.wikipedia.org/wiki/Microsoft_windows_xp.

16. “Software Industries Ltd, CEN/XFS”, retrieved on 7/8/14 from

http://archive.today/vwtcG.

17. “Windows Driver Model”, retrieved on 7/8/14 from

http://en.wikipedia.org/wiki/Windows_Driver_Model.

18. “XPEAK” retrieved on 7/8/14 from http://www.xpeak.org/.

19. “J/eXtensions for Financial Services” retrieved on 7/8/14 from

http://jxfs.net/.

20. Peersman, G. et al, “The Global System for Mobile Communications

Short Message Service”, IEEE Personal Communications, June 2000.

21. Hudson, L. “The Bulk SMS Technology”, March 5, 2013, available at

http://mobilemarketingland.wordpress.com/2013/03/05/the-

bulk-sms-technology/ .

22. “SMS gateway”, retrieved on 5/6/15 from http://www.ask.com/wiki/

SMS_gateway?o=2802&qsrc=999&ad=doubleDown&an=apn&ap=ask.

com.

23. Booch, G., Object Oriented Analysis and Design With Applications, 2nd

ed., Addison-Wesley, 1994.

24. Pressman, R. S., Software Engineering: A Practitioners Approach, 7th ed.,

McGraw-Hill, 2010.

134

25. “Comparison of C# and Java2, retrieved on 5/6/15 from https://en.

wikipedia.org/wiki/Comparison_of_C_Sharp_and_Java.

135

Appendix A ATM Class Source Code

using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Data.SqlClient; using System.Drawing; using System.Net; using System.IO; namespace ATM { public class Atm { private int _id; private string _card_number; private short _cvv; private string _account_number; private string _expiry_date; private string _account_type; private short _pin; private string _bank; private bool _blocked; private Image _card; private string _customer_name; private int _pin_trials = 0; private bool _account_blocked; private string _phone; private int _otp; public Atm() { } public Atm(string card) { SqlConnection sqlCon = new SqlConnection(@"Data Source=.\SQLEXPRESS;AttachDbFilename=|DataDirectory|\bankdb.mdf;Integrated Security=True;Connect Timeout=30;User Instance=True"); try { sqlCon.Open(); SqlCommand sqlCmd = new SqlCommand("SELECT * FROM atm_cards WHERE card_number=" + card, sqlCon); SqlDataReader sdr = sqlCmd.ExecuteReader(); if (sdr.Read()) {

136

_id = sdr.GetInt32(0); _card_number = card; _cvv = sdr.GetInt16(2); _account_number = sdr.GetString(3); _expiry_date = sdr.GetString(4); _account_type = sdr.GetString(5); _bank = sdr.GetString(6); _pin = sdr.GetInt16(7); _blocked = sdr.GetBoolean(8); } sdr.Close(); sqlCon.Close(); } catch (Exception ex) { System.Windows.Forms.MessageBox.Show(ex.Message, "Connection Error", System.Windows.Forms.MessageBoxButtons.OK, System.Windows.Forms.MessageBoxIcon.Error); } } public void ChangePIN(string pin) { _pin = Convert.ToInt16(pin); SqlConnection sqlCon = new SqlConnection(@"Data Source=.\SQLEXPRESS;AttachDbFilename=|DataDirectory|\bankdb.mdf;Integrated Security=True;Connect Timeout=30;User Instance=True"); try { sqlCon.Open(); SqlCommand sqlCmd = new SqlCommand("UPDATE atm_cards SET pin="+pin+" WHERE account_number=" + _account_number, sqlCon); sqlCmd.ExecuteNonQuery(); sqlCon.Close(); } catch (Exception ex) { System.Windows.Forms.MessageBox.Show(ex.Message, "Connection Error", System.Windows.Forms.MessageBoxButtons.OK, System.Windows.Forms.MessageBoxIcon.Error); } } public void InsertCard() { Banking banking = new Banking(); Banking.Customer customer = banking.getCustomer(AccountNumber);// new Banking.Customer();

137

_customer_name = customer.Surname + " " + customer.Firstname + " " + customer.Middlename; _account_blocked = customer.Blocked; _phone = customer.Phone; } //Properties public int ID { get { return _id; } set{ _id = value; } } public string CardNumber { get { return _card_number; } set{ _card_number = value; } } public short CVV { get { return _cvv; } set{ _cvv = value; } } public string AccountNumber { get { return _account_number; } set{_account_number = value; } } public string ExpiryDate { get { return _expiry_date; } set{ _expiry_date = value; } } public string AccountType { get { return _account_type; } set{ _account_type = value; } } public short PIN { get { return _pin; } set { _pin = value; } } public string Bank { get { return _bank; } set{_bank = value; } } public bool Blocked { get { return _blocked; }

138

set{_blocked = value; } } public string Phone { get { return _phone; } set { _phone = value; } } public bool AccountBlocked { get { return _account_blocked; } set { _account_blocked = value; } } public Image Card { get { return _card; } set { _card = value; } } public int PinTrials { get { return _pin_trials; } set { _pin_trials = value; } } public int OTP { get { return _otp; } set { _otp = value; } } public void IncrementTrials() { ++_pin_trials; } public string CustomerName { get { return _customer_name; } set { _customer_name = value; } } public bool VerifyATMPin(int pin) { ++_pin_trials; return _pin == pin; }

139

public void BlockAccount() { new bankdbDataSetTableAdapters.atm_cardsTableAdapter().Update(_card_number, _cvv, _account_number, _expiry_date, _account_type, _bank, _pin, false, _id, _card_number, _cvv, _account_number, _expiry_date, _account_type, _bank, _pin, _blocked, _id); } public enum ATMScreen { Welcome, BalanceInquiry, ChangePIN, InputPIN, InputOneTimePassword, TransactionMenu, AccountTypeMenu, WithdrawalAmountMenu, InputWithdrawalAmount, PrintTransactionReceipt, TakeCash, PerformAnotherOperation, AccountBlocked, TerminateTransaction, TransferFund, RechargePhone, CashDeposit, MiniStatement, None } public enum ATMNotes { N1000, N500, None } public void WithdrawCash(int amount) { decimal balance = Banking.getCustomerAccountBalance(_account_number) - amount; SqlConnection sqlCon = new SqlConnection(@"Data Source=.\SQLEXPRESS;AttachDbFilename=|DataDirectory|\bankdb.mdf;Integrated Security=True;Connect Timeout=30;User Instance=True"); try { sqlCon.Open(); SqlCommand sqlCmd = new SqlCommand("UPDATE bank_account SET balance=" + balance + " WHERE account_number='" + _account_number+"'", sqlCon);

140

sqlCmd.ExecuteNonQuery(); bankdbDataSetTableAdapters.bank_transactionsTableAdapter transact = new bankdbDataSetTableAdapters.bank_transactionsTableAdapter(); transact.Insert(_account_number, amount, balance, " ", " ", " ", DateTime.Now, "Cash Debit", ATM.Properties.Settings.Default.BankBranch); sqlCon.Close(); } catch (Exception ex) { System.Windows.Forms.MessageBox.Show(ex.Message, "ATM Error", System.Windows.Forms.MessageBoxButtons.OK, System.Windows.Forms.MessageBoxIcon.Error); } } public void DepositCash(decimal amount, string account, Atm atm) { decimal balance = Banking.getCustomerAccountBalance(account) + amount; SqlConnection sqlCon = new SqlConnection(@"Data Source=.\SQLEXPRESS;AttachDbFilename=|DataDirectory|\bankdb.mdf;Integrated Security=True;Connect Timeout=30;User Instance=True"); try { sqlCon.Open(); SqlCommand sqlCmd = new SqlCommand("UPDATE bank_account SET balance=" + balance + " WHERE account_number='" + account+ "'", sqlCon); sqlCmd.ExecuteNonQuery(); bankdbDataSetTableAdapters.bank_transactionsTableAdapter transact = new bankdbDataSetTableAdapters.bank_transactionsTableAdapter(); transact.Insert(account, amount, balance, "", atm.CustomerName, atm.Phone, DateTime.Now, "Cash Deposit", ATM.Properties.Settings.Default.BankBranch); sqlCon.Close(); } catch (Exception ex) { System.Windows.Forms.MessageBox.Show(ex.Message, "ATM Error", System.Windows.Forms.MessageBoxButtons.OK, System.Windows.Forms.MessageBoxIcon.Error); } } public static int[] WithdrawalOptions() { bankdbDataSetTableAdapters.atm_cash_withdrawalTableAdapter wOption = new bankdbDataSetTableAdapters.atm_cash_withdrawalTableAdapter(); int[] options = new int[7]; options[0] = wOption.GetData()[0].leftbutton1;

141

options[1] = wOption.GetData()[0].leftbutton2; options[2] = wOption.GetData()[0].leftbutton3; options[3] = wOption.GetData()[0].leftbutton4; options[4] = wOption.GetData()[0].rightbutton1; options[5] = wOption.GetData()[0].rightbutton2; options[6] = wOption.GetData()[0].rightbutton3; return options; } public bool SendOneTimePassword() { string[] smsAPI = { ATM.Properties.Settings.Default.SMSAPI[0], ATM.Properties.Settings.Default.SMSAPI[1] }; string url = "http://mail.etextmail.com/smsapi/Send.aspx?UN=" + smsAPI[0] + "&P=" + smsAPI[1] + "&SA=ATM&DA=" + _phone + "&M=ATM_ONE_TIME_PASSWORD:" + _otp; // Create a request for the URL. try { WebRequest request = WebRequest.Create(url); // If required by the server, set the credentials. request.Credentials = CredentialCache.DefaultCredentials; // Get the response. HttpWebResponse response = (HttpWebResponse)request.GetResponse(); // Display the status. Console.WriteLine(response.StatusDescription); // Get the stream containing content returned by the server. Stream dataStream = response.GetResponseStream(); // Open the stream using a StreamReader for easy access. StreamReader reader = new StreamReader(dataStream); // Read the content. string responseFromServer = reader.ReadToEnd(); // Cleanup the streams and the response. reader.Close(); dataStream.Close(); response.Close(); if (!responseFromServer.Contains("OK")) return false; new bankdbDataSetTableAdapters.atm_otpTableAdapter().Insert(_otp, _card_number, DateTime.Now); return true; } catch (Exception ex) { } return false; } } }

142

Appendix B

ATM Main Form Source Code

using System; using System.Collections.Generic; using System.ComponentModel; using System.Data; using System.Drawing; using System.Linq; using System.Text; using System.Windows.Forms; using System.Threading; using System.Net; using System.IO; namespace ATM { public partial class frmMain : Form { Atm atm; bool cardPicked = false; int changePinStage = 1; int transferFundStage = 1; int rechargePhoneStage = 0; decimal amountWithdrawn = 0; public int cashDepositStage = 1; InputPinControl iPinCtrl; OneTimePassword otpCtrl; Atm.ATMScreen ScreenMode = Atm.ATMScreen.Welcome; TransactionMenu transactionCtrl; TransferFund transferFundCtrl = new TransferFund(); AccountType accountTypeCtrl = new AccountType(); Atm.ATMScreen NextScreenMode = Atm.ATMScreen.None; WithdrawalOptions withdrawalCtrl = new WithdrawalOptions(); ChangePIN changePinCtrl = new ChangePIN(); MiniStatement miniStatCtrl = new MiniStatement(); RechargePhone rechargePhoneCtrl = new RechargePhone(); int[] withdrawalOptions = new int[7]; public decimal DepositAmount = 0; public frmMain() { InitializeComponent(); withdrawalOptions = Atm.WithdrawalOptions(); }

143

private void lblButton1_MouseHover(object sender, EventArgs e) { lblButton1.BorderStyle = BorderStyle.FixedSingle; } private void lblButton1_MouseLeave(object sender, EventArgs e) { lblButton1.BorderStyle = BorderStyle.None; } private void lblButton2_MouseHover(object sender, EventArgs e) { lblButton2.BorderStyle = BorderStyle.FixedSingle; } private void lblButton2_MouseLeave(object sender, EventArgs e) { lblButton2.BorderStyle = BorderStyle.None; } private void lblButton3_MouseHover(object sender, EventArgs e) { lblButton3.BorderStyle = BorderStyle.FixedSingle; } private void lblButton3_MouseLeave(object sender, EventArgs e) { lblButton3.BorderStyle = BorderStyle.None; } private void lblButtonCancel_MouseHover(object sender, EventArgs e) { lblButtonCancel.BorderStyle = BorderStyle.FixedSingle; } private void lblButtonCancel_MouseLeave(object sender, EventArgs e) { lblButtonCancel.BorderStyle = BorderStyle.None; } private void lblButton4_MouseHover(object sender, EventArgs e) { lblButton4.BorderStyle = BorderStyle.FixedSingle; } private void lblButton4_MouseLeave(object sender, EventArgs e) { lblButton4.BorderStyle = BorderStyle.None; }

144

private void lblButton5_MouseHover(object sender, EventArgs e) { lblButton5.BorderStyle = BorderStyle.FixedSingle; } private void lblButton5_MouseLeave(object sender, EventArgs e) { lblButton5.BorderStyle = BorderStyle.None; } private void lblButton6_MouseHover(object sender, EventArgs e) { lblButton6.BorderStyle = BorderStyle.FixedSingle; } private void lblButton6_MouseLeave(object sender, EventArgs e) { lblButton6.BorderStyle = BorderStyle.None; } private void lblButtonClear_MouseHover(object sender, EventArgs e) { lblButtonClear.BorderStyle = BorderStyle.FixedSingle; } private void lblButtonClear_MouseLeave(object sender, EventArgs e) { lblButtonClear.BorderStyle = BorderStyle.None; } private void lblButtonEnter_MouseHover(object sender, EventArgs e) { lblButtonEnter.BorderStyle = BorderStyle.FixedSingle; } private void lblButtonEnter_MouseLeave(object sender, EventArgs e) { lblButtonEnter.BorderStyle = BorderStyle.None; } private void lblButtonZero_MouseHover(object sender, EventArgs e) { lblButtonZero.BorderStyle = BorderStyle.FixedSingle; } private void lblButtonZero_MouseLeave(object sender, EventArgs e) { lblButtonZero.BorderStyle = BorderStyle.None;

145

} private void lblButton7_MouseHover(object sender, EventArgs e) { lblButton7.BorderStyle = BorderStyle.FixedSingle; } private void lblButton7_MouseLeave(object sender, EventArgs e) { lblButton7.BorderStyle = BorderStyle.None; } private void lblButton8_MouseHover(object sender, EventArgs e) { lblButton8.BorderStyle = BorderStyle.FixedSingle; } private void lblButton8_MouseLeave(object sender, EventArgs e) { lblButton8.BorderStyle = BorderStyle.None; } private void lblButton9_MouseHover(object sender, EventArgs e) { lblButton9.BorderStyle = BorderStyle.FixedSingle; } private void lblButton9_MouseLeave(object sender, EventArgs e) { lblButton9.BorderStyle = BorderStyle.None; } private void lblCardSlot_MouseHover(object sender, EventArgs e) { lblCardSlot.BorderStyle = BorderStyle.Fixed3D; } private void lblCardSlot_MouseLeave(object sender, EventArgs e) { lblCardSlot.BorderStyle = BorderStyle.None; } private void btnATMcard_Click(object sender, EventArgs e) { frmCards cards = new frmCards(atm); atm = new Atm(); cards.ShowDialog(this); try

146

{ if (cards.atm.AccountNumber != string.Empty) { atm = cards.atm; picATMCard.Image = atm.Card; cardPicked = true; ScreenMode = Atm.ATMScreen.InputPIN; btnATMcard.Enabled = false; } } catch (Exception ex) { } } private void frmMain_MouseMove(object sender, MouseEventArgs e) { if (cardPicked) { picATMCard.Location = new Point(e.X + 1, e.Y); } } private void lblCardSlot_Click(object sender, EventArgs e) { if (cardPicked) { atm.InsertCard(); if (atm.Blocked || atm.AccountBlocked) { ScreenMode = Atm.ATMScreen.AccountBlocked; pnlATMScreen.Controls.Clear(); pnlATMScreen.Controls.Add(new AccountBlocked()); pnlKeypad.Enabled = false; } else { pnlKeypad.Enabled = true; iPinCtrl = new InputPinControl(); iPinCtrl.CustomerName = atm.CustomerName; pnlATMScreen.Controls.Clear(); pnlATMScreen.Controls.Add(iPinCtrl); } cardPicked = false; picATMCard.Size = new System.Drawing.Size(76, 8); picATMCard.Image = null; picATMCard.Location = new Point(739, 330); picATMCard.Size = new System.Drawing.Size(72, 42); } }

147

private void frmMain_Shown(object sender, EventArgs e) { pnlATMScreen.Controls.Add(new ATMHomeScreen()); } private void lblOperationKeyRight1_MouseHover(object sender, EventArgs e) { lblOperationKeyRight1.BorderStyle = BorderStyle.FixedSingle; } private void lblOperationKeyRight1_MouseLeave(object sender, EventArgs e) { lblOperationKeyRight1.BorderStyle = BorderStyle.None; } private void lblOperationKeyRight2_MouseHover(object sender, EventArgs e) { lblOperationKeyRight2.BorderStyle = BorderStyle.FixedSingle; } private void lblOperationKeyRight2_MouseLeave(object sender, EventArgs e) { lblOperationKeyRight2.BorderStyle = BorderStyle.None; } private void lblOperationKeyRight3_MouseLeave(object sender, EventArgs e) { lblOperationKeyRight3.BorderStyle = BorderStyle.FixedSingle; } private void lblOperationKeyRight3_MouseMove(object sender, MouseEventArgs e) { lblOperationKeyRight3.BorderStyle = BorderStyle.None; } private void lblOperationKeyRight4_MouseHover(object sender, EventArgs e) { lblOperationKeyRight4.BorderStyle = BorderStyle.FixedSingle; } private void lblOperationKeyRight4_MouseLeave(object sender, EventArgs e) { lblOperationKeyRight4.BorderStyle = BorderStyle.None; } private void lblOperationKeyLeft1_MouseHover(object sender, EventArgs e) { lblOperationKeyLeft1.BorderStyle = BorderStyle.FixedSingle; }

148

private void lblOperationKeyLeft1_MouseLeave(object sender, EventArgs e) { lblOperationKeyLeft1.BorderStyle = BorderStyle.None; } private void lblOperationKeyLeft2_MouseHover(object sender, EventArgs e) { lblOperationKeyLeft2.BorderStyle = BorderStyle.FixedSingle; } private void lblOperationKeyLeft2_MouseLeave(object sender, EventArgs e) { lblOperationKeyLeft2.BorderStyle = BorderStyle.None; } private void lblOperationKeyLeft3_MouseHover(object sender, EventArgs e) { lblOperationKeyLeft3.BorderStyle = BorderStyle.FixedSingle; } private void lblOperationKeyLeft3_MouseLeave(object sender, EventArgs e) { lblOperationKeyLeft3.BorderStyle = BorderStyle.None; } private void lblOperationKeyLeft4_MouseHover(object sender, EventArgs e) { lblOperationKeyLeft4.BorderStyle = BorderStyle.FixedSingle; } private void lblOperationKeyLeft4_MouseLeave(object sender, EventArgs e) { lblOperationKeyLeft4.BorderStyle = BorderStyle.None; } private void lblButton1_Click(object sender, EventArgs e) { TypeCharacter("1"); } private void TypeCharacter(string chr) { if (ScreenMode == Atm.ATMScreen.InputPIN) { if (chr == "C") iPinCtrl.Password = ""; else if (iPinCtrl.Password.Length < 4) iPinCtrl.Password = chr;

149

} else if (ScreenMode == Atm.ATMScreen.InputOneTimePassword) { if (chr == "C") otpCtrl.Password = ""; else if (otpCtrl.Password.Length < 6) otpCtrl.Password = chr; } else if (ScreenMode == Atm.ATMScreen.ChangePIN) { if (changePinStage == 1) { if (chr == "C") changePinCtrl.PIN = ""; else if (changePinCtrl.PIN.Length < 4) changePinCtrl.PIN = chr; } else if (changePinStage == 2) { if (chr == "C") changePinCtrl.NewPIN = ""; else if (changePinCtrl.NewPIN.Length < 4) changePinCtrl.NewPIN = chr; } else { if (chr == "C") changePinCtrl.NewPIN2 = ""; else if (changePinCtrl.NewPIN2.Length < 4) changePinCtrl.NewPIN2 = chr; } } else if (ScreenMode == Atm.ATMScreen.RechargePhone) { if (rechargePhoneStage == 0) return; if (rechargePhoneStage == 1) { rechargePhoneCtrl.TypePhoneAmount(chr, 1); } else { rechargePhoneCtrl.TypePhoneAmount(chr, 2); } } else if (ScreenMode == Atm.ATMScreen.InputWithdrawalAmount) { withdrawalCtrl.SetAmount(chr); } else if (ScreenMode == Atm.ATMScreen.TransferFund && transferFundStage == 2)

150

{ transferFundCtrl.SetAccountNumber(chr); } else if (ScreenMode == Atm.ATMScreen.TransferFund && transferFundStage == 3) { transferFundCtrl.SetAmountToWithdraw(chr); } } private void lblButton2_Click(object sender, EventArgs e) { TypeCharacter("2"); } private void lblButton3_Click(object sender, EventArgs e) { TypeCharacter("3"); } private void lblButton6_Click(object sender, EventArgs e) { TypeCharacter("6"); } private void lblButton5_Click(object sender, EventArgs e) { TypeCharacter("5"); } private void lblButton4_Click(object sender, EventArgs e) { TypeCharacter("4"); } private void lblButton7_Click(object sender, EventArgs e) { TypeCharacter("7"); } private void lblButton8_Click(object sender, EventArgs e) { TypeCharacter("8"); } private void lblButton9_Click(object sender, EventArgs e) { TypeCharacter("9"); }

151

private void lblButtonZero_Click(object sender, EventArgs e) { TypeCharacter("0"); } private void lblButtonCancel_Click(object sender, EventArgs e) { cardPicked = false; changePinStage = 1; transferFundStage = 1; rechargePhoneStage = 0; cashDepositStage = 1; iPinCtrl = new InputPinControl(); transactionCtrl = new TransactionMenu(); transferFundCtrl = new TransferFund(); accountTypeCtrl = new AccountType(); NextScreenMode = Atm.ATMScreen.None; withdrawalCtrl = new WithdrawalOptions(); changePinCtrl = new ChangePIN(); miniStatCtrl = new MiniStatement(); rechargePhoneCtrl = new RechargePhone(); LoadATMWelcomeScreen(); } public void LoadATMWelcomeScreen() { atm = new Atm(); cardPicked = false; changePinStage = 1; changePinCtrl.Reset(); ScreenMode = Atm.ATMScreen.Welcome; NextScreenMode = Atm.ATMScreen.InputPIN; btnATMcard.Enabled = true; pnlATMScreen.Controls.Clear(); pnlATMScreen.Controls.Add(new ATMHomeScreen()); pnlKeypad.Enabled = false; } private void lblButtonClear_Click(object sender, EventArgs e) { TypeCharacter("C"); } private void lblButtonEnter_Click(object sender, EventArgs e) { if (ScreenMode == Atm.ATMScreen.InputOneTimePassword) { if (otpCtrl.Password == "") return; otpCtrl.ShowCancelProceed(false); if (atm.OTP.ToString() == otpCtrl.Password)

152

{ ScreenMode = Atm.ATMScreen.TransactionMenu; transactionCtrl = new TransactionMenu(); transactionCtrl.mainForm = this; atm.PinTrials = 0; pnlATMScreen.Controls.Clear(); pnlATMScreen.Controls.Add(transactionCtrl); } else { if (atm.PinTrials == 3) { ScreenMode = Atm.ATMScreen.AccountBlocked; pnlATMScreen.Controls.Clear(); pnlATMScreen.Controls.Add(new AccountBlocked()); pnlKeypad.Enabled = false; atm.BlockAccount(); } else { otpCtrl.ShowInvalidPin(); } } } else if (ScreenMode == Atm.ATMScreen.InputPIN) { if (iPinCtrl.Password == "") return; iPinCtrl.ShowCancelProceed(false); if (atm.VerifyATMPin(Convert.ToInt32(iPinCtrl.Password))) { atm.PinTrials = 0; iPinCtrl.ShowSendingOTP(); ScreenMode = Atm.ATMScreen.InputOneTimePassword; otpCtrl = new OneTimePassword(); //transactionCtrl.mainForm = this; atm.OTP = new Random().Next(100000,999999); tmrSendingOTP.Start(); } else { if (atm.PinTrials == 3) { ScreenMode = Atm.ATMScreen.AccountBlocked; pnlATMScreen.Controls.Clear(); pnlATMScreen.Controls.Add(new AccountBlocked()); pnlKeypad.Enabled = false; atm.BlockAccount(); }

153

else { iPinCtrl.ShowInvalidPin(); } } } else if (ScreenMode == Atm.ATMScreen.InputWithdrawalAmount) { WithdrawCash(); } } private void frmMain_Load(object sender, EventArgs e) { } private void lblOperationKeyRight1_Click(object sender, EventArgs e) { //lblButtonCancel_Click(sender, e); switch (ScreenMode) { case Atm.ATMScreen.TransactionMenu: accountTypeCtrl = new AccountType(); ScreenMode = Atm.ATMScreen.AccountTypeMenu; NextScreenMode = Atm.ATMScreen.WithdrawalAmountMenu; pnlATMScreen.Controls.Clear(); pnlATMScreen.Controls.Add(accountTypeCtrl); break; case Atm.ATMScreen.TransferFund: if (transferFundStage == 1) { transferFundCtrl.Bank = "GTBBank"; transferFundStage = 2; NextScreenMode = Atm.ATMScreen.TransferFund; ScreenMode = Atm.ATMScreen.AccountTypeMenu; pnlATMScreen.Controls.Clear(); pnlATMScreen.Controls.Add(accountTypeCtrl); } else if (transferFundStage == 2) { transferFundStage = 3; transferFundCtrl.ShowInputAmount(); } else if (transferFundStage == 3) { string verifyMsg = Banking.ValidateCustomerAccount(transferFundCtrl.AccountNumber, transferFundCtrl.Bank, transferFundCtrl.AccountType);

154

if (verifyMsg.Equals("correct")) { decimal amount = Banking.getCustomerAccountBalance(atm.AccountNumber); if (amount - Banking.MinimumBalance(atm.AccountType) >= Convert.ToDecimal(transferFundCtrl.Amount)) { atm.DepositCash(Convert.ToDecimal(transferFundCtrl.Amount), transferFundCtrl.AccountNumber, atm); atm.WithdrawCash(Convert.ToInt32(transferFundCtrl.Amount)); TerminateATMOperation("Your fund has been transfered successfully"); transferFundStage = 1; transferFundCtrl = new TransferFund(); } else { transferFundStage = 3; transferFundCtrl.ShowInputAmount("You have insufficient balance\n"); } } else if (verifyMsg.Equals("Invalid account number")) { transferFundCtrl.lblInput.ResetText(); transferFundStage = 2; transferFundCtrl.lblScreen.Text = "Invalid account number, retry"; } else { TerminateATMOperation(verifyMsg); } } break; case Atm.ATMScreen.BalanceInquiry: PerformAnotherOperation(); break; case Atm.ATMScreen.ChangePIN: if (changePinStage == 1) { if (Convert.ToInt16(changePinCtrl.PIN) == atm.PIN) { changePinCtrl.lblPIN.Text = ""; changePinStage = 2; changePinCtrl.lblScreen.Text = "Enter new 4-digit PIN"; } else { atm.IncrementTrials(); if (atm.PinTrials == 3)

155

{ ScreenMode = Atm.ATMScreen.AccountBlocked; pnlATMScreen.Controls.Clear(); pnlATMScreen.Controls.Add(new AccountBlocked()); pnlKeypad.Enabled = false; atm.BlockAccount(); } else changePinCtrl.lblScreen.Text = "Invalid old PIN\nPlease retry"; } } else if (changePinStage == 2) { changePinStage = 3; changePinCtrl.lblPIN.Text = ""; changePinCtrl.lblScreen.Text = "Re-enter the new 4-digit PIN"; } else { changePinCtrl.lblPIN.Text = ""; if (changePinCtrl.NewPIN == changePinCtrl.NewPIN2) { atm.ChangePIN(changePinCtrl.NewPIN); TerminateATMOperation("Your PIN has been changed successfully"); changePinStage = 1; } else { changePinStage = 2; changePinCtrl.lblScreen.Text = "New PINs do not match\nPlease retry"; } } break; case Atm.ATMScreen.RechargePhone: if (rechargePhoneStage == 0) { rechargePhoneStage = 1; rechargePhoneCtrl.Network = "MTN"; rechargePhoneCtrl.ShowInputPhoneNumber(); } else if (rechargePhoneStage == 1) { rechargePhoneStage = 2; rechargePhoneCtrl.lblInput.ResetText(); rechargePhoneCtrl.lblScreen.Text = "Enter Amount"; } else { decimal minBalance = Banking.MinimumBalance(atm.AccountType);

156

decimal balance = Banking.getCustomerAccountBalance(atm.AccountNumber); if (rechargePhoneCtrl.Amount >(balance-minBalance)) { rechargePhoneCtrl.lblScreen.Text = "You have insuffient fund for this transaction\nEnter another amount"; rechargePhoneCtrl.lblInput.Text = ""; } else { //rechargePhoneCtrl = new RechargePhone(); atm.WithdrawCash(rechargePhoneCtrl.Amount); TerminateATMOperation("Your phone recharge has been completed successfully"); } rechargePhoneStage = 0; } break; case Atm.ATMScreen.AccountTypeMenu: if (NextScreenMode == Atm.ATMScreen.TransferFund) { ScreenMode = Atm.ATMScreen.TransferFund; transferFundCtrl.AccountType = "Savings"; transferFundStage = 2; transferFundCtrl.ShowInputAccount(); pnlATMScreen.Controls.Clear(); pnlATMScreen.Controls.Add(transferFundCtrl); } else if (NextScreenMode == Atm.ATMScreen.MiniStatement) { ScreenMode = Atm.ATMScreen.MiniStatement; if(atm.AccountType=="Savings") miniStatCtrl.ShowMinistatement(Banking.MiniStatement(atm.AccountNumber)); else miniStatCtrl.ShowMinistatement("Wrong account type"); pnlATMScreen.Controls.Clear(); pnlATMScreen.Controls.Add(miniStatCtrl); } else if (atm.AccountType == "Savings") { PerformTransaction(); } else { pnlATMScreen.Controls.Clear(); ScreenMode = Atm.ATMScreen.TerminateTransaction; TerminateTransaction terminate = new TerminateTransaction("Operation terminated");

157

terminate.mainForm = this; pnlATMScreen.Controls.Add(terminate); } break; case Atm.ATMScreen.WithdrawalAmountMenu: withdrawalCtrl.amount = withdrawalOptions[4]; WithdrawCash(); break; case Atm.ATMScreen.InputWithdrawalAmount: pnlATMScreen.Controls.Clear(); ScreenMode = Atm.ATMScreen.TerminateTransaction; TerminateTransaction terminateOp = new TerminateTransaction("Operation terminated"); terminateOp.mainForm = this; pnlATMScreen.Controls.Add(terminateOp); break; case Atm.ATMScreen.PerformAnotherOperation: ScreenMode = Atm.ATMScreen.InputPIN; iPinCtrl = new InputPinControl(); iPinCtrl.CustomerName = atm.CustomerName; //iPinCtrl.ShowCancelProceed(true); pnlATMScreen.Controls.Clear(); pnlATMScreen.Controls.Add(iPinCtrl); iPinCtrl.Password = ""; break; case Atm.ATMScreen.AccountBlocked: case Atm.ATMScreen.InputOneTimePassword: case Atm.ATMScreen.InputPIN: lblButtonCancel_Click(sender, e); break; default: break; } } public void PerformTransaction() { if (NextScreenMode == Atm.ATMScreen.WithdrawalAmountMenu) { pnlATMScreen.Controls.Clear(); pnlATMScreen.Controls.Add(withdrawalCtrl); ScreenMode = Atm.ATMScreen.WithdrawalAmountMenu; NextScreenMode = Atm.ATMScreen.InputWithdrawalAmount; } else if (NextScreenMode == Atm.ATMScreen.BalanceInquiry) { ScreenMode = Atm.ATMScreen.BalanceInquiry; pnlATMScreen.Controls.Clear(); pnlATMScreen.Controls.Add(new BalanceInquiry(atm.AccountNumber));

158

} else if (NextScreenMode == Atm.ATMScreen.TransferFund) { ScreenMode = Atm.ATMScreen.BalanceInquiry; pnlATMScreen.Controls.Clear(); pnlATMScreen.Controls.Add(new BalanceInquiry(atm.AccountNumber)); } } private void lblOperationKeyRight4_Click(object sender, EventArgs e) { switch (ScreenMode) { case Atm.ATMScreen.WithdrawalAmountMenu: withdrawalCtrl.InputAmount(); ScreenMode = Atm.ATMScreen.InputWithdrawalAmount; break; case Atm.ATMScreen.TransactionMenu: NextScreenMode = Atm.ATMScreen.AccountTypeMenu; ScreenMode = Atm.ATMScreen.TransferFund; pnlATMScreen.Controls.Clear(); pnlATMScreen.Controls.Add(transferFundCtrl); break; case Atm.ATMScreen.TransferFund: if (transferFundStage == 1) { transferFundCtrl.Bank = "EcoBank"; transferFundStage = 2; NextScreenMode = Atm.ATMScreen.TransferFund; ScreenMode = Atm.ATMScreen.AccountTypeMenu; pnlATMScreen.Controls.Clear(); pnlATMScreen.Controls.Add(accountTypeCtrl); } break; case Atm.ATMScreen.MiniStatement: PerformAnotherOperation(); break; case Atm.ATMScreen.RechargePhone: if (rechargePhoneStage == 0) { rechargePhoneStage = 1; rechargePhoneCtrl.Network = "ETISALAT"; rechargePhoneCtrl.ShowInputPhoneNumber(); } break; default: break; } }

159

private void lblOperationKeyLeft1_Click(object sender, EventArgs e) { switch (ScreenMode) { case Atm.ATMScreen.WithdrawalAmountMenu: withdrawalCtrl.amount = withdrawalOptions[0]; WithdrawCash(); break; /*case Atm.ATMScreen.CashDeposit: withdrawalCtrl.amount = withdrawalOptions[0]; btnCashDeposit.Enabled = true; break;*/ case Atm.ATMScreen.TransactionMenu: //ScreenMode = Atm.ATMScreen.CashDeposit; //btnCashDeposit.Enabled = true; pnlATMScreen.Controls.Clear(); //pnlATMScreen.Controls.Add(cashDepositCtrl); break; case Atm.ATMScreen.TransferFund: if (transferFundStage == 1) { transferFundCtrl.Bank = "Access Bank"; transferFundStage = 2; NextScreenMode = Atm.ATMScreen.TransferFund; ScreenMode = Atm.ATMScreen.AccountTypeMenu; pnlATMScreen.Controls.Clear(); pnlATMScreen.Controls.Add(accountTypeCtrl); } break; default: break; } } public void PerformAnotherOperation() { ScreenMode = Atm.ATMScreen.PerformAnotherOperation; pnlATMScreen.Controls.Clear(); pnlATMScreen.Controls.Add(new PerformAnotherOperation()); } public void WithdrawCash() { decimal balance = Banking.getCustomerAccountBalance(atm.AccountNumber); decimal minBalance = Banking.MinimumBalance(atm.AccountType); if ((decimal)withdrawalCtrl.amount > (balance - minBalance)) {

160

//Case of insufficient balance withdrawalCtrl.ShowInsuffientBalanceMessage(); } else { CashWithdrawal cash = new CashWithdrawal(); atm.WithdrawCash(withdrawalCtrl.amount); amountWithdrawn = withdrawalCtrl.amount; cash.mainForm = this; pnlATMScreen.Controls.Clear(); pnlATMScreen.Controls.Add(cash); } } private void lblOperationKeyRight2_Click(object sender, EventArgs e) { switch(ScreenMode) { case Atm.ATMScreen.WithdrawalAmountMenu: withdrawalCtrl.amount = withdrawalOptions[5]; WithdrawCash(); break; case Atm.ATMScreen.TransferFund: if (transferFundStage == 1) { transferFundCtrl.Bank = "First Bank"; transferFundStage = 2; NextScreenMode = Atm.ATMScreen.TransferFund; ScreenMode = Atm.ATMScreen.AccountTypeMenu; pnlATMScreen.Controls.Clear(); pnlATMScreen.Controls.Add(accountTypeCtrl); } break; case Atm.ATMScreen.PerformAnotherOperation: ScreenMode = Atm.ATMScreen.TerminateTransaction; TerminateTransaction terminate = new TerminateTransaction("Thanks for banking with\nRemember to take your card", true); terminate.mainForm = this; pnlATMScreen.Controls.Clear(); pnlATMScreen.Controls.Add(terminate); break; case Atm.ATMScreen.InputOneTimePassword: if (otpCtrl.Password == "") return; otpCtrl.ShowCancelProceed(false); if (atm.OTP.ToString() == otpCtrl.Password) { ScreenMode = Atm.ATMScreen.TransactionMenu; transactionCtrl = new TransactionMenu(); transactionCtrl.mainForm = this;

161

atm.PinTrials = 0; pnlATMScreen.Controls.Clear(); pnlATMScreen.Controls.Add(transactionCtrl); } else { if (atm.PinTrials == 3) { ScreenMode = Atm.ATMScreen.AccountBlocked; pnlATMScreen.Controls.Clear(); pnlATMScreen.Controls.Add(new AccountBlocked()); pnlKeypad.Enabled = false; atm.BlockAccount(); } else { otpCtrl.ShowInvalidPin(); } } break; case Atm.ATMScreen.InputPIN: if (iPinCtrl.Password == "") return; iPinCtrl.ShowCancelProceed(false); if (atm.VerifyATMPin(Convert.ToInt32(iPinCtrl.Password))) { atm.PinTrials = 0; iPinCtrl.ShowSendingOTP(); ScreenMode = Atm.ATMScreen.InputOneTimePassword; otpCtrl = new OneTimePassword(); //transactionCtrl.mainForm = this; atm.OTP = new Random().Next(100000, 999999); tmrSendingOTP.Start(); } else { if (atm.PinTrials == 3) { ScreenMode = Atm.ATMScreen.AccountBlocked; pnlATMScreen.Controls.Clear(); pnlATMScreen.Controls.Add(new AccountBlocked()); pnlKeypad.Enabled = false; atm.BlockAccount(); } else { iPinCtrl.ShowInvalidPin(); } } break;

162

case Atm.ATMScreen.TransactionMenu: ScreenMode = Atm.ATMScreen.AccountTypeMenu; NextScreenMode = Atm.ATMScreen.BalanceInquiry; pnlATMScreen.Controls.Clear(); pnlATMScreen.Controls.Add(accountTypeCtrl); break; case Atm.ATMScreen.RechargePhone: if (rechargePhoneStage == 0) { rechargePhoneStage = 1; rechargePhoneCtrl.Network = "GLO"; rechargePhoneCtrl.ShowInputPhoneNumber(); } else TerminateATMOperation("Transaction terminated\nPlease remember to take your card"); break; case Atm.ATMScreen.AccountTypeMenu: if (NextScreenMode == Atm.ATMScreen.TransferFund) { ScreenMode = Atm.ATMScreen.TransferFund; transferFundCtrl.AccountType = "Current"; transferFundStage = 2; transferFundCtrl.ShowInputAccount(); pnlATMScreen.Controls.Clear(); pnlATMScreen.Controls.Add(transferFundCtrl); } else if (NextScreenMode == Atm.ATMScreen.MiniStatement) { ScreenMode = Atm.ATMScreen.MiniStatement; if (atm.AccountType == "Current") miniStatCtrl.ShowMinistatement(Banking.MiniStatement(atm.AccountNumber)); else miniStatCtrl.ShowMinistatement("Wrong account type"); pnlATMScreen.Controls.Clear(); pnlATMScreen.Controls.Add(miniStatCtrl); } else if (atm.AccountType == "Current") { PerformTransaction(); } else { pnlATMScreen.Controls.Clear(); ScreenMode = Atm.ATMScreen.TerminateTransaction; TerminateTransaction terminate_ = new TerminateTransaction("Operation terminated");

163

terminate_.mainForm = this; pnlATMScreen.Controls.Add(terminate_); } break; case Atm.ATMScreen.InputWithdrawalAmount: WithdrawCash(); break; default: break; } } private void lblOperationKeyRight3_Click(object sender, EventArgs e) { switch (ScreenMode) { case Atm.ATMScreen.WithdrawalAmountMenu: withdrawalCtrl.amount = withdrawalOptions[6]; WithdrawCash(); break; case Atm.ATMScreen.TransactionMenu: ScreenMode = Atm.ATMScreen.ChangePIN; pnlATMScreen.Controls.Clear(); pnlATMScreen.Controls.Add(changePinCtrl); changePinStage = 1; break; case Atm.ATMScreen.TransferFund: if (transferFundStage == 1) { transferFundCtrl.Bank = "Unity Bank"; transferFundStage = 2; NextScreenMode = Atm.ATMScreen.TransferFund; ScreenMode = Atm.ATMScreen.AccountTypeMenu; pnlATMScreen.Controls.Clear(); pnlATMScreen.Controls.Add(accountTypeCtrl); } break; case Atm.ATMScreen.AccountTypeMenu: if (NextScreenMode == Atm.ATMScreen.TransferFund) { ScreenMode = Atm.ATMScreen.TransferFund; transferFundCtrl.AccountType = "Fixed Deposit"; transferFundStage = 2; transferFundCtrl.ShowInputAccount(); pnlATMScreen.Controls.Clear(); pnlATMScreen.Controls.Add(transferFundCtrl); } else if (NextScreenMode == Atm.ATMScreen.MiniStatement) {

164

ScreenMode = Atm.ATMScreen.MiniStatement; if (atm.AccountType == "Fixed Deposit") miniStatCtrl.ShowMinistatement(Banking.MiniStatement(atm.AccountNumber)); else miniStatCtrl.ShowMinistatement("Wrong account type"); pnlATMScreen.Controls.Clear(); pnlATMScreen.Controls.Add(miniStatCtrl); } else if (atm.AccountType == "Fixed Deposit") { PerformTransaction(); } else { pnlATMScreen.Controls.Clear(); ScreenMode = Atm.ATMScreen.TerminateTransaction; TerminateTransaction terminate = new TerminateTransaction("Operation terminated"); terminate.mainForm = this; pnlATMScreen.Controls.Add(terminate); } break; case Atm.ATMScreen.RechargePhone: if (rechargePhoneStage == 0) { rechargePhoneStage = 1; rechargePhoneCtrl.Network = "AIRTEL"; rechargePhoneCtrl.ShowInputPhoneNumber(); } break; default: break; } } private void lblOperationKeyLeft2_Click(object sender, EventArgs e) { switch (ScreenMode) { case Atm.ATMScreen.WithdrawalAmountMenu: withdrawalCtrl.amount = withdrawalOptions[1]; WithdrawCash(); break; case Atm.ATMScreen.TransferFund: if (transferFundStage == 1) { transferFundCtrl.Bank = "Zenith Bank"; transferFundStage = 2;

165

NextScreenMode = Atm.ATMScreen.TransferFund; ScreenMode = Atm.ATMScreen.AccountTypeMenu; pnlATMScreen.Controls.Clear(); pnlATMScreen.Controls.Add(accountTypeCtrl); } break; case Atm.ATMScreen.TransactionMenu: NextScreenMode = Atm.ATMScreen.MiniStatement; ScreenMode = Atm.ATMScreen.AccountTypeMenu; pnlATMScreen.Controls.Clear(); pnlATMScreen.Controls.Add(accountTypeCtrl); break; default: break; } } private void lblOperationKeyLeft3_Click(object sender, EventArgs e) { switch (ScreenMode) { case Atm.ATMScreen.WithdrawalAmountMenu: withdrawalCtrl.amount = withdrawalOptions[2]; WithdrawCash(); break; case Atm.ATMScreen.TransferFund: if (transferFundStage == 1) { transferFundCtrl.Bank = "Fidelity Bank"; transferFundStage = 2; NextScreenMode = Atm.ATMScreen.TransferFund; ScreenMode = Atm.ATMScreen.AccountTypeMenu; pnlATMScreen.Controls.Clear(); pnlATMScreen.Controls.Add(accountTypeCtrl); } break; default: break; } } private void lblOperationKeyLeft4_Click(object sender, EventArgs e) { switch (ScreenMode) { case Atm.ATMScreen.WithdrawalAmountMenu: withdrawalCtrl.amount = withdrawalOptions[3]; WithdrawCash(); break;

166

case Atm.ATMScreen.TransactionMenu: ScreenMode = Atm.ATMScreen.RechargePhone; rechargePhoneStage = 0; pnlATMScreen.Controls.Clear(); pnlATMScreen.Controls.Add(rechargePhoneCtrl); break; case Atm.ATMScreen.TransferFund: if (transferFundStage == 1) { transferFundCtrl.Bank = "Union Bank"; transferFundStage = 2; NextScreenMode = Atm.ATMScreen.TransferFund; ScreenMode = Atm.ATMScreen.AccountTypeMenu; pnlATMScreen.Controls.Clear(); pnlATMScreen.Controls.Add(accountTypeCtrl); } break; default: break; } } public void TerminateATMOperation(string msg) { cardPicked = false; transactionCtrl = new TransactionMenu(); transferFundCtrl = new TransferFund(); rechargePhoneCtrl = new RechargePhone(); miniStatCtrl = new MiniStatement(); cashDepositStage = 1; changePinStage = 1; rechargePhoneStage = 0; pnlATMScreen.Controls.Clear(); ScreenMode = Atm.ATMScreen.TerminateTransaction; TerminateTransaction terminate = new TerminateTransaction(msg); terminate.mainForm = this; pnlATMScreen.Controls.Add(terminate); } int t = 435; private void tmrMoney_Tick(object sender, EventArgs e) { picMoney.Show(); if (t < 460) { picMoney.Top = (++t); } else

167

{ t = 435; picMoney.Location = new Point(238, 435); tmrMoney.Stop(); picMoney.Hide(); } } public string AccountStatement() { return DateTime.Now + "\nAmount withdrawn: N" + amountWithdrawn + "\nAccount balance: N" + Banking.getCustomerAccountBalance(atm.AccountNumber); } private void tmrSendingOTP_Tick(object sender, EventArgs e) { if (atm.SendOneTimePassword()) { pnlATMScreen.Controls.Clear(); pnlATMScreen.Controls.Add(otpCtrl); } else { TerminateATMOperation("One time password was not sent"); } tmrSendingOTP.Stop(); } } }

168

Appendix C

Banking Class Source Code

using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Data.SqlClient; namespace ATM { classBanking { public Banking() { } publicCustomer getCustomer(string account) { Customer customer = newCustomer(); SqlConnection sqlCon = newSqlConnection(@"Data Source=.\SQLEXPRESS;AttachDbFilename=|DataDirectory|\bankdb.mdf;Integrated Security=True;Connect Timeout=30;User Instance=True"); try { sqlCon.Open(); SqlCommand sqlCmd = newSqlCommand("SELECT * FROM customers, bank_account WHERE customers.account_number=bank_account.account_number AND customers.account_number='" + account + "'", sqlCon); SqlDataReader sdr = sqlCmd.ExecuteReader(); if (sdr.Read()) { customer.ID = sdr.GetInt32(0); customer.AccountNumber = account; customer.Surname = sdr.GetString(2); customer.Firstname = sdr.GetString(3); customer.Middlename = sdr.GetString(4); customer.Sex = sdr.GetString(5); customer.Birthday = sdr.GetDateTime(6); customer.Phone = sdr.GetString(7); customer.Email = sdr.GetString(8); customer.StateOfOrigin = sdr.GetString(9); customer.LGAOfOrigin = sdr.GetString(10); customer.Nationality = sdr.GetString(11); customer.ResidentialAddress = sdr.GetString(12); customer.BankName = sdr.GetString(13); customer.AccountType = sdr.GetString(15); customer.AccountBalance = sdr.GetDecimal(16);

169

customer.Blocked = sdr.GetBoolean(17); } sdr.Close(); } catch (Exception ex) { System.Windows.Forms.MessageBox.Show(ex.Message, "Connection Error", System.Windows.Forms.MessageBoxButtons.OK, System.Windows.Forms.MessageBoxIcon.Error); } sqlCon.Close(); return customer; } publicstructCustomer { publicint ID; publicstring AccountNumber; publicstring Surname; publicstring Firstname; publicstring Middlename; publicstring Sex; publicDateTime Birthday; publicstring Phone; publicstring Email; publicstring StateOfOrigin; publicstring LGAOfOrigin; publicstring Nationality; publicstring ResidentialAddress; publicstring BankName; publicstring AccountType; publicdecimal AccountBalance; publicbool Blocked; } publicstaticdecimal MinimumBalance(string accType) { decimal amount = 0; bankdbDataSetTableAdapters.bank_minbalanceTableAdapter minBal = new bankdbDataSetTableAdapters.bank_minbalanceTableAdapter(); if (accType == "Savings") amount = minBal.GetData()[0].minbalance; elseif (accType == "Current") amount = minBal.GetData()[1].minbalance; else amount = minBal.GetData()[2].minbalance; return amount; } publicstaticdecimal getCustomerAccountBalance(string acc) { decimal balance = 0;

170

SqlConnection sqlCon = newSqlConnection(@"Data Source=.\SQLEXPRESS;AttachDbFilename=|DataDirectory|\bankdb.mdf;Integrated Security=True;Connect Timeout=30;User Instance=True"); try { sqlCon.Open(); SqlCommand sqlCmd = newSqlCommand("SELECT balance FROM bank_account WHERE account_number ='" + acc + "'", sqlCon); SqlDataReader sdr = sqlCmd.ExecuteReader(); if (sdr.Read()) { balance = sdr.GetDecimal(0); } sdr.Close(); } catch (Exception ex) { System.Windows.Forms.MessageBox.Show(ex.Message, "Connection Error", System.Windows.Forms.MessageBoxButtons.OK, System.Windows.Forms.MessageBoxIcon.Error); } sqlCon.Close(); return balance; } publicstaticbool VerifyAccount(string acc) { bool result = false; SqlConnection sqlCon = newSqlConnection(@"Data Source=.\SQLEXPRESS;AttachDbFilename=|DataDirectory|\bankdb.mdf;Integrated Security=True;Connect Timeout=30;User Instance=True"); try { sqlCon.Open(); SqlCommand sqlCmd = newSqlCommand("SELECT * FROM bank_account WHERE account_number ='" + acc + "'", sqlCon); SqlDataReader sdr = sqlCmd.ExecuteReader(); if (sdr.Read()) { result=true; } sdr.Close(); } catch (Exception ex) { } sqlCon.Close(); return result; } publicstaticbool VerifyAccountType(string acc, string accType) { bool result = false; SqlConnection sqlCon = newSqlConnection(@"Data Source=.\SQLEXPRESS;AttachDbFilename=|DataDirectory|\bankdb.mdf;Integrated Security=True;Connect Timeout=30;User Instance=True");

171

try { sqlCon.Open(); SqlCommand sqlCmd = newSqlCommand("SELECT * FROM bank_account WHERE account_number ='" + acc + "' AND account_type='" + accType + "'", sqlCon); SqlDataReader sdr = sqlCmd.ExecuteReader(); if (sdr.Read()) { result = true; } sdr.Close(); } catch (Exception ex) { } sqlCon.Close(); return result; } publicstaticstring ValidateCustomerAccount(string acc, string bank, string accType) { if (!VerifyAccount(acc)) return"Invalid account number"; elseif(!VerifyAccountType(acc,accType)) return"Invalid account type"; string result = "Invalid bank"; SqlConnection sqlCon = newSqlConnection(@"Data Source=.\SQLEXPRESS;AttachDbFilename=|DataDirectory|\bankdb.mdf;Integrated Security=True;Connect Timeout=30;User Instance=True"); try { sqlCon.Open(); SqlCommand sqlCmd = newSqlCommand("SELECT * FROM customers WHERE account_number ='" + acc + "' AND bank_name='" + bank + "'", sqlCon); SqlDataReader sdr = sqlCmd.ExecuteReader(); if (sdr.Read()) { result = "correct"; } sdr.Close(); } catch (Exception ex) { System.Windows.Forms.MessageBox.Show(ex.Message, "Connection Error", System.Windows.Forms.MessageBoxButtons.OK, System.Windows.Forms.MessageBoxIcon.Error); } sqlCon.Close(); return result; } publicstaticstring MiniStatement(string account) { string statement = "";

172

SqlConnection sqlCon = newSqlConnection(@"Data Source=.\SQLEXPRESS;AttachDbFilename=|DataDirectory|\bankdb.mdf;Integrated Security=True;Connect Timeout=30;User Instance=True"); try { int t = 0; sqlCon.Open(); SqlCommand sqlCmd = newSqlCommand("SELECT * FROM bank_transactions WHERE account_number ='" + account + "' ORDER BY transaction_id DESC", sqlCon); SqlDataReader sdr = sqlCmd.ExecuteReader(); while (sdr.Read()) { string transType = sdr.GetString(8); statement += (++t) + ") " + sdr.GetDecimal(2) + (transType=="Cash Deposit" ? " was credited on " : " was debited on ") + sdr.GetDateTime(7).ToString() +" at "+ sdr.GetString(9)+ "\n"; } sdr.Close(); } catch (Exception ex) { System.Windows.Forms.MessageBox.Show(ex.Message, "Connection Error", System.Windows.Forms.MessageBoxButtons.OK, System.Windows.Forms.MessageBoxIcon.Error); } sqlCon.Close(); return (statement == string.Empty ? "No transaction made so far" : statement); } } }