Automazione del trading: EA, script MQL, cBot e VPS

L'automazione trasferisce le attività ripetitive a un programma, ma la responsabilità del suo comportamento resta tua. Un Expert Advisor o cBot richiede un ambiente di esecuzione definito: un terminale, un VPS o un servizio cloud. Spieghiamo le differenze, la diagnosi degli errori e la protezione del conto dopo una disconnessione o un riavvio. L'articolo tratta anche costi di hosting, latenza di esecuzione e controlli necessari prima di eseguire un programma su un conto che opera con margine.

1. Dove viene realmente eseguito un robot: EA, terminale e server del broker

Un equivoco ricorrente nell'automazione al dettaglio è «il mio robot opera presso il broker». Non è così. Un Expert Advisor su MetaTrader è un programma compilato eseguito nel processo del terminale. Il terminale riceve il flusso di quotazioni dal server del broker, esegue il codice del robot agli eventi successivi e invia richieste di trading già pronte. Il broker le convalida e le esegue o rifiuta. Tutto ciò che il robot «sa» e «ricorda» risiede nell'ambiente di esecuzione.

La catena da tenere presente durante ogni analisi dei guasti è questa:

Codice EA → terminale (ambiente di esecuzione) → server del broker → convalida dell'ordine → esecuzione o rifiuto → risposta del server → registro e stato dell'EA

Ogni anello può guastarsi autonomamente e in modo diverso. Un errore logico riguarda il primo. Chiudere il terminale ferma la logica locale e le nuove richieste; il broker continua a gestire gli ordini già memorizzati sul proprio server. Un ordine rifiutato riguarda il quarto anello, anche se appare come «l'EA non ha aperto una posizione». L'infrastruttura reale del broker e del fornitore di hosting è molto più complessa: questa catena è un modello di lavoro, non un diagramma di rete.

Gli eventi a cui reagisce il codice. Su MT4 e MT5 un programma di trading è guidato dagli eventi. OnInit() viene eseguito all'avvio: qui vanno convalidati i parametri di ingresso e preparato lo stato. OnTick() si attiva alla quotazione successiva dello strumento a cui è associato il robot. OnDeinit() viene eseguito quando il programma viene rimosso dal grafico, cambiano i parametri o si chiude il terminale. OnTimer() per azioni periodiche e OnChartEvent() per interagire con il grafico esistono in entrambi i linguaggi: la documentazione MQL4 elenca entrambe le funzioni con le firme complete, insieme a OnInit(), OnTick() e OnDeinit() [10]. La differenza tra gli ambienti si trova nel livello di trading: MT5 aggiunge eventi del tutto assenti in MQL4: OnTrade() e OnTradeTransaction() per reagire ai cambiamenti dello stato del conto [14]. Separatamente, al di fuori del livello di trading, MT5 dispone anche di OnBookEvent() — un evento sui dati di mercato che la documentazione descrive come gestione dei cambiamenti nella profondità di mercato, cioè nel book degli ordini [14]. Funziona soltanto dove viene effettivamente fornita la profondità di mercato: la disponibilità del book dipende da strumento e broker, e sui conti forex al dettaglio spesso manca del tutto. Non è un corso di programmazione, ma il minimo per capire quando il tuo codice abbia la possibilità di agire.

La conseguenza pratica è scomoda: OnTick() non è un orologio. Il numero di chiamate dipende dalle quotazioni in arrivo e dall'elaborazione della coda degli eventi. In MQL5 non viene aggiunto un nuovo evento NewTick se uno è già in coda o in elaborazione[25]. Due broker possono fornire numeri di tick sensibilmente diversi sulla stessa coppia, perché filtrano diversamente il flusso e usano fonti di liquidità differenti. Una logica che presume una frequenza di chiamate «più o meno costante» dipende in realtà dal broker e dal tipo di conto e si trasferisce tra broker peggio di quanto suggerisca il codice identico.

Che cosa resta quando il terminale si spegne

Questa distinzione salva i conti ed è al tempo stesso quella in cui ricompare la falsa semplificazione «su MT4 tutto è sul client».

I livelli di stop loss e take profit associati a una posizione o a un ordine pendente sono memorizzati sul server del broker e funzionano indipendentemente dal terminale. Il trailing stop integrato nell'interfaccia MetaTrader funziona al contrario: viene calcolato localmente sulle quotazioni in arrivo e smette di spostare lo stop quando la piattaforma viene chiusa. Vale sia per MT4 sia per MT5, ma ciascuna piattaforma ha una fonte distinta: la guida di MetaTrader 4 lo descrive come un meccanismo eseguito nel terminale client, non sul server, che smette di funzionare quando il terminale viene spento [8], mentre la guida di MetaTrader 5 ribadisce la stessa regola: il trailing stop viene eseguito nella piattaforma, non sul server come lo stop loss [11]. Sono necessarie due precisazioni, altrimenti l'affermazione diventa falsa. Primo: chiudere il terminale ferma lo spostamento del livello, ma non annulla l'ultima modifica che è riuscito a inviare; questa rimane sul server e continua a proteggere la posizione. Secondo: la descrizione non va estesa a tutte le piattaforme. In cTrader il meccanismo è diverso: la guida del fornitore afferma che tutte le protezioni funzionano nelle varie app e restano attive dopo la fine della sessione [22], e la pagina del pannello Trade Watch precisa espressamente che il trailing stop loss funziona anche quando l'app cTrader è chiusa o disconnessa [23]. La condizione viene quindi mantenuta fuori dall'app dell'utente, che non deve restare in esecuzione. Lo stesso nome indica due modelli operativi diversi: proprio per questo le abitudini non vanno trasferite da una piattaforma all'altra. Il confine tra ordine sul server e funzione locale è spiegato più ampiamente nel seguente articolo 11.4 [situazione al 2026-08-22; verifica le funzioni offerte dal tuo specifico broker nella sua documentazione].

Il terzo caso è pericoloso e ricorre nel codice amatoriale: uno stop loss «virtuale» conservato soltanto in una variabile dell'EA. Per il broker non esiste. Se il processo del terminale si interrompe, la posizione resta senza protezioni oltre ai meccanismi del conto. Prima di presumere di avere uno stop loss, controlla nella finestra delle posizioni che il livello sia visibile sul server, non soltanto nel grafico o nel registro del robot. Livelli consentiti e distanze minime di SL e TP dipendono dalle specifiche dello strumento presso il singolo broker: lo stesso codice può quindi essere accettato su un conto e rifiutato su un altro.

Automazione completa e parziale

Un robot non deve decidere l'ingresso per essere utile. L'automazione parziale —spostare lo stop a break-even, gestire la dimensione della posizione o chiudere parte del volume a un livello definito— copre proprio il frammento del processo eseguito in modo incoerente a mano. Il codice è più breve, le possibilità di errore minori e la diagnosi più semplice. L'automazione completa dal segnale all'esecuzione comporta un ordine di responsabilità del tutto diverso.

Entrambe le varianti hanno però lo stesso prerequisito: le regole devono essere esprimibili senza ambiguità. Se ingresso, uscita e rischio richiedono di giudicare la «qualità» di una configurazione, non hai un sistema da automatizzare, ma un'opinione sul mercato. Un sistema automatico eseguirà una specifica difettosa con la stessa costanza di una buona, soltanto più rapidamente e senza pause. Se le regole abbiano un valore atteso positivo è argomento del materiale su vantaggio e valore atteso; qui ci occupiamo soltanto di eseguire tale specifica in sicurezza.

