TRADING AD ALTA FREQUENZA. ORDINI ERRATI E QUOTE STUFFING. NEL CASO “CITADEL LLC” QUALCOSA NON TORNA PT4

Cari amici, nel post precedente ho provato a dar conto della versione ufficiale dei fatti fornita dal NASDAQ e dalla FINRA sul caso CITADEL LLC; in questo vorrei illustrarne un'altra, ponente una serie di interrogativi ma altresì fornente una serie di dati tecnici -a mio parere- difficilmente confutabili.

Il cannone con cui Citadel spara gli ordini sui mercati

Cosa affermano i diversi esperti di HFT, tra i quali quelli di Nanex? Innanzitutto, contestano il tenore del comunicato del NASDAQ, secondo il quale gli ordini inoltrati da CITADEL verso i vari mercati -specie nell' episodio del 13 Febbraio 2014- non costituirebbero la rappresentazione plastica di una strategia di quote stuffing ragionata, quindi voluta, quanto quella di un semplice errore umano. Tuttavia, secondo la corrente di pensiero oggetto del present post, se si fosse trattato di mero errore umano, questo sarebbe consistito nella erronea configurazione di un parametro (trashing control) autorizzante il trading desk ad inoltrare ordini ad una velocità superiore agli oltre 200 al secondo, quindi con una frequenza operativa definita dalle autorità “eccessiva”:può dirsi un evento del genere semplicemente tale? Per rispondere a questa domanda è necessario valutare -in generale- se essi siano stati inoltrati in maniera uniforme nell'arco dell'intero secondo (1 ogni 5 millisecondi) oppure se tutti e 200 siano stati inviati in una sola frazione temporale pari a 5 millisecondi, rimanendo poi l'HFT silente nei successivi 995 millisecondi (1 secondo= 1.000 millisecondi).Dove sta la differenza? Sta nel fatto che, nella seconda ipotesi, non solo un pacchetto di 200 ordini (200 è una cifra dal valore meramente esemplificativo tratta dal caso qui concretamente esaminato) inoltrato in soli 5 millisecondi impatta -rallentandole nel processo computazionale- le strutture hardware e software -nonché i trading systems- dei vari mercati in una misura maggiore rispetto a quanto accadrebbe a fronte di 200 ordini suddivisi in più frazioni temporali della durata di 5 millisecondi ciascuna, con la particolarità che sganciando la raffica in un sol colpo (5 millisecondi) per poi restare inattivo nei successivi 995, l'HFT non sarebbe rilevato dai softwares di monitoraggio del traffico informatico dei vari mercati, operanti come una sorta di radar. Per quale ragione? Perché i radars operano su basi temporali di 1 secondo o più; quindi, poiché in entrambe le ipotesi operative sopra descritte si avrebbero -comunque- 200 ordini complessivi immessi in 1 secondo, il radar qui considerato -nel caso in cui fossero inseriti tutti in soli 5 millisecondi-non rileverebbe alcun anomalia ove il suo limite massimo di tolleranza fosse settato a 200 ordini al secondo, manovrando l'HTF su parametri quantitativi/temporali atti a non far scattare l'allarme, pur generando il rallentamento proprio del quote stuffing, in virtù della concentrazione degli ordini immessi in soli 5 millisecondi, anziché della loro distribuzione nell'arco del secondo. Cerchiamo di capire il perché, ricordandoci che il quote stuffing -come tutte le medaglie- consta di due facce: immissione e cancellazione. Ogni mercato, dal punto di vista informatico, stabilisce un limite al numero di ordini cancellabili al secondo per singola azione (o altro strumento finanziario). Immaginando che uno di essi lo setti a 300, sarà facile individuare -sui reports di quella piattaforma- episodi di cancellazioni di 300 ordini per secondo per singola azione? No, pur risultando facilissimo rilevare tantissimi casi (quindi tantissimi singoli secondi) in cui risulteranno cancellati ben … 299 ordini! Provo a spiegarmi meglio con un altro esempio.

Ipotizziamo che:

• un mercato fissi a 1.000 il numero massimo di ordini immettibili e/o cancellabili -per singola azione- al secondo;
• un HFT invii una raffica di ordini (prontamente cancellati) in un lasso di tempo molto breve, pari a 100 millisecondi, restando silente per i successivi 900.
• i radar dei mercati misurino il numero di ordini cancellati con la frequenza di una volta al secondo;
• le reti fisiche trasportanti detti ordini (quindi a livello logico i relativi bytes) operino su di una scala temporale misurabile in microsecondi (1 microsecondo è pari ad 1 milionesimo di secondo).

