Risk Management

Soluzioni Applicative per il Risk Management: 

IT e Innovazione tecnologica applicate 

ai Sistemi di Risk Mangement 

Un approccio innovativo

Agenda: Indice degli argomenti trattati 

Premessa 

Risk Management e Sistemi Informativi 

Rischio di Credito 

Definizione funzionale e sistemi informativi 

Soluzioni applicative 

Rischio di Mercato 



Rischio di Controparte 



Rischio Operativo 



Integrazione dei Rischi 

Aspetti funzionali 

Architetture applicative 

Conclusioni

Premessa 

Nell’attuale contesto di particolare turbolenza dei mercati finanziari, le soluzioni 

applicative a supporto del Risk Management svolgono un ruolo fondamentale per: 

l’accuratezza e la tempestività nella 

determinazione di misure di rischio e rendimento; 

l’elaborazione delle potenziali evoluzioni di 

portafoglio e di dinamica dei fattori di rischio in 

funzione dell’ operatività sui mercati; 

l’applicazione continua di esercizi di simulazione e 

di stress testing con logica full evaluation del 

portafoglio; 

l’elaborazione dei rischi in ottica integrata di 

Enterprise wide Risk Management. 

Massimizzazione del profilo rischio/rendimento (risk appetite)

Risk Management e Sistemi Informativi 

Il Consorzio Operativo GruppoMontepaschi ha supportato il Risk Management 

nella progettazione e nello sviluppo di una serie di soluzioni applicative in risposta ad 

esigenze via via più complesse. 

Esigenze Risposte 

Performance dei sistemi 

di misurazione dei rischi 

Sofisticatezza Sofisticazione dei modelli matematici 

Sistemi di analisi e controllo 

Archiviazione delle informazioni /dati 

Fruibilità delle informazioni 

Richieste on-demand 

Articolate analisi di simulazione di portafoglio 

Elevata complessità computazionale 

di spazio e di tempo 

Integrazione architetture e applicazioni 

Reporting direzionale 

Algoritmi time-consuming 

di simulazione Monte Carlo 

Reporting operativo on-demand 

Sistemi complessi di archiviazione dati 

(tracciabilità e rintracciabilità) 

Stress testing con molteplicità di fattori di rischio 

Data Quality

Rischio di Credito - Definizione funzionale e Sistemi Informativi 

Il rischio di credito consiste nelle variazioni inattese nel valore di 

mercato di un’esposizione, o di un portafoglio di esposizioni creditizie, 

dovuto a movimenti avversi del merito di credito della controparte. 

Capitale Regolamentare: modello AIRB 

Molteplicità ed eterogeneità di fonti dati 

Verifica, validazione, archiviazione e storicizzazioni dati 

Calibrazione periodica dei modelli validati 

Reporting a tutti i livelli 

Capitale Interno: Modello di Portafoglio Simulativo 

Complessità degli algoritmi di elaborazione 

Simulazioni MonteCarlo multistep 

Verifica, validazione, archiviazione e 

storicizzazioni dati 

Modello multidimensionale 


Probability Probability Density Density Function Function 

of of Losses Losses 

Expected loss 

Allocated economic capital 

CreditVaR 

Problemi RM Soluzioni IT 

Data Warehouse 

Catastrophe loss 

Business Intelligence

Rischio di Credito - Soluzioni Applicative 

Il data warehousing è un ambiente che copre un’area nella quale si dispone di informazioni, derivate dai diversi 

sistemi LOB (line of business), rielaborati in differenti strutture dati con finalità di analisi e reportistica. 

Per loro natura, le applicazioni LOB poggiano su strutture dati più orientate al dettaglio, che poco si adattano a 

esigenze di sintesi: 

Struttura Finalità 

Relazionale Gestione storico 

OLTP (applicazioni LOB) Data Warehouse / OLAP (on line analysis processing) 

Informazioni di dettaglio 

(es. numero di posti liberi in data 22/02/2002 sul volo Milano 

– Copenaghen delle 09:00 ) 

Normalizzazione dati 

Reportistica 

Informazioni aggregate 

(es. media dei posti liberi sui voli Italia-Danimarca, su periodi 

mensili/annuali, in diverse fasce orarie) 

Visione sul dato attuale Visione su storico / sintesi / dato aggregato 

Es: numero posti liberi in data x sul volo Milano-Roma Es: Media dei posti liberi sui voli in Italia nel mese/anno 

Consente di eseguire attività 

