O Risco Operacional Pode Ser Causado Por

Entendendo as origens do risco operacional na prática

Quando se entra em uma sala de Risk e olha para os frameworks que as bancos montaram, a primeira coisa que nota é que o risco operacional não surge de um único ponto. Ele aparece onde menos se espera. A definição da Basileia é ampla: perdas resultantes de processos inadequados, pessoas, sistemas ou eventos externos. Mas a teoria e a realidade operam em tempos diferentes. O fator mais frequente, na minha experiência, são erros humanos em processos que parecem triviais. Eu trabalhei em uma implantação de reconciliação automática entre o sistema core e a plataforma de compensação de uma financeira. O processo parecia trivial: extrair, transformar, comparar, reportar. O problema foi que ninguém previu o caso de títulos emitidos com vencimento em feriados estaduais diferentes. Em São Paulo, o título compensava no dia útil seguinte; no Nordeste, o vencimento real era outro. O sistema de reconciliação não distinguia e gerava divergências crônicas. Gostaríamos de apontar isso como um bug técnico, mas o problema era de governança: ninguém revisou a regra de negócio antes de homologar. O que vejo repetidamente em auditorias internas é que as equipes de risco operacional tendem a concentrar a análise em fraudes externas e defeitos de sistema, enquanto negligenciam o que eu chamaria de risco de conformidade processual silencioso. É aquele tipo de desvio que acontece quando um procedure é atualizado, mas a execução continua no modelo antigo. Funciona assim: a política mudou em janeiro, o manual foi publicado, mas a equipe de back-office manteve a rotina de confirmação por e-mail porque a nova ferramenta de assinatura digital apresentava instabilidade. Isso aconteceu comigo e causou uma lacuna de rastreabilidade que durou oito meses. Quando o problema foi detectado, já tínhamos 47 contratos sem confirmação válida assinada, expostos a contestações judiciais. A correção levou onze dias e exigiu uma amostragem retroativa em lote.

Mecanismos de causação e a armadilha da subnotificação

Um ponto que poucos consideram é que a maioria dos eventos de risco operacional nunca é registrada. Em uma instituição onde fiz diagnóstico, estimamos que apenas 30 por cento dos eventos se materializavam nos registros formais. O restante persistia como perda operativa silenciosa, absorvida por provisão geral sem sinalização. Isso distorce toda a modelagem de capital, porque o modelo Advanced Measurement Approach (AMA), quando aplicável, depende da frequência e severidade observadas. Se os dados são incompletos, a alocação de capital fica desbalanceada. Os principais vetores de causação que eu recomendo mapear são: Falhas de processo: Quando o procedimento não reflete a realidade operacional ou quando há sobreposição de etapas entre áreas. Isso gera pontos cegos de aprovação e duplicidade de execução. Na prática, um fluxo de aprovação de crédito que atravessa três departamentos sem um responsável único gera retrabalho e, mais grave, ausência de Accountability.

Deficiências em sistemas e tecnologia: Integrações mal testadas, logs insuficientes, versionamento inadequado de contratos em bases de dados. Um exemplo concreto que lidei foi a falta de controle de versão em scripts de ETL usados para geração de relatórios regulatorios. Duas versões coexistiam simultaneamente, produzindo números diferentes para a mesma base. A divergência só apareceu quando o regulator solicitou explicação sobre um gap de 1,7 ponto percentual em exposições classificadas como inadimplentes. Pessoas e governança: Rotatividade elevada em funções críticas sem programa estruturado de knowledge transfer. Eu vi uma instituição perder a capacidade de responder a uma solicitação do Bacen porque a única pessoa que dominava o mapeamento de dados sensíveis saiu sem documentar o procedimento. A resposta foi enviada com quatro dias de atraso e com informações parcialmente desatualizadas. Esse é o tipo de evento que a literatura chama de risco de pessoa-chave, mas que raramente é quantificado nos painéis de direção. Eventos externos: Fraude de terceiros, desastres naturais, interrupções de fornecedores críticos. A pandemia de 2020 foi um stress test não solicitado que expôs fragilidades em muitos bancos. Instituições que não tinham plano de continuidade operacional documentado enfrentaram colapso na prestação de serviços por duas semanas. As que já possuíam runbooks atualizados e mirror sites conseguiram manter 95 por cento das operações em menos de 72 horas.

Como construir um mapeamento útil de causas

O método que costumo recomendar começa com a construção de um Loss Data Collection Framework baseado em categorias padronizadas. O setor financeiro no Brasil adota comumente a classificação do Bacen, que agrupa eventos em sete categorias: fraude interna, fraude externa, clientes, produtos e práticas de negócio, execução e gerenciamento de processos, danos a ativos físicos, e interrupções de negócios e falhas tecnológicas. A utilidade prática dessas categorias só aparece quando elas são vinculadas a causas-raiz específicas, não quando são usadas como caixas de classificação genéricas. Para cada evento registrado, o mapeamento deve conter: — Causa primária identificada, com nível de detalhe suficiente para permitir ação corretiva.

— Controle que falhou ou não existia. — Impacto quantitativo real, incluindo custo de recuperação e dano reputacional quando mensurável. — Tempo até a detecção, porque esse indicador revela a eficácia dos seus GRC (Governance, Risk and Compliance).

Em uma análise que conduzi para um banco de médio porte, mapeamos 213 eventos de risco operacional registrados em doze meses. O resultado mais relevante foi que 68 por cento das causas raiz estavam concentrados em dois controles: aprovação de mudanças em sistemas e gestão de senhas e acessos. A solução não foi implementar um novo software de GRC. Foi revisar o processo de Change Management, aplicar o princípio do menor privilégio de forma consistente e instituir uma revisão trimestral de acessos por função. Isso reduziu em 42 por cento os eventos no trimestre seguinte.

Limitações que precisam ser reconhecidas

O risco operacional não se comporta de forma estacionária. Modelos históricos perdem validade rapidamente em ambientes de mudança regulatória acelerada. O que funcionou como medida de contingência em 2022 pode ser irrelevante em 2025, especialmente com a transição global do AMA para o Novo Padrão de Basileia (Standardized Approach for Operational Risk). A nova estrutura elimina a dependência de dados históricos de perda e adota um fórmula baseada em indicadores internos e externos padronizados. A transição exige que as instituições reformulem todo o histórico de mapeamento, porque os indicadores do novo framework não são diretamente comparáveis com os utilizados no AMA. Além disso, mapear causas não elimina o risco. Mapear permite priorizar. A armadilha comum é tratar o exercício de identificação como solução, quando na verdade é apenas o primeiro passo. A eficácia real depende da capacidade de implementar controles que reduzam a probabilidade ou o impacto, e de monitorar se esses controles estão funcionando conforme projetado. Sem esse ciclo fechado, o mapeamento vira documentação morta, algo que eu vejo com frequência em auditorias. Recomendo complementar o mapeamento tradicional com cenários hipotéticos construídos a partir de eventos similares em outras instituições. O exercício de scenario analysis, embora subjetivo, permite antecipar causas que ainda não geraram perda registrada mas que têm alta probabilidade de se materializar. Eu utilizei esse approach para antecipar um evento de fraude por engenharia social contra a equipe de tesouraria. Dois meses depois, um golpe semelhante atingiu uma instituição concorrente, causando prejuízo de R$ 2,3 milhões. Nossa resposta imediata às recomendações do cenário reduziu a exposição e permitiu que o evento não se concretizasse. Esse é o valor real do mapeamento de causas: não apenas registrar o passado, mas reduzir a janela de vulnerabilidade presente.