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

Mente l'Europa, non ponendo limiti all'accoglienza degli immigrati, si appresta a costruire un futuro che ricalcherà i recente passato USA dove, dal Dicembre 2007, il numero dei nativi USA che hanno trovato un' occupazione (rispetto a quelli già occupati) è cresciuto di 790.000 unità mentre quello degli immigrati è cresciuto di 2.104.000 unità, come da dati FED, 

 noi ci avviamo a chiudere il capitolo dello scandalo ITG.

51. Anche l' Heatmap Strategy del Progetto Omega fu progettato dal Liquidity Executive. Questa strategia, riguardava il trading sui mercati diversi da POSIT, risultando basata su di un live feed (Heatmap Feed) avente ad oggetto informazioni confidenziali relative all'esecuzione degli ordini dei clienti in dark pools esterne (quindi non in POSIT).
52. Al fine di implementare la Heatmap Strategy, il Liquidity Executive e l'Omega Team necessitarono dell'assistenza del GATE Team di ITG. Il GATE era ed è il sistema di gestione degli ordini (e delle relative esecuzioni) di ITG, detto anche “sistema circolatorio” o “piping”; tra le altre cose, risulta tuttora deputato ad instradare gli ordini verso gli algoritmi e gli Smart Routers di ITG, così come verso POSIT e/o in direzione delle trading venues esterne (borse e/o dark pools), oltre ad inviare i report interni di esecuzione nel momento in cui viene eseguito il matching dei trades.
53. Al fine di ottenere l' Heatmap Feed, i dipendenti impegnati con il Progetto Omega, con l'assistenza di quelli responsabili del GATE System, presero in presto un' utility già esistente presso ITG ed utilizzata dagli Smart Order Routers, aggregante le esecuzioni ottenute dai clienti in dark pools esterne, generando -sulla base di questi dati- dei valori probabilistici inerenti il livello di liquidità presente in quelle stesse trading venues.
54. Tuttavia, l' Heatmap Feed in uso ad Omega, non conteneva punteggi probabilistici ma varie categorie di informazioni real-time sugli eseguiti della clientela, tra le quali:

• nome della dark pool di destinazione;
• titoli oggetto di negoziazione;
• informazioni sull' eseguito (filled, partial filled ecc.);
• quantità;
• prezzo di esecuzione;
• tempo di attesa prima dell'esecuzione;
• tempo dell'avvenuta esecuzione;
• istruzioni inerenti il peg (midpoint, bid, ask);
• prezzo limite;
• numero sequenziale utile, eventualmente, ad individuare gli ordini child quali risultanti dal frazionamento di un ordine parent.

Tutte queste informazioni, contenute nell' Heatmap Feed, venivano usate dal Progetto Omega non soltanto nella gestione del Routingma anche per determinare quali titoli negoziare.

55. Utilizzando l' Heatmap Feed, l'algoritmo a questo associato, apriva -passivamente- posizioni in singoli titoli nell'ambito dei mercati lit al bid/ask price corrente, per poi chiuderle al midpoint o miglior prezzo, nelle dark pools selezionate in base ai dati forniti dal feed. L'obiettivo della strategia era quello di guadagnare “metà spread” o qualcosina in più aprendo e chiudendo tali posizioni.
56. Di seguito, un esempio di come funzionasse l' Heatmap Strategy :

• Usando l' Heatmap Feed, Omega rilevava un esecuzione al midpoint di un cliente ITG, legata ad un ordine di vendere azioni Alfa in una dark pool esterna (che, fantasia al potere, chiameremo “Fire Dark Pool”) nel momento in cui il best bid price risultasse pari a $ 10,00 ed il best offer price a $10,02 per azione. Omega, quindi, inferiva che in Fire avrebbe potuto esserci più punti di liquidità per l'esecuzione al midpoint.
• Omega acquistava, su di un mercato lit, le azioni Alfa a $10,00.
• Omega vendeva -in Fire- le medesime azioni al midpoint, pari a $ 10,01, conseguendo un ricavo di $ 0,01.
• Nessun operatore, oltre al Progetto Omega, aveva accesso alle informazioni fornite dall' Heatmap Feed.
• Dall' Aprile al Dicembre 2010, l' Heatmap Feed di Omega comprendeva informazioni di esecuzione sui trades in tempo reale, inerenti tutti i clienti di ITG, appartenenti sia alla sell che alla buy side.

