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.
Name: Tze Kheng Goh
Student number: 47037542
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:
In the beginning, the user will:
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.
The scope for the MVP of this system include the features:
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 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 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 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.
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.
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.
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.
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.