Compensar não é economizar: o que um simulador aberto mostra sobre a liquidez do Pix

No Pix, cada pagamento é liquidado sozinho, na hora. Para isso, o banco de quem paga precisa ter saldo no Banco Central antes de cada transferência, a qualquer hora do dia ou da noite. Nos sistemas antigos, os bancos acumulavam pagamentos e compensavam entradas com saídas, o chamado netting, e precisavam de muito menos dinheiro parado.

Um estudo do próprio Banco Central (Working Paper 619) mostrou que, com o Pix, os bancos perderam essa capacidade de adiar e compensar, e passaram a reter mais ativos líquidos. Olhando os números de um dia qualquer, parece que quase tudo poderia ser compensado: o que um banco paga é parecido com o que ele recebe. Daí nasce uma ideia tentadora: segurar os pagamentos por alguns segundos, achar os que formam um ciclo (A paga B, B paga C, C paga A) e liquidar o ciclo de uma vez. O cliente quase não percebe e o banco economiza liquidez.

Eu quis medir quanto dessa ideia vira dinheiro de verdade. Para isso construí o LoopSettle, um simulador aberto de liquidez em pagamentos instantâneos. Este artigo conta o que ele mostrou, inclusive a parte que derrubou a minha própria hipótese.

O que eu construí

O LoopSettle gera um dia sintético de pagamentos entre 200 instituições, com bancos grandes, médios, fintechs e instituições de pagamento, calibrado com os dados abertos do Pix publicados pelo BCB: volume, ticket médio, concentração por participante e o perfil de cada hora do dia. Depois liquida o mesmo fluxo em vários desenhos de sistema e compara quanto dinheiro cada um exige:

• bruto em tempo real, como o Pix;
• compensação diferida, de 10 em 10 segundos até uma vez por dia;
• micro-ciclos atômicos: a cada janela curta, o motor procura ciclos na fila e liquida cada ciclo inteiro ou nada, com um limite de espera por pagamento.

O núcleo é escrito em Rust, roda em streaming (um milhão de pagamentos usa poucos megabytes de memória) e também compila para WebAssembly: há uma interface que roda inteira no navegador. Tudo foi pensado para caber num notebook com processador i3 de 4ª geração e 4 GB de RAM.

Só uso dados públicos e sintéticos. O LoopSettle é um projeto independente, sem relação com o Banco Central e sem endosso dele; Pix é marca do BCB.

O resultado: compensar não é economizar

Com o cenário calibrado, 10 sementes e de 1 a 30 milhões de pagamentos por dia:

• pela medida "potencial", aquela que compara entradas e saídas do dia sem olhar a ordem no tempo, 85% do volume parece compensável;
• micro-ciclos de até 10 segundos chegam a liquidar 63% do valor dentro de ciclos, mas economizam cerca de 0,01% da liquidez (0,0116%, com intervalo de confiança de 95% entre 0,008% e 0,015%);
• compensar uma vez por dia economiza mais, mas esse ganho encolhe quando o volume cresce. Com 30 milhões de pagamentos por dia e a estrutura entre bancos ajustada a dados reais do WP 619, fica entre 0,2% e 2,8%, conforme o quanto os bancos têm horários diferentes entre si.

Ou seja: volume compensável e liquidez economizada são coisas diferentes, e a distância entre as duas é enorme.

Por que a conta não fecha: o teto

A liquidez que um banco precisa é definida pelo pior momento do dia dele: o ponto em que ele pagou muito mais do que recebeu. Um mecanismo que segura cada pagamento por no máximo d segundos só consegue mexer nos pagamentos que chegaram nos d segundos antes desse pico. Tudo o que aconteceu antes já foi liquidado e não volta.

Daí sai um teto que vale para qualquer algoritmo, por mais esperto que seja: a economia de cada banco é no máximo o valor que ele pagou nos d segundos antes do seu pior momento. No cenário calibrado, com 10 segundos, esse teto fica abaixo de 1% da liquidez em todas as configurações testadas, e o que os micro-ciclos realmente conseguem é uma fração pequena e estável dele, de 3% a 5%. O teto responde à objeção mais comum ("talvez um algoritmo melhor economize mais"): não economiza, porque o limite não depende do algoritmo.

Onde a ideia funciona

O mesmo teto explica por que reordenar pagamentos dá resultado em sistemas de alto valor. Lá há poucos pagamentos, e enormes. O trabalho mais próximo do LoopSettle, de McMahon e coautores com o Banco do Canadá, usou dados reais do sistema canadense de alto valor: reordenar lotes de 70 pagamentos, com cerca de 90 segundos de espera, economizou em média 240 milhões de dólares canadenses por dia contra a ordem de chegada. Pela minha conta, isso é da ordem de 1% a 2% da liquidez que os bancos alocam. No LoopSettle, um cenário estilizado de alto valor tem teto de 13,7% com 10 segundos, contra 0,76% no varejo. A diferença está no formato do fluxo, não no algoritmo.

A restrição que importa é o fim de semana

A conta que os bancos usam no Pix só recebe recursos com o sistema de reservas aberto, em dias úteis, das 6h30 às 18h30. Então os bancos precisam deixar dinheiro separado para as noites e para as 59,5 horas do fim de semana. No simulador, essa reserva fica em torno de 2,7 vezes o pico de um dia útil. Mesmo aí, compensar tudo no fim do fim de semana economizaria só de 0,4% a 1,0%. A necessidade vem do saldo que se acumula numa direção, não de dinheiro dando voltas.

O que o estudo não diz

• Os dados são sintéticos, calibrados com agregados públicos. Quem paga a quem, em detalhe, não é público e continua sendo a principal hipótese do modelo.
• A escala é reduzida: cada pagamento simulado faz o papel de cerca de 239 pagamentos reais. As frações são o resultado; os valores absolutos não valem para o Pix real.
• A dúvida que sobra (0,2% ou 2,8%) só se resolve com dados por participante ao longo do dia, que só o Banco Central tem.

O que aprendi como engenheiro

Trabalho com qualidade de software, e o projeto foi construído como eu gostaria que um sistema financeiro fosse testado:

• Invariantes primeiro. Oito regras que nunca podem quebrar, como "o dinheiro total não muda", "nenhum saldo fica negativo" e "um ciclo liquida inteiro ou não liquida", são testadas por testes baseados em propriedades, com milhares de casos aleatórios a cada execução.
• Reprodutibilidade total. Cada número sai de um comando com semente fixa e é reproduzido byte a byte; a versão do código fica gravada junto com o resultado.
• Critérios de morte escritos antes. Antes de rodar os testes de robustez, anotei o que derrubaria o resultado. Um deles derrubou a minha manchete preferida: a primeira versão dizia que o potencial era 630 vezes maior que o realizável, mas esse potencial encolhe com o volume. A manchete saiu, e o resultado que ficou é mais forte porque sobreviveu.

Teste nos seus dados

Quem tiver arquivos de pagamentos (um banco, uma fintech, um banco central) pode rodar o LoopSettle sem que os dados saiam da máquina: o arquivo é lido em streaming e a saída tem só agregados. O comando loopsettle bound pagamentos.csv calcula a liquidez necessária e o teto de economia para cada tempo de espera.

O código é aberto (Apache-2.0), com documentação em português e inglês, guia de instalação do zero e todos os resultados. O próximo passo é o artigo científico. Críticas e dados para testar o teto são muito bem-vindos.

• Repositório do LoopSettle no GitHub
• Resumo de todos os resultados
• O que o estudo pode e não pode afirmar