A chi serve — A chi vuole capire perché la quantità visibile nel book può essere inferiore a quella complessivamente disponibile e a chi deve eseguire una size senza mostrarla tutta in una sola volta.
Un iceberg order, chiamato anche reserve order o display quantity order in alcuni sistemi, è normalmente un ordine limite del quale il mercato vede soltanto una quantità esposta. La parte non mostrata è la riserva. Quando la tranche visibile viene eseguita, il sistema può rilasciarne un'altra fino all'esaurimento, alla scadenza o alla cancellazione della quantità totale.
Iceberg non significa però “ordine invisibile” in senso universale. La quota esposta partecipa al book; la riserva, le condizioni di rilascio, i dati disseminati e la priorità dopo il refill dipendono dalle regole del singolo venue e del prodotto.
In parole semplici — Un ordine totale di 1.000 unità può mostrarne 50. Dopo l'esecuzione delle 50, altre 50 possono comparire. Sapere che esiste un meccanismo di ricarica non permette però di conoscere in anticipo né la quantità residua né la sua priorità.
Istruzione, quantità e refill
| Elemento | Funzione |
|---|---|
| Ordine parent | Esprime lato, prezzo limite e quantità complessiva |
| Display quantity | Definisce la quantità massima mostrata in un dato momento |
| Reserve quantity | Parte non ancora esposta al book pubblico |
| Refill | Rilascio di una nuova tranche dopo un fill o altra condizione prevista |
| Child order | Nuovo ordine inviato da un sistema esterno nel caso di iceberg sintetico |
La terminologia non è uniforme. Nel Regolamento delegato (UE) 2017/583, RTS 2 per strumenti non-equity, l'articolo 4 descrive il reserve order come un limit order composto da una parte divulgata e una non divulgata; quest'ultima può essere eseguita soltanto dopo essere stata rilasciata nel book come nuovo ordine visibile. È una definizione normativa circoscritta a quel perimetro, non una specifica tecnica valida per ogni borsa, broker o crypto exchange.
Anche “display quantity” può essere un qualificatore dell'ordine, non un tipo autonomo. CME, per esempio, documenta una quantità mostrata che si ricostituisce man mano che viene eseguita. Prima di usare la funzione occorre quindi leggere la documentazione del prodotto, non dedurre la meccanica dal solo nome usato nell'interfaccia.
Iceberg nativo e sintetico
Un iceberg nativo è gestito dal matching engine o dall'infrastruttura del venue. Il venue riceve la quantità totale e governa esposizione e refill. Un iceberg sintetico è invece gestito dal broker, da un ISV o da un algoritmo esterno: il venue può vedere soltanto child order successivi, senza conoscere la size parent.
La distinzione modifica rischio operativo e tracce nei dati:
- il nativo dipende dalla disponibilità e dalle regole del venue;
- il sintetico dipende anche da rete, gateway, latenza e continuità del sistema che invia i child order;
- un nativo può conservare lo stesso identificativo dell'ordine durante il refill, mentre child sintetici possono ricevere identificativi nuovi;
- identità dell'ordine e priorità in coda non sono la stessa cosa.
La documentazione Market by Order di CME, per esempio, spiega che un iceberg
nativo mantiene lo stesso OrderID quando la quantità mostrata viene
ricaricata, mentre il PriorityID può cambiare. Un iceberg sintetico gestito da
un sistema esterno invia invece nuovi ordini al venue. Questo esempio dimostra
perché non si può trasferire automaticamente una regola di priorità da un
mercato a un altro.
Priorità e probabilità di fill
Il prezzo limite resta un vincolo sul prezzo, non una promessa di esecuzione. La tranche visibile compete secondo l'algoritmo di matching applicabile; una tranche rilasciata successivamente può ricevere una nuova priorità o un diverso trattamento. Regole price-time, pro-rata e ibride producono esiti differenti.
Nascondere quantità può ridurre l'esposizione informativa iniziale, ma non rende l'ordine immune da:
- fill parziali o mancati;
- movimento del mercato lontano dal limite;
- selezione avversa quando gli altri partecipanti negoziano contro la quota;
- commissioni e regole di accesso specifiche;
- perdita di priorità al refill;
- indisponibilità della funzione su un dato strumento.
L'effetto sul market impact non è garantito. Una minore size visibile può limitare l'informazione immediatamente esposta, ma un pattern di ricariche ripetute può a sua volta rivelare interesse e modificare il comportamento degli altri operatori.
Si può riconoscere dal book?
Solo inferenzialmente. Molti scambi sullo stesso livello, accompagnati da una quantità visibile che ricompare, sono compatibili con un iceberg; non ne provano l'esistenza. Nuovi ordini indipendenti, più partecipanti, feed aggregati, cancellazioni e latenze di mercato possono produrre una sequenza simile.
Un feed Market by Price aggrega quantità per livello. Un feed Market by Order
può mostrare ordini e posizione in coda con maggiore granularità, ma resta
anonimo e non rivela necessariamente la riserva complessiva. Neppure un
OrderID persistente identifica il proprietario.
Errore tipico — Trasformare un possibile refill in una certezza su “whale”, intenzione direzionale o quantità residua. I dati osservati supportano un'ipotesi di microstruttura, non l'identità né il futuro comportamento di chi ha inviato l'ordine.
Esempio controllato
Un sell limit totale di 10.000 azioni espone 500 azioni. Le prime 500 vengono eseguite e il venue mostra un'altra tranche. L'operatore aggressivo sa che sul livello è arrivata nuova quantità, ma non sa se restino 500 o 9.500 azioni, se il refill abbia perso priorità o se parte della sequenza provenga da ordini distinti. Per valutare l'esecuzione servono log, specifiche del venue e dati coerenti con il feed utilizzato.
Checklist prima dell'uso
- Verificare se l'implementazione è nativa o sintetica.
- Leggere regole di display, quantità minima e prodotti ammessi.
- Controllare priorità iniziale, priorità al refill e modifiche dell'ordine.
- Separare quantità totale, esposta, eseguita, cancellata e residua.
- Misurare fill, costo e impatto rispetto a un benchmark dichiarato.
- Prevedere cosa accade se il sistema esterno o la connessione si interrompono.
Il quadro generale si trova nell'hub Ordini, esecuzione e microstruttura. Per la coda vedi priorita-ordini-e-fill-parziali; per la frammentazione di una size vedi order-splitting.
Fonti
- CME Group, Market by Order (MBO) — FAQ — differenza fra feed MBO e MBP, iceberg nativi e sintetici,
OrderIDePriorityID. - CME Group, Display Quantity Order Overview — quantità mostrata, fill e replenishment nel perimetro CME.
- CME Group, Enter Orders — descrizione operativa del campo Display Quantity.
- EUR-Lex, Regolamento delegato (UE) 2017/583, articolo 4 — definizione di reserve order nel perimetro RTS 2.