How a Trade Replication Engine Works

A trade replication engine takes one inbound signal and produces one independent execution attempt per connected account. The signal is read once. The orders are dispatched separately. From that point forward, each account lives and dies on its own results, regardless of what happens anywhere else in the fan-out.

That dispatch step sounds simple, and structurally it is. Every genuinely hard problem in multi-account automation sits downstream of it: keeping accounts in sync when brokers reject orders selectively, preventing duplicate executions when a signal arrives twice, and sizing positions correctly when accounts hold very different amounts of capital. This article walks through each of those problems in the order you will encounter them.

If you are running one strategy across several of your own accounts, or evaluating whether to do so, understanding the mechanics below will save you from surprises that are difficult to diagnose after the fact.

What a Replication Engine Actually Does

One Signal, Multiple Executions

The accepted payload fields (ticker, action, sentiment, quantity, orderType) are read once when the signal arrives. After that, the engine dispatches separately to each connected account. A fill in one account has no bearing on the result in another: each downstream execution is an independent attempt.

What is not being replicated matters as much as what is. Position state is not shared. The engine does not synchronize open positions between accounts after the fact. If account A fills and account B does not, no automatic correction brings account B into alignment.

Fill prices are not replicated either. Each broker returns its own execution price, so accounts receiving the same signal will rarely fill at identical prices. Risk controls configured per account (allowed sides, trading windows, order type overrides) apply independently and can cause one account to act differently from another on the same signal.

The Fan-Out Model

How Fan-Out Is Structured

Fan-out means the engine takes one accepted payload and spawns one execution path per account, running those paths concurrently rather than sequentially. The fan-out step itself is the simplest part of the architecture. Every hard problem that follows (idempotency, ordering, partial failure, sizing, reconciliation) is a consequence of fan-out, not a property of it.

Each execution path goes through the same planning and approval stages independently, including fetching quotes and checking buying power at that specific broker. Two accounts at different brokers will complete those steps at different speeds depending on each broker's API responsiveness.

Latency Compounds Across Paths

Signal-to-fill latency runs through four phases: signal transit, planning (quote and buying-power fetch), approval, and execution. Each account's execution path runs through all four phases independently. Because paths run concurrently, total wall-clock time for the fan-out is closer to the slowest single path than to the sum of all paths. Adding accounts does not multiply elapsed time, but it does mean the overall fan-out finishes no faster than the slowest broker in the group.

Idempotency: Handling Duplicate Signals

Why Duplicates Happen

Webhook delivery from third-party signal sources is not guaranteed to be exactly-once. A signal may arrive more than once, or not at all. Network retries, alert platform retries, and user-initiated retests can all produce duplicate signals that carry identical payload content. Without idempotency controls, a duplicate signal that reaches a replication engine will fan out a second set of orders to every connected account.

Staleness Checks as a Defense

Including a timestamp in the payload using the time field (ISO-8601) allows the engine to calculate signal age and reject stale duplicates before they reach the fan-out step. The rejectAfter field accepts a maximum signal age in seconds (1-30) for entry or exit staleness checks, using the time field when present and falling back to webhook receive time.

A signal that arrives twice within the staleness window is not automatically safe. If the first copy was already processed, the second copy must be detected and discarded by the engine, not by staleness logic alone. The most reliable defense combines a time field in every payload with a rejectAfter threshold appropriate to your signal frequency.

Ordering Is Not Guaranteed

Why Signal Order Can Invert

Two signals sent in rapid succession may arrive at the engine out of order due to network jitter, alert platform queuing, or processing delays. Sending a buy and sell signal within milliseconds of each other creates a race condition: there is no guarantee the buy order will be sent to the broker and filled before the sell order is received and processed. The practical guidance is to leave at least one to five minutes between signals rather than relying on send order to determine execution order.

Exit-Before-Entry Sequencing

When a single signal requires both closing an existing position and opening a new one on the opposite side, sending one combined signal is safer than sending two back-to-back signals. With a single signal, the engine can ensure the exit order is submitted first and waits for that fill before submitting the entry order, rather than leaving sequencing to network timing.

Sending a simultaneous exit and entry as two separate signals is unsupported because there is no guarantee of processing order between them. If signals must be separated, enforce a delay of at least one to five minutes between them.

Partial Failure Is the Normal Case

How Partial Failure Occurs

A broker can reject an order for one account (insufficient buying power, unsupported order type, symbol restriction) while accepting the same order for another account on the same signal. Failed or rejected orders are never retried. If broker communication fails, no retry attempt is made, and the accounts that failed are left without the intended position.

The engine may send an email notification when a trade fails, but some rejection scenarios, such as an order accepted by the broker and later rejected internally, may not surface a failure notification. Do not rely on the absence of a notification as confirmation that all accounts filled successfully.

Designing for Partial Failure

Treat every account as independently capable of ending up in a different state from its siblings after any given signal. Order type fallback applies per account: if an order type sent in the payload is not supported by a specific broker, that account falls back to its configured default order type, which may differ from what other accounts receive. Monitoring each account's position state separately, rather than assuming all accounts mirror the first successful fill, is the only reliable approach.

Per-Account Sizing

Why Sizing Belongs in Account Config

A single payload drives accounts of different sizes, so a fixed quantity in the signal (quantityType fixed_quantity) will produce the same absolute position in every account regardless of account equity. That is rarely the intended behavior for multi-account replication.