(es.vendere il biglietto). 

Consente di eseguire decisioni 

(es.sopprimere un volo scarsamente frequentato). 

Da un concetto di data warehousing puro, che nella forma più semplice consiste in una normalizzazione delle diverse 

sorgenti dati, si passa al concetto più esteso della Business Intelligence, dove le strutture dati subiscono una modifica 

sostanziale ed un’elaborazione più spinta (strutture OLAP) per consentire il pre-calcolo delle aggregazioni che saranno 

richieste dall’utente in fase di analisi o reportistica avanzata. 

Data 

Warehouse 

Struttura Finalità 

Multidimensionale Reportistica avanzata 

OLAP 

Analisi e Pivoting 

Data mining 

Caratteristiche comuni 

Data Quality 

Data Dictionary 

Maggiore capacità di 

analisi avanzate

Rischio di Mercato - Definizione funzionale e sistemi informativi 

Il rischio di mercato è definito come la massima perdita 

finanziaria potenziale che si può verificare sulle posizioni 

detenute in portafoglio, a seguito di variazioni sfavorevoli 

nei parametri di mercato rilevanti (risk factors). 

Problemi RM 

Modelli di stress testing dei fattori di rischio 

(sensitivity vs scenario) 


Simulazioni giornaliere di variazioni 

ipotetiche di portafoglio (analisi di what if) 

Simulazioni storiche di molteplici fattori di mercato 

Modelli di pricing (flexible) 

Elaborazioni giornaliere dei modelli di portafoglio 

,027 

,020 

,013 

,007 

,000 

0 

0,50 1,75 3,00 4,25 5,50 

Soluzioni IT 

Grid Architetture 

Schede CUDA 

539 

404,2 

269,5 

134,7

Rischio di Mercato - Soluzioni Applicative 

Infrastruttura software che abilita un numero di computer isolati (server, workstation o 

anche desktop) a comportarsi come un singolo server multiprocessore. 

Caratteristiche 

Architettura GRID - definizione 

Non richiede particolari tipologie di rete o computer, ben 

adattandosi ai computer già esistenti in azienda 

Comporta una drastica riduzione dei tempi di calcolo grazie alla 

esecuzione parallela di più pacchetti di lavoro 

SINGLE SERVER 

GRID APPROACH 

START 25000 operations 

STOP 

5000 op. 

5000 op. 

START 5000 op. 

STOP 

5000 op. 

5000 op. 

TIME


Il componente chiave di una architettura GRID è il Resource Manager, che si occupa 

di smistare i pacchetti di lavoro in cui è stato suddiviso il calcolo complessivo verso i 

computer (o “nodi”) liberi, scelti tra quelli iscritti nell’infrastruttura. 

In maniera simile alla torre di controllo di un aeroporto, che organizza ed ordina tutti 

gli aerei in atterraggio e decollo in modo che condividano le stesse piste, allo stesso 

modo il Resource Manager sapendo quali sono i computer disponibili e quali sono 

quelli più scarichi fa si che le richieste di elaborazione vengano eseguite dai computer 

meno occupati, evitando di congestionare i computer che già stanno lavorando. 

…vantaggi 

I nodi possono essere condivisi con altre applicazioni 

Il Resource Manager identifica e corregge eventuali 

failure di un nodo reindirizzando il pacchetto di 

lavoro verso altri nodi disponibili 

Massima valorizzazione del parco macchine 

(utilizzando anche Desktop e workstation)


Evoluzione 

Il modello CUDA 

Il modello CUDA trae origine dal fenomeno di rapida evoluzione delle schede 

video a fronte delle richieste di mercato in termini di editing video e gaming. 

Negli ultimi anni le aziende del settore hanno commercializzato un numero 

crescente di schede grafiche con performance di assoluto rilievo in termini di 

capacità di calcolo. 

Dalla comparazione fra la capacità di calcolo dei nuovi processori grafici 

(GPU- Graphics Processing Unit) ed il costo di acquisto, è in corso una 

variazione del paradigma che vede la scheda video non più dedicata alla sola 

grafica, ma utilizzata da altre tipologie di applicazioni che per loro natura 

sono CPU intensive 

…vantaggi 

Elevata capacità di calcolo 

Ottimo rapporto prezzo/prestazioni 

Migliori prestazioni 

Prime evidenze 

… la scheda CUDA può raggiungere la potenza di 100 CPU ed è più 

perfomante quanto più complesso è lo strumento di cui si valuta il VaR


