La cooperazione PUMA tra la Banca d’Italia e gli intermediari per la produzione delle segnalazioni statistiche, di vigilanza e di risoluzione

La cooperazione PUMA tra la Banca d’Italia e gli intermediari per la produzione delle segnalazioni statistiche, di vigilanza e di risoluzione

Xxxxxxx Xxxx*, Xxxxx Xxxxxxxxx**, Xxxxxx Xxxxxxxx*, Xxxxxxx Xxxxxxxx*

Sommario

La Banca d'Italia raccoglie una gran quantità di informazioni – statistiche, di vigilanza e di risoluzione – dalle banche e dagli altri intermediari finanziari, al fine di svolgere le proprie funzioni istituzionali e soddisfare le esigenze di altre autorità, nazionali e internazionali, in particolare la BCE, l’EBA e l’SRB. Sin dalla fine degli anni ottanta del secolo scorso, la Banca d’Italia promuove una intensa cooperazione con il sistema attraverso la procedura PUMA (Procedura Unificata Matrici Aziendali), con l’obiettivo di fornire supporto agli intermediari e raccogliere elementi di interesse. La validità di questo approccio è stata ampiamente confermata anche nell’ambito delle trasformazioni del framework di reporting che sono state introdotte nel tempo a livello europeo.

Obiettivo del presente lavoro è descrivere le caratteristiche della PUMA, discutere i principali risultati conseguiti nel corso degli anni, illustrarne il ruolo svolto nell’ispirare analoghe iniziative intraprese a livello europeo e soffermarsi su come questa cooperazione tra la Banca d’Italia e il sistema rimarrà centrale negli anni a venire. In un contesto segnaletico caratterizzato da una crescente complessità, la PUMA ha permesso di realizzare un punto di equilibrio efficiente tra l’esigenza di supportare i produttori delle informazioni, perseguendo contestualmente obiettivi di qualità dei dati e di contenimento dei costi, da un lato, e il mantenimento in capo agli enti segnalanti delle responsabilità sulla produzione dei flussi segnaletici, dall’altro.

* Servizio Rilevazioni ed Elaborazioni Statistiche della Banca d’Italia.

** Iccrea Banca (Gruppo GBCI), Unità Organizzativa Politiche Normative e Principi Contabili, che dal 1994 partecipa ai lavori dei Gruppi funzionali PUMA

Indice

1. Introduzione 3

2. L’evoluzione delle segnalazioni statistiche, di vigilanza e di risoluzione 4

2.1 Le tre fasi “storiche” della raccolta dei dati bancari e finanziari 4

2.2 La CRR2 e la pandemia da COVID-19 e gli impatti sulle segnalazioni armonizzate 10

3. La PUMA e i processi di produzione dei dati dei segnalanti 11

3.1 L’esperienza PUMA all’interno della strategia della Banca d'Italia per l’integrazione statistica 12

3.2 Il contributo della PUMA e i fattori di successo 13

3.3 La PUMA come procedura metadata-driven 16

3.4 La definizione del dizionario PUMA 17

3.4.1 Le informazioni di input 17

3.4.2 Le regole di trasformazione 18

3.5 Il ruolo della cooperazione PUMA nel processo di innovazione segnaletica 20

3.5.1 L’interazione con il normatore 21

3.5.2 L’aggiornamento della documentazione PUMA 22

3.5.3 La diffusione della documentazione PUMA: sito Web e attività formativa 23

3.6 L’organizzazione della cooperazione 24

3.7 I vantaggi dell’esperienza PUMA 25

4. Altre esperienze di cooperazione tra banca centrale e industria 29

4.1 Austria 29

4.2 Il Banks’ Integrated Reporting Dictionary (BIRD) 31

4.3 Il confronto con la PUMA 33

5. Possibili sviluppi alternativi in campo regolamentare 35

5.1 Soluzioni RegTech 35

5.2 Modelli di “data-pull” 37

5.3 Osservazioni sugli approcci alternativi al reporting 38

6. Conclusioni 39

Bibliografia 42

1. Introduzione1

Le segnalazioni che gli intermediari bancari e finanziari sono tenuti a inviare periodicamente alla Banca d'Italia sono state interessate negli ultimi due decenni da una profonda evoluzione, caratterizzata da un continuo arricchimento delle informazioni trasmesse, da una maggiore tempestività e da una crescente complessità delle elaborazioni necessarie per produrle. Il contesto internazionale è stato il fattore trainante di questa evoluzione: la politica monetaria comune, che necessita di informazioni analitiche a supporto delle proprie strategie, l’avvio delle segnalazioni di vigilanza e di risoluzione armonizzate e l’esigenza di disporre di dati sempre più granulari hanno determinato profondi cambiamenti nell’assetto delle segnalazioni di competenza delle banche centrali. Il ruolo delle autorità sovranazionali nel definire gli obblighi segnaletici è diventato preponderante, così come è fortemente aumentata la domanda da esse espressa per dati di qualità sempre più elevata e pienamente armonizzati tra paesi, con una varietà e un livello di dettaglio tali da cogliere tempestivamente la maggiore complessità del comparto finanziario. In questo quadro si sono acuite le difficoltà degli enti segnalanti nel far fronte, in modo tempestivo e accurato, alle numerose, nuove richieste informative provenienti da più autorità e alle frequenti modifiche alle segnalazioni esistenti, nonché l’esigenza delle medesime autorità di disporre di un data-set informativo basato su interpretazioni normative coerenti tra i segnalanti.

In Italia, l’esperienza della cooperazione PUMA (Procedura Unificata Matrici Aziendali) tra gli intermediari bancari e finanziari e la Banca d’Italia, promossa e coordinata da quest’ultima, ha costituito negli anni una risposta alla crescente complessità del framework segnaletico. Avviata negli anni ottanta del secolo scorso, in un contesto in cui si stava avviando una fase di profonda automazione dei processi di elaborazione dei dati, la PUMA ha poi svolto un ruolo determinante nel promuovere e facilitare l’adozione dell’“approccio integrato” alla raccolta ed elaborazione dei dati che le banche e gli intermediari finanziari ex art. 106 del Testo Unico Bancario (TUB) sono tenuti a trasmettere alla Banca d’Italia2, contribuendo a migliorarne la qualità e a ridurre i costi di produzione. All’interno della Banca d'Italia la PUMA è il canale primario di contatto con gli enti segnalanti per le strutture che definiscono la normativa segnaletica; inoltre costituisce una fonte di conoscenze insostituibile per approfondire, fino all’estremo dettaglio, le problematiche interpretative e tecniche connesse con l’applicazione delle disposizioni segnaletiche. Analogamente, per gli enti segnalanti la PUMA è divenuta un componente essenziale dell’approccio aziendale agli obblighi di reporting statistico, utilizzabile nel continuo per implementare i framework informativi.

Negli ultimi anni la PUMA si è confrontata con esperienze avviate in altri contesti. In primo luogo, essa è diventata un punto di riferimento a livello internazionale per avviare analoghe iniziative di cooperazione con gli enti segnalanti. In particolare, il progetto strategico denominato Banks’ Integrated Reporting Dictionary (BIRD) del Sistema Europeo di Banche Centrali (SEBC), fortemente sostenuto dalla Banca d’Italia, si ispira direttamente alla soluzione PUMA per strutturare una collaborazione con l’industria bancaria europea nella definizione di regole standard per la produzione dei dati richiesti dalle Authority, in

1 Ringraziamo Xxxxxxxxx Xxxxxxx (Banca d’Italia – Servizio Regolamentazione e Analisi Macroprudenziale - RAM), Xxxxxxxxxx Xxxxxxxx (Professore ordinario di Economia degli intermediari finanziari presso l’Università di Roma Tor Vergata e Segretario Generale dell’Associazione Italiana per il Factoring – Assifact), Xxxxxxxxx xx Xxxxxxxxxxxxxxx (Executive Vice President e Head of Group Accounting & Regulatory Reporting di UniCredit) e Xxxxxxx Xxxxxxxxx (Banca d’Italia – Servizio Rilevazioni ed Elaborazioni statistiche - RES) per i loro preziosi commenti. Le opinioni e le conclusioni sono esclusivamente quelle degli autori e non rispecchiano necessariamente il punto di vista della Banca d'Italia.

2 “On the contrary, the integrated approach favours the identification and exploitation of the synergies and relationships between different segments of the Bank’s information assets. In so doing it aims to avoid, as far as possible, the duplication of data requests to reporters, thus helping to contain the reporting burden. Moreover, it increases the possibility of the cross-use of different information segments and, from a technological point of view, it also supports the application of significant economies of scale”, Casa et al. (2022). Cfr. infra par. 3.1.

particolare la BCE, l’EBA e l’SRB. In secondo luogo, la PUMA può essere messa in relazione con approcci di tipo diverso, quali quelli basati sul RegTech o su modelli di tipo “data-pull”.

Questo lavoro inquadra l’esperienza della PUMA nel contesto dell’evoluzione delle segnalazioni che le banche sono tenute a trasmettere alla Banca d’Italia e alle altre autorità (EBA, BCE, SRB). La sezione 2 delinea l’excursus storico sul complesso delle segnalazioni - statistiche, di vigilanza e di risoluzione - evidenziandone la crescente complessità. La sezione 3 descrive la cooperazione PUMA e ne illustra il contributo fornito alla produzione dei dati. Nella sezione 4 sono esposte le caratteristiche di altre esperienze di cooperazione nel reporting tra banca centrale ed enti segnalanti. La sezione 5 esamina alcuni approcci innovativi nel campo del regulatory reporting in corso di valutazione ovvero già adottati dalle autorità. Le conclusioni delineano il possibile scenario futuro della PUMA in un contesto segnaletico sempre più armonizzato a livello europeo.

2. L’evoluzione delle segnalazioni statistiche, di vigilanza e di risoluzione

L’evoluzione delle segnalazioni statistiche e di vigilanza della Banca d’Italia dalla prima, grande riforma della matrice dei conti3 del 1989 a oggi si configura come una vera e propria rivoluzione sotto i profili delle fonti normative e della quantità, varietà e modalità di raccolta delle informazioni. I principali cambiamenti nell’assetto istituzionale all’origine di questa evoluzione sono stati, in ordine temporale, i seguenti:

- la progressiva adozione dell’”approccio integrato” da parte della Banca d’Italia a partire dall’inizio degli anni novanta del secolo scorso (Casa et al., 2022);

- l’avvio, all’inizio del 1999, dell’ultima fase dell’Unione Economica e Monetaria (UEM), con l’introduzione della politica monetaria comune, e

- le risposte alla crisi finanziaria del 2007-2008, con l’istituzione nel 2011 dell’Autorità bancaria europea (European Banking Authority, EBA), con l’introduzione nel 2014 del Single Rulebook e del Meccanismo di Vigilanza Unico europeo (MVU) e del Meccanismo di Risoluzione Unico europeo (MRU) e con l’avvio nel 2018, in ambito Eurosistema, di alcune segnalazioni statistiche armonizzate altamente granulari.

Nel biennio 2020-2021, infine, la revisione del Capital Requirements Regulation (CRR) e la pandemia da COVID-19 hanno fatto emergere ulteriori esigenze informative.

Si tratta di un processo evolutivo ovviamente connesso alle esigenze di contesto economico, dal quale le autorità derivano le relative esigenze informative (a titolo di esempio attuale, si pensi alla tematica della transizione ecologica).

2.1 Le tre fasi storiche della raccolta dei dati bancari e finanziari

Con riferimento all’evoluzione della normativa in materia di segnalazioni statistiche, di vigilanza e di risoluzione sulle quali è competente la Banca d’Italia, si possono individuare tre periodi.

Nel primo, fino al 1998, il fondamento giuridico per la raccolta delle informazioni dai segnalanti (banche e società finanziarie) è stato rappresentato dalla normativa di vigilanza, con l’eccezione dei dati sull’usura,

3 La matrice dei conti è uno schema segnaletico onnicomprensivo che integra i fabbisogni informativi di utenti diversi.

raccolti sulla base della legge 7 marzo 1996, n. 108, e dei dati decadali, per i quali la rilevazione avviene su base volontaria. Le richieste di informazioni erano prevalentemente espressione di esigenze nazionali che originavano, con poche eccezioni, principalmente dalle finalità della vigilanza sugli intermediari bancari e finanziari e dall’analisi economica, competenze storicamente attribuite alla Banca d’Italia. I due blocchi principali delle segnalazioni erano costituiti dalle segnalazioni di vigilanza (quelle delle banche riunite nella cd. “matrice dei conti”) e da quelle alla Centrale dei rischi4. Queste ultime offrivano informazioni a livello di singolo debitore circa la sua esposizione creditizia nei confronti delle banche e delle società finanziarie, utili sia ai segnalanti stessi per la concessione e il monitoraggio del credito, sia alla Banca d’Italia per le attività di vigilanza, di ricerca economica e di valutazione del rischio dei prestiti bancari accettati come garanzie nelle operazioni di politica monetaria. Le segnalazioni di vigilanza avevano invece una natura multi-purpose, volta a cogliere informazioni aggregate di natura statistica (incluse quelle sui servizi di pagamento e di investimento) e contabile, nonché informazioni sui rischi assunti dagli intermediari (tipicamente, rischio di credito e di controparte, rischi di mercato e grandi rischi).

A tali esigenze, che hanno costituito il nucleo originario a fondamento degli obblighi segnaletici imposti agli intermediari, si sono affiancate nel tempo nuove responsabilità assegnate alla Banca d’Italia, connesse con la sorveglianza sui sistemi di pagamento, la supervisione sui mercati e la risoluzione e gestione delle crisi nei confronti degli intermediari bancari e non.