Come si atteggerebbe un HFT e quale sarebbe il risultato operativo in presenza delle condizioni sopra indicate -molto realistiche- condizioni?

1. Se un mercato stabilisce che, per ogni secondo e per ogni azione il numero massimo di ordini immettibili e/o cancellabili sia pari a 1.000, l'HFT invierà 1.000 ordini (subito cancellati) in -ad esempio- soli 100 millisecondi, restando silente nei successivi 900; così facendo, i “radars” in uso ai mercati, rileveranno 1.000 ordini immessi in un secondo, come tali rispettosi dei parametri quantitativi/temporali previamente settati.
2. Se la piattaforma di negoziazione (mercato regolamentato, ECNs, MTFs) stabilisce che il network (hardware+software) possa accettare al massimo 1.000 ordini al secondo (i numeri impiegati hanno funzione meramente esemplificativa), va da sé che, onde evitare la comparsa di latenza (ritardo), la velocità massima di conduzione (quando parlo di conduzione parlo proprio di quantità di ordini presenti nei cavi) degli ordini deve essere pari a un ordine per millisecondo (1.000 ordini al secondo sono infatti pari ad 1 al millisecondo, essendo il millisecondo pari ad 1/1000 di secondo). Ciò significa anche che, qualora un HFT inviasse 1.000 ordini in 100 millisecondi anziché 100 in 100 millisecondi (come sarebbe naturale in un contesto operativo volto a non generare ritardi essendo la portata massima in tal caso pari ad 1 ordine al millisecondo), la rete fisica risulterà sovraccaricata producendo un ritardo proprio dopo i primi 100 ordini (portata massima per 100 millisecondi in assenza di latenza); ne consegue che le informazioni di prezzo e quantità proprie di altri 900 ordini (sia parte dei mille, sia altri ad essi in testa al flusso generale di dati), arriveranno in ritardo presso i computers degli altri traders, con tutto quello che ne consegue in termini di latenza informativa su profondità e ampiezza del book e conseguente sfruttamento degli arbitraggi da latenza, generati dall'HFT proprio tramite quote stuffing. E' questo il punto cruciale della guerra tecnologica in atto sui mercati.

Ritorniamo a Citadel. Domandano alcuni autori: come mai il NASDAQ ha sottostimato l'impatto dell'algoritmo di Citadel e quanto questo era effettivamente diffuso? Perché, ad esempio, nel provvedimento sanzionatorio non è stato fatto riferimento alcuno alle raffiche di ordini -rilevate nel giorno antecedente l'evento del 13 Febbraio 2014- interessanti decine di titoli? Perché, ad esempio, nel medesimo provvedimento non è stato fatto riferimento alcuno agli altri 632 eventi di quote stuffing verificatisi proprio in data 13 Febbraio 2014?

Partiamo dal 12 Febbraio 2014 e soprattutto partiamo da una serie di dati statistici offerti da NANEX.

In data 12 Febbraio 2014, dalle ore 13:31 sino alla chiusura delle contrattazioni, un algoritmo di un HFT ha piazzato (con contestuale cancellazione) dai 5.000 ai 30.000 ordini al secondo, su singoli titoli azionari ed ETFs. In molti segmenti temporali della durata di un secondo, sono state individuati più di 20 mila ordini falsi aventi ad oggetto un singolo titolo, quindi immessi al ritmo di uno ogni 50 microsecondi (milionesimi di secondo) o meno. In 50 microsecondi, l'informazione può percorrere circa 15,2 km, il che significa che ciascuno dei 20 mila ordini veniva cancellato dopo aver percorso meno di 15,2km prima di arrivare al data center del mercato collocato nel New Jersey. Solo computers collocati a metà della distanza sopra indicata potrebbe aver agito in tempo sui circa 20,000 ordini tarocchi al secondo per singolo titolo. Quelli interessati dai fenomeni di quote stuffing nella giornata del 12 Febbraio 2012, avevano come iniziati le lettereO, P, Q, S, T. Non tutti erano quotati sullo stesso mercato, ma gli eventi più estremi hanno interessato proprio il NASDAQ.L' order to trade ratio per ciascuno di essi era bassissimo; in 15 secondi furono registrati 275 mila ordini farlocchi, immessi e cancellati con riguardo ad un solo titolo, vale a dire PLUG. Da notare come in molti casi, il bombardamento sia partito negli ultimi 3 minuti di contrattazioni

Ecco i dati di NANEX

Nanex.net

