Quali Rischi Sono Associati ai Sistemi Basati su Regole?

Cos’è un Sistema Basato su Regole?

Un Sistema Basato su Regole (RBS) prende decisioni applicando regole predefinite agli input. Tipicamente, le regole prendono delle condizioni (ad esempio, “se accade X”) e le associano a output (ad esempio, “allora fai Y”). L’idea fondamentale è che la logica decisionale sia esplicita e deterministica, non appresa automaticamente dai risultati.

In pratica, il comportamento del sistema dipende da tre categorie di assunzioni: (1) gli input sono corretti e tempestivi, (2) le regole sono logicamente complete per le situazioni che si presentano, e (3) la mappatura dagli output alle azioni nel mondo reale viene eseguita come previsto.

In che modo si manifestano i principali rischi?

Rischi operativi ed esecutivi

Anche se le regole sono ben formulate, l’esecuzione reale può discostarsi dalle aspettative del sistema. Esempi includono dati in ritardo o mancanti, differenze tra i dati utilizzati per le decisioni e quelli usati successivamente per i report, e attriti nell’esecuzione come costi, esecuzioni parziali o slippage. Un’altra causa comune di errore sono le “condizioni limite”: quando gli input sono al di fuori del range previsto (formati inattesi, picchi improvvisi, flussi interrotti), la regola può produrre un risultato non intenzionale dal progettista.

Un rischio correlato è che i componenti operativi possano guastarsi in modi non gestiti dalle regole. Ad esempio, se il sistema non riesce a raggiungere l’ambiente di esecuzione o non riesce a confermare i risultati, potrebbe continuare ad agire su informazioni obsolete o smettere di rispondere.

Rischi di mercato e di condizione

Le regole sono spesso calibrate su osservazioni passate o su schemi stabili. Quando il comportamento del mercato cambia — ad esempio, cambiamenti nei regimi di volatilità, rottura delle correlazioni o condizioni di liquidità in calo — le regole possono diventare meno rappresentative delle condizioni attuali. Poiché un RBS di solito non “si adatta” automaticamente, potrebbe continuare ad applicare la stessa logica anche quando le sue assunzioni di base non corrispondono più alla realtà.

Un modo pratico per considerare questo aspetto è: un RBS è robusto solo nella misura in cui le condizioni coperte dalle sue regole sono ampie. Se il sistema non è stato progettato esplicitamente per scenari anomali, può comportarsi in modo coerente ma errato.

Rischi di controparte e di ambiente

Gli output delle regole richiedono spesso una parte esterna o un servizio per eseguire le azioni. Questo introduce rischi di controparte e di ambiente: il processo che riceve la richiesta potrebbe comportarsi diversamente da quanto ipotizzato dal sistema, la disponibilità dei prezzi potrebbe cambiare o la connettività potrebbe degradare. Anche senza considerare un fornitore specifico, il rischio generale rimane che la “decisione” non sia la stessa cosa del “risultato”.

Se le conferme o gli ack sono in ritardo, duplicati o mancanti, lo stato interno del sistema può sballarsi. Ciò può portare a ripetizioni involontarie (eseguire la stessa azione più volte) o azioni mancate (credere che un’azione sia avvenuta quando non lo è stata).

Limiti materiali e come verificarli

Rischi di interpretazione e manutenzione

Le regole sono solitamente create e successivamente aggiornate da esseri umani. Il rischio può insinuarsi attraverso definizioni di regole ambigue, copertura incompleta di casi limite o cambiamenti nella rappresentazione degli input. Nel tempo, i problemi di manutenzione possono accumularsi: una regola potrebbe essere ancora logicamente corretta, ma potrebbe dipendere da un campo di input il cui significato è cambiato, oppure potrebbe non adattarsi più alla logica generale del sistema.

Verifica che puoi eseguire autonomamente

Per valutare autonomamente il rischio, verifica il sistema lungo quattro assi: (1) validazione degli input — cosa succede quando gli input sono mancanti, in ritardo o al di fuori dei range attesi; (2) copertura delle regole — se tutti gli scenari rilevanti corrispondono a comportamenti sicuri e intenzionali; (3) modellizzazione di costi ed esecuzione — se il percorso decisionale del sistema tiene conto di attriti come costi di transazione ed esiti parziali; e (4) coerenza dello stato — se il sistema può recuperare da risposte esterne fallite o duplicate.

Prossima domanda da porsi

Se stai valutando un RBS, la domanda più utile da porsi non è “Funzionerà?”, ma “Quali assunzioni richiede per un comportamento corretto, e con quale frequenza queste assunzioni vengono violate in condizioni realistiche?”. Poiché i risultati variano in base alle condizioni e ai vincoli operativi, concentrare la verifica sui casi di fallimento delle assunzioni, piuttosto che sul successo passato.