Soluzioni · Servizi finanziari
Un’applicazione per servizi finanziari si giudica da ciò che accade ai suoi margini: cosa viene scritto nel registro, cosa accade quando il cliente chiede indietro i propri dati, cosa si vede nell’informativa precontrattuale e cosa accade quando un’attività programmata non viene eseguita. Noi costruiamo la meccanica; la politica di credito resta vostra.
Già costruitoO platformă de creditare în producție, verificabilă din exterior azi: partea publică e o aplicație compilată static cu 50 de ecrane, între care patru calculatoare — credit, eligibilitate, refinanțare, grafic de plăți — pagini pe tip de credit, informare precontractuală și o rută prin care clientul își cere datele personale; partea de business e un backend modular în TypeScript cu 16 module și 18 tabele în schema de date, între care contract, plată, jurnal de audit, cerere privind datele personale, document încărcat, instantaneu zilnic de indicatori și rulare de sarcină programată. Harta de site de pe producție listează 227 de adrese, iar rutele românești și cele rusești răspund amândouă — verificate de mine pe 06.09.2026. Rezerva pe care o spunem: dovada e din cod și din răspunsurile publice, nu din comportamentul intern al serverului — nu am verificat pe ce versiune rulează producția și nici că toate cele 16 module sunt active pe live.
Una società di credito non ha bisogno di un sito. Ha bisogno di una catena completa: la richiesta entra online, passa attraverso un flusso decisionale, produce un contratto, genera un piano di pagamento e lascia traccia nell’audit. Ogni anello mancante nella catena si trasforma in una persona che copia dati da un posto all’altro, e nei servizi finanziari ogni copia manuale è anche un problema di conformità, non solo di tempo.
La struttura che costruiamo riflette questo direttamente nei dati. Nella piattaforma che citiamo, lo schema ha 18 tabelle, e il loro elenco dice più di qualunque descrizione architetturale: richiesta, contratto, pagamento, codice monouso, sessione, richiesta di richiamata, modello di notifica, registro delle notifiche, istantanea giornaliera degli indicatori, esecuzione di attività programmata, articolo, reindirizzamento di indirizzo, impostazione di visibilità, nota interna, registro di audit, documento caricato, richiesta relativa ai dati personali. Il backend è suddiviso in 16 moduli, tra cui uno dedicato esclusivamente ai diritti dell’interessato.
La parte pubblica non è decorazione: quattro calcolatori — credito, eligibilità, rifinanziamento e piano di pagamento — più pagine separate per tipo di credito e l’informativa precontrattuale. Nel credito al consumo, l’informativa precontrattuale non è una pagina d’immagine: è l’obbligo di mostrare le condizioni prima che la persona si impegni. La trattiamo come un requisito del prodotto, non come un testo giuridico incollato alla fine. I percorsi romeni restano senza prefisso, mentre quelli russi vanno su un segmento proprio, con etichette canoniche e alternative generate dalla lingua del percorso attivo.
E il limite che va detto prima del contratto: il flusso decisionale sulle richieste — le regole, le soglie, l’approvazione — è vostro. Noi costruiamo la meccanica attraverso cui la richiesta circola, viene documentata e diventa contratto. Non scriviamo la politica di credito e non ci assumiamo la valutazione di un richiedente; sono decisioni con conseguenze giuridiche che appartengono all’istituto autorizzato.
Cosa comprende
La richiesta entra online e vive come entità propria, con stato visibile e con una schermata di monitoraggio per il cliente. I documenti caricati hanno la loro tabella, il contratto ha la sua tabella, il pagamento la sua. La differenza rispetto a un modulo che invia un’e-mail è che, dopo tre mesi, si può rispondere dai dati alla domanda «che cosa è accaduto alla richiesta del 12 marzo».
Il contratto e il piano non vengono composti manualmente in un documento separato: escono dai dati della richiesta approvata. È l’unica variante in cui il numero nel contratto e il numero nel piano non possono differire, e il cliente che chiama con il documento in mano parla della stessa cosa dell’operatore che guarda nel sistema.
Credito, eligibilità, rifinanziamento e piano di pagamento — schermate separate, pubbliche, senza autenticazione. Nel credito al consumo, il calcolatore è la prima interazione reale: la persona vuole vedere la rata prima di parlare con qualcuno. E il rifinanziamento è un calcolatore diverso da quello del credito, non lo stesso con altre etichette.
Pagina propria, non un paragrafo nel piè di pagina. Il motivo è pratico: se l’informativa non è nel percorso che la persona compie prima di firmare, non fa il suo lavoro né per lei né per l’istituto. Il testo è vostro e dei vostri giuristi; noi costruiamo il luogo, il momento e la tracciabilità.
Esiste una pagina pubblica attraverso la quale il cliente richiede i propri dati personali, un modulo backend dedicato e uno schermo di amministrazione per le richieste ricevute, oltre a una tabella in cui esse risiedono. La conseguenza pratica: il termine legale di risposta può essere rispettato senza che qualcuno apra manualmente il database — e si può dimostrare, dopo un anno, che è stato rispettato.
Il registro di audit è una tabella propria, distinta dalle note interne degli operatori. La separazione conta in sede di verifica: una è l'evidenza tecnica di ciò che è accaduto, l'altra è ciò che ha scritto un collega su un dossier. Mescolate, la prima diventa illeggibile e la seconda diventa un documento.
Esiste una tabella per le esecuzioni delle attività pianificate e una per gli snapshot giornalieri degli indicatori. In una piattaforma finanziaria, un'attività che non è stata eseguita per tre notti di fila è un problema più grave di una pagina offline: non si vede dall'esterno, ma sposta i numeri. Per questo l'esecuzione si registra, non si presume.
I percorsi romeni restano senza prefisso, quelli russi passano su un segmento proprio, con etichette canoniche e alternative generate dalla lingua del percorso attivo. Nella sitemap in produzione ci sono 227 indirizzi. Per una società di credito della Repubblica Moldova, la parte russa non è una traduzione di cortesia — è metà dei richiedenti.
Verifiche pre-pubblicazione, migrazioni di database eseguite con comando separato in produzione, generazione di secret, backup e ripristino del database — tutto come script nel repository, non come passaggi in un documento. In un sistema che gestisce contratti e pagamenti, «ripristino» deve essere un comando che avete provato, non un'intenzione.
Traseul
Cosa significa una richiesta presentata, una richiesta approvata, un pagamento incassato; cosa accade a una richiesta a cui non si è risposto; cosa si chiude quando un servizio esterno non risponde. Consegniamo il documento di vocabolario e invarianti, perché in una piattaforma finanziaria un termine usato in due sensi diventa, più tardi, due cifre diverse in due report.
Il registro di audit e l'evidenza dei documenti non si aggiungono alla fine; fanno parte della prima versione che funziona. Consegniamo il flusso completo dalla richiesta al contratto, con la sua traccia, su dati di test — non schermate che sembrano belle sopra un database vuoto.
Le schermate pubbliche, i calcolatori, le pagine per tipo di credito e l'informativa precontrattuale, con gli indirizzi romeni senza prefisso e quelli russi su un segmento proprio, con etichette canoniche corrette. Consegniamo la sitemap generata dai dati e la verifica che entrambe le versioni rispondano.
Verifica pre-pubblicazione, migrazioni in produzione con comando separato, generazione di secret, backup e ripristino — collaudati, non solo scritti. Consegniamo il repository, il documento di messa in esercizio e gli accessi. Il ripristino del database viene dimostrato alla consegna, una volta, davanti a voi.
I dati
Le regole differiscono da un settore all’altro. Queste sono quelle che si applicano nei servizi finanziari.
Un caso
La situazione
Il requisito iniziale in un progetto di prestito suona quasi sempre allo stesso modo: «un sito con modulo di richiesta». Il problema emerge al secondo mese, quando qualcuno chiede dov’è il contratto, chi ha modificato il dossier e come rispondiamo a una richiesta di accesso ai dati personali entro il termine legale.
Cosa abbiamo costruito
Abbiamo costruito la piattaforma in due metà, nello stesso deposito. La parte pubblica è un’applicazione compilata staticamente, con 50 schermate: quattro calcolatori — credito, eleggibilità, rifinanziamento, piano dei pagamenti — pagine per tipo di credito, informativa precontrattuale, monitoraggio dello stato della richiesta e una pagina tramite la quale il cliente richiede i propri dati personali. La parte business è un backend modulare in TypeScript, con 16 moduli — tra cui autenticazione, diritti per ruolo, flusso delle richieste, documenti, pagamenti, notifiche, attività programmate e uno dedicato ai diritti dell’interessato — sopra uno schema con 18 tabelle: richiesta, contratto, pagamento, codice monouso, sessione, documento caricato, log di audit, richiesta relativa ai dati personali, esecuzione di attività programmata, istantanea giornaliera di indicatori e il resto.
Cosa è emerso
La catena è completa: la richiesta entra, circola, produce contratto e piano, e ogni passaggio lascia una traccia. Le richieste relative ai dati personali hanno un percorso proprio, con schermata di amministrazione, quindi il termine legale può essere rispettato e dimostrato. La parte pubblica è verificabile dall’esterno: 227 indirizzi nella mappa del sito, con entrambe le versioni linguistiche attive.
Cosa non dice il caso
La prova è nel codice e nelle risposte pubbliche, non nel comportamento interno del server: non abbiamo verificato su quale versione gira la produzione e nemmeno che tutti i 16 moduli siano attivi in live. Il flusso decisionale sulle richieste — regole, soglie, approvazione — appartiene al cliente; noi abbiamo costruito la meccanica, non la politica di credito.
Domande
Voi. Le regole, le soglie e l’approvazione sono la politica dell’istituzione autorizzata, non del fornitore di software. Noi costruiamo la meccanica attraverso la quale la richiesta circola, viene documentata, diventa contratto e piano dei pagamenti, e lascia traccia. Un fornitore che si assume la decisione di credito vende qualcosa che non ha il diritto di vendere.
Esiste una pagina pubblica attraverso la quale viene richiesta, un modulo backend dedicato, una schermata di amministrazione e una tabella in cui la richiesta vive. Quindi si può rispondere entro i termini e si può dimostrare successivamente. Ciò che non è una decisione tecnica: cosa può essere cancellato e cosa deve essere conservato in conformità alla legislazione finanziaria — questo si stabilisce con i vostri legali, prima dell’implementazione.
Dai dati della richiesta approvata, insieme al piano dei pagamenti — entrambi dalla stessa fonte, così da non poter differire. Ciò che resta vostro è il contenuto del contratto e le sue condizioni. Un contratto composto manualmente in un documento separato è il luogo classico in cui compaiono due cifre diverse per lo stesso prestito.
Perché nel credito al consumo l’informazione deve essere sul percorso che la persona segue prima di impegnarsi, non in un piè di pagina. La trattiamo come parte del prodotto: il luogo, il momento e la tracciabilità sono nostri, il testo è dei vostri legali.
Almeno di quelli che corrispondono a decisioni diverse. Nella piattaforma che citiamo sono quattro — credito, ammissibilità, rifinanziamento, piano dei pagamenti — perché il rifinanziamento non è lo stesso calcolo di un nuovo credito, e il piano risponde a una domanda diversa rispetto alla rata. Un solo calcolatore con molti campi è più difficile da usare di quattro semplici.
No, ed è una regola, non una preferenza: costruiamo e testiamo su dati di prova. L’accesso ai dati reali, quando è necessario, avviene con persone nominate, per un periodo stabilito e con traccia nel registro. In un sistema finanziario, „abbiamo avuto bisogno di guardare in produzione” è una frase che deve comparire in un registro, non in una discussione.
Si vede, perché le esecuzioni sono scritte in una tabella propria, accanto agli snapshot giornalieri degli indicatori. È importante proprio perché un’attività che non è stata eseguita non produce alcun sintomo visibile dall’esterno — il sito risponde, le schermate appaiono bene, ma i numeri non si muovono più.
Nessuna cifra di volume, di interesse, di numero di richieste o di clienti, anche se è esposta pubblicamente sul suo sito — perché è la sua affermazione, non la nostra misurazione. Ciò che possiamo mostrare è la struttura: quanti moduli, quali tabelle, quali schermate pubbliche, cosa viene verificato alla pubblicazione. La stessa regola si applicherà anche al vostro lavoro.
La parte pubblica si può verificare ora: la mappa del sito ha 227 indirizzi, e le versioni romena e russa di un calcolatore rispondono entrambe. La parte backend si legge dal codice — moduli e schema dei dati — non dal comportamento del server: non abbiamo verificato su quale versione gira la produzione e nemmeno che tutti i moduli siano attivi su live, e preferiamo scriverlo piuttosto che lasciare l’impressione contraria.
Raccontaci il tuo processo. Insieme stabiliamo cosa vale la pena costruire, cosa possiamo collegare e come verifichiamo il risultato.