Looking for an experienced developer to help build a modular trading tool

I would just say that it all depends on how high of frequency data you are going to be using.

If the model can work with minute bars it is much different than if the model needs order book data. The scale of the time series data problem is night and day. If what you are doing is on the scale of KdB then just forget about it. You will have to build a team just to handle the data. Minute bars though are nothing, you don't even really need a time series database.

Whatever the up front cost is the maintenance cost will be just as expensive. Software and software engineers are mostly shit. The software will need constant maintenance because you are solving a unique and changing problem with what amounts to hacks.

First though your data solution has to actually be cost effective or you have nothing. If it is just barely cost effective it will be crushing as the system scales up. The data solution is not just the cost of the data, it is the handling/munging/error checking/etc that will be basically a full time job at some level of high frequency.
 
I would just say that it all depends on how high of frequency data you are going to be using.

If the model can work with minute bars it is much different than if the model needs order book data. The scale of the time series data problem is night and day. If what you are doing is on the scale of KdB then just forget about it. You will have to build a team just to handle the data. Minute bars though are nothing, you don't even really need a time series database.

Whatever the up front cost is the maintenance cost will be just as expensive. Software and software engineers are mostly shit. The software will need constant maintenance because you are solving a unique and changing problem with what amounts to hacks.

First though your data solution has to actually be cost effective or you have nothing. If it is just barely cost effective it will be crushing as the system scales up. The data solution is not just the cost of the data, it is the handling/munging/error checking/etc that will be basically a full time job at some level of high frequency.
I would beg to differ slightly here.
The biggest issue I had was cutting down slippage and therefore latency.
TSDBs are also available open source and free which isn´t that costly provided that you have a decent programmer and you don´t use arcane languages like Golang or Haskell

However, and this is the lesson everyone will learn the hard way sooner or later, once you start legging one side passively, you are in HFT territory, period.
Everyone is watching the same prices, leaning on the same orders and fighting over queue position at the same prices. And the faster you are, the longer you can leave your order in the queue. The slower you are the larger the deviation of your actual fill price from your theoretical.

So the timeframe doesn´t really matter, but the size of your edge does. When you average 0,5% or 50bps per trade and you repeatedly get slipped for 1-2 ticks you wave good bye to almost half of your profits. And honestly, even lower frequency traders (one trade per day) would kill for 50bps average.
 
Thanks for the advice- but I'm still interested in connecting with any developers who think they have the expertise... if they don't exist here so be it.

MrMuppet: I'm well aware of what you are saying, you are clearly knowledgeable and correct on most of these points, although some of your assumptions are not completely relevant or accurate for my needs, but you have identified a lot of the complexities.

I've been a senior trader a top tier Prop Firm for over a decade (one that everyone here is familiar with) helping to design tech/strategies for arbs and implementing them. I have probably spent more hours going through logs and working with developers than 99% percent of people here- but I wouldn't trust myself to build anything. I'm an arb trader/strategist- not a coder (in fact I've never backtested a single thing).

For the record, I never said how much I manage- I said I would have to trust the tool to manage millions in live quotes, but in retrospect this was not relevant.

Perhaps I misled my intention with my C++ comments- I am NOT trying to build some sort of latency-sensitive system, that I not my goal. I currently trade in a high-touch manner, but in a very specific way that I'm looking to automate in a manner that's very common at most ETF arb shops. My opportunities often last multiple seconds- so frankly any programming language would do- I figured one I'm paying to build something why not make it a good as possible for fast markets. But if that would make the price increase dramatically, python would be totally fine. Perhaps that's a takeaway here.

I get that there would a high chance for a messy/unusable tool- and it's not my first rodeo going down this hole, however I just wanted to see if there are any qualified developers I could find in this forum.. if not, so be it.

