Keywords

1 Introduction

The “Mobile Banking System” in this paper referes to the concept of a mobile banking system in general. With the advancement of mobile technologies, most modern commerce payments depend on the mobile banking system that is always open 24/7, 365 days a year for financial transactions. However, the unfortunate truth is that fraudulent transactions are also around-the-clock operations. With the continuous improvement and growth at a rapid pace in the utility of mobile banking payment technologies, fraudulent mobile banking transactions are being multiplied using bleeding-edge technologies sharply and a significant economic loss is made every year around the world. 2019 Iovation financial services fraud and consumer trust report [24] show that 61% of financial transactions originate from mobile and 50% of suspected fraudulent transactions seen by Iovation are from mobile devices. Fraudsters seek new vulnerabilities with every advance in fraud prevention and have become an even more pressing issue of security challenges for banks and financial institutions. Fraud-the Facts 2021 [25] revealed that mobile banking fraud losses increased by 41% in 2020 in the UK.

Mobile banking users download phishing apps unknowingly, install them on their mobile devices, and input login credentials (Username and password) in the phishing app unintentionally. They follow the links in the phishing emails/SMS and are redirected to the phishing login interface, and they input the login credentials in the phishing login interface. Thus, phishers steal login credentials using phishing apps or phishing login interfaces from mobile banking users and employ the stolen login credentials to login into the mobile banking system. As the login credentials are valid, phishers login into the mobile banking system. Phishers request a transaction, and MBS sends a one-time password (OTP) for the security of the transaction. However, phishers reply to the OTP, and they execute the fraudulent transactions as shown in the threat model in Fig. 1.

Fig. 1.
figure 1

Threat model for phishing in mobile banking system at transaction level

Full size image

Generally, mobile banking users provide usernames and passwords only once on their mobile devices for MBS and MBS do not ask for a password each time they use the MBS. MBS use OTP for security when they request a transaction. Phishers get stolen/lost users’ mobile devices and they do not have to enter the username and password to use the MBS. They request fraudulent transactions using the stolen/lost mobile devices. Currently, security is maintained in the MBS at the transaction level using login credentials and the OTP mechanism (Two-factor authentication). Phishers do not have to input login credentials (Username and password) on mobile devices. MBS sends OTP to the phishers for security and asks to reply to the OTP. Phishers have physical access to mobile devices and reply to OTP easily and execute fraudulent transactions. Hence, only two-factor authentication (Login credentials, and OTP) mechanism cannot stop phishers from executing fraudulent transactions, and there is a need for multi-factor authentication to stop the fraudulent transactions in the mobile banking system.

Researchers have worked to prevent these frauds and enhance the security measures for fraudulent transactions. Researchers developed a layered approach for near-field communication (NFC) enabled mobile payment systems [1] and used machine learning algorithms for the mobile fraud detection system [2, 3]. However, machine learning can solve simple fraud cases, and more complex frauds require human intervention. Fraudsters also use emerging technologies to mimic the transaction behavior of genuine customers. They also keep changing their methods so that it is difficult to detect fraud using machine learning methods. Authors of [4,5,6,7,8] presented a fraud detection system for electronic banking systems in which [4] proposed biometric security and systems, and [5,6,7,8] employed machine learning for fraud detection in electronic banking transactions. Authors of [9,10,11,12,13,14,15,16,17,18,19,20] used machine learning, deep learning, and neural networks for fraud detection in online transactions and banking transactions. Authors of [21,22,23] developed fraud detection systems for financial databases.

The above research adopted machine learning models to mitigate fraudulent transactions in online transactions. However, these approaches are inefficient and insufficient to account for fraudulent transactions in the mobile banking system. To overcome this gap, this paper presents a new anti-phishing model for mobile banking systems at the transaction level (AntiPhiMBS-TRN), and the objective of this research is to mitigate fraudulent transactions executed using stolen login credentials and stolen/lost mobile devices. Banks and financial institutions can implement AntiPhiMBS-TRN to mitigate fraudulent transactions in the mobile banking industry. The paper is further structured as follows: Sect. 2 describes the related works, Sect. 3 presents the novel anti-phishing model to mitigate fraudulent transactions in the mobile banking system, Sect. 4 describes the results and discussion, and Sect. 5 presents conclusions and future work.

2 Related Works