Con il progetto di integrazione del reporting indipendentemente dalla natura della segnalazione e dalla tipologia di ente segnalante, il modello dati utilizzato in modo trasversale a tutte le segnalazioni è diventato il “modello matriciale” (Xxx Xxxxxxx et al., 2007), sulla base del quale è stato implementato il dizionario statistico contenente tutte le definizioni e le relative codifiche delle richieste informative della Banca d’Italia (Casa et al., 2022). Queste ultime e il formato tecnico per lo scambio dei dati (per anni il cd. “formato PUMA” poi affiancato dal più moderno formato XML) sono stati resi noti e aggiornati nel tempo attraverso circolari della Banca d’Italia appositamente definite, in particolare la n. 154 del 1991 (Segnalazioni di vigilanza delle istituzioni creditizie e finanziarie. Schemi di rilevazione e istruzioni per l'inoltro dei flussi informativi).5

Nella seconda fase, che si colloca orientativamente tra il 1999 e il 2011, la Banca d’Italia, quale membro del SEBC, ha avviato la raccolta di informazioni ulteriori rispetto a quelle disponibili a livello nazionale per lo svolgimento delle funzioni di politica monetaria, supervisione sui sistemi di pagamento e tutela della stabilità finanziaria.

L’articolo 5 dello Statuto SEBC ha attribuito alla Banca centrale europea (BCE), assistita dalle banche centrali nazionali (BCN), il potere di raccogliere le informazioni statistiche necessarie allo svolgimento dei compiti direttamente dagli operatori economici o dalle competenti autorità nazionali. Il Regolamento (CE) n. 2533/98 del 23 novembre 1998 (Raccolta di informazioni statistiche da parte della Banca centrale europea), comunemente definito Umbrella Regulation, rappresenta una componente fondamentale del quadro normativo a sostegno dei compiti di raccolta di informazioni statistiche che fanno capo alla BCE. Il Regolamento stabilisce le tipologie di operatori economici nei confronti dei quali la BCE può esercitare i propri poteri di raccolta di informazioni statistiche, la natura di tali poteri (ad esempio la facoltà di imporre sanzioni), le condizioni per la protezione e l’utilizzo dei dati confidenziali e per la loro condivisione con il Sistema Statistico Europeo (SSE), composto dall’Eurostat e dagli istituti nazionali di statistica (INS), con le autorità incaricate della supervisione delle istituzioni finanziarie, dei mercati, delle infrastrutture e con quelle preposte alla tutela della stabilità finanziaria.

4 Le ulteriori raccolte di dati, talvolta inizialmente realizzate in forma separata, sono state progressivamente inserite nel complesso delle informazioni gestite secondo l’approccio integrato.

5 Le segnalazioni alla Centrale dei rischi, seppur integrate a livello di dizionario statistico, per la loro peculiarità hanno mantenuto modalità tecniche specifiche per lo scambio delle informazioni.

In questo quadro, la BCE svolge un ruolo fondamentale di raccordo nell’armonizzazione delle norme e delle modalità di raccolta, compilazione e distribuzione delle statistiche creditizie e finanziarie. Sulla base di tale Regolamento, il Consiglio Direttivo della BCE approva infatti (1) le regulations che fissano nello specifico gli obblighi statistici per i reporting agents e definiscono per ciascun caso la “actual reporting population”, (2) le guidelines rivolte alle BCN in materia statistica e (3) le decisions riguardanti, tra l’altro, il regime di riservatezza delle informazioni e le misure per assicurarne l’applicazione. Ai fini dell’oggetto di questo lavoro, un aspetto importante del Regolamento 2533/98, rimasto inalterato nei successivi emendamenti, è che esso autorizza le BCN all’utilizzo delle informazioni statistiche riservate raccolte ai sensi dei regolamenti statistici della BCE anche per l’esercizio della funzione di vigilanza o di altre funzioni ad esse attribuite che non rientrano nei compiti del SEBC.

La Banca d’Italia, al pari di altre BCN (di Spagna e Portogallo fin dall’inizio, di Croazia, Austria, Malta, Finlandia e, in parte, Francia da un secondo momento), ha deciso di continuare a raccogliere anche queste “nuove” informazioni all’interno di un framework nazionale integrato con gli altri dati bancari, operando una razionalizzazione complessiva della “matrice dei conti”. A tal fine, nella normativa secondaria sul reporting emanata dalla Banca d’Italia, i regolamenti della BCE sono elencati tra le fonti normative primarie per l’imposizione degli obblighi segnaletici, di norma accanto alla normativa di vigilanza, senza distinguere tra quanto viene raccolto per finalità di vigilanza e quanto per soddisfare le esigenze informative della BCE. Una così netta separazione non sarebbe peraltro stata possibile, poiché la maggior parte delle informazioni richieste alle banche soddisfano entrambi gli scopi.

L’ultima fase dell’evoluzione della normativa segnaletica è quella che si è venuta a determinare in risposta alla crisi finanziaria del 2007-2008. Coincide con l’istituzione del Single Rulebook, volto a garantire un quadro normativo solido e uniforme per facilitare il funzionamento del mercato interno e prevenire opportunità di arbitraggio normativo (Comitato di Basilea per la Vigilanza Bancaria, 2010a), con l’introduzione della vigilanza europea, cioè con l’istituzione nel 2011 dell’Autorità bancaria europea (European Banking Authority, EBA) e nel 2014 del Meccanismo di vigilanza unico (Single Supervisory Mechanism, SSM) e del Meccanismo di risoluzione unico (Single Resolution Mechanism, SRM) e con l’avvio in ambito Eurosistema, a settembre 2018, di alcune segnalazioni statistiche armonizzate altamente granulari (AnaCredit e Securities Holdings Statistics Group, SHSG).

Per la Banca d’Italia come per le altre banche centrali nazionali ne sono discesi nuovi oneri e vincoli rispetto alla raccolta delle informazioni richieste dalle suddette autorità.

I principali atti normativi introdotti per la realizzazione del Single Rulebook sono la Direttiva (UE) 36/2013 sull'accesso all'attività degli enti creditizi e sulla vigilanza prudenziale sugli enti creditizi e sulle imprese di investimento (Capital Requirements Directive, CRD) e il Regolamento (UE) 575/2013 sui requisiti patrimoniali (Capital Requirements Regulation, CRR) che, a partire dall’1 gennaio 2014, stabilisce i requisiti prudenziali direttamente applicabili agli enti creditizi e alle imprese di investimento (Commissione europea, 2013).

Il CRR comprende una serie di articoli con mandati specifici per l'EBA di elaborare norme tecniche di attuazione (Implementing Technical Standards, ITS) relative agli obblighi di segnalazione di vigilanza, finalizzati ad armonizzare le normative segnaletiche in Europa, con l'obiettivo in particolare di specificare formati uniformi, frequenza e date di trasmissione delle segnalazioni. Obblighi di segnalazione uniformi sono necessari per garantire condizioni eque di concorrenza tra gruppi comparabili di enti creditizi e imprese di investimento (level playing field) e una maggiore efficienza e convergenza delle pratiche di vigilanza; essi, inoltre, consentono alle autorità di vigilanza di valutare i rischi in modo coerente in tutta l’Unione europea (UE) e di confrontare efficacemente le banche e identificare i rischi sistemici emergenti.

Gli ITS stabiliscono gli obblighi di segnalazione relativi a fondi propri e requisiti di fondi propri, informazioni finanziarie, perdite derivanti da prestiti garantiti da beni immobili, grandi esposizioni, coefficiente di leva finanziaria e coefficienti di liquidità. Poiché gli ITS seguono l'ambito e il livello di applicazione stabiliti nel CRR, si applicano agli enti creditizi e alle imprese di investimento, a livello (i) individuale e (ii) consolidato, con l’eccezione delle informazioni finanziarie per le quali l’ambito di applicazione è solo consolidato.

Gli ITS definiscono i dati richiesti, espressi in forma di template, e forniscono le istruzioni per la loro compilazione. In aggiunta l'EBA pubblica la documentazione tecnica che contiene il modello di rappresentazione dei dati (Data Point Model) e il formato di trasmissione degli stessi (XBRL), nonché le metodologie per la verifica della qualità delle informazioni (c.d. validation rules).

In questo modo l’EBA, sulla base della normativa europea6, ha introdotto nella raccolta statistica il principio della maximum harmonisation7 e imposto un primary reporting armonizzato nella UE, attraverso il cosiddetto Single Rulebook, che contempla – oltre ai citati ITS – anche gli Standard Tecnici di Regolamentazione (RTS), le Linee Guida (EBA Guidelines) e le Questions & Answers (EBA Q&A).

In questo quadro non è consentito alle autorità nazionali di disegnare uno schema segnaletico più dettagliato né di integrare le richieste informative armonizzate con dati richiesti per altre finalità. Tale soluzione si discosta da quella seguita dalla BCE nel 1998, quando lasciò piena autonomia alle BCN su come tradurre i requisiti delle regulation statistiche negli schemi nazionali di rilevazione. In un primo momento i “nuovi” dati necessari alla conduzione della vigilanza europea sono stati raccolti dalla Banca d’Italia sulla base sia dei regolamenti comunitari sia della normativa di vigilanza nazionale8. Nel giugno 2016 la Banca d’Italia decise di raccogliere le segnalazioni di vigilanza armonizzate facendo esclusivamente riferimento alla normativa comunitaria e al modello di rappresentazione dei dati definito dall’EBA9; la migrazione alla nuova modalità di raccolta – che ha rappresentato per gli enti segnalanti una netta discontinuità nelle modalità non soltanto tecniche di rappresentazione e gestione del reporting regolamentare – è stata completata a settembre 2018.

Per quanto concerne gli intermediari finanziari iscritti nell’albo previsto dall’art. 106 del Testo Unico Bancario, che non sono direttamente oggetto della disciplina prudenziale e segnaletica europea ma sono sottoposti a un regime di vigilanza prudenziale equivalente a quello delle banche, nel rispetto del principio di proporzionalità, la normativa segnaletica nazionale ha stabilito l’applicazione, con alcune particolarità, del regolamento di esecuzione che ha adottato gli ITS dell’EBA in materia di fondi propri e requisiti di fondi propri, informazioni finanziarie a livello consolidato e grandi esposizioni.

Con l’avvio dell’SSM, alla BCE sono stati attribuiti poteri di indagine, tra cui si annovera la “richiesta di informazioni” per l’assolvimento delle nuove funzioni; il quadro è dunque analogo a quello fronteggiato

6 Le principali fonti regolamentari che disciplinano il potere di raccogliere i dati sono: Reg. UE n. 575/2013 (c.d. "CRR"); Xxxxxxxxx UE n. 36/2013 (c.d. "CRD IV"); Xxxxxxxxx UE n. 59/2014 (c.d. "BRRD"); Reg. UE n. 806/2014 (c.d. "SRM Regulation"). I regolamenti di esecuzione che hanno adottato gli ITS sono i seguenti: Reg. UE n. 680/2014 e ss. (c.d. "Regolamento EBA-ITS"), poi sostituito dal Reg. UE 2021/451; Reg. UE n. 2070/2016 e ss. (in materia di Supervisory Benchmarking Exercise); Reg. UE 2018/1624 (informazioni ai fini dei piani di risoluzione); Reg. UE 2021/453 (in materia di Fundamental Review of Trading Book); Reg. 2021/763 (in materia di MREL/TLAC). Inoltre si devono considerare le Guidelines pubblicate dall’EBA, in particolare le Guidelines on Funding Plans (EBA/GL/2019/05).

7 Sulla base di tale principio la legge nazionale, nella fase di applicazione della normativa europea, non può discostarsi dai termini e dalle condizioni fissate da quest’ultima. Il principio proibisce cioè le prassi cc.dd. di “gold-plating” poste in essere dagli Stati membri in fase di recepimento nazionale della legislazione europea.

8 In Italia, per dare continuità al collaudato sistema segnaletico preesistente e contenere i costi della transizione, le regole europee sono state applicate, attraverso l’esercizio di un’opzione prevista dalla normativa comunitaria, disciplinando il primary reporting con le circolari segnaletiche della Banca d’Italia, la cui impostazione è stata tenuta ferma sui criteri nazionali di rilevazione dei dati (cd. “sistema matriciale”). A tal fine, le disposizioni sono state riarticolate in due parti distinte: una “armonizzata”, dai contenuti coincidenti con quelli europei, e una “non armonizzata”, comprendente altre informazioni di vigilanza.

9 La scelta iniziale operata dalla Banca d’Italia, descritta nella nota precedente, è stata abbandonata in considerazione della sua onerosità, per gli intermediari e per la Banca, e per evitare i connessi rischi operativi e legali.

a livello nazionale dalle autorità cui è affidata la responsabilità della vigilanza prudenziale. Il potere di raccogliere informazioni può essere esercitato dalla BCE sia direttamente, sia per il tramite delle autorità nazionali, in linea con lo schema operativo di raccolta “delegata” già previsto per gli obblighi statistici del SEBC. Per svolgere i nuovi compiti di vigilanza la BCE ha utilizzato per lo più le informazioni già richieste dall’EBA10; inoltre, a partire da dicembre 2015, l’SSM ha imposto alle banche ulteriori obblighi segnaletici con una regolamentazione specifica (FINREP su base individuale – Regolamento 534/2015).

Anche l’avvio del SRM ha comportato l’introduzione di nuovi obblighi informativi per le banche. Il Single Resolution Board (SRB), in cooperazione con le autorità di risoluzione nazionali, nel 2017 ha avviato la raccolta delle informazioni ai fini della redazione dei piani di risoluzione e della determinazione del requisito minimo di fondi propri e passività ammissibili assoggettabili a svalutazione e conversione per le maggiori banche europee. Oltre alle informazioni da fornire ai sensi dei regolamenti emanati in base agli ITS dell’EBA, le banche e i gruppi bancari sotto la competenza del SRB devono trasmettere informazioni aggiuntive sulla struttura delle passività, sulle funzioni critiche e sull’accesso ai sistemi di pagamento e alle infrastrutture di mercato. Infine, le banche sono tenute a segnalare i dati necessari per il calcolo della contribuzione ex-ante al Single Resolution Fund.

Oltre all’esigenza di armonizzare le normative segnaletiche in Europa e di colmare importanti lacune informative per le analisi di stabilità finanziaria (in particolare quelle sulla liquidità e sulla leva finanziaria), la crisi ha evidenziato la necessità di disporre di statistiche più granulari, per due ragioni principali. In primo luogo, la crisi ha mostrato come diversi settori economici, nonché singole imprese e famiglie nei diversi paesi dell'area dell'euro, abbiano reagito in modi molto diversi agli shock economici. La BCE – a fini di policy – deve analizzare e monitorare questi sviluppi; ciò vale a maggior ragione se si tiene conto che la BCE, ma anche le banche centrali nazionali e le altre autorità dell'area dell'euro, hanno assunto nuovi compiti in termini di vigilanza macroprudenziale, che hanno richiesto nuovi strumenti e conoscenze.

Le statistiche aggregate possono rivelarsi insufficienti per la valutazione approfondita di alcuni fenomeni economici. Ad esempio, la disponibilità di informazioni granulari sulle singole imprese relativamente ai crediti concessi e ai bilanci, è di grande utilità per individuare i driver di fondo dei finanziamenti e supportare le decisioni di policy (De Bonis, Piazza, 2020). Inoltre, la maggiore granularità delle informazioni richieste può essere vantaggiosa anche per gli enti segnalanti; è stato, in particolare, evidenziato come il trattamento dei dati a livello micro possa determinare un miglioramento della governance dei dati stessi (Xx Xxxxxxxxxxxxxxx, 2016).

Negli scorsi anni sono stati conseguiti importanti risultati rispetto alla disponibilità di basi dati granulari. Da settembre 2018, con l’avvio della rilevazione granulare AnaCredit11 sono disponibili per le banche centrali dell’Eurosistema le informazioni dettagliate armonizzate sui singoli prestiti bancari (con una soglia minima di 25.000 euro) concessi nell'area dell'euro alle controparti identificate come persone giuridiche. Dalla medesima data sono disponibili anche informazioni granulari sulla detenzione di titoli su scala globale da parte di tutti i gruppi bancari (SHSG) sotto la vigilanza diretta della BCE. Altri nuovi database granulari comprendono il reporting statistico sul mercato monetario (Money Market Statistical Reporting, MMSR, avviato nel 2016), che include i dati transazione per transazione su base giornaliera da più di cinquanta grandi banche dell’area dell’euro in quattro diversi segmenti del mercato monetario in

10 Nel Single Supervisory Mechanism (SSM) le informazioni raccolte sulla base degli ITS sono utilizzate dalla BCE per lo svolgimento dei propri compiti di supervisione, insieme ad ulteriori informazioni raccolte in base alla normativa emanata dalla BCE stessa. Seguendo il cosiddetto “approccio sequenziale” le segnalazioni di vigilanza armonizzate vengono trasmesse dalle banche alle autorità di vigilanza nazionali, che a loro volta le inviano alla BCE. Quest’ultima inoltra all’EBA le segnalazioni raccolte ai sensi dei regolamenti di esecuzione che adottano gli ITS dell’EBA o di Guidelines dell’EBA, evitando in tal modo un double reporting.

11 AnaCredit (analytical credit datasets) è una raccolta di informazioni dettagliate sui singoli prestiti bancari nell'area dell'euro. Per maggiori informazioni cfr. xxxxx://xxx.xxx.xxxxxx.xx/xxxxx/xxxxx_xxxxxx_xxxxxxx/xxxxxxxxx/xxxx/xxxxx.xx.xxxx .

euro, e le informazioni sulle transazioni in derivati (EMIR derivatives reporting) e sulle operazioni di finanziamento tramite titoli (Securities Financing Transactions Regulation, SFTR).

Si riepilogano di seguito le tre fasi sopra descritte in una tabella di sintesi:

Fase	Descrizione	Caratteristiche
Prima - dal 1989 al 1998	Adozione dell’”approccio integrato” da parte della Banca d’Italia	 Il modello dati utilizzato in modo trasversale a tutte le segnalazioni è diventato il “modello matriciale”, sulla base del quale è stato implementato il dizionario statistico contenente tutte le definizioni e le relative codifiche delle richieste informative  Le richieste di informazioni erano prevalentemente espressione di esigenze nazionali che originavano principalmente dalle finalità della vigilanza sugli intermediari bancari e finanziari e dall’analisi economica
Seconda – dal 1999 al 2010	Avvio dell’ultima fase dell’UEM, con l’introduzione della politica monetaria comune	 La Banca d’Italia, quale membro del SEBC, ha avviato la raccolta di informazioni ulteriori rispetto a quelle disponibili a livello nazionale per lo svolgimento delle funzioni di politica monetaria, supervisione sui sistemi di pagamento e tutela della stabilità finanziaria  La BCE svolge un ruolo fondamentale di raccordo nell’armonizzazione delle norme e delle modalità di raccolta, compilazione e distribuzione delle statistiche creditizie e finanziarie
Terza – dal 2011 ad oggi	Risposte alla crisi finanziaria del 2007-2008	 Istituzione del Single Rulebook, volto a garantire un quadro normativo solido e uniforme per facilitare il funzionamento del mercato interno e prevenire opportunità di arbitraggio normativo  Introduzione della vigilanza europea, con l’istituzione nel 2011 dell’EBA e nel 2014 del SSM e SRM  Avvio in ambito Eurosistema, nel 2018, di alcune segnalazioni statistiche armonizzate altamente granulari (AnaCredit e SHSG)  Ne sono discesi nuovi oneri e vincoli rispetto alla raccolta delle

informazioni richieste dalle suddette autorità

2.2 La CRR2 e la pandemia da COVID-19 e gli impatti sulle segnalazioni armonizzate

Nel 2019 sono state apportate due modifiche significative al CRR che hanno influito sulle segnalazioni di vigilanza:

 il Regolamento di modifica (UE) 2019/876 (Regolamento sui requisiti patrimoniali II – c.d. CRR2), che attua una serie di misure chiave nella UE per gli enti che coprono diversi ambiti informativi quali liquidità, leva finanziaria e grandi esposizioni;

 il Regolamento di modifica (UE) 2019/630 (Regolamento backstop), che stabilisce livelli minimi uniformi di copertura per garantire che gli enti dispongano di una copertura delle perdite sufficiente per future esposizioni deteriorate (Non Performing Exposures, NPE).

Le principali novità del CRR2, guidate da un principio di proporzionalità in virtù del quale sono state previste anche misure di alleggerimento degli oneri connessi agli obblighi di vigilanza a vantaggio dei soggetti più piccoli, sono volte a:

 ridurre la leva finanziaria eccessiva;

 fronteggiare il rischio di finanziamento a lungo termine;

 fronteggiare i rischi di mercato aumentando la sensibilità al rischio dei requisiti esistenti e rafforzando la proporzionalità del quadro prudenziale;

 contenere i costi di compliance per le banche piccole e non complesse senza compromettere la loro stabilità;

 migliorare la capacità di impiego delle banche a sostegno della crescita economica in particolare per le PMI;

 aumentare la capacità di assorbimento delle perdite e di ricapitalizzazione delle banche sistemiche (Global Systemically Important Institution, G-SIIs).

Il Regolamento backstop ha previsto l’introduzione, quale misura di primo pilastro, di livelli minimi uniformi di copertura delle perdite sulle esposizioni deteriorate. In particolare, la norma ha previsto che, laddove per ciascuna esposizione gli accantonamenti effettuati non siano almeno pari a tale livello minimo, gli enti sono tenuti a dedurre la relativa differenza dai fondi propri.

Inoltre, per mitigare le conseguenze economiche negative della pandemia da COVID-19, la UE e gli Stati membri hanno introdotto un'ampia gamma di misure a sostegno dell’economia reale e del settore finanziario. In particolare, alcuni paesi hanno stabilito “per legge” moratorie sui rimborsi dei prestiti esistenti, concedendo ai mutuatari la possibilità di sospendere, con varie modalità, i pagamenti previsti. Altri Stati hanno previsto misure analoghe nella sostanza, ma implementate nell’ambito di iniziative più generali coordinate dal settore bancario (moratorie “non legislative”). In diverse giurisdizioni, inoltre, sono state introdotte varie forme di garanzie pubbliche da applicare ai nuovi prestiti.

A fini di vigilanza, l’EBA ha chiarito in specifiche Guidelines (GL) le implicazioni di tali moratorie sui pagamenti in termini di rispetto delle regole prudenziali, anche in relazione all'applicazione delle regole sulle misure di concessione (forbearance) e sulla definizione di default. Tali precisazioni, in particolare,

chiariscono che le sospensioni dei pagamenti applicate sulla base della GL sulle moratorie non sono da considerarsi misure di concessione e non modificano la preesistente classificazione delle esposizioni.

La mancanza di informazioni sufficienti sull’applicazione delle moratorie dei pagamenti e delle garanzie pubbliche ha indotto l’EBA a introdurre con le GL una raccolta di ulteriori informazioni specifiche dalle banche e ha richiesto altresì un’informativa al pubblico ai fini della disciplina di mercato e della trasparenza per gli investitori e nel più ampio interesse pubblico. Le GL si basano sulle definizioni esistenti del FINREP e sono soggette all’applicazione del principio di proporzionalità e flessibilità per adattare l’applicazione degli orientamenti alle particolari situazioni in un dato Stato membro. Le linee guida lasciano ampio spazio alla flessibilità della vigilanza nell’attuazione delle regole generali, rispetto sia alla popolazione degli enti interessati, sia ai modelli di dati applicati. Le linee guida riguardano i seguenti obblighi: (1) di informativa per monitorare l’utilizzo delle moratorie di pagamento e l’evoluzione della qualità creditizia delle esposizioni soggette a tale moratoria; (2) di informativa per le esposizioni soggette a moratoria; (3) di informativa per i nuovi prestiti oggetto di specifiche garanzie pubbliche istituite per mitigare gli effetti della crisi indotta dal COVID-19; (4) di segnalazione su altre misure di concessione applicate in risposta alla crisi.

Gli obblighi di segnalazione e disclosure nel contesto della pandemia da COVID-19, previsti inizialmente fino al 31 dicembre 2021, sono stati successivamente prorogati fino a nuovo avviso. Le segnalazioni vengono effettuate su base trimestrale a partire dalla data di riferimento del 30 giugno 2020. La disclosure viene effettuata con frequenza semestrale, il 30 giugno e il 31 dicembre.

Il 26 giugno 2020 è stato pubblicato nella Gazzetta ufficiale della UE il Regolamento (UE) 873/2020 (c.d. CRR quick fix) del Parlamento europeo e del Consiglio del 24 giugno 2020, che modifica i Regolamenti (UE) n. 575/2013 e (UE) 2019/876 per quanto riguarda taluni adeguamenti in risposta alla pandemia da COVID-19 (Commissione europea, 2020). Il CRR quick fix fa parte di una serie di misure adottate dalle istituzioni europee per mitigare l'impatto della pandemia di COVID-19 sulle banche negli Stati membri della UE. Oltre alla flessibilità già prevista dalle norme esistenti, il quick-fix ha introdotto alcuni adeguamenti al CRR, comprese misure temporanee volte a rafforzare i flussi di credito alle imprese e alle famiglie, sostenendo così l'economia dell'Unione. Inoltre, il CRR quick fix ha previsto modifiche ai requisiti normativi che hanno un impatto anche sulle segnalazioni di vigilanza, in particolare sui moduli relativi al coefficiente di leva finanziaria, ai fondi propri e al rischio di credito. L'EBA ha pubblicato linee guida per fornire chiarimenti e aiutare le banche a produrre le segnalazioni e le informative che sono legate a tali misure regolamentari (European Banking Authority, 2020b).

3. La PUMA e i processi di produzione dei dati dei segnalanti

Come descritto nella sezione precedente, parallelamente all’evoluzione del contesto economico e finanziario e alla maggiore complessità del quadro normativo di riferimento, la quantità e la granularità dei dati statistici richiesti alle banche e agli altri intermediari finanziari hanno registrato nel corso del tempo un percorso di continuo arricchimento, accelerato in particolare nell’ultimo decennio. Nonostante il processo di armonizzazione a livello europeo, gli oneri sostenuti dagli enti segnalanti per la produzione dei dati da trasmettere alle autorità hanno assunto dimensioni significative. È stato stimato, ad esempio, che con riferimento alle segnalazioni di vigilanza disciplinate dall’EBA, le banche dei paesi dello Spazio economico europeo sostengono complessivamente un costo annuo, comprensivo delle spese correnti e di impianto, pari a 5,5 miliardi di euro (European Xxxxxxx Xxxxxxxxx, 0000x). Tra i principali fattori vi sono la complessità delle disposizioni segnaletiche e l’ampiezza delle richieste informative.

La Banca d'Italia, nella consapevolezza di tale (comunque inevitabile) complessità, persegue la riduzione dei costi seguendo un approccio integrato, all’interno del quale l’esperienza della cooperazione PUMA sostiene gli enti segnalanti nello sviluppo di soluzioni adeguate per il corretto adempimento degli obblighi segnaletici. In questa sezione si illustrano le caratteristiche di fondo di questa esperienza e il contributo che offre al miglioramento della qualità dei dati e all’efficienza dell’intero processo.

3.1 L’esperienza PUMA all’interno della strategia della Banca d'Italia per l’integrazione statistica

L’informazione statistica è considerata dalla Banca d'Italia come una risorsa strategica, diretta a soddisfare le esigenze di una molteplicità di utenti:

– le funzioni istituzionali (vigilanza sugli intermediari, supervisione sui mercati e i sistemi di pagamento, ricerca economica, politica monetaria, ecc.);

– altre autorità nazionali (Consob, Istat, ecc.) e sovranazionali (BCE, EBA, ecc.);

– gli utenti esterni (istituti di ricerca e Università, esponenti del mondo finanziario, ecc.);

– gli enti segnalanti (che ricevono i flussi di ritorno e, nel produrre il reporting, hanno a disposizione un modello di riferimento uniforme e condiviso).

Nella gestione della risorsa statistica la Banca d'Italia si ispira, come già accennato, a un approccio di tipo integrato, che consiste, in termini generali, nel gestire i diversi fabbisogni informativi come parti di un sistema unitario. Un approccio alternativo, orientato a trattare gli ambiti informativi di interesse dei vari utenti indipendentemente l’uno dall’altro (approccio a silos), comporterebbe anche una frammentazione della normativa segnaletica, dei dizionari statistici e delle infrastrutture tecniche.

Di norma le autorità, anche se raccolgono le informazioni separatamente per i vari utilizzi, desiderano poi collegare e in qualche modo “riconciliare” i dati raccolti tramite survey differenti ma attinenti a fenomeni analoghi. In alcuni casi, questo obiettivo viene perseguito mantenendo sistemi informativi diversi e cercando al tempo stesso di usare congiuntamente i dati attraverso un’interoperabilità dei sistemi, secondo un approccio che può essere definito di integrazione ex post.

La Banca d'Italia ha invece seguito un approccio di integrazione ex ante, basato su un unico sistema di definizione e di classificazione dei dati. I diversi fabbisogni informativi sono quindi “fusi” in un'unica struttura di raccolta, che considera la possibilità di utilizzare più volte ogni dettaglio informativo. Non si tratta solamente di condividere o riutilizzare le informazioni, ma di guardare ai dati dalla prospettiva unitaria di un sistema statistico comune. All’interno della Banca d’Italia quest’ultimo è governato dal Comitato per le Statistiche, presieduto da un membro del Direttorio, con la partecipazione degli utenti, dei gestori dei dati e degli esperti IT per le applicazioni statistiche. Tale Comitato garantisce un forte coordinamento tra i vari stakeholder e la valutazione anche di nuove survey da parte di tutti coloro potenzialmente interessati all’utilizzo dei dati.

Le richieste sono individuate tramite un unico processo, evitando ridondanze, e sono descritte utilizzando un unico modello informativo. Un dizionario statistico unitario contiene le informazioni sui dati e i concetti e permette quindi di comprendere i contenuti del sistema informativo. Le applicazioni statistiche utilizzate sono normalmente specifiche per funzione (acquisizione, controllo, trasformazione, diffusione,

ecc.) e generalizzate per contenuto, cioè indipendenti dai dati trattati12. I metadati, che descrivono i concetti statistici, i dati e le regole di trasformazione, sono attivi in quanto guidano le funzioni software (Del Vecchio, 2001); in altri termini, è previsto che le definizioni date dagli utenti siano direttamente interpretate ed eseguite dal sistema elaborativo13. Gli utenti accedono alle informazioni tramite un data warehouse statistico unitario e regole condivise nell’ambito del Comitato per le Statistiche.

L’esperienza PUMA occupa una posizione di rilievo nel contesto dell’approccio integrato alla gestione della risorsa statistica. La PUMA non è un software, ma una documentazione: essa descrive in termini funzionali il processo di produzione delle segnalazioni che ha luogo all’interno degli enti segnalanti e che ha come output le informazioni richieste dalla Banca d'Italia e dalle autorità comunitarie. Il risultato è la creazione di una linea di continuità tra l’autorità che raccoglie i dati e le informazioni che gli enti segnalanti hanno a disposizione ed elaborano in funzione delle esigenze di utilizzo. Più precisamente, la PUMA sostiene gli intermediari nell’integrazione dei loro sistemi di gestione dei dati, contribuendo così a ottimizzare il processo complessivo di reporting e a migliorare la coerenza e la qualità delle informazioni trasmesse, offrendo nel contempo opportunità concrete di contenimento degli oneri segnaletici.

Tale esperienza poggia sulla (solo apparentemente scontata) constatazione che la qualità e la tempestività dei dati prodotti per gli utenti finali dipendono strettamente dalla qualità e tempestività dei dati ricevuti dai segnalanti, che sono a loro volta fortemente condizionate dalla disponibilità di un processo atto a produrli che sia quanto più possibile documentato, standardizzato e automatizzato. Pertanto, vi è un interesse diretto dell’autorità a promuovere miglioramenti nei processi interni degli enti per produrre informazioni statistiche, sebbene tali processi rimangano sotto la piena responsabilità degli enti stessi.

In generale, le banche e gli altri intermediari finanziari italiani hanno recepito tale approccio dal punto di vista di processo nella misura in cui la fonte delle informazioni risiede in un sistema a monte che è alimentato con tutti i dati ed i relativi attributi necessari per adempiere alle necessità segnaletiche (ma anche di bilancio, ecc.) e da qui alimenta a propria volta tutti i processi a valle con un data-set coerente, senza necessità di riconciliazioni ulteriori.

3.2 Il contributo della PUMA e i fattori di successo

Al fine di comprendere come la PUMA incida sul processo di generazione delle informazioni statistiche occorre entrare preliminarmente nei meccanismi interni agli enti segnalanti.

Per produrre i dati richiesti, gli intermediari partono dalle informazioni contenute nei propri sistemi, definibili come “dati primari”. A tale riguardo ogni banca può essere organizzata in modo diverso: ad esempio, il sistema informativo può articolarsi in un numero anche significativo di procedure applicative, ciascuna delle quali dedicata a specifici ambiti di prodotto (ad es. fidi, titoli, derivati, ecc.), ovvero prevedere sistemi diversi di sintesi a loro volta finalizzati ad utilizzi mirati dei dati (ad es. risk management,

12 In virtù di tale strategia, incentrata sul riutilizzo di componenti generalizzati, una nuova esigenza di informazione statistica può essere soddisfatta senza la scrittura di nuovo software, bensì tramite l’utilizzo integrato di una parte o di tutti i componenti disponibili, personalizzandone lo specifico trattamento mediante la definizione di opportuni metadati.

13 Un sistema informativo basato su metadati attivi ha i seguenti vantaggi:

 è auto-documentativo (i metadati attivi sono intrinsecamente corretti e aggiornati e documentano le operazioni del sistema informativo per gli utenti, gli amministratori e il personale IT);

 autonomia dell’utente (gli amministratori possono predisporre e modificare le definizioni contenute nelle survey e le relative elaborazioni con un minimo coinvolgimento della funzione IT, così come gli utenti finali possono ricercare e consultare i dati senza l’aiuto dell’amministratore o della funzione IT);

 time to market e riduzione dei costi (la realizzazione e la modifica delle applicazioni comporta principalmente interventi sulle definizioni e in misura molto minore sul software, rendendo più agevole la gestione della complessità).

bilancio, ecc.) o ancora – ed è la tendenza più recente – includere archivi generalizzati nei quali vengano raccolte tutte le informazioni elementari ritenute anche solo potenzialmente utili per le finalità del reporting. In genere, le informazioni primarie sono costituite da dati granulari, come i singoli prestiti erogati, con le relative informazioni elementari (data di scadenza, valuta, ecc.). Gli enti devono quindi accertarsi innanzitutto di avere a disposizione i dati che sono necessari per soddisfare le richieste informative delle autorità, quindi estrarli in modo organizzato, sviluppando infine un processo di trasformazione (a volte anche molto complesso) per arrivare a produrre le segnalazioni.

I processi interni degli enti segnalanti per produrre dati statistici possono essere definiti secondo criteri e modalità organizzative diverse in relazione al livello di integrazione adottato.

Nei processi basati su un approccio non integrato, per ogni segnalazione da produrre la banca estrae le informazioni necessarie dal suo sistema operativo e produce i dati finali, usando applicazioni informatiche ad hoc. Poiché ciò avviene in maniera indipendente dalle altre segnalazioni, è molto probabile che le singole applicazioni estraggano le medesime informazioni più volte per comporre i singoli flussi informativi da inviare alle autorità. Per esempio, i dati delle segnalazioni di vigilanza armonizzate possono essere estratti dagli archivi aziendali ed elaborati separatamente dalle informazioni per finalità di politica monetaria anche qualora vi siano sovrapposizioni tra i due ambiti informativi.

Se l’intermediario segue invece un approccio integrato, la produzione delle varie segnalazioni è ottenuta attraverso un’elaborazione dei dati provenienti da una base dati di input, definita logicamente in maniera unitaria, i cui contenuti sono estratti dai diversi sotto-sistemi informativi. In sostanza, vi è una estrazione di tutte le informazioni primarie necessarie, che poi vengono utilizzate per la predisposizione delle varie segnalazioni.

Nell’esperienza italiana quest’ultimo approccio, decisamente più efficiente anche dal punto di vista degli standard qualitativi dei dati da trasmettere alle autorità, è risultato prevalente anche in relazione all’azione svolta dalla cooperazione PUMA sin dagli anni ottanta. Infatti, per la strutturazione dei dati di input e per la definizione delle “regole di trasformazione” gli enti possono avvalersi della documentazione prodotta dalla cooperazione - il cosiddetto “dizionario” (cfr. paragrafo 3.4). Si tratta di uno strumento fondamentale soprattutto per le banche medio-piccole, per le quali sarebbe invece estremamente oneroso sviluppare una soluzione autonoma.

L’esperienza PUMA si è sviluppata proprio con l’intento di perseguire gli obiettivi, condivisi dalla Banca d’Italia e dagli enti segnalanti, di aumentare la qualità dei dati e ridurre i costi della loro produzione14. Per raggiungere tali obiettivi, apparentemente in contrasto tra loro, il modello si basa su una documentazione a supporto delle banche attraverso la quale queste ultime possono estrarre i dati primari e applicare regole condivise e procedure standard di trasformazione dei dati per produrre le informazioni statistiche in maniera automatizzata. A tal fine, è stato costituito un gruppo di lavoro permanente, coordinato dalla Banca d’Italia, con il compito di definire tali regole all’interno di un dizionario formalizzato (cfr. paragrafi 3.3 e 3.4).

È importante precisare che la documentazione PUMA viene messa a disposizione di tutti gli enti interessati a consultarla, anche di quelli che non partecipano direttamente alla cooperazione PUMA, e costituisce di fatto un “bene pubblico”. Altre beneficiarie importanti di questa documentazione sono le società di software che assistono gli intermediari nella definizione delle procedure per predisporre i flussi informativi da trasmettere alle autorità, che la usano per aggiornare i propri pacchetti applicativi.

14 Un’esperienza preliminare era stata condotta, in forma semplificata, nel corso degli anni settanta all’interno della Convenzione Interbancaria Per l’Automazione (CIPA) ed ha avuto come risultato lo sviluppo di un software per la produzione delle sole informazioni contenute nella neonata matrice dei conti.

Il continuo e tempestivo aggiornamento della documentazione PUMA divulgata al sistema ha permesso di far fronte ai numerosi cambiamenti nelle normative segnaletiche e all’incessante arricchimento delle informazioni trattate. PUMA è così diventata un punto di riferimento imprescindibile per la produzione delle segnalazioni, sebbene la scelta su come organizzare i sistemi interni a ciascun ente segnalante per il reporting così come la responsabilità della correttezza dei dati trasmessi alla Banca d’Italia rimangano in capo a ciascun segnalante.

Vari fattori hanno contribuito al successo dell’iniziativa.

Nella fase di avvio della PUMA la possibilità di seguire un approccio comune, “di sistema”, nella produzione delle segnalazioni, fondato su una documentazione condivisa sviluppata in collaborazione con l’Autorità, si presentava maggiormente idoneo a fronteggiare le innovazioni segnaletiche; tale aspetto indusse gli intermediari ad aderire fattivamente sin da subito alla proposta formulata principalmente dalla Banca d’Italia e a sostenere i costi interni “di impianto”. Il livello qualitativo dei risultati ottenuti e la predisposizione nel corso del tempo di una rilevante massa critica di informazioni trattate hanno fatto poi sì che le banche proseguissero in modo conseguente nell’utilizzo della PUMA. Inizialmente, le attività della cooperazione ebbero ad oggetto la matrice dei conti, la Centrale dei Rischi, gli Archivi Rischi e Segnalazioni (ARS)15 e la matrice valutaria16; successivamente, furono incluse, tra l’altro, le informazioni di carattere prudenziale, il bilancio, le segnalazioni degli intermediari finanziari non bancari, le statistiche decadali e, negli anni più recenti, le segnalazioni di vigilanza armonizzate, le informazioni analitiche sui crediti (AnaCredit) e sui titoli detenuti (SHS) e le segnalazioni in materia di risoluzione (cfr. sezione 1).

In secondo luogo, la rilevanza dell’esperienza PUMA per il sistema bancario e finanziario è legata anche a utilizzi della procedura interni agli intermediari. Come sottolineato all’inizio degli anni novanta del secolo scorso dall’allora Vice Direttore generale della Banca d'Italia Xxxxxxx Xxxxx Xxxxxxxx, la PUMA è molto di più di uno strumento per produrre le segnalazioni destinate alla Banca centrale. Infatti, “allo scopo di generare quelle segnalazioni, essa opera una selezione dagli archivi dell’azienda bancaria e costruisce un’ampia base dati, che resta a disposizione dell’azienda stessa”; da questa base dati le banche possono trarre informazioni che “forniscono elementi di valutazione e di sostegno per la pianificazione e il controllo di gestione” (Padoa-Schioppa, 1993).

In terzo luogo, è risultato fondamentale il convinto sostegno da parte di tutti gli attori coinvolti, secondo ruoli definiti chiaramente ma che solo di recente sono stati anche formalizzati nell’ambito di una revisione della governance (cfr. paragrafo 3.6):

 la Banca d'Italia coordina l’iniziativa, guida le attività di analisi delle problematiche e di individuazione delle soluzioni17 e cura le attività operative per l’aggiornamento e la pubblicazione della documentazione PUMA;

 le banche e intermediari finanziari partecipano direttamente alla pianificazione delle attività, all’analisi delle problematiche e all’individuazione delle soluzioni;

 le società di software, cui gli intermediari di norma affidano lo sviluppo del software per elaborare i dati da trasmettere alle autorità, svolgono anche nell’ambito della cooperazione PUMA un importante ruolo di natura “consulenziale” per individuare ex ante eventuali criticità per la produzione di determinate informazioni.

Infine, sono da sottolineare alcune scelte strategiche relative al contenuto del dizionario PUMA (cfr. paragrafo 3.4), che hanno favorito la fruibilità del prodotto, ne hanno valorizzato le potenzialità e hanno facilitato l’adeguamento nel tempo alle nuove esigenze informative. In particolare, tra queste rilevano: la definizione di un input estremamente granulare (dati primari); lo sviluppo di una serie importante di

15 Insieme di dati fornito a supporto delle ispezioni di vigilanza.

16 La matrice valutaria era una segnalazione che copriva le operazioni in valuta estera delle banche.

17 A tal fine è di grande importanza il supporto fornito dai normatori per eventuali chiarimenti interpretativi (cfr. paragrafo 3.5.1).

controlli sulla consistenza, coerenza e validità dei dati esercitati sin dal momento iniziale in cui le informazioni vengono processate; la decisione di includere trasformazioni altamente complesse (quale ad esempio il meccanismo di attribuzione di un fido ad una o più esposizioni da esso assistite) e la capacità di descriverle con efficacia e di aggiornarle tempestivamente. Infatti, le informazioni di input definite nella soluzione PUMA sono molto vicine ai sistemi operativi degli enti segnalanti e, di conseguenza, le regole elaborative sviluppate al suo interno coprono un ampio spettro delle trasformazioni necessarie per integrare le informazioni originarie e per produrre in maniera standardizzata i dati richiesti dall’Autorità. Il processo è completato da controlli dei dati (esercitati come accennato in ogni fase di trasformazione) e da regole logiche rigorose, che permettono di presidiare la qualità delle informazioni ben prima che le segnalazioni prodotte vengano trasmesse alle autorità e da queste sottoposte alle verifiche di qualità.

3.3 La PUMA come procedura metadata-driven

L’esperienza PUMA si muove nell’ottica dell’adozione da parte degli enti segnalanti di una procedura

metadata-driven18, composta da:

 un dizionario dei metadati, e

 un software generalizzato, ovvero basato su componenti deputati all’automazione di un particolare aspetto del processo ma in grado di esercitare le proprie funzionalità su qualunque informazione statistica.

La realizzazione del software è lasciata al mercato: nella PUMA viene definita la logica del processo, ma non è previsto di fornire un pacchetto applicativo centralizzato adatto per tutti i segnalanti. Ciascuno di essi ha provveduto autonomamente a selezionare, tra quelle che si sono rese disponibili sul mercato, la soluzione software preferita.

Il dizionario PUMA costituisce l’insieme di metadati che guidano i sistemi interni delle banche. Per poter assumere il ruolo di “dizionario attivo” (cfr. paragrafo 3.1) è necessario che il dizionario sia descritto in un linguaggio per quanto possibile formale, tale cioè da poter essere letto da un software in maniera più o meno automatica.

La rappresentazione dei metadati utilizza un database relazionale, il cui modello dei dati è il cosiddetto “modello matriciale” (Xxx Xxxxxxx et al., 2007). Il linguaggio è in gran parte formalizzato e capace di descrivere trasformazioni complesse ed è al tempo stesso sufficientemente user-friendly da poter essere gestito in autonomia anche da analisti business, ovvero non necessariamente da esperti IT. L’uso di un linguaggio formale consente di descrivere il processo di produzione delle informazioni con maggior precisione e di documentare i concetti statistici e gli algoritmi di calcolo in maniera più rigorosa. La documentazione PUMA è completata da istruzioni e regole elaborative descritte in un linguaggio non strutturato, ovvero non adatto a essere automaticamente eseguito da un software19.

Occorre comunque evidenziare alcuni elementi di evoluzione nell’organizzazione interna degli enti segnalanti per la gestione delle informazioni e nel ruolo di PUMA:

 si è gradualmente ampliata la specializzazione tra l’ambiente utilizzato per il reporting e altri data- mart interni;

18 Applicato alle discipline di data management, un approccio metadata-driven consiste nel pilotare il funzionamento del sistema di gestione dei dati attraverso un modello di governo costituito da una serie di entità, attributi, relazioni, regole.

19 Nell’attività che viene svolta dai gruppi di lavoro PUMA le diverse competenze ed esperienze (personali e soprattutto aziendali) dei partecipanti vengono integrate in un’analisi congiunta, che combina questioni di natura finanziaria e contabile con problematiche di gestione e trasformazione dei dati, in modo da ottenere un prodotto unitario.

 il dizionario PUMA sta diventando sempre meno “attivo” da un punto di vista tecnico, considerato che le soluzioni software adottate dalla maggior parte degli enti non lo utilizzano direttamente come insieme di metadati, ma piuttosto come riferimento documentale;

 i dati contenuti negli archivi “intermedi” della PUMA (nel senso di non ancora compattati e configurati per la produzione del reporting finale previsto) rappresentano una fonte di importanza crescente per la produzione di informative sia a utilizzo interno sia rivolte a terzi (mercato e autorità incluse).

3.4 La definizione del dizionario PUMA

Il presente paragrafo descrive lo strumentario messo a punto dalla PUMA, ovvero il suo dizionario, che rappresenta il “cuore” dell’iniziativa. Come già osservato, la produzione di dati statistici è un processo che parte dai sistemi informativi aziendali e arriva alle segnalazioni finali da trasmettere alle autorità. Esso pertanto inizia con un input, i dati di base negli archivi degli intermediari (dati primari), e termina con un output, i flussi informativi, ottenuto dopo una sequenza di trasformazioni per assicurare la compliance a quanto stabilito dalla normativa segnaletica di riferimento. Sebbene tale processo abbia luogo presso ciascun ente separatamente, il dizionario PUMA si propone di contribuire al suo governo, stabilendo definizioni comuni e regole standard che sono dunque applicabili da tutti gli enti segnalanti20.

Il dizionario PUMA è composto da:

 le informazioni di input;

 le regole di trasformazione;

 le informazioni di output.

Sono inoltre previste regole di validazione finalizzate a monitorare in ogni fase del processo (non, dunque, soltanto alla sua conclusione) la qualità dei dati.

Mentre la definizione dell’output contenuta nella documentazione PUMA corrisponde, come detto, alle richieste informative descritte nella normativa segnaletica, la definizione dell’input e delle trasformazioni richiede un approfondimento.

3.4.1 Le informazioni di input

La documentazione PUMA individua i dati da estrarre dai sistemi operativi delle banche al fine di soddisfare tutte le richieste informative. L’input è costituito da una base dati contenente informazioni ad un elevato livello di granularità che derivano direttamente dalle procedure operative dell’intermediario. Il livello di dettaglio è così analitico che di norma ogni osservazione si riferisce a una particolare operazione (ad esempio, la concessione di una linea di credito a una controparte), a cui vengono associati gli attributi rilevanti (nell’esempio, la valuta, la scadenza, ecc.). Per le attività di finanziamento e di deposito i dati sono generalmente nominativi, mentre le operazioni in titoli fanno riferimento al codice del titolo (c.d. ISIN); attraverso l’Anagrafe dei soggetti e l’Anagrafe dei titoli si può poi ricavare gran parte delle informazioni di interesse relative alle caratteristiche della controparte e del titolo. Questa granularità

20 È bene evidenziare come tale approccio incentrato su di un dizionario comune risponda anche a quanto richiamato dal Comitato di Basilea nel documento “Principi per un’efficace aggregazione e reportistica dei dati di rischio” (cd. BCBS 239) a proposito di “risk data aggregation”: “As a precondition, a bank should have a “dictionary” of the concepts used, such that data is defined consistently across an organisation”. PUMA è andata oltre perché non solo promuove un approccio all’interno di ogni singolo ente ma si propone di avere un dizionario comune tra le banche.

consente di far fronte a richieste aggiuntive di informazioni aggiungendo nuove variabili che arricchiscono la base dati ma senza la necessità di modificare l’unità di osservazione.

Poiché gli enti segnalanti possono strutturare i propri sistemi operativi in modi diversi, è necessario definire una tassonomia per organizzare l’informazione “primaria” presente nelle basi dati interne degli intermediari in maniera standardizzata. La creazione di questa base di partenza è tuttavia agevolata da un profilo logico intrinseco nei fenomeni, in base al quale – a conclusione di analisi a volte anche approfondite e complesse – risulta oggettivamente definito il fabbisogno informativo minimale necessario per poter soddisfare compiutamente le esigenze informative poste dalla normativa. La PUMA definisce quindi una struttura comune applicabile a tutti gli enti (inderogabile da un punto di vista logico), alla quale questi ultimi possono ricondurre i propri dati primari. La modalità con la quale tale operazione può essere effettuata è però estremamente flessibile, potendosi agevolmente adattare alle concrete caratteristiche del sistema informativo di ciascun ente segnalante; si tratta di una caratteristica di notevole importanza della procedura, che ha contribuito fortemente alla diffusione dell’approccio della PUMA.

Nella definizione dell’input si seguono le comuni regole di corretta modellazione dei dati (Codd, 1970). Ad esempio, l’insieme di codici elementari che compongono un dominio deve essere separato (i codici non si devono sovrapporre) e completo (la totalità dei codici deve coprire l’intero dominio di interesse) e le informazioni di input devono essere “non ridondanti” (ogni dettaglio informativo deve essere presente una sola volta, ma può essere usato in molte trasformazioni).

L’input viene quindi definito in modo da contenere tutte le informazioni necessarie per soddisfare gli obblighi segnaletici.

È da osservare come – oltre alla valenza propria per così dire “tecnico-funzionale” – un input così configurato assuma per i segnalanti anche la valenza di modello di riferimento utilizzabile per identificare la capacità informativa che i sistemi aziendali devono possedere per poter gestire adeguatamente un determinato prodotto. Questa caratteristica – che può apparire come “acquisita” per i prodotti più “tradizionali” – è particolarmente apprezzata dai segnalanti per quelli più complessi e/o innovativi, ad esempio quelli di recente introduzione nel mercato o che sono stati interessati da una significativa “rivisitazione” della normativa di riferimento.

3.4.2 Le regole di trasformazione

La seconda componente fondamentale dell’approccio integrato consiste nella definizione delle regole di trasformazione. A tale riguardo, la documentazione PUMA indica come i dati elementari di input debbano essere trasformati al fine di generare i flussi segnaletici richiesti dalle autorità. Più specificatamente, si tratta di aggregazioni più o meno complesse, e di controlli come di seguito delineati.

Tra gli altri, una prima tipologia verifica la presenza di un valore osservato che esprima la misura o la caratteristica qualitativa di un certo fenomeno (cd. “controlli di presenza”). Una seconda classe di controlli mira a verificare che i dati riportati per una certa variabile assumano valori all’interno di un determinato dominio (cd. “controlli di dominio”), che può consistere in un insieme determinato di elementi, appositamente elencati oppure contenuti in una tabella esterna (ad esempio, la tabella contenente per ciascun ISIN le informazioni anagrafiche sui titoli), oppure può essere definito da una regola (ad esempio, un codice identificativo di una certa lunghezza e composto da caratteri numerici e alfabetici in un ordine predefinito). Infine, vi sono controlli volti ad assicurare la coerenza tra variabili diverse, definita sulla base di un’analisi che può far riferimento, tra l’altro, a vincoli normativi (principi di

bilancio, regole prudenziali, ecc.), a nozioni di tecnica finanziaria e a criteri di classificazione statistica (cd. “controlli di coerenza”).

Oltre alla necessità di eseguire tali controlli, le informazioni granulari di input devono essere sottoposte a varie trasformazioni per diventare un dato statistico di output. Come già osservato, il grado di complessità di tali elaborazioni può variare di molto. Casi relativamente semplici sono costituiti, ad esempio, dal calcolo, a partire da informazioni granulari sui rapporti creditizi, di un dato sintetico che esprima l’ammontare dei finanziamenti relativi a una particolare tipologia di operazione, oppure dall’aggregazione di informazioni di base rilevate con una frequenza elevata in intervalli temporali predefiniti. Ma vi sono molte trasformazioni caratterizzate da una notevole complessità ed è principalmente in questi casi che la PUMA fornisce un contributo determinante nella misura in cui risponde in modo efficiente ed efficace a due esigenze fondamentali: la prima consiste nel collegare le logiche del flusso dati tra i diversi sistemi operativi della banca, ovvero gestire in modo integrato dati che il sistema informativo dell’intermediario tratta separatamente (un esempio è costituito dal trattamento dei fidi e delle garanzie ricevute, che comprende le regole di connessione con i rapporti di finanziamento e i relativi meccanismi di allocazione - cfr. il Riquadro 1); la seconda esigenza attiene all’applicazione uniforme della normativa e delle specifiche disposizioni segnaletiche (ad esempio, le classi di esposizione per il rischio di credito e la ponderazione per il requisito patrimoniale sono determinate da complessi algoritmi che, sulla base di quanto disposto dalla normativa prudenziale, combinano le informazioni sul tipo di attività, sulle caratteristiche della controparte, sulla disponibilità di un rating, sulla valuta dell’operazione, sulla sua durata e così via).

Ogni trasformazione, coerentemente con gli obiettivi di trasparenza e tracciabilità che caratterizzano l’intero processo, è documentata in modo tale che i dati progressivamente ottenuti (ancora caratterizzati da un livello di granularità e ampiezza del corredo informativo molto elevati) possano essere utilizzati per finalità ulteriori rispetto a quelle segnaletiche finali.

Riquadro 1 – Un esempio di trasformazioni complesse: il trattamento dei fidi e delle garanzie

Le informazioni sui rapporti di finanziamento, sulle linee di credito (fidi) e sulle garanzie sono presenti separatamente nell’input PUMA. Le numerose fattispecie che si presentano nell’operatività aziendale sono rappresentate nella loro complessità, provviste dei dettagli utili ai successivi trattamenti. In particolare, i fidi e le garanzie si distinguono a seconda che si riferiscano a un unico cliente o a più soggetti (“plurimi”) e in base al collegamento con i rapporti (“specifici” se collegati ad un unico rapporto, “promiscui” se collegati a più rapporti, “generici” se collegati a tutti i rapporti di un cliente).

Le regole di trasformazione PUMA definiscono le modalità di trattamento di tali informazioni, che comprendono i seguenti passaggi:

1) i rapporti, i fidi e le garanzie sono abbinati (funzione c.d. di “fusione”), in base, per esempio, a un codice di abbinamento univoco aziendale oppure a un codice di ripartizione costituito da un range di valori associati a tutti i rapporti del cliente;

