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 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).

 

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 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.

 

Thanks claude.ai. Big help, bot.

 

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...

 

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

 

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