Considerazioni Avanzate per la Definizione di un EA

Definizione preliminare: cosa significa un EA nel forex

Una definizione di EA si riferisce tipicamente a un componente di trading automatizzato progettato per essere eseguito all’interno di una piattaforma di trading. Nel contesto del forex, un EA è un software in grado di osservare input basati sul mercato resi disponibili dalla piattaforma, applicare regole decisionali e quindi inviare richieste di trade (ad esempio, ordini di entrata e uscita). Le “considerazioni avanzate” iniziano distinguendo ciò che è concettualmente stabile da ciò che può variare in base all’ambiente.

Un modello semplice, utile per definire un EA senza vincolarlo a un singolo fornitore, è il seguente:

• Input: dati resi disponibili dalla piattaforma (prezzi o valori derivati), più parametri di configurazione scelti dall’utente o dall’autore.
• Logica: un processo deterministico o basato su regole (spesso espresso come condizioni e calcoli) che decide se piazzare, modificare o annullare ordini.
• Esecuzione: il meccanismo che trasforma una decisione in ordini, inclusi tempistiche, slippage e comportamento dei tipi di ordine disponibili.
• Stato: variabili persistenti che tracciano ciò che è accaduto finora (posizioni aperte, ultimo orario di trade, limiti raggiunti).

Quando si spiega una definizione di EA, è importante specificare quale parte si sta definendo. Ad esempio, definire “l’automazione” non è la stessa cosa che definire “il comportamento esatto di esecuzione”.

Meccanismo: le parti che rendono un EA più di un concetto

Input e assunzioni

Anche definizioni semplici possono diventare ambigue se gli input non sono specificati. Molti EA si basano su:

• Serie storiche di prezzo utilizzate dalla piattaforma (ad esempio, chiusura barra rispetto a aggiornamenti tick).
• Gestione del tempo (ora del server rispetto all’ora locale, e cosa significa “inizio”).
• Vincoli dello strumento (cosa la piattaforma permette per un simbolo, e se è abilitata la copertura o il netting).

Considerazione avanzata: la definizione dovrebbe includere l’assunzione sulla granularità dei dati. Una regola logica che si attiva “su ogni tick” differisce da una che si attiva “una volta per barra”. Senza specificare l’assunzione sulla frequenza di attivazione, una definizione di EA non può essere verificata in modo equo.

Struttura della logica (regole decisionali)

Nella definizione di un EA, la logica è spesso espressa come:

• Condizioni di entrata: quando richiedere un ordine.
• Condizioni di uscita: quando chiudere o aggiustare posizioni.
• Controlli di rischio: limiti come numero massimo di posizioni aperte, restrizioni basate sul tempo o condizioni di stop per il drawdown.

Un caso limite importante è che alcuni “controlli di rischio” dipendono dagli esiti di esecuzione. Ad esempio, se l’EA presuppone che un ordine venga eseguito immediatamente ma l’ambiente ritarda l’esecuzione, un controllo basato sull’“esposizione corrente” può comportarsi in modo diverso dal previsto.

Comportamento di esecuzione (trasformare decisioni in ordini)

L’esecuzione è spesso la parte più variabile della definizione di un EA. Include:

• Tipi di ordine e come vengono gestiti dalla piattaforma.
• Tempistiche: se la logica viene eseguita prima o dopo gli aggiornamenti dei prezzi.
• Costi: commissioni e spread che modificano i prezzi effettivi.
• Slippage: differenze tra prezzo di riempimento atteso e prezzo effettivo.

Considerazione avanzata: una definizione di EA dovrebbe separare esplicitamente la “logica decisionale” dai “risultati di esecuzione”. Anche se la logica decisionale è stabile, l’esecuzione può produrre risultati netti diversi.

Stato e re-entrancy

Gli EA mantengono uno stato per evitare azioni duplicate o applicare limiti. Le definizioni avanzate dovrebbero menzionare la gestione dello stato:

• Se l’EA memorizza i timestamp dell’“ultima azione”.
• Se verifica le posizioni esistenti prima di inviare nuovi ordini.
• Cosa accade se l’EA viene riavviato (reset dello stato) o se la piattaforma si riconnette.

