Serve una licenza bancaria per lanciare un'app fintech?

«Serve una licenza bancaria per lanciare un'app fintech?» sono in realtà tre domande con un solo cappotto. Detenete fondi dei clienti? Li movimentate? E quale autorizzazione regolamentare copre quel movimento: la vostra o quella di qualcun altro? Rispondete a queste e la questione della licenza si risolve quasi da sola. La versione breve, che sorprende la maggior parte dei team: la maggioranza delle app fintech non ha mai una licenza bancaria, perché la maggioranza delle app fintech non fa mai l'unica cosa per cui una licenza bancaria esiste. Quella che segue è una mappa dello spettro, non una consulenza legale: l'obiettivo è sapere quali domande fare prima che qualcuno vi indichi tempi o prezzi.

A che cosa serve davvero una licenza bancaria

Una licenza bancaria completa (in termini UE, l'autorizzazione come ente creditizio) consente un'attività specifica e fortemente presidiata: raccogliere depositi dal pubblico e reimpiegare quel denaro in prestiti. Quello squilibrio di scadenze, finanziare prestiti a lungo termine con saldi che i clienti possono ritirare a vista, è il motivo per cui le banche hanno requisiti patrimoniali pesanti, obblighi di garanzia dei depositi e un supervisore che legge il loro bilancio voce per voce. Se la vostra app non raccoglie depositi e non concede prestiti a fronte di essi, quasi certamente non state guardando a una licenza bancaria. State guardando a qualcosa di più leggero, più in basso nello spettro, e lo spettro è tutta la storia.

Lo spettro delle autorizzazioni, dalla più pesante alla più leggera

Le autorizzazioni finanziarie si articolano in livelli. In cima c'è l'istituto di credito, cioè la banca, che può raccogliere depositi e concedere prestiti. Subito sotto, un istituto di moneta elettronica (IMEL) può emettere moneta elettronica: può custodire il valore dei clienti e metterlo su carte o in wallet, ma i fondi che detiene vanno salvaguardati, cioè tenuti separati e intoccabili, mai prestati. Più in basso, un istituto di pagamento (IP) può eseguire pagamenti — disporre bonifici, incassare, rimettere fondi, fare acquiring di transazioni con carta — ma non è pensato per custodire valore nel tempo: il denaro transita, non staziona. In fondo, un agente o distributore non ha alcuna licenza propria e opera sotto l'autorizzazione di un soggetto autorizzato che lo ha registrato.

Il meccanismo è questo: a ogni gradino in meno si perde una funzione e, con essa, una parte di capitale e di obblighi. Detenere depositi è la cosa più impegnativa che si possa essere autorizzati a fare; essere agente di chi può farlo è la più leggera. La maggior parte delle app fintech per i consumatori — wallet, carte, trasferimenti, link di pagamento — si colloca nella fascia degli IMEL e degli istituti di pagamento, oppure poggia su un partner che detiene una di queste autorizzazioni. Pochissime hanno bisogno di essere una banca, e capirlo presto fa risparmiare un sacco di energie sprecate.

Un modo rapido per collocarsi: se i tuoi clienti manterranno un saldo nell'app — un wallet che ricaricano, una carta che precaricano — sei nel territorio della moneta elettronica, perché la custodia di valore è l'autorizzazione che definisce un IMEL. Se il denaro si limita a transitare — disponi un bonifico, incassi una bolletta, giri subito un pagamento in uscita — l'autorizzazione da istituto di pagamento è la soluzione naturale, detenuta da te o da un partner. Se non tocchi mai i fondi e ti limiti a mostrare informazioni su conti detenuti altrove, anche questo ha una sua registrazione, più leggera. Più in alto ti collochi, più capitale e vigilanza ti vengono addossati: l'obiettivo di progetto è non collocarti più in alto di quanto il prodotto richieda davvero.

Affittare l'autorizzazione: i modelli con partner

Non serve detenere in prima persona l'autorizzazione per costruirci sopra. La strada più comune è affittarla. Con un accordo di sponsor bank o di Banking-as-a-Service, una banca o un IMEL autorizzato tiene i conti, emette gli IBAN e le carte e salvaguarda i fondi; tu sviluppi l'app sulla loro API e porti sul mercato l'esperienza. Con un modello ad agenti ti registri come agente di un istituto di pagamento — o come distributore di un emittente di moneta elettronica — e la loro licenza copre la tua attività, con il regolatore che ti conosce tramite loro. Contratti diversi, stesso fatto di fondo: da qualche parte nello stack, qualcuno detiene l'autorizzazione. L'unica domanda è se quel qualcuno sei tu o un partner.

Chi si assume quali responsabilità

Affittare una licenza non significa scaricare la responsabilità. Il soggetto autorizzato è quello che risponde al regolatore: della salvaguardia dei fondi dei clienti, del monitoraggio antiriciclaggio, della condotta dell'intero programma. Ma quegli obblighi scendono a valle per contratto. Se ti appoggi alla licenza di un partner, continuerai a occuparti di KYC e onboarding, a monitorare le transazioni per l'AML, a rispettare i limiti e la reportistica a cui il partner è vincolato. La responsabilità non viene tanto esternalizzata quanto ripartita: il partner ne risponde al regolatore e ti chiede conto tramite un contratto che riporta sulle tue spalle gran parte degli obblighi quotidiani. Leggi quel contratto con la stessa attenzione con cui leggeresti la licenza che hai scelto di non ottenere.

Una licenza è l'autorizzazione a detenere o muovere il denaro altrui. Il software è il modo in cui quel denaro viene disposto, riconciliato e restituito al cliente in forma leggibile. Puoi acquistarli da un unico fornitore o da due, ma stai sempre acquistando entrambi.

Software e licenza sono due acquisti distinti

È la consapevolezza che riordina l'intero progetto. Per il cliente un'app di pagamento sembra una cosa sola, ma ne sono fuse due: l'autorizzazione regolamentata a detenere o muovere denaro, e il software che dispone il movimento, tiene il ledger, riconcilia gli accrediti e mostra un saldo su uno schermo. Le due cose si reperiscono separatamente. Puoi avere una licenza tua e acquistare il software; avere una licenza e sviluppare il software internamente; affittare l'autorizzazione tramite un partner e acquistare il software sopra; oppure prendere entrambi da un unico fornitore che li ha impacchettati. Sono tutti scenari normali. Ciò che non è normale — e che fa perdere ai progetti mesi senza che ce ne si accorga — è confondere le due cose: cercare una “licenza bancaria” quando serviva un partner BaaS più un'app, oppure cercare un'app dando per scontato che l'autorizzazione ci sia già incorporata.

Vederli come acquisti separati fa chiarezza perché permette di valutarli e pianificarli in modo indipendente. Il software si giudica nel merito — il flusso di onboarding funziona, il ledger è corretto, gli operatori riescono davvero a gestire il sistema — mentre l'autorizzazione si giudica per giurisdizione, salvaguardia e condizioni. Protocore Pay (/products/pay) è un esempio di solo livello software: una piattaforma di app whitelabel con console per gli operatori, che gira su qualunque infrastruttura regolamentata tu le porti. Non è una licenza, e nessun software lo è — ed è proprio per questo che la licenza resta una voce separata nel piano.

Le domande da fare a qualsiasi fornitore di piattaforme

Chiunque ti proponga una piattaforma “lancia la tua fintech”, la stessa breve lista di domande taglia via gran parte dell'ambiguità. Il vostro prodotto include un'autorizzazione regolamentata, o la porto io? Se la include, di chi è la licenza, in quali paesi, e sono cliente diretto di quel soggetto o di un suo agente? Chi salvaguarda i fondi dei clienti, e dove sono custoditi? Chi è indicato al regolatore per l'antiriciclaggio: voi, il partner o io? Quali obblighi ricadono su di me per contratto anche se la licenza non è mia? E se la partnership finisce, che ne è del denaro dei miei clienti e dei loro dati? Le risposte dividono in fretta i fornitori tra chi vende software, chi rivende l'autorizzazione di un partner e chi ha davvero impacchettato entrambi — e ti dicono con quale dei tre stai parlando.

Il lato rassicurante di tutto questo: la maggior parte delle app parte come software più autorizzazione di un partner e passa a una licenza propria solo quando volumi, margini o strategia rendono sensati capitale e personale di compliance. Sapere quale gradino serve davvero — e che software e autorizzazione si acquistano su voci separate — è già gran parte del lavoro. Il resto è porre le domande qui sopra e leggere con attenzione le risposte. Nulla di tutto ciò costituisce consulenza legale, e soglie e nomi delle categorie variano da una giurisdizione all'altra: consideralo la mappa da portare al confronto con un regolatore o un consulente, non un sostituto.