project-proposal-2025

BANKRR

Abstract

Trying to save for your next holiday? Eyeing a new car? Or just looking to just get on top of your finances? Managing your money can sometimes feel overwhelming and time-consuming, but what if it wasn’t. What if saving for that new purchase could be as simple as a few taps.

Introducing BANKRR, a cloud based financial tracking platform, designed to put you in control of your money. BANKRR eliminates the hassle of juggling multiple bank accounts by consolidating your expenses into one clear, birds-eye view—helping you track, plan, and spend smarter. BANKRR will also provide recommendations depending on the users’ financial goals. Spend Smarter, live more with BANKRR.

image

Author

Name: Tze Kheng Goh

Student number: 47037542

Functionality

Overview

BANKRR is a simplistic approach to building insightful financial charts. The general premise is that users are able to track their spending and identify ways for them to reach their short and long term financial goals.

To start using BANKRR, users begin by registering an account. In the signup phase, we collect essential details such as email, phone number, name, date of birth, and address for verification. Users will also fill out a questionnaire about financial profile and goals. The rest of the functionality doc will assume that user has completed these details.

An example of a process flow from user login can be seen below: image

In the beginning, the user will:

  1. Log into the website with their username/email and password. MFA will also be needed as it is a financial app.
  2. From here if financial goals have already been defined, user can choose to skip or add more goals/information from their given financial situation.
  3. The user can choose where the information gets source from. They can:
    • Securely link their bank accounts (requiring third-party authentication from their respective banks) or upload their bank statements. For this option to be available, users must authenticate their phone number and submit a legal photo identification, to consolidate verification processes.
    • Manually input financial data like expenses to estimate income, expenses, and savings.
  4. The user can then also choose to link payment options like apple pay. This is so real-time transaction data will show up in the data, ensuring that charts are up to date with user’s spending habits.
  5. From all the information gathered, the application can use automated financial analysis tools software APIs like Xero or its own virtual environment AI to generate financial charts and report back to the user. Use of AI to looks at user profile and goals and provide an insights on how user is tracking. Information should be downloadable in pdf format if user requires it.

For security and privacy, BANKRR can only access up to one month of past transactions, ensuring data privacy. After signing up for this application, user’s next login will be done through multi-factor authentication.

View of numerous different project flows:
Login -> Skipped defining goals (No change) -> Information already provided (source and additional source) -> Output. Login -> Define new goals -> Information already provided (source and additional source) -> Output. Login -> Skipped defining goals -> Authenticate access for apple pay -> Review data -> Output. Login -> Manage profile.

Scope

The scope for the MVP of this system include the features:

Quality Attributes

Reliability

Reliability will be crucial for BANKRR system as it collects, stores and generates fiscal reports from user’s sensitive financial data. To provide accurate and reliable insights into user’s spending trends, the system must ensure that analysis is conducted using correct data for each individual. If unable to do so, it could result in misleading insights, potentially causing users to make poor financial decisions that hinder their ability to reach their financial goals and impact their overall financial wellbeing.

Reliability of this system can be done through live testing. Mocking up different financial data and user spending habits and ensure that specific habits are identified in the results.

Security

Security is software that maintains normal operation when subjected to attacks. This attribute is extremely important to BANKRR as it prevents unauthorised access or malicious attacks. As BANKRR uses extremely sensitive user data, both data in transit and data at rest must also be heavily encrypted and highly secure.

Testing the security of the application can be done through penetration testing, packet sniffing (Wireshark), vulnerability scanning, logging and database encryption. These are measurable by simulating different login requests (some valid and some invalid) to ensure that intended behaviour occur with each authentication system occur for each case. Using vulnerability scanning along this can also identify any vulnerabilities within the application. Logging can be used to pinpoint where unauthorised access occurs and looking at the percentage of data, both in transit and at rest, that is encrypted within the application.

Interoperability

Interoperability attribute is important to BANKRR because it will need to be able to communicate both internally (with components) and externally (APIs) for sourcing, passing and receiving information. As spending habits of users can be irregular, being able to process new information, storing it and sending it out to external APIs securely and quickly will be key in providing up-to-date analysis on user spending trends.

Interoperability can be tested by scheduling irregular spending patterns to ensure that data is being passed correctly within the system. Upon receiving output from the external API, an audit can be done to ensure that the new spending habits are accounted for. Logging can also be used to identify vulnerabilities in terms of communication from the different APIs.

Extensibility

Extensibility attribute is important to BANKRR as users have diverse ways of budgeting and different views/interests on their financial performance. Being able to add methods for seamless migration from existing user budgeting tool will provide a more user-friendly transition. Users may also like to see additional financial insights, which can be done through incorporating customised analytics towards specific individuals goals.

Extensibility can be tested in isolated environments for different plugs-in for sourcing data and the customisable templates. These techniques for sourcing data can be automated, while customisable templates will require both manual and automatic checks. The evaluation of extensibility will depend on how well-defined and easy it will be to customise different plug-ins depending on the architecture and interface.

Evaluation

Reliability

To evaluate the reliability of the system a simple test with a small load (1-3 users) adding data and providing general financial insights is conducted correctly. A second evaluation can be done by adding more con-current (10-20) users where sourcing individuals’ data and generating financial reports happens irregularly and simultaneously.

Security

Evaluation of this can be applied on different parts of the system such as the login screen, database security and the information in transit. Malicious requests sent to login screen, attempting to gain unthorised access to database information and attemtping to decrypt information in transit can be tested. Number of passed/failed tests can be tracked by using a logger to evaluate how secure the application is.

Interoperability

For interoperability, a small load (1-2 users) test for internal communication within different components. The architecture should allow for seamless communication with internal components of the system. Another small load test will be generated for communication with external APIs. This is to ensure that our application can also send and receive information from external services.

Extensibility

For this approach, it will take a less quantitative approach as it heavily depends on the architecture, components, interfaces and attributes. Architecture should accommodate for different services in the front end and be flexible enough to provide customisability for the user. Components should be able to function independently for their own purpose.