Per founder che costruiscono banche consumer, wallet, prestiti, pagamenti

Design e sviluppo per founder fintech

KYC integrato. Scope PCI ridotto al minimo. Un registro contabile che regge un audit. Un'app per il consumatore che si guadagna il posto sulla home screen di chi la apre ogni giorno.

I problemi che sentiamo più spesso

Onfido per il KYC, un account Stripe Connect, e un registro contabile interno di cui nessuno si fida davvero

Tre fornitori, e un team contabile che a fine mese riempie fogli di calcolo per far quadrare i numeri.

Un flusso 3DS2 che fa cadere il cliente proprio prima del click finale

Autenticazioni che rimbalzano, redirect del browser, sessioni perse al primo pagamento. Il cliente apre l'account di un concorrente.

Un responsabile compliance che ti chiede come dimostri che il cliente A non vede i dati del cliente B

L'ufficio acquisti del prossimo cliente regolato farà la stessa domanda. Se la risposta è solo nella testa di una persona, il contratto si blocca.

Una pagina prezzi scritta per un ingegnere dei pagamenti, non per il cliente

Circuiti, BIN, network, sovrapprezzi. Chi compra voleva sapere quanto avrebbe pagato, non come si chiamano le cose.

kiBank · una banca consumer che si dissolve nella giornata

Una banca consumer progettata e costruita per intero. Sito di marketing, app, design system, e tutta l'infrastruttura sotto. Due superfici, una sola promessa, ogni schermata che si guadagna il proprio posto togliendo un attrito quotidiano.

Dentro la build di kiBank

Una banca consumer vive su un telefono. Le persone aprono l'app bancaria tutti i giorni, spesso prima di colazione, spesso con una mano sola in metropolitana. La maggior parte delle app rende quel momento caotico, sterile, o ansioso. kiBank ha scelto una terza strada: una banca che si dissolve nella giornata.

Il prodotto doveva risultare quieto, comportarsi velocemente, e dimostrare il proprio valore nei primi dieci secondi di ogni sessione. Due superfici, una sola promessa, e ogni schermata che si guadagna il proprio posto togliendo un attrito quotidiano. Abbiamo progettato e costruito l'intero ecosistema, dal sito di marketing all'app, passando per il design system e tutta l'infrastruttura sotto. Un solo team, una sola base.

Il design system era il progetto

Una banca che vive su un telefono non ha spazio per stili one-off. Abbiamo iniziato costruendo i componenti che il sito di marketing, l'app, e gli strumenti di back-office avrebbero condiviso, ovvero bottoni, card, badge di stato, input group, sheet modali, righe di lista, grafici, e il sistema di toast che fa emergere ogni evento di transazione. Centoventi componenti, duecento design token, un audit di accessibilità che copre screen reader, controllo vocale e sensibilità al movimento. I temi chiaro e scuro condividono ogni layout, ogni regola di spaziatura, ogni curva di animazione. Un cambio di tema costa zero round trip e sopravvive a un kill-and-relaunch dell'app.

Il sito di marketing come una sola conversione

Il sito è costruito attorno a un solo risultato, cioè portare il visitatore a installare l'app prima che cambi scheda. Ogni sezione risponde a una domanda emersa nelle interviste con i clienti, nell'ordine in cui quelle domande arrivano. Una shell statica Next.js viene distribuita da Vercel Edge in meno di 200ms in qualunque parte d'Europa, e le immagini arrivano da Cloudflare R2 con conversione AVIF al volo. L'intera landing pesa meno di una sola foto prodotto su un tipico sito di e-commerce. L'eroe della pagina è un telefono, non una persona. I proof point sono silenziosi: il design di una carta, un saldo, una notifica. La CTA è il bottone di installazione.

Sei schermate portano la banca

L'app fa stare l'intera esperienza in sei schermate. La disciplina si vede subito: ogni tap è una decisione più in profondità in un flusso, mai uno spostamento laterale che fa perdere il contesto. La home porta il saldo, l'attività recente, e una sola azione suggerita. La schermata carta blocca, sblocca, e rivela i dati della carta dietro un prompt biometrico. L'attività filtra e cerca. La schermata di invio è un'unica form che si adatta a un bonifico SEPA, a un trasferimento interno, o a un pagamento programmato senza cambiare layout. Il profilo porta lo stato KYC, le impostazioni di notifica, e il canale di supporto. La schermata azioni-carta è dove vivono i limiti di spesa, le carte virtuali, e il blocco merchant.

La banca vive sul telefono