2. Indicatore, script, EA e cBot: quattro classi diverse di strumenti

La richiesta «cerco uno script che faccia trading per me» ricorre spesso e di solito significa qualcosa di diverso da come suona. Uno script su MetaTrader ha effettivamente accesso alle funzioni di trading e può inviare molte operazioni in una sola esecuzione: «uno script che fa trading» non è di per sé una contraddizione. Il problema è altrove: uno script ha un solo punto di ingresso, OnStart(), e termina insieme a quella funzione: non può quindi sorvegliare il mercato per una settimana. I tre tipi di programma MetaTrader differiscono per ciclo di vita e ambito di accesso; in cTrader la suddivisione è diversa.

Separare gli accessi è un vantaggio, ma la garanzia che ne deriva è più limitata di quanto si dica di solito. Un indicatore non accede alle funzioni di trading e non invierà un ordine da solo: è tutto ciò che se ne può dedurre. Non significa che un suo errore sia innocuo: se un EA legge il buffer e decide su quella base, un valore sbagliato diventa un'operazione errata inviata dall'EA. L'architettura corretta resta la stessa: l'indicatore calcola ed espone il risultato in un buffer, l'EA lo legge e decide. Analisi ed esecuzione sono così separate e verificabili autonomamente, purché si provi anche il contenuto del buffer, non soltanto la logica dell'EA.

In cTrader la suddivisione è diversa e non corrisponde uno a uno. L'equivalente di un EA è un cBot, quello di un indicatore è un indicatore. Non esiste una categoria separata «script»: un'operazione una tantum viene eseguita da un cBot che lavora nel metodo di avvio e si arresta da solo.

Tre errori che costano tempo:

• Aspettarsi che un indicatore faccia trading. Un indicatore su MetaTrader non ha accesso alle funzioni di trading. Un prodotto pubblicizzato come «indicatore che opera da solo» non è un indicatore oppure usa un programma separato in background: è il codice di quel programma a essere responsabile dei tuoi ordini
• Un EA dove basterebbe uno script. Chiudere tutte le posizioni in una sola esecuzione è un compito da script. Un EA collegato al grafico continuerà a vivere, reagire alle nuove quotazioni e richiedere supervisione
• Un monolite invece di moduli. Un programma che esegue cinque strategie, sorveglia il rischio del conto, disegna e invia notifiche contemporaneamente è più difficile da diagnosticare. Un sistema automatico per strategia e un supervisore del rischio separato permettono di spegnere l'insieme per parti

Prima di scrivere un robot, scrivi uno script informativo. Non perché sia un esercizio da principianti, ma perché un programma privo intenzionalmente di qualsiasi chiamata di trading permette di verificare se leggi correttamente i dati dell'ambiente: simbolo, quotazioni, costo e fondi disponibili. Se le letture sono sbagliate, il robot vi baserà ogni decisione.

Quello che segue non è un programma da compilare, ma uno schema strutturale: ordine dei controlli e nomi delle funzioni MQL4 da usare nella tua implementazione. Non incollarlo ed eseguirlo come un file pronto. Non è stato validato né compilando né provandolo su un conto di broker. La compilazione controlla la sintassi, ma da sola non conferma letture, permessi o comportamento nell'ambiente scelto. Conserva la sequenza, scrivi un'implementazione completa e verifica i risultati su un conto demo; il resoconto della prova permette di valutarne il comportamento.

SCHEMA STRUTTURALE – diagnosi dell'ambiente prima di scrivere un robot
Notazione orientativa per MQL4. Non è codice completo e compilabile.

punto di ingresso: OnStart() – una tantum, termina con la funzione

1. symbol   := Symbol()
   Non fissare il nome nel codice: il suffisso del broker lo modifica.

2. bid, ask := MarketInfo(symbol, MODE_BID / MODE_ASK)
   point    := MarketInfo(symbol, MODE_POINT)
   spread   := if point > 0 then (ask - bid) / point
               altrimenti: lettura non risolta
   Un punto zero indica una lettura fallita delle specifiche, non
   uno spread zero: i due casi richiedono registrazioni diverse.

3. lotMin   := MarketInfo(symbol, MODE_MINLOT)
   lotStep  := MarketInfo(symbol, MODE_LOTSTEP)
   Proprietà dello strumento presso quel broker, non costanti del linguaggio.

4. nel diario: symbol, bid, spread, lotMin, lotStep,
   OrdersTotal(), AccountFreeMargin()

5. tradePossible := IsTradeAllowed()
   Etichetta nel registro: trading possibile in questo momento.
   Non: trading automatico autorizzato; vedi il paragrafo seguente.

Ciò che questo schema non contiene e non deve contenere:
   nessuna chiamata a OrderSend, OrderClose o OrderModify.

Tre elementi dello schema ricompaiono in ogni robot successivo: nome del simbolo letto dall'ambiente anziché fissato nel codice, passo del volume letto dalle specifiche e controllo esplicito della possibilità di operare in quel momento. L'ultimo punto richiede di correggere una semplificazione diffusa. IsTradeAllowed() non risponde soltanto alla domanda sul consenso all'automazione: la documentazione MQL4 lo descrive come un controllo che l'Expert Advisor sia autorizzato a operare e il contesto di trading non sia occupato [15]. Un risultato false può significare mancanza di permesso oppure contesto occupato, cioè uno stato transitorio che passerà da solo. Registra separatamente il risultato della funzione e la causa accertata con un controllo aggiuntivo; altrimenti la diagnosi «trading disabilitato» riguarderà qualcosa che non è affatto disabilitato. La sezione sui guasti in produzione riprende tutte e tre le letture.

3. MQL4 e MQL5: due ambienti, non due versioni di uno solo

La semplificazione «MQL5 è MQL4 con più funzioni» è falsa proprio dove conta in pratica: nel modello di ordini e posizioni. Va eliminato subito anche un altro mito: MQL4 non è puramente procedurale; la documentazione MetaQuotes ne descrive classi, ereditarietà, funzioni virtuali e template [1]. La differenza non sta quindi nel paradigma di programmazione, ma nell'interfaccia di trading, nella lettura degli indicatori e nel modo in cui la piattaforma rappresenta l'esposizione aperta.

Il livello di trading. In MQL4 una sola funzione, OrderSend(), apre una posizione, mentre OrderSelect() sposta il contesto sull'elemento successivo di un elenco che contiene insieme ordini pendenti e posizioni aperte. In MQL5 i concetti sono separati: ordine, posizione ed eseguito storico sono distinti. Inviare una richiesta significa compilare una struttura e controllare quella restituita con il codice di risposta del server; le classi della libreria standard come CTrade sono un comodo involucro di questo meccanismo, non una modalità operativa separata [2].

Il livello dei dati. In MQL4 una chiamata all'indicatore restituisce il valore della candela specificata. In MQL5 restituisce un handle creato una volta, di solito in OnInit(); i valori vengono poi copiati in un array tramite una funzione di copia del buffer. Una riscrittura letterale crea un nuovo handle a ogni quotazione anziché riusare quello esistente. Il compilatore non lo segnala: l'errore è nel punto di creazione, non nella sintassi. È una classica trappola di migrazione proprio perché non si manifesta subito.

