Translate

venerdì 3 luglio 2015

QUELLA VOLTA IN CUI L'ALGORITMO DELLA GOLDMAN SACHS SI RIBELLO' AL SUO CREATORE, SPINGENDO LA BANCA ED IL MERCATO DELLE OPZIONI USA AD UN PASSO DAL TRACOLLO. GLI EVENTI PT.2

Machines are alive, humans no more
Per la prima parte, clicca qui.
A partire dal 2012, GSCO (Goldman, Sachs & Co) ha avviato un processo volto a consolidare al suo interno alcune funzioni del servizio clienti, in precedenza svolte -in esclusiva- da un broker-dealer collegato alla banca, denominato Goldman Sachs Execution & Clearing L.P. (GSEC) oppure in condivisione con GSCO. Una delle funzioni del servizio clienti garantite prima del 2012 da GSEC, riguardava la fornitura di liquidità ai clienti operanti sul mercato elettronico delle opzioni. Questa fornitura di liquidità, veniva realizzata in parte tramite l'uso del matching engine il quale cercava di accoppiare le indicazioni di interesse della banca verso particolari opzioni, conosciute anche come “axes” o “contingent orders,  con gli ordini dei clienti. Laddove fosse stato possibile eseguire il trade tramite incrocio realizzato tra un ordine retail ed uno espressione degli interessi propri della banca, i due sarebbero stati accoppiati ed inviati al mercato per l'esecuzione nel rispetto delle norme applicabili. Nel caso in cui non fosse stato possibile il matching, l'ordine retail sarebbe stato instradato verso il mercato. Gli axes sono basati sull'interesse della banca, nell'ambito dell'esecuzione dei trades eseguiti in conto proprio, risultando vincolati nel prezzo, nella size e con riguardo ad altri parametri. Gli axes non sono pensati per andare a mercato senza essere accoppiati con gli ordini retail; viceversa, in tal caso, sono destinati a rimanere nel matching engine in attesa di ordini della clientela da sottoporre ad incrocio. GSCO iniziò le operazioni nel Settembre del 2012. Le due unità tecnologiche principalmente coinvolte in questo progetto erano: l' Equity Derivatives Automation Team (“Ed-Dat”) e la Mission Control. Ed-Dat era responsabile per lo sviluppo dei sistemi impiegati dai traders del settore equity derivatives della banca, interagenti con i clienti attivi nel trading elettronico. 
La Mission Control monitorava quei sistemi di trading una volta attivati e gestiva molti degli aggiornamenti e dei cambiamenti richiesti una volta che un particolare sistema fosse operativo. Il sistema disegnato dall' Eq-Dat Team usava un algoritmo per generare axes. Ogni axe conteneva un prezzo preimpostato pari ad $ 1,00, anche se il sistema era impostato in modo tale che il prezzo avrebbe potuto adeguarsi a quello di qualsiasi ordine retail destinato ad essere incrociato. Gli axes venivano poi inviati verso un server sul quale transitava l'intero flusso di ordini e che separava gli axes, collocandoli in una di due “liste” basate sul simbolo ticker dell'azione sottostante all'opzione. Le opzioni i cui simboli delle azioni sottostanti ricadevano nel range “A-H” ed “L-Z”, fluivano in una lista, mentre le opzioni con simboli sottostanti nel range “I-K” fluivano nell'altra. Gli axes poi passavano attraverso due servers di esecuzione al fine di trovare un ordine della clientela da incrociare in Sigma Options. Tuttavia, prima di raggiungere Sigma Options, gli axes passavano attraverso uno smart order router che traduceva le informazioni degli ordini provenienti dai due servers di esecuzione in un formato leggibile da Sigma Options. La traduzione era governata dai valori di configurazione settati dal Mission Control Team, deputato a gestire la connessione dei servers di esecuzione all'order router. Una volta passato attraverso il router, l'axe veniva inviato verso Sigma Options per verificare la presenza di ordini retail da incrociare. Quando un ordine del clienti (privati, imprese) veniva incrociato con un axe, il prezzo di questo veniva aggiustato dal -prefissato- $ 1,00 al prezzo attuale in corrispondenza del quale avveniva il matching con l'ordine del cliente. Se un axe veniva accoppiato con un ordine della clientela, i due ordini (axe+ordinario della clientela) tornavano indietro attraverso il router, per giungere ai servers di esecuzione prima di essere inviati al mercato per l'esecuzione. Nel caso in cui non fosse rilevato alcun match tra l'ordine axe e l'ordine customer, questo veniva instradato al mercato per il crossing e l'esecuzione, mentre l'axe rimaneva in Sigma Option (anche se nel frattempo poteva esser rimpiazzato da un axe successivo avente ad oggetto lo stesso simbolo). Gli axes non erano costruiti per andare a mercato in assenza di incrocio con l'ordine customer e conseguenziale aggiustamento del prezzo.


Continua...