Researchers have worked on the prevention of fraudulent transactions in digital banking. Vishwakarma, Tripathy, and Vemuru [1] proposed a layered approach for near field communication (NFC) enabled mobile payment system to prevent fraudulent transactions. Delecourt and Guo [2] utilized potential reactions of fraudsters into consideration to build a robust mobile fraud detection system using adversarial examples. Zhou, Chai, and Qiu [3] introduced several traditional machine learning algorithms for fraud detection in the mobile payment system. Eneji, Angib, Ibe, and Ekwegh [4] focused on the integration of biometric security to mitigate and combat electronic banking frauds. Ali, Hussin, and Abed [5] reviewed various attack detection systems and identified transaction monitoring as the most effective model for electronic banking (e-banking). Pracidelli, and Lopes [6] proposed the artifacts capable of minimizing electronic payment fraud problems using unsupervised and supervised algorithms. Guo,Wang,Dai,Cheng, and Wang [7] proposed a novel fraud risk monitoring system for e-banking transactions. Seo and Choi [8] used machine learning techniques for predicting abusers in electronic transactions.

Minastireanu and Mesnita [9] reviewed the existing research in fraud detection and found that the best results were achieved in terms of accuracy and coverage by the supervised learning techniques. Zhou, Zhang, Wang, and Wang [10] used the siamese neural network structure to solve the problem of sample imbalance in online transactions. Khattri and Singh [11] proposed a new distance authentication mechanism for committing a valid and secure online transaction using a credit card or debit card. Kanika and Singla [12] reviewed the use of deep learning techniques for online transaction fraud detection. Hartl and Schmuntzsch [13] focused on the user-end fraud detection and protection for online banking in social engineering. Kataria and Nafis [14] compared the hidden Markov model, deep learning, and neural network to detect fraud in online banking transactions. Masoud and Mehdi [15] used the k nearest neighbor technique with association rules to improve the algorithms for detecting outliers in credit card transactions for electronic banking. Eshghi and Kargari [16] proposed a multi-criteria decision method, intuitionistic fuzzy set, and evidential reasoning of a transaction concerning the effects of uncertainty for them. Kargari and Eshghi [17] proposed a semi-supervised combined model based on clustering algorithms and association rule mining for detecting frauds and suspicious behaviors in banking transactions. Sarma, Alam, Saha, Alam, Alam, and Hossain [18] proposed a system to detect bank fraud using a community detection algorithm that identifies the patterns that can lead to fraud occurrences. Gyamfi and Abdulai [19] used supervised learning methods to support vector machines with spark (SVMS) to build models representing normal and abnormal customer behavior for detecting fraud in new transactions. Shaji and Panchal [20] used an adaptive neuro-fuzzy inference system for detecting fraudulent transactions. Susto, Terzi, Masiero, Pampuri, and Schirru [21] proposed a machine learning-based decision support system for fraud detection in online/mobile banking system. Sapozhnikova, Nikonov, Vulfin, Gayanova, Mironov, and Kurennov [22] employed three classifiers and developed an algorithm for analyzing the information about the user environment to monitor the transactions. Mubalaike and Adali [23] emphasized deep learning (DL) models to detect fraudulent transactions with high accuracy.

Above mentioned works do not mitigate fraudulent transactions using stolen login credentials and phishing apps in the mobile banking system. Our paper proposes a new anti-phishing model to mitigate fraudulent transactions in the mobile banking system in the world of mobile payment transactions. Banks and financial institutions can implement this model to mitigate phishing attacks in the mobile banking system.

3 Proposed Anti-phishing Model AntiPhiMBS-TRN

This paper proposes an anti-phishing model for mobile banking systems at the transaction level (AntiPhiMBS-TRN). AntiPhiMBS-TRN aims to mitigate phishing attacks in the mobile banking system for three categories of users. The first category is the users who download phishing apps mistakenly and provide login credentials in phishing apps. The second category is the users who visit the phishing login interface mistakenly and provide login credentials in the phishing login interface. Phishers steal login credentials from banking users using phishing apps or phishing login interfaces and exploit them to request fraudulent transactions. The third category is the users whose mobile devices are stolen by the phishers or lost somewhere unknownigly. When phishers get such stolen/lost mobile devices, they do not have to enter the login credentials to use the mobile banking system. Phishers request transactions using the stolen/lost mobile devices.

Fig. 2.
figure 2

