Un generatore di numeri di documento d’identità nazionale produce identificatori che corrispondono al formato che ciascun paese emette davvero, compresi la lunghezza, l’insieme di caratteri, la posizione della cifra di controllo e le regole interne che rendono un numero valido e un altro non valido. La differenza tra uno strumento utile e una stringa di cifre casuali sta in quelle regole, perché ogni percorso di validazione serio le controlla.
Questa guida esamina come i numeri di identificazione differiscono tra i paesi, perché un segnaposto come 123456789 fallisce ogni controllo e quindi non testa nulla, perché la lunghezza deve essere configurata per paese anziché presunta, e qual è il confine onesto di un record sintetico in un flusso KYC. Alla fine dovreste sapere quali proprietà servono a un’identità di test per esercitare una vera pipeline di onboarding.
Perché i numeri di identificazione non sono un unico formato con lunghezze diverse?
L’assunto diffuso che ogni paese emetta un identificatore che è essenzialmente un lungo numero con un checksum è sbagliato in modi che rompono sistemi reali. I paesi differiscono sul fatto che l’identificatore sia numericamente composto o meno, sul fatto che venga emesso alla nascita o alla registrazione, sul fatto che codifichi una data e sul fatto che compaia su una carta o solo in un registro.
Il numero di previdenza sociale degli Stati Uniti è di nove cifre in tre gruppi, e il formato è l’unica cosa che il numero visibile porta con sé. L’articolo sul formato del numero di previdenza sociale spiega quali intervalli non vengono mai emessi e perché un validatore che accetta ogni stringa di nove cifre sta accettando numeri che non possono esistere.
La Cina emette un numero di identità di residente di diciotto caratteri che inizia con un codice di indirizzo, prosegue con una data di nascita e termina con un carattere di controllo che può essere la lettera X. Il Brasile emette il CPF come undici cifre di cui le ultime due sono cifre di controllo calcolate dalle nove precedenti, e spesso scritto con una punteggiatura che un parser deve gestire. La Turchia emette il T.C. Kimlik No come undici cifre la cui prima cifra non è mai zero e le cui ultime due cifre derivano dalle altre.
La Spagna emette il DNI come otto cifre più una lettera di controllo calcolata da un modulo, e il NIE per i residenti stranieri segue lo stesso schema con una lettera iniziale diversa. L’Indonesia emette un NIK di sedici cifre che incorpora un codice di distretto e una data. Il Vietnam emette un numero di identità di cittadino di dodici cifre. La Russia emette l’INN come dieci o dodici cifre a seconda dell’entità, e il SNILS come undici cifre in un formato numerato. L’articolo sulla lunghezza del documento d’identità nazionale per paese raccoglie le lunghezze in un unico posto.
Perché la cifra di controllo è tutto?
Una cifra di controllo trasforma una stringa di cifre in un valore che può essere testato per coerenza interna. Senza di essa, ogni numero della lunghezza giusta è ugualmente valido, e un campo che si limita a contare i caratteri accetterà un refuso, un incolla troncato e un numero inventato con lo stesso entusiasmo.
Con essa, un validatore può rifiutare la stragrande maggioranza dei valori digitati male prima che qualcosa a valle li veda. È tutto qui il beneficio, ed è per questo che un generatore che non calcola le cifre di controllo produce dati che non possono esercitare il percorso di validazione che dovrebbe testare.
Le conseguenze di saltarle sono facili da vedere. Una fixture riempita di valori segnaposto supererà un controllo di lunghezza e fallirà ogni checksum, quindi il test esercita solo il ramo di rifiuto. I bug nel ramo di accettazione — il ramo che gira in produzione — restano non visitati, e la suite riporta successo mentre non copre nulla.
È per questo che l’aritmetica conta più dell’apparenza. La guida alle cifre di controllo dei documenti d’identità nazionali illustra i metodi a modulo usati in diversi paesi, e la panoramica degli algoritmi delle cifre di controllo li colloca nella più ampia famiglia di controlli che include i numeri di conto bancario e i codici a barre. Quando scegliete un generatore, la domanda da porre è quali algoritmi nazionali implementa e se l’output supera un validatore indipendente.
Perché la lunghezza deve essere configurata per paese
Nulla di un campo di identificazione dovrebbe essere codificato rigidamente. Uno schema che memorizza ogni identificatore in una colonna a larghezza fissa troncherà quelli più lunghi e lascerà spazio vuoto per quelli più corti, e un validatore che presuppone una sola lunghezza rifiuterà ogni paese per cui non è stato scritto.
Il progetto pratico è un campo paese che seleziona un insieme di regole, e un insieme di regole che porta la lunghezza, i caratteri ammessi, l’algoritmo di controllo e il modo in cui il valore viene presentato per la visualizzazione. Il valore memorizzato e il valore visualizzato di solito sono diversi, perché molti paesi stampano una punteggiatura che non fa parte dell’identificatore stesso.
La configurazione deve anche gestire i paesi che non emettono alcun identificatore di questo tipo. In quei casi il campo dovrebbe essere legittimamente assente anziché riempito con una stringa dall’aspetto plausibile. Un valore assente e un valore sbagliato falliscono diversamente a valle, e uno schema che non riesce a esprimere l’assenza finirà per memorizzare un identificatore fabbricato in un record che non ne aveva mai avuto uno.
Dove in un singolo paese esistono più identificatori, il modello deve distinguerli. Un numero fiscale, un numero di previdenza sociale e un numero di identità nazionale possono essere tutti di undici cifre nella stessa giurisdizione, e trattarli come un unico campo garantisce che un test finirà per verificare quello sbagliato. Dare a ciascun identificatore un nome basato su cosa è anziché sulla sua posizione nel modulo è il modo più economico per tenerli separati, e rende un’esportazione da un paese leggibile in un altro.
Come si comporta un identificatore sintetico in un flusso KYC
Un flusso KYC di solito fa diverse cose con un identificatore. Controlla il formato, calcola la cifra di controllo, invia il valore a un servizio di verifica esterno, memorizza il risultato e talvolta conserva un’immagine di un documento. Un numero generato soddisferà i primi due e fallirà il terzo, e questo è il comportamento corretto per dati sintetici.
Il fallimento al terzo passaggio è ciò che rende il record sicuro. Poiché nessuna autorità emittente conosce l’esistenza del numero, nessun servizio di verifica può confermarlo e nessun account può essere aperto su di esso. Se un numero generato soddisfacesse mai una verifica esterna, significherebbe che il numero apparteneva a qualcuno, il che sarebbe un difetto grave del generatore anziché una funzionalità.
Questo significa che il test KYC con identificatori sintetici avviene su due livelli. Il livello locale testa la vostra validazione, formattazione, gestione degli errori e memorizzazione, e i valori sintetici sono ideali per esso. Il livello di integrazione richiede una sandbox fornita dal fornitore di verifica, e quelle sandbox di solito arrivano con le proprie identità di test fisse. Mescolare i due — inseguire un numero sintetico attraverso un endpoint di verifica live — non produce altro che rumore.
I team dovrebbero anche essere attenti a cosa verificano nel passaggio esterno. Un test che si aspetta uno specifico codice di rifiuto da un fornitore reale sta testando il comportamento attuale del fornitore, che cambia senza preavviso. Un test che si aspetta che la vostra applicazione gestisca un rifiuto con garbo sta testando il vostro software, che è la cosa che possedete. Lo stesso ragionamento vale per la tempistica del controllo: se il vostro flusso verifica in modo asincrono, i casi interessanti sono una risposta lenta, un timeout e una risposta che arriva due volte, e quelli sono più economici da produrre con uno stub che controllate che con una sandbox di un fornitore che risponde in modo fisso.
Quali sono i confini di conformità per i test di identità
Il primo confine è che un record sintetico non è una persona. Può avere un nome, una data di nascita, un indirizzo e un identificatore, e nessuno di questi appartiene a nessuno. Presentarlo come l’identità di qualcuno, o usarlo per impersonare un individuo reale, è un abuso indipendentemente da come il record è stato prodotto.
Il secondo confine riguarda i dati reali. Un record che combina un nome reale con un identificatore reale è un’identità reale per qualsiasi definizione pratica, e copiare tali record in un ambiente di test è una comunicazione illecita. L’articolo dati di identità di test spiega perché copiare righe di produzione in un ambiente inferiore è sia un problema normativo sia operativo, e l’articolo GDPR e dati di identità di test copre l’inquadramento giuridico.
Il terzo confine è lo scopo. Un identificatore generato esiste per esercitare un flusso che gestite voi, e non deve essere usato per aprire un conto reale, per superare una fase di verifica, per rivendicare un beneficio, per ottenere un documento o per superare un controllo che esiste per proteggere qualcuno. Questo vale sia che il flusso appartenga a voi sia a una terza parte.
Il quarto confine è la conservazione. Anche i record sintetici si accumulano, e un database di un milione di identità generate non è pericoloso di per sé ma a colpo d’occhio è indistinguibile da uno che lo è. Marcare le righe generate, conservare i parametri di generazione ed eliminare le fixture non più usate mantiene visibile la distinzione.
Un quinto confine è la presentazione onesta. Se un record sintetico deve mai lasciare l’ambiente di test — in una demo, uno screenshot o un corso di formazione — dovrebbe essere etichettato come generato ovunque un lettore potrebbe scambiarlo per i dati di una persona reale. L’etichetta non costa nulla e rimuove un’ambiguità che un lettore non ha modo di risolvere da solo.
Cosa dovrebbe contenere un record di identità di test
Un record utile porta un insieme coerente di campi anziché un solo identificatore. Nomi e un cognome appropriati al paese, una data di nascita coerente con qualsiasi intervallo di età valido, un indirizzo all’interno della stessa giurisdizione, un numero di telefono che porta il prefisso di chiamata del paese e gli identificatori che quel paese emette davvero. Ogni coppia in quell’insieme vincola l’altro membro, ed è la proprietà che rende il record utilizzabile.
Fornite sia un record fisso per le asserzioni sia uno generato per l’esplorazione. Il record fisso rende significativo un test di regressione, e il record generato trova casi che nessuno ha annotato. Il generatore di identità su questo sito è costruito in modo che la stessa chiave con lo stesso paese restituisca lo stesso record, il che permette a una fixture di restare stabile tra le esecuzioni mentre altri record esplorano lo spazio.
Poi validate l’output in modo indipendente. Prendete un identificatore generato, passatelo attraverso un validatore che avete scritto voi stessi dall’algoritmo pubblicato e confermate che la cifra di controllo passi. Quella singola abitudine intercetta un’intera classe di errori di configurazione in cui viene selezionato un paese ma vengono applicate le regole di un paese vicino. L’articolo sulla coerenza dei campi di identità descrive i controlli incrociati che vale la pena aggiungere accanto ad esso.
Ogni identificatore prodotto in questo modo è un dato di test sintetico. Il formato, la lunghezza e la cifra di controllo seguono le regole pubblicate affinché il software possa essere esercitato, ma il numero non appartiene a nessuna persona, non è mai stato emesso da alcuna autorità e non deve essere usato per impersonare qualcuno, per aprire o registrare un conto reale, per superare una verifica di identità reale o per ottenere alcun beneficio o documento.