In parole semplici — Una strategia può essere corretta e produrre comunque una perdita se l'ordine è sbagliato, i dati sono incompleti, un sistema non risponde o un fornitore interrompe il servizio. Il presidio non è soltanto «fare attenzione»: richiede controlli, alternative provate e un processo di recupero.
Il Basel Framework definisce il rischio operativo come il rischio di perdita derivante da processi interni, persone o sistemi inadeguati o falliti, oppure da eventi esterni. La definizione include il rischio legale ed esclude il rischio strategico e reputazionale. È una tassonomia usata per le banche, ma la distinzione è utile anche per un'attività di trading: identifica il meccanismo della perdita prima di scegliere il controllo.
Il rischio operativo non è sinonimo di rischio sistemico. Un guasto può restare locale oppure propagarsi attraverso dipendenze comuni e infrastrutture; questa eventuale propagazione non cambia la categoria del rischio originario.
Da dove può nascere
| Fonte | Esempi | Evidenza da controllare |
|---|---|---|
| Processi | istruzione duplicata, riconciliazione assente, autorizzazione errata | eccezioni, controlli saltati, posizioni non riconciliate |
| Persone | errore di quantità, competenze insufficienti, accesso improprio | log di approvazione, separazione dei compiti, formazione |
| Sistemi e dati | API indisponibile, feed obsoleto, clock o mapping errato | integrità e freschezza dei dati, allarmi, capacità e failover |
| Eventi esterni | cyberattacco, interruzione del fornitore, sito inaccessibile | dipendenze terze, scenari, tempi effettivi di recupero |
| Aspetti legali | contratto non applicabile, mandato o autorizzazione carente | termini, responsabilità, documentazione e giurisdizione |
Una perdita può avere più cause. Per esempio, un dato esterno errato diventa un incidente interno se non esistono validazione, blocco e riconciliazione. Il registro degli incidenti deve quindi distinguere causa, impatto, controllo fallito e azione correttiva, senza ridurre tutto a “errore umano”.
Controlli prima, durante e dopo l'evento
- Prevenire: permessi minimi, separazione dei compiti, limiti di size e notional, validazione di strumento e prezzo, change management.
- Rilevare: monitor di dati e ordini, alert su scarti e latenze, riconciliazione fra portafoglio, broker, banca e custode.
- Rispondere: ruoli di escalation, potere di sospendere automazioni, canali alternativi e comunicazioni predefinite.
- Ripristinare: priorità delle operazioni critiche, dati recuperabili, procedure manuali controllate e verifica dello stato prima della ripartenza.
- Apprendere: analisi della causa, aggiornamento dei controlli e test che dimostri la chiusura dell'azione correttiva.
Una checklist riduce la variabilità, ma non sostituisce controlli automatici né supervisione. Un limite che può essere ignorato senza traccia non è lo stesso controllo di un blocco tecnico con approvazione ed evidenza.
Resilienza e continuità operativa
La resilienza operativa è la capacità di erogare operazioni critiche durante una perturbazione. La continuità operativa prepara la risposta e il recupero. Non promette assenza di incidenti: stabilisce quali servizi devono continuare, quale interruzione è tollerabile e come tornare a uno stato controllato.
Un piano verificabile identifica almeno:
- operazioni critiche, proprietari, persone, dati, sistemi e terze parti da cui dipendono;
- soglie di escalation e tolleranze d'impatto coerenti con il contesto;
- copie e procedure di recupero dei dati, sistemi e sedi alternative;
- canali alternativi verso personale, clienti, intermediari, controparti e autorità pertinenti;
- modalità controllate per ridurre rischio, sospendere ordini o accedere a fondi e attività;
- scenari severi ma plausibili, esercitazioni, risultati, carenze e nuova verifica dopo le correzioni.
Un secondo account non costituisce da solo un piano di continuità: deve essere accessibile, compatibile con strumenti e permessi, finanziato secondo il piano e provato senza creare nuove esposizioni. Allo stesso modo, un backup non è utile finché il ripristino e l'integrità dei dati non sono stati testati.
I documenti BCBS, FINRA e IOSCO citati sotto hanno destinatari regolamentati specifici. Forniscono un quadro di controllo autorevole, ma requisiti e frequenze applicabili dipendono da soggetto e giurisdizione.
Errore tipico — Registrare l'incidente come caso isolato, riavviare il sistema e non verificare dipendenze, dati, ordini pendenti e causa del controllo fallito.
Fonti
- Basel Committee on Banking Supervision — Basel Framework, OPE10: Definitions and application
- Basel Committee on Banking Supervision — Revisions to the Principles for the Sound Management of Operational Risk
- Basel Committee on Banking Supervision — Principles for operational resilience
- FINRA — Rule 4370: Business Continuity Plans and Emergency Contact Information
- IOSCO — Mechanisms for Trading Venues to Effectively Manage Electronic Trading Risks and Plans for Business Continuity
- IOSCO — Market Intermediary Business Continuity and Recovery Planning