WalletPAOne complex solution for a complete wallet management.
- Scope Product workshops, backend, frontend
- Timeframes February 2021 – till now
- Technologies Node.js, NestJS, Azure, TypeScript, Open Banking Protocol
- Business sector Fintech
- Model of collaboration Time & Material
- iteo Team 1 PM
1 UX designer
6 backend developers
2 frontend developers
PoC working phase
After starting the work on PoC we have been adding new logic and features each month, till now.
Right now, we are starting the analysis related to two brand new modules that will be introduced soon – monitoring of the chosen transaction groups, as well as alerting users about anything suspicious, like differences in the transactions, or delays.
Business needs & goals
Our Client came up with the idea once he noticed that none of the banks nor other financial applications offer grouping transactions in a convenient and intuitive way.
On this basis, he started to think about a highly comprehensive solution when it comes to monitoring and managing his wallet.
The project workshops involved investigating the idea and its possibilities in the context of the whole application.
We have discussed the views, features, and integrations with an external API.
Due to the size of the application and many uncertainties, we decided to develop a Proof of Concept, to take care of the major ones.
We have been brainstorming for a few months, validating and implementing the ideas in order to reach the point when the whole scope of the PoC is fully recognized.
Proof of Concept
The scope of the proof of concept contained:
Fetching user’s bank transactions through the use of Plaid API (with the Open Banking protocol under the hood)
Displaying them in our tool
Grouping them based on predefined settings:
– minimum confidence level for similarity
– recursion tolerance window
– other factors that help create/reject a group of transactions
Aggregation of groups and splitting them in two types, based on their reliability
Discussion and further actions in the context of monitoring and alerting transaction groups chosen by the users (with their setup)
Both the backend API and the frontend web application are hosted on the Azure infrastructure.
To access bank transactions, the application uses a third-party API by Plaid. It allows us to pull transactions from various banks in the UK (and possibly in multiple other countries), using one common API. Plaid is transparent to the user and makes all operations on financial data secure by using the Open Banking protocol.
System is connected to the OBP via the Plaid API.
Then, it gathers the transactions from the linked account, creates groups (based on the implemented logic), and aggregates them into two “master groups” – perfect groups (no flaws) and imperfect groups (some flaws).
Challenges & solutions
The grouping process starts from pulling bank transactions from a user’s bank account.
They are then grouped based on specific criteria and conditions where the main ones are the similarity of transaction descriptions and the regularity the transactions occur with.
The groups are two-fold.
A ‘perfect group’ contains a sequence of transactions with a monthly recurrence period, with no gaps in the sequence (no missing transactions). An ‘imperfect group’ on the hand, is a sequence of transactions with no gaps or more than one transaction per month. The rest are considered non-recurring transactions.
Proof of concept type of the system, showing connection to the OBP, gathering the transactions and creating appropriate groups.