Let's talk!


One 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

WalletPA is a single, complex solution for complete wallet and personal finances management. It enables controlling groups of transactions, comparing services (internet providers, water suppliers, energies companies, etc.), swapping to better offers, and much more.


  • 2021

    Product workshops


    PoC working phase

  • 2022


  • Project’s highlights

    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.

    Product Workshops

    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)


    Tech Stack

    The solution was written in TypeScript, a modern version of JavaScript. We used React for frontend and Node.js with the popular NestJS framework for backend.


    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.