Project Description
In this project, a group of students and I were in charge of creating an API to rebalance portfolios contained by a mock system created by HSBC.
We went through the whole development process, from doing the documentation to finally deploying our project. Rebalancing is important because portfolios
are made up of x number of different funds, say 2. With time these funds can gain interest, changing the percentage that each fund initially made up of the total
portfolio. When this happens there needs to be a set of transactions performed on that particular portfolio to bring the allocation back to the pre-established allocation.
Here is an example to illustrate. Important to note our UI is simply to showcase the backend functionality, hence its relatively simple and easy to use. Login page authentication
was designed to work as long as the customer ID exists in the mock system, so it follows a relatively simple validation.
In this illustration you can see how the portfolio allocations change with time. So after 1 year or 2 years the portfolio is out of balance. So our algorithm, through the API, would make
the required transactions to bring the portfolio back to the pre-determined allocation. These allocation can be modified at any time as you can see in the continuing image. Not does it follow
these allocation preference but you can also establish a "margin of error" which we call deviation. This deviation is the percentage that the client is willing to take as error above or below
the original established allocation. Here you can see our UI for selecting the allocation and the deviation.
We used Spring Boot to create the calls to a mock system provided by HSBC which contained mock data for clients and their portfolios. The goal was to create an API which would rebalance these portfolios.
The rebalancing consisted of having customers perform a set of transactions to have an initial portfolio. A customer could technically contain no portfolio initially. Once
a portfolio was created, a customer would select their prefered allocation. How this works is we would call the endpoints in their mock system, containing the customer id in the header. We understand this does not
follow standard security procedures but for the scope of the project this was acceptable. @GetMapping("/portfolio/{id}") was the endpoint to get portfolio information for every client. We did test cases on every endpoint, for example:
Here are all the requirements that our API meets.
Now the best part, the algorithm. We found various methods to perform the rebalancing. We had
3 different strategies for rebalancing. 1. Buy and Sell. This would mean that when a portfolio is unbalanced, we buy some of the fund that is
under allocated and sell some of the fund that is over allocated. 2. Just buy to balance. This would imply the client to add money to their portfolio
and buy enough of the fund that is under allocated to bring the distribution back withing the threshold. 3. Just sell to balance. This would imply retracting
some funds through selling of the fund that is over allocated such that the allocation goes back to normal. We opted to operate only with 1 for the scope of the project.
Our algorithm provides recommendations based on this allocation method. The following UI images reflect first, how a client can visualize both its portfolio and if its unbalanced
any recommendations provided. Next, in more detail, how the user can see its own portfolio information, and then how
our system performs recommendations for a given portfolio.
As you can see, the recomendation is not for the portfolio displayed in the first picture. These images
are just for the purpose of showcasing how the UI looked. Moving on we have our Use-Case Diagram. It showcases the major user flow through our
system and the different cases we had to test for.
The following illustrates our deployment infrastructure for GCP.
Another very sweet part of our project was being able to set up a pipeline. We used Gitlabs CI Pipeline by doing a
.gitlab-ci.yml file containing a script to run our tests. We used gradle as our building tool. I was lucky enough to act as Project Manager for this project
as I learned a lot about documenting work and also about building and maintaining a project, something I would not have been able to do without the help of my peers, TA, and professor.
Also want to thank HSBC and Google for taking the time and providing us with advice to guide us in building the project. Here you can see our pipeline in production.