Limitazione materiale: le assunzioni sullo stato possono fallire. Se la definizione di EA non tiene conto del comportamento al riavvio, potrebbe inviare nuovamente richieste o saltare azioni previste.

Evidenze ed esempio con assunzioni verificabili

Poiché non si assume l’uso di dati di mercato in tempo reale, l’obiettivo è mostrare come costruire un esempio che possa essere verificato in modo indipendente.

Un esempio “modello semplice” verificabile

Supponiamo che una definizione di EA includa queste assunzioni:

• L’EA valuta la logica una volta per chiusura barra.
• La logica di entrata è una condizione booleana basata su valori calcolati da quella barra.
• Quando la condizione diventa vera, l’EA invia un singolo ordine di mercato.
• L’EA memorizza un flag di stato per evitare di inviare un altro ordine fino al verificarsi di una nuova barra qualificante.

Come verificare questo:

• Verificare la frequenza di attivazione controllando se la logica viene chiamata alla chiusura della barra o sugli aggiornamenti tick (questo è un dettaglio implementativo nell’ambiente della piattaforma).
• Verificare lo stato confermando se l’EA impedisce ordini multipli dopo il primo evento qualificante.
• Verificare l’indipendenza dell’esecuzione controllando come la piattaforma esegue gli ordini di mercato in condizioni di spread o latenza variabili.

Caso limite da includere nella definizione di EA: se gli spread si allargano temporaneamente nel momento della chiusura della barra, il prezzo effettivo di riempimento può differire da quello atteso dai prezzi medi. Anche un trigger corretto non garantisce risultati simili.

Relazioni storiche e perché non definiscono la definizione

Un errore comune è pensare che, poiché un EA ha prodotto risultati in passato, la sua definizione debba essere completa. In realtà, le relazioni storiche non stabiliscono risultati futuri. Questo è importante per la definizione di un EA perché può nascondere assunzioni mancanti (ad esempio, dipendenza da un comportamento del feed dati che in seguito cambia).

Limitazioni e rischi da includere in una definizione di EA

Una definizione solida di EA dovrebbe indicare almeno una limitazione materiale o un modo di fallimento.

Modo di fallimento 1: incompatibilità ambientale

Backtesting ed esecuzione reale spesso differiscono a causa di:

• Qualità dei dati e allineamento temporale (spread diversi, ricostruzione dei tick diversa).
• Assunzioni di esecuzione (modellizzazione dei fill rispetto ai fill reali).
• Impostazioni della piattaforma (modalità conto, regole di gestione degli ordini).

Limitazione materiale: una definizione che omette dettagli sul modellaggio dell’esecuzione può indurre in errore, facendo credere che il mapping da logica a ordini sia identico in tutti gli ambienti.

Modo di fallimento 2: ambiguità di configurazione

Gli EA richiedono tipicamente parametri (input) come soglie, regole di dimensionamento delle posizioni e finestre temporali. Le considerazioni avanzate includono:

• Se le unità dei parametri sono chiaramente definite.
• Se i valori predefiniti sono sicuri o semplicemente “funzionano” per una configurazione specifica.
• Se i parametri interagiscono (ad esempio, un limitatore di frequenza di trade può sovrascrivere una regola di entrata).

Incertezza da dichiarare: senza assunzioni esplicite sui parametri, due definizioni di “stesso EA” possono riferirsi a comportamenti diversi.

Modo di fallimento 3: cambio di regime e sensibilità ai costi

Anche se la logica è internamente coerente, le condizioni di mercato e i costi possono cambiare:

• I regimi di volatilità influenzano la frequenza con cui si attivano le condizioni.
• I cambiamenti di spread o commissioni influenzano la redditività netta.

Limitazione: qualsiasi esempio che si basi su condizioni stabili è fragile. Una definizione dovrebbe distinguere il comportamento delle regole dagli effetti netti dopo i costi.

Verifica e prossime domande

Per verificare in modo indipendente una definizione di EA, concentrarsi su questi controlli che non richiedono affermazioni sul rendimento futuro:

• Controllo meccanico: confermare l’assunzione sulla frequenza di attivazione (tick vs chiusura barra) e la logica di stato che impedisce azioni duplicate.