2) i fidi sono allocati ai rapporti in modo da calcolare informazioni aggiuntive, come i margini e gli sconfinamenti;

3) le garanzie sono allocate ai rapporti e ai fidi in modo da calcolare informazioni aggiuntive, come l’ammontare garantito.

L’esecuzione delle elaborazioni di cui ai punti 2) e 3) richiede di definire i criteri per operare la c.d. “ripartizione fidi e garanzie”, individuando tra l’altro i fidi e le garanzie da considerare e stabilendo l’ordine da seguire per il loro trattamento e le regole per confrontare gli importi. Tali criteri sono differenziati a seconda della normativa segnaletica di riferimento (Centrale dei Rischi, bilancio, coefficienti prudenziali, ecc.) e danno quindi luogo a distinte elaborazioni.

La presenza in PUMA di tale trattamento ha consentito di produrre i risultati di elaborazioni estremamente complesse attraverso regole definite in modo standardizzato all’interno di un processo integrato. La scelta strategica

della cooperazione PUMA è stata quella di includere nella procedura un ampio novero di trasformazioni, anche quelle meno agevoli, dagli effetti molto “sensibili” (si pensi ad esempio alla ripartizione fidi e garanzie effettuata per le Centrale dei Rischi, avente effetto diretto sulla rappresentazione della posizione nominativa del debitore) e potenzialmente controverse. L’esperienza ultra trentennale, ormai consolidata, dimostra come, a fronte della complessità dell’impianto e dello sforzo iniziale necessario per razionalizzarlo e documentarlo, sia stato possibile migliorare significativamente la stabilità e qualità dei dati ottenuti. Una scelta di tipo diverso avrebbe comportato la necessità per ogni banca di alimentare direttamente in input le informazioni richieste dalle varie disposizioni segnaletiche (margine disponibile / sconfinamento e ammontare garantito a fini Centrale dei Rischi, a fini bilancio, a fini coefficienti prudenziali, ecc.).

