Lecture Notes on Data Engineering

and Communications Technologies 62

Valentina E. Balas
Aboul Ella Hassanien
Satyajit Chakrabarti
Lopa Mandal Editors

Proceedings
of International
Conference
on Computational
Intelligence, Data
Science and Cloud
Computing
IEM-ICDC 2020
Multilevel User Verification in Cloud
Banking System

Ankur Biswas and Abhishek Roy

Abstract The recent incidents of sky high fraudulent banking transactions, ponzi
monetary schemes and its corresponding corruption charges have shaken the eco-
nomic backbone of India. Its impact is so high that Government has to opt for legal
remedies to bring back the imposters under justice. This scenario clearly depicts
that existing banking system is incapable to handle and crack down these fraudulent
activities and hence it requires extensive research work to prevent similar incidents
in near future. Information and communication technology (ICT)-based electronic
message communication system may be utilized under controlled environment to
monitor and maintain these financial transaction from its initial stage. Since cyber
space is an open forum, which is easily accessible to all (including the adversaries),
multilevel verification of user will help to reduce risk factors of banking transactions
to significant level, if not eliminate it completely. This monitoring system will be
more cohesive in nature if a single window-based integrated environment streamlines
all the parties engaged in a specific banking transaction. To achieve this objective,
in this paper, authors have proposed a Multipurpose Electronic Card (MEC)-based
Cloud Banking System (CBS) as a part of broader Integrated Electronic Service
Delivery System (IESDS), which will verify its user (i.e. Client) through multilevel
architecture.

Keywords Cloud banking · User verification · Multilevel architecture

A. Biswas (B) · A. Roy

Department of Computer Science & Engineering, Adamas University,
Kolkata, West Bengal, India
e-mail: ankur2u@gmail.com
A. Roy
e-mail: dr.aroy@yahoo.com

© The Author(s), under exclusive license to Springer Nature Singapore Pte Ltd. 2021 527
V. E. Balas et al. (eds.), Proceedings of International Conference on Computational
Intelligence, Data Science and Cloud Computing, Lecture Notes on Data Engineering
and Communications Technologies 62, https://doi.org/10.1007/978-981-33-4968-1_41
528 A. Biswas and A. Roy

1 Introduction

Recently, India is witnessing rapid growth of fraud banking transactions in vari-

ous forms like unauthorized ATM transactions by adversaries, bank loan approvals
for fraudsters, money laundering due to ponzi monetary schemes, etc., which have
shaken the economic backbone of our country and caused untimely death of many
victims. In most of these cases, adversary manages to conceal its activities due to
its high level contacts within the system and often flew out of country to avoid legal
consequences. Its impact is so high that Government has to opt for legal remedies to
bring back the imposters under justice. The entire scenario clearly reveals that bank-
ing system is facing severe challenge due to its internal and external adversaries.
To be precise, existing banking system is insufficient to control these fraud trans-
actions, which calls for thorough research work to neutralize those illicit banking
transactions from its initial stage. To achieve this objective, in the following sec-
tions, a multilevel user verification scheme (using single window interface, namely
Multipurpose Electronic Card) has been proposed for Citizen centric Cloud Banking
System (CBS).
Section 2 mentions the origin of our research work. Section 3 explains our pro-
posed Cloud Banking System (CBS) during Citizen to Government to Bank to Citizen
(C2G2B2C) type of transaction. Section 4 mentions the conclusion of our present
work and explores its future possibilities.

2 Origin of Work

