Fintech:
Pagamenti / finanza regolamentata

Il libro mastro esistente del cliente era stato innestato sull'istanza PostgreSQL operativa dal primo giorno. Regolamenti, rimborsi, versamenti ai partner e saldi dei clienti scrivevano tutti nelle stesse tabelle che servivano l'applicazione, senza invariante in sola aggiunta e senza traccia di audit distinta. L'audit dell'autorità di regolamentazione ha rilevato quattro difetti concreti: le transizioni di stato non erano registrate in modo sistematico con l'attore che le aveva avviate, i calcoli di saldo dipendevano da una join che poteva perdere righe in silenzio sotto carico, i periodi di conservazione erano incoerenti da una tabella all'altra, e la postura di ripristino da uno snapshot corrotto non era stata testata.

Peggio ancora, il team che aveva costruito il libro mastro era andato via da tempo. La conoscenza istituzionale sul perché di ogni scorciatoia era andata via con esso. PLACEHOLDER: confermare la tempistica di transizione del team con il cliente prima di ogni pubblicazione esterna.

La postura di SDEN sui libri mastro finanziari è esplicita: in sola aggiunta per costruzione, in partita doppia per principio contabile, isolato dal database operativo, e progettato per l'audit prima che l'audit sia pianificato. La migrazione si è svolta in quattro fasi, ciascuna con un punto di validazione controllato su cui il cliente poteva porre il veto.

1. Fase 1: Inquadramento e modello di minaccia

   Due settimane. Abbiamo mappato ogni transizione di stato che il libro mastro esistente produceva, individuato le sette che l'autorità di regolamentazione avrebbe trattato come critiche per l'audit, e redatto il modello di minaccia attorno a esse. Risultato: una tassonomia di eventi tipizzata, uno schema target, e un registro dei rischi che il CFO del cliente ha firmato.

2. Fase 2: Costruzione del libro mastro in sola aggiunta

   Otto settimane. Nuovo libro mastro in un cluster PostgreSQL distinto con invarianti stretti in sola aggiunta imposti al database e al livello applicativo, contabilità in partita doppia, log di audit immutabile diffuso verso una destinazione isolata, e chiavi di cifratura per tenant per gli account di alto valore.

3. Fase 3: Migrazione a doppia scrittura

   Dieci settimane. Ogni scrittura verso il libro mastro esistente era duplicata verso quello nuovo, con una riconciliazione continua. Gli scarti erano investigati e corretti alla fonte, non rattoppati. La finestra di doppia scrittura è rimasta aperta abbastanza a lungo da assorbire il ciclo completo di riconciliazione che il cliente esegue mensilmente con i suoi partner bancari.

4. Fase 4: Switchover e prova d'audit

   Sei settimane. I cammini di lettura sono migrati verso il nuovo libro mastro dietro feature flag. Lo switchover delle scritture è avvenuto un sabato con il team operations in una war room dedicata. La prova d'audit ha eseguito le query attese dall'autorità di regolamentazione contro il nuovo libro mastro e ha prodotto l'esatto dossier di prove che il team di audit ha richiesto il mese successivo.

L'audit è stato superato al primo colpo. PLACEHOLDER: confermare l'ente di audit e il quadro normativo prima di ogni pubblicazione esterna: il progetto era inquadrato secondo le aspettative di un'autorità di vigilanza finanziaria europea equivalenti a Consob / Banca d'Italia / ESMA.

Sul piano operativo, il ciclo di riconciliazione che il team eseguiva manualmente ogni mese è diventato un processo quotidiano automatizzato. Il bus factor sulla conoscenza del libro mastro è passato da un ingegnere a quattro. La base di codice è nei repository del cliente con una documentazione scritta per il prossimo ingegnere che entra nel team, non per il project manager che ha inquadrato il progetto.