L'ottantatré per cento delle sessioni avviene dal telefono, in movimento, con una mano sola. Il design mobile non parte da un wireframe, parte dall'ergonomia del pollice. I tap target sono almeno quarantaquattro pixel, con otto pixel di respiro su ogni lato. L'azione primaria vive nel terzo inferiore della schermata, sempre raggiungibile. La tastiera che si apre non spinge i contenuti fuori dall'area visibile, è il form a scorrere nello spazio disponibile mentre l'azione resta visibile. La stessa libreria di componenti rende le stesse schermate su web e su mobile. Niente re-skinning, niente codepath separato.

La fiducia che nasce da questo design è operativa, non promozionale. La schermata carta rivela il numero solo dopo un prompt biometrico e pulisce gli appunti dopo trenta secondi. La schermata di invio non auto-compila mai l'importo dall'attività precedente, perché lo spintarello sbagliato sul denaro è peggio di nessuno spintarello. Il sistema di notifica è PSD2-compliant: gli avvisi di transazione arrivano, ma non rivelano mai il nome del merchant o l'importo sulla schermata di blocco, a meno che l'utente non l'abbia scelto in modo esplicito. Ogni scelta che tocca il portafoglio è auditabile, reversibile, e tarata per la persona che controlla il proprio saldo con una mano sola mentre va al lavoro.

Perché questa forma conta per un founder fintech

Un prodotto fintech non è il sito di marketing più una carta. È il flusso KYC al signup, il redirect 3DS2 al primo acquisto, il registro contabile che legge il revisore, la risposta di supporto che il cliente legge alle 23 quando una transazione gli sembra sbagliata, e il report regolatorio che esce ogni mese nel formato giusto. kiBank è la forma di lavoro che chiude tutto quel cerchio sotto un solo design system e una sola infrastruttura, non otto fornitori che vedono ognuno una fetta del cliente. Il risultato è un prodotto che mantiene la propria forma quando arriva la licenza successiva, la geografia successiva, o la linea di prodotto successiva.

Quello che il lavoro ha consegnato

Due superfici sotto un solo design system. Centoventi componenti. Duecento design token. Un audit di accessibilità completo sull'intera app. Web servito sotto i 200ms in tutta Europa da Vercel Edge. Cambio di tema dell'app che costa zero round trip e sopravvive a un kill-and-relaunch.

Leggi il case study completo

Cosa consegniamo in questo verticale

Integrazione KYC con Onfido o Veriff

Cattura del documento, liveness check, sanctions e PEP screening, tutto cablato a una state machine che il team di supporto può controllare.

Registro contabile event-sourced

A partita doppia, immutabile, replayable. La prima richiesta del revisore si soddisfa con una query SQL, non con una riunione.

Connettori PSD2 per open banking

Account information e payment initiation tramite Tink, TrueLayer, o direttamente sulla API dell'ASPSP.

Riduzione dello scope PCI

I dati della carta non toccano mai i tuoi server. Stripe Elements o Adyen drop-in, solo token, il server-side non vede mai il PAN.

Flusso 3DS2

Conforme alla SCA, con una rotta redirect-back che regge la sessione attraverso la pagina di challenge dell'issuer.

Issuing su circuito Visa o Mastercard

Tile sul circuito, BIN sponsorship via partner BaaS se non hai una licenza propria.

Riconciliazione delle transazioni

Match giornaliero a tre vie tra registro contabile, file di settlement del circuito ed estratto conto bancario.

Monitoraggio frodi e AML

Motore di regole più modello ML più coda di revisione manuale. Le transazioni sospette restano lato server prima di arrivare al cliente.

Export per la rendicontazione regolatoria

SEPA, FATCA, CRS, transaction reporting nei formati che il regolatore chiede davvero.

Audit log di compliance

Ogni azione privilegiata attribuita, firmata, interrogabile. Il revisore entra con una domanda ed esce con un CSV.

Autenticazione biometrica

Face ID e Touch ID all'apertura dell'app, con fallback su passcode che non sembra un ripiego.

Dashboard di customer due diligence

Vista per il responsabile compliance, con revisioni in sospeso, casi sospetti, KYC scaduti, hit sulle liste di sanzioni.

Notifiche push conformi

Avvisi di transazione PSD2-compliant che non rivelano dati sensibili sulla schermata di blocco.

Blocco carta, limite di spesa, carta virtuale

Le tre funzioni che il cliente cerca davvero al secondo accesso, cablate sulla stessa state machine.

Uno stack che combacia con il taccuino del regolatore

Ogni livello qui esiste per ripagarsi due volte: la prima quando stai mettendo online la prima versione del prodotto, la seconda quando ti trovi davanti a un regolatore o a un responsabile compliance che chiede esattamente come il sistema risponde alla sua domanda. Scegliamo lo stack che regge proprio in quel secondo momento.

