Come funziona il codice fiscale: l'algoritmo spiegato

Il codice fiscale è probabilmente l'identificatore più usato in Italia, e quasi nessuno sa come è fatto. Non è un numero assegnato a caso da un ufficio: è il risultato di un algoritmo pubblico, deterministico, che chiunque può calcolare a mano con carta e penna partendo da cinque informazioni — cognome, nome, data di nascita, sesso e comune di nascita. Questa proprietà, che sembra un dettaglio tecnico, ha conseguenze pratiche importanti su cosa il codice fiscale può e non può dimostrare.

In questo articolo smontiamo i sedici caratteri uno per uno, con esempi verificati, e arriviamo alla parte che di solito viene liquidata in una riga: il carattere di controllo e l'omocodia. Alla fine dovrebbe essere chiaro perché validare un codice fiscale lato server è utile, ma perché trattarlo come una prova d'identità è un errore.

La struttura dei sedici caratteri

Il codice fiscale delle persone fisiche è lungo esattamente sedici caratteri alfanumerici, divisi in cinque blocchi di lunghezza fissa. Prendiamo come esempio di riferimento una persona di fantasia: Mario Rossi, nato a Roma il 12 luglio 1985. Il suo codice fiscale è RSSMRA85L12H501I.

Nessuno di questi blocchi contiene informazioni segrete. Tutti derivano da dati che una persona comunica normalmente in decine di contesti: il nome sul citofono, la data di nascita su un profilo social, il comune di nascita in un curriculum. È il primo indizio del fatto che il codice fiscale sia un identificatore, non un segreto.

Le tre lettere del cognome

La regola per il cognome è la più semplice delle due regole alfabetiche: si prendono le consonanti nell'ordine in cui compaiono, fino a tre. Se non bastano, si aggiungono le vocali, sempre nell'ordine originale. Se il cognome è così corto da non arrivare a tre caratteri neanche così, si riempie a destra con la lettera X.

• Rossi → consonanti R, S, S → RSS
• Bianchi → consonanti B, N, C, H → si fermano alle prime tre → BNC
• Esposito → consonanti S, P, S, T → SPS
• Fo → consonante F, vocale O, poi manca un carattere → FOX

L'ultimo caso non è un esempio di scuola: cognomi di due lettere esistono davvero, e la X finale è il motivo per cui capita di vedere codici fiscali che sembrano contenere un errore di battitura.

Le tre lettere del nome, e la regola che quasi tutti sbagliano

Qui c'è l'unica vera insidia dell'algoritmo. Per il nome si contano prima le consonanti. Se sono tre o meno, si applica esattamente la stessa regola del cognome. Ma se sono quattro o più, non si prendono le prime tre: si prendono la prima, la terza e la quarta, saltando deliberatamente la seconda.

Data di nascita e sesso, compressi in cinque caratteri

L'anno usa solo le ultime due cifre — un problema di ambiguità che il codice fiscale non risolve e di cui parliamo più avanti. Il mese diventa una lettera, secondo una tabella che salta volutamente le lettere facilmente confondibili con altre.

Il giorno occupa due cifre, ma con una convenzione che codifica anche il sesso: per gli uomini si scrive il giorno così com'è (01–31), per le donne si somma 40, ottenendo un valore tra 41 e 71. Non serve quindi un campo separato per il sesso, e il giorno resta comunque leggibile.

• Mario Rossi, uomo nato il 12 luglio 1985 → 85 L 12 → RSSMRA85L12H501I
• Anna Bianchi, donna nata il 3 febbraio 1990 → 90 B 43 (3 + 40) → BNCNNA90B43F205C
• Giulia Esposito, donna nata l'8 giugno 2001 → 01 H 48 (8 + 40) → SPSGLI01H48L219H

Il codice del comune di nascita

I quattro caratteri successivi sono il codice catastale del comune, storicamente noto come codice Belfiore: una lettera seguita da tre cifre. Roma è H501, Milano F205, Napoli F839, Torino L219. Per chi è nato all'estero la lettera iniziale è sempre Z, seguita dal codice dello stato.

Il carattere di controllo

L'ultimo carattere non aggiunge informazione: serve a rilevare errori. Si calcola sui quindici caratteri precedenti, e il meccanismo è più raffinato di una semplice somma, perché deve intercettare anche gli errori di trasposizione — due caratteri adiacenti scambiati, l'errore di battitura più comune insieme al singolo carattere sbagliato.