I also refuse to subscribe to this rule: "Either learn to code or buy off the shelf" - There are a lot more options that. For example another option I'm considering is to go in house to a prop house for 40% (and retain my IP)... but I don't really need their capital (I'm close to capacity for my higher sharpe stuff), so I basically be implicitly 'paying' them 60% for a good tech-stack... hence my reason to see if I could instead build something good enough.

If anyone has any other thoughts or ideas I'd been keen to hear them (besides do it yourself).
 
I would beg to differ slightly here.
The biggest issue I had was cutting down slippage and therefore latency.
TSDBs are also available open source and free which isn´t that costly provided that you have a decent programmer and you don´t use arcane languages like Golang or Haskell

However, and this is the lesson everyone will learn the hard way sooner or later, once you start legging one side passively, you are in HFT territory, period.
Everyone is watching the same prices, leaning on the same orders and fighting over queue position at the same prices. And the faster you are, the longer you can leave your order in the queue. The slower you are the larger the deviation of your actual fill price from your theoretical.

So the timeframe doesn´t really matter, but the size of your edge does. When you average 0,5% or 50bps per trade and you repeatedly get slipped for 1-2 ticks you wave good bye to almost half of your profits. And honestly, even lower frequency traders (one trade per day) would kill for 50bps average.

You are totally correct here, with respect to the HFT stuff- that's definitely the realm I live in- competing against the faster boys requires the need to be a bit savvy and only 'quote' or take when proper signals align, and there's a higher % of making the hedge.

I'm generally targeting <7 bps range of edge, and yes many trades will end up 3 or scratch, occasional lossers (and can't let these deltas run). But as long as you get enough flow on exchange you run a profitable, high-sharpe biz.
 
I'm looking to hire someone to build a robust market-making tool:

I have more granular schematics but as a general overview the tool will have the following capabilities:

-Generate theoretical bid/ask values for 'product A' based on a ratio+offset to 'product b' *Ability to be used for various sets of products simulatenously simply by swapping products and ratios.
-Needs to work for both futures and equity markets
-Once a theoretical value is generated, should have the ability to build modular strategies to send orders- MM (quote, dime, multi-levels) / Market Take
-Needs to generate hedging orders based on 'product b' or using designated hedges
-Needs to be robust... completed tool will have to be able to manage millions in live quotes simultaneously and reliably.

The simplest way I'd describe it is a form of an automated pair trading tool where opportunities are based on theoretical values priced off a per-defined ratio.

I've been using IB for over 10 years, so ideally I would build something that would work there, unless the developer/product manager convinces me there is a better direction.

I'm willing to pay fairly based on developer ability and experience. Thanks.
I have one written in java (akka). you just need to create a new strategy actor everything else is implemented. It's out of date though. free on bitbucket
 
I really find it hard to believe that a an operation like OP is proposing would be run at IB like MrMuppet said. Just can't get over that really there are so many things wrong with this they are innumerable. Even if you had perfect code it would not run as expected because of snap shot data. It's ok for an investor but not this project at all.

40% of what? 1st that's way too much you must be crazy....

Here I have just saved you 40k probably in just getting started.

To create a C++ framework for the described project, we will design the structure to include classes and functions that cover the main tasks. This framework will be modular and scalable to handle multiple products, generate theoretical bid/ask values, send various types of orders, and handle hedging operations. Here’s how we can conceptualize this framework using pseudocode:

High-Level Framework Design in C++ Pseudocode
1. Core Components
  • Product: Represents a tradeable product (futures, equity).
  • Strategy: Represents different market-making strategies (quote, market take, etc.).
  • Order: Represents buy/sell orders.
  • Hedge: Represents hedging actions.
2. Key Classes and Structures

// Base class for any tradeable product
class Product {
public:
std::string symbol; // Symbol for the product (e.g., AAPL, S&P Futures)
double currentPrice; // Current market price
double theoreticalBid; // Theoretical bid price
double theoreticalAsk; // Theoretical ask price

Product(std::string symbol) : symbol(symbol), currentPrice(0), theoreticalBid(0), theoreticalAsk(0) {}

virtual void updatePrice(double newPrice) {
currentPrice = newPrice;
}
};

// Derived class for Futures products
class FuturesProduct : public Product {
public:
FuturesProduct(std::string symbol) : Product(symbol) {}
};

// Derived class for Equity products
class EquityProduct : public Product {
public:
EquityProduct(std::string symbol) : Product(symbol) {}
};

// Class representing trading strategy
class Strategy {
public:
virtual void calculateTheoreticalValues(Product& productA, Product& productB, double ratio, double offset) = 0;
virtual void executeOrder(Product& product) = 0;
};

