Struttura IBAN e il controllo mod-97 spiegato

Un IBAN è uno dei pochi identificatori la cui grammatica interna è pubblicata per intero. Leggilo da sinistra e attraversi tre zone: un codice paese, una coppia di cifre di controllo e poi la parte di conto nazionale. Le prime due zone sono uguali ovunque, mentre la terza cambia forma da un paese all’altro.

Questa combinazione è ciò che rende l’identificatore al tempo stesso facile da analizzare e facile da convalidare male. Questo articolo separa le parti, spiega l’aritmetica mod-97 che le tiene insieme e mostra perché l’aritmetica è la cosa meno interessante che la stringa abbia da dire.

Quali sono le parti di un IBAN?

Il nome sta per numero di conto bancario internazionale, e l’obiettivo di progetto era permettere a un’unica stringa di portare informazioni sufficienti perché un trasferimento transfrontaliero fosse instradato senza un foglio di istruzioni separato.

Il codice paese dice quali regole nazionali si applicano; le due cifre dicono se la stringa è sopravvissuta intatta alla trasmissione; il resto è il conto così come il paese stesso lo scrive. Solo la zona centrale è standardizzata dalle regole IBAN, e solo la zona centrale può essere verificata senza conoscere la disposizione del paese.

Gli esempi usati in tutto questo articolo sono segnaposto volutamente sintetici, scelti per mostrare come le parti si incastrano. Nessuno di essi è un identificatore di conto reale, e nulla di quanto qui scritto va letto come l’affermazione che un particolare conto esista.

Il codice paese e le due cifre di controllo ISO

Le due cifre dopo il codice paese provengono da un sistema di caratteri di controllo concordato a livello internazionale, la disposizione MOD 97-10 che appartiene alla famiglia passata in rassegna in Algoritmi cifra di controllo. Poiché l’aritmetica ripiega l’intera stringa in quelle due posizioni, cambiare qualsiasi altro carattere le invalida.

È per questa proprietà che la coppia vale la pena di essere calcolata anche quando la disposizione nazionale è sconosciuta. Una routine può verificare i primi quattro caratteri rispetto al resto della stringa e raggiungere una conclusione sull’integrità della trasmissione senza possedere una sola specifica nazionale. Ciò che non può fare è decidere se la lunghezza sia giusta per il paese indicato, perché quella lunghezza vive nelle regole nazionali.

Dentro quelle regole nazionali i campi differiscono ampiamente. Un paese può impacchettare un codice bancario e un numero di conto in un numero fisso di posizioni; un altro può aggiungere una filiale, un marcatore di valuta o una cifra di controllo nazionale. Lo standard IBAN registra quanto è lunga l’intera stringa di ogni paese, ma il significato di ciascun campo interno resta al paese che lo ha definito.

Perché il BBAN spesso porta anche una cifra di controllo nazionale?

Perché la parte di conto era di solito un numero nazionale funzionante molto prima di essere incorporata in un formato transfrontaliero. Le banche avevano già costruito la propria difesa contro gli errori di trascrizione, e l’involucro internazionale non l’ha rimossa. Il risultato è una stringa che porta due controlli indipendenti: la coppia internazionale in testa e qualunque cosa il paese abbia inserito all’interno.

I due sono calcolati da materiale diverso, quindi falliscono per motivi diversi. Un codice paese corrotto rompe la coppia internazionale; una cifra di conto digitata male dentro la parte nazionale può rompere il controllo nazionale, la coppia internazionale o entrambi, a seconda di dove si trova. Quando un validatore segnala che il formato è corretto ma il controllo è fallito, la spiegazione abituale è che la parte nazionale e il suo controllo non concordano più.

Per chi implementa questo significa che la stessa stringa può essere giusta a un livello e sbagliata a un altro, e un messaggio che confonde i due non è abbastanza. Di’ quale controllo è fallito e di’ quale parte della stringa copre — la posizione del problema è l’informazione di cui l’utente ha bisogno.

Trasformare le lettere in numeri: l’idea dietro mod-97