Information and communication technology (ICT) plays a vital role to deliver multi-
faceted electronic services to Citizen in cost effective and timely manner. As Internet
is an open cyber space, which is equally accessible to all (including the adversaries),
installation of proper security protocol will ensure detection and subsequent neu-
tralization of illicit attempts at its initial stage. As users communicate with each
other through virtual mode during electronic communication, strict verification of
user’s digital identity will provide significant advantage to any electronic service
delivery model. Furthermore, a single window interface can be proposed to bring
compactness of all Citizen centric electronic services. Though critics may raise con-
cern about privacy issues of Citizen due to the involvement of Government during
electronic transactions, as a victim of terrorism (in all possible form), we can not
afford unbounded liberty of Citizen. Furthermore, the involvement of Government
during these electronic transactions will also help Citizen to seek prompt assistance
during any adverse situation. The block diagram of our proposed Integrated Elec-
tronic Service Delivery system (IESDS) [1–3] is shown through Fig. 1, which is also
explained below:
Multilevel User Verification in Cloud Banking System 529

1. Primary players of electronic transaction:

(a) Citizen (i.e. Client or Service Seeker).
(b) Government (i.e. State and its agencies).
(c) Service Provider (e.g. Bank [5, 7, 8, 12, 14, 15, 19, 21], University, Hospital,
Employer, Transport Services, etc.).
2. Phases of an electronic transaction:
(a) Citizen to Government (C2G): During this phase, Citizen uses Multipurpose
Electronic Card (MEC) to send SERVICE REQUEST (using Path—1 of
Fig. 1) to Government through Public Kiosk (i.e. Public Cloud).
(b) Government to Service Provider (G2S): During this phase, Government ver-
ifies the identity [18] of Citizen, and only in case of successful verification,
SERVICE REQUEST is processed towards appropriate Service Provider.
We have also considered privacy issues of Citizen judiciously. For this rea-
son, Service Provider will send its SERVICE RESPONSE through Trans-
action Master, which is not under the direct control of Government.
(c) Service Provider to Citizen (S2C): During this phase, Service Provider
receives SERVICE REQUEST of Citizen through Government and re-
verify its identity. In case of successful verification, Service Provider
responds with SERVICE RESPONSE to Citizen (i.e. Client) using Path—2
of Fig. 1.

Fig. 1 Block diagram of Integrated Electronic Service Delivery System (IESDS)

530 A. Biswas and A. Roy

As our objective is to ensure cost effective and prompt electronic service [9, 13,
20] delivery to doorstep of end user (i.e. Citizen), we have shown our conceptual
diagram through Fig. 2 during Citizen to Government to Service Provider to Citizen
(C2G2S2C) type of transaction, which is also described below:
1. Citizen side:
(a) Citizen initiates electronic transaction using Multipurpose Electronic Card
(MEC).
(b) Citizen transmits its unique parameter and SERVICE REQUEST using
Path—1 of Fig. 2 to Government through Public Kiosk (i.e. Public Cloud).
The primary objective of Citizen is to avail SERVICE RESPONSE after
successful verification of its digital identity.
2. Government side:
(a) Cloud Governance (C-Governance) Interface receives unique parameter and
SERVICE REQUEST of Citizen through its Firewall.
(b) Government verifies the identity of Citizen.
Scenario 1 (Verification Failure): In this case, transaction is aborted, and Cit-
izen is informed through system time out.
Scenario 2 (Verification Success): In this case, transaction proceeds towards
Cloud Service (C-Service) Server for further identification of the electronic
service requested by Citizen (i.e. Client).
(c) Cloud Service (C-Service) Server performs READ and WRITE operations
over the Data Centre attached its Private Cloud and transmits SERVICE
REQUEST to service specific server. In our proposed system, we have used
various service servers which will contain detailed information of all Third
Party Service Providers of that specific service domain. For example, Bank
Server will contain the detailed information of all the banks eligible to provide
electronic banking facilities to its Client.
(d) Service-specific server identifies the exact Third Party Service Provider
desired by Citizen (i.e. Client) and transmits its SERVICE REQUEST to
that Third Party Service Provider for its final execution. To ensure privacy
of Citizen, in our proposed system, Government can monitor any SERVICE
REQUEST only up to this phase of transaction.
3. Service Provider side (i.e. Third Party):
(a) Service Provider receives SERVICE REQUEST of Citizen and re-verifies
its identity.
Scenario 3 (Verification Failure): In case of unsuccessful verification, the
transaction is aborted, and Citizen is informed through system time out.
Scenario 4 (Verification Success): In case of successful verification, Service
Provider sends SERVICE RESPONSE to Citizen.
4. Citizen side:
(a) Citizen access SERVICE RESPONSE using Path—2 of Fig. 2.
Multilevel User Verification in Cloud Banking System 531

