Get In touch
Feel free to email me at hi@riteshr.au for counsuting work, and I'll get back to you.
A copy-trading platform built for fund managers to execute a single trade decision and have it accurately relayed, sized, and executed across every client account under their management — each with its own fund level, risk profile, and broker relationship — while giving clients real-time visibility into their own portfolio.
The system was built to solve a problem that sits at the center of managed trading: a fund manager doesn't trade one account, they trade a decision — and that decision has to reach thousands of accounts, correctly and fast, without becoming the fund manager's full-time job.
Fund managers running copy-trading strategies aren't managing one portfolio — they're managing one decision that has to become thousands of individually correct trades. Each client account under a manager can differ in fund level, risk tolerance, and available capital, which means the same trade decision can't simply be duplicated account to account — it has to be sized and validated per client, every time.
At the volume a single fund manager could operate at — thousands of clients — doing this manually, or even semi-manually, wasn't viable. A delay of even a few seconds between a manager's decision and execution across the client base could mean very different fill prices for different clients on what was supposed to be the same trade. And any trade that failed to execute couldn't simply be dropped — it had to be tracked and retried, or the fund manager's intended position would silently diverge from what actually happened in clients' accounts.
The core challenge wasn't placing a trade — it was building a system that could take one decision and correctly, quickly, and accountably turn it into thousands of individual trades across accounts with different fund levels, risk profiles, and brokers, while keeping every client's accounting accurate and giving them visibility into the result.
This meant the system needed to:
In effect, the system needed to behave less like a single trading terminal and more like a real-time fan-out engine, where one instruction became many independently validated, accounted, and tracked transactions.
I was responsible for the architecture and development of the platform, with ownership spanning the trade-relay engine, accounting, bank integration, and the multi-tenant structure underneath all of it.
My work included:
The key architectural responsibility was making sure that no matter how many clients sat under a fund manager, a single trade decision reached every account correctly and with minimal delay — and that every account's accounting stayed accurate even when a trade didn't go through as planned.
The hardest part of this system was structural: a fund manager's single trade decision had to become thousands of individually valid trades without processing them one at a time. Sequential relay would have meant clients further down the line got meaningfully different execution than clients at the front — unacceptable when they were all supposed to be following the same decision. Multiprocessing the relay and execution path was what kept manager-to-broker delay minimal regardless of how many clients sat under a manager.
Even though every client under a manager was reacting to the same trade decision, none of them could simply receive an identical trade — fund levels and risk profiles differed per client. The system had to validate and size every trade per account, in parallel, without that per-client logic becoming the bottleneck that reintroduced the latency the multiprocessing model was built to remove.
Trading against a stale internal balance risks executing trades a client can't actually afford. Integrating directly with bank APIs to check fund levels in real time meant the system could validate against ground truth at the moment of the trade — at the cost of needing to handle bank API latency and failures gracefully without stalling the broader relay process for other clients.
A trade that doesn't execute same-day can't just disappear — the manager's intended position and the client's actual holdings would silently diverge. Building an automated retry mechanism that queued unexecuted trades for the next trading day, without duplicating trades that had partially executed or re-triggering trades that had failed for a client-specific reason (like insufficient funds), required treating trade state as something to be tracked deliberately, not assumed.
With multiple fund managers each running their own client base of up to 5,000 accounts, the platform had to guarantee that one manager's trading volume, one client's fund shortfall, or one tenant's activity never leaked into another's accounting or execution path. That isolation had to hold at the multi-tenant level and the per-client level simultaneously, without duplicating infrastructure per tenant.
This project changed how I think about systems where one action is supposed to become many identical-in-intent but individually-different outcomes. It's tempting to think of copy-trading as a broadcast problem — send the same instruction everywhere. In practice, it's closer to running thousands of small, independent decisions in parallel, all derived from one source of truth, each of which can succeed, fail, or need to wait a day, without any of that affecting the others.
The real engineering challenge wasn't the trading logic itself — it was building the plumbing that let one decision travel to thousands of accounts fast, get validated individually, and stay accountable if something didn't go as planned. That's the same lens I bring to any system where scale isn't just "more of the same," but "more independently-correct instances of the same."
Feel free to email me at hi@riteshr.au for counsuting work, and I'll get back to you.