La riga sulla modalità di contabilizzazione merita una spiegazione perché provoca guasti inattesi. Netting significa una posizione netta per strumento: un ordine opposto non ne apre una seconda, ma riduce o inverte quella esistente. Un robot trasferito da MT4 che presuma molte posizioni indipendenti sullo stesso simbolo inizierà, in questa modalità, a chiudere i propri ingressi. La modalità è stabilita dal broker: non è il «comportamento predefinito di MT5», ma una proprietà del singolo conto da verificare prima della messa in esercizio, preferibilmente leggendola nel codice.

Quando ha senso migrare. Quando il vecchio ambiente limita davvero il lavoro: servono test multivaluta, un test forward nel tester, un modello di tick più accurato o strumenti che il broker non offre su MT4. Essere «più nuova» non basta: riscrivi il livello di trading e la lettura degli indicatori, ottenendo nuovi errori in codice che prima funzionava. Il tempo dipende dalle dimensioni del sistema; non esiste una cifra onesta valida per tutti. Se migri, confronta i risultati operazione per operazione, non il totale. Un totale uguale con un elenco di operazioni diverso significa che due logiche differenti hanno prodotto per caso un risultato simile.

MT5 offre anche ottimizzazione distribuita a pagamento nella rete di calcolo MetaQuotes. Più potenza significa però provare più combinazioni di parametri, aumentando direttamente il rischio di adattamento eccessivo al passato. La metodologia —suddivisione dei dati, costi, numero di varianti— è materia del articolo su demo, backtesting e test forward ed è trattata lì per intero.

4. cTrader Algo: C#, Python ed esecuzione locale e cloud

In questa sezione è particolarmente facile ripetere descrizioni obsolete: i materiali più vecchi chiamano l'ambiente di automazione cAlgo o cTrader Automate e lo presentano come esclusivamente C# e locale. Entrambe le affermazioni oggi sono false.

Secondo la documentazione ufficiale Spotware, l'ambiente si chiama cTrader Algo e permette di creare algoritmi in due linguaggi: C# e Python [3]. I cBot possono essere eseguiti localmente o nel cloud. La documentazione cloud precisa che il cBot opera in un ambiente isolato fornito da cTrader e che l'app dell'utente —Windows, Mac, mobile o browser— non deve restare aperta né connessa a internet [4]. Questo cambia l'intero calcolo dell'hosting discusso più avanti nell'articolo.

Limiti dell'esecuzione cloud al 2026-08-22. La documentazione indica fino a dieci istanze simultanee in funzione continua su un conto reale e una su un conto demo, che si arresta automaticamente al massimo dopo sette giorni. Precisa inoltre che le regole possono variare secondo il broker e che i cBot con pacchetti esterni funzionano nel cloud se rispettano condizioni aggiuntive [4]. Considera questi numeri come lo stato del prodotto alla data di pubblicazione e ricontrollali prima di basarvi un'architettura.

Struttura di un cBot. Il programma eredita da una classe base di robot. Il metodo di avvio corrisponde all'inizializzazione nota da MQL, la gestione della quotazione successiva corrisponde a OnTick(), e il metodo di arresto alla deinizializzazione. Una differenza utile è la gestione nativa dell'evento di chiusura della barra: in MetaTrader devi rilevarlo confrontando l'ora di apertura della candela attuale con quella memorizzata.

Open API non è REST. Va precisato perché nelle fonti secondarie circola la semplificazione «cTrader ha un'API REST». La documentazione Spotware descrive lo scambio dati di Open API tramite oggetti JSON o Google Protocol Buffers [5]. FIX API è un servizio separato. Permessi, disponibilità e condizioni di connessione dipendono dal broker: progetta quindi l'integrazione dopo aver letto la documentazione del fornitore specifico, non la descrizione generale della piattaforma.

Scegliere un ambiente non significa scegliere «la piattaforma migliore». Se il broker ne offre uno solo, la decisione è già presa. Se li offre entrambi, il criterio è pratico: in quale sai scrivere e mantenere codice di cui comprendi il comportamento e come vuoi risolvere la continuità operativa. Il linguaggio da solo non crea un vantaggio: cambia i costi di manutenzione e il numero di errori che commetterai.

Un webhook come ponte verso altri sistemi

Il secondo percorso di automazione non passa dal codice eseguito nella piattaforma: un evento esterno, per esempio un avviso da una piattaforma grafica, invia una richiesta HTTP a un indirizzo concordato e un'applicazione intermedia la trasforma in una chiamata all'API del broker. La catena diventa evento → webhook → applicazione intermedia → API del broker → convalida → ordine → risposta del server, e il webhook copre un solo anello: l'invio della richiesta. Consegna non significa esecuzione: riceverlo correttamente non dice se il volume rispettasse le specifiche, ci fosse margine libero o il server avesse accettato l'ordine. Ogni passaggio intermedio aggiunge latenza e modalità di guasto proprie, compresa la ripetizione della richiesta dopo una riconnessione. L'indirizzo del webhook va protetto, ma conoscerlo non deve sostituire l'autorizzazione: l'intermediario deve verificare mittente, freschezza della richiesta e identificatore univoco. La configurazione degli avvisi sulla piattaforma grafica è trattata in un articolo separato; qui conta soltanto dove si colloca questo ponte nella catena e che cosa non garantisce.

5. Permessi, compilazione, registri e identificazione delle proprie posizioni

«Il robot non opera» è una segnalazione tipica nell'automazione al dettaglio e può non riguardare la strategia. Prima di correggere le condizioni di ingresso, verifica quattro cose: che il programma sia compilato, associato al grafico giusto, autorizzato al trading automatico a ogni livello e che cosa abbia registrato esattamente il diario.

Compilazione e posizione dei file

Il sorgente in MetaEditor ha un'estensione testuale, ma sul grafico viene caricato un file compilato. I file devono stare nella cartella dati della piattaforma, nella sottocartella del tipo di programma, altrimenti non saranno visibili. Apri la cartella dati dal menu: di solito non coincide con quella di installazione, quindi non darlo per scontato. Dopo la copia aggiorna l'elenco nel navigatore. Leggi gli avvisi del compilatore: una conversione implicita di tipo nel codice di trading può troncare un volume a zero.

Tre livelli di consenso al trading automatico

Il consenso al trading automatico non è un unico interruttore. Il primo livello è l'impostazione globale della piattaforma: il pulsante di trading algoritmico sulla barra. Il secondo sono le proprietà del programma quando lo aggiungi al grafico. Il terzo è fuori dal tuo controllo: il conto. Il broker può vietare l'automazione su un tipo di conto o limitare del tutto il trading, per esempio su un conto di sola lettura. Un robot che non verifichi queste condizioni segnalerà soltanto un ordine fallito senza indicarne la causa.

Segue un altro schema strutturale, non un file da compilare, stavolta per MQL5. Mostra la sequenza di controlli dei permessi e normalizzazione del volume, ma non è un'implementazione validata. La compilazione da sola non stabilisce il comportamento su un conto specifico: verifica anche risposte del terminale, proprietà del simbolo e permessi mentre sei connesso al broker. L'articolo non presenta tale prova. Usa lo schema come base dei tuoi controlli, non come modulo pronto per il trading. Non contiene chiamate che inviino ordini.

SCHEMA STRUTTURALE – permessi e normalizzazione del volume
Notazione orientativa per MQL5. Non è codice completo e compilabile.

