---
title: "QUANTMONITOR LIVE PORTFOLIO — Monthly Performance Update"
description: "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 U..."
url: https://quantmonitor.net/quantmonitor-live-portfolio-monthly-performance-update-3/
date: 2026-02-25
modified: 2026-02-25
author: "Lukas"
image: https://quantmonitor.net/wp-content/uploads/2026/02/nahledovka-2026.webp
categories: ["Nezařazené"]
type: post
lang: en
---

# QUANTMONITOR LIVE PORTFOLIO — Monthly Performance Update

### 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:
`dax`
`dow`
`brent`
`xauusd`
`usdjpy`
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_H`
`BRENT = BZ_J`
`XAUUSD = GC_J`
`USDJPY = 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=false`
`PlaceLimitOrderIfSlipped=true`
`LimitOrderExpirationMinutes=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=true`
`PlaceLimitOrderIfSlipped=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.

[
⬇️ Download: FX Blue Copier Configuration Files (.set)
](https://quantmonitor.net/wp-content/uploads/2026/02/Archiv.zip)

I will attach the configuration files used in this setup to the article:
*DAX
`dax sender.set`
`dax receiver.set`
DOW
`dow sender.set`
`dow receiver.set`
Brent
`brent sender.set`
`brent receiver.set`
Gold (XAUUSD → GC)
`xauusd sender.set`
`xauusd receiver.set`
USDJPY → 6J
`usdjpy sender.set`
`usdjpy 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.