Fraudulent transaction protection in the mobile banking system using AntiPhiMBS-TRN

Full size image

In all of the above cases, the mobile banking system sends OTP to the phishers for the security of the transactions. However, phishers reply to OTP using mobile devices as they have physical access to them and execute fraudulent transactions. Our proposed model AntiPhiMBS-TRN protects mobile banking users from phishers’ fraudulent transactions as shown in Fig. 2. We propose the architecture of the anti-phishing model AntiPhiMBS-TRN to describe the detailed working mechanism of AntiPhiMBS-TRN.

3.1 Architecture of Anti-phishing Model AntiPhiMBS-TRN

The architecture of the anti-phishing model AntiPhiMBS-TRN consists of the model for defending against phishing attacks in the mobile banking system at the transaction level. The participating agents in our proposed model AntiPhiMBS-TRN are mobile user, bank, bank application, mobile banking system, phishing application, and phisher.

We specify the following agents and initial conditions for working of AntiPhiMBS-TRN.

  • A mobile user (U) opens an account in the Bank (B) and provides an international mobile equipment identity number (imeiNo) of mobile devices for the Mobile Banking System (MBS).

  • Bank provides application id (appId), user id (uId), login password (lgnPwd), transaction password (trnPwd), and a unique id for transaction (unqIdTrn) to the user for transaction in MBS. Bank generates unqIdTrn once when a new bank account is opened. New unqIdTrn is not needed for each transaction.

  • Bank shares imeiNo, appId, uId, lgnPwd, trnPwd, unqIdTrn, and mobNo of each user with MBS.

  • Each of the banking applications is identified by an appId and know the relationship among uId, appId, imeiNo, and unqIdTrn for each user.

  • Bank and MBS know the relationship among uId, lgnPwd, trnPwd, appId, imeiNo, and unqIdTrn for each user.

  • Users download mobile banking app (BA), install, run and provide login credentials (Username and password) to log on to the mobile banking system.

  • Users always share the IMEI number of the mobile device with the MBS. MBS verifies the IMEI number of the mobile device during the transaction.

  • Users do not reveal the information provided by the bank to others.

Model for Preventing Fraudulent Transactions in the Mobile Banking System

We consider that banks provide training to mobile users about the detailed procedure to execute transactions using the mobile banking system. This paper presents the scenario of transactions in the mobile banking system using the mobile banking app and the scenario of fraudulent transactions.

Scenario of Transaction in the Mobile Banking System Using Mobile Banking App

All the participating agents (user, bank, bank app, and mobile banking system) of the model must follow the following steps to mitigate the phishing attacks at the transaction level.

  • Step 1. A mobile user (U) opens a bank account in the Bank (B) and provides an imeiNo as security parameters to the bank.

  • Step 2. Bank sends uId, lgnPwd, trnPwd, and a unqIdTrn to the user for transactions in the MBS.

  • Step 3. Bank sends appId, uId, lgnPwd, trnPwd, unqIdTrn, and mobile number (mobNo) of each user to the MBS.

  • Step 4. A mobile user downloads the app, logins and is authenticated in MBS, and requests for transactions.

  • Step 5. Bank app (BA) asks for a unique id for the transaction to the user.

  • Step 6. The user provides unqIdTrn to BA.

  • Step 7. BA sends uId, lgnPwd, and unqIdTrn to MBS and requests for the transaction.

  • Step 8. MBS asks BA for its appId.

  • Step 9. BA provides appId to MBS.

  • Step 10. MBS asks for a transaction password to the BA if the application id is the same as in the stored database of MBS for that user id.

  • Step 11. BA asks for the transaction password to the user.

  • Step 12. The user provides trnPwd to BA.

  • Step 13. BA sends trnPwd to the MBS.

  • Step 14. MBS verifies the transaction password and sends OTP to the user.

  • Step 15. The user replies with the OTP to the MBS. MBS verifies the OTP and IMEI number of the mobile device.

The scenario of transactions in the mobile banking system is shown in Fig. 3. Mobile banking users request transactions and the bank app asks the user to input the unique id for the transaction. The user inputs in the bank app of the mobile banking system.

Fig. 3.
figure 3

Scenario of transaction by using bank app

Full size image