3.5 Il ruolo della cooperazione PUMA nel processo di innovazione segnaletica

Il coinvolgimento della cooperazione PUMA nel definire e realizzare una nuova raccolta di dati o nel modificare quelle esistenti ha inizio sin dalla pianificazione delle nuove esigenze statistiche.

Ogni anno viene organizzato un incontro nel corso del quale i rappresentanti delle strutture della Banca d'Italia responsabili della normativa segnaletica e della rilevazione dei dati illustrano ai partecipanti alla cooperazione PUMA le novità pianificate per il biennio successivo. In base alle iniziative previste viene quindi redatto il programma di lavoro dei gruppi PUMA; questi ultimi, oltre a predisporre l’aggiornamento della documentazione, svolgono anche un importante ruolo (informale) di “consulenti tecnici” del normatore nella fase di definizione della normativa segnaletica. Ne discende che la cooperazione PUMA costituisce parte integrante del processo di attuazione delle innovazioni segnaletiche, fornendo un contributo fondamentale alla chiara specificazione di tali innovazioni e favorendone il corretto e tempestivo recepimento, nel rispetto dei reciproci ruoli. Tale funzione è approfondita nei paragrafi seguenti.

3.5.1 L’interazione con il normatore

Come già osservato, l’attività della cooperazione PUMA è principalmente volta a realizzare la documentazione che può essere utilizzata su base volontaria da tutti gli enti segnalanti per produrre le informazioni richieste. In questo ambito, l’interazione con i responsabili della Banca d’Italia per la redazione della normativa segnaletica è essenziale sia ex ante, in relazione a quella attività di consulenza informale in fase di definizione della normativa cui si accennava in precedenza, sia ex post per evitare che le regole definite dai gruppi di lavoro PUMA non siano in linea con la corretta interpretazione di quest’ultima.

Circa la dimensione ex ante del confronto tra i normatori e i segnalanti, ovvero in fase di predisposizione della normativa regolamentare, è importante precisare preliminarmente che esso non incide neanche minimamente sulle reciproche facoltà e responsabilità. Si tratta piuttosto di una interlocuzione preziosa innanzitutto dal punto di vista del normatore, che beneficia delle competenze specialistiche dei rappresentanti di banche e finanziarie per affinare la descrizione dei fenomeni di interesse e rendere la norma più vicina alla reale operatività degli enti. Una valutazione da parte dei gruppi PUMA viene normalmente richiesta e presa in considerazione ben prima della pubblicazione dei documenti per la consultazione pubblica21. Dal punto di vista dei segnalanti, essi hanno modo di entrare sin dall’inizio nel merito dei contenuti delle richieste delle quali saranno destinatari e ciò consente loro di valutarne le implicazioni e avviare le azioni necessarie per un tempestivo recepimento.

Con riferimento all’interazione ex post, la sua valenza e necessità discendono dalla considerazione che in un ambito così complesso e articolato qual è il reporting regolamentare, in cui si sovrappongono criteri contabili, prudenziali, statistici, civilistici, a volte anche gestionali, la concreta implementazione di una innovazione segnaletica, per quanto illustrata in modo chiaro e puntuale nella sua enunciazione, richiede poi di scendere a un livello di dettaglio tale al quale nessuna norma può ragionevolmente spingersi. La necessità di questa interazione si è rafforzata con il progressivo spostamento del potere normativo a livello sovranazionale, che ha aumentato le difficoltà di esaminare il dettaglio delle disposizioni e di definirne le modalità operative di implementazione22.

La maggiore complessità del contesto di riferimento, unita a una crescente granularità dei dati richiesti dagli utenti, ha reso sempre più importante questa attività. In particolare, l’emergere di esigenze conoscitive estemporanee e spesso estremamente urgenti per far fronte ad eventi imprevisti, comporta frequentemente la necessità di sapere quali informazioni sono disponibili e quali sono reperibili con relativa rapidità. Gli esperti della cooperazione PUMA sono in grado di effettuare tale verifica in tempi contenuti, facendo riferimento all’ampia base dati di input costruita nell’ambito del processo segnaletico e già definita in un’ottica multi-purpose. Un importante esempio recente che ben illustra la valenza di questa azione svolta dalla PUMA è costituito dal fabbisogno informativo aggiuntivo richiesto dalle autorità in connessione con la pandemia di COVID-19. La Banca d’Italia ha attuato diverse iniziative volte a raccogliere informazioni in particolare per misurare l’impatto di alcuni provvedimenti assunti dal Governo in merito alla moratoria di alcuni finanziamenti e alla disponibilità di nuova finanza garantita dallo Stato (Casa, D’Alessio, 2020); in questa circostanza l’interlocuzione preliminare svolta all’interno

21 Questa prassi è stata adottata nella realtà italiana ben prima che nell’Unione Europea venissero enunciati i principi della cosiddetta better regulation.

22 In particolare, secondo quanto rappresentato dai partecipanti alla cooperazione PUMA, tra i fattori più rilevanti si evidenziano i seguenti:

1) l’eterogenea platea dei destinatari delle norme europee, appartenenti a paesi con sistemi giuridici e finanziari diversi, che rende necessaria la scrittura di disposizioni di carattere generale e dunque più lontane dalle specificità nazionali; 2) una tecnica di scrittura delle istruzioni segnaletiche caratterizzata da un minor grado di dettaglio e un minor numero di esempi applicativi rispetto alle circolari segnaletiche della Banca d’Italia; 3) un dialogo meno diretto con l'industria su tematiche di reporting al di fuori dei processi formali delle consultazioni pubbliche e delle Q&A.

dei gruppi PUMA è stata essenziale per mettere tempestivamente a disposizione del policy maker i dati necessari per le rispettive valutazioni.

