A Resolução BCB nº 524, que entrou em vigor dia 1º de dezembro de 2025, foi publicada para resolver um problema recorrente em sistemas de pagamento instantâneo: a dificuldade de detectar e bloquear fraudes antes que transações sejam liquidadas de forma irreversível. À medida que o volume de transações PIX cresce e ataques se tornam mais sofisticados, a operação passa a lidar com respostas heterogêneas de provedores e decisões distribuídas ao longo do fluxo transacional. Nesse cenário, manter a integridade operacional deixa de ser um detalhe técnico e passa a ser um requisito fundamental de operação.
O problema central que a resolução expõe não é novo: em sistemas de pagamento instantâneo, a liquidação ocorre em segundos, mas a finalidade — o momento em que uma transação se torna verdadeiramente irreversível — pode levar minutos, horas ou até dias. Essa lacuna entre liquidação e finalidade cria uma janela de exposição ao risco. Durante esse intervalo, transações fraudulentas podem ser executadas, fundos podem ser transferidos e, quando a fraude é finalmente detectada, o prejuízo já está consolidado e rollbacks passam a não existir mais, não sendo possível "consertar" o estado após a liquidação.
O que torna esse problema particularmente complexo é que a percepção do usuário final não reflete a realidade técnica. Para o usuário, a notificação de "pagamento bem-sucedido" sugere que a transação está completa e final. Para a instituição financeira ou de pagamento, no entanto, essa mesma transação está apenas começando seu ciclo de validação e confirmação. Essa divergência entre percepção e realidade é o que a Resolução 524 força as instituições a confrontar.
O problema da janela de exposição ao risco
Em uma arquitetura tradicional, a validação de fraudes ocorre após a liquidação. A transação é iniciada, enviada ao Sistema de Pagamentos Instantâneos (SPI), liquidada e, somente então, submetida a análises de risco, compliance e detecção de fraudes. Esse modelo cria uma janela de exposição que pode durar minutos. Em um ataque coordenado, minutos são suficientes para causar perdas milionárias.
O problema não é apenas o tempo de detecção, mas a dependência de ordem. Quando múltiplos serviços participam da validação — KYC, AML, limites, detecção de fraudes — e cada um opera de forma independente, o resultado final pode variar dependendo da ordem em que os eventos são processados. Se um serviço de detecção de fraudes está temporariamente indisponível ou respondendo com latência elevada, a transação pode ser aprovada por outros serviços e liquidada antes que a fraude seja identificada. Essa falta de determinismo torna o sistema sensível a efeitos de concorrência e diferenças de ordenação.
A Resolução 524 introduz mecanismos que transferem a responsabilidade da detecção e bloqueio de fraudes para as próprias instituições, exigindo uma mudança de uma postura reativa para uma proativa. O artigo 18, inciso III, alínea "b" estabelece a obrigatoriedade de mecanismos próprios para identificar, em tempo real e com base em padrões históricos e comportamentais, movimentações atípicas ou potencialmente fraudulentas na Conta PI, com a capacidade de interromper o processamento de transações em caso de suspeita de comprometimento de sistemas [1].
Aqui temos a introdução de um conceito de análise endógena: Tradicionalmente, as instituições monitoravam as transações de seus clientes (análise exógena). A resolução agora exige o monitoramento da própria Conta PI da instituição (análise endógena). Isso significa que a Conta PI deve ser tratada como um ativo sob risco, com monitoramento constante de padrões de velocity, volume, horário e destinatários.
Ataques que comprometem as credenciais de uma instituição podem não ser detectados por sistemas focados no comportamento do cliente, mas seriam imediatamente visíveis em uma análise endógena da Conta PI.
Por que arquiteturas tradicionais falham
A maioria das instituições financeiras opera com uma arquitetura transaction-first, na qual a transação é processada, registrada no ledger e, posteriormente, submetida a validações de fraude, compliance e limites. Esse modelo apresenta três fragilidades estruturais.
Primeiro, a necessidade de rollbacks. Quando uma fraude é detectada após a liquidação, é necessário reverter a transação no ledger, notificar contrapartes, ajustar saldos e lidar com possíveis inconsistências. Em sistemas de pagamentos instantâneos, onde a irrevogabilidade é uma característica central, rollbacks são especialmente problemáticos. O ledger acaba registrando resultados que refletem mais a ordem acidental dos eventos do que a lógica esperada do produto. Isso gera retrabalho, exceções e esforço contínuo de conciliação.
Segundo, a janela de exposição ao risco. O intervalo entre a execução da transação e a detecção da fraude cria uma janela de oportunidade para atacantes. Em ataques cibernéticos sofisticados, como o registrado em julho de 2025, que resultou em desvios superiores a R$ 813 milhões [2], essa janela pode ser explorada para transferir centenas de milhões antes que controles sejam acionados.
Terceiro, a falta de visibilidade endógena. Sistemas focados na análise exógena (transações do cliente) frequentemente negligenciam padrões anômalos na própria Conta PI da instituição. Ataques que comprometem Prestadores de Serviços de Tecnologia da Informação (PSTIs) ou exploram vulnerabilidades em APIs podem gerar movimentações atípicas que passam despercebidas até que o dano esteja consolidado.
Validation-first: determinismo em sistemas distribuídos
Se a validação pós-liquidação cria janelas de risco e dependência de ordem, a única solução sustentável é validar antes da liquidação. Uma arquitetura validation-first inverte o fluxo tradicional: validações de fraude, compliance e limites ocorrem antes que a transação atinja o ledger. Apenas transações que passam por todos os controles são autorizadas a prosseguir. Esse modelo elimina rollbacks, reduz a janela de exposição ao risco e permite implementar a análise endógena exigida pela Resolução 524.
O conceito central dessa arquitetura é o conjunto entre determinismo e colaboração em cadeia, de modo que faz-se a validação na origem (débito) e espera-se que a contraparte em compliance com a regulamentação realize o mesmo movimento no destino (crédito). Essa característica é essencial para que a operação seja mensurável, auditável e resistente a inconsistências estruturais.
Outro aspecto fundamental é a imutabilidade. Uma vez que uma transação é registrada no ledger, ela não pode ser alterada ou deletada. Isso cria um audit trail completo e à prova de adulteração, facilitando auditorias e investigações de incidentes. A imutabilidade também garante que o ledger seja a fonte única da verdade financeira, sem depender de suposições sobre o comportamento do restante do fluxo.
A previsibilidade é o terceiro pilar. O comportamento do ledger deve ser previsível para os demais componentes da arquitetura. Suas interfaces devem ser estáveis, e o ledger não deve tentar inferir lógicas de negócio e nem compensar falhas upstream. Ele registra o estado financeiro de forma rigorosa, evitando que decisões tomadas em outros serviços se convertam, inadvertidamente, em estados inconsistentes. Essa previsibilidade contribui para reduzir retrabalho e simplifica o papel de validação, risco e reconciliação.
Impacto operacional
O impacto de uma arquitetura validation-first na operação é direto. A operação deixa de tentar "consertar" o estado e passa a se apoiar em uma base consistente. A eliminação de tentativas de rollbacks é o benefício mais imediato.
Transações fraudulentas são bloqueadas antes de atingir o ledger, eliminando a necessidade de reversões complexas e custosas (e que muitas vezes nem são mais possíveis). Isso preserva a integridade contábil e reduz o risco operacional. Em um ataque de velocity, por exemplo, onde um atacante tenta executar 1.000 transações de R$ 10.000 em 5 minutos, a detecção e bloqueio em tempo real (em milissegundos) minimizam a janela de oportunidade.
Após as primeiras transações, soluções como o Tracer da Lerian detectam uma anomalia no padrão e o score de risco das transações subsequentes aumenta drasticamente e ao atingir um threshold de risco, bloqueia-se automaticamente todas as novas transações daquela origem, antes que elas sejam enviadas ao SPI. Nenhuma perda financeira ocorre a partir deste ponto.
A auditabilidade completa é outro benefício crítico. Todas as tentativas de transação, tanto as bem-sucedidas quanto as bloqueadas, são registradas gerando um audit trail completo, incluindo o score de risco e a justificativa do bloqueio. Isso facilita a demonstração de conformidade em auditorias e processos sancionadores, reduzindo o risco de penalidades.
A redução de retrabalho é talvez o benefício menos visível, mas mais impactante no longo prazo. Quando se tem uma operação com um ledger determinístico e imutável aliado a soluções que se acoplam nele seguindo os mesmos parâmetros para garantir a integridade do fluxo, a equipe de operações não precisa gastar tempo reconciliando estados divergentes, investigando exceções ou corrigindo inconsistências. O tempo que seria gasto em retrabalho pode ser redirecionado para melhorias de produto, otimização de processos e inovação.
Conclusão
A Resolução BCB 524 expõe um problema fundamental em sistemas de pagamento instantâneo: a lacuna entre liquidação e finalidade cria uma janela de exposição ao risco que não pode ser resolvida com validação pós-liquidação. Em operações que procuram manter escala com governança, uma arquitetura validation-first não é apenas desejável: é essencial.
O objetivo de uma arquitetura validation-first não é ser "mais moderna", mas manter coerência mesmo quando todo o restante do sistema está sujeito a variações naturais de um ambiente distribuído. Ela foi projetada para ser a fonte de verdade financeira sem se tornar um gargalo e sem exigir suposições sobre o comportamento do restante do fluxo.