Il contesto: dati preziosi in un modello di accesso che non reggeva più
Abbrevia S.p.A. è uno dei principali provider italiani di business intelligence e valutazione del rischio creditizio. Il loro asset strategico: un database proprietario su milioni di aziende italiane, aggiornato continuamente con dati camerali, bilanci, eventi pregiudizievoli, protesti e segnalazioni di anomalie.
Per anni, questo patrimonio informativo era stato accessibile attraverso workflow tradizionali: query manuali, report su richiesta, export batch periodici. Un modello che funzionava per una certa generazione di clienti — ma che non reggeva più due pressioni convergenti:
- La compliance AML/KYC era diventata obbligatoria per legge, con requisiti stringenti di audit trail e verifica continuativa delle controparti per banche, intermediari finanziari e istituti di pagamento.
- I clienti si aspettavano accesso in tempo reale, non export notturni. Un'operazione creditizia non può aspettare un report il giorno dopo.
La conclusione era chiara: non bastava ottimizzare i processi esistenti. Serviva una piattaforma costruita per il futuro, non adattata dal passato.
La sfida progettuale: multi-prodotto, multi-tenant, mission-critical
Il brief iniziale definiva tre dimensioni non negoziabili.
Multi-prodotto. Abbrevia non voleva un singolo prodotto, ma una piattaforma che ospitasse suite di moduli con logiche distinte — credit risk scoring, report informativi, AML/KYC compliance, monitoraggio continuativo — ognuno con regole di pricing, accesso e API proprie. La piattaforma doveva essere estensibile: i prodotti di domani non potevano richiedere una riscrittura dell'architettura di oggi.
Multi-tenant enterprise. I clienti di Abbrevia sono istituzioni finanziarie soggette a vigilanza: banche, intermediari, società di factoring, istituti di pagamento. Non utenti "consumer" che tollerano un downtime di qualche ora o un audit trail impreciso. Ogni istituzione pretende segregazione completa dei dati e la capacità di dimostrare agli organi di vigilanza esattamente cosa è stato consultato, da chi, quando e con quale esito.
Scala verso l'alto. Il target erano 4M+ richieste annue con picchi enterprise da gestire senza degradazione. Ma la piattaforma doveva essere progettata per crescere senza che l'architettura diventasse il collo di bottiglia alla prima espansione commerciale.
La prima decisione che ha contato non è stata tecnologica: è stata disegnare il confine esatto tra ciò che la piattaforma avrebbe gestito e ciò che i sistemi sottostanti di Abbrevia avrebbero continuato a fare. Sbagliare questa linea in un progetto multi-prodotto significa accoppiamento crescente, refactoring costosi e roadmap sempre in ritardo.
Come abbiamo strutturato il progetto
Prima di scrivere una riga di codice: tre settimane di discovery e architettura review con il team tecnico e business di Abbrevia. L'obiettivo non era produrre un documento — era allineare le aspettative su quattro aree critiche:
- I flussi dati esistenti e i punti di integrazione con i database proprietari Abbrevia
- I requisiti normativi specifici: AML/KYC, GDPR applicato al trattamento dati d'impresa, indicazioni Banca d'Italia per gli intermediari vigilati
- I pattern di utilizzo reali dei clienti enterprise (quante richieste, in che arco orario, con quali picchi)
- I target di performance non negoziabili: latenza massima accettabile per query real-time, SLA di disponibilità, recovery time dopo un'interruzione
Solo dopo questo lavoro preparatorio abbiamo potuto definire un'architettura che risolvesse il problema reale, non quello immaginato.
L'architettura: tre layer distinti per tre responsabilità distinte
La piattaforma Abbrevia-X è strutturata in tre strati con responsabilità nette e interfacce ben definite.
Layer 1 — Data & Integration
Un integration layer che astrae i sistemi dati sottostanti di Abbrevia esponendo API standardizzate verso il layer applicativo. Questo strato gestisce query optimization, caching intelligente per i profili ad alta frequenza di accesso, normalizzazione dei dati da fonti eterogenee (dati camerali, informazioni creditizie, eventi pregiudizievoli) e gestione dei refresh. Cambiare una fonte dati sottostante non richiede toccare il layer superiore.
Layer 2 — Product Core
Il nucleo della piattaforma ospita i moduli prodotto con logica di business propria: Credit Risk & Scoring per l'accesso real-time ai profili aziendali con scoring multi-dimensionale; AML/KYC Module con workflow strutturati per onboarding, due diligence periodica e monitoraggio continuativo, audit trail immutabile incluso; Report & BI per la generazione di report informativi approfonditi; Monitoring per l'alerting automatico su variazioni nei profili delle controparti monitorate.
Layer 3 — Tenant Management & Gateway
Gestione dell'accesso multi-tenant con isolamento completo tra clienti, API key management, rate limiting per piano contrattuale, billing integration e analytics di utilizzo granulare per prodotto e per cliente. Questo layer è anche il punto di ingresso per le integrazioni enterprise via API.
Le scelte tecniche che hanno fatto la differenza
Event-driven per il monitoraggio continuativo
Per il modulo di monitoraggio su 6M+ profili, il polling attivo sarebbe stato insostenibile: verificare periodicamente milioni di record per identificare i cambiamenti avrebbe richiesto risorse computazionali sproporzionate. Abbiamo adottato un'architettura event-driven: quando un profilo monitorato subisce un aggiornamento nei sistemi sottostanti, viene emesso un evento che i subscriber configurati per quel cliente processano in modo asincrono. Il risultato: notifiche in tempo reale senza carico computazionale lineare rispetto al volume dei profili monitorati.
4M+ richieste annue gestite senza polling attivo su milioni di profili. L'event-driven non era una scelta di tendenza: era l'unica architettura sostenibile a quella scala.
Audit trail immutabile per la compliance AML
Per i clienti soggetti a vigilanza, la capacità di dimostrare agli organi di controllo quando è stata effettuata una verifica, da chi, su quale controparte e con quale esito non è un requisito nice-to-have: è un vincolo normativo. Ogni operazione nel modulo AML/KYC produce un record firmato e immutabile nel log, con timestamp certificato, identificativo dell'operatore, hash dei dati consultati e risultato della verifica. Questo audit trail è esportabile in formato standard per gli adempimenti verso Banca d'Italia e gli organismi di vigilanza europei.
La scelta progettuale cruciale: l'audit trail è stato progettato come requisito primario, non aggiunto in seguito. I sistemi di compliance che lo costruiscono come afterthought mancano sempre qualcosa al momento dell'ispezione reale.
Multi-tenant con isolamento completo, non con shared tenancy
La soluzione più economica operativamente — uno schema database condiviso tra tenant con row-level security — non era accettabile per istituzioni finanziarie soggette a vigilanza. La segregazione completa ha un costo in infrastruttura e overhead operativo maggiore, ma è l'unica architettura che passa senza compromessi un audit normativo che richiede dimostrazione dell'assenza di accesso incrociato tra clienti.
API bulk per i clienti enterprise
I clienti enterprise — banche con portafogli di migliaia di controparti — non usano la piattaforma una richiesta alla volta. Hanno bisogno di arricchimento massiccio dei propri sistemi interni, importazione batch di nuove controparti e aggiornamenti periodici di tutti i profili monitorati. Abbiamo progettato API bulk con gestione asincrona dei job, notifiche al completamento, rate limiting per piano contrattuale e dashboard di stato che non penalizzano i client standard durante i picchi di utilizzo enterprise.
I risultati
La piattaforma è oggi il prodotto strategico principale di Abbrevia, con clienti distribuiti in tutto il settore finanziario italiano: banche commerciali, intermediari di credito, società di factoring, istituti di pagamento, studi di consulenza aziendale. Il modulo AML/KYC ha abilitato Abbrevia ad entrare in segmenti di clientela che in precedenza non potevano essere serviti per mancanza di un workflow compliance certificabile.
Collaboriamo con TC Consulting da diversi anni per lo sviluppo di soluzioni software e progetti integrati con intelligenza artificiale. Oltre alle competenze tecniche, ciò che fa davvero la differenza è la professionalità delle persone: un team preparato, disponibile e capace di comprendere a fondo le esigenze di business. Un partner affidabile e orientato al risultato, con cui è semplice costruire valore nel tempo.
Cosa ci ha insegnato questo progetto
Il confine tra platform e product è una scelta strategica, non tecnica
La prima decisione non è "quale framework usiamo" ma "dove finisce la piattaforma e dove inizia il prodotto". In un sistema multi-prodotto, sbagliare questa linea significa accoppiamento progressivo che rallenta ogni nuovo sviluppo. Dedicare settimane alla discovery prima del codice non è un costo: è il miglior investimento del progetto.
Nei settori regolamentati, l'audit trail non è un'aggiunta successiva
Se lo costruisci come afterthought — "lo aggiungiamo quando serve" — manca sempre qualcosa al momento dell'ispezione reale. L'audit trail va progettato come requisito primario di architettura, non come feature di release 2.0. Il costo di aggiungerlo ex post è sistematicamente sottostimato.
Il multi-tenant "vero" non è negoziabile in finance
La segregazione completa ha un costo operativo superiore alla shared tenancy. Ma in un contesto dove i clienti sono soggetti a vigilanza, è l'unica architettura che sopravvive a un audit normativo senza compromessi o soluzioni di emergenza. Il risparmio in infrastruttura non vale il rischio di non poter dimostrare l'isolamento in sede ispettiva.