Nei portafogli NPL il collo di bottiglia sono i dati, non lo scoring

Chi lavora su portafogli di credito deteriorato conosce bene il momento in cui un portafoglio NPL passa di mano: arriva quasi sempre come un file Excel, con un tracciato che non rispetta il proprio stesso schema — indirizzi scritti in quattro formati diversi, date in tre formati diversi, posizioni duplicate con lievi variazioni sul nome del debitore.

Prima ancora di poter impostare una strategia di recupero, qualcuno deve passare giorni — a volte settimane — a capire quante posizioni ci sono davvero, quali sono duplicate, quali hanno dati sufficienti per essere lavorate. Non è un’attività di analisi. È archeologia dei dati.

Perché il tempo è la variabile che pesa di più

In un portafoglio NPL il tempo che passa tra l’acquisizione e la prima azione di recupero è una delle variabili che erode più valore atteso del portafoglio — spesso più del tasso di recupero stimato, più dei costi legali della procedura. Ogni settimana spesa a ricostruire manualmente l’anagrafica delle posizioni è una settimana in cui il portafoglio non genera nessuna azione, e quindi nessun recupero.

È un problema che si nota soprattutto perché è asimmetrico rispetto a dove va l’attenzione: gli strumenti di scoring, segmentazione e prioritizzazione delle posizioni sono maturi, funzionano bene, e sono relativamente facili da mettere in produzione una volta che i dati sono puliti. Il lavoro che fa davvero la differenza sul time-to-first-action è quello che non finisce mai in una slide: normalizzare i formati, deduplicare le posizioni, riconciliare i tracciati di originator diversi tra loro e con i sistemi interni.

Un problema di modellazione, non solo di pulizia dati

Trattato come semplice “data cleaning”, questo lavoro tende a essere svolto ad hoc, portafoglio per portafoglio, con script scritti sotto pressione e mai riutilizzati. Il problema si ripresenta identico al portafoglio successivo, spesso con un originator diverso e un tracciato altrettanto inconsistente.

Noi lo trattiamo come un problema di modellazione del dominio, non di pulizia una tantum — è l’approccio Domain-Driven Design che applichiamo trasversalmente, anche fuori dal contesto industriale in cui abbiamo costruito la nostra esperienza:

  • Un anti-corruption layer per ogni sorgente: invece di adattare il modello interno al formato di ogni fornitore di dati, ogni tracciato in ingresso viene tradotto in un modello di dominio canonico (posizione, debitore, garanzie, storico pagamenti) attraverso un layer di traduzione dedicato. Il formato sorgente può cambiare, il modello a valle no.
  • Bounded context separati per ingestion e per recupero: la logica che normalizza e riconcilia i dati in ingresso è un contesto a sé, con le sue regole e la sua definizione di “posizione valida” — separata dal contesto che applica scoring e strategia di recupero. Mescolarli è la ragione per cui, in molti sistemi, un tracciato malformato blocca anche la parte “intelligente” a valle.
  • Pipeline event-driven invece di ETL big-bang: un portafoglio viene ingerito come sequenza di eventi (posizione ricevuta, posizione validata, duplicato rilevato, posizione riconciliata), non come un unico batch che deve andare a buon fine per intero. Permette di iniziare a lavorare le posizioni pulite mentre le eccezioni vengono ancora gestite, invece di aspettare che tutto il portafoglio sia “a posto”.

Questo non elimina il lavoro di normalizzazione — lo rende ripetibile. Il secondo portafoglio, e il decimo, costano una frazione del primo, perché l’anti-corruption layer si estende invece di essere riscritto.

Cosa non promettiamo

Non promettiamo un miglioramento del tasso di recupero: quello dipende da variabili — natura del credito, garanzie, strategia legale — che non sono di nostra competenza. Quello su cui possiamo essere utili, e su cui misuriamo davvero il risultato, è il tempo che passa tra l’acquisizione di un portafoglio e il momento in cui la prima azione di recupero può partire su dati affidabili.

Se stai valutando come strutturare — o velocizzare — l’ingestion dati di un portafoglio NPL, o più in generale l’architettura di una piattaforma di gestione del credito deteriorato, parliamone.

Altri approfondimenti

Vuoi ragionare sul tuo impianto?

Partiamo dal processo e dai dati disponibili per definire insieme il prossimo passo.