The bank app already knows the login credentials (User id and password) as they are inputted by the users for authentication in the mobile banking system before requesting the transactions. The bank app sends the login credentials and unique id for the transaction to the MBS. MBS wants to verify the identity of the bank app and asks it to provide the application id. The bank app supplies the app id to MBS. MBS verifies the application id of the bank app within its database. If the application id is not valid, MBS knows that the app is a phishing app. If the application id is valid, then MBS asks the bank app to provide a transaction password. After that, the bank app asks the user to provide the transaction password. The user provides the transaction password to the bank app. The bank app provides the transaction password to the MBS. MBS verifies the two-factor authentication (login credentials and unique id for transactions). If both of them are correct, then MBS sends OTP to the user as third-factor authentication. The user replies with the OTP. MBS always detects the IMEI number of the transaction originating mobile devices. Finally, MBS verifies the OTP and the IMEI number of the mobile devices. If both the OTP reply and IMEI number of the mobile devices are valid, then MBS executes the transactions. Generally, the execution of the transaction depends on the two-factor authentication (login credentials and OTP) only. In AntiPhiMBS-TRN, the execution of the transaction depends on the multi-factor authentication (login credentials, unique id for transaction, OTP, and IMEI number of mobile devices).

Scenario of Fraudulent Transaction by Phisher

The fraudulent transactions can be executed in the mobile banking system using the following methods.

  • Fraudulent transaction using stolen login credentials and phishing apps

  • Fraudulent transaction using stolen/lost mobile devices.

Fraudulent Transaction Using Stolen Login Credentials and Phishing Apps

When the phishers request transactions using stolen login credentials, MBS detects the new mobile devices with the help of the registered IMEI number for that user. The bank app asks for a valid IMEI number of the registered mobile devices to the phisher as shown in Fig. 4. The phisher cannot provide the IMEI number of the old mobile device, and the new mobile device is not allowed for the fraudulent transaction. Generally, MBS does not notice the change of mobile devices for financial transactions. This paper uses an IMEI number of mobile devices in AntiPhiMBS-TRN for the security of change of mobile devices. If the phishers reply with the valid IMEI number anyway and request the transaction, the bank app asks for a unique id for the transaction and the phishers cannot provide a unique id for the transaction to the bank app.

Fig. 4.
figure 4

Scenario of fraudulent transaction using stolen login credentials

Full size image

If phishers use phishing apps (PA), phishing app requests a fraudulent transaction, the mobile banking system asks for an application id to the phishing app to identify the phishing apps. The phishing app provides a fake app id to the MBS. However, MBS detects the phishing app as a fake app that differs from the registered app id. Thus, the phishers cannot execute the fraudulent transaction using phishing apps.

Fraudulent Transaction Using Stolen/Lost Mobile Devices

Practically, mobile banking users input login credentials (username and password) in the mobile banking system only once, and they are saved on those mobile devices. They do not have to input first-factor authentication (Login credentials) each time when they request transactions. MBS uses OTP as the second-factor authentication for the security of the transactions. The phishers get stolen/lost mobile devices and request a fraudulent transaction using the mobile banking system running on those mobile devices as shown in Fig. 5. If AntiPhiMBS-TRN is not used, MBS asks for OTP only to the phishers and they can reply to OTP easily using the stolen/lost mobile devices and the fraudulent transactions can be successful. However, in AntiPhiMBS-TRN, the bank app asks for a unique id for a transaction for multifactor authentication. The phishers cannot provide a unique id for the transactions to the bank app, and fraudulent transactions are not executed using those stolen/lost mobile devices. The advantage of AntiPhiMBS-TRN is that phishers cannot execute fraudulent transactions using stolen login credentials and stolen/lost mobile devices.

Fig. 5.
figure 5

Scenario of fraudulent transaction using stolen/lost mobile devices

Full size image

3.2 Verification of Proposed Anti-phishing Model AntiPhiMBS-TRN

We develop a verification model of AntiPhiMBS-TRN by specifying system properties and safety properties using PROMELA. The verification model of AntiPhiMBS-TRN consists of the processes, message channels, and data types. The processes (mobileUser, bank, mobileBankingSystem, bankApp, phisher, and phishing app) in AntiPhiMBS-TRN communicate with each other using defined message channels. We specify the following temporal property using linear temporal logic (LTL) in the verification model of AntiPhiMBS-TRN.

