Como processadoras modernas traduzem milhões de mensagens ISO 8583 em registros contábeis confiáveis, e por que o ledger é a peça que faltava nessa equação.
Quando você aproxima seu cartão de uma maquininha, uma dança técnica complexa e invisível acontece em milissegundos. Em menos tempo do que uma piscada de olhos, uma mensagem viaja do terminal para a adquirente, atravessa a rede da bandeira, chega a uma processadora, consulta um emissor e retorna com uma decisão: aprovado ou negado.
Essa coreografia, repetida milhões de vezes por dia no Brasil, sustenta o comércio moderno. As processadoras são o cérebro invisível por trás dessa operação, orquestrando um fluxo de informações que precisa ser não apenas ultrarrápido, mas, acima de tudo, infalivelmente confiável.
O desafio fundamental de uma processadora é duplo. Primeiro, traduzir a linguagem esotérica das bandeiras, o padrão ISO 8583, em decisões de negócio instantâneas. Segundo, garantir que cada uma dessas decisões se transforme em um registro contábil à prova de falhas. Historicamente, a indústria focou massivamente no primeiro desafio, construindo sistemas de mensageria altamente otimizados. Contudo, o registro contábil foi frequentemente tratado como um sistema auxiliar, uma consequência da transação e não sua fundação.
Este artigo argumenta que essa visão é uma das principais fontes de complexidade e risco em infraestruturas de pagamento. O ledger não é um apêndice; ele é a fonte da verdade, a fundação da confiabilidade. Processadoras modernas precisam de uma nova geração de ledgers, projetados para entender a natureza temporal e multiestágio das transações de cartão, garantindo consistência e auditabilidade do início ao fim.
O Fluxo Invisível de uma Transação de Cartão
Para entender a necessidade de um ledger especializado, primeiro precisamos desmistificar o fluxo de uma transação. Embora pareça um evento único, uma compra no cartão é uma sequência de passos em que a processadora atua como um dos principais nós de comunicação e decisão.
No coração desse fluxo está a linguagem universal das bandeiras: o padrão ISO 8583. Diferente de APIs modernas baseadas em JSON, trata-se de um padrão binário e posicional. Uma mensagem de autorização de compra (0100), por exemplo, não é autodescritiva; ela consiste em uma sequência de bytes na qual posição e tamanho de cada campo são previamente definidos.
Anatomia de uma mensagem ISO 8583 (simplificada)
MTI (Message Type Indicator)
0100 indica uma requisição de autorização.
Bitmap primário
Campo de 8 bytes que indica quais dos primeiros 64 Data Elements estão presentes.
Data Elements (DEs)
Campos de dados propriamente ditos, como:
- DE2 (PAN): número do cartão
- DE4 (Transaction Amount): valor da compra
- DE41 (Terminal ID): identificação da maquininha
Durante a autorização, a processadora interpreta essa estrutura, executa validações críticas em menos de 100 milissegundos e encaminha a solicitação de autorização ao emissor, que decide aprovar ou negar a transação. Esse fluxo reforça que a decisão financeira está no emissor e não em uma simples consulta direta de saldo.
O Ciclo de Vida Contábil de uma Transação
Validar e aprovar uma transação é apenas metade da história. O verdadeiro desafio começa quando essa aprovação precisa se transformar em um registro contábil confiável. Uma transação de cartão não é um evento atômico, mas uma sequência temporal de estados que podem durar dias ou meses.
Autorização (Base I)
No momento da compra ocorre uma reserva de limite, não uma movimentação financeira efetiva. O ledger registra um hold no saldo do cliente, garantindo que aquele valor não seja gasto novamente. É um estado transitório e reversível.
Clearing (Base II)
As adquirentes enviam um arquivo contendo todas as transações capturadas, que são consolidados e processados pelas bandeiras e repassadas às processadoras dos emissores. É nesse momento que a transação se torna um compromisso financeiro real. O hold no ledger precisa ser convertido em um débito efetivo na conta do cliente.
Settlement (Liquidação)
Cerca de dois dias após a transação (D+2), ocorre a liquidação financeira entre adquirente e emissor através do SPB. O ledger registra essa movimentação interbancária para fechar o ciclo.
O cenário se complica com exceções. Timeouts podem exigir reversões confiáveis de holds. Chargebacks podem surgir meses depois. Ledgers genéricos, que tratam cada operação como evento isolado, não foram projetados para essa complexidade. A fragmentação entre sistemas de autorização, contabilidade e liquidação frequentemente gera inconsistências e trilhas de auditoria incompletas.
Arquitetura de Ledger para Processamento de Cartões
A arquitetura tradicional de banco de dados não atende plenamente aos requisitos de uma processadora moderna. Um ledger especializado precisa considerar latência, concorrência e auditabilidade desde a concepção.
Principais princípios arquiteturais:
Double-entry nativo
Cada transação gera um par de lançamentos balanceados (débito e crédito), garantindo consistência matemática permanente.
CQRS (Command Query Responsibility Segregation)
Separação entre escrita e leitura. Escritas ocorrem em log append-only otimizado; consultas utilizam visões materializadas de alta performance.
Event sourcing
Cada mudança de estado é registrada como evento imutável, criando trilha completa de auditoria e facilitando reconciliação e compliance.
Essa abordagem permite modelos como autorização baseada em infraestrutura desacoplada, mantendo o ledger como fonte única da verdade sem confundir o papel decisório do emissor na autorização.
A Abordagem Lerian: Midaz como Ledger para Processadoras
Esses requisitos não são teóricos; eles emergem da realidade operacional de processadoras que lidam com milhões de transações diárias. E foi exatamente esse cenário que motivou a criação do Midaz, o ledger de código aberto da Lerian, projetado para ser a fundação de infraestruturas financeiras de alta performance.
Sua arquitetura baseada em PostgreSQL e mensageria assíncrona implementa CQRS e event sourcing, possibilitando consultas de saldo com latência inferior a 50ms. O controle de concorrência utiliza versionamento de saldos (optimistic locking), prevenindo double spending sem degradação de performance.
Transações complexas podem ser registradas como operações contábeis atômicas e consistentes. A capacidade multi-asset permite operar moedas, pontos ou cashback no mesmo sistema. O log append-only garante auditabilidade e simplifica compliance.
Integrar o Midaz significa transformar o ledger de um banco de dados genérico para um sistema contábil especializado, melhor preparado para suportar escala, regulação e complexidade operacional.
O fato de o Midaz ser 100% código aberto é um diferencial estratégico. Ele elimina o vendor lock-in de soluções proprietárias, permite auditoria completa do código-fonte e oferece a flexibilidade para customizar a lógica contábil para casos de uso específicos, algo impensável em plataformas de BaaS (Banking as a Service) que operam como caixas-pretas.
Conclusão
Processar transações de cartão vai muito além da mensageria. Trata-se de contabilidade distribuída em tempo real. A arquitetura invisível por trás de cada transação bem-sucedida é complexa, mas não precisa ser opaca.
Tratar o ledger como sistema auxiliar gera complexidade, conciliações manuais e falta de visibilidade. Processadoras e fintechs modernas precisam de uma fundação contábil que compreenda a natureza temporal, concorrente e auditável das transações financeiras.
Adotar um ledger moderno e de código aberto como o Midaz permite construir infraestruturas mais rápidas, resilientes e transparentes, estabelecendo uma base confiável para o futuro das finanças digitais.
Sobre o Midaz
O Midaz é um ledger de código aberto desenvolvido pela Lerian para ser a fundação de infraestruturas financeiras modernas. Com suporte nativo a double-entry, CQRS, event sourcing e multi-asset, foi projetado para atender requisitos de latência, concorrência e auditabilidade de processadoras, fintechs e plataformas de pagamento.