Dynamic quantity types such as percent_of_equity and risk_percent calculate position size at execution time using each account's actual equity, naturally scaling position size to account size without changing the signal. TradersPost resolves quantity at the account level using the quantityType field, so one signal drives correctly sized positions across accounts of different sizes without any payload modification.

Risk-Based Sizing Across Accounts

The risk_dollar_amount and risk_percent quantityType values require a stop loss to be present, either in the payload or in subscription settings, because position size is calculated backward from risk tolerance. risk_percent calculates a quantity for the given risk percent of equity, making it the most portable sizing method across accounts of different sizes because it references each account's own equity rather than a shared dollar figure.

Accounts at brokers that do not support a stop loss order type will receive a fallback order type, which can affect whether the risk-based size calculation applies correctly for that account. Verify stop loss support at each connected broker before relying on risk-based sizing across the full fan-out.

Reconciliation After the Fan-Out

What Reconciliation Means Here

Reconciliation is the process of verifying that each account's actual position matches the intended position after a fan-out completes, and deciding what to do when they differ. Because partial failure is normal and fill prices vary per broker, accounts will routinely diverge from each other after a multi-account signal. Reconciliation is the trader's responsibility. The engine does not automatically flatten an account that missed an entry or re-enter an account that was rejected.

Rate Limits and API Call Volume

Each account in a fan-out generates its own set of broker API calls: quote fetch, buying power check, and order submission at minimum. Adding a second account at least doubles the API call volume per signal. Broker API rate limits apply per account or per API key, not across the aggregate fan-out. An account at a rate-limited broker will queue or fail while other accounts proceed.

Webhook-driven replication is designed for higher timeframe signals where API call volume per unit time remains within broker limits. High-frequency use cases are outside the intended operating range of this architecture.

Replication Readiness Checklist

Signal Hygiene

• Include the time field in every payload using ISO-8601 format so the engine can calculate signal age and so staleness checks via rejectAfter have a precise reference point.
• Never send back-to-back signals intended to be processed in a specific order within milliseconds of each other. Use a single combined signal or enforce a delay of at least one to five minutes between signals.
• Set test to true when validating payload structure and fan-out behavior so that orders are processed as test signals and not submitted to any broker.

Per-Account Configuration

• Configure sizing at the account level using dynamic quantityType values (percent_of_equity, risk_percent) rather than relying on a fixed quantity in the signal payload.
• Verify that each connected broker supports the order types and time-in-force values in your payload. Unsupported values fall back to account-level defaults, which may differ from your intent.
• Monitor each account independently after every signal. A successful fill in one account does not imply success in all accounts.

If you are running multiple accounts through a single strategy and want to see how TradersPost handles fan-out, per-account sizing, and staleness controls in practice, you can connect your broker accounts and test with the test flag before sending live signals.

Bottom Line

• A trade replication engine dispatches one independent execution per account. No state, no fill price, and no position is shared between accounts after the signal is accepted.
• Partial failure is normal. A broker rejection in one account leaves that account out of the position with no automatic correction and no retry.
• Ordering between signals is not guaranteed. Use a single combined signal for exit-plus-entry, and leave at least one to five minutes between any two separate signals.
• Size positions using dynamic quantityType values so each account's position scales to its own equity rather than receiving a fixed absolute quantity.
• Reconciliation, rate limit monitoring, and per-account position verification are your responsibility as soon as you add the second account.

Frequently Asked Questions

Does a replication engine guarantee identical positions?

No. Each account's order is an independent execution attempt. A broker can reject an order for one account while accepting it for another on the same signal. Failed or rejected orders are never retried, so an account that misses a fill stays out of the position until a new signal arrives or the trader intervenes manually. Reconciliation across accounts is the trader's responsibility, not the engine's.

How should I size across accounts of different sizes?

Use a dynamic quantityType such as percent_of_equity or risk_percent rather than a fixed quantity. A fixed quantity in the signal payload produces the same absolute position in every account regardless of account size. Risk-based sizing options (risk_dollar_amount, risk_percent) require a stop loss to be present in the payload or in account subscription settings.

What happens if the same signal arrives twice?

Without a staleness check, the engine treats the second arrival as a new signal and fans out a second set of orders to all connected accounts. Adding a time field to the payload and configuring rejectAfter allows the engine to reject signals older than the specified threshold (1-30 seconds), which reduces the impact of delayed duplicates. Including time in every payload is the most accurate defense because rejectAfter uses that field when present and falls back to webhook receive time otherwise.

Does more accounts mean more rate limit risk?

Yes. Each account in a fan-out generates its own independent set of API calls for quote fetching, buying power checks, and order submission. Two accounts means at least twice the API calls per signal. Broker rate limits apply per account or API key, not across the combined fan-out, so a rate-limited account will fail or queue while others proceed. Webhook-driven replication is designed for higher timeframe strategies where signals are infrequent enough to stay within broker API limits.

Can I send exit and re-entry as two separate signals?

Sending two back-to-back signals for exit and re-entry is unsupported because there is no guarantee of processing order between them. The correct approach is to send a single signal that implies both the exit and the entry. The engine will submit the exit order first, wait for it to fill, and then submit the entry order. If signals must be sent separately, leave at least one to five minutes between them to reduce race condition risk.