Altri territori da esplorare 

Il gruppo MPS monitora costantemente il 

mercato alla ricerca di tecnologie che 

sfruttano il calcolo parallelo e che 

potrebbero essere utilizzate in campo 

finanziario per ridurre i tempi di 

elaborazione. Una di queste è costituita 

dai dispositivi FPGA (Field Programmable 

Gate Array), device digitali 

riprogrammabili che promettono capacità 

di calcolo di 400 CPU in un singolo 

dispositivo.

Rischio di Controparte - Definizione funzionale e sistemi informativi 

Il rischio di controparte è il rischio che la controparte di 

una transazione avente a oggetto determinati strumenti 

finanziari risulti inadempiente prima del regolamento della 

transazione stessa. 

Problemi RM 

Modelli di princing 

(derivati complessi) 

Simulazione Monte Carlo 

(n timestep e m/000 scenari) 

Soluzioni IT 

Schede Cuda 

Macchine Virtuali

Rischio di Controparte - Soluzioni Applicative 

Creazione di un ambiente computazionale isolato (macchina virtuale), sulla quale 

possa essere messo in esecuzione un sistema operativo completo. 

Il sistema operativo ospite 

lavora come se fosse in 

esecuzione direttamente su 

hardware fisico. Questo 

comportamento è reso possibile 

da un programma di controllo 

che è l’unico che accede alle 

risorse fisiche e le controlla 

rendendole disponibili alle 

macchine virtuali. 

…vantaggi 

Virtualizzazione - definizione 

Macchina 

Reale 

massimizzazione dello sfruttamento Hardware dell’azienda 

diminuzione dei costi dell’hardware 

Macchina Virtuale 1 

Applicazioni 1 

Sistema Operativo (Linux…) 

CPU, RAM, dischi, rete 

diminuzione dei costi di gestione e dei servizi di disaster recovery 

… 

Macchina Virtuale 1 

Applicazioni 1 

Sistema Operativo (Linux…) 

CPU, RAM, dischi, rete 

Programma di controllo (Virtual Platform) 

CPU(x86,ppc,…) motherboard, dischi, rete, RAM


Altri territori da esplorare 

Un’ altra tecnologia in corso di valutazione 

è rappresentata dal Cloud Computing 

attraverso l’utilizzo di Open Nebula. 

In questa prima fase stiamo lavorando 

nella direzione di un Internal Cloud. In 

prospettiva questo modello è adatto a 

sperimentare soluzioni che vedano il 

ricorso a potenza di calcolo esterna 

(strabordo) in situazione di saturazione 

della potenza interna.

Costo ell’informazione (€) 

Rischio Operativo - Definizione funzionale e sistemi informativi 

Il rischio operativo è il rischio di subire perdite derivanti 

dall’inadeguatezza o dalla disfunzione di procedure, risorse umane e 

sistemi interni, oppure da eventi esogeni. 

General Ledger Level 

Management DB 

Level 

G.MontePaschi 

Le informazioni raccolte a livello di branch assicurano 

la completezza delle informazioni a fronte, però, di un 

significativo effort in termini di gestione e di IT. 

Le informazioni sulle perdite operative sono raccolte in un DB. A 

questo livello è possibile definire un owner responsabile 

dell’accuratezza e completezza delle informazioni raccolte. 

Livello ottimale per la gestione dei rischi operativi : 

un sistema contabile in cui sono dettagliate tutte le 

informazioni relative alle perdite potenziali. 

Dettagli delle informazioni 

Branches Level

Rischio Operativo - Soluzioni Applicative 

Il trattamento delle informazioni relative a tale rischio, è in carico all’applicativo OpRisk. 

L’infrastruttura supporta tutte le fasi di governo del rischio operativo di competenza delle 

società del Gruppo MPS. 

Il software utilizzato permette di 

Storicizzare i dati di perdita; 

Elaborare analisi quantitative; 

Creare scenari di tipo simulativo 

Integrità del dato 

Caratteristiche 

Tracciabilità 

Accesso 

Data 

Warehouse 

OLAP

Integrazione dei Rischi - aspetti funzionali 

Il Gruppo MPS determina il capitale interno 

complessivo atto a fronteggiare tutti i rischi a 

cui il Gruppo Bancario risulta esposto in 

condizioni fisiologiche di mercato ed in ipotesi di 

stress test mediante un approccio simulativo a 

copula. 

Complessità e numerosità delle prove di stress testing e di stima 

delle misure prospettiche di capitale interno 