In Sect. 3, we have discussed our Cloud Banking System (CBS) using this proposed
Citizen centric Multipurpose Electronic Card (MEC).

3 Proposed Cloud Banking System (CBS)

Figure 3 shows the schematic diagram of our Citizen centric Cloud Banking System
(CBS) which have been offered through single window interface, i.e. Multipurpose
Electronic Card (MEC). Throughout our approach, we have focused on broader
Integrated Electronic Service Delivery System (IESDS), and Cloud Banking System
(CBS) is a part of that system which will deliver banking facilities to Citizen through
electronic medium. In order to help Government to identify illicit transactions of
adversaries, we have shown multilevel user authentication [4, 6, 10, 11, 16, 17]
scheme during Citizen to Government to Bank to Citizen (C2G2B2C) type of Cloud
Banking transaction, which is described below:
1. Phase 1: It denotes the Cloud Governance transaction, where Government verifies
the identity of Citizen (i.e. Client) and transmits SERVICE REQUEST to Phase
2 of transaction.
2. Phase 2: It denotes the banking transaction of Citizen (i.e. Client), which is
assessed within the Cloud Governance system to identify the exact Third Party
Service Provider (i.e. Bank). After identification of the exact service provider (i.e.
Bank), SERVICE REQUEST of Citizen is transmitted to Phase 3 of transaction.
3. Phase 3: It denotes the final phase of transaction where Third Party Service
Provider (i.e. Bank) interacts with Citizen to deliver the SERVICE RESPONSE
through Public Kiosk (i.e. Public Cloud). The Transaction Master shown in Fig. 1
maintains the log of all transactions carried out by Citizen using Transaction In
Log and Transaction Out Log, respectively.
The algorithm of our Cloud Banking System (CBS) is explained in Sect. 3.1.

3.1 Algorithm

The primary players of our proposed system are Client (i.e. Citizen), Government
(i.e. State and its agencies) and Bank (i.e. Third Party Service Provider) which are
connected through Public Kiosk (i.e. Public Cloud). The step-wise explanation of
our Cloud Banking System (CBS) is mentioned below:
CLIENT Side:
Step 1: Client uses Multipurpose Electronic Card (MEC) to initiate banking trans-
action through Public Kiosk (i.e. Public Cloud).
PUBLIC KIOSK Side:
Step 2: As in this paper we are focusing on Cloud Banking System (CBS), we
 532

Fig. 2 Conceptual diagram of Integrated Electronic Service Delivery System (IESDS)

A. Biswas and A. Roy
Multilevel User Verification in Cloud Banking System 533

Fig. 3 Proposed Cloud Banking System (CBS)

534 A. Biswas and A. Roy

