Em termos simples — Um modelo pode calcular exatamente o que foi programado e ainda assim produzir uma decisão ruim porque os dados, as premissas ou o uso não correspondem ao problema real.
O risco de modelo é a possibilidade de consequências adversas ao tomar decisões com base em uma saída incorreta ou mal utilizada. Erro de código é apenas uma causa possível.
Onde nasce
Dados podem estar incompletos, atrasados ou contaminados. Premissas podem falhar fora da amostra. A implementação pode divergir da especificação. Usuários podem aplicar o modelo a produtos, horizontes ou regimes para os quais ele não foi desenhado. Mudanças posteriores podem ocorrer sem nova validação.
Ciclo de controle
O processo começa com finalidade, proprietário e materialidade. Seguem documentação, testes de dados, desenvolvimento, implementação e validação independente. A aprovação deve impor limites de uso. Depois entram monitoramento, backtesting, análise de exceções, controle de mudanças e retirada.
Uma validação útil desafia teoria, dados, código e resultados; compara alternativas e verifica sensibilidade. Em modelos de terceiros, a falta de acesso interno não elimina a obrigação de compreender finalidade, entradas e limitações.
Saídas e decisão
VaR, ES e cenários devem mostrar versão, data dos dados, incerteza e exceções. Overrides precisam de justificativa e trilha. Quando o modelo não representa um risco material, limites adicionais ou ajustes conservadores podem ser necessários.
Nenhum selo de validação é permanente. Mudança de mercado, produto, dados ou uso pode reabrir o risco mesmo sem alteração no código.
Materialidade e proporcionalidade
Nem todo cálculo requer o mesmo grau de governança. A intensidade do controle depende do impacto potencial, do número de decisões afetadas e da dificuldade de detectar erro. Uma planilha simples usada para uma posição grande pode ser mais material que um sistema sofisticado empregado apenas para pesquisa.
O inventário deve incluir modelos internos, fornecedores, planilhas e ajustes manuais materiais. Cada item precisa de finalidade, versão, proprietário, usuários e dependências. Componentes reutilizados por vários processos criam concentração: uma falha pode aparecer simultaneamente em preço, risco e relatório.
Evidência de validação
Resultados de teste, problemas abertos, limites de uso e remediações precisam permanecer acessíveis. Aprovar com ressalvas é diferente de validar sem restrições. Quando o problema não pode ser corrigido imediatamente, o controle pode reduzir o perímetro, impor buffer ou exigir revisão manual documentada.
Fontes
- Federal Reserve, SR 26-2: Guidance on Model Risk Management.
- Federal Reserve, Attachment to SR 26-2.