[](((usrId==bankUsrId)&&(lgnPwd==bankLgnPwd)&&usrTrnPwd==bankTrn

Pwd)&&(usrUnqIdTrn==bankUnqIdTrn)&&(usrOTP==bankOTP))-><>(transactionSuccess==true))

The LTL property states that the transaction of the banking user in the mobile banking system will succeed if (i) the user id provided by the user and received by MBS from the bank is equal, (ii) the login password provided by the user and received by MBS from the bank is equal, (iii) the transaction password provided by the user and received by MBS from the bank is equal, (iv) the unique id for the transaction provided by the user and received by MBS from the bank is equal, and (v) OTP provided by the user and sent by MBS to the user is equal.

4 Results and Discussion

This paper verifies the safety properties and the LTL property of the proposed model AntiPhiMBS-TRN. We accomplished experiments using SPIN Version 6.4.9 running on a computer with the following specifications: Intel® Core(TM) i5-6500 CPU@3.20 GHz, RAM 16 GB, and windows10 64 bit. We ran SPIN to verify the safety properties of AntiPhiMBS-TRN for up to 50 users. SPIN checked the state space for deadlocks during the verification of safety properties. The SPIN verification results for safety properties are in Table 1.

Table 1. Verification results for safety properties
Full size table

Table 1 shows the results obtained from SPIN illustrating the elapsed time, total memory usage, states transitioned, states stored, depth reached, and verification status for safety properties for various users. The SPIN verification results show a continuous rise in the verification time, transitions, and depth with an increase in the number of users during the verification of AntiPhiMBS-TRN. Besides, the SPIN verification did not detect any deadlock or errors during the execution of the AntiPhiMBS-TRN model. After that, we executed SPIN in the same computing environment to verify the LTL property for up to 50 users. The SPIN verification result for LTL property is in Table 2.

Table 2. Verification results for LTL property
Full size table

SPIN checked the statespace for never claim and assertion violations in the run of LTL property. The SPIN verification results show a continuous rise in the verification time and depth with the increase in the banking users during the verification of LTL property. The SPIN verified the LTL property successfully. Moreover, the SPIN verification did not detect any deadlock or errors during the execution of the AntiPhiMBS-TRN model. SPIN did not generate any counterexample during these experiments, and we concluded that there is no error in the design of the AntiPhiMBS-TRN model.

5 Conclusion and Future Work

In this digital era, fraudulent transactions are escalating sharply with the rise in mobile banking transactions in banks and financial institutions. Phishers utilize phishing apps or phishing login interfaces to accumulate login credentials and employ them to perform fraudulent transactions within the mobile banking industry. Moreover, phishers exploit stolen/lost mobile banking users’ mobile devices to execute fraudulent transactions. Even though fraudulent transactions are ascending progressively, any anti-phishing model for fraudulent transactions has not been developed so far for the mobile banking system. Therefore, this paper developed a new anti-phishing for mobile banking system at the transaction level (AntiPhiMBS-TRN) to mitigate fraudulent transactions globally. Phishers exploit stolen login credentials for fraudulent transactions using a new mobile device. However, AntiPhiMBS-TRN detects the new mobile device and queries the IMEI number of the old mobile device to execute the transaction. The phishers cannot deliver an IMEI number, a unique id for the transactions and cannot succeed in the fraudulent transactions in the mobile banking system. The phishing apps cannot provide a valid application id to the mobile banking system, and phishers fail to execute the fraudulent transactions in the mobile banking system using phishing apps. Phishers get stolen/lost mobile devices and request transactions using mobile banking systems installed in those devices. However, AntiPhiMBS-TRN employs a unique id for the transaction system, and phishers cannot provide a unique id for transactions. Hence, phishers fail to execute the fraudulent transactions using stolen/lost mobile devices.

We observed from our experimental SPIN results of the PROMELA model of the AntiPhiMBS-TRN program that the AntiPhiMBS-TRN does not include any deadlocks or errors within the model. Moreover, SPIN verified safety properties and LTL property within the PROMELA model of AntiPhiMBS-TRN. Hence, banks and financial institutions can implement this verified AntiPhiMBS-TRN model to mitigate the ongoing fraudulent transactions and increase the mobile banking users to transform into a cashless society in this digital era of digital banking. In future research, we will propose a new secured model to detect the change of locations and mitigate other probable attacks such as man in the middle (MITM) attack, SQL injection attack, man in the browser (MITB) attack, replay attack in the mobile banking system.