Em termos simples — Uma ideia e um modelo podem estar corretos, mas a operação ainda pode falhar por erro humano, sistema indisponível, processo incompleto ou fornecedor interrompido.
O risco operacional nasce de processos, pessoas, sistemas ou eventos externos inadequados ou falhos. Inclui risco jurídico em definições prudenciais, mas não deve ser confundido automaticamente com risco estratégico ou sistêmico.
Eventos e causas
Exemplos incluem ordem duplicada, dado incorreto, permissão excessiva, reconciliação ausente, indisponibilidade, ataque cibernético, falha de terceiro e processo de liquidação quebrado. A perda visível pode ser financeira, jurídica ou operacional; a causa raiz pode combinar vários elementos.
Do controle à resiliência
Mapeie serviços críticos, responsáveis, sistemas, dados e terceiros. Defina tolerância à interrupção. Aplique segregação de funções, limites, reconciliações, logs e mudanças controladas. Teste continuidade, canais alternativos, restauração e comunicação.
Resiliência não significa impedir toda falha. Significa manter ou recuperar o serviço dentro de um impacto tolerado. Um plano não testado e dependente das mesmas pessoas ou instalações do processo principal pode falhar junto com ele.
Aprendizado e governança
Incidentes e quase-erros devem registrar linha do tempo, impacto, causa, controle que falhou e ação corretiva. Indicadores de risco só ajudam se houver gatilho, proprietário e resposta. Terceirizar uma função não transfere integralmente a responsabilidade.
Controles preventivos e detectivos
Validação de entrada, limites e segregação reduzem a chance de erro; reconciliação, alertas e revisão independente ajudam a detectá-lo. Um controle precisa indicar qual falha cobre e qual evidência deixa. Muitos passos manuais sem prioridade podem aumentar, em vez de reduzir, a fragilidade.
Terceiros e concentração
Broker, provedor de dados, nuvem, telecomunicação e custodiante podem participar do mesmo serviço crítico. Dois fornecedores não criam redundância se dependem da mesma infraestrutura. Contratos, rotas alternativas, acesso a dados e testes conjuntos devem refletir essas dependências.
Após a recuperação, posições, caixa e registros precisam ser reconciliados. Retomar a tela não prova que ordens, confirmações e liquidações estejam corretas.
Fontes
- Basel Committee, Operational risk — OPE10.
- Basel Committee, Principles for operational resilience.
- Basel Committee, Revisions to the principles for sound management of operational risk.
- FINRA, Rule 4370 — Business Continuity Plans and Emergency Contact Information.
- IOSCO, Mechanisms for Trading Venues to Effectively Manage Electronic Trading Risks and Plans for Business Continuity.
- IOSCO, Cyber Security in Securities Markets.