Portfolio · FinTech

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 Capabilities

One trade decision. Thousands of independently correct executions.

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.

Context

Why this system was needed.

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 problem wasn't placing one trade.

The core challenge 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.

Relay one decision across every account

A single trade instruction had to reach every client account under a manager with minimal delay.

Validate each client independently

Every trade had to be sized and validated against each client's own fund level and risk profile.

Verify real funds before execution

Available funds had to be checked directly against the client's bank account before execution.

Recover failed trades safely

Trades that failed same-day needed to be tracked and retried without being lost or duplicated.

Keep accounting isolated per client

Every client account required independent accounting, positions and history regardless of what happened elsewhere.

Scale across multiple fund managers

The platform had to support multiple fund managers and their separate client bases on shared infrastructure.

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.

My Role

Architecture and platform development.

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.

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

Where the complexity actually lived.

Challenge 01

Fanning one decision out to thousands of accounts without losing speed

Sequential relay would have meant clients further down the line received meaningfully different execution than those at the front. Multiprocessing the relay and execution path kept manager-to-broker delay minimal regardless of client count.

Challenge 02

Validating individually while acting collectively

Every client was reacting to the same manager decision, but each trade still had to be sized and validated independently without that per-client logic becoming a bottleneck.

Challenge 03

Trusting real bank data over cached balances

Bank APIs were used to verify fund levels against real account data at execution time, while API latency and failures had to be isolated so one client could not stall the broader relay process.

Challenge 04

Making unexecuted trades a retry, not a loss

Failed trades needed explicit state tracking and automated retry logic so the intended portfolio could not silently diverge from actual client holdings.

Challenge 05

Keeping tenants and clients fully isolated at scale

Multiple fund managers could each operate thousands of client accounts, so tenant-level and client-level isolation had to remain intact without requiring separate infrastructure for every tenant.

Reflection

One intent can still require thousands of independently correct outcomes.

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.