Assegnazione del punteggio di affidabilità creditizia: Parte 9 - Implementazione delle scorecard: Distribuzione, produzione e monitoraggio

Blog

Inserito

15 nov 2017

Categoria

Scienza dei dati

Condividi

Di: Natasha Mashanovich, Senior Data Scientist presso World Programming, Regno Unito

"Conoscenza non è potere. L'applicazione della conoscenza è potere." – Il vantaggio reale di una scorecard o di una strategia di credito è evidente solo in fase di implementazione. La fase finale del framework CRISP-DM (implementazione) rappresenta la transizione dal dominio della scienza dei dati al dominio della tecnologia dell'informazione. Di conseguenza, i ruoli delle responsabilità cambiano anche dagli scienziati dei dati e dagli analisti finanziari agli amministratori e ai tester di sistema e di database.

Prima di implementare il scorecard, è necessario adottare una serie di decisioni tecnologiche. Queste decisioni riguardano: la disponibilità dei dati; la scelta di quale hardware e software è utilizzato; chi è responsabile dell'implementazione di scorecard; chi è responsabile della manutenzione delle scorecard e se la produzione viene gestita internamente o esternamente.

L'implementazione di scorecard è un processo sequenziale che viene avviato una volta che il modello di scorecard è stato autorizzato dall'azienda. Il processo inizia con la generazione di un codice di distribuzione delle scorecard, che porta alla pre-produzione, produzione e post-produzione.


Figura 1. Fasi di implementazione della scorecard

Codice di distribuzione

Il codice di distribuzione viene creato traducendo un modello concettuale, quale un'equazione di modello o una forma tabellare di una scorecard, in un artefatto software equivalente, pronto per essere eseguito su un server. La piattaforma di implementazione su cui verrà eseguito il modello identifica la lingua di distribuzione e potrebbe essere, ad esempio, il linguaggio SAS (Figura 2), SQL, PMML o C++. La scrittura del codice di distribuzione del modello può essere propensa all'errore e spesso rappresenta un collo di bottiglia, in quanto sono necessari diversi cicli di raffinamento del codice per produrre il codice di distribuzione. Alcuni fornitori analitici offrono funzionalità di distribuzione automatica dei codici nel loro software: una funzionalità desiderata che produce codice privo di errori, riducendo il tempo di distribuzione e il ciclo di verifica del codice.


Figura 2. Generazione automatica del codice di distribuzione del linguaggio SAS con il software di World Programming

L'implementazione di una scorecard, se è in un server di pre-produzione per la verifica o un server di produzione per il punteggio in tempo reale, richiede un wrapper API che viene posizionato attorno al codice di distribuzione del modello per consentire la gestione delle richieste remote per il punteggio del modello. Gli input per il modello, forniti da origini dati interne ed esterne, si possono estrarre sia dall'esterno che dall'interno del motore per il punteggio. Il primo esegue l'estrazione delle variabili al di fuori del motore per il punteggio e passa le variabili come parametri di una richiesta API. Quest'ultimo, come illustrato nella figura 3, esegue un codice di pre-elaborazione all'interno del motore per il punteggio e svolge l'estrazione delle variabili e il punteggio del modello nello stesso motore.


Figura 3. Punteggio in tempo reale tramite la chiamata API

Pre-produzione e produzione

La pre-produzione è un ambiente utilizzato per eseguire una serie di test prima di approvare il modello all'ambiente di produzione (live). Questi test sarebbero in genere test di valutazione del modello e di validità, test di sistema che misurano il tempo di richiesta e risposta con il carico di punta previsto, o i test di configurazione dell'installazione e del sistema.

I modelli accuratamente testati e approvati vengono caricati nell'ambiente di produzione, la destinazione finale. I modelli in esecuzione in un server di produzione possono essere nello stato attivo o passivo. I modelli attivi sono modelli di campioni i cui punteggi vengono utilizzati nel processo decisionale in tempo reale come approvazione o rifiuto di credito. I modelli passivi sono tipicamente richieste di verifica del modello non ancora utilizzate nel processo decisionale, ma i cui punteggi sono registrati e analizzati per un periodo di tempo, per giustificare il valore dell'azienda prima di diventare modelli attivi.

