LA DARK SIDE DEL TRADING. LO SCANDALO ITG , IL PROGETTO OMEGA E GLI HIGH FREQUENCY TRADERS CHE NON PERDONO MAI PT. 2 - “THE FACILITATION STRATEGY Ver. 2010”

Nel post precedente (clicca qui), abbiamo più volte citato la figura centrale del “Liquidity Executive”di ITG, quale architettodel Progetto Omega: ma di fatto, chi è il Liquidity Executive? E' Hitesh Mittal. Hitesh Mittal lascia ITGnel 2011 e si accasa, in qualità di capo trader, presso il4° hedge fund più grande al mondo; più precisamente, inizia a lavorare presso “AQR Capital”, un hedge fund fondato dall'ex dipendente di Goldman Sachs, Cliff Asness, della specie “Mega Quant”.

Hitesh Mittal

Nell' Agosto 2015, Mittal viene però licenziato da AQR, a seguito dell' emersione dello scandaloITG. Qualcuno potrebbe pensare: ma che bravo Mr. Asness, lui sì che fa rispettare le regole. Può darsi; ma non sarà mica lo stesso che qualche tempo fa scrisse questo editoriale (clicca qui) per Bloomberg? Ad un certo punto, come vedremo meglio nei prossimi posts, nel Dicembre 2010, il Compliance Department della ITG, venne a conoscenza delle malefatte di Mittal il quale, nonostante la dura presa di posizione degli organi di controllo interni al gruppo, non solo continuò a frodare i clienti sell-side, ma di lì a poco sarebbe divenuto capo trader del 4° hedge fund più grande al mondo, gestore di masse pari a 136 miliardi di dollari. Nei posts precedenti, abbiamo avuto altresì modo di apprezzare come il Progetto Omega fosse stato approvato dal Consiglio di Amministrazione di ITG, di cui faceva parte -tra gli altri- Kevin J.P. O' Hara, già membro della Division of Enforcement della SECnonché Assistente Specialepresso il Dipartimento di Giustizia americano, dimessosi a seguito dello scandalo; qui, il cerchio si chiude.

37. Il Liquidity Executive, vale a dire Mittal, ex programmatore, guidò gli sviluppatori dell' Omega Software verso la progettazione e l'implementazione di due principali trading strategies, utilizzate nel live trading:

1. la Facilitation Strategy;
2. l' Heatmap Strategy.

Entrambe, erano basate sulla conduzione di trading ad alta frequenza, finalizzato all'acquisto ed alla vendita di azioni quotate sui mercati USA, al prezzo o nel range di prezzi ricadenti nel National Best Bid and Offer Price (NBBO),con l'obiettivo di realizzare piccoli profitti o “spreads” tra l'esecuzione dell'operazione di acquisto e quella di vendita, in time frames estremamente bassi. Lo ricordiamo, il NBBO è il più alto bid price ed il più basso ask price di un dato titolo; la differenza tra il best bid ed il best offer (ask) è detta bid-ask spread. Il NBBO delle azioni, quindi, si basa sull'insieme dei best bid and offer prices di tutti i titoli quotate su tutti i mercati nazionali USA.

38. POSIT era programmata per eseguire trades al o all'interno del NBBO, mentre gli ordini potevano essere ivi instradati con 3 tipi di peg, legati al NBBO:

• passivo;
• midpoint;
• aggressivo.

39. In POSIT, durante il periodo oggetto d'indagine, gli ordini ancorati come “passivi” venivano prezzati al National Best Bid (se d'acquisto) o al National Best Offer (se di vendita). Un ordine del cliente ancorato come “aggressivo”, avrebbe “crossato lo spread” (clicca qui) venendo eseguito al National Best Bid (nel caso di aggressive sell order) o al National Best Offer (nel caso di un aggressive buy order). Quindi, un buy order passivo sarebbe stato eseguito in POSIT solo contro un aggressive sell order; viceversa un sell order passivo sarebbe stato eseguito solo contro un buy order aggressivo. Il “midpoint” order (clicca qui), avrebbe, invece, ricercato punti di esecuzione equivalenti a quelli indicati nel link.
40. Nel periodo approssimativamente compreso tra Aprile e Dicembre 2010, la Facilitation Strategy di Omega, progettata dal Liquidity Executive (cioè da Mittal), riguardava il trading basato su di un live feed di news (noto come “Aleri Feed”) inerente gli ordini instradati dai clienti sell-side verso le strutture di trading algoritmico (comprese quelle Active, Close, Dynamic IS, Flexible Participation, POSIT Marketplace, Raider, TWAP, Volume Participation, VWAP, PWP and Hedge Pro Pairs) di ITG, per l'esecuzione. L'Omega Team accedeva al feed, previa connessione ad una software utility chiamata “Aleri”, normalmente impiegata dai sales and support teams di ITG. Il feed conteneva varie categorie di informazioni real-time riconducibili agli ordini “parents” veicolati per il tramite di tutti gli algos offerti da ITG, tra le quali:

• l'identificativo del cliente;
• il titolo negoziato;
• la market side occupata;
• la size dell'ordine;
• il numero di azioni rispetto al quale fosse stata ottenuta l'esecuzione dell'ordine;
• il target price;
• l'algoritmo di ITG utilizzato per l'esecuzione dell'ordine;
• i parametri temporali dell'ordine.