L’attività di consulenza assume un aspetto formale nell’ambito della cosiddetta “analisi di impatto”, prevista dalla legge 262/2005 sulla tutela del risparmio. Infatti, la richiesta di nuove informazioni richiede normalmente una valutazione dei costi e dei benefici ad essa associati. Quando la normativa è responsabilità di autorità sovranazionali, solitamente sono queste ultime che conducono tale analisi, talvolta con il contributo delle autorità nazionali; per contro, se è la Banca d’Italia che manifesta l’esigenza di raccogliere nuove informazioni, essa è tenuta a condurre un’analisi di impatto secondo un processo predefinito, che tiene conto della difficoltà di misurare oggettivamente i costi e i benefici e di confrontarli. Se l’innovazione segnaletica interessa le categorie di enti che partecipano alla cooperazione PUMA, il ruolo di quest’ultima è fondamentale nell’effettuazione della valutazione dei costi. Di norma gli enti aderenti a PUMA vengono interessati formalmente nella fase di pre-consultazione della normativa con la richiesta di fornire una quantificazione ordinale dei costi di impianto e ricorrenti associati a ogni nuovo dettaglio informativo. Talvolta vengono confrontate opzioni diverse su cui gli enti possono esprimere una valutazione della fattibilità e dei costi.

In sintesi, la cooperazione PUMA rappresenta un interlocutore privilegiato del normatore ed è un “valore aggiunto” rispetto alle ordinarie procedure di confronto e consultazione previste. Infatti, la conoscenza dell’operatività aziendale e dei suoi sistemi informativi, unita alla capacità e alla necessità di analizzare approfonditamente le modalità di produzione delle informazioni, consentono agli esperti PUMA di valutare le conseguenze di una scelta normativa e di anticiparne le criticità. A sua volta il normatore, grazie a questa collaborazione, può meglio precisare i contenuti delle segnalazioni, riducendone i costi e aumentandone la rispondenza alle aspettative degli utenti.

3.5.2 L’aggiornamento della documentazione PUMA

In presenza di nuove richieste di dati definite dal normatore, la PUMA aggiorna tempestivamente la documentazione a supporto dei segnalanti al fine di renderla disponibile in tempo utile per il necessario adeguamento dei rispettivi sistemi informativi. Il coordinamento tra la produzione normativa e l’attività della PUMA, sia riguardo ai contenuti che alla tempistica, rende possibile soddisfare le esigenze informative secondo le scadenze previste. L’introduzione di nuovi requisiti segnaletici da parte della normativa attiva un processo di aggiornamento consolidato che consiste nelle seguenti fasi.

La prima attività da svolgere riguarda la valutazione dell’impatto sui dati di input (cfr. paragrafo 3.4.1), ovvero l’individuazione precisa delle nuove informazioni da reperire nei sistemi informativi degli intermediari per soddisfare i nuovi requisiti. In questo ambito il contributo dei rappresentanti degli intermediari segnalanti è cruciale in quanto, grazie alla conoscenza nei minimi dettagli delle attività bancarie e finanziarie, sono in grado di individuare accuratamente i dati di input da integrare analizzando approfonditamente le nuove esigenze informative introdotte dalla normativa. Di norma, l’impatto sull’input viene divulgato in una bozza di documentazione PUMA con un certo anticipo rispetto all’entrata in vigore della normativa, per lasciare agli enti il tempo necessario per reperire i nuovi dati nei sotto-sistemi informativi aziendali.

Successivamente, si lavora all’adeguamento delle regole di trasformazione. Anche in questa fase il confronto con l’Autorità è di fondamentale importanza per la corretta applicazione della normativa, attraverso la traduzione di istruzioni di carattere generale in precisi algoritmi di elaborazione dei dati. Al riguardo, sebbene la documentazione PUMA non costituisca un’interpretazione ufficiale della normativa

(e quindi i segnalanti mantengano la piena responsabilità nella produzione dei flussi da trasmettere), le banche e gli intermediari finanziari considerano tale documentazione uno strumento fondamentale, che attraverso la definizione logica del processo di produzione dei dati li facilita nella compliance alla normativa segnaletica, particolarmente utile in caso di questioni controverse. Sotto questo aspetto la documentazione PUMA si differenzia significativamente dall’utilizzo delle moderne tecnologie “RegTech” per la produzione e gestione della normativa regolamentare in materia di supervisione (cfr. paragrafo 5.1).

Una volta che l’analisi condotta dai gruppi PUMA è stata completata, viene aggiornata e resa disponibile a tutti gli intermediari la nuova documentazione, che comprende:

– il dizionario PUMA in forma di database, distinto per banche e intermediari finanziari23;

– il Manuale tecnico funzionale, che contiene, tra l’altro, la descrizione del modello utilizzato per la rappresentazione dei metadati, le istruzioni per la compilazione dell’input e le fasi di trasformazione particolarmente complesse che non possono essere incluse nel database;

– le note tecniche, che descrivono, con riferimento a un certo ambito informativo, l’analisi svolta per l’aggiornamento della documentazione PUMA, normalmente connesso a rilevanti novità segnaletiche;

– le codifiche dei dati di output, quando la normativa non le contiene (ad esempio, per il bilancio bancario) oppure per documentarle in PUMA è necessaria una loro ricodifica (come per le segnalazioni descritte nel Data Point Model dell’EBA).

La complessità di tale attività emerge da alcuni numeri. Allo stato attuale la documentazione PUMA copre 29 basi informative per le banche e 7 per gli intermediari finanziari non bancari (nel 2011 erano rispettivamente 14 e 4). Nel corso del 2021 sono stati pubblicate 49 versioni del database PUMA, con

235.255 modifiche ai metadati, 23 aggiornamenti del Manuale, 18 note tecniche e 11 aggiornamenti delle codifiche.

3.5.3 La diffusione della documentazione PUMA: sito Web e attività formativa

La documentazione PUMA viene diffusa attraverso il sito Internet della cooperazione (xxxxx://xxx.xxxxxxxxxxxxxxxx.xxx/), all’interno della sezione “Prodotti”. L’uso di un sito web distinto, realizzato nel 2020, permette di configurare la cooperazione PUMA come soggetto autonomo, ancorché privo di personalità giuridica, sia dalla Banca d'Italia sia dagli enti che aderiscono all’iniziativa. Il sito viene utilizzato, oltre che per pubblicare la documentazione PUMA mettendola a disposizione di tutti gli intermediari inclusi quelli che non partecipano ai Gruppi PUMA, anche per presentare la cooperazione e le sue attività. Una newsletter periodica ne evidenzia gli appuntamenti e gli argomenti di particolare interesse.

Un canale meno noto ma sempre più importante per la diffusione dei contenuti della PUMA è quello della formazione degli operatori del settore (esponenti del mondo bancario e finanziario addetti alle segnalazioni, esperti del risk management, rappresentanti delle società di software e dei centri di servizi che implementano le innovazioni in materia segnaletica). La pubblicazione della documentazione viene infatti accompagnata da iniziative formative volte a favorire la comprensione delle novità segnaletiche e dei relativi adeguamenti PUMA e il loro tempestivo recepimento. Queste iniziative registrano normalmente

23 La realizzazione di dizionari PUMA separati per le banche e gli altri intermediari finanziari riflette le loro differenze in termini sia di operatività sia di obblighi segnaletici.

un’elevata partecipazione24, soprattutto nel contesto attuale caratterizzato dal forte aumento del volume dei dati statistici richiesti e dall’accresciuta complessità della normativa segnaletica.

Inoltre, la cooperazione PUMA organizza autonomamente incontri periodici, annuali o semestrali, con le società di software e i centri servizi in caso di rilevanti novità segnaletiche. La collaborazione con tali aziende, che rappresentano i primi utilizzatori della documentazione prodotta, permette di individuare eventuali problematiche che scaturiscono dall’esecuzione concreta delle regole PUMA e di poter così migliorare le soluzioni adottate. Nei suddetti incontri vengono esposti gli interventi apportati alla documentazione e vengono chiarite le logiche sottostanti, lasciando comunque autonomia nella definizione delle varie soluzioni applicative.

Recentemente hanno assunto particolare rilevanza anche i corsi di formazione, organizzati dal team PUMA della Banca d'Italia, sul modello dati utilizzato per descrivere il dizionario PUMA e sul database relazionale dove i metadati PUMA sono contenuti. Questa attività formativa ha accompagnato il passaggio, avvenuto a metà 2020, a nuove modalità di rappresentazione della documentazione PUMA, con l’adozione di un prodotto tecnologicamente più moderno che ha permesso di superare vincoli e rigidità degli strumenti precedenti.

3.6 L’organizzazione della cooperazione

La cooperazione PUMA è fondata sulla disponibilità di tutti gli attori coinvolti a collaborare per il perseguimento degli obiettivi condivisi di alta qualità dei dati e di contenimento dei costi a carico degli intermediari. Una chiara individuazione dei ruoli e delle responsabilità è pertanto essenziale per il proficuo svolgimento delle attività.

A dicembre 2018 i partecipanti all’iniziativa hanno stipulato un Accordo (xxxxx://xxx.xxxxxxxxxxxxxxxx.xxx/xxx-xxxxx/Xxxxxxx_xx_xxxxxxxxxxxx.xxx) che definisce l’oggetto, i partecipanti, gli organi di governo e le regole della cooperazione. Ai sensi dell’Accordo l’obiettivo è “la realizzazione e manutenzione di una documentazione di riferimento per la produzione dei flussi informativi da parte degli intermediari”. Possono aderire all’intesa:

a) le banche iscritte all’albo di cui all’art. 13 del TUB;

b) gli intermediari finanziari di cui all’art. 106 del TUB;

c) le associazioni di categoria e i consorzi costituiti fra banche e/o intermediari finanziari.

A giugno 2022, gli aderenti comprendevano 26 enti (xxxxx://xxx.xxxxxxxxxxxxxxxx.xxx/xxx- siamo/Elenco_degli_aderenti.pdf), oltre alla Banca d'Italia, rappresentativi delle banche grandi e medie, del credito cooperativo e degli intermediari finanziari che svolgono le varie tipologie di attività finanziaria di natura creditizia.

La governance della cooperazione è garantita dal Comitato strategico, presieduto da un rappresentante della Banca d'Italia e composto da un membro per ogni ente partecipante all’iniziativa e dal coordinatore dei Gruppi funzionali (cfr. infra). Tale Comitato approva la pianificazione delle attività, individua le risorse da assegnare ai progetti e ne definisce le priorità, delibera sulle richieste di partecipazione alla

24 Tra le iniziative più consolidate nel tempo si segnalano i seminari che ABIFormazione (divisione di ABIServizi SpA, società per azioni partecipata dall’Associazione Bancaria Italiana) organizza in corrispondenza di rilevanti innovazioni nella normativa segnaletica. La struttura dei seminari prevede una parte iniziale di inquadramento normativo, svolta generalmente dagli esperti della funzione di Vigilanza della Banca d'Italia, seguita dalla descrizione dettagliata degli interventi effettuati sulla documentazione PUMA, a cura del team della Banca d'Italia che coordina le attività della cooperazione, e dalla testimonianza, da parte delle banche e degli intermediari finanziari partecipanti, delle principali problematiche incontrate nell’implementazione delle nuove richieste informative.

cooperazione e sull’eventuale esclusione e approva le modifiche all’Accordo. In considerazione dell’estrema importanza per le attività PUMA della collaborazione con le strutture responsabili in Banca d’Italia della produzione normativa, è prevista anche la partecipazione di questi ultimi, in qualità di “osservatori”, alle riunioni del Comitato strategico.

L’analisi della normativa e la definizione degli interventi sulla documentazione PUMA sono svolte dai Gruppi funzionali interbancario e interfinanziario, coordinati da un rappresentante della Banca d'Italia. A ogni partecipante sono richieste adeguate conoscenze dell’operatività bancaria e finanziaria ed esperienza nella predisposizione delle segnalazioni. Anche le società fornitrici di software o di consulenza che operano in campo contabile/regolamentare possono essere invitate a partecipare alle riunioni dei gruppi funzionali.

La Segreteria tecnica dell’iniziativa è affidata alla Banca d'Italia, che mette anche a disposizione le risorse logistiche e tecnologiche per lo svolgimento delle attività. In particolare, è di fondamentale importanza per la qualità dei prodotti divulgati disporre di una soluzione informatica che permetta elevati livelli di efficienza e garantisca, grazie a un articolato sistema di controlli, la completezza, la correttezza e l’integrità del dizionario PUMA25.

3.7 I vantaggi dell’esperienza PUMA

L’esperienza della cooperazione PUMA ha contribuito ad aumentare il livello qualitativo delle segnalazioni e a rendere più agevole il compito di banche e altri intermediari finanziari nella produzione delle informazioni statistiche, contenendo efficacemente i costi del reporting. Lo spirito di collaborazione tra i partecipanti e le frequenti interazioni con la Banca d’Italia nel corso del tempo hanno inoltre permesso a quest’ultima di maturare una maggiore sensibilità verso le problematiche specifiche degli enti segnalanti e a questi ultimi di essere parte attiva nel processo di costruzione e produzione del reporting regolamentare (cfr. il Riquadro 2). Di seguito si descrivono alcuni ambiti che ne beneficiano in modo particolare.

Coerenza - In primo luogo, la soluzione PUMA assicura la coerenza tra i dati statistici prodotti dal singolo ente con riferimento alle diverse segnalazioni che vengono trasmesse alle autorità, in quanto i flussi traggono origine da elaborazioni sul medesimo set di dati primari estratti dai vari database dell’intermediario.

Standardizzazione – La soluzione favorisce inoltre un più elevato grado di armonizzazione tra i flussi a livello di sistema in quanto i dati sono prodotti dai vari enti segnalanti seguendo le medesime regole. L’analisi condotta dai Gruppi funzionali PUMA a livello centralizzato, sostenuta da un’interazione costante con gli esperti della Banca d’Italia, riduce il rischio di interpretare la normativa segnaletica non correttamente o in modo non uniforme tra intermediari.

Correttezza - Sebbene la coerenza “interna” ai flussi trasmessi da un dato segnalante e “tra” segnalanti sia un elemento fondamentale per la qualità delle informazioni trasmesse, essa di per sé non assicura che i dati siano corretti. La cooperazione PUMA contribuisce alla correttezza delle informazioni in vari modi: innanzitutto, la documentazione comprende regole di controllo dei dati di input che permettono di intercettare alla fonte eventuali errori; inoltre, essendo le regole elaborative definite centralmente, ciascun ente segnalante può concentrarsi sulla corretta estrazione dei dati di input, che rappresenta il fattore

25 In particolare, l’applicazione utilizzata a tale scopo consente di eseguire controlli sui metadati inseriti, di arricchire l’input con nuovi elementi desunti dalla logica del processo, di condurre ulteriori verifiche di coerenza e di produrre il database contenente il dizionario PUMA.

predominante per la qualità delle segnalazioni. Va ricordato, in ogni caso, che l’applicazione delle regole PUMA non elimina il rischio di errori nei dati, la cui correttezza rimane sotto la piena responsabilità dell’ente che li produce.

Time-to-market - In considerazione del processo unico sottostante la produzione dei dati, gli intermediari hanno margini di efficienza e sono potenzialmente in grado di accorciare i tempi di generazione dei report senza stravolgimenti. Ad esempio, tale impostazione ha aiutato le banche nella riduzione dei tempi per la trasmissione delle segnalazioni di vigilanza armonizzate, che dal 2014 sono stati accorciati a T+42 rispetto alla data di riferimento.

Flessibilità - Un ulteriore vantaggio della soluzione PUMA è la sua flessibilità. La documentazione viene definita in un sistema tabellare esterno ai programmi applicativi e può essere gestita da personale senza particolari competenze IT. Conseguentemente, in un contesto in cui i fabbisogni informativi variano frequentemente, è possibile adeguarsi in maniera veloce ai cambiamenti. Infatti, gran parte degli adeguamenti riguardano i metadati che compongono la documentazione PUMA, che possono quindi essere aggiornati a cura dei partecipanti ai Gruppi funzionali e a beneficio di tutto il sistema, con impatti limitati sui software e costi contenuti per gli enti segnalanti. Inoltre, l’estrema granularità e ricchezza della base dati di input riduce l’impatto di nuove richieste informative, che potrebbero essere soddisfatte aggiornando le regole di trasformazione di informazioni elementari di input già disponibili.

Onere segnaletico - Dal punto di vista dell’ente segnalante, l’approccio PUMA favorisce una maggiore efficienza dei processi segnaletici grazie al riutilizzo dei dati di base e alla condivisione tra gli intermediari di una parte dei costi di analisi e di implementazione della normativa. Inoltre, permette di adottare procedure interne che considerano unitariamente le diverse richieste informative, standardizzando e centralizzando alcune attività. Occorre altresì sottolineare che un siffatto approccio, documentato in maniera strutturata e formale, facilita, con modalità che si ricorda sono assolutamente non vincolanti, lo sviluppo delle applicazioni IT per il reporting.

Tracciabilità – Infine, si evidenzia l’importanza della “tracciabilità” del processo (cd. “audit trail”) e della possibilità per gli enti segnalanti di risalire dagli aggregati ai dati micro. Questa caratteristica consente, tra l’altro, di individuare più facilmente gli errori segnaletici intercettati dall’autorità con le procedure di controllo, che in parte fanno riferimento a dati aggregati, e di rispondere tempestivamente alle relative richieste di chiarimenti.

Queste caratteristiche rendono l’esperienza PUMA estremamente vantaggiosa, anche considerando i possibili rischi ad essa connessi, quali: a) un’interpretazione non corretta della normativa segnaletica diffusa in tutto il sistema; b) il mancato rispetto dei tempi per gli adeguamenti software a causa della disponibilità tardiva della documentazione PUMA; c) l’erronea percezione in alcuni dei soggetti coinvolti di una (pur evidentemente infondata) deresponsabilizzazione degli intermediari, nonostante il chiaro disclaimer pubblicato sul sito della cooperazione26.

Riquadro 2 - L’esperienza di un reporting agent nell’ambito della cooperazione PUMA1

La produzione del reporting regolamentare rappresenta – come una esperienza ormai consolidata ampiamente dimostra – una sfida impegnativa per la totalità degli enti segnalanti (indipendentemente dalla loro natura, dimensione, collocazione sul mercato, modello organizzativo, ecc.).

26 Nel disclaimer si legge, tra l’altro, che “la documentazione PUMA non influisce, modifica o sostituisce le responsabilità degli intermediari nei confronti delle autorità competenti”. Inoltre “gli intermediari segnalanti restano pienamente responsabili dell’organizzazione dei propri sistemi di segnalazione interna e della correttezza dei loro dati nei confronti delle autorità”.

Si tratta infatti di produrre periodicamente, secondo tempi e schemi prestabiliti e non derogabili, un set di informazioni intrinsecamente delicate e sensibili (per il contenuto che le caratterizza e per l’attenzione che sono destinate ad avere presso le autorità), ma anche di confrontarsi con una esigenza comune a tutto il sistema, toccando con mano la propria concreta capacità di assolvere in modo adeguato a quanto richiesto. In questo il contributo dato dalla PUMA è storicamente stato ed è tuttora fondamentale: lo fu inizialmente, quando in un contesto esclusivamente nazionale si trattò di dare un impulso deciso alla automazione e standardizzazione, e lo è oggi, in un contesto prevalentemente comunitario, nel quale occorre confrontarsi con un reporting progressivamente sempre più articolato e complesso, che riflette le esigenze informative generate dallo scenario attuale, caratterizzato da shock “estremi” e trasformazioni incessanti.

