A copier that’s set up wrong doesn’t fail loudly — it quietly puts the wrong size on the wrong account until a firm’s drawdown line ends the experiment. Set up right, it turns one clean decision into synchronized fills across every account you run.
Here’s the configuration order that keeps you out of trouble.
Choosing your master account
The master is the account you trade by hand — every slave mirrors it, so pick it deliberately.
Good master criteria:
- The one you actually watch. Your master should be the account you’d trade even if the copier didn’t exist. You need eyes on the source of truth.
- The most stable connection. If the master’s platform drops, nothing propagates. Favor the account on the most reliable data feed and lowest latency.
- The least fragile ruleset. Because the master leads, avoid making your tightest-drawdown or nearest-to-breach account the master — you don’t want the source of every trade to be the one most likely to get disabled mid-session.
One master, clearly designated. Multiple masters feeding overlapping slaves is how you double-fill an account by accident.
Connecting slaves: broker-side vs platform copiers
There are two broad architectures, and the choice shapes everything downstream.
- Platform copiers run inside the trading terminal (an EA or add-on that reads the master and writes to slaves on the same machine or a bridge). Simple to start, but tied to the platform staying open and online.
- Broker-side / server-side copiers route fills through a service that connects to each account’s API. No terminal babysitting, faster and more resilient, and they can enforce per-account logic centrally.
For prop stacks that span platforms, server-side is usually the sturdier choice. Shibiki connects each account through its native integration — MetaTrader 5 for MT5 prop accounts, cTrader for cTrader ones — and routes copies server-side, so a closed terminal doesn’t break the chain and each account keeps its own risk enforcement.
| Platform copier | Server-side copier | |
|---|---|---|
| Runs where | Inside the terminal | Broker/API connection |
| Needs terminal open | Yes | No |
| Cross-platform | Hard | Native per platform |
| Per-account rule enforcement | Limited | Central |
Whichever you choose, confirm each firm permits copying into that account before you connect it — the rules differ by firm and change often.
Lot-size mapping — fixed, multiplier, or risk-based
This is the setting that most often blows accounts, because the master’s size is almost never the right size for a slave. Three mapping modes:
- Fixed — every slave trades a set size regardless of the master. Predictable, but ignores that accounts differ in size and rules. Use only when all accounts are near-identical.
- Multiplier — slave size = master size × a factor (0.5×, 2×, etc.). Simple to reason about, but it inherits the master’s risk shape: if the master oversizes, so does every slave, proportionally.
- Risk-based — each slave computes its own size from its own account balance and the trade’s stop distance, targeting a consistent risk percentage per account. This is the safest for a mixed stack, because a smaller or tighter-drawdown account automatically takes less. Work the sizes out with a lot size calculator before you commit them.
The principle: map risk, not lots. Two accounts with different sizes trading the same lot count are not running the same strategy — they’re running two different risk levels that happen to look alike. Risk-based mapping keeps each account inside its own limits even when the master doesn’t have to.
Symbol and order-type filters
Not every trade on the master belongs on every slave. Filters are how you stop copies you don’t want.
Configure per slave:
- Symbol whitelist / blacklist. If a slave’s firm restricts an instrument, or the broker’s symbol name differs (e.g.
NAS100vsUSTEC), map or block it. A mismatched symbol either errors or, worse, fills the wrong market. - Order-type filter. Some slaves should only mirror market orders and ignore pending orders, or skip trades below a minimum stop distance.
- Session / time filter. Block copies during windows where a slave’s firm restricts trading — around high-impact news, or outside allowed hours.
Get the symbol mapping wrong and the copier will happily route a valid-looking order to the wrong contract. Verify every symbol maps correctly on each slave before live size touches it.
Testing with a single micro lot before you scale
Never trust a fresh copier configuration with real size. The whole setup — connection, mapping, filters, symbol names — has failure modes you can’t see until a trade actually flows through it.
The test protocol:
- Set the smallest possible size everywhere — one micro lot on the master, minimum on each slave.
- Open one trade on the master and watch it land on every slave. Confirm it appears on all of them, on the right symbol, at roughly the right size.
- Modify and close it. Move the stop, then close. Verify each slave mirrors the modify and the close — copiers that open fine sometimes miss exits, which is the dangerous direction.
- Check the records. Every slave fill should be attributable back to the one master decision. Shibiki flags these as a copy group automatically, so you can confirm the fills line up and later pool them into one edge view with a Wilson confidence interval as the sample grows.
- Scale in stages. Only after a clean micro-lot cycle do you step size up — and even then, gradually.
Run this drill again after any change to mapping or filters. A copier is infrastructure: you test it small, prove the exits work, and only then let it carry real risk across accounts like Topstep and the rest of your stack.
Related: MT5 integration · cTrader integration · lot size calculator