The problem AAmaze solves

The objective of this exercise is to build an application to deliver a solution that will help users track expenses in various categories utilizing visualization.
The proposed solution is an expense manager/ wealth mobile application being developed with millennials as users in mind. The application will ingest the data fetched from the Account Aggregators which reside at FIU’s servers (Pirimid with Bank of Baroda in this case). The entire flow of data is managed with the user's consent and in real life, the user will have the ability to pause or revoke the consent for sharing the data at any point in time. As we did not have availability to the APIs to pause/ revoke the consent, we have not implemented this journey with the submitted solution. Here, the visual layer will ingest the analyzed data received from APIs shared by the bank.
Please note - no further categories are getting created as we do not want to build an additional analytics layer on top of analyzed data leading to an increase in TAT and having users end up with confusion. We did find inconsistencies in transactions getting tagged in the wrong categories but have not restructured or corrected them on purpose.
The mobile App will have 4 main modules:
A home or landing screen to add/ remove linked bank accounts (AA journey)
A money manager tab will have expenses and income screens showing transaction categorization as they're categorized by the processing engine
A user portfolio screen showing the user’s holdings in Equities, Mutual Funds, NPS, PPF, insurance, and cash in the bank
User Profile screens from where the product-related details and information will be shown to the users

Challenges we ran into

Inconsistencies in the data were observed which is mentioned in the Assumptions and Limitations section
We found missing transactions resulting in an incorrect calculator of the average balance, average debit, and credit amount at different time intervals
As one mobile number giving analyzed data for multiple FIP accounts was observed to be for multiple users as well. This made it difficult to build user profiles as per the defined personas
APIs giving analytics output were available intermittently which led to slow unit testing
Fetching data for users with mobile number 9987600007 was a tough job as it was not showing accurate results. Later was found an additional OTP (123456) was to be given for the PPF data for this user to fetch from the given APIs
We observed that the data was altered without prior notification to us. This led to confusion on the accuracy of the previously passed test cases of newly created variables
Evaluating the technologies to use was a major challenge to make this scalable and adaptable to the upcoming technologies. While we’ve shared the solution as an APK, the same solution can be deployed as an SDK with visuals for native as well as hybrid apps with no loss in functionality
As the solution was to be developed for both android, and iOS users, we avoided going with a pure android approach and hence did not use Material 3 themes which could have added more scalability and adaptability to the solution