I test KYB sono il lavoro di assicurarsi che un flusso di verifica aziendale si comporti correttamente prima di incontrare un richiedente reale. KYB sta per Know Your Business, e il nome indica la differenza che conta: il soggetto da verificare è un’organizzazione, non una persona, e un’organizzazione ha livelli — proprietari, controllanti, registrazioni, documenti — che un controllo di identità personale non deve mai affrontare.
Questo articolo stabilisce cosa verifica realmente un flusso KYB, perché la verifica aziendale è più difficile di quella personale, come dovrebbero comportarsi il rifiuto e la revisione e come testare l’intero processo senza indebolire i controlli che state testando.
Cosa verifica realmente un flusso KYB?
Verifica che l’organizzazione sia reale, che sia ciò che dichiara di essere e che le persone che ne stanno dietro siano chi dicono di essere. Un controllo di identità personale risponde a “questa persona è chi dichiara”; un controllo aziendale pone la stessa domanda su un’entità e poi aggiunge una seconda domanda sugli esseri umani che la controllano.
Un flusso tipico raccoglie quindi diversi tipi di prove, e i requisiti specifici dipendono dalla giurisdizione e dal regolatore a cui risponde l’impresa che effettua l’onboarding. In termini generali:
- Esistenza — prova che l’entità è registrata, tratta dal registro del suo paese di costituzione.
- Identificazione — il numero di registrazione e qualsiasi identificativo fiscale o di partita IVA che l’entità possiede.
- Ubicazione — prova dell’indirizzo registrato e, talvolta, anche di un indirizzo operativo.
- Proprietà e controllo — gli individui che in ultima istanza possiedono o controllano l’entità.
- Attività — cosa fa realmente l’impresa e qualsiasi licenza o permesso richiesto da quell’attività.
- Rappresentanza — conferma che la persona che invia sia autorizzata ad agire per l’entità.
Nessuno di questi è una formalità e nessuno può essere dedotto da un altro. Una società registrata può avere una proprietà opaca, una licenza può essere posseduta ma scaduta, e la persona che compila il modulo spesso non è un amministratore.
Perché verificare un’impresa è più difficile che verificare una persona?
Tre ragioni strutturali, tutte quante si manifestano come difetti nei test.
La prima è la stratificazione. Una persona è un unico soggetto con un’unica identità. Un’impresa può essere posseduta da un’altra società, posseduta da un trust, amministrato in un terzo paese. Il flusso deve seguire quella catena abbastanza a fondo da identificare gli esseri umani alla sua estremità, e “abbastanza a fondo” è un giudizio, non un numero fisso di passaggi.
La seconda è che le prove sono distribuite. I documenti di identità personale provengono da un’unica autorità in un unico paese. Le prove aziendali provengono da un registro qui, da un’autorità fiscale là e da una banca altrove, in più lingue, con periodi di validità diversi e diversi gradi di accessibilità pubblica.
La terza è che la verifica non è un evento unico. La proprietà cambia, gli indirizzi cambiano, le licenze scadono, le entità vengono rinominate o ristrutturate. Un’impresa che ha superato la verifica in un anno può presentare un quadro sostanzialmente diverso l’anno successivo.
Cosa deve inviare il richiedente?
Dipende dalla giurisdizione e dal profilo di rischio che applica l’istituzione verificante, ma un insieme rappresentativo di requisiti appare così.
| Requisito | Cosa stabilisce | Note per chi testa |
|---|---|---|
| Certificato di costituzione o equivalente | L’entità esiste e il suo nome e numero sono come dichiarati | Spesso abbinato a un estratto recente del registro |
| Prova di registrazione fiscale o IVA | L’identità fiscale dell’entità | Può non esistere per ogni impresa legittima |
| Prova dell’indirizzo registrato | Dove l’entità è ufficialmente situata | Una bolletta o un estratto del registro, a seconda del paese |
| Informazioni su proprietà o controllo | Chi in ultima istanza possiede o controlla l’entità | La parte più difficile da modellare e da testare |
| Documenti d’identità dei controllanti | Che gli individui siano reali | Attiva un controllo personale separato |
| Licenza o permesso | Che un’attività regolamentata sia autorizzata | Assente per la maggior parte delle imprese non regolamentate |
L’osservazione ingegneristica cruciale è nell’ultima colonna delle righe centrali: diversi di questi elementi sono facoltativi in un modo che è legittimo e non incompleto. Un’impresa senza registrazione IVA non è un richiedente difettoso, e un flusso che tratta l’assenza come fallimento respingerà una larga fetta del mercato reale.
Come dovrebbero comportarsi il rifiuto e la revisione?
Come stati ordinari e attesi, non come errori terminali. Un flusso di verifica che può concludersi solo con un’approvazione o con un vicolo cieco è un flusso che verrà aggirato da chi lo gestisce, e aggirare un controllo è come si perde il controllo.
Progettate gli esiti separatamente. Un rifiuto su basi documentate — per esempio un documento che non corrisponde al registro — è riesaminabile e appellabile. Una richiesta di ulteriori informazioni è uno stato ripristinabile che conserva tutto ciò che è già stato inviato. Una coda di revisione manuale è un esito legittimo, non un fallimento dell’automazione. E ogni rifiuto dovrebbe portare una motivazione abbastanza specifica da essere azionabile, perché “verifica non riuscita” non dà al richiedente nulla da correggere né al team di assistenza nulla da spiegare.
Due proprietà trasformano questi stati da teoria in un flusso praticabile. Le motivazioni di rifiuto dovrebbero essere un vocabolario controllato, così da poter essere contate, instradate e gestite in modo coerente. E una domanda rifiutata dovrebbe essere ripristinabile: il richiedente corregge un documento, non l’intero invio.
Ciò che non deve accadere è una scorciatoia di test che disattiva i controlli. Disattivare i controlli su sanzioni, proprietà o documenti per far passare un test produce un sistema i cui guasti sono invisibili finché non diventano costosi.
Per gli sviluppatori: stati, prove e conservazione
Modellate il flusso come una macchina a stati esplicita — non avviato, inviato, in revisione, in attesa di informazioni, approvato, rifiutato — con transizioni registrate, timestamp e l’attore responsabile di ciascuna. Un campo di stato che è una stringa di testo libero deriverà entro un mese, e la deriva è invisibile finché qualcuno non prova a farne un rapporto.
Le prove hanno bisogno di un modello proprio. Ogni documento inviato dovrebbe portare un tipo, un emittente o paese, la data di rilascio e una scadenza dove applicabile, perché una licenza scaduta non è una prova anche se il file è ancora lì. Separate i metadati del documento dal file stesso, così che le regole di conservazione possano agire sui metadati senza toccare il contenuto.
La titolarità effettiva è la parte che i team sottovalutano. Modellatela come un grafo — entità e individui come nodi, proprietà e controllo come archi — anche se l’interfaccia mostra sempre e solo due livelli. Appiattirla in qualche campo del nome rende i dati inutilizzabili la prima volta che una struttura proprietaria deve essere ricontrollata.
La conservazione e l’isolamento sono gli altri punti non negoziabili. Le prove di verifica sono tra il materiale più sensibile che un’impresa detiene, quindi tenete gli ambienti di test liberi da documenti e richiedenti reali e tenete del tutto i dati di produzione fuori dai database di test. Le entità sintetiche prodotte dal generatore di dati aziendali sono l’input giusto per provare questo flusso: non descrivono alcuna attività reale, e l’articolo sui confini dei dati aziendali sintetici spiega perché ciò conta quando uno screenshot o un’esportazione sfugge al proprio ambiente. La più ampia macchina dei record aziendali sintetici è trattata in dati aziendali di test.
Passi successivi
Scrivete ogni stato in cui può trovarsi il vostro flusso di verifica, poi controllate se ciascuno è raggiungibile in un ambiente di test e se ciascuno porta un messaggio azionabile per il richiedente. Qualsiasi stato che non può essere raggiunto nei test è uno stato che verrà raggiunto per la prima volta in produzione. Poi provate il flusso dall’inizio alla fine con una società generata dal generatore di dati aziendali e confermate che nessun passaggio richieda di disattivare un controllo per procedere.