Esecuzione, monitoraggio e rischio di un algoritmo

Un backtest positivo non è un via libera. Tra il test e il conto reale ci sono ostacoli che il test non vede: spread variabili, slippage, rifiuto degli ordini, bug, interruzioni di connessione, cambi di regola del broker. Questa lezione ti guida in un passaggio graduale e prudente, con i sistemi di sicurezza che devono esistere prima di far girare un algoritmo con denaro.

Le fasi consigliate

1. Backtest solido con costi realistici e validazione (moduli precedenti).
2. Paper trading (dati in tempo reale, ordini simulati o su conto demo) per almeno qualche settimana e un numero minimo di operazioni.
3. Live con size minima (rischio 0,1-0,25%) per 1-3 mesi, per verificare esecuzione, slippage e comportamento reale.
4. Aumento graduale solo se i risultati restano coerenti con il test e i limiti di sicurezza funzionano.

Cosa cambia tra test e reale

L'architettura di un sistema di esecuzione

Un sistema semplice ma robusto ha questi blocchi:

1. Ingestione dei dati: legge le candele chiuse (dal broker o da una fonte affidabile).
2. Motore dei segnali: lo stesso codice usato nel backtest, applicato in tempo reale alla candela appena chiusa.
3. Gestore del rischio (risk guard): un modulo che può bloccare qualsiasi ordine (limiti giornalieri, massimo posizioni, spread anomalo, orari).
4. Esecutore: invia gli ordini al broker con stop loss e take profit già impostati.
5. Registro (log): scrive ogni decisione, ordine e risposta.
6. Monitoraggio e allarmi: notifica errori e superamento di soglie.
7. Kill switch: un modo semplice per spegnere tutto (anche a mano).

Il principio chiave: il risk guard deve essere indipendente dal motore dei segnali e avere l'ultima parola.

Un esempio di risk guard

Uno schema in Python puro (senza dipendenze dal broker), da testare a fondo:

from datetime import datetime, timezone

class RiskGuard:
    def __init__(self, max_daily_loss_r=2.0, max_trades_per_day=3, max_spread_pips=2.5,
                 max_open_positions=1, allowed_hours=(7, 10)):
        self.max_daily_loss_r = max_daily_loss_r
        self.max_trades_per_day = max_trades_per_day
        self.max_spread_pips = max_spread_pips
        self.max_open_positions = max_open_positions
        self.allowed_hours = allowed_hours
        self.reset_day()

    def reset_day(self):
        self.day = datetime.now(timezone.utc).date()
        self.daily_r = 0.0
        self.trades_today = 0
        self.killed = False

    def register_result(self, r):
        self.daily_r += r
        if self.daily_r <= -self.max_daily_loss_r:
            self.killed = True          # limite di perdita giornaliero raggiunto

    def can_trade(self, spread_pips, open_positions, now=None):
        now = now or datetime.now(timezone.utc)
        if now.date() != self.day:
            self.reset_day()
        if self.killed:
            return False, "kill switch: perdita giornaliera raggiunta"
        if self.trades_today >= self.max_trades_per_day:
            return False, "massimo operazioni giornaliere"
        if open_positions >= self.max_open_positions:
            return False, "posizioni aperte al massimo"
        if spread_pips > self.max_spread_pips:
            return False, "spread anomalo"
        if not (self.allowed_hours[0] <= now.hour < self.allowed_hours[1]):
            return False, "fuori dalla finestra oraria"
        return True, "ok"

Ogni ordine passa da can_trade: se restituisce False, non si invia nulla e si scrive il motivo nel log.

Un esempio di invio ordine con MetaTrader 5 (solo schema, su demo)

MetaTrader 5 ha una libreria Python ufficiale (pacchetto MetaTrader5, su Windows). Uno schema dell'invio di un ordine con stop e take profit:

import MetaTrader5 as mt5