La disponibilità della documentazione PUMA ha innanzitutto facilitato, inducendola come sviluppo naturale, la produzione regolare e standardizzata (ottenuta cioè non con un pur apprezzabile sforzo ad hoc, bensì con un processo documentato e pressoché totalmente automatizzato) del reporting. Può apparire una considerazione ovvia, se si considera la natura obbligatoria del reporting, ma in realtà non è così. Un conto, infatti, è disporre di una informativa prodotta sulla base di una interpretazione e applicazione delle norme del tutto individuale; ben altra cosa è definire un flusso segnaletico che – ferma restando la inderogabile responsabilità individuale di ciascun segnalante – discende da una declinazione funzionale ed applicativa delle norme condivisa e da una concreta applicazione effettuata da software liberamente selezionati sul mercato ma anch’essi di fatto condivisi (almeno nell’utilizzo) da un numero spesso importante di segnalanti. Su questo aspetto può essere utile evidenziare come un tale approccio non si ponga in contrasto con l’esigenza che le norme stesse (come ad esempio accade chiaramente con quelle comunitarie di rango regolamentare) non risultino in tal modo oggetto di una “interpretazione” (nel senso tecnico-giuridico del termine) che sarebbe contra legem. Esse sono, infatti, direttamente applicabili ed eventualmente assistibili nella loro applicazione mediante procedimenti (ad es. le Q&A) ben noti e chiaramente definiti, con i quali la cooperazione descritta non si pone in alcun modo in contrasto, in quanto produce una documentazione tecnico-funzionale.

Il supporto della PUMA ha agevolato numerose transizioni importanti e complesse. A titolo meramente esemplificativo (poiché in realtà sono state davvero numerose e significative), dopo l’originario impianto finalizzato alla produzione della matrice dei conti, della matrice valutaria, degli Archivi Rischi e Segnalazioni (ARS) e della segnalazione per la Centrale dei Rischi, è possibile citare tra le altre:

- l’applicazione del decreto legislativo n. 87 del 27 gennaio 1992, adottato in attuazione della direttiva n. 86/365/CEE relativa ai conti annuali ed ai conti consolidati delle banche e degli altri istituti finanziari (prima esperienza di standardizzazione delle attività connesse con la redazione del bilancio conforme a criteri comunitari);

- l’impianto delle rilevazioni prudenziali (sin da quelle c.d. di “Basilea 1”: coefficiente di solvibilità, rischi di mercato e grandi esposizioni), progressivamente assistite nel loro sviluppo anche in implementazioni particolarmente complesse quale ad esempio quella connessa con il calcolo degli effetti dei fattori di rischio “gamma” e “xxxx” per i contratti derivati di negoziazione;

- la riforma della Centrale dei rischi nel 1997, con la quale fu innovato significativamente il processo di produzione dei dati, implementata l’adozione di una metodologia di descrizione dei dati duttile e flessibile (cosiddetto “modello matriciale”), estesa l’area di rilevazione agli affidamenti concessi dagli intermediari finanziari, supportata la transizione ad una segnalazione in grado di fornire una rappresentazione pluridimensionale della posizione debitoria dell’affidato capace di cogliere i diversi profili della relazione “banca-cliente” (il modello introdotto rese possibili oltre 1000 osservazioni teoriche per ogni cliente a fronte di 9 del sistema precedente);

- le riforme della matrice dei conti del 1998 (con la quale, mediante una modifica profonda della allora “Sezione V

– Informazioni per paese di controparte” ed una significativa riduzione dei tempi di produzione dei dati da parte delle banche, si rese possibile alla Banca d’Italia la produzione tempestiva del secondary reporting verso la BCE, implementando nel processo PUMA anche il calcolo dell’aggregato soggetto ad onere di riserva obbligatoria) e del 2008 (anno di introduzione delle regole per la compilazione delle segnalazioni statistiche di vigilanza, su base individuale, che le banche italiane e le filiali italiane di banche estere trasmettono alla Banca d'Italia tuttora);

- la prima applicazione dei principi contabili internazionali IAS (International Accounting Standards)/IFRS (International Financial Reporting Standards) al bilancio e alle connesse segnalazioni di vigilanza delle banche e degli intermediari finanziari vigilati (2005 - 2006);

- i templates EBA sui temi prudenziali (large exposures, asset encumbrance, leverage ratio, Liquidity Coverage Requirement - LCR, Net Stable Funding Ratio - NSFR, Additional Liquidity Monitoring Metrics - ALMM inclusi) tra il 2015 e il 2016;

- le rilevazioni granulari AnaCredit e SHS (Securities Holdings Statistics) nel 2018.

Questa elencazione testimonia non solo il lavoro svolto, quanto piuttosto della capacità della PUMA di conseguire tempestivamente i nuovi obiettivi, che inevitabilmente continueranno a porsi in futuro, sia in termini di produzione di nuovi report, sia di possibili integrazioni con analoghe iniziative in corso in ambito europea (in particolare il BIRD).

Il supporto “qualitativo”, inoltre, si è rivelato anche un (non meno rilevante ed apprezzabile) fattore di contenimento dei costi. La PUMA permette infatti di produrre nuovi report e di adeguare quelli esistenti a un costo significativamente inferiore in quanto la disponibilità progressivamente consolidata di una base dati “di input” molto ricca e granulare permette un approccio “incrementale”, ovvero di integrare di volta in volta tale base dati con le informazioni necessarie senza doverne predisporre una interamente ad hoc. Inoltre, i cambiamenti che originano esclusivamente da una diversa rappresentazione dei fenomeni hanno un costo limitato alla produzione finale, ovvero allo sviluppo delle regole di trasformazione interne alla procedura, ma non richiedono una implementazione vera e propria e, soprattutto, la creazione di flussi di input dedicati, che sono la componente spesso più costosa e delicata degli aggiornamenti.

All’essere un fattore di facilitazione del reporting e di contenimento dei costi si aggiunge poi un valore “intangibile”

– ma non per questo meno significativo – della PUMA nella misura in cui essa contribuisce significativamente a far maturare in tutti coloro che negli enti segnalanti sono coinvolti a vario titolo nell’attività di reporting regolamentare la consapevolezza che tale loro coinvolgimento non costituisce un mero adempimento (sia pure obbligatorio e assistito, in caso di non adeguato assolvimento, da uno specifico regime sanzionatorio). Esso piuttosto rappresenta la compartecipazione attiva a un processo delicato e complesso, volto a porre gli utilizzatori dei dati – le autorità, soprattutto, ma anche i segnalanti stessi, le associazioni di categoria, gli studiosi, ecc. – nella condizione di essere correttamente ed adeguatamente informati per adempiere ai compiti ad essi assegnati.

Questo contribuisce ad un processo che diviene in tal modo più partecipato e “cooperativo” e crea, dal punto di vista dei segnalanti, un mutuo vantaggio costituito dal fatto che gli intermediari di volta in volta più specializzati o semplicemente di maggiori dimensioni si possono porre come “apportatori di conoscenze specifiche” (in particolare sulle operazioni più complesse e/o innovative) a beneficio anche di quelli di più ridotte dimensioni. Questi ultimi dal canto loro effettuano – proprio grazie alle loro caratteristiche – un monitoraggio degli effetti della documentazione estremamente accurato ed efficace anche su aspetti che – nei grandi numeri – risulterebbe oggettivamente più difficile individuare; in molti casi restituiscono un feedback prezioso per perfezionare la documentazione disponibile, a vantaggio di tutti.

Per completezza d’informazione, è opportuno evidenziare anche il ruolo in alcuni casi esercitato dalla documentazione PUMA nel “facilitare” l’accesso a prodotti o iniziative di grande interesse nel sistema, per le quali il poter contare sul trattamento all’interno del protocollo PUMA ha consentito a tutte le tipologie di intermediari di essere prontamente (e felicemente, come poi l’esperienza ha concretamente dimostrato) in condizione di accedervi. A titolo di esempio si riportano due iniziative di conoscenza comune: 1) la produzione dell’informativa connessa con la partecipazione al primo programma Targeted longer-term refinancing operations (TLTRO), che fu ottenuta in tempi brevissimi, con un impatto davvero minimo sull’input richiesto alle banche; 2) la documentazione delle cartolarizzazioni sintetiche, condizione necessaria per l’adesione a recenti iniziative approvate dalla Commissione europea nel quadro delle norme comunitarie sugli “aiuti di Stato” (quali l'introduzione di un nuovo prodotto nell'ambito del Fondo europeo di garanzia gestito dal gruppo BEI - Banca europea per gli investimenti, che si presenta sotto forma di garanzie su segmenti di cartolarizzazione sintetica a beneficio delle imprese colpite dalla pandemia di coronavirus).

Quello che più in generale si vuole evidenziare è come la disponibilità di conoscenze sull’organizzazione delle informazioni necessarie per il trattamento di determinate fattispecie (che è uno dei risultati offerti dalla documentazione PUMA, liberamente e gratuitamente accessibile per tutti gli interessati) si configuri a volte come fattore critico di successo per la effettiva realizzazione di determinate operazioni, con effetti poi estremamente significativi non soltanto per l’intermediario che riesce in tal modo a porle in essere ma per il sistema nel suo complesso.

In prospettiva, la capacità ampiamente dimostrata della PUMA di contribuire efficacemente e con flessibilità all’evoluzione del reporting regolamentare consente alla Banca d’Italia e ai rappresentati di banche e finanziarie di essere fiduciosi sulla capacità di integrarsi con analoghe iniziative comunitarie in corso (il BIRD) e, a prescindere da ciò, di continuare a supportare la produzione di nuovi framework segnaletici.

(1) A cura di Xxxxx Xxxxxxxxx.

4. Altre esperienze di cooperazione tra banca centrale e industria

Nel panorama europeo, negli anni più recenti una cooperazione strutturata tra l’industria e le autorità analoga a quella PUMA e volta a supportare la gestione delle segnalazioni statistiche è stata avviata in Austria e nel SEBC con il progetto Banks’ Integrated Reporting Dictionary (BIRD). Tali iniziative hanno tratto ispirazione dall’esperienza italiana e analogamente si pongono l’obiettivo comune di rendere più efficiente il processo di reporting regolamentare degli intermediari.

4.1 Austria

La banca centrale austriaca (OeNB) ha avviato nel 2013 una iniziativa di armonizzazione e integrazione dei dati, in collaborazione con gli enti vigilati. Al progetto hanno partecipato diverse banche e società che forniscono servizi finanziari. Il progetto mira a semplificare il regulatory reporting e migliorare la qualità dei dati attraverso la riorganizzazione del sistema di segnalazione della banca centrale austriaca (Kienecker et al., 2018). Gli intermediari che aderiscono all’iniziativa inviano i dati granulari, secondo uno schema predisposto dalla banca centrale, a una piattaforma condivisa, dove vengono eseguite le trasformazioni, attraverso un unico software, per la generazione dei flussi aggregati (secondo un modello dati predefinito e predisposto dalla OeNB), che vengono poi trasmessi alla banca centrale27.

Per dar corso a questa iniziativa è stata costituita la Austrian Reporting Services GmbH (AuRep), un fornitore di servizi per il reporting statistico che ha predisposto e gestisce una piattaforma denominata Common Reporting Platform dedicata alla produzione dei report.

AuRep supporta le banche che usufruiscono del servizio nella conversione dei dati presenti nei rispettivi sistemi informativi in uno basato sui c.d. “cubi”. Più specificamente, per ciascun ente segnalante i dati estratti dai database aziendali sono conferiti in un unico “basic cube” dal quale le informazioni vengono poi estratte per essere riorganizzate negli “smart cubes”, ciascuno dei quali descrive la struttura delle informazioni che devono essere trasmesse alla OeNB. Il dettaglio del modello informativo è riportato nella Figura 1.

27 Simile soluzione è stata analizzata in Lussemburgo dove alcuni membri dell’Association des Banques et Banquiers Luxembourg (ABBL) hanno avviato uno studio di fattibilità per quantificare costi e benefici derivanti dall’eventuale creazione di un hub che gestisca, sulla base di una logica cooperativa, il reporting previsto dalle normative segnaletiche per il settore bancario. Il progetto si proponeva di fornire servizi per le segnalazioni regolamentari, con l’obiettivo di garantire la trasparenza dei processi di segnalazione, una più elevata qualità dei dati e una maggiore flessibilità nel sistema di reporting, evitando ridondanze informative e riducendo i costi per gli enti segnalanti. Analogamente alla soluzione austriaca, un siffatto sistema avrebbe consentito di realizzare delle economie di scala nella produzione delle segnalazioni delle singole banche partecipanti; l’hub, infatti, avrebbe permesso di elaborare i dati grezzi su una piattaforma comune con strumenti di calcolo condivisi e in linea con le richieste informative previste dalla normativa segnaletica, evitando di implementare le stesse soluzioni in ogni singola banca segnalante. Il progetto dopo una fase esplorativa non ha fatto seguire una fase realizzativa.

Figura 1 – Flusso dati OeNB

Per ciascun ente segnalante, l'elaborazione e la preparazione di tutti i flussi per l’invio alla banca centrale austriaca avvengono attraverso un software disponibile sulla Common Reporting Platform. La presenza di una piattaforma unica che viene utilizzata dai diversi enti segnalanti in luogo di soluzioni IT individuali permette a livello di sistema una riduzione dei costi per la preparazione e l’invio delle segnalazioni. Inoltre, l’adozione di un unico modello dati (basic cube e smart cube) permette di condividere le stesse conoscenze tra i diversi operatori e promuovere, attraverso definizioni univoche e condivise, una maggiore qualità dell’informazione indipendentemente dall’ente segnalante che produce il dato specifico.

L’obiettivo della piattaforma è di descrivere formalmente, raccogliere e inviare a OeNB i dati delle segnalazioni. I dati che entrano nella Common Reporting Platform sono descritti secondo un modello granulare entità-relazione (modello ER), che contiene tutte le informazioni (con un elevato livello di granularità) necessarie a soddisfare i requisiti segnaletici di OeNB, evitando ridondanze. I cubi e le regole di trasformazione sono definiti in maniera congiunta dall'OeNB e dalle banche austriache.

Il flusso dei dati descritto nella Figura 1 prevede che le banche alimentino i “cubi base” estraendo le informazioni dai loro sistemi informativi; successivamente, i cubi di base sono sottoposti a varie trasformazioni, espresse in un linguaggio pseudo-formale. Le trasformazioni possono prevedere arricchimenti dei cubi base, filtri e aggregazioni che portano in alcuni casi alla segnalazione finale in altri casi alla creazione dei c.d. smart cube ovvero cubi arricchiti di nuove informazioni dai quali si estraggono poi le segnalazioni finali.

È importante notare che l'OeNB non può accedere ai dati di input granulari, ma solo a quelli delle segnalazioni che sono per lo più aggregati.

Questa soluzione è stata adottata dalla maggior parte delle banche e dei fornitori di servizi finanziari austriaci.

Analogamente alla soluzione PUMA, anche nel caso austriaco il beneficio ultimo della soluzione adottata è una maggiore capacità del sistema di soddisfare i requisiti informativi in maniera efficace ed efficiente,

in cui le regole di calcolo e i dati di input sono condivisi dal sistema degli enti segnalanti e definiti con la collaborazione della banca centrale. Questo genera una maggiore coerenza dei dati inviati e determina una maggiore qualità del dato stesso. Inoltre, il sistema è più flessibile perché capace di rispondere più velocemente alle modifiche della normativa segnaletica, in quanto dispone di una base dati di input ampia ed integrata che ha maggiori possibilità di coprire nuove richieste informative rispetto al caso di sistemi non integrati. Allo stesso tempo, la partecipazione della banca centrale all’analisi dei regolamenti segnaletici favorisce una maggiore qualità dei dati, prodotti attraverso un unico processo elaborativo. Infine, la soluzione adottata porta anche ad una riduzione dei costi IT, grazie alla condivisione della piattaforma di produzione delle statistiche da parte delle banche partecipanti. Nel paragrafo 4.3 ci si soffermerà sui pro e i contro di questo approccio rispetto alla soluzione PUMA.

4.2 Il Banks’ Integrated Reporting Dictionary (BIRD)

Nel 2015 la BCE ha avviato il progetto statistico strategico denominato Banks' Integrated Reporting Dictionary (BIRD)28, con il duplice scopo di aumentare la qualità dei dati segnalati e di ridurre l'onere di segnalazione.

Le caratteristiche fondamentali del BIRD si ispirano direttamente a quelle della PUMA italiana: il progetto, infatti, si basa su un modello di dati armonizzato che specifica quelli che dovrebbero essere estratti dai sistemi informativi interni delle banche per generare le segnalazioni richieste dalle autorità. Inoltre, vengono definite in modo chiaro le regole di trasformazione da applicare alle informazioni di base al fine di produrre uno specifico dato regolamentare finale. La cooperazione dell’industria è su base volontaria: attualmente partecipano al BIRD circa trenta banche commerciali europee di nove paesi della UE e le banche centrali di Austria, Finlandia, Francia, Germania, Italia, Paesi Bassi e Spagna29.

Il BIRD è costituito dall’input, le informazioni di base necessarie a soddisfare gli obblighi di segnalazione, dall’output, i flussi informativi da trasmettere alle autorità, e dalle transformation rules, che descrivono in un linguaggio formale le varie fasi di aggregazione e calcolo che le banche devono compiere per generare i dati di output a partire da quelli di input. La Figura 2 rappresenta il BIRD all’interno del più generale sistema di reporting dei dati bancari e finanziari.

Figura 2 - Il BIRD nella strategia dell’Eurosistema per la raccolta dei dati dalle banche

28 xxxxx://xxx.xxx.xxxxxx.xx/xxxxx/xxx_xxxxxxxxxx/xx-xxxxxxxxx_xxx_xxxxxxxxx/xxxxxxxxx/xxxx/xxxx_xxxxxxxxx.xx.xxxx

29 La lista delle banche commerciali e delle banche centrali partecipanti è riportato al link xxxxx://xxx.xxx.xxxxxx.xx/xxxxx/xxx_xxxxxxxxxx/xx-xxxxxxxxx_xxx_xxxxxxxxx/xxxxxxxxx/xxxx/xxxx_Xxxxxx_xxxxx.xx.xxxx.

L’input è articolato nei seguenti due componenti.

Il Logical Data Model (LDM) è un modello di dati altamente “normalizzato”30, che descrive il dominio business, ovvero le informazioni (metadati) e le relazioni logiche tra i dati che sono rilevanti per soddisfare i requisiti di segnalazione.

L'Input Layer (IL) è un modello meno “normalizzato” rispetto all'LDM. È progettato per supportare l'effettiva implementazione fisica del BIRD da parte delle banche. L’IL è derivato direttamente dall’LDM tramite un processo noto come "forward engineering".

Il linguaggio finora utilizzato per descrivere le trasformazioni è il Validation and Transformation Language (VTL) sviluppato dalla comunità SDMX31. Si tratta di un linguaggio standard per definire regole di validazione e trasformazione (insieme di operatori, loro sintassi e semantica) per qualsiasi tipo di dato statistico (SDMX Technical Working Group – VTL Task Force, 201832). L’adozione del VTL garantisce una descrizione univoca delle trasformazioni (SDMX, 2021) e la possibilità di “tradurre” agevolmente questo linguaggio formale in uno qualsiasi dei linguaggi informatici utilizzati nei sistemi informativi delle