A. IL TRADING È CONSENTITO? Quattro letture, ciascuna con il suo registro

   TerminalInfoInteger(TERMINAL_TRADE_ALLOWED)
      false -> trading algoritmico disabilitato nella piattaforma
   MQLInfoInteger(MQL_TRADE_ALLOWED)
      false -> trading disabilitato nelle proprietà del programma
   AccountInfoInteger(ACCOUNT_TRADE_ALLOWED)
      false -> trading bloccato sul conto
   AccountInfoInteger(ACCOUNT_TRADE_EXPERT)
      false -> il broker non consente qui trading automatico

   Il trading è consentito solo se tutte e quattro le letture sono true.
   Il registro deve indicare quale sia fallita; altrimenti
   la diagnosi finisce con «il robot non opera».

B. NORMALIZZARE IL VOLUME ALLA GRIGLIA DEL PASSO

   ingresso: symbol, vol
   uscita: multiplo del passo oppure 0.0 per «non inviare»

   B1. if not MathIsValidNumber(vol) or vol <= 0.0
          -> registrare l'errore e restituire 0.0
       I normali confronti non rifiutano NaN in modo affidabile.
       Verifica esplicitamente che l'ingresso sia finito prima
       del calcolo; altrimenti il risultato può restare non valido.

   B2. leggere le specifiche con la variante che restituisce lo stato:
          SymbolInfoDouble(symbol, SYMBOL_VOLUME_MIN,  vmin)
          SymbolInfoDouble(symbol, SYMBOL_VOLUME_MAX,  vmax)
          SymbolInfoDouble(symbol, SYMBOL_VOLUME_STEP, vstep)
       una lettura false oppure vstep <= 0.0
          -> registrare _LastError e restituire 0.0
       La variante che restituisce solo un numero tace sull'errore
       e restituisce uno zero indistinguibile da uno zero reale.

   B3. TOL   := 1e-8            tolleranza della divisione binaria
       steps := MathFloor(vol / vstep + TOL)
       result := NormalizeDouble(steps * vstep, 8)

       La postcondizione promessa, e soltanto questa:
         il risultato è un multiplo intero del passo;
         non supera l'ingresso di oltre
         TOL * vstep.
       Non promette che non superi mai l'ingresso.

   B4. if result > vmax
          -> result := NormalizeDouble(MathFloor(vmax / vstep + TOL) * vstep, 8)
       if result < vmin
          -> restituire 0.0
       L'ordine conta: minimo e massimo sono controllati solo
       su un valore già allineato alla griglia del passo.

Questa seconda funzione sembra un dettaglio, ma riguarda un'intera classe di rifiuti. Passo, minimo e massimo del volume sono proprietà dello strumento presso il singolo broker e differiscono tra conti. La dimensione calcolata dal rischio quasi mai coincide esattamente con il passo consentito: il server rifiuta un volume non valido anziché arrotondarlo per te.

Due dettagli meritano una spiegazione: appartengono entrambi alla classe di errori descritta parlando degli avvisi del compilatore, quando il codice funziona ma il risultato differisce silenziosamente dal calcolo. Primo: il volume si ottiene contando passi interi e moltiplicandoli per il passo, non arrotondando a un numero fisso di decimali. Due decimali trasformerebbero 0,003 in zero con un passo di 0,001, presente sui conti cent e su alcuni CFD. Ricavare i decimali dal logaritmo del passo fallisce se questo non è una potenza di dieci: con passo 0,25, un volume di 1,75 diventa 1,8, che non è un multiplo del passo; il server lo rifiuta come un volume mai normalizzato. Secondo: la divisione in virgola mobile può finire appena sotto un intero. Senza una piccola correzione, l'arrotondamento per difetto sottrae silenziosamente un passo: 0,3 diviso 0,1 risulta sotto tre e la posizione è più piccola di quanto previsto dal rischio. Minimo e massimo vanno quindi controllati solo alla fine sul valore già allineato alla griglia: arrotondare per difetto può violare un minimo prima rispettato e anche il taglio al massimo deve restare sulla stessa griglia.

Quella correzione ha però un altro lato, da dichiarare senza promettere più di quanto la funzione mantenga. Aggiungendo qualcosa prima di arrotondare per difetto, il risultato può superare minimamente l'ingresso: con volume 0,2999999995 e passo 0,1 restituisce 0,3, cioè cinque decimiliardesimi di lotto in più. Per i passi dell'esempio la differenza è trascurabile, ma la garanzia corretta è questa: il risultato è multiplo del passo e non supera l'ingresso oltre la tolleranza accettata. È un limite deliberato, perché senza di esso lo stesso codice perde un intero passo con 0,3. Due casi facili da dimenticare vanno bloccati separatamente: un ingresso non finito, che i normali confronti non rifiutano in modo affidabile, e una lettura fallita delle specifiche. Per questo lo schema contiene MathIsValidNumber() all'ingresso e la variante di SymbolInfoDouble() che restituisce uno stato invece di un solo numero; quest'ultima, in caso di errore, restituisce uno zero indistinguibile da uno zero reale.

Registri: traccia diagnostica di base dopo un guasto

La piattaforma mantiene diari separati, utilmente: quello del programma contiene le stampe del codice e i messaggi di inizializzazione e rimozione; quello della piattaforma registra accessi, disconnessioni, riconnessioni, richieste e risposte del server. Il tester ha un diario proprio. Le copie salvate nella cartella dati sopravvivono al riavvio: solo così si può ricostruire un guasto notturno.

Il robot dovrebbe registrare almeno momento della decisione con prezzo e spread, parametri inviati, codice di risposta del server, prezzo effettivo di esecuzione, ogni modifica dei livelli e ogni attivazione di una protezione. Senza prezzo e codice di risposta non distingui un errore logico da un rifiuto del broker: sono problemi del tutto diversi.

Va chiarita subito una distinzione che ritorna nei guasti. Il diario è la traccia diagnostica di base: dice che cosa il programma ha fatto e visto in un dato momento. La fonte di verità sull'esecuzione è però lo stato del conto e la cronologia sul server del broker. La distinzione smette di essere accademica proprio quando serve: con una connessione interrotta, il registro può terminare con un errore di invio mentre il server ha già eseguito l'operazione. Se si contraddicono, fa fede il server.

Identificare le proprie posizioni

Il robot deve saper rispondere «questa posizione è mia?». Sul conto possono coesistere operazioni manuali, di un altro robot e della stessa strategia su un simbolo diverso. Servono un identificatore numerico assegnato all'invio dell'ordine —chiamato magic number in entrambi gli ambienti MetaTrader— e il campo commento. La regola pratica è semplice: ogni ciclo sulle posizioni filtra insieme per identificatore e simbolo, mai soltanto per simbolo.

Saltare il filtro costa caro: il robot chiuderà posizioni manuali e due robot con lo stesso identificatore modificheranno reciprocamente i livelli. Su un conto netting è più difficile, perché una posizione netta non ha un solo proprietario: il robot deve registrare autonomamente l'esposizione che si attribuisce e ricostruirla dopo il riavvio dalla cronologia, non dallo stato attuale.

6. Catalogo dei guasti in produzione: dalle riconnessioni alle modifiche delle specifiche del simbolo