Next.js App Router su Vercel Edge. Il sito di marketing e la webview dell'app vivono nello stesso runtime, con nodi edge che tengono la callback KYC sotto i 200ms in qualunque parte d'Europa. Il redirect-back del 3DS2 atterra su una rotta protetta dal middleware edge che ha già verificato la sessione prima ancora di renderizzare un solo byte sul browser.

Supabase Postgres con sicurezza a livello di riga ed event sourcing sul registro contabile. L'isolamento multi-tenant è imposto sulla riga, non nel codice applicativo, perché la prima domanda dell'audit del regolatore è esattamente quella. Il registro è a partita doppia e immutabile, con posting append-only, ogni saldo derivabile per replay, ogni riconciliazione riproducibile senza stored procedure.

Stripe Elements o Adyen drop-in per i dati della carta. Il PAN non tocca mai i tuoi server, e così lo scope PCI resta su SAQ A. I token tornano indietro, i pagamenti escono, e il codice si fa auditare in un pomeriggio invece che in un trimestre.

Onfido o Veriff per il KYC, cablati a una state machine che il team di supporto e il team compliance leggono dalla stessa schermata. Sanctions e PEP screening su ogni iscrizione e su ogni cambio di titolare effettivo, con la coda di hit che alimenta direttamente la dashboard di customer due diligence.

Cloudflare R2 per i documenti dei clienti, cioè documenti KYC, estratti conto, report regolatori. Cifrati a riposo con chiavi gestite dal cliente, accesso solo con URL firmata, niente costi di egress quando il regolatore chiede l'export completo degli ultimi dodici mesi.

TypeScript strict dall'API alla UI. I rename restano sicuri, le migrazioni di schema restano verificabili, il bus factor resta a zero. Quando il responsabile compliance che ha impostato le regole lascia il team, il prodotto non perde la propria memoria istituzionale.

Domande che fanno i founder

Siete regolati, o vi appoggiate a un partner BaaS?

Non abbiamo una licenza nostra. Per issuing, pagamenti o raccolta depositi ci appoggiamo a un provider BaaS che ce l'ha, e cuciamo l'integrazione. La controparte legale resta l'ente licenziato, noi ci occupiamo della superficie prodotto e del codice di integrazione.

Si riesce a collegarsi al nostro core banking attuale?

Sì. Abbiamo integrato Mambu, Thought Machine, e un paio di ASPSP europei direttamente. Se il vostro core espone una API HTTP sensata e uno stream di webhook, ci colleghiamo. Se non lo fa, gli costruiamo intorno un wrapper.

Come tenete lo scope PCI al minimo?

I dati della carta passano direttamente dal browser a Stripe Elements o Adyen drop-in. I vostri server ricevono un token, mai un PAN e mai un CVV. Il codice finisce in scope SAQ A, che è l'attestazione annuale meno costosa che si possa avere.

Come gestite il flusso 3DS2 al primo pagamento?

Una rotta redirect-back che tiene la sessione attraverso la pagina di challenge dell'issuer, più un fallback nel flusso mobile per quando il cliente è in-app. Il cliente non rinserisce mai la carta.

Il registro contabile regge un audit finanziario?

È a partita doppia, append-only, ed event-sourced. Il revisore riceve un accesso read-only sulla tabella delle postings e ricostruisce ogni saldo con una query SQL. Abbiamo accompagnato dei revisori dentro, e sono usciti prima del previsto.

Cosa fate per sanctions screening e liste PEP?

Integriamo ComplyAdvantage o Refinitiv al signup e a ogni cambio di titolare effettivo. Gli hit finiscono in una coda che il responsabile compliance smaltisce dal dashboard di customer due diligence, e il cliente resta in stato pending finché la coda non è chiusa.

Come gestite dispute e chargeback?

La coda dei chargeback alimenta una singola inbox di supporto, con la notifica al merchant, il template di evidence per il cardholder e il tracker delle deadline del circuito tutto su un'unica schermata. Il team che gestisce i rimborsi è lo stesso che risponde al chargeback, così il cliente sente una voce sola.

Vi occupate anche delle pratiche regolatorie?

No. Lavoriamo insieme ai legali e ai consulenti di compliance che portate voi. Possiamo suggerire partner con cui abbiamo già spedito progetti, ma le pratiche regolatorie non sono nostre da firmare.

Raccontaci il tuo prodotto fintech

Una chiamata per inquadrare il progetto, un numero concreto nella prima risposta, zero teatro da agenzia e zero pitch deck di case study tutti uguali.