assume that preliminary verification of Citizen using Username, Password and One
Time Password (OTP), etc. (which are actually the part of core Cloud Governance
transaction) have been completed successfully.
Step 3: Public Kiosk transmit SERVICE REQUEST to Government for identifica-
tion of bank mentioned in the SERVICE REQUEST.
GOVERNMENT Side:
Step 4: As the main objective of Government is to process Cloud Banking transaction
in a secure manner, it receives SERVICE REQUEST through its Firewall which
prevents entry of malicious code within the system. This step denotes the starting of
Phase 1 shown in Fig. 3.
Step 5: Then, it passes through Intrusion Detection System (IDS) and Intrusion Pre-
vention System (IPS) which provides next layer of security to sensitive information
of Client.
Step 6: At this stage of transaction, for first time the Cloud Banking Interface (which
is mainly the part of Cloud Governance system) receives SERVICE REQUEST of
Client.
Step 7: It further verifies the SERVICE REQUEST of Client.
Scenario 1 (Verification Success): The transaction proceeds towards Step—12, i.e.
starting of Phase 2 as shown in Fig. 3.
Scenario 2 (Verification Failure): The transaction proceeds towards Step—8 to give
further scope of transaction to Client.
Step 8: In this case, Verification Failed function is called to monitor the number of
failed attempts and redirect it to provide further scope of transaction up to maximum
count three (i.e. 03).
Step 9: A counter with initial value as zero (i.e. 0) is assigned to count the number
of failed attempts / transactions, which should not allow more than three attempts.
Step 10: Cloud Banking Interface re-verifies the SERVICE REQUEST of Client.
This step is executed as long as the total number of failed attempts does not cross
the limit of count three (i.e. 03).
Scenario 3 (Verification Success):
In case of successful verification, SERVICE REQUEST proceeds towards Step—
12, i.e. starting of Phase 2 as shown in Fig. 3.
Scenario 4 (Verification Failure):
In case of unsuccessful verification, SERVICE REQUEST is aborted, and transac-
tion proceeds towards Step—11.
Step 11: Client is informed through system timeout about cancellation of SERVICE
REQUEST after three failed attempts. This step denotes the unsuccessful termina-
tion of proposed Cloud Banking System (CBS).
Step 12: SERVICE REQUEST arrives at this step after successful verification by
Cloud Banking Interface of Government. It is further optimized by Query Optimizer
to enhance its performance.
Step 13: It proceeds through Scheduler for faster channelization compared to simul-
taneous SERVICE REQUEST of other Clients.
Multilevel User Verification in Cloud Banking System 535

Step 14: As the primary objective of Government is to facilitate secured Cloud

Banking transaction, it receives SERVICE REQUEST through Firewall of Cloud
Banking Interface to forestall entry of malicious codes of adversary.
BANK Side:
Step 15: At this stage of transaction, SERVICE REQUEST identifies its specific
Bank for execution at the Third Party Service Provider side.
Step 16: SERVICE REQUEST passes through Firewall of the selected Bank.
Step 17: To provide additional layer of security to SERVICE REQUEST, it further
passes through Intrusion Detection System (IDS) and Intrusion Prevention System
(IPS).
Step 18: As the starting of Phase 3 as shown in Fig. 3, Private Cloud of Bank receives
SERVICE REQUEST of Client. During this phase, the Data Centre attached to
Private Cloud of Bank performs READ and WRITE operations to record all banking
transactions.
Step 19: Bank further verifies the identity of its Client.
Scenario 5 (Verification Success): In case of successful verification, transaction pro-
ceeds towards Step—20.
Scenario 6 (Verification Failure): In case of unsuccessful verification, transaction
goes back to Step—8 to provide further scope of transaction to Client up to maxi-
mum count three (i.e. 03).
Step 20: Bank starts session to process SERVICE REQUEST. This step denotes the
starting point of final execution of banking transaction after satisfying all security
protocols of Government and Bank, respectively.
Step 21: It passes through scheduler to speed up the desired transaction.
Step 22: Transaction In Log is generated and stored in the Data Server.
Step 23: After generating the Transaction Log, Bank displays type of bank accounts
available for the Client.
Step 24: At this stage, Client selects specific banking service from the list of available
services.
Step 25: After selection of type of transaction, SERVICE REQUEST goes through
its operational validation.
Scenario 7 (Status: SUCCESS): In case of successful validation, SERVICE
REQUEST proceeds towards Step—26 of banking transaction.
Scenario 8 (Status: FAILURE): In case of unsuccessful validation, SERVICE
REQUEST initiates abort( ) function and proceeds towards Step—26 of banking
transaction.
Step 26: To maintain transaction details (i.e. for both successful and unsuccessful
attempts), Transaction Out Log is generated and stored in Data Server of selected
Bank.
Step 27: BANK terminate the Session and sends SERVICE RESPONSE through
Public Kiosk to Client.
PUBLIC KIOSK Side:
Step 28: Public Kiosk transmit SERVICE RESPONSE to Client.
536 A. Biswas and A. Roy