Analisi di back testing dei risultati 

Eterogeneità dei flussi relativi ai singoli rischi 

complessità dei modelli di integrazione 

(numerose simulazioni MC) 

iRisk 

Molteplicità ed eterogeneità dei modelli di stima dei singoli rischi 

Strumenti di controllo e di validazione della qualità del dato 

Reporting operativo e direzionale 

Calibrazioni periodiche dei parametri di stima 

Tracciabilità e rintracciabilità delle elaborazione a tutti i livelli di calcolo

Integrazione dei Rischi- architetture applicative 

I principi di organizzazione secondo un modello SOA rispondono ad esigenze di controllo della 

complessa organizzazione dei processi. 

SOA definisce un modello in cui la logica complessiva di automazione è partizionata in unità più 

semplici e distinte (o servizi) che rappresentano i sottoprocessi, ove le chiamate fra servizi avvengono 

in maniera trasparente. 

Agilità ed efficienza, in un modello SOA, derivano da 3 caratteristiche principali: 

•Flessibilità e facilità di manutenzione - Un servizio presenta necessariamente un grado di 

complessità inferiore che implica migliore capacità di manutenzione. La scomposizione in unità isolate 

ma omogenee dal punto di vista funzionale garantisce la flessibilità necessaria per rispondere alle 

modifiche dei business requirements. 

•Riutilizzo – I servizi, progettati come unità elementari, presentano un grado di riutilizzo elevato. 

•Disaccoppiamento funzionale e tecnologico – L’isolamento delle funzionalità in servizi consente il 

disaccoppiamento necessario e fondamentale fra l’evoluzione a medio e lungo termine dei requisiti 

business con i cicli di innovazione tecnologica che intrinsecamente hanno natura a breve termine.

Conclusioni 

La struttura IT è “condannata” a rispondere alle nuove sfide esplorando 

continuamente soluzioni innovative per i sistemi di Risk Management. 

La principale difficoltà consiste nel ripensare soluzioni emergenti sul mercato ai fini 

di rispondere alle complessità operative del Risk Management.

Financial Data 

WareHouse 

Applicazione di tecniche di 

warehousing alla finanza 

FDWH

Sommario 

•Modellazione di un DataWarehouse 

•Componenti di un modello di Data 

Warehouse 

• Differenze tra DB relazionali 

normalizzati e Data Warehouse 

• Star Schema e Snowflake Schema 

• Applicazioni alla finanza 

FDWH

Data Warehouse - Definizione 

W.H.Immon, è stato il primo a parlare di data 

warehouse (letteralmente magazzino dati), lo 

definisce come: 

– A subject-oriented, integrated, time-variant and 

non-volatile collection of data in support of 

management's decision making. 

● Subject-oriented: 

– organizzato attorno a degli specifici aspetti 

dell'azienda (clienti, vendite, ordini, etc...) 

– focalizzato sui dati utili al processo decisionale, e 

non sulle operazioni giornaliere 

– contiene tipicamente dati aggregati 

FDWH


● Integrated 

– integra dati da sorgenti diverse e di tipo eterogeneo 

(database relazionali, file di testo, database transazionali, 

etc...) 

– assicura la consistenza dei dati integrati utilizzando tecniche 

di data cleaning e data integration. 

● i dati vengono convertiti per assicurarne la consistenza e solo 

successivamente inseriti nel Data Warehouse 

● Time-variant 

– i dati non forniscono solo informazioni attuali ma hanno una 

prospettiva storica (per esempio, dati sugli ultimi 5-10 anni) 

FDWH


Non volatile 

– è un archivio fisicamente separato dalle basi di 

dati usate per le operazioni quotidiane. 

● non è possibile dunque che si tratti di una “vista” 

all'interno del database operativo. 

– non richiede operazioni di aggiornamento continuo 

e dunque non necessità di supporto per la gestione 

delle transazioni e della concorrenza. 

– le uniche operazioni effettuabili su un data 

warehouse sono il caricamento iniziale dei dati e 

l'accesso in lettura. 

FDWH


… IN CONCLUSIONE… 

Un data warehouse è una raccolta organica di 

informazioni da più sorgenti anche eterogenee 

(database aziendali, database di 

altre aziende, internet, flat file) che 

– è mantenuta separatamente dal database 

principale della organizzazione; 

– serve da supporto per le attività decisionali, 

fornendo una serie di dati storici consistenti. 

FDWH

Data Warehouse – Obiettivi e finalità 

