Sono arrivato al fintech dalla parte delle operations, non da quella della norma.

Ho iniziato in Telecom Italia e poi in Atlanet, negli anni in cui la telefonia italiana passava dal monopolio alla concorrenza: l'autorità decideva le condizioni di accesso e l'azienda doveva costruirci sopra qualcosa che stesse in piedi commercialmente. La norma non era un vincolo esterno da subire, era il terreno di gioco. In Retevisión ho visto la stessa dinamica in un altro mercato europeo, dal lato di chi entra in un sistema già occupato. Poi la direzione marketing di H3G, dove al vincolo regolatorio si è aggiunto quello industriale: portare a mercato in un settore affollato, sotto vigilanza continua.

Sembra una successione di settori diversi. Non lo è: in tutti e tre i casi il lavoro era tradurre un impianto normativo in decisioni che un'azienda può eseguire davvero, e reggere il confronto con chi vigila su quelle decisioni. Nel fintech ho trovato la stessa struttura del problema — autorizzazioni, capitale e governance, aspettative supervisorie, dossier che devono restare coerenti nel tempo — con una normativa più giovane e in movimento più rapido.

È il motivo per cui il mio advisory si chiama operativo e non legale: non nasce dall'interpretare la norma in astratto, ma dal dover far funzionare un'azienda dentro quella norma, con le persone e i tempi che ha.

In Bizando lavoro con fintech, istituti di moneta elettronica, istituti di pagamento e crypto-asset service provider, in Italia e nell'Unione, su tre cluster ricorrenti: preparare un'autorizzazione iniziale, sostenere lo scaling di chi è già autorizzato, mantenere l'impianto allineato nel tempo.

Concretamente: strutturazione del dossier, redazione degli annexi tecnici e regolatori, gestione delle richieste di integrazione dell'autorità, disegno dei processi operativi e delle deleghe interne, preparazione alle ispezioni. Il cliente non parte da zero — entrano dal primo giorno i miei template per le sezioni ricorrenti, le checklist di gap analysis per istanze EMI, PI e CASP, le matrici comparative fra giurisdizioni UE e una libreria curata di precedenti regolatori europei.

Lavoro affiancando il team interno, non sopra di esso. Sui dossier complessi il pattern che funziona è uno split netto: l'avvocato firma l'opinion formale e gestisce l'interlocuzione con l'autorità, io costruisco l'impalcatura del dossier e la produzione documentale.

CAI sta per Collective Artificial Intelligence: una metodologia interna, sviluppata sul lavoro reale di anni di advisory regolatorio. La spiego per esteso perché in un settore che vende compliance, dire come si producono i documenti è parte del contratto morale con il cliente.

Il principio: il giudizio senior resta umano, la produzione viene amplificata. Sistemi AI specializzati fanno la ricerca normativa veloce, le prime stesure delle sezioni ricorrenti, la comparazione fra versioni e la sintesi di corpus estesi. Io faccio le scelte che hanno conseguenze — impostazione strategica, interpretazione non standard, wording rivolto all'autorità — e valido ogni sezione prima che esca.

Tre presidi su ogni deliverable. Un doppio pass di revisione mia, prima sul contenuto regolatorio e poi sulla leggibilità per il destinatario reale. Un red-team con sistemi CAI sul draft, per far emergere lacune logiche e contraddizioni interne: controllo additivo, non sostitutivo. Una tracciabilità versionata completa, che permette di ricostruire mesi dopo il perché di ogni scelta documentale.

Due cose che la CAI non sposta. Ogni claim normativo è ancorato a una fonte primaria identificabile — testo di legge, technical standard, opinion, Q&A pubblica — non a una sintesi generativa. E la responsabilità professionale del deliverable è mia: quando un documento arriva all'autorità con la mia firma sotto, significa che l'ho costruito, validato, e che ne rispondo io.