Robo-advisory

Goal Based Robo Advisory for Edelweiss.

Client is one of the India’s leading diversified financial services company providing a broad range of financial products and services to a wide client base. Its products and services span across multiple asset classes and consumer segments across domestic and global geographies. Client provides services in equity market, commodity market, mutual funds, loans, life insurance and so on. 

Business Problem.

The existing system would allow investors to invest in mutual funds of their choice which sometimes resulted in potential risk. This system did not gain attention of newbie investors who had little or no knowledge of which mutual fund to invest in. This led to following problems:

  1. Attracting potential investors
  2. Load on help desk or customer care services to guide huge number of potential investors
  3. Delays in investment which is not feasible in live fund trading.
  4. Further growth of the business and customer satisfaction.

With the new potential investors, it was necessary to give them a tool by which they can understand the potential growth based on their own preferences. Robo-advisory was the ideal way to guide and attract such investors.

Solution.

A set of APIs were defined and developed aligning to different functional requirements. These APIs were then consumed by Front end to process the information. Information processing required linking GPS to couple of third party systems which are connected to Exchange. The data would be fetched from these intermediate systems at a fixed time of day through Scheduled jobs implemented by developers of GPS system.

A detailed understanding of working of each and every API was provided to the client’s team. This team then consumed the APIs on the front end developed by them.

System architecture Diagram

 

 

Challenges.

Listed below are the key challenges faced:

  1. Changing requirements: The fields in the input and outputs of some of the APIs were changed continuously which required developer to rework on them.
  2. Validating multiple conditions in one single API: Requirements required to iterate through 300+ complex, lengthy and inter-related conditions before the results are displayed.
  3. Maintaining performance: The system developed being for a live trading required faster responses. Traversing through complex functionality with timely responses was a big challenge.
  4. Redis hosted on multiple servers: The live Redis was supposed to be connected with multiple servers. This required dynamic allocation of servers at runtime based on availability.
  5. Rebalancing as a new feature: Rebalancing being a new feature, even to Client, led to frequent inputs/changes at each module developed.
  6. Knowledge of Third party databases: GPS has to post and get data from multiple third party databases. The fields, tables, stored procedures, databases, etc. to be referred differed with different functionality. At times, the data was fetched from different servers which had different login credentials to be used. Above all, the third party databases were using MS SQL. This required developers to be very cautious while coding.
  7. Continuous parallel development of Third party APIs: Even while the API development was undergoing, the STORED PROCEDUREs on third party’s MS-SQL server were being updated to reflect business requirements. This led to rework as API results were based on them.
  8. Implementing XIRR: XIRR, an excel function to calculate Internal Rate of Return (IRR), was initially implemented using the available DLL. But this DLL created performance issues when the number of records went high.
  9. Choosing authentication mechanism: Choosing a feasible authentication mechanism in such a risky environment wherein investor’s crucial information may be revealed.
  10. Absence of front end: Absence of front end in the initial stages of development made unit testing bit difficult. To overcome this, a set of basic HTML pages corresponding to each API were developed. This helped developers to validate the inputs and verify the outputs.
  11. No tester involved from client side: There was not a single potential tester involved from Client side till the front end was completely ready. This resulted in rework or updates the functionality at almost the last stage of development.
  12. Front end design team location: The front end team being located in other city, sometimes led to confusions. As an instance, they utilized first API instead of second.

Value Delivered

Following were the key benefits for the client:

  1. Complex functionality with excellent performance: Used standardized coding methods to improve performance wherever required.
  2. Switch Redis servers at runtime: Implemented functionality that can dynamically choose between the available Redis servers, for processing.
  3. Maintain up-to-date information: A number of schedulers were implemented that would fetch data from third party databases on a scheduled time to track the current status of orders and maintain the same in GPS databases.
  4. Performance maintenance: At times, where the DLL proved to be infeasible, DLL reference was removed and a function resembling it was developed from scratch to improve performance.
  5. JWT authentication: Used JWT (JSON Web Token) authentication mechanism which is one of the compact and self-contained way for securely transmitting information between parties as a JSON format.
  6. Simple, ready to use APIs: GPS incorporates simple to understand and easy to use APIs. This results in increased usability wherever required by the technical team of Client.

APIs have a lot of advantages mainly because of its reusability. APIs are web services that once created can be used on multiple applications, multiple platforms and so on. The same set of APIs can be integrated with multiple mobile applications at the same time. Making data available via API can support faster and easier data migration, code updates and improved data quality review and clean-up.

  1. Different execution paths for different accounts: Different types of accounts like Physical and Demat undergo different order processing paths. The determination of type of account was known somewhere between the order execution.
  1. Rebalancing feature: Rebalancing feature monitors investor’s portfolio for any risks to arrive and suggests solutions to avoid them. This improved investor faith in client.
  2. Adds to Client’s vision: GPS is considered as a major initiative to achieve Client’s vision of democratizing their participation in financial markets.
Contact Us
close slider
Address (INDIA)

Merce Technologies Pvt Ltd
301 Technocity
X-5/3 TTC Industrial Area
MIDC Mahape, Navi Mumbai 400710

:+91 22 27781895/96
:info@merce.co

Address (USA)

Merce Technologies Pvt Ltd
1819 S Pearl St
Denver, CO 80210

:+1 720-643-2019
:biz.usa@merce.co