•Possibilità di accedere a tutti i dati 

centralizzati in un solo database 

•Coerenza e consolidamento dei dati 

•Velocità nell’accesso alle informazioni 

•Strumento di supporto decisionale 

•Base informativa per costruire sistemi di 

analisi e previsione: 

•Reports 

•On-Line Analytical Processing (OLAP) 

•Data Mining 

FDWH

Data Warehouse – OLAP, OLPT 

I sistemi informativi che si poggiano su un database 

tradizionale vengono spesso chiamati sistemi OLTP (online 

transaction processing). 

– La loro funzione è eseguire le operazioni giornaliere: 

modifica dei dati e semplici operazioni di lettura. 

● Un data-warehouse, invece, è il cuore di un sistema 

OLAP (online analytical processing). 

– La loro funzione è fornire supporto a operazioni di analisi 

dei dati e a processi decisionali. 

FDWH

FDWH 

DB Olap 

Caratteristiche di un database per un ambiente 

analitico: 

•Entità denormalizzate 

•Disegno del database più semplice (meno tabelle e 

meno associazioni) per una comprensione più facile 

da parte dell’utente 

•I dati memorizzati possono essere aggregati 

(riassuntivi) 

•Le interrogazioni richiedono poche join 

•Ottimizzato per la consultazione, per l’utente è 

read-only

1 

2 

Data Warehouse – Architettura 

Source OLTP 

Systems 

Data 

Warehouse 

FDWH 

Data Marts 

3 4 5 

Clients 

Retrieve Data Populate Populate Query 

Transform Data Data Warehouse Data Marts Data

Market Risk Management 

Siena 3 giugno 2011 

Ufficio Finanza e Risk Management

IT FOR FINANCE 

MARKET RISK MANAGEMENT


















MARKET RISK MANAGEMENT 

4.5.4





4 h escludendo le flex options



Requisiti Regolamentari: Modello Interno per i Rischi di Mercato 

Le banche che utilizzano il Modello Interno devono soddisfare un requisito patrimoniale 

corrispondente al maggiore tra i due importi seguenti: 

1. La misura del valore a rischio (VaR) del giorno precedente sommata, ove del caso, al 

requisito aggiuntivo per il rischio di default; 

2. La media delle misure del VaR giornaliero nei 60 giorni operativi precedenti, moltiplicata 

per un fattore non inferiore a 3, eventualmente maggiorato sulla base dei risultati dei test 

retrospettivi e sommata ove nel caso al requisito aggiuntivo per il rischio di default. 

C 

t 

max 

VaRGS 

t 

1 

; 

* 

1 

60 

60 

i 

1 

VaRGS 

t 

i 

RD



Calcolo del Requisito Patrimoniale a fronte dei Rischi di Mercato 

C 

t 

max 

VaRGS 

t 1 

; 

1 

* 

60 

60 

i 1 

VaRGS 

t 

i 

dove: 

•Ct: è il requisito patrimoniale al giorno t; 

• VaRGSt-i: è il VaR Generico-Specifico ovvero il Value at Risk calcolato secondo il modello interno per il 

portafoglio detenuto al giorno t-i (i=1,2,3,…60) e relativo al rischio Generico e Specifico (idiosincratico e di 

evento); il VaR deve essere al 99% a 10 giorni. 

• β : rappresenta il fattore moltiplicativo pari a 3, eventualmente maggiorato fino a 4 da parte di Banca d’Italia, in 

seguito alla risultanza negativa dei test retrospettivi o a fronte di accertate inadeguatezze del modello; 

RD: identifica la porzione di Rischio di Default eventualmente non considerata nel modello all’interno del 

VaRGS. L’RD identificato in letteratura anche come Incremental Default Risk Charge (IDRC) rappresenta la 

vera novità di Basilea 2 per quanto riguarda i Rischi di Mercato. Occorre precisare che al momento non sono 

disponibili best practices internazionali circa la determinazione/stima di questa componente e anche la Vigilanza 

non ha ancora rilasciato linee guida certe da applicare. 

RD



ARCHITETTURA TECNICA E APPLICATIVA IN MPS GROUP 

Architettura applicativa – Modello Interno 

Architettura applicativa - ALGO SUITE 

Architettura tecnica 

Schema macchine

INFO PROVIDER 

DWHR 

Anagrafiche e 

dati di mercato 

Misure 

di rischio 

ALGORITMICS 



SAF 

EAST 

Posizioni dati di mercato e 

