Home - mwhicks-dev/py-tradekit GitHub Wiki

This cornerstone library is a fundamental part of a larger trading platform meant for secure, version-controlled development of trading resources. I decided to create my trading platform as a result of this late 2023 Reddit post:

In particular, a response to this question from u/wsc-porn-acct -- whose username I am hoping stands for "Wall Street Concepts" -- reads:

In my opinion, the good tools are the ones that:

  1. don't require you to share your strategy (code or configuration is stored on your local machine)
  2. there is a practice or demo environment that mimics production, especially with realtime data, but historical "realtime" is ok
  3. the exact same tool is used in demo and production, messaging your demo and live results should be the same

The only thing I've really found like this is on TradeStation, but you have to use their Easy Language.

Tradingview tries, but it isn't quite there. But I don't frankly know too much about it firsthand.

Every other platform I've seen you write your own code and stream data to your server and send orders from your program. TDA doesn't have a demo environment so that is a DEALBREAKER. IBKR does, but their setup is a little wonky, doesn't natively support full automation. TradeStation also allows rolling your own.

After doing some further reading, asking my partner who is in finance, and consulting my close friend ChatGPT which provided me the following three resources, I felt like I was in a good spot to begin work on this core library. The business rules, so to speak.

I have identified the following three major components necessary for any algorithmic trading application, which will be implemented (abstractly) within this library, and implemented in the larger overarching service.

  1. The market data provider. Any useful algorithm will require some way to obtain historical stock data, real-time stock values, or both. I plan to provide interfaces, schemas, and entities that represent both of these. While the real-time market data should in practice be an external service, like Yahoo! Finance or something like that, historical data can be passed manually from some user who has been collecting it. However, this interface will be strictly defined as an external service hook, something that reads out data. That (or other) data is to be fed to the next component.
  2. The actual trading model. This component is strictly responsible for, at any given time, providing a list of trade signals. The details -- what stocks to observe, what indicators it uses, and how the model calculates those indicators and its output signals -- is left to implementation. An implementation of this interface will represent the implementation of the trading strategy, and nothing more. Once again, these signals will be passed to the following component. Hold indicators will not be returned, as they are not executed in a meaningful way.
  3. The web broker. While the trading model is responsible for generating trade signals, this component is responsible for executing the orders they represent. While the other two component skeletons will be interfaces, this one will be an abstraction containing a priority queue of trade signals organized by time, as well as abstract methods necessary for broker operation. Overlying software in the greater platform will be responsible for monitoring investment value, performance metrics, and so on. The broker will be asynchronous.

This tool will be utilized by a layer sitting above it, which will be responsible for the following:

  • Synthesizing the runtime of the data provider, model, and broker, either in a deployed form or in the form of model testing.
  • Tracking traded equities, investment values, and performance metrics.
  • Threaded flows of control for different portions of the application.

Another smaller layer which only uses a data provider will also be created. This layer is available for real-time market data mining.

With this, we satisfy two of our main three stipulations: A practice environment can (and will) be made available as an implementation of the broker that does not actually execute any trade signals, but responds to and is treated by the overarching system as if it does. This allows for the transition from the demo to the production environment to be trivial as it will only require switching out a broker component, something the higher layers are designed to support.

At a higher (and fairly later) level, I plan to create a version control system that is available for the development of trading strategies at the individual component level. The web service will refer to this system at the deployment level, allowing for users to select and interchange their components with others. Although this may appear to violate the need not to require sharing your strategy, I plan to be very deliberate about this sensitive information, ensuring that all resources are encrypted before they are stored in their repository. Although it doesn't really matter, I don't want peoples' trading algorithms - my interest lies more in creating the platform. However, that is what the finished product will look like. Very robust asymmetric key protocols.