QORE è costruito come un sistema event-driven, multitenant per costruzione, con isolamento per container. Ogni componente fa una cosa sola e la fa bene. Ogni decisione è tracciata, ogni esecuzione è ricostruibile.
Le scelte architetturali privilegiano stabilità in produzione e latenza misurata sui percorsi critici. Niente componenti sperimentali nei punti caldi, niente moda del momento — solo ciò che ha dimostrato di reggere in scenari reali ad alta intensità. Il risultato è un sistema che non sacrifica performance per affidabilità, né viceversa.
Bus eventi sub-millisecondo per la comunicazione tra servizi. Acknowledgement nativo, footprint operativo minimo. Ogni componente dialoga via subject pattern dedicato per cliente.
Feed market data tick-by-tick di livello istituzionale, con re-subscription automatica al rollover dei contratti future. Latenza misurata dal trade reale al motore decisionale.
Layer di esecuzione disaccoppiato dal motore strategico. Sequenza atomica con what-if margin pre-ordine e stop attaccato dalla prima fase. Sostituibile, testabile, isolato.
Persistenza tick-by-tick per backtesting e replay deterministico. Ogni decisione è ricostruibile a posteriori, indipendentemente dal feed live.
Ogni cliente è un servizio dedicato con configurazione esterna. Aggiungere un tenant significa avviare un nuovo servizio: zero modifiche al codice condiviso.
Dashboard responsive con aggiornamenti real-time. Autenticazione con refresh, middleware multitenant per il filtro automatico delle informazioni per cliente.
Ogni strategia produce uno score 0–100 sul prossimo tick. Quando più letture concordano sulla direzione, il segnale acquista peso. Le soglie sono configurabili per simbolo e per tenant.
Il footprint chart mostra il volume aggressor per livello di prezzo. La strategia calcola imbalance bid/ask e identifica zone di assorbimento istituzionale — dove il volume entra ma il prezzo non si muove, segnale di difesa del livello.
// Footprint snapshot — ES Z6 @ 14:32:11 level bid_vol ask_vol imbal 5418.50 141 62 2.27× 5418.75 2,847 12 237× ABSORPT 5419.00 28 186 0.15× 5419.25 14 94 0.15× ───────────────────────────────────────── signal: LONG · score: 87 edge: assorbimento sul bid 5418.75
La VWAP è una misura statica del consenso istituzionale sulla sessione. Quando il prezzo la perde e poi la riconquista con volume crescente, è il mercato che dichiara: "il livello giusto è qui sopra, non lì sotto".
// VWAP reclaim setup vwap: 5417.42 last_loss: 5417.00 (8 min ago) reclaim_bar: 5418.50 → 5419.25 reclaim_volume: +34% vs avg confirm_bar: pending ───────────────────────────────────────── action: armare LONG su conferma stop: 5416.75 (min rejection) target: trailing 3 fasi
Gli ordini iceberg sono grandi ordini istituzionali frammentati per nascondere la dimensione reale. La strategia cerca le firme tipiche: refill ripetuti sullo stesso livello, dimensione costante, indipendenza dal flusso aggressor.
// Iceberg detection level: 5418.75 refills: 7 in 42s refill_size: ~150 contracts (σ 12) aggressor: SELL netto −1,847 persistence: livello attivo da 3.4 min ───────────────────────────────────────── read: istituzionale difende 5418.75 action: LONG con stop sotto livello
Il momentum genuino ha tre marcatori simultanei: accelerazione del prezzo, espansione del range della barra, picco di volume. Quando i tre indicatori convergono, è raro. Quando convergono, va seguito.
// Momentum burst trigger price_accel: +2.8 σ (threshold ≥ 2.0) range_expand: +167% vs prior 5 volume_peak: 3,412 (p99 = 2,847) all_triggers: YES ✓ ───────────────────────────────────────── signal: LONG burst · score: 93 trail: fase 3 stretta da 1.5 → 1.0 ATR
Una sola pipeline serve N clienti. Ogni tenant ha il suo container orchestrator,
il suo middleware autenticato, il suo filtro automatico per tenant_id.
Niente è hardcodato. Tutto deriva da configurazione esterna.
Nessun valore specifico del cliente è mai presente nel codice. Tutto proviene da
file .env o YAML con tenant_id come chiave di routing.
Aggiungere un tenant significa avviare un nuovo container — senza modificare una
sola riga.
super_admin · infra_admin · strategy_admin · support · finance · trader · demo_viewer. Capabilities tracciate sezione per sezione.
Ogni azione lascia traccia: actual_user_id, effective_user_id, IP, timestamp. Login impersonation tracciato in audit log dedicato.
Quattro modelli supportati: TWS condivisa, dedicata, paper-only, simulator. La scelta è del tenant, l'infrastruttura non cambia.
Ogni esecuzione passa per 17 step verificati: niente è opzionale. Se uno step fallisce, l'esecuzione si interrompe con stato preciso.
Lo stato locale viene confrontato con lo stato del broker ogni 4 secondi. Discrepanze rilevate immediatamente e gestite con regole esplicite.
Il valore del margine viene sempre dal what-if al broker. Se il what-if fallisce per più di 3 minuti, il sistema entra in "blocco" e rifiuta nuovi ordini.
Pulsante di emergenza in dashboard. Tutte le posizioni aperte vengono chiuse al mercato e tutte le strategie disattivate, registrato in audit.
Cambio contratto future automatico alle 02:00 italiane su crossover di volume, con protezione 1 giorno: nessuna posizione aperta durante il rollover.
Ogni release passa prima per un ambiente staging identico (subnet separata). Solo dopo test E2E superati la release viene promossa in produzione.
Per i partner tecnici e i clienti istituzionali è disponibile la documentazione architetturale completa, sotto NDA. Contattaci per richiederla.