CLIENT Side:
Step 29: Client accesses SERVICE RESPONSE through Public Kiosk. This step
denotes successful termination of proposed Cloud Banking System (CBS).

4 Conclusion

In this paper, we have shown Cloud Banking System (CBS) within Integrated
Electronic Service Delivery System (IESDS) during Citizen to Government to
Bank to Citizen (C2G2BC) type of banking transaction. We have judiciously bal-
anced between privacy concern of an individual and the necessity for state spon-
sored surveillance for greater benefit of society. Hence, we have sent SERVICE
RESPONSE through Transaction Master, which is not only beyond the direct control
of Government but also records all successful and unsuccessful (i.e. illicit attempts
of adversaries) banking transactions of user through Transaction In Log and Trans-
action Out Log, respectively. For this reason, we will further explore the features
of Transaction Master in our future work. Considering the security aspect of our
nation, neither we can afford unbounded liberty of user nor we should allow absolute
surveillance over user’s transaction. Our objective is to provide a secured single win-
dow interface for delivery of multivariate electronic services to user and at the same
time facilitate Government to respond promptly during adverse situation, so that
adversaries does not get any scope to fulfil their ill intentions. However, in future, we
have to explore in details all the security protocols of our proposed Cloud Banking
System (CBS) to gain trust of user.

References

1. A. Roy, Object-oriented modeling of multifaceted service delivery system using connected

governance, in Automated Software Testing. ICDCIT 2019. Services and Business Process
Reengineering, ed. by A. Jena, H. Das, D. Mohapatra (Springer, Singapore, 2020), pp. 1–25.
https://doi.org/10.1007/978-981-15-2455-4_1
2. A. Roy, Smart delivery of multifaceted services through connected governance, in 3rd Interna-
tional Conference on Computing Methodologies and Communication (ICCMC) (IEEE, India,
2019), pp. 476–482. https://doi.org/10.1109/ICCMC.2019.8819851
3. S. Biswas, A. Roy, An intrusion detection system based secured electronic service delivery
model, in 2019 3rd International Conference on Electronics, Communication and Aerospace
Technology (ICECA), Coimbatore, India, pp. 1316–1321 (2019). https://doi.org/10.1109/
ICECA.2019.8822016
4. A. Biswas, A. Roy, A study on dynamic ID based user authentication system using smart card.
Asian J. Convergence Technol. (AJCT) 5, 2 (2019). http://www.asianssr.org/index.php/ajct/
article/view/871 Retrieved on 08/03/2020. ISSN 2350-1146
5. A. Mahalle, J. Yong, X. Tao, Protecting privacy in digital era on cloud architecture for banking
and financial services industry, in 2019 6th International Conference on Behavioral, Economic
and Socio-Cultural Computing (BESC), Beijing, China, pp. 1–6 (2019). https://doi.org/10.
1109/BESC48373.2019.8963459
Multilevel User Verification in Cloud Banking System 537

