Decifrare i dati Bankit: una guida pratica
Come navigare le tavole statistiche della Banca d’Italia, trovare la combinazione giusta di codici e usare i dati una volta estratti
Paolo Volterra 
Il database statistico della Banca d’Italia (Bankit.sqlite) contiene centinaia di tavole con decine di migliaia di serie. Le convenzioni di codifica — codici FENEC, codici settore come S14, 600, SBI71 — non sono sempre auto-documentate nel dump locale. Questo documento propone un metodo sistematico per orientarsi tra le tavole, identificare la combinazione corretta di parametri e passare dai dati grezzi all’analisi.
Bankit, Banca d’Italia, Infostat, data discovery, codice FENEC, codice SET_CTP, depositi bancari, SQLite, guida metodologica
1 Perché Bankit
La Banca d’Italia pubblica i dati del sistema bancario e finanziario italiano attraverso la piattaforma Infostat [1]. Un dump SQLite locale del database — che chiameremo Bankit.sqlite — contiene centinaia di tavole organizzate per tipologia statistica: stock e flussi bancari (BSIB, TFR, TDB), tassi di interesse (MIR), indicatori di rischio (TRI), e molto altro.
Il problema pratico è duplice. Da un lato, orientarsi tra le tavole: in quale tabella si trova il dato che serve? Dall’altro, decifrare i codici: uno stesso concetto (es. «famiglie consumatrici») può comparire come S14, 600, SBI28 a seconda della tavola, e la scelta sbagliata produce numeri completamente diversi.
Questo documento sistematizza quanto appreso navigando il database per un caso concreto — l’estrazione dei depositi bancari delle famiglie consumatrici per provincia [2] — e lo generalizza in un metodo riutilizzabile. La prima parte descrive come trovare la combinazione giusta di tavola e codici; la seconda suggerisce direzioni di analisi una volta che i dati sono stati estratti.
2 Architettura del database
2.1 Struttura delle tabelle
Il dump Bankit.sqlite contiene circa 245 tabelle. I nomi seguono una convenzione a prefisso che indica la provenienza:
| Prefisso | Fonte statistica | Esempi |
|---|---|---|
TDB* |
Tavole depositi bancari | TDB10290, TDB20290 |
TFR* |
Tavole finanziarie regionali | TFR10241, TFR10269 |
TRI* |
Tavole rischio e incagli | TRI30021, TRI30496 |
BSIB* |
Bilanci bancari (stock) | BSIB0800 |
MIR* |
Tassi di interesse (MIR) | MIR0100, MIR0400 |
BAM_decodifiche |
Decodifica di codici (parziale) | settori, valute |
dove_SET_CTP |
Mappa tabella → colonna che usa SET_CTP |
Le tabelle nuts_it_2024, comuni, regioni forniscono la geografia.
I numeri nelle sigle TDB* hanno un significato: TDB10290 parte dal 2007, TDB20290 dal 2011 (la versione più recente con copertura ridotta). In generale, la serie TDB1* ha la copertura storica più lunga, la serie TDB2* ha una finestra temporale più corta ma dati più aggiornati o definizioni riviste.
2.2 Colonne ricorrenti
La maggior parte delle tavole condivide queste colonne:
DATA_OSS: data dell’osservazione (tipicamente fine mese o trimestre)VALORE: il valore numerico. Attenzione all’unità: in molte tavole è in migliaia di euro (da dividere per 1.000 per milioni, per 1.000.000 per miliardi). Altre tavole usano milioni. L’ordine di grandezza va verificato caso per caso confrontando con valori noti.FENEC: codice del fenomeno economico (es.1041810= depositi esclusi PCT,52000100= versione aggiornata,1001301= depositi a vista e overnight)SET_CTP: codice del settore di controparte (es.600,S14,S11,SBI28)LOC_CTP: localizzazione geografica della controparte (IT= nazionale, codici NUTS2 di 4 caratteri, NUTS3 di 5 caratteri)ENTE_SEGN: ente segnalante (es.1070001= banche + Cassa Depositi e Prestiti,1100010= solo banche)
3 Decifrare i codici
3.1 FENEC: il fenomeno economico
FENEC è un codice numerico che identifica cosa viene misurato. Non esiste una tabella di decodifica completa nel dump SQLite. I codici più comuni:
| FENEC | Descrizione (ricostruita) | Tavole tipiche |
|---|---|---|
1041810 |
Depositi (esclusi PCT) | TDB10290 |
52000100 |
Depositi (versione aggiornata) | TDB20290 |
1001301 |
Depositi a vista e overnight | TFR10269 |
1077778 |
Sotto-componente depositi | TDB10295 |
52000700 |
Prestiti (incluse sofferenze) | BSIB0800, TDB20295 |
Il modo più affidabile per identificare un FENEC sconosciuto è confrontare il valore nazionale (LOC_CTP='IT') con un valore noto dello stesso ordine di grandezza. Per esempio: se il totale nazionale è circa 1.200 miliardi, siamo nell’ordine dei depositi; se è 600 miliardi, potrebbe essere una sotto-componente; se è 60 miliardi, è qualcosa di molto più specifico.
3.2 SET_CTP: il settore di controparte
Il codice SET_CTP identifica chi detiene il deposito o il prestito. Qui sta una delle insidie maggiori. Il SEC 2010 [3] definisce i settori istituzionali con codici S*, ma Bankit usa anche codici proprietari numerici. La tabella BAM_decodifiche copre solo alcuni codici; dove_SET_CTP elenca le tabelle che usano questo campo ma non fornisce la decodifica.
Esempio critico — famiglie consumatrici:
S14nel SEC 2010 = «Famiglie» (households)- In Bankit,
S14può includere componenti aggiuntive (~90 miliardi in più nel caso depositi) rispetto alla definizione stretta di «famiglie consumatrici» - Il codice
600— numerico, non SEC — corrisponde esattamente alle «famiglie consumatrici» secondo la classificazione interna Bankit S14BI2= «Famiglie produttrici» (un sotto-insieme distinto)SBI71in altre tavole (es.BSIB0800) = famiglie consumatrici + produttrici
Regola pratica: se una tavola ha sia S14 sia 600, provare entrambi e confrontare con un valore di riferimento noto. La differenza tra i due può rivelare cosa include il codice SEC più ampio.
3.3 LOC_CTP: la geografia
IT= intero territorio nazionale- 4 caratteri (es.
ITC4) = NUTS2 (regioni) - 5 caratteri (es.
ITC4C) = NUTS3 (province)
La tabella nuts_it_2024 nel database fa da ponte tra codici NUTS3 e nomi di province/regioni.
4 Caso studio: depositi delle famiglie consumatrici
Per replicare i dati di un articolo che riportava 1.162,8 miliardi di euro di depositi di famiglie consumatrici a aprile 2026 [2], il percorso è stato:
4.1 Primo tentativo (sbagliato)
TDB10290 + SET_CTP='S14' + FENEC=1041810 → 1.247,8 miliardi. Scostamento: +7,3%. Direzione giusta ma livello sbagliato.
4.2 Diagnosi
La stessa tavola TDB10290 contiene anche il codice SET_CTP='600'. Provandolo: 1.157,9 miliardi — molto più vicino ma ancora ~5 miliardi sotto.
4.3 Trovare la tavola giusta
Il passo successivo è stato interrogare tutte le tavole con SET_CTP='600' per trovare quella con il FENEC che desse il valore nazionale esatto. Su 245 tabelle, quattro contengono il settore 600 con dati provinciali:
| Tavola | FENEC | Valore naz. (mld) | Nota |
|---|---|---|---|
TDB10290 |
1041810 | 1.157,9 | Vicino ma sotto |
TDB10295 |
1077778 | 618,1 | Sotto-componente |
TDB20290 |
52000100 | 1.162,8 | Match esatto |
TDB20295 |
52000700 | 618,3 | Sotto-componente |
Risultato: TDB20290 + SET_CTP='600' + FENEC=52000100 riproduce esattamente tutti i valori dell’articolo.
4.4 Verifica sui dati sub-nazionali
Il test definitivo è sui dati disaggregati. Confrontando i delta per 103 province tra i nostri dati e quelli pubblicati, 99 corrispondono esattamente (correlazione 0,92). L’unica discrepanza significativa è la Sardegna, dove il database manca di una provincia (ITG2H, Sud Sardegna) all’ultima data disponibile — un problema di copertura, non di codici.
4.5 Lezioni dal caso
- SET_CTP ‘600’ ≠ ‘S14’: la classificazione Bankit ha codici proprietari che non coincidono 1:1 con i codici SEC 2010, anche quando il concetto sembra lo stesso.
- Tabelle «gemelle»:
TDB1*eTDB2*spesso contengono lo stesso fenomeno con definizioni o finestre temporali diverse. Provare entrambe. - Il valore nazionale è l’ancora: se esiste un valore di riferimento affidabile per il totale Italia, usarlo per validare la combinazione tavola+FENEC+SET_CTP prima di scendere al dettaglio provinciale.
- Verifica sub-nazionale: la corrispondenza sul totale nazionale può nascondere errori di composizione. Solo il confronto sui dati disaggregati (province, settori) dà la certezza di aver trovato la combinazione giusta.
5 Metodo di ricerca sistematica
Quando si affronta una domanda nuova («esiste una tavola con il dato X?»), l’approccio è:
5.1 Passo 1: cercare per parola chiave
Il database non ha metadati testuali ricercabili direttamente in SQL. La tabella LEGEND contiene descrizioni in italiano per alcune tavole (es. «Depositi per provincia»), ma la copertura è parziale. La tabella STRUCTURE elenca le colonne di ogni tavola con i domini associati.
-- Cerca tavole con una colonna specifica
SELECT name FROM sqlite_master
WHERE type='table' AND name NOT LIKE 'nuts%';5.2 Passo 2: screening per settore e localizzazione
Per ogni tavola candidata, verificare: - Contiene SET_CTP? Se sì, include il settore cercato? - Contiene LOC_CTP? Se sì, a che granularità (nazionale, regionale, provinciale)? - Quali FENEC sono disponibili per quel settore?
# Pattern di screening
for t in candidate_tables:
sectors = query(f"SELECT DISTINCT SET_CTP FROM '{t}'")
fenecs = query(f"SELECT DISTINCT FENEC FROM '{t}' WHERE SET_CTP='TARGET'")
locs = query(f"SELECT DISTINCT LOC_CTP FROM '{t}' WHERE SET_CTP='TARGET' LIMIT 10")5.3 Passo 3: validazione nazionale
Per ogni combinazione candidata (tavola + FENEC + SET_CTP), estrarre il valore nazionale più recente e confrontarlo con un benchmark noto.
v = query(f"SELECT VALORE FROM '{t}' WHERE SET_CTP='TARGET'
AND FENEC=F AND LOC_CTP='IT'
ORDER BY DATA_OSS DESC LIMIT 1")5.4 Passo 4: validazione sub-nazionale
Se il nazionale corrisponde, verificare su un campione di province per confermare che la composizione geografica sia corretta.
5.5 Passo 5: verifica delle unità
L’unità di misura (VALORE) va sempre verificata. Il modo più rapido: confrontare l’ordine di grandezza del totale nazionale con un dato pubblico noto. Se il PIL italiano è circa 2.000 miliardi, un valore di 1.200 miliardi per i depositi è plausibile; un valore di 1.200 milioni no.
6 Idee di utilizzo
Una volta identificata la combinazione giusta di tavola e codici, i dati Bankit si prestano a diverse direzioni di analisi.
6.1 Analisi territoriale
Il database ha granularità provinciale (NUTS3) per decine di fenomeni: depositi, prestiti, sofferenze, tassi di decadimento, numero di sportelli. Questo permette di costruire mappe, classifiche e indicatori di divergenza territoriale che vanno oltre le medie nazionali.
Alcune domande: - Quali province hanno perso più depositi in termini reali (al netto dell’inflazione)? - La riduzione degli sportelli bancari è uniforme o colpisce più alcune aree? - Esiste una correlazione tra calo dei prestiti e aumento delle sofferenze a livello provinciale?
6.2 Serie storiche e cicli
La profondità temporale (mensile dal 2007 o 2011) consente di analizzare l’evoluzione ciclica dei fenomeni bancari: la corsa ai depositi durante il Covid, il successivo rallentamento con l’inflazione, la trasmissione dei rialzi BCE ai tassi sui prestiti.
6.3 Composizione e sostituzione
Confrontando diverse componenti dello stesso fenomeno, emergono dinamiche di sostituzione. Per esempio: i depositi in conto corrente stagnano mentre crescono i titoli di Stato in portafoglio alle famiglie — un indicatore di riorientamento del risparmio.
6.4 Integrazione con altre fonti
I dati Bankit possono essere incrociati con: - ISTAT: popolazione residente per provincia → indicatori pro capite - InfoCamere: numero di imprese per provincia → prestiti per impresa - Agenzia delle Entrate: reddito imponibile → depositi in rapporto al reddito - Eurostat: confronti con altri paesi europei
Il join geografico passa sempre attraverso i codici NUTS.
6.5 Indicatori compositi
Combinando più variabili Bankit si possono costruire indicatori sintetici: - Indice di bancarizzazione: depositi pro capite × sportelli per abitante - Indice di stress creditizio: sofferenze / prestiti totali - Velocità di trasmissione della politica monetaria: lag tra variazioni BCE e variazioni dei tassi sui nuovi prestiti
6.6 Automazione e monitoraggio
Il dump SQLite si aggiorna periodicamente. Un notebook parametrizzato su tavola + FENEC + SET_CTP permette di aggiornare automaticamente grafici e analisi a ogni rilascio dei dati, senza riscrivere il codice.
Trasparenza sull’uso dell’intelligenza artificiale
L’uso di strumenti di intelligenza artificiale generativa è dichiarato esplicitamente in quanto parte del processo di lavoro seguito nella redazione del presente documento. Tali strumenti sono stati impiegati a supporto della lettura, della sintesi, della riorganizzazione argomentativa e della revisione testuale, sempre nell’ambito di un processo pienamente controllato dall’autore.
La responsabilità per le fonti utilizzate, le analisi condotte, le verifiche effettuate, le interpretazioni proposte e le conclusioni formulate resta interamente in capo all’autore.
L’intelligenza artificiale è stata utilizzata come ambiente di supporto cognitivo ed editoriale, non come fonte primaria, autore autonomo o sostituto del giudizio critico.