30 Nell’ambito della gestione di basi dati la normalizzazione può essere definita come “il processo di organizzazione dei dati in un database. Tale processo comprende la creazione di tabelle e la definizione di relazioni tra di esse sulla base di regole progettate in modo da proteggere i dati e rendere il database più flessibile mediante l'eliminazione della ridondanza e delle dipendenze incoerenti” (xxxxx://xxxx.xxxxxxxxx.xxx/xx-xx/xxxxxx/xxxxxxxxxxxx/xxxxxx/xxxxxxxx-xxxxxxxxxxxxx-xxxxxxxxxxx).

31 La Task Force for the Validation and Transformation Language (VTL) è stata costituita nel 2013 nella comunità SDMX.

32 Cfr. in particolare il capitolo “General Characteristics of the VTL”.

banche per l'eventuale implementazione del BIRD. Negli ultimi anni è stata svolta con successo una attività di test mirata a verificare la correttezza sintattica delle regole di trasformazione definite in VTL33.

Il BIRD, al pari di quanto avviene con la PUMA, è assimilabile a un “bene pubblico”, ovvero esso mira a fornire un servizio a tutti gli intermediari bancari, indipendentemente dalla partecipazione al gruppo, che come accennato è esclusivamente su base volontaria; ne consegue che la documentazione BIRD è liberamente accessibile sul sito della BCE34. Anche l'implementazione di una soluzione informatica che utilizzi il BIRD rimane una scelta autonoma dell’intermediario.

Alla fine del 2021, il BIRD Steering Group, che tra l’altro definisce le priorità e il programma di lavoro del progetto, ne ha affinato gli obiettivi fondamentali. Nel prossimo futuro, il progetto si concentrerà sulla produzione dei dati definiti nell’Integrated Reporting Framework (IReF), il progetto dell’Eurosistema volto a realizzare un quadro segnaletico integrato per la raccolta dei dati bancari e finanziari per finalità statistiche in tutta l'area dell'euro35. In particolare, le attività si indirizzeranno sull’aggiornamento dell’input layer per allinearlo alle esigenze dell’IReF.

La realizzazione del progetto IReF favorirà anche il superamento del principale fattore che finora ha ostacolato la piena affermazione del BIRD con riferimento alle rilevazioni di dati per finalità statistiche. Il BIRD, infatti, fa riferimento direttamente a quanto presente nei regolamenti statistici della BCE; nella loro implementazione, gli intermediari sono tenuti a trasmettere i dati alla banca centrale della rispettiva giurisdizione (primary reporting), la quale poi li invia alla BCE (secondary reporting). Il primary reporting, tuttavia, si basa sui requisiti stabiliti a livello nazionale dalla rispettiva banca centrale, non armonizzati a livello europeo e che pertanto non necessariamente coincidono con quanto stabilito nel BIRD. In sostanza, per gli obblighi di segnalazione statistica le banche devono adattare il contenuto del BIRD ai requisiti nazionali, in quanto l’armonizzazione del primary reporting si realizzerà solo con l’IReF.

La situazione è decisamente più semplice per le segnalazioni di vigilanza armonizzate (EBA ITS), poiché in questo caso il primary reporting è lo stesso tra giurisdizioni (essendo stabilito dall’EBA secondo il principio della maximum harmonisation descritto nel paragrafo 2.1) e ciò facilita l'applicazione diretta del BIRD da parte degli intermediari.

4.3 Il confronto con la PUMA

I due progetti di cooperazione tra intermediari e autorità sintetizzati nei sotto-paragrafi precedenti condividono con l'approccio PUMA alcuni aspetti importanti. In particolare, entrambi muovono dal riconoscimento, in particolare presso le autorità regolamentari, del fatto che il reporting ha una valenza così importante per il sistema considerato nel suo complesso (inteso quindi come un quid unum e non isolando le esigenze, il ruolo, le facoltà e le responsabilità dell’uno o l’altro dei soggetti coinvolti) che la sua gestione complessiva non può essere ridotta alla (mera) configurazione di un obbligo (che pure sussiste) gravante sugli enti segnalanti. Per contro, la cooperazione tra tutti i soggetti coinvolti nel rispetto dei rispettivi ruoli costituisce un presupposto importante, anche se di per sé non sufficiente, per

33 Occorre notare, tuttavia, che sono in corso delle attività di sviluppo della metodologia BIRD mirate ad introdurre regole di trasformazione scritte in un linguaggio logico/semantico per supportare gli utenti non tecnici e fornire la prospettiva business in un linguaggio ancora formale ma più semplice.

34 xxxxx://xxx.xxx.xxxxxx.xx/xxxxx/xxx_xxxxxxxxxx/xx-xxxxxxxxx_xxx_xxxxxxxxx/xxxxxxxxx/xxxx/xxxx_xxxxxxx.xx.xxxx

35 Il progetto IReF prevede di integrare le statistiche europee in un unico reporting framework standardizzato a livello europeo. Questo progetto insieme al BIRD fa parte della strategia di lungo termine del SEBC per il reporting delle banche (xxxxx://xxx.xxx.xxxxxx.xx/xxxxx/xxx_xxxxxxxxxx/xx-xxxxxxxxx_xxx_xxxxxxxxx/xxxxxxxxx/xxxx/xxxxx.xx.xxxx) ed ha lo scopo di standardizzare, armonizzare e integrare il più possibile le statistiche del SEBC al momento della loro raccolta presso le banche. Per maggiori dettagli cfr. xxxxx://xxx.xxx.xxxxxx.xx/xxxxx/xxx_xxxxxxxxxx/xx-xxxxxxxxx_xxx_xxxxxxxxx/xxxxxxxxx/xxxx/xxxxx.xx.xxxx#XXxX .

assicurare efficienza ed efficacia a un processo di per sé molto complesso, senza inficiare in alcun modo le responsabilità assegnate ai singoli partecipanti. Parte integrante di tale approccio è la sensibilità verso l’esigenza di supportare gli enti segnalanti in un contesto in cui i requisiti segnaletici aumentano costantemente, così come il volume e la varietà di dati che sono scambiati tra il sistema bancario e le varie autorità regolamentari europee.

Quello che differenzia invece i due approcci documentati in precedenza rispetto alla PUMA è il perimetro definito per l’intervento e gli strumenti utilizzati per raggiungere l’obiettivo generale: nel BIRD, così come nella PUMA, il focus è esclusivamente sugli aspetti business di modellazione dei dati e delle regole di validazione e trasformazione degli stessi; nel caso austriaco, oltre agli aspetti di modellazione, si affianca il supporto IT comune.

A livello organizzativo, la soluzione IT adottata dall’Austria, fondata sullo sviluppo di un software unico, in contesti dove gli intermediari presentano caratteristiche eterogenee potrebbe risultare rigida rispetto alle esigenze specifiche di ciascun intermediario; inoltre, a livello operativo vi è il rischio che l’eventuale indisponibilità della piattaforma comune comporti il blocco generalizzato delle attività di tutti gli intermediari. Tali criticità non si riscontrano invece nella soluzione PUMA, così come nel BIRD, che non mira direttamente a introdurre una soluzione IT ma piuttosto a definire una documentazione che deve poi essere tradotta da diversi operatori sul mercato in altrettante soluzioni IT, modellabili secondo le esigenze dei singoli intermediari; a fronte di questo vantaggio è evidente che possono esservi aggravi di costo derivanti dalla mancata standardizzazione dei software.

In Italia, l’avvio del BIRD ha costituito l’occasione per effettuare alcuni interventi di modernizzazione della PUMA. A tale riguardo, è stata già completata una prima fase di migrazione dei contenuti PUMA in un database la cui struttura è equivalente a quella del database BIRD. Questo processo ha permesso un avvicinamento del modello PUMA a quello del BIRD senza perdita di contenuti e il passaggio a una tecnologia più moderna ed efficiente rispetto a quella parzialmente obsoleta utilizzata in precedenza. A livello tecnologico le due soluzioni sono oggi molto simili. Circa i contenuti, la PUMA copre ampiamente il reporting delle banche italiane, mentre il BIRD, in relazione all’avvio relativamente recente contiene pochi reporting framework. Una differenza importante che è opportuno rimarcare riguarda il perimetro di utilizzo delle due documentazioni presso l’industria, che dipende dalle scelte strategiche degli intermediari in quanto l’adesione in entrambi i casi è su base volontaria: il BIRD non si è ancora affermato stabilmente presso l’industria bancaria europea quale strumento fondamentale di supporto nell’attività di reporting; per contro, in Italia la soluzione PUMA viene ampiamente utilizzata da oltre tre decenni dalle banche e dalle società finanziarie per fornire il reporting alla Banca d’Italia.

In prospettiva, la vicinanza tecnologica e l’affinità concettuale tra le due soluzioni consentiranno un completo raccordo tra esse. In particolare, i dati altamente granulari dell’input PUMA, utilizzando delle trasformazioni definite ad hoc, potranno essere raccordati alle informazioni contenute nell’input layer del BIRD. In tal modo, da un lato si potranno salvaguardare i processi di estrazione dei dati aziendali sviluppati per la PUMA dalle banche italiane (la cui modifica comporterebbe costi molto rilevanti) e dall’altro si potrà consentire alle banche italiane di sfruttare i contenuti della documentazione BIRD sviluppata a livello europeo per le segnalazioni armonizzate. Si tratterà, in sostanza, di effettuare una connessione logica tra le due documentazioni.

Per gli intermediari italiani si tratta di un vantaggio importante rispetto alle banche degli altri paesi europei, che verosimilmente garantirà loro un significativo contenimento dei costi di implementazione del nuovo framework segnaletico standardizzato IReF quando questo sarà integrato nel BIRD.

5. Possibili sviluppi alternativi in campo regolamentare

Le esperienze descritte nel paragrafo precedente si basano principalmente sulla cooperazione dell’industria con le autorità al fine di sviluppare congiuntamente soluzioni utili a soddisfare le richieste segnaletiche definite da queste ultime. Per riassumere, gli ingredienti fondamentali di questo approccio sono:

 la definizione di un input layer altamente granulare;

 la definizione di regole di trasformazione per collegare tale input layer ai diversi report richiesti dalle autorità;

 il ruolo decisivo delle autorità nella promozione e nel coordinamento dell’iniziativa di cooperazione;

 la volontarietà dell’adozione di simili soluzioni da parte degli enti segnalanti.

In questo paragrafo ci si concentra sulla riflessione in corso, ancora di natura prevalentemente metodologica, su nuove soluzioni per il reporting regolamentare incentrate su (a) una maggiore granularità delle richieste informative da parte delle autorità regolamentari e (b) sull’assegnazione a queste ultime della responsabilità di effettuare le trasformazioni dei dati primari nelle informazioni aggregate necessarie alle proprie analisi, superando così la responsabilità attualmente posta in capo agli enti segnalanti36. Le soluzioni in discussione rientrano essenzialmente in due tipologie: l’approccio noto come Regulatory Technology (RegTech) e i modelli di data-pull.

In termini generali, entrambi gli approcci presuppongono la presenza imprescindibile di un dizionario unico di dati, che ne permette la standardizzazione e deve essere condiviso e applicato da tutte le parti coinvolte al fine di poter implementare queste soluzioni. La principale differenza è che nel caso del RegTech le autorità utilizzano il dizionario per regolamentare dettagliatamente i dati di input e le loro trasformazioni volte a calcolare le informazioni aggregate (“instructions as code”), le uniche poi che devono essere trasmesse dagli enti segnalanti: in sostanza, le autorità descrivono le trasformazioni come “codice machine-executable” che gli enti segnalanti possono eseguire direttamente per calcolare dai dati di input i report richiesti. Nel caso dei modelli di data-pull, le autorità descrivono nel dizionario i dati che i segnalanti devono “consegnare” in un database di staging, ovvero un’area di memorizzazione delle informazioni alla quale le autorità accederanno per effettuare le elaborazioni necessarie per le proprie finalità; in questo approccio, pertanto, la responsabilità di elaborare i dati granulari per ottenere gli aggregati regolamentari è rimessa in capo alle autorità. Inoltre, si supera il concetto di cadenza predefinita delle segnalazioni, in quanto un'autorità può accedere ai dati disponibili in qualsiasi momento.

5.1 Soluzioni RegTech

RegTech consiste, per i profili che rilevano maggiormente nell’ambito di questo lavoro, nell’impiego da parte delle imprese finanziarie e, più in generale, di quelle che operano in settori regolamentati, di tecnologie innovative a supporto delle procedure di conformità e dei processi di implementazione delle

36 Considerazioni simili sono contenute in A reporting system for the future (2022), il recente studio di fattibilità su “Redesign Options for Regulatory Reporting” condotto da BaFin, sostenuto anche dalla società di consulenza Accenture, insieme a Deutsche Bundesbank, enti creditizi, fornitori di servizi e associazioni di categoria.

normative, con l’obiettivo di perseguire contestualmente risultati in termini di efficienza e contenimento dei costi.

Di norma, le istruzioni segnaletiche fornite dalle autorità sono espresse principalmente in un “linguaggio naturale” che richiede pertanto un’interpretazione da parte degli enti segnalanti. RegTech mira ad agevolare l’interpretazione delle istruzioni in linguaggio naturale per ridurre gli errori e rendere più efficienti i processi di produzione dei dati. Esistono infatti opzioni tecnologiche per aiutare a verificare se le regole del linguaggio naturale sono conformi agli standard esistenti per la scrittura della normativa. La standardizzazione della stesura non renderebbe necessariamente le istruzioni più brevi, ma potrebbe rendere più agevole la loro comprensione e il loro utilizzo, che nelle soluzioni più avanzate sotto l’aspetto tecnologico che prevedono anche la fornitura di “annotazioni” alle istruzioni segnaletiche sono ulteriormente facilitati in quanto tali annotazioni possono includere specifici tag (metadati) che consentono di estrarre le informazioni in modo automatizzato (Bank of England, 2020).

Tale contesto generale di applicazione della tecnologia alla normativa e agli adempimenti segnaletici potrebbe evolvere verso un approccio più “estremo” nel quale le regole – oltre che nel comune linguaggio legislativo – verrebbero pubblicate anche in forma di “codice”37. La divulgazione di un codice dovrebbe indurre un livello di dettaglio, accuratezza e coerenza maggiore di quanto riscontrabile nella pubblicazione mediante linguaggio naturale, riducendo in tal modo gli oneri interpretativi e agevolando l’implementazione delle norme nei processi di reporting interni agli intermediari segnalanti. In particolare, i software segnaletici aziendali potrebbero, in un tale scenario, “incorporare” un codice già scritto, senza necessità di dover svolgere le attività normalmente necessarie affinché una norma venga “tradotta” in linguaggio digitale. Di tale impostazione beneficerebbero anche le autorità che, dovendo predisporre una versione in codice delle norme, potrebbero anche cimentarsi in una attività di test preventiva rispetto alla loro pubblicazione.

Sotto l’aspetto meramente metodologico, è abbastanza intuitivo che l’obiettivo della scrittura di un “codice” con le caratteristiche di dettaglio e accuratezza sopra descritte presuppone la previa definizione di un input comune e condiviso, a sua volta dettagliato in tutte le informazioni elementari (univocamente censite) necessarie. Se tale presupposto non è soddisfatto, le istruzioni – ancorché redatte in forma di codice – risulterebbero infatti non direttamente implementabili ma piuttosto richiederebbero uno sforzo di interpretazione (che la soluzione in esame mira invece a eliminare o comunque circoscrivere) e lo sviluppo di una connessione tra i dati di input identificati nel codice pubblicato e le informazioni censite nei sistemi informativi aziendali.

Nonostante la tematica su come redigere le normative seguendo soluzioni di tipo RegTech sia di stretta attualità, anche presso le istituzioni comunitarie, essa costituisce ancora un’area oggetto di analisi e confronto di idee e prospettive e non si riscontrano ad oggi molti casi in cui tali soluzioni siano state effettivamente implementate. Un esempio interessante di sviluppo in tale direzione è offerto dal progetto-pilota Digital Regulatory Reporting (DRR) sviluppato nel Regno Unito nel biennio 2018-19 congiuntamente dalla Financial Conduct Authority (FCA) e dalla Bank of England, in partnership con un numero ristretto di intermediari bancari. L’obiettivo del progetto di rendere il processo di regulatory reporting più accurato, efficiente e coerente viene perseguito tramite:

a) la definizione di un regolamento segnaletico immediatamente “leggibile” da un software (Machine Readible Regulation – MRR);

37 Enciclopedia Treccani, definizione di “codice sorgente”: “Versione di un algoritmo scritta in un linguaggio di programmazione ad alto livello (ossia più vicino al linguaggio umano, tipicamente in pseudo inglese), le cui istruzioni sono poi eseguite dalla macchina mediante appositi programmi (compilatori, assemblatori o interpreti). L’impiego di un codice sorgente è finalizzato all’esecuzione, sull’insieme dei dati di ingresso, di azioni definite nel linguaggio di programmazione scelto tramite un numero limitato di istruzioni.”.

b) la sua conversione, mediante un compilatore, in codice per l’esecuzione su un dataset esterno (Machine Executable Regulation – MER);

c) la definizione di un modello di dati comune che deve essere adottato dai soggetti segnalanti al fine di eseguire il regolamento.

In tal modo, la produzione delle segnalazioni destinate alle autorità viene affidata direttamente a un software, senza alcun intervento umano, e si elimina tutta l’attività che nell’approccio tradizionale è necessaria per implementare le richieste segnaletiche in un software in grado di estrarre i dati necessari e processarli per ottenere il flusso di dati da inviare. In sintesi, il fulcro per il contenimento del reporting burden è costituito dalla scrittura di istruzioni in un linguaggio direttamente leggibile ed eseguibile da un computer (PA Consulting, 2020).

Il progetto, ancora in corso, è confluito nella nuova strategia della FCA (Data Strategy) nella quale l’automazione e i sistemi “data-driven” sono parte essenziale dell’approccio sui dati. I risultati sono promettenti ma vi sono ampie aree che necessitano un approfondimento e la sperimentazione ha mostrato come in ogni caso si tratti di una innovazione molto complessa, che richiede investimenti di non poco conto anche da parte degli enti segnalanti oltre che delle autorità.

5.2 Modelli di “data-pull”

Altre iniziative vanno nella direzione di consentire alle autorità di passare dal concetto di regulatory reporting a quello di data sharing. In quest’ultimo framework, le autorità estrarrebbero le informazioni di cui hanno bisogno direttamente dai database degli istituti finanziari (data-pull); questo approccio rimpiazzerebbe quindi la trasmissione a frequenza periodica delle informazioni da parte degli enti segnalanti (approccio "data-push"). L’implementazione del data-pull aiuterebbe le autorità nel monitoraggio “on-demand” delle condizioni dei singoli istituti finanziari, consentendo loro di agire rapidamente se la situazione lo richiede, a tutto vantaggio del perseguimento della stabilità finanziaria (Xxxxxxxx et al., 2020).

Queste soluzioni vanno oltre la standardizzazione dei dati e il miglioramento delle istruzioni di reporting. Esse, infatti, necessitano di un intervento anche invasivo sull'architettura complessiva del sistema segnaletico e sulle responsabilità dei singoli attori sua governance. Gli enti segnalanti potrebbero, ad esempio, rendere disponibili i propri dati, con un livello di input comune e predefinito, tramite una application programming interface (API) alla quale si collegherebbero direttamente le autorità competenti. L’API potrebbe limitare l'accesso ai dati potenzialmente estraibili ai soli dati cui hanno diritto di accesso e potrebbe anche stabilire vincoli sulle richieste, come la quantità di dati e il livello minimo di aggregazione.