Alcuni guasti dell'automazione riguardano l'ambiente di esecuzione, non le regole della strategia. Un backtest standard non riproduce ogni situazione; alcune richiedono prove di guasto separate. L'elenco non raccoglie stranezze, ma situazioni da prevedere quando tieni un robot attivo per mesi.

Scenario da riprodurre: ordine duplicato dopo una riconnessione

Lo descriviamo separatamente perché non si può provocare a richiesta con un solo clic. La redazione non lo ha riprodotto: quanto segue non contiene risultati di misurazione né un resoconto dell'ambiente in cui si sarebbe misurato. Presenta il meccanismo e le istruzioni per verificarlo autonomamente.

Condizioni. Il robot rileva una condizione di ingresso e chiede di aprire una posizione. Mentre attende la risposta, la connessione cade. L'ordine è arrivato al server ed è stato eseguito, ma la risposta non torna al terminale. Il robot registra un errore e conclude che non esiste una posizione.

Conseguenza prevista. Se la condizione resta valida alla riconnessione, il robot invia di nuovo la richiesta. Su un conto hedging nascono due posizioni invece di una e il rischio effettivo è doppio rispetto al previsto. Su un conto netting i registri sono diversi, ma l'esposizione aumenta comunque: cresce la posizione netta, che il robot vede ancora come un unico ingresso. È una conclusione dedotta dal meccanismo descritto, non una misura ottenuta da una prova effettuata.

Come verificarlo autonomamente. Disattivare a mano la scheda di rete «subito dopo l'invio» non è una procedura, ma una lotteria. Non controlli se la richiesta sia arrivata al server; se non è arrivata, riproduci un altro caso: un normale ordine fallito. Su demo, una regola del firewall o uno strumento diagnostico può interrompere la connessione in modo controllato, ma confermare l'invio non dimostra l'esecuzione. Lo scenario si verifica solo se la cronologia del server conferma l'esecuzione mentre il terminale non ha ricevuto la risposta. Il tester non può riprodurlo: la prova è manuale e proprio per questo va documentata. Annota tutti gli elementi seguenti: senza anche uno solo, il risultato non chiarisce nulla e non è confrontabile con una seconda prova:

• piattaforma, versione del terminale e numero di build, letti nella finestra informativa, non a memoria
• broker, numero del conto demo, server connesso e tipo di conto —hedging o netting—, perché la conseguenza dipende da questo
• simbolo con suffisso completo del broker, volume richiesto e modalità di esecuzione dello strumento
• data e ora della prova nell'ora del server del broker, non locale
• come è stata interrotta la connessione e quando ha avuto effetto rispetto all'invio: è l'unico parametro che decide se riproduci questo caso o uno diverso
• risultato: voce completa del diario del robot confrontata con la cronologia sul server. È questa a stabilire se l'ordine sia arrivato; il diario del terminale non basta, perché proprio la sua mancata conoscenza è il fenomeno studiato
• numero di ripetizioni e quante hanno dato lo stesso risultato; un solo passaggio non dimostra nulla

Va corretta un'altra ricetta ripetuta: il magic number identifica una strategia, non una singola intenzione d'ordine. Due richieste dello stesso robot hanno lo stesso numero, che da solo non risponde a «questo specifico ordine è già partito?». Serve un identificatore persistente della singola decisione, assegnato e registrato prima dell'invio e conservato fuori dalla memoria del processo. Solo così, riconciliando gli stati, distingui «non l'ho inviato» da «l'ho inviato e non so che cosa sia successo». Il commento è un posto naturale per trasportarlo nell'ordine, ma il server può troncarlo o sovrascriverlo: usalo come indizio e risolvi confrontando i tuoi registri con la cronologia del server.

La protezione. La regola è semplice e scomoda: fa fede lo stato del conto, non la memoria del robot. Dopo ogni richiesta fallita o con esito non confermato, prima di riprovare il programma deve leggere posizioni attuali e operazioni storiche più recenti, filtrare per identificatore proprio e verificare se l'ordine sia già presente. Un blocco temporale tra invii sullo stesso simbolo è un'aggiunta economica, ma da sola non basta.

Lo stesso principio evita un'altra classe di incidenti: un robot senza controllo dell'esposizione invia richieste a ogni chiamata in un mercato rapido. Ne segue una valanga di ordini e, nei casi estremi, una restrizione dell'accesso al server da parte del broker. Controllare lo stato prima dell'invio e limitare le operazioni per unità di tempo sono condizioni senza le quali il robot non deve uscire dal demo.

7. Continuità operativa: computer, VPS, hosting della piattaforma e calcolo dei costi

Un sistema classico su MetaTrader richiede un terminale attivo. È l'unico motivo per parlare di hosting: non velocità né «professionalità», ma il fatto che un processo spento non calcola nulla. L'eccezione è il percorso cloud di cTrader Algo: un cBot che ne rispetti le condizioni può non aver bisogno di alcun VPS esterno. La precisazione conta perché lo stesso ecosistema permette anche l'esecuzione locale e allora torna l'intera questione dell'hosting. I limiti delle istanze dipendono da conto e broker e i pacchetti esterni funzionano nel cloud solo con condizioni aggiuntive.

Che cosa introduce un computer domestico nell'equazione. Interruzioni di corrente, riavvii dopo aggiornamenti, guasti della linea internet, blocchi del sistema: ciascun evento interrompe l'ambiente e tutta la logica del robot. Non interrompe i livelli SL e TP registrati sul server del broker. È il confine da conoscere per valutare quanto perdi davvero durante un'interruzione.

Che cosa non fa un VPS. Non migliora la strategia né elimina slippage o rifiuti. Non protegge dai guasti del broker né dalla caduta della sua linea verso il fornitore di liquidità. Non garantisce continuità: una disponibilità dichiarata è un impegno contrattuale, non una legge fisica. Compri una cosa: togliere hardware e connessione personali dall'elenco delle cause di guasto.

Due prodotti diversi sotto un solo nome

La parola «VPS» indica due soluzioni amministrate in modi completamente diversi.

Un server virtuale con un sistema operativo completo si affitta come un normale computer in un centro dati. Ti colleghi con desktop remoto, installi la piattaforma e gestisci aggiornamenti, avvio automatico, monitoraggio e backup della configurazione. Hai piena libertà di usare più piattaforme, script di supervisione e strumenti diagnostici, e piena responsabilità della manutenzione, compresa la sicurezza dell'accesso remoto.

L'hosting integrato nella piattaforma funziona diversamente. MetaTrader VPS si avvia dalla piattaforma e l'ambiente viene migrato con un solo comando. Ospita sistemi automatici attivi e abbonamenti alla copia di segnali senza richiedere l'amministrazione di Windows o l'accesso con desktop remoto [6]. La semplicità ha un prezzo: non puoi installare software arbitrario e lavori entro risorse prestabilite.

Calcolo dell'infrastruttura su un esempio esplicito

Uso i prezzi precedenti per rendere l'esempio verificabile, non solo illustrativo. Con pagamento annuale il costo è 12 × 10 USD = 120 USD all'anno. Con pagamento mensile: 12 × 15 USD = 180 USD all'anno.

Limito la conclusione a questo esempio. Su un conto dell'ordine di 2.000 USD, il solo hosting consuma diversi punti percentuali di capitale l'anno prima di spread e commissioni e compete con un risultato realisticamente atteso. Su un conto dieci volte più grande rappresenta un decimo di quella percentuale. Non ne segue che un VPS «convenga» o no a chiunque altro: il costo dell'infrastruttura va calcolato rispetto al proprio capitale, non al prezzo sulla pagina del fornitore.