// Market making strategy (MM), quote, etc.
class MarketMakingStrategy : public Strategy {
public:
void calculateTheoreticalValues(Product& productA, Product& productB, double ratio, double offset) override {
productA.theoreticalBid = productB.currentPrice * ratio - offset;
productA.theoreticalAsk = productB.currentPrice * ratio + offset;
}

void executeOrder(Product& product) override {
// Implement logic for sending orders
// Could be multiple types: quote, market take, etc.
}
};

// Class for hedging operations
class Hedging {
public:
void generateHedgeOrder(Product& hedgeProduct, double quantity) {
// Generate and execute hedging order based on the given quantity
}
};

// Order class
class Order {
public:
std::string productSymbol;
std::string orderType; // "Buy" or "Sell"
double price;
int quantity;

Order(std::string symbol, std::string type, double price, int qty)
: productSymbol(symbol), orderType(type), price(price), quantity(qty) {}

void execute() {
// Logic to execute order
}
};

// Main Trading Engine to manage multiple products and strategies
class TradingEngine {
public:
std::vector<Product*> products; // List of products to trade
Strategy* strategy; // Current strategy in use

void addProduct(Product* product) {
products.push_back(product);
}

void setStrategy(Strategy* strat) {
strategy = strat;
}

void run() {
for (auto product : products) {
// Example: Assuming the first product is 'product A' and the second is 'product B'
// In reality, you would have more robust logic to match products
if (products.size() > 1) {
strategy->calculateTheoreticalValues(*products[0], *products[1], 1.5, 0.5);
strategy->executeOrder(*products[0]);
}
}
}
};

Explanation of the Framework
  1. Product Class Hierarchy:
    • The Product base class represents any tradeable item. Derived classes like FuturesProduct and EquityProduct can have specialized behavior.
    • Each product has a symbol, current market price, and calculated theoretical bid/ask prices.
  2. Strategy Class:
    • The Strategy base class defines a generic interface for different trading strategies. The MarketMakingStrategy class implements specific behavior for market-making.
    • The calculateTheoreticalValues method sets the theoretical bid/ask prices based on a given ratio and offset.
    • The executeOrder method simulates sending orders based on calculated values.
  3. Hedging Class:
    • The Hedging class is responsible for generating hedge orders. This is essential in market-making to manage risk.
  4. Order Class:
    • Represents a trade order with details such as product symbol, order type, price, and quantity. The execute method would handle the execution of orders.
  5. Trading Engine:
    • The TradingEngine class manages the overall operation, holding a list of products and applying a selected strategy.
    • The run method iterates over the products, applies the strategy to calculate theoretical prices, and sends orders.
Notes on Scalability and Robustness
  • Multithreading/Concurrency: In a real-world implementation, you would need multithreading or asynchronous processing to handle the continuous update of market data and the sending of orders in real-time.
  • Error Handling: Proper error handling mechanisms are required for robustness.
  • Data Management: Efficient management of real-time data streams, possibly using message queues or databases for persistent storage and retrieval.
  • Optimization: Techniques to minimize latency and maximize throughput, essential for handling millions of quotes and orders.
This pseudocode provides a framework that can be expanded upon with additional features, such as connecting to specific exchanges or trading platforms, handling more complex strategies, or implementing risk management protocols.
 
I really find it hard to believe that a an operation like OP is proposing would be run at IB like MrMuppet said. Just can't get over that really there are so many things wrong with this they are innumerable. Even if you had perfect code it would not run as expected because of snap shot data. It's ok for an investor but not this project at all.

40% of what? 1st that's way too much you must be crazy....

Here I have just saved you 40k probably in just getting started.

To create a C++ framework for the described project, we will design the structure to include classes and functions that cover the main tasks. This framework will be modular and scalable to handle multiple products, generate theoretical bid/ask values, send various types of orders, and handle hedging operations. Here’s how we can conceptualize this framework using pseudocode:

High-Level Framework Design in C++ Pseudocode
1. Core Components
  • Product: Represents a tradeable product (futures, equity).
  • Strategy: Represents different market-making strategies (quote, market take, etc.).
  • Order: Represents buy/sell orders.
  • Hedge: Represents hedging actions.
2. Key Classes and Structures