Monitoraggio

"Se non puoi misurarlo, non puoi migliorarlo. (Lord Kelvin)" – Ogni modello si degrada nel tempo in conseguenza all'evoluzione del modello naturale influenzata da molti fattori, tra cui i lanci di nuovi prodotti, incentivi per il marketing o la tendenza economica, per cui il normale monitoraggio del modello è fondamentale per prevenire qualsiasi effetto negativo sull'azienda.

Il monitoraggio del modello è la verifica post-implementazione utilizzata per determinare se i modelli continuano ad essere in linea con le prestazioni previste. L'infrastruttura informatica deve essere configurata in anticipo per consentire il monitoraggio agevolando la generazione di rapporti sul modello, un repository per l'archiviazione dei rapporti e un dashboard di monitoraggio.


Figura 4. Processo di monitoraggio del modello

È possibile utilizzare i rapporti sul modello, ad esempio, per individuare se le caratteristiche dei nuovi candidati cambiano nel tempo; stabilire se è necessario modificare il valore soglia del punteggio per regolare il tasso di accettazione o il tasso di insolvenza; o determinare se la scorecard classifica il cliente nello stesso modo in cui ha classificato la popolazione di costruzione di modelli su diverse bande di rischio.

La riduzione delle prestazioni della scorecard viene generalmente acquisita utilizzando i valori soglia predefiniti. A seconda della grandezza del cambiamento, si intraprende un corso di azione pertinente. Ad esempio, è possibile ignorare le modifiche minori nella metrica delle prestazioni delle scorecard, ma le modifiche moderate potrebbero richiedere una ricalibrazione del monitoraggio o della scorecard più frequente. Qualsiasi cambiamento importante richiede la ricostruzione del modello o lo scambio al modello alternativo con maggior rendimento.

I reparti del rischio di credito hanno accesso a una vasta gamma di rapporti, tra cui una serie di rapporti sulle tendenze, rapporti sull'adempimento e analisi del portafoglio (Tabella 1). Esempi di due rapporti più tipici sono la stabilità della popolazione e il monitoraggio delle prestazioni. La stabilità della popolazione misura durante un periodo di tempo il cambiamento della distribuzione dei punteggi di affidabilità creditizia nella popolazione. Il rapporto sulla stabilità genera un indice che indica la grandezza della modifica del comportamento del cliente a causa dei cambiamenti nella popolazione. Qualsiasi variazione significativa crea un avviso che richiede la riprogettazione del modello. Un rapporto sul monitoraggio dell'adempimento è un rapporto di back-end che richiede un tempo sufficiente per maturare i conti dei clienti affinché sia possibile valutare il rendimento della clientela. Il suo scopo è duplice; in primo luogo, verifica la potenza della scorecard valutando se è ancora in grado di classificare i clienti per rischio e, in secondo luogo, ne verifica la precisione confrontando i tassi di insolvenza previsti, noti al momento della costruzione di modelli con i tassi di insolvenza attuali.

Tipo di rapportoNome del rapporto
Rapporti sulle tendenzeStabilità della popolazione
Analisi dei tassi dell'approvazione
Analisi delle caratteristiche
Rapporti sull'adempimentoMonitoraggio sull'adempimento
Analisi per coorte
Analisi del portafoglioDistribuzione delle inadempienze
Matrice di transizione

Tabella 1. Rapporti sul monitoraggio delle scorecard

La difficoltà con il monitoraggio del modello è un intervallo di tempo prolungato compreso tra la richiesta di modifica e la sua implementazione. La complessità delle attività per facilitare il processo di monitoraggio per ogni modello in esecuzione nell'ambiente di produzione (Figura 1), incluso il codice per generare i rapporti, l'accesso alle origini dati pertinenti, la gestione dei modelli, i pianificatori dei rapporti, gli avvisi di riduzione delle prestazioni dei modelli e la visualizzazione dei rapporti, che portano ad un processo gravoso e impegnativo. Questa è stata la motivazione principale per cui gli istituti finanziatori esternalizzano la capacità di monitoraggio del modello o investono in un processo automatizzato che faciliti il monitoraggio del modello con minimi sforzi umani.