Scelta dei parametri e messa in esercizio

Un robot che fa solo trading richiede poche risorse; il carico viene dall'ottimizzazione nel tester, che può avvenire altrove. La precisazione sulla tabella conta più del contenuto: sono valori illustrativi, non misurazioni di questo articolo né requisiti del fornitore; mostrano solo che cosa verificare. Misura tu: esegui la configurazione prevista per alcuni giorni su demo, leggi nel gestore attività i picchi di memoria e processore del processo della piattaforma e solo dopo scegli la macchina su quella base.

Il mercato si divide in tre categorie, diverse per chi sostiene il costo della manutenzione, non per il prezzo. L'hosting del broker può avere condizioni agevolate a un dato livello di attività: è comodo, ma lega a un solo broker. Gli specialisti di hosting per il trading collocano server nei centri dati usati dai broker FX. I cloud pubblici generali lasciano tutta la configurazione a te. Non faccio nomi: disponibilità, sedi e condizioni cambiano più rapidamente di un articolo e un elenco in un testo didattico diventa troppo facilmente una raccomandazione.

Lista di controllo per attivare l'hosting:

1. Esegui tutto su demo, non per un numero fisso di giorni, ma fino a tre eventi: riavvio forzato, perdita e ripristino della connessione, chiusura e riapertura del mercato nel fine settimana. Solo dopo cambia conto
2. Programma gli aggiornamenti fuori orario e verifica che cosa accade dopo un riavvio forzato
3. Configura l'avvio automatico e il ripristino dei grafici con i programmi associati
4. Verifica separatamente se il trading automatico sia attivo dopo il riavvio: l'avvio della piattaforma non lo garantisce
5. Monitora indipendentemente la disponibilità della macchina e, separatamente, il processo della piattaforma; il ping non rileva un'app bloccata
6. Disattiva spegnimento dello schermo e sospensione, configura la rotazione dei registri e controlla lo spazio libero
7. Proteggi l'accesso remoto con password forte e univoca e autenticazione a più fattori se disponibile; limita per indirizzo se possibile
8. Salva modelli dei grafici e parametri. Non conservare credenziali nei file di configurazione o nelle note: usa un gestore di password
9. Pianifica la perdita della macchina: da dove ripristinerai e in quanto tempo

L'ultimo punto viene spesso saltato. L'hosting non è una protezione finché non sai quanto impiegherai a ricostruire l'ambiente e non l'hai provato una volta con calma.

8. Latenza: che cosa misuri esattamente e che cosa non dice la misura

«Ping di 2 ms» non significa «ordine eseguito in 2 ms». Conviene leggerlo due volte, perché la vendita di infrastruttura si basa sul confondere la differenza. La latenza della catena comprende più segmenti, misurati separatamente con strumenti e precisioni diversi.

Le dichiarazioni sull'hosting riguardano quasi sempre il primo o secondo segmento. Quando MetaQuotes indica accesso da MetaTrader VPS al 96% dei server sotto 10 ms [6], descrive il segmento di rete. Non dice quanto impiegherà il broker a concludere davvero l'operazione: dipende dalla politica di esecuzione, dalla liquidità disponibile e dal carico del server in quel momento.

L'unica misura che riguarda il tuo conto viene dai tuoi dati. Registra tre timestamp e due prezzi: decisione con il prezzo visto dal robot, invio della richiesta e momento e prezzo di esecuzione letti dalla risposta del server. Dopo una serie abbastanza lunga avrai una distribuzione, non un numero della pagina di un fornitore. Guarda la distribuzione, non la media: singole esecuzioni lente durante dati o liquidità scarsa pesano più di una mediana tranquilla.

Una precisazione decide se la misura abbia senso. I primi due timestamp vengono dal tuo computer e l'ora dell'operazione nella cronologia dall'orologio del server. Sottrarli mescola due orologi e aggiunge uno scarto sconosciuto, invisibile nel numero. Misura quindi l'andata e ritorno localmente con un solo contatore ad alta risoluzione, dalla chiamata di invio al ritorno della risposta. Annota accanto il timestamp della cronologia come quantità separata, non come estremo dello stesso segmento. Senza telemetria del broker non sai quanto la richiesta sia rimasta nella sua infrastruttura: puoi misurare il totale e confrontare periodi, non dividerlo in fasi.

Per valutare la sensibilità della logica c'è il tester MetaTrader 5, che permette di emulare latenza e usare diversi modelli di tick, compresi tick reali del broker [7]. Non misura la tua connessione: verifica se la strategia sopravvive a condizioni di esecuzione peggiori. La metodologia completa è trattata nel articolo sui test delle strategie.

Quando conta davvero

La risposta viene dall'aritmetica, non dalle convinzioni. A parità di costo, il suo peso cresce al diminuire dell'operazione media. I valori sono illustrativi: ipotizzo un costo totale per operazione di 2,0 pip, composto da spread, commissione convertita in pip e slippage tipico. Il costo reale si ricava dalle specifiche del conto e dalle proprie operazioni. La latenza non entra e non può entrare nella somma: non è un costo in pip, ma un parametro del modello di esecuzione. La tabella quindi non la misura e non permette conclusioni in un senso o nell'altro.

Per un sistema che mira a diverse decine di pip, l'esempio suggerisce di verificare se la latenza influisca materialmente sui risultati prima di pagare per ridurla. Se mira a pochi pip, latenza e slippage sono un problema della strategia, non dell'hosting: nessun server lo risolverà.

Parametri di protezione da condizioni di esecuzione sfavorevoli

Due meccanismi appartengono al codice. Il primo è un filtro sullo spread: prima di ogni decisione confrontalo con una soglia e non aprire posizioni se viene superata. Definisci la soglia come multiplo dello spread tipico dello strumento nei tuoi orari, non come costante fissa: lo stesso limite non avrà senso su un altro simbolo o broker.

Il secondo viene spesso descritto come limite universale al prezzo di esecuzione, ed è proprio ciò che non è. Lo scostamento massimo consentito all'invio vale per una sola modalità. La guida MetaTrader 4 precisa che lo scostamento di prezzo all'invio viene usato soltanto in Instant Execution [18]. La stessa pagina spiega l'effetto reale del campo, inverso all'idea di «protezione dallo slippage»: se lo scostamento è inferiore o uguale al parametro, l'ordine viene eseguito al nuovo prezzo senza ulteriori avvisi; altrimenti il broker restituisce nuovi prezzi di esecuzione [18]. Una variazione entro il limite viene quindi eseguita al nuovo prezzo senza avviso; la riquotazione, con nuovi prezzi da confermare, arriva solo oltre il limite. In modalità di mercato il campo non esiste: la guida MetaTrader 5 lo descrive per Instant Execution e afferma il contrario per Market Execution. Il broker decide il prezzo senza ulteriore confronto e inviare l'ordine significa acconsentire in anticipo all'esecuzione a quel prezzo [11]. Qui il broker stabilisce il prezzo e l'invio è consenso anticipato; il modulo presenta una Fill Policy al posto dello scostamento.