6. I. Gordin, A. Graur, A. Potorac, Two-factor authentication framework for private cloud, in 2019
23rd International Conference on System Theory, Control and Computing (ICSTCC), Sinaia,
Romania, pp. 255–259 (2019). https://doi.org/10.1109/ICSTCC.2019.8885460
7. A. Mahalle, J. Yong, X. Tao, Ethics of IT security team for cloud architecture infrastructure
in banking and financial services industry, in 2019 IEEE 23rd International Conference on
Computer Supported Cooperative Work in Design (CSCWD), Porto, Portugal, pp. 506–511
(2019). https://doi.org/10.1109/CSCWD.2019.8791928
8. M. Singh, K.S. Tanwar, V.M. Srivastava, Cloud computing adoption challenges in the banking
industry, in 2018 International Conference on Advances in Big Data, Computing and Data
Communication Systems (icABCD), Durban, pp. 1–5 (2018). https://doi.org/10.1109/ICABCD.
2018.8465412
9. X. Liao, S. Alrwais, K. Yuan et al., Cloud repository as a malicious service: challenge, identi-
fication and implication, in Cybersecurity, vol. 1, 14 (2018). https://doi.org/10.1186/s42400-
018-0015-6
10. J. Gowthami, N. Shanthi, N. Krishnamoorthy, Secure three-factor remote user authentication
for E-Governance of smart cities, in 2018 IEEE International Conference on Current Trends
Toward Converging Technologies (IEEE, India, 2018), pp. 1–8. https://doi.org/10.1109/icctct.
2018.8551172
11. S. Dhal, V. Bhuwan, Cryptanalysis and improvement of a cloud based login and authentication
protocol, in 2018 4th International Conference on Recent Advances in Information Technology
(RAIT) (IEEE, Dhanbad, India, 2018). https://doi.org/10.1109/RAIT.2018.8388988
12. S.P. Tripathi, A. Kumar, R. Astya, Study on secured framework for cloud based online banking,
in 2017 International Conference on Computing, Communication and Automation (ICCCA),
Greater Noida, pp. 853–858 (2017). https://doi.org/10.1109/CCAA.2017.8229915
13. N. Srilatha, G. Mrali, M. Deepthi, A framework to improve E-seva services through E-
governance by using DNA cryptography, in 2017 International Conference on Algorithms,
Methodology, Models and Applications in Emerging Technologies (ICAMMAET) (IEEE, India,
2017), pp. 1–4. https://doi.org/10.1109/ICAMMAET.2017.8186748
14. S. Nagaraju, L. Parthiban, Trusted framework for online banking in public cloud using multi-
factor authentication and privacy protection gateway. J. Cloud Comp. 4, 22 (2015). https://doi.
org/10.1186/s13677-015-0046-4
15. J. Park, Y. An, K. Yeom, Virtual cloud bank: an architectural approach for intermediating
cloud services, in 2015 IEEE/ACIS 16th International Conference on Software Engineering,
Artificial Intelligence, Networking and Parallel/Distributed Computing (SNPD), Takamatsu,
pp. 1–6 (2015). https://doi.org/10.1109/SNPD.2015.7176235
16. N.E. Madhoun, F. Guenane, G. Pujolle, A cloud-based secure authentication protocol for
contactless-NFC payment, in 2015 IEEE 4th International Conference on Cloud Network-
ing (CloudNet), Niagara Falls, ON, pp. 328–330 (2015). https://doi.org/10.1109/CloudNet.
2015.7335332
17. S.K.S.V.A. Kavuri, G.R. Kancherla, B.R. Bobba, Data authentication and integrity verification
techniques for trusted/untrusted cloud servers, in 2014 International Conference on Advances
in Computing, Communications and Informatics (ICACCI), New Delhi, pp. 2590–2596 (2014).
https://doi.org/10.1109/ICACCI.2014.6968657
18. U. Habiba, R. Masood, M. Shibli, M. Niazi, Cloud identity management security issues and
solutions: a taxonomy, in Complex Adaptive Systems Modeling, vol. 2, 5 (2014). https://doi.
org/10.1186/s40294-014-0005-9
19. l. Sangavarapu, S. Mishra, A. Williams, G.R. Gangadharan, The Indian banking community
cloud, in IT Professional, vol. 16, 6, pp. 25–32 (2014). https://doi.org/10.1109/MITP.2014.97
20. F. Zhu, H. Li, J. Lu, A service level agreement framework of cloud computing based on
the Cloud Bank model, in 2012 IEEE International Conference on Computer Science and
Automation Engineering (CSAE), Zhangjiajie, pp. 255–259 (2012). https://doi.org/10.1109/
CSAE.2012.6272592
21. J. Jiang, D. Yang, A research on commercial bank information systems based on cloud comput-
ing, in 2011 IEEE 3rd International Conference on Communication Software and Networks,
Xi’an, pp. 363–366 (2011). https://doi.org/10.1109/ICCSN.2011.6014585