// Base class for any tradeable product
class Product {
public:
std::string symbol; // Symbol for the product (e.g., AAPL, S&P Futures)
double currentPrice; // Current market price
double theoreticalBid; // Theoretical bid price
double theoreticalAsk; // Theoretical ask price

Product(std::string symbol) : symbol(symbol), currentPrice(0), theoreticalBid(0), theoreticalAsk(0) {}

virtual void updatePrice(double newPrice) {
currentPrice = newPrice;
}
};

// Derived class for Futures products
class FuturesProduct : public Product {
public:
FuturesProduct(std::string symbol) : Product(symbol) {}
};

// Derived class for Equity products
class EquityProduct : public Product {
public:
EquityProduct(std::string symbol) : Product(symbol) {}
};

// Class representing trading strategy
class Strategy {
public:
virtual void calculateTheoreticalValues(Product& productA, Product& productB, double ratio, double offset) = 0;
virtual void executeOrder(Product& product) = 0;
};

// Market making strategy (MM), quote, etc.
class MarketMakingStrategy : public Strategy {
public:
void calculateTheoreticalValues(Product& productA, Product& productB, double ratio, double offset) override {
productA.theoreticalBid = productB.currentPrice * ratio - offset;
productA.theoreticalAsk = productB.currentPrice * ratio + offset;
}

void executeOrder(Product& product) override {
// Implement logic for sending orders
// Could be multiple types: quote, market take, etc.
}
};

// Class for hedging operations
class Hedging {
public:
void generateHedgeOrder(Product& hedgeProduct, double quantity) {
// Generate and execute hedging order based on the given quantity
}
};

// Order class
class Order {
public:
std::string productSymbol;
std::string orderType; // "Buy" or "Sell"
double price;
int quantity;

Order(std::string symbol, std::string type, double price, int qty)
: productSymbol(symbol), orderType(type), price(price), quantity(qty) {}

void execute() {
// Logic to execute order
}
};

// Main Trading Engine to manage multiple products and strategies
class TradingEngine {
public:
std::vector<Product*> products; // List of products to trade
Strategy* strategy; // Current strategy in use

void addProduct(Product* product) {
products.push_back(product);
}

void setStrategy(Strategy* strat) {
strategy = strat;
}

void run() {
for (auto product : products) {
// Example: Assuming the first product is 'product A' and the second is 'product B'
// In reality, you would have more robust logic to match products
if (products.size() > 1) {
strategy->calculateTheoreticalValues(*products[0], *products[1], 1.5, 0.5);
strategy->executeOrder(*products[0]);
}
}
}
};

Explanation of the Framework
  1. Product Class Hierarchy:
    • The Product base class represents any tradeable item. Derived classes like FuturesProduct and EquityProduct can have specialized behavior.
    • Each product has a symbol, current market price, and calculated theoretical bid/ask prices.
  2. Strategy Class:
    • The Strategy base class defines a generic interface for different trading strategies. The MarketMakingStrategy class implements specific behavior for market-making.
    • The calculateTheoreticalValues method sets the theoretical bid/ask prices based on a given ratio and offset.
    • The executeOrder method simulates sending orders based on calculated values.
  3. Hedging Class:
    • The Hedging class is responsible for generating hedge orders. This is essential in market-making to manage risk.
  4. Order Class:
    • Represents a trade order with details such as product symbol, order type, price, and quantity. The execute method would handle the execution of orders.
  5. Trading Engine:
    • The TradingEngine class manages the overall operation, holding a list of products and applying a selected strategy.
    • The run method iterates over the products, applies the strategy to calculate theoretical prices, and sends orders.
Notes on Scalability and Robustness
  • Multithreading/Concurrency: In a real-world implementation, you would need multithreading or asynchronous processing to handle the continuous update of market data and the sending of orders in real-time.
  • Error Handling: Proper error handling mechanisms are required for robustness.
  • Data Management: Efficient management of real-time data streams, possibly using message queues or databases for persistent storage and retrieval.
  • Optimization: Techniques to minimize latency and maximize throughput, essential for handling millions of quotes and orders.
This pseudocode provides a framework that can be expanded upon with additional features, such as connecting to specific exchanges or trading platforms, handling more complex strategies, or implementing risk management protocols.