La rarità di fenomeni di queste proporzioni è rappresentata in maniera perfetta – oltre che artisticamente eccitante- in questo grafico di NANEX, che tramite puntini blu e rossi (maggiore è il diametro, maggiore è la magnitudo del fenomeno) mostra la distribuzione temporale dei casi di quote stuffing moderato (ordini per secondo >= a 6.000 puntini blu) ed estremo (ordini per secondo >= a 25.000, puntini rossi), dal 2009 in poi.

Nanex.net

Qui, invece, un estratto delle statistiche inerenti alcuni dei titoli affetti dal quote spamming, in quella giornata.

Le altre critiche mosse al comunicato NASDAQ da NANEX e da altri traders in alcuni forum tematici presenti nella dark net di internet, quali sarebbero? Innanzitutto, sia gli esperti di NANEX che quelli coperti dall'anonimato in alcuni forum non accessibili dai comuni motori di ricerca, dopo aver analizzato e confrontato i “direct feed” NASDAQ Total View data con quelli del SIP, hanno riscontrato inesattezze rispetto a quanto dichiarato dal NASDAQ. In cosa consisterebbero dette inesattezze?

• Il NASDAQ afferma che CITADEL piazzò ordini ad una velocità di uno ogni 8-9 microsecondi. I contrarian, invece, sostengono che siano stati piazzati ad una velocità di 17 messaggi al millisecondo oppure, visto il tutto in termini di ordini, alla velocità di 8-9 al millisecondo, poiché un messaggio serve per inserire l'ordine ed uno per cancellarlo.
• Il Nasdaq afferma che l'algoritmo di Citadel iniziò ad operare in Quote Stuffing sul titolo PENN tra le 13:32:53.029 e le 13:33:00.998; i contrarian sottolineano invece come sia i dati del direct feed sia quelli del SIP mostrino l'algoritmo attivarsi tra le 13:32:48.875 e le 13:33:04.525
• Nel grafico di cui sotto, offerto da NANEX, possiamo ben capire come i contrarian -verosimilmente- abbiano ragione sull'inesattezza temporale delle evento interessante il titolo PENN sul NASDAQ: per quale motivo? Perché sia le rilevazioni del SIP (blu) sia quelle del direct feed del NASDAQ (rosse), indicanti un lasso temporale differente da quello citato nel comunicato del NASDAQ, si sovrappongono perfettamente, il che vuol dire che convergono sull'esattezza della finestra temporale rilevata da NANEX & C. 

Nanex.net

Di seguito esporrò una serie di considerazioni utili -almeno spero- a comprendere i 2 grafici che inserirò a chiusura di questo post. Nel mondo della finanza, la commodity che ha più valore in assoluto non è né l'oro, né il platino, né il crude oil: è l'infomazione.In questo zero-sum game,i “giocatori” che per primi accedono alla migliore informazione (vale a dire a quella maggiormente aderente alla realtà) alla fine, portano sempre a casa il bottino e/o il bottino più grosso.Il bisogno di ricevere informazioni accurate e di qualità, ma soprattutto il bisogno di riceverle il più rapidamente possibile ha contribuito a creare una vera e propriaindustria dei dati. I principali clienti degliHigh-Speed Informations Providers sono gli HFTs: i loro algoritmi analizzano al millisecondo le informazioni ottenute dai primi, prendendo posizione sul mercato conseguentemente. La maggior parte degli investitori retail, basa le proprie scelte di mercato facendo riferimento al consolidated feed,vale al dire al risultato del consolidamento del flusso di dati, derivato dalla combinazione di tutti i prezzi di tutte le azioni quotate su tutti i mercati, volta a calcolare il NBBO,successivamente diffuso come unico data stream. Il consolidated feed prices è noto anche come SIPo SIP Feed. Chi non volesse attendere i dati del SIP (gli HFTs)si orienta sui servizi di colocation e multiple co-location qui descritti (in tal caso i server utilizzati per il funzionamento degli algoritmi sono posizionati in più località, ciascuna delle quali in prossimità di una piattaforma.)Per gli HFTs intendono usufruire di tali servizi? Al fine di “vedere” i dati in anticipo rispetto a coloro i quali facciano affidamento -unicamente- su quelli distribuiti dal SIP; infatti tramiteco-location et similia i dati passano direttamentedal mercato all'HFT,laddove quegli stessi dati viaggiando verso il consolidated feed, percorrono la strada più lenta,“fermandosi” nel punto di consolidamento, prima della loro diffusione.In osservanza delReg NMSstatunitense, la fornitura di dati -tramite direct data feed- ad un operatore disposto a pagare, con una rapidità maggiore di quella garantita da parte dello stesso mercato nel trasferirli vesto il consolidated feed è proibita (mentre è astrattamente consentita una più rapida trasmissione dal mercato al consolidated feed): l'informazione sui prezzi proveniente da un mercato deve perciò giungere contemporaneamente sia a coloro i quali paghino per il servizio di direct feed sia al SIP (consolidated feed). Dove risiede dunque il problema? Risiede nel SIP, presso il quale, vuoi a causa della mole di dati da processare, vuoi per la struttura fisica e logica non proprio all'avanguardia, intercorrono alcuni millesimi di secondo tra la ricezione dei dati (da tutti i mercati), il loro consolidamento e la loro diffusione. Diffusione in corrispondenza della quale quel dato avrà un marca temporale “t” quando in realtà è ivi giunto qualche millesimo di secondo prima, per poi restarvi il tempo (millisecondi) necessario al processo di consolidamento; millisecondi durante i quali gli utilizzatori dei servizi di direct data feed hanno ricevuto nuove e più aggiornate informazioni.In altri termini, a causa del funzionamento del SIP, gli investitori sprovvisti un servizio di direct data feed sono portati a considerare “nuovi” dati vecchi di qualche millesimo di secondo, mentre saranno gli utilizzatori del servizio “di comunicazione diretta” gli unici a vedere i dati considerabili realmente nuovi in quel dato momento.