1. Ogni carattere viene convertito in un numero, ma con due tabelle diverse a seconda che si trovi in posizione dispari o pari (contando da 1).
2. I valori vengono sommati.
3. Della somma si prende il resto della divisione per 26.
4. Il resto viene mappato su una lettera: 0 → A, 1 → B, e così via fino a 25 → Z.

Il punto chiave sono le due tabelle. Nelle posizioni pari la conversione è quella ovvia (le cifre valgono se stesse, A vale 0, B vale 1, fino a Z che vale 25). Nelle posizioni dispari i valori sono volutamente irregolari e sparsi: A vale 1, B vale 0, C vale 5, D vale 7, E vale 9, e così via. È proprio questa asimmetria a rendere il controllo sensibile allo scambio di due caratteri vicini: se le due tabelle fossero uguali, invertire due caratteri adiacenti lascerebbe la somma invariata e l'errore passerebbe inosservato.

RSSMRA85L12H501  →  carattere di controllo: I
RSSMRA85L12H501I →  valido
RSSMRA85L12H501A →  non valido (carattere di controllo errato)

L'omocodia: quando due persone ottengono lo stesso codice

L'algoritmo comprime cognome, nome, data e luogo in sedici caratteri, e come ogni compressione con perdita può produrre collisioni. Due persone con cognomi e nomi che generano le stesse triplette, nate lo stesso giorno nello stesso comune, ottengono lo stesso codice fiscale. Il fenomeno si chiama omocodia e non è raro come si potrebbe pensare, soprattutto tra persone nate all'estero, dove il codice del paese è unico per milioni di persone.

L'Agenzia delle Entrate risolve il conflitto sostituendo le cifre con lettere, partendo dalla cifra più a destra e procedendo verso sinistra, secondo una tabella fissa.

Dopo la sostituzione il carattere di controllo viene ricalcolato sul codice modificato. Il primo livello di omocodia per Mario Rossi sostituisce l'ultima cifra del codice di Roma (H501 diventa H50M) e produce RSSMRA85L12H50MA — dove anche l'ultima lettera cambia, da I ad A, perché il controllo si ricalcola sempre.

Cosa il codice fiscale non garantisce

Qui arriviamo alla conseguenza pratica più importante, e alla ragione per cui vale la pena capire l'algoritmo invece di limitarsi a usarlo. Poiché il codice fiscale è interamente calcolabile da dati anagrafici pubblici, la sua conoscenza non dimostra nulla sull'identità di chi lo comunica.

• Non è un segreto: chiunque conosca nome, cognome, data e luogo di nascita di una persona può ricostruirne il codice fiscale in pochi secondi.
• Non è una prova di identità: un codice formalmente valido dice solo che qualcuno ha applicato correttamente l'algoritmo, non che esista una persona reale con quei dati.
• Non è univoco in senso stretto: l'omocodia esiste proprio perché due persone possono generare lo stesso codice.
• Non è invariante: chi ottiene una rettifica anagrafica, o una correzione di dati errati, riceve un codice fiscale diverso. Usarlo come chiave primaria di un database è una scelta che prima o poi costa una migrazione.
• Non disambigua il secolo: l'anno ha solo due cifre, quindi un codice con 25 può indicare il 1925 o il 2025. Solo il contesto lo risolve.

La conclusione operativa è netta: la validazione del codice fiscale è un controllo di forma, non di autenticazione. Serve a intercettare errori di battitura prima che finiscano in un database, e in questo è efficace. Non serve, e non va usata, come fattore di verifica dell'identità: per quello esistono i documenti e i sistemi di identità digitale.

Validare in pratica

Se dovete implementare la validazione, l'ordine dei controlli conta, perché ognuno è più costoso del precedente e scarta un insieme diverso di errori.

1. Normalizzate: rimuovete gli spazi e portate tutto in maiuscolo. Gli utenti incollano codici con spazi molto più spesso di quanto si immagini.
2. Verificate la forma: sedici caratteri, solo lettere maiuscole e cifre. Attenzione a non pretendere cifre nelle posizioni numeriche, per via dell'omocodia.
3. Ricalcolate il carattere di controllo sui primi quindici caratteri e confrontatelo con il sedicesimo. Questo intercetta la stragrande maggioranza degli errori di battitura.
4. Solo se serve davvero, decodificate data e comune per verificarne la coerenza con gli altri dati raccolti — ricordando che serve una tabella che includa i comuni soppressi.

E soprattutto: fatelo lato server. Una validazione solo nel browser è un aiuto all'utente, non un controllo — chiunque può aggirarla, e i dati che arrivano dalle integrazioni non passano mai dal vostro form.