57. Nel tardo autunno del 2010, il CEO di ITG dispose che, altri 2 alti dirigenti parlassero con il Liquidity Executive al fine di raccogliere informazioni sull' operatività del Progetto Omega, le quali avrebbero costituito oggetto di presentazione da parte dello stesso CEO, dinanzi al Consiglio di Amministrazione, nel Febbraio 2011.
58. Verso la metà di Dicembre 2010, il compliance department di ITG, nonché il senior management appresero, in virtù delle stesse ammissioni del Liquidy Executive, che il Progetto Omega fosse espressione del trading basato su di un live feed di informazioni provenienti dagli ordini dei clienti sell-side, inviati agli algoritmi di ITG. L'azienda sospese immediatamente il trading svolto tramite il Progetto. Poco dopo, lo stesso dipartimento, venne a conoscenza di ulteriori dettagli inerenti la Facilitation Strategy, l' uso dell' Aleri Feed fatto da Omega, l'uso del feed di esecuzione customer side fatto dal Progetto nell'ambito dell'implementazione dell' Heatmap Strategy.
59. Come detto nei post precedenti, il Liquidty Executive non aveva dichiarato né al compliance department né la senior management, le strategie utilizzate nell'ambito del Progetto Omega. Anzi, anteriormente al Dicembre 2010, aveva fornito loro, sul punto, informazioni false.
60. Tra il 9 ed il 20 Dicembre 2010, mentre il Progetto era sospeso, il Liquidity Executive subì una dura reprimenda da parte del CEO; tuttavia, dopo alcune modifiche apportate alle strategie di trading impiegate, il Progetto ripartì con l'operatività live.
61. A partire dal 21 Dicembre 2010 circa, il Progetto Omega ripartì apportando delle modifiche alla Facilitation Strategy, affinché questa non avesse accesso all' Aleri Feed. In aggiunta, a partire dal 24 Gennaio 2011, il Progetto Omega mutò la Heatmap Strategy inibendole l'accesso all' Heatmap Feed.
62. Quando il Progetto Omega intraprese nuovamente le negoziazioni, nessun cambiamento fu apportato alla sua struttura organizzativa. Proprio come accadeva prima della sospensione temporanea, il Liquidity Executive continuò a gestire il Progetto ed a dirigere le strategie di trading ad esso connesse, conservando il ruolo di responsabile degli algoritmi di ITG, degli Smart Order Routers e di POSIT, che contemplava l'accesso alle informazioni confidenziali degli ordini della clientela e delle informazioni inerenti il trading. Anche gli altri membri del team continuarono ad operare negli stessi ruoli occupati prima della sospensione.
63. Nonostante la rimozione dei non regolamentari direct feed, con riguardo alla Facilitation Strategy, il Progetto Omega continuò ad avere un accesso improprio alle informazioni identificative degli utilizzatori di POSIT. Inoltre, l' Omega Team proseguì a coordinarsi con il development team di POSIT, al fine di identificare gli utilizzatori sell-side di Omega con i quali tradare in POSIT, assicurandosi che gli stessi fossero configurati per negoziare aggressivamente nella dark pool di ITG.
64. Dopo la ripresa del trading, il Progetto Omega continuò a negoziare sino a quando, nel Luglio 2011, il Liquidity Executive venne licenziato.
65. Durante e dopo la sospensione del trading condotto dal Progetto Omega, ITG continuò a tenere segreta l'esistenza del Progetto e le attività a questo connesse, evitando di dichiararne l'esistenza anche alla SEC.