Copy Trade Application

Turning one fund manager's decision into thousands of accurately executed trades, in real time


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.

Key metrics


  • Supported fund managers with up to 5,000 clients each, each with independent fund levels and risk profiles
  • Multiprocessed trade relay minimizing delay between manager trigger and broker execution across all client accounts
  • Multi-tenant architecture supporting multiple fund managers and their client bases independently
  • Direct bank API integration for real-time fund-level verification
  • Automated next-day trade retry for orders that couldn't be executed same-day
  • Companion mobile application for real-time client portfolio tracking
reconciliation system screenshot

Context


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 Challenge


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:

  • Relay a single trade decision to every client account under a manager with minimal delay.
  • Size and validate each trade individually against each client's fund level and risk profile.
  • Verify available funds directly against the client's bank account before execution.
  • Handle trades that failed to execute same-day without losing or duplicating them.
  • Keep full accounting for every client account, independent of every other.
  • Support multiple fund managers and their separate client bases on one platform.
  • Give clients real-time visibility into their own portfolio performance.
  • Scale trade relay so that manager-to-broker delay stayed minimal regardless of client count.

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.

reconciliation system screenshot

My Role


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:

  • Designing the trade relay architecture that fanned a manager's single trade decision out across all client accounts.
  • Designing the multiprocessed execution model to minimize manager-to-broker latency at scale.
  • Building the per-client accounting system tracking fund levels, positions, and trade history independently per account.
  • Implementing the retry mechanism for trades that failed to execute same-day.
  • Integrating with bank APIs to verify client fund levels in real time before execution.
  • Designing the multi-tenant structure supporting multiple fund managers and their client bases on shared infrastructure.
  • Working on the mobile application layer for real-time client-facing portfolio tracking.

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.

Engineering Challenges


1
Fanning one decision out to thousands of accounts without losing speed

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.

2
Validating individually while acting collectively

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.

3
Trusting real bank data over cached balances

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.

4
Making unexecuted trades a retry, not a loss

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.

5
Keeping tenants and clients fully isolated at scale

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.

Reflection


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

Get In touch

Feel free to email me at hi@riteshr.au for counsuting work, and I'll get back to you.