Prima di proseguire, consentitemi di meglio specificare il concetto di “parent orders”. Un ordine “parent” è un ordine “pieno” o completo”,proveniente da un cliente, tipicamente diviso in ordini dalla size minore (detti “child”) nel momento in cui viene instradato algoritmicamente per l'esecuzione.Ad esempio, nell'ipotesi di un parent sell order con size pari a 1.000 azioni (o altro asset), lo stesso sarebbe suddiviso in 10 sell orders di tipo “child”, ciascuno dei quali con size pari a 100. In tal caso, l' Aleri Feed conteneva le informazioni riguardanti i parents orders dei clienti sell-side, compresi gli aggiornamenti correlati (ad esempio il numero di azioni effettivamente vendute), rilasciati nel momento di esecuzione degli ordini child.

41. Solo il Progetto Omega aveva accesso all'Aleri Feed; nessun cliente di POSIT poteva accedervi.
42. La Facilitation Strategy era progettata per rilevare gli ordini provenienti dai clienti sell-side, gestiti da ITG tramite Aleri Feed; basandosi su quelle informazioni, ITG apriva posizioni nei mercati lit sulla stessa side occupata dagli ordini rilevati, per poi chiuderle in POSIT previo posizionamento sulla side opposta a quella riconducibile agli ordini rilevati poco prima. La Facilitation Strategy era strutturata in modo tale da guadagnare l'intero “bid-ask spread”, tramite l'apertura e la chiusura di posizioni.
43. Di seguito, un esempio di come funzionasse la Facilitation Strategy:

• Usando l' Aleri Feed, Omega rilevava da un cliente sell-side (brokers, broker-dealers), l' ordine di acquistare n azioni Alfa, nel momento in cui il best bid fosse pari a $10,00 ed il best offer fosse pari a $10,02 ( i valori scelti sono casuali) 
• Omega acquistava n azioni al prezzo di $10,00 su di un mercato lit.
• L'algoritmo di ITG, instradava l'ordine di acquistare n azioni, proveniente dal cliente sell-side di ITG- verso POSIT.
• Omega vendeva n azioni Alfa al cliente sell-side di ITG, in POSIT, al prezzo di $10,02, conseguendo un ricavo di $0,02 per singola azione.

44. Basandosi sulla loro esperienza nella progettazione, costruzione e/o scrittura dei codici di programmazione per la suite di algoritmi in uso alla clientela di ITG, il Liquidity Executive (Mittal) ed i membri dell'Omega Team, comprendevano come gli algoritmi di ITG's lavorassero nonché la logica ad essi sottostante e sottostante al routing degli ordini. Nel corso del periodo oggetto di indagine, tutti gli algoritmi di ITG instradavano gli ordini verso POSIT. In aggiunta, gli algoritmi di ITG, facevano normalmente uso degli Smart Order Routers dello stesso broker, risultati anch'essi settati per direzionare gli ordini verso POSIT.
45. Per l'intero periodo di tempo nel corso del quale il proprietary trading desk di ITG risultò attivo, l' Omega Team ebbe accesso alle identità degli clienti di POSIT ed usò questa informazione al fine di identificare l'intero gruppo di potenziali clienti sell-side, con i quali Omega averebbe potuto tradere in POSIT. Inoltre, l' Omega team usò le informazioni alle quali aveva accesso, per analizzare i profitti e le perdite generati dalla Facilitation Stratey, in controparte. Basandosi sui dati relativi all'andamento dei profitti e delle perdite, senza che i clienti di POSIT sapessero o avessero autorizzato alcunché in ordini all'utilizzabilità di questi dati, l'Omega team decideva se stoppare il trading con un certo gruppo di clienti per continuarlo con altri.
46. La Facilitation Strategy, era costruita per negoziare solo con i clienti sell-side, identificati da Omega. Al fine di rendere effettivo questo aspetto della strategia, l' Omega team necessitava dell'assistenza fornita dal development team di POSIT, un gruppo avente come referente proprio il Liquidity Executive. Sotto la direzione dell' Omega Team, il POSIT team implementò la configurazione richiesta nella dark pool, in modo tale di consentire ai clienti della sell-side di tradare o interagire con Omega in POSIT.
47. Nessuno, al di fuori del Progetto Omega, aveva la possibilità di identificare specificatamente le controparti con con le quali intendeva negoziare. Gli altri clienti operanti in POSIT, non erano in grado di avere contezza di questo dato, in quanto ITG aderiva alla policy non prevedente la disclosure delle identità dei clienti
48. La Facilitation Strategy che Omega impiegò, fu progettata al fine di guadagnare l'intero “bid-ask spread” sia aprendo che chiudendo posizioni, nel mentre oeprava passivamente. Per guadagnare l'intero “bid-ask spread” negoziando con i clienti sell-side in POSIT, quei clienti necessitavano di essere configurati per tradare aggressivamente in POSIT, in modo tale che gli stessi fossero disponibili a “crossare lo spread” e vendere ad Omega al bid price o acquistare da questo all'offer price.
49. Il Progetto Omega adottò le misure necessarie ad assicurare che i clienti sell-side, con i quali negoziava in POSIT, fossero configurati per negoziare aggressivamente in POSIT. Sotto la direzione del Liquidity Executive, uno degli sviluppatori software di Omega si accordò con tutto il personale di ITG – compresi quelli responsabili dell'amministrazione di POSIT, degli algoritmi e degli smart routers di ITG- al fine di ottenere conferma che i clienti della sell-side con i quali i clienti del Progetto Omega era in grado di negoziare in POSIT, tradassero -aggressivamente- in POSIT.
50. Nonostante l'obiettivo della strategia fosse quello di guadagnare l'intero “bid-ask spread”, in alcuni casi Omega eseguiva, in POSIT, trades al midpoint senza ottenere - di conseguenza- il full spread. Quando ciò accadeva, Mittal chiedeva al team di investigare, previo coordinamento con il development team di POSIT, al fine di stabilire le ragioni in base alle quali i trades venissero eseguiti al midpoint anziché al bid/ask price, come desiderato dallo stesso Liquidity Executive.