Thanks claude.ai. Big help, bot.
 
python would be totally fine. Perhaps that's a takeaway here.

Very much this. Iterate, iterate, iterate. Run it "through a profiler" and get rid of hotspots as they creep up. As they say "premature optimization is the root of all evil". My own system uses no less than six different languages... the lisp stuff is mostly for my own "high touch" subsystems.

Reuse, reuse, reuse. Don't think for a moment that you should avoid some excellent open-source code because it's implemented in something besides your language du jour. Forking is your friend. A deep understanding of concurrency at the OS level is mandatory.

I've got some critical/redundant pieces in rather obscure languages that I'm perfectly happy with and balk at rewriting for mere academic reasons. Better to understand them and integrate them properly.

All that said, I prefer bottom-up/agile than BDUF/waterfall. If you don't have a small army of senior developers the bazaar will crush the cathedral every time IMHO. Either way I'd always keep in mind the following...

"The essence of writing is rewriting"
--- William Zinsser
If you want I'll send you a VM image w/ all my stuff for...
f093158dfa26aa8f80daeac989501cd4.jpg
 
Last edited:
Thanks for the advice- but I'm still interested in connecting with any developers who think they have the expertise... if they don't exist here so be it.

MrMuppet: I'm well aware of what you are saying, you are clearly knowledgeable and correct on most of these points, although some of your assumptions are not completely relevant or accurate for my needs, but you have identified a lot of the complexities.

I've been a senior trader a top tier Prop Firm for over a decade (one that everyone here is familiar with) helping to design tech/strategies for arbs and implementing them. I have probably spent more hours going through logs and working with developers than 99% percent of people here- but I wouldn't trust myself to build anything. I'm an arb trader/strategist- not a coder (in fact I've never backtested a single thing).

For the record, I never said how much I manage- I said I would have to trust the tool to manage millions in live quotes, but in retrospect this was not relevant.

Perhaps I misled my intention with my C++ comments- I am NOT trying to build some sort of latency-sensitive system, that I not my goal. I currently trade in a high-touch manner, but in a very specific way that I'm looking to automate in a manner that's very common at most ETF arb shops. My opportunities often last multiple seconds- so frankly any programming language would do- I figured one I'm paying to build something why not make it a good as possible for fast markets. But if that would make the price increase dramatically, python would be totally fine. Perhaps that's a takeaway here.

I get that there would a high chance for a messy/unusable tool- and it's not my first rodeo going down this hole, however I just wanted to see if there are any qualified developers I could find in this forum.. if not, so be it.

I also refuse to subscribe to this rule: "Either learn to code or buy off the shelf" - There are a lot more options that. For example another option I'm considering is to go in house to a prop house for 40% (and retain my IP)... but I don't really need their capital (I'm close to capacity for my higher sharpe stuff), so I basically be implicitly 'paying' them 60% for a good tech-stack... hence my reason to see if I could instead build something good enough.

If anyone has any other thoughts or ideas I'd been keen to hear them (besides do it yourself).

Thanks for the color, so at least you have at least some grip on what you´re getting into.
Nevertheless, as it´s already being said, it´s hard to understand why you would trade via IB which isn´t the same shop as it was when Peterffy was still in charge. It´s a trash shop with trash infrastructure and it´s internal risk engine is an enigma that will margin call you at will...or not.

At least start by looking at a proper clearer that offers proper tech.

If you have prop background, you know how many guys worked in the tech department. One guy for hardware, another one for connectivity and probably a couple of code jockeys to implement the traders ideas.
And that´s how many people you need. A senior who is proficient in critical low latency systems costs north of 200k today and that is just one guy.
You just cannot replicate the economics of scale of a prop shop as a one man show. Many tried and either failed or run a prop shop themselves sooner or later.

The problem is your market. If you said you trade crypto...well 15k worth of Python code on a Jupyter Notebook would do...and probably 1k/m maintainance. You would not even need to go custom for futures. TT or CQG is 2k/m all in
But you want to trade US Equities, one fragmented nightmare of a market that cannot decide weither it´s lit or OTC, where infra is crazy expensive because everyone and their mom is selling their soul to get a piece of that juicy 18 sharpe retail flow... and your software developer needs to understand it. Good luck with that.


Off the shelf or learn to code...or join a prop shop again. Weither you partner up with some coders and share your success or you pay a split for the tech. Paying 100k+ one time fee to replicate your former prop shops tech stack is the road to disaster, believe me ;)
 