strumenti OTC 

FDWH 

MUREX 

Viste 

Misure di rischio 

Albero dei portafogli 

Volatilità e dividendi discreti 

P&L -- Back testing effettivo 

Back Office 

TPRM 

INFO PROVIDER 

BCU



MUREX: applicativo in uso alle B.U. Finanza di gruppo. E’ utilizzato per intermediare le operazioni di Trading ed Hedging chiuse con 

controparti interne ed esterne. L’applicativo contiene le informazioni relative ai contratti intermediati, siano essi di posizione, di 

anagrafica o di mercato. Le valorizzazioni calcolate dall'applicativo, lì dove non siano disponibili valori di mercato, acquisiscono valore 

di ufficialità all'interno della Banca. Giornalmente, all’end of day del front office, i dati relativi a strumenti e posizioni vengono riportati 

sul DWH. 

EAST: applicativo che gestisce le informazioni anagrafiche e i dati di mercato consolidati delle attività finanziarie di varia natura 

(azioni, obbligazioni, warrant, fondi, derivati, altre attività finanziarie), oltre alle anagrafiche dei soggetti collegati alle attività 

finanziarie (emittenti e/o garanti e controparti). EAST è un presidio "Master" unico di gestione delle anagrafiche e dei dati di mercato da 

alimentare con informazioni corrette e affidabili. Il prodotto è "Multi - Istituto", ovvero è in grado di gestire, per ogni titolo, 

informazioni particolari per ogni banca. Giornalmente i dati relativi alle anagrafiche degli strumenti presenti nel portafoglio di 

negoziazione ed i dati di mercato vengono riportati sul DWH. 

TPRM: applicativo in dotazione alle Business Control Unit e al ARM (AreaRisk Management) per la gestione operativa dei controlli di 

linea (controllore dei parametri che entrano in Murex ai fini della validazione del P&L gestionale), per il monitoraggio dei limiti 

operativi a qualsiasi livello dell'albero dei portafogli e per la produzione della reportistica quotidiana. Nell'ambito dell'architettura 

applicativa svolge dunque il duplice ruolo di fornitore di dati (contributore dei parametri complessi, volatilità implicite e correlazioni, 

validati ai fini del calcolo delle misure di rischio) e di strumento di reportistica gestionale per gli operatori. TPRM fornisce inoltre la 

struttura dell’albero dei portafogli per finalità di Risk Management.





RISK MAPPER: Modulo di caricamento delle anagrafiche, delle posizione e dei dati di mercato tramite il servizio 

UDS. 

UDS (Algo Data Server): Servizio di I /O dati su AIDB. 

AIDB (Algo Input Data Base): Base dati non storica delle informazioni (anagrafiche, posizioni e dati di mercato) 

da fornire in input ai motori di calcolo. Permette di filtrare i dati per una elaborazione parallela. 

ASE DB (Algo Scenario Engine): Base dati dei fattori di rischio utilizzati nella generazione degli scenari storici. 

ASE Server: Motore di calcolo degli scenari storici utilizzati da Riskwatch per il calcolo degli indicatori di rischio. 

RISK WATCH: Motore di calcolo degli indicatori di rischio (VaR) tramite la valutazione delle posizioni detenute 

in portafoglio su ogni scenario generato dal modulo ASE. 

AHS (Algo Hierarchy Server), ARE (Algo Risk Engine), RPM (Report Production Manager): Server Algo per 

la riaggregazione dei cubi e la creazione dei reports che verranno storicizzati all’interno del DWH.





Nel disegno dell’architettura tecnica è stato attribuito particolare rilievo ai requisiti di performance, sicurezza (dei 

dati, del software e dell’hardware) e affidabilità. A tal proposito elementi qualificanti sono: 

il sistema operativo scelto per la Suite Algo – LINUX; 

l’architettura applicativa GRID che permette la scalabilità del sistema; 

l’ambiente di DISASTER RECOVERY - parco server composto da 2 application server xseries 8 processori, 2 DB Server Oracle 

4 processori, più 6 nodi di calcolo (server biprocessori) sul sito di Siena; 2 application server xseries 8 processori, 2 DB Server 

Oracle 4 processori, più 6 nodi di calcolo (server biprocessori) sul sito di Firenze. 

I dati sono su Storage Area Network, gestiti per il Disaster recovery. 

Ambienti distinti - produzione, collaudo, laboratorio, test, rigiro elaborazioni e disaster ricovery 