L’aritmetica ha bisogno di cifre, ma la stringa si apre con delle lettere. Il ponte è una sostituzione: ogni lettera viene rimpiazzata da un numero secondo una regola pubblicata fissa, dopo che i primi quattro caratteri sono stati spostati in fondo alla stringa. L’intero valore trasformato viene poi diviso per novantasette, e un identificatore valido è quello che lascia un resto specifico.

Riordinare anziché accodare è la parte sottile. Spostare il codice paese e le cifre di controllo in fondo significa che le cifre da verificare si trovano alla fine del numero da dividere, quindi influenzano direttamente il resto. È questo che permette alle due cifre iniziali di agire come controllo su tutto ciò che viene dopo.

Ne derivano due conseguenze per chi scrive codice. Primo, il valore trasformato è molto più lungo di quanto qualsiasi tipo intero ordinario possa contenere, quindi la divisione deve essere eseguita cifra per cifra o con una struttura per numeri grandi; i tentativi di farla con un semplice intero a 64 bit traboccano silenziosamente e producono sciocchezze su alcuni input. Secondo, le lettere devono essere convertite con la mappatura pubblicata esatta — approssimazioni come un rango alfabetico che parte da uno danno un resto che sembra plausibile ed è semplicemente sbagliato.

Perché una prova superata non dimostra che un conto esiste?

L’aritmetica mod-97 confronta la stringa con se stessa. Non ha alcuna conoscenza di alcuna banca, di alcun cliente o di alcun conto, e nessuno presso un istituto emittente viene consultato quando viene eseguita. Un valore può soddisfare perfettamente l’aritmetica e comunque non appartenere ad alcun conto, perché soddisfare l’aritmetica è esattamente ciò che fa di proposito qualsiasi generatore.

Verificare che un conto sia aperto e raggiungibile è un’operazione diversa con un profilo di costo diverso. Richiede una consultazione di una directory attiva, che può avere limiti di frequenza, può non essere disponibile fuori dall’orario lavorativo e può richiedere un rapporto contrattuale per essere interrogata. Sono le preoccupazioni di un confine tra client e server, non di una routine di checksum.

Il messaggio di errore onesto descrive quindi la stringa. Può dire che il formato corrispondeva e le cifre di controllo reggevano, oppure che la lunghezza non si adatta al codice paese indicato. Non deve dire che il conto esiste, e non deve implicare che un controllo fallito significhi che il conto è chiuso o fraudolento.

Per gli sviluppatori: instradare per paese e lunghezza

L’implementazione è per lo più tenuta di registri, ed è nella tenuta di registri che vivono i bug.

1. Normalizza prima l’input: elimina spazi e trattini e riduci le lettere a un’unica combinazione di maiuscole e minuscole.
2. Leggi il codice paese e cercalo. Se è sconosciuto, segnala uno schema sconosciuto anziché un controllo fallito.
3. Confronta la lunghezza totale con la lunghezza definita dal paese, e fermati lì se non corrisponde — l’aritmetica non è significativa su una stringa della dimensione sbagliata.
4. Esegui la trasformazione mod-97 e confronta il resto, usando una routine cifra per cifra o per numeri grandi.
5. Verifica ogni cifra di controllo nazionale dentro la parte di conto con la sua regola.

Mantieni la tabella dei paesi come dati, poiché lunghezze e disposizioni cambiano, e tieni separati i due giudizi nel valore di ritorno: un paese non supportato non è un conto non valido. Dove un utente incolla un valore proveniente da una fonte non attendibile, ricorda che la normalizzazione elimina la presentazione e nulla di più; non è un passo di riparazione.

Passi successivi

Prendi un paese che il tuo prodotto supporta, annota cosa contiene la sua disposizione nazionale e rileggi la stringa con questo in mente. Poi verifica un valore da un capo all’altro nello strumento di validazione dei numeri, e leggi Numeri senza cifre di controllo per il caso opposto, in cui un formato è il massimo che un validatore possa mai confermare.