def open_long(symbol, lots, sl, tp, magic=20260101):
    if not mt5.initialize():
        raise RuntimeError("MT5 non inizializzato")
    tick = mt5.symbol_info_tick(symbol)
    request = {
        "action": mt5.TRADE_ACTION_DEAL,
        "symbol": symbol,
        "volume": lots,
        "type": mt5.ORDER_TYPE_BUY,
        "price": tick.ask,
        "sl": sl,
        "tp": tp,
        "deviation": 10,                 # slippage massimo tollerato (in punti)
        "magic": magic,                  # identifica gli ordini del tuo algoritmo
        "comment": "algo-demo",
        "type_time": mt5.ORDER_TIME_GTC,
        "type_filling": mt5.ORDER_FILLING_IOC,
    }
    result = mt5.order_send(request)
    ok = result is not None and result.retcode == mt5.TRADE_RETCODE_DONE
    return ok, result

Punti fondamentali: stop e take profit inviati insieme all'ordine, un magic number per riconoscere le tue posizioni, un limite di slippage (deviation), il controllo del retcode e mai un ordine senza passare dal risk guard. I dettagli (modalità di riempimento, simboli, decimali) dipendono dal broker: leggi la documentazione ufficiale e prova in demo.

I sistemi di sicurezza indispensabili

• Stop loss su ogni posizione, inviato al broker insieme all'ordine (non gestito "dal programma").
• Limite di perdita giornaliero e settimanale che spegne l'algoritmo.
• Numero massimo di posizioni e size massima (un valore "hard" nel codice: se il calcolo produce un volume enorme per un bug, viene tagliato).
• Filtro di spread e filtro orario.
• Kill switch manuale facile da usare (per esempio un file "STOP" che il programma controlla ogni ciclo).
• Controllo delle posizioni aperte all'avvio: evita di aprirne di duplicate dopo un riavvio.
• Log completo di ogni decisione e ordine, con data e ora UTC.
• Nessun "martingala" né aumenti automatici della size dopo le perdite.

Monitoraggio: come accorgersi che qualcosa non va

Confronta con regolarità le statistiche reali con quelle del backtest:

• Win rate, R medio delle vincite e delle perdite, aspettativa.
• Slippage medio e spread effettivo pagato.
• Numero di segnali attesi vs. avvenuti.
• Drawdown reale vs. distribuzione del Monte Carlo.

Se dopo un campione significativo (per esempio 50-100 operazioni) le statistiche reali sono molto peggiori dell'intervallo atteso, ferma l'algoritmo e indaga: il mercato potrebbe essere cambiato, il test era ottimista o c'è un errore di esecuzione. Regola: prima di rischiare di più, verifica che il reale confermi il test.

Cosa può andare storto (e come prepararti)

Per far girare l'algoritmo senza interruzioni molti usano un server privato virtuale (VPS), ma questo aggiunge costi e superficie di errore: valuta se serve davvero.

Conclusione del corso

Hai percorso un intero cammino: struttura di mercato, liquidità, aree, timing, modello operativo, gestione, piano, validazione statistica, valutazione critica delle prove e automazione. La competenza vera non è conoscere i termini: è saper misurare se un'idea ha un vantaggio, gestire il rischio quando non ce l'ha e restare onesti con i propri dati. Procedi piano, con capitale che puoi permetterti di perdere, tieni sempre un diario dei risultati e ricorda che la migliore protezione è la prudenza.

Torna quando vuoi alla community per condividere i tuoi test, agli strumenti per calcolare rischio e dimensione e alle analisi di mercato per allenare la lettura del contesto.

In sintesi

• Dal backtest al reale: paper trading, live con size minima, crescita graduale.
• L'esecuzione richiede risk guard indipendente, stop e TP presso il broker, log e kill switch.
• Prova ogni pezzo di codice su demo e rendi impossibile aprire posizioni fuori dalle regole.
• Monitora le statistiche reali rispetto al test e fermati se si allontanano in modo significativo.
• Prevedi gli scenari di guasto e la prudenza come prima regola.

Esercizio pratico

1. Scrivi le regole del tuo risk guard (perdita giornaliera, numero operazioni, spread massimo, orari).
2. Testa la classe RiskGuard con casi costruiti a mano (perdita massima raggiunta, spread alto, fuori orario).
3. Prepara un piano di paper trading di almeno un mese con soglie di stop dell'algoritmo se le statistiche divergono dal test.