Um banco é, por definição, uma “organização monetária”, e seu futuro depende do sucesso com que essa organização emite e paga empréstimos. Para trabalhar com empréstimos com sucesso, você precisa entender a situação financeira dos mutuários, que é auxiliada por fatores de risco de crédito (FKR). Os analistas de crédito os identificam em grandes quantidades de informações bancárias, processam esses fatores e prevêem novas mudanças. Normalmente, análises descritivas e de diagnóstico são usadas para isso, mas decidimos conectar as ferramentas de aprendizado de máquina ao trabalho. Leia sobre o que aconteceu no post.
Alguns fatores de risco de crédito estão à superfície, enquanto outros precisam ser pesquisados profundamente nas entranhas dos dados bancários. Alterações na taxa de câmbio do dólar, receita do cliente, carga da dívida, queda nas vendas e classificações, tribunais, processos criminais, fusões e aquisições - tudo isso fornece um sinal estatístico de diferentes pontos fortes. Para compor corretamente a imagem geral do mutuário, é necessário não apenas captar todos os sinais associados, mas também avaliar sua força.
A análise descritiva e de diagnóstico funcionou bem ao trabalhar com a FCR, mas, no entanto, esses métodos não apresentam desvantagens. O uso da análise é limitado aos reguladores - nem todos os métodos e modelos avançados podem ser aprovados por eles. O Analytics não é flexível e não oferece a oportunidade de apresentar dados em uma fatia arbitrária - e isso geralmente é muito necessário. E com a eficiência nesse caso, nem tudo é ótimo. E também acontece que, para alguns modelos analíticos, simplesmente não há dados suficientes.
Por que não tentar o aprendizado de máquina para esses fins? Portanto, é perfeitamente possível melhorar o cálculo da significância dos fatores de risco de crédito, em termos técnicos - para aumentar em vários pontos percentuais o indicador Gini, pelo qual avaliamos a precisão dos modelos de previsão. Quanto melhor o cálculo do FKR, mais precisa é a avaliação da condição financeira dos clientes - maior a qualidade da carteira de empréstimos do banco. E quanto menor a proporção de trabalho manual.
Progresso do projeto
O Cloudera Hadoop foi escolhido para armazenar big data, o Apache Spark e o Apache Hive SQL foram implantados para acessar dados brutos, e o Apache Oozie foi usado para coordenar e iniciar o carregamento e cálculo dos fluxos de dados. Usando o Apache, o Zeppelin e o JupyterHub visualizaram e exploraram os dados. Além disso, eles usaram várias bibliotecas de aprendizado de máquina que suportam processamento paralelo - Spark MLIB, PySpark e H20.
Sete nós foram alocados para tudo isso:
- 3 nós principais com vRAM de 64 GB e 2 TB de espaço em disco cada
- 3 nós de dados com 512 GB de vRAM e 8 TB cada
- 1 nó para aplicativos com vRAM de 128 GB, 2,5 TB
O projeto inteiro levou três meses e consistiu em três etapas de demonstração, quatro sprints semanais em cada uma. Para o cálculo, 22 fatores de risco de crédito foram escolhidos durante o projeto.
No primeiro estágio, implantamos a infraestrutura e conectamos as primeiras fontes de dados:
- Armazenamento de informações corporativas (FIR) - o principal armazenamento do banco. Para operar livremente com dados no Data Lake e não criar uma carga nos sistemas de produção, nós os carregamos de fato como um todo.
- O sistema de cálculo de classificação () é um dos principais bancos de dados para avaliação de riscos associados às atividades de clientes corporativos. Ele contém informações sobre classificações de empresas, indicadores de demonstrações financeiras.
- Dados de fontes externas refletindo afiliação e outros critérios.
- Arquivos separados contendo informações e dados adicionais para o trabalho dos cientistas de dados.
No segundo estágio, o primeiro PCF foi calculado, tentamos construir modelos com base nesses indicadores, instalamos uma ferramenta de BI e discutimos como visualizar a dinâmica do PCF. Como resultado, decidimos preservar a estrutura familiar da planilha do Excel na nova ferramenta, deixando a visualização avançada para o futuro.
E, finalmente, na fase final, baixamos todos os dados ausentes, inclusive de uma fonte externa. O banco temia que sua significância estatística fosse pequena, por isso realizamos testes estatísticos que provaram o contrário. A demonstração final demonstrou a operação de ferramentas de ciência de dados, BI, carregamento regular e atualização de dados. Dos 22 fatores, apenas dois não foram calculados dentro do piloto, devido a razões externas - a falta de dados da qualidade exigida.
Resultado
O cluster no Hadoop é facilmente escalável e permite que os modelos alimentem mais dados, e eles podem executar cálculos em paralelo. O indicador Gini cresceu - os modelos previram com mais precisão certos eventos relacionados a fatores de risco de crédito.
Antes, nossos analistas precisavam entrar em contato com o departamento de TI para gravar consultas SQL no repositório corporativo e depois processar os modelos em seus computadores pessoais. E agora, o cluster piloto permite que os analistas escrevam consultas por conta própria, ou seja, aumentar os dados brutos e os modelos de processamento é muito mais rápido.
Planos
Este ano, continuaremos o desenvolvimento do projeto. Implementaremos a infraestrutura do Data Lake em equipamentos especializados para aumentar a velocidade de amostragem e processamento. Organizamos com base no "lago" um recurso único e centralizado para análise de crédito. Adicione mais algumas fontes de dados e conecte novas bibliotecas de aprendizado de máquina.
Outras divisões do banco se interessaram pelo nosso projeto - CRM, auditoria interna (busca de fraudadores, identificação de transações suspeitas), suporte operacional (antifraude), analistas do setor. Ao usar a "caixa de proteção", damos a eles nossos desenvolvimentos, eles terão acesso fácil aos dados, a capacidade de conectar quaisquer fontes de dados e experimentar usando modelos de aprendizado de máquina.