Il broker stabilisce la modalità per ogni simbolo: la prima domanda non è «quale valore imposto?», ma «questo campo si applica al mio strumento?», da verificare nelle specifiche. Se si applica, scegli tra due costi: un limite stretto provoca più riquotazioni e richieste che non passano al primo tentativo; uno ampio riduce le riquotazioni ma aumenta le esecuzioni a prezzi diversi da quello visto alla decisione. Trattalo come elemento della strategia, non come impostazione tecnica. Se non si applica, resta il registro della differenza effettiva tra prezzo della decisione ed esecuzione. È utile conservarlo in entrambi i casi.

Il terzo meccanismo è temporale ed è il più semplice: una finestra senza nuove posizioni. Nel rollover giornaliero e alle pubblicazioni più importanti, lo spread aumenta e la liquidità cala. Bloccare gli ingressi richiede poche righe, purché usi l'ora del server anziché quella locale e abbia provato il filtro al cambio dell'ora.

9. Interruttore di emergenza, limiti e standard minimo di messa in esercizio

Un robot senza meccanismo di arresto ha un potenziale di perdita illimitato entro il margine disponibile. Non perché sia scritto male, ma perché manca una condizione che lo fermi. L'interruttore di emergenza non è un extra: è la condizione per parlare di un sistema gestito anziché di un programma lasciato a sé stesso.

Limiti che ogni sistema automatico su un conto reale dovrebbe avere:

1. Limite di drawdown del patrimonio. Superata una flessione prefissata dal picco del patrimonio, il robot chiude le proprie posizioni, conferma rileggendo il conto che non ne resti nessuna e solo allora si ferma; se ne resta una, deve rimanere attivo e dare l'allarme. La soglia deriva dal piano di rischio adottato: la metodologia per fissarla appartiene al materiale sul rischio; qui conta che la soglia esista nel codice e sia verificata prima della logica della strategia
2. Limite di perdita giornaliera. Contatore azzerato a un'ora del server e ricostruito dopo il riavvio dalla cronologia, non conservato solo in memoria
3. Limite al numero di posizioni aperte. Limite rigido indipendente dalla logica di ingresso
4. Limite alla dimensione di una posizione. Limite applicato al risultato del calcolo della dimensione della posizione, perché un errore aritmetico non diventi un ordine dal volume sproporzionato
5. Filtro sullo spread e, se la modalità del simbolo lo prevede, scostamento massimo di prezzo. Entrambi descritti nella sezione precedente
6. Filtro orario. Finestre senza nuove posizioni
7. Reazione ai problemi di connessione. Rilevata una disconnessione o quotazioni obsolete, il robot non apre nuove posizioni ma non chiude alla cieca quelle esistenti: farlo su un prezzo vecchio può essere peggio che attendere

L'ordine conta: le condizioni di sicurezza vanno all'inizio del gestore dell'evento, prima di ogni logica di ingresso. Se violate, il programma non deve aprire né aumentare esposizione; può solo chiudere le proprie posizioni e registrare l'evento. Riprendere richiede una decisione umana consapevole, mai una ripartenza automatica dopo un'attesa.

condizione di arresto: patrimonio attuale < picco patrimoniale × (1 − drawdown consentito) → registrare → chiudere le proprie posizioni → ricontare l'esposizione propria → rimuovere il programma solo con zero posizioni e zero errori di chiusura → altrimenti allertare e restare attivo

Segue l'ultimo schema dell'articolo, l'unico che tocca una funzione di chiusura. Ha quindi due barriere, entrambe nei valori predefiniti, non in un commento. Primo: la simulazione è attiva per impostazione predefinita; non invia operazioni, ma registra che cosa chiuderebbe. Secondo: prima della prima quotazione legge il tipo di conto e, fuori dal demo, rifiuta l'inizializzazione finché il lettore non imposta una conferma esplicita separata. MQL4 espone questa lettura tramite AccountInfoInteger(ACCOUNT_TRADE_MODE), e la documentazione distingue tra conto demo, da competizione e reale [16]. Un avvertimento in un commento non è una protezione; lo è un valore predefinito da cambiare consapevolmente perché accada qualcosa.

SCHEMA STRUTTURALE – arresto per drawdown del patrimonio
Notazione orientativa per MQL4. Non è codice completo e compilabile.

IMPOSTAZIONI DI INGRESSO – le prime due decidono la sicurezza

   DryRun := TRUE                            valore predefinito
      Il programma non invia operazioni. Registra che cosa
      chiuderebbe: numero dell'ordine, volume e prezzo
      di riferimento. Per chiudere qualcosa, questa impostazione
      deve essere cambiata a mano.

   LiveAccountConsent := FALSE                valore predefinito
      Senza questo consenso rifiuta l'avvio su un conto
      diverso dal demo. Il consenso non può essere dato
      per errore.

   MagicNumber    – identificatore delle proprie posizioni
   MaxDrawdownPct – drawdown consentito dal picco patrimoniale
   MaxDeviation   – vale per una sola modalità di esecuzione;
                    vedi il paragrafo sotto lo schema

AVVIO – OnInit()

   mode := AccountInfoInteger(ACCOUNT_TRADE_MODE)
   if mode != ACCOUNT_TRADE_MODE_DEMO
         and not LiveAccountConsent:
      registrare: conto non demo, consenso mancante
      terminare inizializzazione con errore (INIT_FAILED); nient'altro
   peak       := AccountEquity()
   stopped    := FALSE
   lastAlert  := 0          timestamp dell'ultimo allarme

OGNI QUOTAZIONE – OnTick()

   if stopped:
      remaining := CountOwnPositions()
      if remaining > 0
            and TimeCurrent() - lastAlert >= 3600:
         registrare: stato fermo, remaining
         inviare un allarme a una persona
         lastAlert := TimeCurrent()
      terminare la gestione di questa quotazione
         nessun ritentativo autonomo di chiusura: il successivo
         è una decisione umana eseguita a mano
   equity := AccountEquity()
   if equity > peak: peak := equity
   threshold := peak * (1 - MaxDrawdownPct / 100)

   if equity >= threshold:
      ramo vuoto: lo schema sorveglia soltanto la soglia
      e non contiene alcuna logica di ingresso

   altrimenti:
      stopped := TRUE
      registrare: equity, threshold, peak, timestamp
      errors    := CloseOwnPositions()
      remaining := CountOwnPositions()
      if remaining == 0 and errors == 0 and not DryRun:
         ExpertRemove()          rimozione solo dopo il successo
      altrimenti:
         registrare: errors, remaining
         inviare un allarme a una persona
         lastAlert := TimeCurrent()
         NON rimuovere: resta attivo, non apre nulla,
         ripete l'allarme e attende una persona

CHIUSURA – CloseOwnPositions() restituisce il numero di errori

   errors := 0
   for i from OrdersTotal() - 1 down to 0:

      if not OrderSelect(i, SELECT_BY_POS, MODE_TRADES):
         errors := errors + 1
         registrare: posizione i, GetLastError()
         passare alla successiva       non tacere qui

      if OrderType() > OP_SELL: saltare
                                     pendenti separatamente
      if OrderMagicNumber() != MagicNumber
            or OrderSymbol() != Symbol(): saltare
                                     lasciare intatte altrui e manuali

      RefreshRates()
      price := MarketInfo(OrderSymbol(),
                          MODE_BID for OP_BUY, MODE_ASK for OP_SELL)
      if price <= 0:
         errors := errors + 1
         registrare: quotazione assente, GetLastError()
         passare alla successiva

      ticket := OrderTicket()
      volume := OrderLots()

      if DryRun:
         registrare: CHIUDEREBBE ordine, volume, price
         passare alla successiva       nulla va al server

      if not OrderClose(ticket, volume, price, MaxDeviation):
         errors := errors + 1
         registrare: numero ordine, GetLastError()

   return errors