I really hate to rain on your parade but I went through this myself and I can tell you that your expectations are absolutely unrealistic.

"How difficult can it be, right? The algorithm is pretty straight forward and I just need to connect it to IB API. Perhaps 20k - 30k will do and a guy from either a contractor or a guy from Upwork."

Here are some lessons for you:

- if your algo needs to do any kind of calculations based on past data, like theoretical values you need a database first. Most likely you will hire a monkey who codes one in SQL which blows up your machine within two weeks. Find me a freelancer who knows time series database programming such as KdB+ for under 200/h

- for your database to be filled with data, you will need a feed handler that translates and cleans the gibberish from your source into something that can be stored

- now we´re getting to the order management system or OMS. When you send an order, you send that message to the exchange, the exchange sends back a message that the order is either acknowledged, declined for whatever reason or cancelled. The same goes for fills. Your hedger can only hedge if it knows that the quoting order has been filled and by how much.
You will need exception handling, crash management, yada, yada, yada

- Let´s go over latency and expect 50ms ping to your broker and 50ms to the exchange: Your quoting order is sent to the broker first for the risk checks, then it gets to the exchange. That´s 100ms. Now you wait for the order confirmation, another 100ms. Now your pricing asset changes so you need to amend your quote (I hope the indian freelancer knows the difference between cancel/replace and amend), another 200ms
When your quote gets hit, it takes 100ms for the fill confirmation to get to you and another 100ms for the hedging order to arrive at the exchange and another 100ms until you know if you have been legged or not so that your risk management, we haven´t talked about yet, can either do nothing or amend the hedging order.

- Risk management: You need to make sure you have automatic kill switches in case your algo goes haywire and that your portfolio is in line with your risk parameters.

- Log: You need to log every single action of your algo and you also need to log your mark outs vs. theo to measure slippage.

- Your quote machine needs to be in line with the exchange rules, meaning you have to throttle your quotes and maintain a given message to fill ratio.

- Exchange connections and Broker APIs are patched all the time and your system will be infested with bugs so you have to maintain the connector and the software.

- On top of all you don´t have any idea how all of this works so you cannot differentiate between a qualified programmer who has experience with this kind of stuff and a punk who tells you "no problem, you´ll have it next week"

- Futures would be easier but you want to trade equities. There are 17 different exchanges and an infinite number of dark/OTC venues so you need to handle all of them AND you need to decide where your passive order should sit. Maker/taker fee structure, order types, routing, you name it

Unless you have a mid 6 figure budget for development and a 5 figure monthly budget for maintainance you will end up with an unusable product that causes more harm than good. Been there, done that. Either learn to code or buy off the shelf.


I don´t know what you´re planning to do but I guess you´re not looking to trade pairs with 50bps slippage but you don´t care because 3 week holding period and you will also not mass quote 500 single names against SPY.
So you are neither happy with a retail spreader that can be had for 100/month nor do you have the capacity for a seven figure low latency infrastructure.


Your best bet would be a prop shop infrastructure aka.

- broker/clearer with low latency DMA...meaning say good bye to IB
- off the shelf software that is running on a co-located server maintained by the SaaS provider. If you rent the software only and look to deploy it yourself on either colo or cross connected virtual machines you´re looking at a massive overhead since NASDAQ alone is round about 30k/month just for priority connection.

For equities I would guess you´re good with a monthly budget between 5 and 10k all in.
Sounds steep? You will get it cheaper, but look at it this way:

You "manage millions", so I guess we´re looking at a 2m USD account :D
Let´s say you are turning that over 200 times per year, that´s 400m USD turnover per year.
An average slippage of 4bps (2cts for a 50$ stock) will cost you 160k. So imagine using a shitty retail setup that runs on your local machine with "fast internet" and averages 20bps slippage over theoretical (10cts for a 50$ stock) -> 800k


Be warned, my friend. The rabbit hole you´re about to crawl into is very, very deep.

The gem of a post like this make wading through the morass worth it.
 
Back
Top