Questo approccio consente una maggiore flessibilità alle autorità, che possono adattare i propri processi decisionali e le proprie metodologie agilmente avendo a disposizione una base dati granulare, mentre le diverse esigenze informative possono essere soddisfatte con elaborazioni diverse delle stesse basi dati disponibili nell’area di memorizzazione delle informazioni.

Un’applicazione concreta di tale modello nel campo delle segnalazioni è quella della National Bank of Rwanda (NBR), in cui è stato creato nel 2020 un sistema di data warehouse elettronico (EDW) per automatizzare i processi di reporting al fine di fornire dati alle autorità di supervisione (National Bank of Rwanda, 2017). Partendo da una situazione in cui non esisteva alcun tipo di reporting statistico alle autorità, si è potuta operare una completa standardizzazione dei dati e l’implementazione di un sistema molto innovativo senza dover sostenere alcun costo connesso a un cambio di paradigma. L'EDW consente alla NBR di "estrarre" automaticamente i dati dai sistemi IT degli intermediari partecipanti. Questo approccio

riduce la necessità per i responsabili delle segnalazioni in queste istituzioni di elaborare e inviare manualmente i report, nonché gli errori e le incongruenze spesso associati a questo processo. A tal fine, è stato sviluppato un dizionario dati e a ogni ente finanziario è stato richiesto di scrivere script che potessero “mappare” i dati dei propri sistemi IT a questo dizionario. Tali informazioni vengono quindi inserite in una "zona di sosta" da dove la NBR può estrarre quelle di cui ha bisogno. Questo approccio ha portato anche a un miglioramento dell’utilizzo per fini interni di queste informazioni da parte degli intermediari, ad esempio nell’ambito del risk management.

5.3 Osservazioni sugli approcci alternativi al reporting

L’aspetto sostanziale che accomuna le soluzioni di tipo RegTech e quelle di “data-pull” è che in entrambi i casi le autorità hanno la responsabilità di descrivere lo strato dei dati di input, un dataset che, in un sistema di reporting integrato per i dati statistici, di vigilanza e di risoluzione, tende ad assumere un livello di granularità delle informazioni estremamente elevato.

La tematica della eventuale assunzione da parte delle autorità della responsabilità della produzione “diretta” degli aggregati regolamentari a partire dai dati granulari è stata ampiamente dibattuta anche nel corso dei lavori che hanno portato alla pubblicazione dell’“EBA report on a feasibility study of an integrated reporting system under article 430c CRR”. La discussione parte dalla considerazione che i requisiti segnaletici in ambito statistico, prudenziale e di risoluzione sono definiti a un livello relativamente aggregato e presentano in diversi casi delle sovrapposizioni tra concetti simili, che obbligano i segnalanti a ripetere più volte elaborazioni sostanzialmente simili; tale inefficienza potrebbe essere evitata se le autorità disponessero direttamente dei dati primari (granulari), con i quali effettuare le elaborazioni necessarie per i propri scopi.

I feedback raccolti nell’ambito della consultazione pubblica sul Rapporto dell’EBA hanno evidenziato non poche perplessità in merito alla possibilità di richiedere un unico dataset altamente granulare agli enti segnalanti, in particolare per la predisposizione delle informazioni di risoluzione e prudenziali. Ai fini dell’analisi svolta in questo lavoro, tali considerazioni rilevano in quanto possono essere estese alla granularità delle soluzioni di tipo RegTech e a quelle di “data-pull”.

In primo luogo, un aspetto da tenere in debita considerazione quando si considera una maggiore granularità attiene al quadro giuridico sottostante, che definisce i limiti della raccolta granulare e la definizione e l'applicazione delle regole di trasformazione. Sebbene l'attuale quadro possa, in linea di principio, essere suscettibile di modifiche da parte del legislatore, occorre approfondire importanti tematiche, in particolare relativamente alla “responsabilità” sui dati prodotti. Gli enti segnalanti devono, infatti, rimanere responsabili di tutti i dati aziendali (granulari e aggregati), in particolare in ambito prudenziale e di risoluzione, poiché è su di essi che si basano le decisioni di intervento delle autorità e degli enti stessi. Ciò significa che gli enti devono essere responsabili non solo di tutti i dati granulari prodotti, ma anche degli aggregati che vengono calcolati a partire da essi. Ciò potrebbe limitare i possibili guadagni di efficienza per gli enti derivanti da una soluzione più granulare.

In secondo luogo, richiedere una maggiore granularità a livello consolidato (gruppo bancario), per la componente attinente a intermediari residenti in paesi extra-UE, potrebbe non essere fattibile, in particolare per effetto di vincoli giuridici relativi allo scambio di dati granulari con le autorità competenti della UE.

Inoltre, c’è tutta un’area di informazioni aggregate per il cui calcolo è richiesto il giudizio soggettivo degli esperti e pertanto la loro derivazione da dati di elevata granularità non è automatica. A titolo di esempio si menzionano i seguenti due aspetti:

 il reporting granulare è considerato più fattibile a livello di singolo intermediario, meno a livello consolidato in quanto richiede il giudizio di esperti nell'applicazione dei principi contabili e prudenziali; pertanto, il processo di consolidamento dei dati mal si presta a essere delegato a terzi;

 l’esistenza dei modelli interni e di regole basate su principi consentono agli enti di seguire approcci diversi, rendendo impossibile la definizione di una regola di trasformazione standard per il calcolo dei dati.

Infine, gli enti segnalanti devono mettere a punto strumenti e processi adeguati per l’aggregazione dei dati sul rischio e per il reporting dei rischi che sono valutati come parte della loro governance interna nell’ambito dello SREP (ad es., compliance con i principi BCBS 239; Comitato di Basilea per la Xxxxxxxxx Xxxxxxxx, 0000x).

6. Conclusioni

Nell’ultimo ventennio il contesto nel quale le banche e gli altri intermediari finanziari italiani si sono trovati a soddisfare gli obblighi di segnalazione imposti dai regolamenti delle autorità è diventato sempre più complesso e sfidante, anche in relazione al ritmo decisamente più intenso delle innovazioni regolamentari che è all’origine della continua crescita del volume e della varietà di dati richiesti agli intermediari. La presenza, accanto alla Banca d’Italia, di istituzioni internazionali che possono imporre obblighi segnaletici costituisce un ulteriore elemento di complessità.

L'attuale panorama delle segnalazioni raccolte dagli intermediari bancari e finanziari della UE è costituito da diversi domini informativi (statistico, di vigilanza prudenziale e di risoluzione) non integrati tra loro, la cui responsabilità è posta in capo a diverse autorità. Ne conseguono potenziali inefficienze nel processo di raccolta delle informazioni e il rischio di una duplicazione dei dati richiesti. In relazione a ciò, da alcuni anni sono state avviate riflessioni e iniziative per realizzare un sistema di segnalazione integrato al fine di semplificare tutto il processo di produzione e di gestione delle informazioni statistiche per intermediari segnalanti e autorità. Il principio cardine dovrebbe essere "define data once and report once", come richiesto dall’industria bancaria europea (European Banking Federation, 2018); la realizzazione di un tale sistema favorirebbe, inoltre, la condivisione delle informazioni tra le autorità grazie a una governance condivisa. L’art. 430c della CRR ha dato mandato all’EBA di verificare la fattibilità di un tale sistema, a cui l’EBA ha dato seguito pubblicando il relativo studio di fattibilità il 16 dicembre 2021 (European Banking Authority, 2021b).

Un altro elemento di complessità riguarda la presenza, accanto alle normative segnaletiche armonizzate a livello europeo, di esigenze informative volte a soddisfare una domanda specificamente nazionale, con costi aggiuntivi per enti segnalanti.

Infine, ad alimentare le frequenti innovazioni segnaletiche hanno concorso indubbiamente i numerosi shock registrati negli ultimi anni, a seguito dei quali le autorità – nazionali e internazionali – hanno individuato di volta in volta alcuni gap informativi, pianificando nuove iniziative volte a disporre di un set ancor più completo di dati per monitorare la stabilità del sistema finanziario e prevenire future crisi o limitarne gli effetti.

Questi fattori evolutivi rendono il quadro delle segnalazioni sempre più articolato e complesso, con conseguenti, crescenti difficoltà degli enti segnalanti a rispondere nei tempi richiesti a tali sfide. In Italia, una strategia avviata dalla Banca d’Italia, che continua a produrre risultati concreti dopo oltre trent’anni si fonda su una collaborazione strutturata e su base volontaria con gli enti segnalanti, con l’obiettivo di rendere più efficaci ed efficienti i processi segnaletici. In particolare, come documentato nel presente lavoro, questa collaborazione ha una duplice valenza: ex ante, permette di vagliare con attenzione le nuove proposte di normativa segnaletica al fine di individuare opzioni che favoriscano la produzione di dati di qualità e ne contengano i costi; ex post, tramite la predisposizione della cosiddetta “documentazione PUMA” descrive le logiche di calcolo dai dati di input delle banche agli output richiesti dalle autorità, mettendo a fattor comune le conoscenze normative e l’esperienza operativa dei partecipanti, con il contributo fondamentale dei normatori per la risoluzione degli eventuali dubbi interpretativi. La longevità della cooperazione PUMA è la dimostrazione del contribuito che questa ha fornito per aumentare il livello qualitativo delle segnalazioni e supportare le banche e gli altri intermediari finanziari nella produzione delle informazioni statistiche. Lo spirito di collaborazione e le frequenti interazioni con il normatore hanno, inoltre, permesso alla Banca d’Italia di accrescere il grado di “sensibilità” verso i costi e le problematiche fronteggiate dagli enti segnalanti.

L’approccio italiano della PUMA è stato di esempio per altre autorità in Europa: dapprima l’Austria e, qualche anno dopo, la BCE hanno avviato un’esperienza di cooperazione simile con il rispettivo sistema bancario. L’Austria, pur con alcune differenze di tipo organizzativo, ha replicato l’esperienza italiana su base nazionale; la BCE, in virtù della progressiva armonizzazione a livello europeo delle segnalazioni, ha avviato l’iniziativa di cooperazione BIRD, con il coinvolgimento di un numero significativo di BCN e di banche commerciali europee. Tali esperienze si fondano sul presupposto che il primary reporting rimanga aggregato con poche eccezioni (sia in ambito statistico, quali ad esempio AnaCredit e SHSG, sia in ambito di vigilanza, quali le grandi esposizioni) e che i processi di calcolo e la connesse responsabilità in merito alla predisposizione dei flussi da trasmettere alle autorità restino una prerogativa degli enti segnalanti.

Tuttavia, è in corso un dibattito a livello europeo sul valore dei dati granulari per le autorità e sulla possibilità di trasferire in capo a queste ultime la complessità elaborativa per la produzione degli indicatori aggregati. In tale contesto il dibattito si concentra in particolare su due approcci al regulatory reporting: il primo è noto come “RegTech” e si basa sulla produzione di una normativa in formato digitale che guida le elaborazioni di dati aggregati a partire da uno schema di input standardizzato altamente granulare; nel secondo approccio, denominato “data-pull model”, sarebbero direttamente le autorità a estrarre, a seconda dei bisogni, le informazioni da uno schema di input altamente granulare disponibile presso gli intermediari e le elaborerebbero in base alle specifiche esigenze.

Tra le soluzioni di cooperazione, quali la PUMA e il BIRD, e quelle basate su schemi di input obbligatori e altamente granulari, quali RegTech e “data-pull”, si ritiene che le prime siano preferibili per una serie di motivi.

Innanzitutto, le autorità non subentrano ai segnalanti nell’elaborazione delle informazioni granulari: al di là degli oneri e della complessità computazionale (si pensi, ad esempio, all’enorme problema del consolidamento dei dati dei gruppi bancari, con una particolare criticità per la raccolta dei dati dalle legal entities extra-europee), l’aspetto più rilevante è che i segnalanti devono continuare a rimanere consapevoli e responsabili dei numeri prodotti in quanto questi non rappresentano solo un obbligo segnaletico di natura statistica nei confronti delle autorità, ma piuttosto devono guidare le scelte strategiche aziendali.

Un secondo aspetto di cui tenere conto quando si considera una maggiore granularità degli obblighi segnaletici attiene al quadro giuridico sottostante, che definisce i limiti della raccolta granulare e la

definizione e l'applicazione delle regole di trasformazione per ottenere gli aggregati di natura prudenziale e di risoluzione necessari alle autorità.

Anche nella prospettiva del BIRD, si ritiene che in Italia l’esperienza della cooperazione PUMA continuerà a rappresentare un punto di riferimento essenziale per i produttori dei dati, pur in un quadro in cui occorrerà effettuare alcuni interventi per garantire la piena integrazione tra le due soluzioni. La possibilità di realizzare questa integrazione dipende comunque dal grado di maturazione che sarà raggiunto dal progetto BIRD, al momento tutt’altro che consolidato, e dalla sua capacità di diventare effettivamente un punto di riferimento per gli enti segnalanti, al pari di quanto si riscontra da anni per la PUMA.

Bibliografia

BaFin (2022), A reporting system for the future, Feasibility study on “Redesign Options for Regulatory Reporting” (short version).

Bank of England (2020), Transforming data collection from the UK financial sector, Discussion Paper, January.

Casa M., Xxxxxxxx Xxxxxxxx L., Mellone L., Xxxxxxxxx F. (2022), L’approccio integrato della Banca d’Italia alla raccolta e produzione dei dati creditizi e finanziari, Questioni di Economia e Finanza n. 667, Banca d’Italia.

Casa M., D’Xxxxxxx X. (2020), Le statistiche della Banca d’Italia nell’epoca del coronavirus, Banca d’Italia, Note COVID-19, Ottobre (xxxxx://xxx.xxxxxxxxxxxx.xx/xxxxxxxxxxxxx/xxxx-xxxxx-00/0000/Xxxx-XXXXX- Statistiche-2020.10.22.pdf).

Codd E. F. (1970), "A Relational Model of Data for Large Shared Data Banks". Communications of the ACM, 13/6.

Comitato di Basilea per la Vigilanza Bancaria (2009), Strengthening the resilience of the banking sector, Consultative Document, Banca dei Regolamenti Internazionali.

Comitato di Basilea per la Vigilanza Bancaria (2010a), Basilea 3 – Schema di regolamentazione internazionale per il rafforzamento delle banche e dei sistemi bancari, Banca dei Regolamenti Internazionali.

Comitato di Basilea per la Vigilanza Bancaria (2013a), Principi per un’efficace aggregazione e reportistica dei dati di rischio, Banca dei Regolamenti Internazionali.

Commissione europea (2013), Capital Requirements - CRD IV/CRR – Frequently Asked Questions, MEMO/13/690.

Commissione europea (2020), Commission Interpretative Communication on the application of the accounting and prudential frameworks to facilitate EU bank lending - Supporting businesses and households amid COVID-19, COM(2020) 169 final.

Cooperazione PUMA, Manuale tecnico funzionale, sito web della Cooperazione PUMA, xxxxx://xxx.xxxxxxxxxxxxxxxx.xxx/xxxxxxxx/xxxxxxx/xxxxx.xxxx.

Xxxxxxxx J.C., Xxxxxxxxx K., Xxxxxx J., Xxx X. (2020), From data reporting to data-sharing: how far can suptech and other innovations challenge the status quo of regulatory reporting?, FSI Insights on policy implementation Xx 00, Xxxx xxx Xxxxxxxxxxxxx Xxxxxxxxxxx.

Xx Xxxxx X., Piazza M. (2020), A silent revolution. How central bank statistics have changed in the last 25 years, Questioni di Economia e Finanza n. 579, Banca d’Italia.

Del Vecchio V. (2001), The Banca d’Italia’s active statistical meta-information system, Banca d'Italia, xxxxx://xxx.xxxxxxxxxxxx.xx/xxxxxxxxxxx/xxxxxxxx-xxxx/xxxxxxx-xxxxxxxxxxx- statistico/modellazione/The_BI_Active.pdf.

Xxx Xxxxxxx V., Xx Xxxxxxxx X., Pambianco S. (2007), The ‘Matrix’ Model: Unified model for statistical data representation and processing, Banca d'Italia, xxxxx://xxx.xxxxxxxxxxxx.xx/xxxxxxxxxxx/xxxxxxxx-xxxx/xxxxxxx- informativo-statistico/modellazione/matrixmod.pdf.

Xx Xxxxxxxxxxxxxxx (2016), Micro data and governance. The path for going from the particular to the general, 8th European Central Bank Conference on Statistics “Central Banking Statistics. Moving beyond the aggregates”, Xxxxxxxxx xx Xxxx, 0 July 2016.

European Banking Authority (2020a), Guidelines on reporting and disclosure of exposures subject to measures applied in response to the COVID‐19 crisis, EBA/GL/2020/07.

European Banking Authority (2020b), Guidelines on supervisory reporting and disclosure requirements in compliance with the CRR ‘quick fix’ in response to the COVID‐19 pandemic, EBA/GL/2020/11.

European Banking Authority (2021a), Study of the cost of compliance with supervisory reporting requirements report, EBA/REP/2021/15.

European Banking Authority (2021b), EBA report on a feasibility study of an integrated reporting system under article 430c CRR, EBA/REP/2021/38.

European Banking Federation (2018), Data reporting: European banks underline the need for an integrated and standardized EU framework, EBF Press Release.

Xxxxxxxxxx M., ABBL – The Luxembourg Bankers’ Association (2019), Reporting 3.0 in Luxembourg: Setting up of Financial Reporting Hub, 23rd XBRL Europe Day in Paris, France, May 28-29th 2019 xxxxx://xxx.xxxxxxxxxx.xxx/xx-xxxxxxx/xxxxxxx/0000/00/00_Xxxxxxxxx-Xxx-Xxxxxxxxxx- 23rdXBRLEuropeDay_v1.pdf

Xxxxxx, X., Xxxxxxx X. (2017), Leveraging ‘suptech’ for financial inclusion in Rwanda, Private Sector Development (blog), World Bank.

Xxxxxxxxx X., Xxxxxxxx X., Xxxxxx J. (2018), Managing the processing chain from banks’ source data to statistical and regulatory reports in Austria, XxXX Xxxxxxxxxxx X0/00.

Xxxxxxxxx Financial Reporting Hub (2019), Industrialization of regulatory reporting, 26th RegTech Convention 2019, Frankfurt am Main.

National Bank of Rwanda (2017), Annual Report, 1 July 2016–30 June 2017.

PA Consulting (2020), Digital regulatory reporting: review of phases 1 and 2 of the digital regulatory reporting initiative, September 2020.

Padoa-Schioppa T. (1993), Le segnalazioni statistiche rivolte alla Banca d'Italia come fondamento della gestione delle aziende di credito, intervento alla prima convention dell’Associazione Italiana per la Pianificazione ed il Controllo di Gestione in Banca e nelle Istituzioni Finanziarie, Roma, 12 febbraio 1993.

SDMX Technical Working Group - VTL Task Force (2018), VTL – version 2.0 (Validation & Transformation Language) Part 1 - User Manual, April 2018, xxxxx://xxxx.xxx/xx-xxxxxxx/xxxxxxx/XXX- 2.0-User-Manual-20180416-final.pdf.

SDMX (2021), SDMX STANDARDS: SECTION 6 - TECHNICAL NOTES - Version 3.0, October

2021, xxxxx://xxxx.xxx/xx-xxxxxxx/xxxxxxx/XXXX_0-0-0_XXXXXXX_0_XXXXX-0_0.xxx.