CONFERMA – CountOwnPositions()

   Scorre di nuovo l'elenco e conta le posizioni con il proprio
   MagicNumber su questo simbolo, saltando i pendenti come
   il ciclo precedente. Legge lo stato del conto, non la memoria
   del programma: solo questa lettura decide se può terminare.

Che cosa non fa lo schema: è importante quanto ciò che fa. Non elimina ordini pendenti né gestisce chiusure parziali. Non sopravvive al riavvio: flag di arresto e picco patrimoniale sono in memoria, quindi riparte da zero. Non ritenta neppure la chiusura, per scelta, non per lacuna. Dopo una chiusura fallita resta fermo: non apre nulla, riconta le posizioni a ogni quotazione e, finché ne resta una, ripete registro e allarme non più di una volta all'ora. Il tentativo successivo spetta a una persona, a mano dal terminale o dall'app del broker. Il comportamento è completo: il ritentativo automatico non appartiene allo schema e nulla attende di essere riempito. Una decisione è invece obbligatoria: la rimozione avviene solo dopo aver ricontato le posizioni proprie, quando non ne resta nessuna e nessun tentativo ha segnalato errori. L'ordine conta: rimuoversi incondizionatamente dopo un fallimento lascia esposizione aperta e un registro, senza nessuno nel sistema che provi a chiuderla. Per questo, con errori o posizioni residue, resta attivo e allerta.

Una cosa sembra buona pratica, ma non lo è. RefreshRates() restituisce un valore booleano, ma trattare false come errore sarebbe sbagliato: la documentazione MQL4 indica che restituisce true quando i dati sono stati aggiornati e precisa che l'unico motivo per non aggiornarli è che siano già i dati correnti del terminale client [17]. False significa quindi che i dati sono già aggiornati. Va verificato altro: che il prezzo letto dopo l'aggiornamento sia positivo. Un prezzo zero indica lettura fallita delle specifiche o quotazione assente; una richiesta di chiusura a quel prezzo viene rifiutata.

Resta il parametro di scostamento: qui una precisazione conta più del valore. MaxDeviation non è un limite universale al prezzo di esecuzione: vale solo per Instant Execution. Entro il limite esegue al nuovo prezzo senza avviso; solo oltre il limite il server restituisce prezzi da confermare. Meccanismo e citazioni sono spiegati nella sezione sulla latenza, e più ampiamente nel seguente articolo sulle piattaforme; qui conta una conseguenza. Valori dell'ordine di tre punti, cioè 0,3 pip su un conto a cinque cifre, vengono copiati senza riflettere e scelti per ingressi tranquilli, non chiusure d'emergenza. Queste avvengono proprio con spread ampio e slippage: una soglia così stretta fa restituire nuovi prezzi anziché eseguire. Se il programma non gestisce riquotazioni, restano posizione aperta ed errore. Lo scostamento per l'emergenza deve essere molto più ampio di quello d'ingresso, e va chiamato per ciò che è: non più protezione, ma consenso anticipato a chiudere peggio del prezzo visto, in cambio di maggiori possibilità che la richiesta passi. Scegli tra prezzo peggiore ed esposizione aperta, non tra sicurezza e rischio. Con Market Execution il campo manca: decide il broker, inviare è consenso anticipato e resta solo da registrare quanto la chiusura differisca dal prezzo della decisione.

Un'altra asimmetria, indipendente dalla modalità, riguarda l'ambito. La soglia si calcola da AccountEquity(), cioè dal patrimonio dell'intero conto, ma chiude solo posizioni del simbolo attuale. Eseguito su tre grafici, al superamento chiuderà lo strumento su cui arriva la quotazione; le altre istanze continueranno a contare il proprio picco. Su più grafici, la supervisione del rischio complessivo va separata in un altro programma. Ogni lacuna richiede una decisione progettuale consapevole prima di toccare denaro reale.

Tre livelli di protezione

Nessuna basta da sola: ognuna fallisce in uno scenario diverso.

1. Il codice del robot. I limiti descritti funzionano solo con il programma attivo
2. Il server del broker. Livelli SL/TP associati, margin call e chiusura automatica allo stop-out funzionano indipendentemente dal tuo ambiente; ogni posizione automatica dovrebbe quindi avere protezione lì, non solo in una variabile
3. La persona. Notifiche sul telefono di aperture, chiusure, arresti ed errori e capacità provata di chiudere a mano dall'app del broker: ultimo livello se falliscono i primi due

Le dipendenze sono concrete. Una protezione sul server non ferma una serie di piccole perdite che rispettano singolarmente il rischio ma insieme prosciugano il conto: serve il limite di drawdown nel codice. Quel limite non aiuta se muore la macchina del terminale; allora lavora solo il livello del broker. Senza i primi due livelli, le notifiche raccontano soltanto come prosegue la perdita.

Anche le protezioni vanno provate

Una protezione mai attivata è un'ipotesi, non una protezione. Si prova su demo in due fasi, perché la prima controlla la correttezza a minor costo. Prima: simulazione attiva e soglia abbastanza bassa da essere superata entro un'ora. Non invierà nulla, ma registrerà quali posizioni considera proprie e che cosa farebbe. Se l'elenco non coincide —può accadere al primo tentativo per filtri di identificatore o simbolo troppo ampi—, lo saprai senza chiudere nulla. Solo quando coincide disattiva la simulazione e ripeti. Verifica separatamente tre cose: chiusura delle sole posizioni proprie, evento nel diario e arresto solo dopo aver confermato che nulla resti aperto. Prova a parte la disconnessione: togli la rete per alcuni minuti e controlla se al ritorno riconcilia con la cronologia o riparte e apre una seconda posizione.

Lo standard minimo di messa in esercizio è questo: programma compilato con limiti, permessi verificati ai tre livelli, decisioni su file e demo nell'ambiente previsto con riavvio forzato, disconnessione e passaggio del fine settimana. Poi, solo se il piano di rischio lo permette, conto reale al volume minimo prima di aumentare l'esposizione. Quante operazioni e quali risultati consentano di avanzare è un tema distinto di validazione delle strategie; qui si tratta solo di preparazione operativa.

Un sistema automatico pronto di terzi

Un'osservazione sui prodotti dei marketplace software, per la sicurezza operativa: il file è compilato, quindi non puoi leggerne la logica né verificare limiti di drawdown, protezioni sul server o aumento del volume dopo perdite consecutive. Valutare la strategia richiede gli strumenti del materiale sui test. Qui vale una regola più semplice: non puoi sorvegliare in sicurezza un sistema di cui non sai prevedere il comportamento nei guasti, qualunque sia la curva dei risultati mostrata.

Scrivere il robot è spesso la parte più semplice. Mantenerlo è più difficile: revisione settimanale dei registri per rifiuti e tempi anomali, controllo del drawdown rispetto alle ipotesi e domanda onesta se il mercato assomigli ancora a quello dei test. L'automazione sposta l'esecuzione nel codice ed elimina alcuni errori umani di esecuzione. Non sposta la responsabilità: resta tua, insieme al dovere di fermare il sistema in tempo.