QuantMonitor Live Portfolio:
Performance Has Been Moving Sideways Recently + Launching a CFD-to-Futures Copying Test
Welcome to another episode of the QuantMonitor Live Portfolio Monthly Performance Update.
In recent weeks, the portfolio has been moving mostly sideways without significant growth. This is a natural phase in the development of any systematic portfolio — after stronger growth periods, consolidation often follows, where strategies continue generating trades, but the overall equity curve temporarily flattens.
Instead of chasing short-term performance, I’m now focusing on an important next step: infrastructure development, specifically a project for copying trades from a CFD account to a futures account.
New Project:
Copying from CFD to Futures (FX Blue Personal Trade Copier)
I have launched a test project in which I copy selected signals from CFD symbols to corresponding futures contracts using FX Blue Personal Trade Copier.
The goal of this project is to:
preserve the entry/exit logic of the existing strategies,
move execution to futures markets,
test practical usability (fills, slippage, stability, synchronization),
prepare the groundwork for a more robust future deployment.
This is not a final production setup yet — it is a controlled practical test that I will monitor for several months and then evaluate.
How the Copying Works in Practice (Based on the .set Configuration Files)
The architecture is simple and transparent:
for each market, I use a separate pair of settings files:
Sender (.set) = monitors and broadcasts trades from the CFD account
Receiver (.set) = receives signals and opens the corresponding futures contracts
1) Separate Channels for Each Market
Each market uses its own communication channel, for example:daxdowbrentxauusdusdjpy
This means signals do not mix across markets — DAX goes only through the DAX channel, gold only through XAUUSD, etc.
2) The Sender Filters Only a Specific CFD Symbol
In each sender file, a specific symbol is defined via IncludeSymbols, for example:
DAX sender: IncludeSymbols=.DE40Cash
DOW sender: IncludeSymbols=.US30Cash
Brent sender: IncludeSymbols=BRENT
Gold sender: IncludeSymbols=XAUUSD
USDJPY sender: IncludeSymbols=USDJPY
Important sender settings:
only selected symbols are copied,
pending orders are disabled (IncludePendingOrders=false),
the copier does not send already existing/open trades after startup (AllowExistingOrders=false),
heartbeat runs every 10 seconds (HeartbeatPeriodSeconds=10),
trade monitoring is fast (TradeWatchFrequencyMS=100),
warning notifications can be sent by email (SendWarningsByEmail=true).
3) The Receiver Maps the CFD Symbol to a Futures Contract
The key part is CustomSymbolMappings, which defines exactly what should be opened on the futures account:.DE40Cash = FDAX_H.US30Cash = YM_HBRENT = BZ_JXAUUSD = GC_JUSDJPY = 6J_H
The receiver also uses PermittedSymbols, so it allows only the target futures symbol.
This reduces the risk of an incorrect order being opened on the wrong instrument.
4) Position Size: Fixed Lots on the Receiver Side
On the futures side, each market uses a fixed contract size (UseFixedLotSize), meaning that regardless of the CFD lot size, a predefined integer number of futures contracts is opened on the target account.
Current receiver settings:
FDAX_H = 1 contract
YM_H = 5 contracts
BZ_J = 8 contracts
GC_J = 4 contracts
6J_H = 10 contracts
This is a practical implementation of the CFD → futures conversion with respect to account size, notional exposure, and the fact that futures must be traded in whole contracts.
“Ideal” (Non-Integer) Contracts vs. Real-World Futures Sizing
When designing the conversion, the approximate ideal (non-integer) contract sizes are:
FDAX: 0.0024 × 416.67 = 1.00
YM: 0.012 × 416.67 = 5.00
BZ: 0.02 × 416.67 = 8.33
GC: 0.01 × 416.67 = 4.17
6J: 0.0244 × 416.67 = 10.17
Because futures can only be traded in whole contracts, I use rounded fixed sizes in the receiver settings (currently conservatively):
BZ: 8 instead of 8.33
GC: 4 instead of 4.17
6J: 10 instead of 10.17
This keeps exposure close to the target level while avoiding over-allocation.
How Slippage and Execution Are Handled
The receiver settings also include important execution parameters:
for most markets:TradeAllOrdersAtMarket=falsePlaceLimitOrderIfSlipped=trueLimitOrderExpirationMinutes=20
This means that if the entry price moves outside the acceptable range (slippage), the copier attempts to handle the situation by placing a limit order with a time expiration.
Exception: USDJPY → 6J
For USDJPY / 6J, I currently use a different configuration:TradeAllOrdersAtMarket=truePlaceLimitOrderIfSlipped=false
In other words, I prefer immediate market execution there, without switching to a limit order.
This is part of the test — I want to compare how different execution approaches perform in real fills.
What I Will Track Over the Next Few Months
I treat this project as a live experiment with a clear objective: to determine whether copying signals from CFD to futures is operationally viable over the long term.
In the follow-up evaluation, I will focus mainly on:
entry/exit consistency between the source and target accounts,
slippage and execution quality,
tracking error versus the original CFD portfolio,
behavior during volatile market moves,
copier stability and any issues (heartbeat / rejected orders).
In a few months, I will publish a separate article with the results and concrete numbers.
I will attach the configuration files used in this setup to the article:
DAXdax sender.setdax receiver.set
DOWdow sender.setdow receiver.set
Brentbrent sender.setbrent receiver.set
Gold (XAUUSD → GC)xauusd sender.setxauusd receiver.set
USDJPY → 6Jusdjpy sender.setusdjpy receiver.set
(You can also add short labels such as “CFD sender” / “Futures receiver” so it is immediately clear what each file is for.)
Additional Note: Darwinex Zero Futures Copying (Calibration Phase)
As part of this project, I am also copying signals to futures contracts connected to my Darwinex Zero setup: https://www.darwinexzero.com/darwin/BPQC
Please note that this DARWIN is still being created and is currently in the calibration phase, so the track record should be viewed as preliminary at this stage. I will share a more meaningful evaluation once the calibration period is complete and I have enough data from live operation.
Conclusion
The portfolio is currently in more of a consolidation phase, but at the same time I am moving the project forward on the infrastructure side. Copying from CFD to futures is an important step toward a more robust and scalable setup.
If you’re interested in the progress, follow the next monthly update — the next episode will already include the first practical observations from the running copier test.