Monitoraggio processi - per l’applicativo (batch) viene utilizzato uno schedulatore IBM (OPC-TIVOLI), che permette il 

monitoraggio del processo applicativo presso l’ufficio del Consorzio “Presidio Flussi” (dalle 7.00 alle 3.20 del giorno seguente). 

Monitoraggio hardware, i servizi indispensabili ed il batch tramite il Guardian-Tivoli, che invia allarmi all’ufficio del Consorzio 

della Control Room, che presidia i sistemi 24 ore su 24, compresi i giorni festivi. 

Ci avvaliamo inoltre di tutti gli ausili informatici messi a disposizione dal Consorzio Operativo GMPS per le sicurezze, intese 

come riconoscimento dell’utente e relativa assegnazione di ruolo, nell’accesso ai dati e nella gestione del software (distribuzione 

automatizzata e versioning).

VaR 



Si effettua una “pesatura” degli strumenti per 

ottenere una serie di micro-elaborazioni 

computazionalmente uguali tra loro. 

. 

. 

. 

GRID 

Architettura per il calcolo parallelo 

Distribuito. Utilizza un insieme 

eterogeneo di macchine.





TPRM-System 

Equity Volatility 



• TPRM System è un software applicativo utilizzato nelle Risk Control Unit per il 

monitoraggio del P&L (Profit and Loss) e del rischio finanziario. 

• Applicativo che fa parte di TPRM System. 

• Genera una superficie di volatilità per ogni sottostante azionario. 

• La volatilità misura la potenziale variazione di prezzo di un azione. 

Utilizzo della volatilità 

• Pricing dello strumento finanziario opzione. 

• Calcolo del VaR (Value-at-Risk) definito come la perdita di valore di un portafoglio in un 

certo periodo di tempo e con una certa probabilità.



•La volatilità quotata dal mercato non è costante come è invece stato ipotizzato da Black-Scholes-Merton, ma varia in 

funzione del livello del prezzo futuro e della scadenza dell’opzione. 

•Propriamente, si osserva un profilo con smile (letteralmente "sorriso"), quando le opzioni ITM e OTM presentano una 

volatilità implicita superiore rispetto a quelle ATM. L’entità dello smile è misurata dalla differenza tra le volatilità implicite OTM 

e ATM. Non sempre si osserva uno smile simmetrico rispetto allo strike ATM per cui le differenze rispetto al valore ATM del 

dei put OTM (con strike inferiore al prezzo corrente) è superiore (o inferiore) a quella osservata per i call OTM (con strike 

superiore): un tale profilo può dipendere dall'asimmetria della distribuzione. Negli anni passati questo fenomeno era 

ricondotto all’esistenza di una minore liquidità di alcune tipologie di opzioni che giustificava l’applicazione di prezzi più elevati 

e quindi la presenza di una volatilità implicita maggiore. Un’altra spiegazione di questa situazione, relativamente alle opzioni 

OTM, era ricondotta all’effetto lotteria, alla possibilità cioè di poter ritrarre ampi payoff spendendo piccole somme di denaro; 

questo induceva gli operatori ad acquistare questo tipo di opzioni facendone salire il prezzo e di conseguenza anche la 

volatilità implicita. Spiegazioni più recenti riconducono, invece, l’effetto smile all’esistenza di due caratteristiche nella 

distribuzione a scadenza che i prezzi dell’attività sottostante possono assumere; esse sono: 

- la presenza di code spesse (fat tails); 

- l’esistenza di asimmetrie (skew). 

•Un secondo elemento che giustifica volatilità differenziate 

per strike è la presenza di un effetto skew (o asimmetria) 

nella distribuzione. Una distribuzione asimmetrica indica che 

le probabilità associate ad un rialzo o ad un ribasso nelle 

quotazioni dell’attività sottostante non sono uguali.

Interpolazione lineare: 



Input: matrice di volatilità puntuale (Scadenze x Strike), ottenuta da 

un elaborazione di dati prelevati dal mercato. 

Km 

Km 

Km 

Km 

( m, t) 

v( 

Km 

, t) 

v( 

Km 

, t) 

K K 

K K 

K m 

S 

m 

M 

m 

dove con s prezzo spot 

M vettore moneyness 

Fitting delle scadenze: 

σ( 

m) 

con 

x 

σ 

max 

( m) 

( m) 

min ( m) 

max ( m) 

x( 

m) 

m 

( T 

m 

t) 

e 

Tvettore scadenze 

t data considerata 

