## 3 Proposed Solution  
Overall, our proposed solution comprises three main components that need to communicate with each other, as shown in Figure 1, which depicts the high-level architecture of our proposed solution. According to Figure 1, the 1 st entity represents the ATM, and the 2 nd entity presents the existing banking infrastructure. The 3 rd entity represents the mobile-based authenticator app, which acts as the main enabler of our solution. To provide a clear picture of the existing ATM process, Figure 2 depicts the workflow of an existing ATM process, which is based on a PIN for authentication. Accordingly, it only requires a user to enter a PIN to authenticate the transaction. Figure 1: High-level architecture of our proposed solution. In our proposed multi-factor authentication solution, the authenticator app would be able to authenticate any ATM transactions and keep track of them as well. Moreover, our proposed solution offers a control panel that provides administrator privileges to the users for disabling the multi-factor authentication, setting up a withdrawal limit, and blocking the card in case it is stolen. Further, it also includes a Rest API, whose main purpose is to enable better integration with existing banking systems without making any major modifications. As seen in Figure 3, our approach does not involve any modifications to the already-in-place ATM infrastructure, but it will authenticate users in a very precise manner. When a user completes a transaction by utilizing our authentication schema, the user will have a greater understanding of what occurs in the background than they have in the present environment, which is blind. Overall, our user authenticator system does not require a lot of information other than the user's unique identifier (PIN) in order to approve a transaction. Instead, it will connect with a smart mobile-based authentication app and cross-check the user's location. Figure 3 showcases the high-level workflow of our solution. Figure 3: The high-level workflow of our ATM solution. Figure 2: The workflow of the existing ATM process. According to the workflow of the solution, when a customer requests a transaction at an ATM, the request will initially reach the bank with ATMID and CARDNO parameters. The bank then processes the request, and it will send an authentication request to the authentication API to authenticate the customer with the parameters BankID and BankAPIKEY. Then, the authentication API, through the authenticator app, authenticates the user's location, matches it with the ATM location, and accordingly approves or denies the transaction. Overall, the authentication measures can be explained as follows, and according to the overall workflow, this proposed approach does not require any modifications to the already-in-place ATM infrastructure, but it will authenticate users in a very precise manner based on the geolocation. Compared to the existing workflow, which is depicted in Figure 2, instead of dispensing cash once the PIN is correct, our approach further checks whether the user has their mobile device in their possession and, if so, determines the GPS location of the device, to provide better security for ATM payments. **Step 1:** The user makes a transaction request (ATMID, CARDNO) at the ATM. **Step 2:** The bank receives the transaction request and fetches BankID and APIKEY. **Step 3:** The bank sends an authentication request (Input ATMID, CARDNO, APIKEY) to an authenticator API. **Step 4:** The authentication API fetches data from user's authenticator mobile app. **Step 5:** IF Authenticated? Then \begin{tabular}{l} IF Request amount \(<\) withdrawal limit Then \\ Go to Step 6. \\ Else \\ Go to step 7. \\ Else \\ Go to Step 7. \\ \end{tabular}   
**Step 6:** Approve the transaction. **Step 7:** Deny the transaction.