Una delle innovazioni più importanti introdotte dal Nuovo Accordo di Basilea è la consapevolezza che nella pratica bancaria occorre affrontare e gestire un nuovo tipo di rischio: il rischio operativo. Le banche sono tenute ad accantonare del capitale a copertura del loro rischio operativo; la normativa vigente prevede diversi metodi per determinarlo: quelli che applicano una percentuale fissa al margine d’intermediazione, e quelli (detti avanzati) che applicano modelli statistici alla “storia passata” delle perdite subite. Il modello più in voga, stima l’ammontare del capitale di copertura da una distribuzione statistica delle perdite per eventi omogenei, cioè eventi accomunati dall’essere tutti di un certo tipo che accadono in attività della stessa linea di business.
Che si ritenga o no conveniente utilizzare i metodi avanzati, un database dei dati principali sulle perdite operative permette di sapere a quanto ammontano, dove si verificano, se sono occasionali o ricorrenti ed individuare eventuali punti deboli nelle procedure o nei controlli.
NATURA DI UNA PERDITA OPERATIVA
Tipo di evento, linea di business e data di accadimento sono, in teoria, l’insieme minimo delle informazioni che caratterizzano un evento di perdita operativa. Nella pratica queste informazioni non sono sufficienti per tre motivi:
_ Le perdite operative sono complesse perché possono prendere forma nel tempo. Una frode interna che coinvolge più clienti ha effetti che diventano evidenti con il passare del tempo. In questi casi occorre tracciare le variazioni degli importi e considerare l’eventualità di accantonamenti e recuperi.
_ A volte, eventi avversi provocano effetti a catena. I guasti nei sistemi causano un blocco dell’operatività con nuove perdite che devono essere ricondotte all’evento generante.
_ Per governare il rischio operativo occorre conoscere il contesto nel quale un evento di perdita si è manifestato.
INFORMAZIONI DA “COLLEZIONARE”
Per un evento di perdita occorre collezionare almeno queste informazioni:
Cos’è accaduto e quando
_ Tipo dell’evento secondo la classificazione data dalla normativa.
_ Date di accadimento e di rilevazione.
_ Descrizione dell’evento.
_ Eventuale evento scatenante.
_ Indicazione di perdita di confine (boundary). Sono perdite dovute a un errore operativo ma i cui effetti sono conteggiati come rischio di credito o di mercato.
_ Adempimento di una norma disattesa che ha causato una sanzione (perdite adducibili al rischio di compliance).
Ambito di accadimento
_ Unità operativa dove ha avuto origine l’evento: per capire se ci sono concentrazioni di particolari tipi di eventi in certi ambiti, ad esempio in particolari aree geografiche.
_ Processo (sequenze di operazioni finalizzate all’espletamento dell’attività bancaria): per capire se ci sono particolari attività a rischio. In una unità operativa, ad esempio, si com-mettono più errori nell’esecuzione di certe attività piuttosto che altre. Potrebbe essere un problema di scarsa preparazione del personale o di procedure inadeguate, di carenza di controlli o di applicativi mal progettati.
_ Business line interessata.
Effetti economici
_ Importo lordo della perdita e riferimenti contabili.
_ Eventuali accantonamenti previsti quando si può solo stimare l’entità della perdita. Si pensi a contenziosi dove non si conosce l’impatto economico se non dopo l’intero iter giudizia-rio.
_ Dati degli eventuali recuperi assicurativi.
FASI DELLA RACCOLTA PERDITE
Possiamo delineare un ipotetico processo di raccolta perdite come segue (Figura 1).
(cliccare sull’immagine per visualizzarla correttamente)
Ci sono principalmente due possibilità per arrivare a censire una perdita operativa:
1. Segnalazione da parte del personale
Il personale dell’unità operativa di accadimento segnala una perdita di cui viene a conoscenza. Un esempio: c’è un errore durante l’esecuzione di un ordine di borsa: una quantità al posto di un’altra. Il mercato non è propizio e c’è una perdita sulle posizioni eccedenti: un tipico esempio di perdita boundary.
In genere la cultura del rischio nelle banche non è molto diffusa, le persone tendono a non riconoscere le perdite operative e a farle rientrare in altre categorie. Quando si trovano a segnalarle non sono sempre in grado di classificare correttamente gli eventi e normalmente ignorano come inquadrare formalmente la propria attività. Per questo motivo la segnalazione dev’essere validata da un responsabile e, per perdite gravi, dal risk manager o da una figura con competenze equivalenti.
Una volta controllati tutti i dati l’importo va autorizzato. La catena di autorizzazione può anche diventare molto complessa con vari livelli di approvazione che dipendono dal tipo di evento e da un plafond annuale. Tutte le perdite operative devono, secondo la norma vigente, avere corrispondenza in bilancio. L’ultimo passaggio consiste nella contabilizzazione della perdita.
2. Inserimento da poste contabili
La raccolta dei dati di perdita avviene direttamente dalla contabilità. Un caso tipico è l’ammanco di cassa in filiale che non consente di quadrare la cassa giornaliera se non con un movimento contabile apposito. In questi casi si cerca di costruire delle interfacce che, monitorando periodicamente le prime note contabili, ricercano delle causali plausibili di perdite operative e poi aprono una segnalazione nel sistema di raccolta integrandola ove possibile in modo euristico.
SOGLIE
Non tutti gli eventi debbono essere censiti, non siamo interessati a registrare la scomparsa di una matita, ma solo perdite sopra una certa soglia. La scelta della soglia ha una certa importanza, perché condiziona il modello statistico e se troppo elevata può nascondere una serie di eventi che sommati insieme diventano significativi.
IMPATTI SUI SISTEMI
Un sistema di raccolta perdite comporta la realizzazione di un’applicazione distribuita. Il tipo di soluzione dipende dall’architettura informatica della banca. Potrebbe essere un’applicazione web based oppure una procedura ospitata sul mainframe.
Possiamo schematizzarne l’architettura come in figura 2.
Figura 2 – Sistema informatico di raccolta perdite
Il nucleo applicativo è formato dal database delle perdite operative e dall’applicazione che permette agli utenti delle filiali e degli uffici centrali di inserire i dati dell’evento. Un sistema di workflow management gestisce il ciclo di approvazione dei dati dell’evento e della spesa. Il nucleo si deve interfacciare con i sistemi centrali per la contabilizzazione e per rilevare i dati di eventi di perdita determinati da particolari movimenti contabili. Se la banca amministra carte di credito avrà un sistema di gestione degli allarmi e delle frodi. Questi eventi devono confluire direttamente nel database delle perdite operative. Per loro natura, le frodi su carta consistono di un insieme di usi illeciti in tempi diversi. Questi eventi sono detti perdite sequenziali e vanno ricondotti a un unico schema. Il processo di caricamento di questi dati deve permetterne l’integrazione e la modifica successiva.
Dal database delle perdite operative si producono report e si alimentano anche sistemi di KRI (Key Risk Indicators). Inoltre si determinano le distribuzioni di probabilità indispensabili per implementare i modelli statistici di calcolo del capitale regolamentare.
La collezione delle perdite è solo un tassello del processo di gestione del rischio operativo che può essere supportato anche da altri applicativi, si pensi ai sistemi di modellazione dei processi oppure a sistemi di legal inventory che catalogano gli adempimenti di norme che se non rispettate portano a “perdite compliance” (adducibili al rischio di compliance).
Come si vede, un sistema di raccolta perdite operative tocca tutti i gangli vitali del sistema informativo aziendale, per questo è difficile che si possano trovare sul mercato suite applicative che possono essere implementate “As Is”.
La nostra esperienza ha mostrato un panorama fortemente variegato, dove non esiste un attore principale del mercato e ci sono iniziative artigianali di alcuni risk manager che fanno raccolta perdite con i database personali sui loro Pc. Le banche che hanno esternalizzato la gestione dei loro sistemi hanno l’ulteriore problema di non disporre della completa libertà di realizzare applicativi ad hoc o comprare sul mercato.
CONCLUSIONI
Il database delle perdite operative è una miniera di informazioni utili per il risk manager a patto che vengano opportunamente registrati anche tutte i dati relativi al contesto nel quale l’evento è avvenuto.
Sono sconsigliabili soluzioni “fai da te” con strumenti di informatica personale perché una collezione non adeguatamente controllata, scollegata da un processo di governo, oltre a non consentire l’adozione di metodi avanzati, finisce con il distorcere la percezione del rischio.
Figura 1 – Ipotetico processo di raccolta perdite attraverso due possibilità di censimento: segnalazione da parte del personale; rilevamento dal sistema