, parametri di ottimizzazione 

( T 

t)



Output: superficie continua di volatilità (Nuove Scadenze x Moneyness) 

Moneyness 

prezzo Strike 

prezzo Spot 

La nuova matrice 

viene spedita al 

motore di calcolo del 

VaR.

Crescente importanza delle schede video 

Nell’ambito della Computer Grafica 

Programmi di fotoritocco 

Progettazione CAD 

Computer animation 

In ambito entertainment 

Realizzazione di videogiochi 

Riproduzione di filmati in alta definizione 

Recentemente in ambito GPU computing 



Utilizzo di GPU nel Pricing di Strumenti 

Derivati Complessi 

Esecuzione di applicazioni non grafiche su hardware grafico quali: 

Simulazione di sistemi complessi (molecole, fluidi) 

Analisi dei segnali 

Applicazioni finanziarie 

…



GPU Computing: quali applicazioni? 

Le applicazioni si adattano bene all’hardware grafico se presentano: 

Elevata regolarità 

Elevato parallelismo 

Elevato volume di calcolo



I prodotti finanziari e il problema della loro valutazione 

Gli Strumenti Finanziari Derivati: 

Dipendenza da un “sottostante” (es.: merci, valute, azioni, …) 

Utilizzati per: 

Copertura di portafoglio 

Speculazione 

Arbitraggio 

Notevolmente raffinati ma complessi 

Difficile valutarli con tecniche analitiche 

Necessità di utilizzare tecniche numeriche quali il metodo Monte Carlo

Idea base: 



Il metodo Monte Carlo in finanza 

Si simula l’andamento del sottostante 

Si calcola il pay-off sulla base delle simulazioni 

Si ottiene il valore dello strumento come media di quelli ottenuti nelle varie simulazioni 

Caratteristiche: 

Risultati più affidabili al crescere del numero di simulazioni 

Computazionalmente oneroso 

Indipendenza delle simulazioni



NVIDIA CUDA 

(Compute Unified Device Architecture) 

Un semplice esempio: la somma di due vettori di 128 componenti 

//kernel 

__global__ void vectorSum(float *d_C, float*d_A, 

} 

float*d_B){ 

idx = blockIdx.x*blockDim.x + threadIdx.x; 

d_C[idx] = d_A[idx] + d_B[idx]; 

main(){ 

//puntatori ai dati nella memoria del device 

float *d_A, *d_B, *d_C; 

} 

... 

//invocazione del kernel che esegue la somma 

vectorSum>(d_C,d_A,d_B); 

... 

CUDA 

Thread 

+ 

+ 

+ 

+ 

+ 

+ 

+ 

= 

= 

= 

= 

= 

= 

= 

d_A d_B d_C



Architettura della prima 

GPU CUDA: il chip G80 

Nel chip G80: 

8 cluster (TPC) di multiprocessori 

2 multiprocessori (SM) per cluster 

8 processori scalari (SP) o core per multiprocessore 

In totale quindi 8*2*8 = 128 core 

Nelle recenti GPU NVIDIA (chip GT200) i core salgono a 240 

La GPU è organizzata 

come un array di 

multiprocessori detti 

Streaming 

Multiprocessors (SM)

Azione 1 

Azione 2 

Azione 3 

. 

. 

. 

Azione n 

Date di monitoraggio 



Le opzioni di tipo Altiplano 

1 m m+1 

2m 

Tempo 

Cedola 

1 

L’opzione periodicamente stacca cedole composte da: 

Cedola 

2 

Date pagamento 

cedola 

una componente fissa (indipendente dal sottostante) 

. . . 

Possiedono come sottostante 

un paniere di azioni (basket) 

Il sottostante viene osservato 

solo nelle “date di 

monitoraggio” 

una componente aggiuntiva (legata all’andamento del sottostante secondo le regole di 

pay-off) 

Cedola 

c-1 

... ... 

... 

2m+1 (c-1)m (c-1)m+1 

cm 

Cedola 

c



WORK IN PROGRESS E PROSSIMI SVILUPPI 

E-Rack 7118 Preconfigured Clusters 

8 Tesla S1070 Preconfigured Cluster 

• 32 Tesla T10 GPUs 

• 8 Server E7118 with Dual-socket Quad-core Xeon 2.66 GHz 

• 1 Server E7125 with Dual-socket Quad-core server Xeon 2.66 GHz 

• 128 GB GPU memory

Risk Management

Create successful ePaper yourself

Delete template?

Save as template?