Proviamo ad analizzare nel dettaglio il frame temporale di un secondo, rappresentante la vista offerta dal Total View (il Direct Feed del Nasdaq) e dal SIP (Consolidated Data) nel momento in cui Citadel attacca in quote stuffing il titolo Penn National Gaming Inc. (PENN). Ogni pixel del grafico è pari ad un millisecondo. La linea blu rappresenta il numero di quotazioni generate dal SIP in ogni millisecondo; la linea rossa mostra il numero di messaggi registrati dal direct feed (Total View) del Nasdaq. Tra i due non dovrebbero esserci ritardi in osservanza del Reg NMS; tuttavia, in diversi frame sono stati rilevati non solo sul titolo in esame ma su tutti quelli gestiti tramite lo stesso hardware e software in uso al SIP. Chi si avvantaggia del ritardo? Gli HFTs, specie quando lo stesso diviene prevedibile quindi maggiormente gestibile in maniera matematica, previa generazione del quote stuffing; più nello specifico se ne avvantaggiano gli internalizzatori. Cos' è un internalizzatore? E' un’impresa di investimento che in modo organizzato, frequente e sistematico negozia per conto proprio eseguendo gli ordini del cliente al di fuori di un mercato regolamentato o di un sistema multilaterale di negoziazione. L'internalizzazione sistematica si ha quando l'intermediario internalizzatore esegue ordini, potenzialmente eseguibili su un mercato regolamentato, mediante incrocio con ordini di altri clienti oppure in contropartita con il proprio magazzino titoli, al di fuori di un mercato regolamentato o di un sistema multilaterale di negoziazione; in altri termini, esso garantisce il matching degli ordini retail basati sui dati SIP, potendo acquistare e vendere nel contempo le medesime azioni ai prezzi più aggiornati fatti segnare sul più rapido direct feed, oltre a poter sfruttare, posizionandosi di conseguenza, le informazioni di su prezzi e size degli ordini transitanti -con relative più o meno prolungate permanenze- presso le dark pools.

Nanex.net

Cosa ci dice, invece, il grafico di cui sotto? Come prima cosa è opportuno notare come lo stesso sia scansionato su frames da 200 millisecondi ciascuno: 13:32:50:00; 13:32:50:20; 13:32:50:40; 13:32:50:60 e così via; in secondo luogo (ma non per importanza), in corrispondenza delle frecce blu,è possibile osservare come il SIP diventi silente, ovvero non trasmetta quotazioni (bid/ask prices e quantità) del titolo PENN,accumulando un ritardo rispetto al direct feed (linea rossa) addirittura pari -nel caso della prima freccia- a 16 millisecondi. Questo succede proprio per effetto del tempo necessario a consolidare i vari dati, ingorgati nel collo di bottiglia fisico (hardware) e logico (software) del SIP; terminato il silenzio, il SIP esplode in un tripudio di nuove quotazioni. Tuttavia, i traders che le osserveranno non immaginano di certo che si tratti di dati vecchi di qualche millisecondo (16 nel caso qui preso in considerazione): per quale motivo? Perché il SIP marca temporalmente quei dati come dati delle ore 13:32:50:16 (momento della diffusione) e non come sarebbe viceversa corretto fare, delle ore 13:32:50:00 (momento in cui arrivano dal mercato al SIP).  

Nanex.net

Post scritto ascoltando