Soluzioni Applicative per il Risk Management:

Transcript

1

2 Soluzioni Applicative per il Risk Management: Un approccio innovativo IT e Innovazione tecnologica applicate ai Sistemi di Risk Mangement

3 Agenda: Indice degli argomenti trattati Premessa Risk Management e Sistemi Informativi Rischio di Credito Definizione funzionale e sistemi informativi Soluzioni applicative Rischio di Mercato Definizione funzionale e sistemi informativi Soluzioni applicative Rischio di Controparte Definizione funzionale e sistemi informativi Soluzioni applicative Rischio Operativo Definizione funzionale e sistemi informativi Soluzioni applicative Integrazione dei Rischi Aspetti funzionali Architetture applicative Conclusioni

4 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)

5 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

6 Probability Density Function of Losses 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. Expected loss Allocated economic capital CreditVaR Catastrophe loss Problemi RM Soluzioni IT 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 Data Warehouse Capitale Interno: Modello di Portafoglio Simulativo Complessità degli algoritmi di elaborazione Simulazioni MonteCarlo multistep Verifica, validazione, archiviazione e storicizzazioni dati Modello multidimensionale Reporting a tutti i livelli Business Intelligence

7 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: OLTP (applicazioni LOB) Informazioni di dettaglio (es. numero di posti liberi in data 22/02/2002 sul volo Milano Copenaghen delle 09:00 ) Visione sul dato attuale Data Warehouse / OLAP (on line analysis processing) Informazioni aggregate (es. media dei posti liberi sui voli Italia-Danimarca, su periodi mensili/annuali, in diverse fasce orarie) 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. Struttura Finalità Struttura Finalità Caratteristiche comuni Relazionale Data Warehouse Gestione storico Normalizzazione dati Reportistica Multidimensionale OLAP Reportistica avanzata Analisi e Pivoting Data mining Data Quality Data Dictionary Maggiore capacità di analisi avanzate

8 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)., , ,2, ,5, ,7, ,50 1,75 3,00 4,25 5,50 Problemi RM Modelli di stress testing dei fattori di rischio (sensitivity vs scenario) Soluzioni IT Reporting a tutti i livelli Simulazioni giornaliere di variazioni ipotetiche di portafoglio (analisi di what if) Simulazioni storiche di molteplici fattori di mercato Modelli di pricing (flexible) Grid Architetture Schede CUDA Elaborazioni giornaliere dei modelli di portafoglio

9 Rischio di Mercato - Soluzioni Applicative Architettura GRID - definizione Infrastruttura software che abilita un numero di computer isolati (server, workstation o anche desktop) a comportarsi come un singolo server multiprocessore. Caratteristiche 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 START operations STOP 5000 op op. GRID APPROACH START 5000 op. STOP 5000 op op. TIME

10 Rischio di Mercato - Soluzioni Applicative 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)

11 Rischio di Mercato - Soluzioni Applicative 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

12 Rischio di Mercato - Soluzioni Applicative 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.

13 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 Soluzioni IT Modelli di princing (derivati complessi) Simulazione Monte Carlo (n timestep e m/000 scenari) Schede Cuda Macchine Virtuali

14 Rischio di Controparte - Soluzioni Applicative Virtualizzazione - definizione 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. Macchina Reale Macchina Virtuale 1 Applicazioni 1 Sistema Operativo (Linux ) CPU, RAM, dischi, rete Macchina Virtuale 1 Applicazioni 1 Sistema Operativo (Linux ) CPU, RAM, dischi, rete Programma di controllo (Virtual Platform) CPU(x86,ppc, ) motherboard, dischi, rete, RAM vantaggi massimizzazione dello sfruttamento Hardware dell azienda diminuzione dei costi dell hardware diminuzione dei costi di gestione e dei servizi di disaster recovery

15 Rischio di Mercato - Soluzioni Applicative 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.

16 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. Branches Level 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. Management DB Level G.MontePaschi 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. General Ledger Level 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

17 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 Caratteristiche Integrità del dato Tracciabilità Data Warehouse OLAP Accesso

18 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 Molteplicità ed eterogeneità dei modelli di stima dei singoli rischi Analisi di back testing dei risultati irisk Strumenti di controllo e di validazione della qualità del dato Reporting operativo e direzionale Eterogeneità dei flussi relativi ai singoli rischi Calibrazioni periodiche dei parametri di stima complessità dei modelli di integrazione (numerose simulazioni MC) Tracciabilità e rintracciabilità delle elaborazione a tutti i livelli di calcolo

19 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.

20 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.

21

22 Financial Data WareHouse Applicazione di tecniche di warehousing alla finanza FDWH

23 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

24 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

25 Data Warehouse - Definizione 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

26 Data Warehouse - Definizione 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

27 Data Warehouse - Definizione 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

28 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

29 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

30 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 FDWH

31 Data Warehouse Architettura Source OLTP Systems Data Marts Data Warehouse Clients Retrieve Data Populate Populate Query Transform Data Data Warehouse Data Marts Data FDWH

32 Market Risk Management Siena 3 giugno 2011 Ufficio Finanza e Risk Management

33

34

35

36

37

38

39

40

41

42 4.5.4

43

44 4 h escludendo le flex options

45 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 ; * i 1 VaRGS t i RD

46 Calcolo del Requisito Patrimoniale a fronte dei Rischi di Mercato C t max VaRGS t 1 ; 1 * 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

47 ARCHITETTURA TECNICA E APPLICATIVA IN MPS GROUP Architettura applicativa Modello Interno Architettura applicativa - ALGO SUITE Architettura tecnica Schema macchine

48 SAF INFO PROVIDER Anagrafiche e dati di mercato EAST MUREX INFO PROVIDER DWHR Posizioni dati di mercato e strumenti OTC FDWH Viste Misure di rischio Albero dei portafogli Volatilità e dividendi discreti P&L -- Back testing effettivo Back Office TPRM BCU Misure di rischio ALGORITMICS

49 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.

50

51 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.

52

53 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).

54 Si effettua una pesatura degli strumenti per ottenere una serie di micro-elaborazioni computazionalmente uguali tra loro. GRID VaR... Architettura per il calcolo parallelo Distribuito. Utilizza un insieme eterogeneo di macchine.

55

56

57 TPRM-System TPRM System è un software applicativo utilizzato nelle Risk Control Unit per il monitoraggio del P&L (Profit and Loss) e del rischio finanziario. Equity Volatility 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à.

58 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.

59 Input: matrice di volatilità puntuale (Scadenze x Strike), ottenuta da un elaborazione di dati prelevati dal mercato. Interpolazione lineare: 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 m m Fitting delle scadenze: σ( m) σ max ( m) x( m) ( T t) e ( T t) con x ( m) min ( m) max ( m) T vettore scadenze t data considerata, parametri di ottimizzazione

60 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.

61 Utilizzo di GPU nel Pricing di Strumenti Derivati Complessi 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 Esecuzione di applicazioni non grafiche su hardware grafico quali: Simulazione di sistemi complessi (molecole, fluidi) Analisi dei segnali Applicazioni finanziarie

62 GPU Computing: quali applicazioni? Le applicazioni si adattano bene all hardware grafico se presentano: Elevata regolarità Elevato parallelismo Elevato volume di calcolo

63 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

64 Il metodo Monte Carlo in finanza Idea base: 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

65 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<<< 1,128 >>>(d_c,d_a,d_b);... CUDA Thread + = d_a d_b d_c

66 Architettura della prima GPU CUDA: il chip G80 La GPU è organizzata come un array di multiprocessori detti Streaming Multiprocessors (SM) 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