The problem uniBroker solves

This project aims to unify the trading API interfaces of all the major Indian brokers to form one standard library that can execute trades, monitor positions, and other data like holdings, available margins, etc. on all your brokerages at once. Thus acting as a broker of brokers of sorts.

Most professional traders and automated trading systems use multiple(two or more) brokers to execute and manage their trades, positions, and portfolios. Some use a full-service broker for specific trades and discount ones for other trades. This creates a mess of APIs, web apps, logins, 2FA keys, and more.

Moreover, there have been many instances where an o-Auth session expires or the broker's servers go down temporarily.

This is a real issue with real consequences on trading performance. What if your algorithmic trading system sends a signal and the API of your broker requires you to login again or just simply fails to work. Or if you are trading manually, the time cost of switching brokers on the fly can mean the difference between a profitable or unprofitable trade.

uniBroker solves this by using the broker's own web-app API endpoints instead of their provided free/paid API solutions. This allows automation of o-Auth/2fa and login flow and allows it to interface with the brokers with no readily available public API.

v0.20 will have automatic fail-over support where you can select one preferred broker and other secondary brokers. The library will automatically switch brokers for you in case your primary broker goes down.

The current iteration of this project (v0.15) supports two brokers (upstox and Zerodha) with support for six more brokers coming this summer.

All of this is and will always be open source and hence free of charge where anyone can look into the source code to verify that nothing shady is going on.

It's time Indian traders get a streamlined multi-broker experience like the hedge funds do!

Challenges I ran into

Technical challenges ->

• Figuring out 2FA login flow and API endpoints of different brokers -> there are a lot of moving pieces when you login with your favorite broker. Figuring those out is a herculean task which needed a lot of patience just doing it for 2 brokerages. I used burpsuite to intercept http requests and codified them into my GO library.
• Figuring out how to make executing orders concurrent without overloading the brokerage servers -> One of my goals with this library was to make the execution of orders concurrent ie. execute all the orders on the orders-list at once and not sequentially. What made GOlang the prime candidate for this project is its strong concurrency support which helped me implement worker-pools pretty easily to let the users vary how many concurrent orders to process at a time.
• Convert it into a live server and add a UI layer -> Currently you can only execute trades by feeding your trades into a JSON file that the library parses and then executes concurrently. But I have live server support planned for the future versions of this library. The UI layer will make this library accessible to non technical folks (mockup of the UI-Layer are provided in the assets section). The UI-layer is heavily inspired by Zerodha's Kite platform.
• General software architecture and code prettiness -> The current iteration of uniBroker is pretty hacky to say the least. I plan on refactoring the code to make it more modular and easier to contribute to.

Regulatory challenges ->

• Where does this project lie in the regulatory spectrum -> The stance of SEBI on open source libraries and tools which extend the functiontionality of brokerages to aid traders is unclear. I would love to know about it by the jury panelists.