Studio di sviluppo fintech: cosa verificare su KYC, PSD3 e DORA

Uno studio di sviluppo fintech è un team di prodotto che progetta e realizza software finanziario regolamentato portando i vincoli di conformità (verifica dell'identità, autorizzazioni sui pagamenti, resilienza operativa, accessibilità) dentro l'interfaccia e dentro il codice, invece di aggiungerli in una revisione poco prima del rilascio. La distinzione conta nel 2026 perché le regole europee su cui viaggia un prodotto fintech si stanno riscrivendo su cinque calendari diversi, e tre arrivano dopo il rilascio di un prodotto avviato quest'anno.

Questo è un promemoria per chi compra. Racconta cosa è cambiato fra il 2025 e il 2028, le quattro domande da fare prima di firmare, e dove passa il confine fra chi sviluppa il prodotto, l'istituto autorizzato e i legali che servono comunque.

Cosa fa uno studio fintech che uno studio generalista non fa

Una dashboard, una registrazione e un pagamento con carta li sviluppa qualsiasi studio serio. Un prodotto finanziario regolamentato aggiunge tre obblighi che cambiano la forma del software: l'identità dell'utente va verificata e riverificata, il movimento di denaro deve appoggiarsi alla licenza di qualcuno, e l'intero sistema deve reggere un'autorità che chiede prove documentate, non schermate.

Quegli obblighi spostano decisioni ordinarie. La registrazione smette di essere un modulo con tre campi e diventa una macchina a stati con dietro una coda di revisione manuale. Il database smette di essere un unico schema e si porta dietro un libro mastro in sola aggiunta, dove nessuno aggiorna una riga esistente. Il canale degli incidenti smette di essere un thread su Slack e diventa un obbligo di segnalazione con un cronometro sopra. Chi non ha mai lavorato con questi vincoli preventiva bene la dashboard e incontra il resto al terzo mese.

Cosa è cambiato in Europa fra il 2025 e il 2028

Il quadro lo fissano cinque date. Due sono già passate, e due delle tre che restano arrivano quando i prodotti avviati nel 2026 saranno già online: per questo entrano oggi nella discussione sull'architettura.

• Il DORA si applica dal 17 gennaio 2025. Gli intermediari finanziari devono governare il rischio dei fornitori ICT, tenere un registro delle informazioni su ogni accordo, classificare e segnalare gli incidenti, avere piani di uscita per i fornitori da cui dipendono. A novembre 2025 le autorità di vigilanza europee hanno pubblicato il primo elenco dei fornitori ICT designati come critici, e il regime è passato dalle linee guida alla vigilanza vera (EIOPA, DORA).
• L'European Accessibility Act si applica dal 28 giugno 2025. Rientrano i servizi bancari al consumatore, i terminali di pagamento e il commercio elettronico finanziario: quindi l'app, il sito, gli estratti conto, l'assistenza e la procedura di disdetta (Bird & Bird). La strada pratica alla conformità è la norma EN 301 549 v3.2.1, che recepisce per intero le WCAG 2.1 livello AA e aggiunge requisiti su hardware, documentazione e software non web (ETSI EN 301 549 v3.2.1).
• Le regole europee antiriciclaggio si applicano dal 10 luglio 2027. Un solo regolamento sostituisce i recepimenti nazionali divergenti che oggi si mappano paese per paese. L'Autorità antiriciclaggio europea opera da Francoforte dal 1º luglio 2025 e dal gennaio 2028 vigila direttamente su un massimo di 40 gruppi transfrontalieri, scelti nel corso del 2027 (AMLA).
• La PSD3 e il regolamento sui servizi di pagamento hanno chiuso il negoziato. Parlamento e Consiglio hanno raggiunto l'accordo provvisorio a novembre 2025 e il Coreper ha avallato i testi ad aprile 2026. La pubblicazione in Gazzetta ufficiale è attesa nella seconda metà del 2026 e le regole di sostanza dovrebbero applicarsi verso il 2028, quando scade la finestra di recepimento della direttiva (Norton Rose Fulbright).
• I portafogli di identità digitale europei vanno offerti dagli Stati entro il 24 dicembre 2026. Banche, istituti di pagamento e istituti di moneta elettronica dovranno accettarli come strumento di identificazione e di autenticazione forte circa un anno dopo. Ad agosto 2026 diversi portafogli nazionali risultavano in ritardo, con la Germania che ha indicato il 2 gennaio 2027 per il proprio (Forbes).

Come si verifica che uno studio abbia davvero esperienza fintech

Quattro domande distinguono chi ha rilasciato un prodotto regolamentato da chi ne ha letto. Falle a voce, non dentro una richiesta d'offerta, e ascolta quanto sono concrete le risposte.

1. Su quale licenza gira il prodotto

Le forme sono due. Nel modello dell'agente distribuisci le autorizzazioni di un istituto già abilitato: la responsabilità dell'attività regolamentata resta al soggetto principale e tu non puoi offrire nulla fuori dal suo perimetro, ed è il motivo per cui questa strada va online in poche settimane. Nel modello diretto sei tu a ottenere la licenza di istituto di pagamento o di moneta elettronica, e il calendario cambia del tutto. Le guide sulle licenze indicano istruttorie di circa tre-sei mesi in Lituania e di dodici-diciotto mesi presso l'autorità britannica, prima ancora che lo sviluppo cominci (Crassula, guida alla licenza EMI).

Uno studio che non sa dirti in quale delle due forme sta il tuo prodotto, e cosa comporta ciascuna sul flusso di registrazione, non ne ha mai realizzato uno. I due modelli producono onboarding diversi, tempi di conservazione dei dati diversi, riconciliazioni diverse e stati di errore diversi.

2. Se il KYC è una schermata o un sistema di decisione

Le demo dei fornitori mostrano sempre il percorso pulito: richiedente in regola, foto del documento nitida, spunta verde in undici secondi. L'ingegneria sta negli altri stati. Un profilo con pochissima storia verificabile. Un documento che si legge male da un telefono vecchio con poca luce. Un nome che finisce in una lista sanzioni o di persone politicamente esposte e richiede una decisione umana. Un rifiuto da comunicare senza spiegarne nel dettaglio il motivo.

Chiedi allo studio di accompagnarti in questi quattro stati e nel giro di revisione dell'analista, non nell'integrazione dell'SDK. In un prodotto regolamentato la conversione dell'onboarding si decide quasi tutta negli stati brutti, quelli che nessuno mette nel prototipo.

3. Che aspetto ha la tracciabilità

Il DORA ha reso la gestione dei fornitori e degli incidenti un obbligo documentato, con artefatti dal nome preciso: registro delle informazioni, diritti contrattuali di audit e di uscita, classificazione degli incidenti rispetto alle finestre di segnalazione. Tradotto in prodotto: ogni cambio di stato ha bisogno di un evento durevole con attore, orario e motivo, e il database applicativo non è il libro di verità del denaro.

Aggiungere un registro di eventi a un'applicazione CRUD dopo il rilascio è una riscrittura, non uno sprint. Chiedi di vedere come lo studio ha modellato eventi e libro mastro su un progetto già consegnato. Se la risposta è updated_at, hai già capito.

4. Dove sta l'accessibilità

Da giugno 2025 le regole sull'accessibilità coprono tutta la parte dei servizi bancari rivolta al consumatore, e i pezzi che i team dimenticano sono gli estratti conto, il terminale, l'assistenza e la disdetta. Chiedi quale strada di conformità segue lo studio, chi esegue i test, e se contrasto, ordine di focus e dimensione dei bersagli si decidono una volta nel design system oppure si ridecidono a ogni schermata. Ne abbiamo scritto in design accessibile dopo l'EU Accessibility Act.

Cosa uno studio fintech non deve venderti

Uno studio non è uno studio legale, non è una società di consulenza sulla conformità e non è una licenza. Chi propone il via libera normativo insieme allo sviluppo sta vendendo qualcosa che non gli appartiene, e le conseguenze restano a chi compra.

La divisione che regge è questa: l'interpretazione delle regole spetta ai tuoi legali e al responsabile della conformità, le autorizzazioni all'istituto abilitato, il prodotto che deve soddisfare entrambi (e le prove che lo dimostrano) allo studio. L'interpretazione va chiesta per iscritto a chi è qualificato a darla, poi consegnata a chi sviluppa sotto forma di vincoli con criteri di accettazione. È anche il modo più economico per tenere onesto il perimetro, come raccontato in come scrivere il brief per un'agenzia di sviluppo software.

I pezzi dello stack 2026 che reggono i vincoli

Le scelte tecniche di un progetto regolamentato non hanno niente di esotico. Cambia quali decisioni portano peso.

• Identità attraverso un fornitore in cloud, dietro un'interfaccia tua. Il fornitore cambia almeno una volta, per copertura geografica, per prezzo o per un requisito sulla residenza dei dati. La logica di decisione e gli stati del richiedente stanno nel tuo codice, non nel pannello del fornitore.
• Un libro mastro separato dallo schema applicativo. In sola aggiunta, in partita doppia, riconciliato a scadenza fissa con gli estratti dell'istituto. I saldi si calcolano, non si salvano in una colonna modificabile.
• Autorizzazione a livello di riga sul database, non solo nell'API. La row-level security di Postgres tiene il confine fra tenant e ruoli anche quando un endpoint è scritto male, e resta veloce se le policy sono scritte pensando al planner (sette pattern che usiamo).
• La giurisdizione come configurazione. Requisiti di verifica, tempi di conservazione e testi informativi cambiano da paese a paese. Quando diventano rami nel codice, il secondo mercato costa quanto il primo.
• Un design system che possiede i valori accessibili di partenza. Contrasto, focus, testi di errore e dimensione dei bersagli si decidono una volta, poi ogni schermata li eredita.

Quando basta uno studio generalista

Non tutti i prodotti del settore hanno bisogno di tutto questo. Un prototipo pre-licenza per un giro di raccolta, uno strumento B2B di analisi che legge i dati bancari tramite un fornitore e non tocca mai il denaro, una console interna per un istituto che i controlli ce li ha già: sono progetti software normali, e pagarci sopra il sovrapprezzo del regolamentato è spreco.

I vincoli iniziano a mordere quando si muove denaro di consumatori, quando l'identità va provata e conservata, e quando un'autorità può chiedere le prove a posteriori. Se due di queste tre condizioni valgono, scegli lo studio sul vincolo. Se non ne vale nessuna, scegli sul prodotto.