O Pix Fala uma Língua que Seu Core Bank Não Entende: Por que Você Precisa de um Intérprete (Anti-Corruption Layer)

O ACL é o diplomata que impede a guerra entre dois domínios que nunca deveriam se conhecer tão de perto.

Pra quem usa, é um toque e pronto. Pra quem constrói, é conciliar um protocolo de liquidação em tempo real, irrevogável, regulado pelo Banco Central, com um núcleo bancário que muitas vezes ainda pensa em lote, em ledger contábil, e às vezes nem tem autonomia total sobre a própria arquitetura. Este artigo é sobre o tradutor que existe entre esses dois mundos — e por que ele não é opcional.

Existem dois países vizinhos. Um é jovem, fala uma língua nova, padronizada, criada em comitê, com gramática rígida e sem exceções — tudo precisa ser dito de um jeito específico, ou a mensagem simplesmente não é aceita na fronteira. O outro é antigo, tem séculos de tratados, dialetos regionais, expressões que só fazem sentido se você souber a história por trás delas. Os dois precisam negociar dinheiro entre si, todos os dias, milhões de vezes por dia, em menos de dez segundos por negociação. Essa é a situação de qualquer banco que precisa fazer o Pix conversar com o seu core bancário.

Pix parece simples — até você olhar por trás do app

Em termos simples

Pro usuário, Pix é abrir o app, apontar a câmera ou colar uma chave, confirmar, e pronto — o dinheiro já está do outro lado. Essa experiência de dez segundos é, de propósito, projetada para esconder toda a complexidade que ela carrega por trás.

Pra entender o Pix, primeiro lembre da TED

Se você tem mais de trinta anos, provavelmente já viveu isso: precisar mandar dinheiro pra alguém numa sexta-feira à tarde e torcer para o relógio cooperar. Antes do Pix existir, a TED — Transferência Eletrônica Disponível, criada em 2002 — era basicamente a única forma de mandar dinheiro entre bancos diferentes de forma eletrônica. E a TED, para quem não lembra mais ou nunca precisou lidar com ela, tinha um detalhe brutal: ela tinha hora para fechar.

Feita até por volta das 17h (no horário de Brasília, variando um pouco por instituição), o dinheiro chegava no mesmo dia útil — às vezes em minutos, às vezes em algumas horas. Passou desse horário, mesmo que fosse 17h01? A transferência ficava “engavetada” até o próximo dia útil. Numa sexta à tarde, isso significava esperar até segunda-feira. Um profissional autônomo que recebia o pagamento de um cliente numa sexta de manhã, mas cujo cliente só conseguia fazer a transferência à noite, simplesmente não via aquele dinheiro até a semana seguinte — mesmo o dinheiro já “existindo”, já tendo saído da conta de alguém.

Por que errar uma letra desfazia a transferência inteira

Tinha outro problema, tão irritante quanto o horário: para fazer uma TED, era preciso informar banco, agência, conta e CPF ou CNPJ do destinatário — e, em muitos casos, o nome precisava bater exatamente com o que o banco de destino tinha cadastrado. Não existia nenhum tipo de “atalho”: nenhuma chave curta, nenhum QR code, nenhum diretório central que resolvesse quem era quem. Bastava errar um dígito da agência, ou digitar o nome com uma abreviação diferente da que o banco de destino esperava, para a transferência ser recusada e devolvida — e o processo inteiro precisava recomeçar do zero, muitas vezes horas depois, arriscando cair fora da janela das 17h de novo.

A tecnologia por trás da TED — e por que ela tinha hora pra fechar

A TED era processada pelo STR — Sistema de Transferência de Reservas, a infraestrutura de liquidação do próprio Banco Central — ou, para valores menores, pela infraestrutura da CIP (Câmara Interbancária de Pagamentos), através de um sistema chamado SITRAF. O detalhe importante aqui: tanto o STR quanto o SITRAF foram desenhados para operar dentro de uma janela de expediente bancário — o SITRAF, por exemplo, funcionava historicamente só entre 6h30 e 17h, em dias úteis. Não é que o dinheiro “demorasse” tecnicamente para se mover; é que a própria infraestrutura de liquidação por trás da TED só ficava de portas abertas durante o horário comercial, replicando no sistema bancário eletrônico a mesma lógica de uma agência física que fecha as portas às 16h.

Ou seja: o problema nunca foi a internet ser lenta. Era a arquitetura de liquidação ter sido desenhada, décadas atrás, em torno do conceito de “expediente bancário” — um conceito que fazia todo sentido quando transferências eram físicas, feitas na boca do caixa, e que continuou entalado dentro da infraestrutura eletrônica muito depois de deixar de fazer sentido para o usuário final.

O que o Pix realmente resolveu

Comparar Pix com TED só como “ficou mais rápido” subestima o tamanho da mudança. O Pix resolveu os dois problemas na raiz, não na superfície: o DICT eliminou a necessidade de decorar banco, agência, conta e nome exato — uma chave (CPF, e-mail, telefone ou chave aleatória) resolve tudo isso automaticamente, direto no diretório do Banco Central, o que também elimina boa parte do erro humano que devolvia TEDs. E o SPI foi desenhado, desde o primeiro dia, para não ter janela de expediente — opera de fato 24 horas, 365 dias por ano, sem “fechar às 17h” e sem pausar no fim de semana ou feriado. Não é a mesma infraestrutura da TED, otimizada. É uma infraestrutura nova, desenhada para um pressuposto que a TED nunca teve: dinheiro não deveria ter horário de expediente.

Vale registrar também que o Pix não parou de evoluir depois do lançamento: o Pix Saque e o Pix Troco, criados posteriormente, levaram esse mesmo raciocínio para o dinheiro físico — permitindo sacar espécie em casas lotéricas, padarias e supermercados usando o mesmo protocolo. É mais uma pista de que o Pix não é uma funcionalidade fechada e estática; é uma plataforma regulatória em expansão constante — o que, como vamos ver mais adiante, é parte do motivo pelo qual conectar um core bancário a ela não pode ser um projeto “de uma vez só”.

Por trás do toque no app de hoje existe um protocolo de liquidação regulado pelo Banco Central — o SPI — operando em modelo RTGS (liquidação bruta em tempo real): cada transação é processada individualmente, de forma definitiva e irrevogável, 24 horas por dia, 365 dias por ano. Existe o DICT, o diretório que resolve uma chave Pix na conta de destino. Existe o ICOM, a interface pela qual as mensagens trafegam — em XML, seguindo o padrão internacional ISO 20022. E existe, do outro lado dessa cadeia inteira, o núcleo bancário — o sistema que efetivamente debita e credita a conta do cliente, sustenta o histórico, gera o extrato, e responde por cada centavo perante o regulador.

O problema é que esse núcleo, na maioria dos bancos, não nasceu pensando em nada disso. Nasceu pensando em lançamento contábil, em fechamento de expediente, em lote processado à noite — na mesma lógica de janela de operação que limitava a TED. É a colisão entre um protocolo desenhado do zero para o tempo real e um sistema que carrega décadas de decisões pensadas para um mundo que fechava às 16h.

Não podemos aceitar

Tratar “o Pix já está pronto, é só consumir a API do Banco Central” como uma frase completa. Ela descreve o protocolo — não descreve o trabalho de fazer esse protocolo conversar com o que já existe dentro do banco.

Como precisamos pensar

Diante de qualquer integração nova com um protocolo regulado, a pergunta não é “como eu chamo essa API”, é “qual dos dois lados vai ter que ceder terreno quando um conceito de um simplesmente não existir no vocabulário do outro?”

Quantos sistemas diferentes você imagina que uma única transação Pix atravessa hoje, entre o toque no app e o dinheiro efetivamente aparecer na conta do outro lado?

🧠 Exercício de raciocínio

Antes de continuar, responda mentalmente duas coisas: primeiro, por que uma infraestrutura de liquidação (STR/SITRAF) precisaria ter “horário de expediente” se o dinheiro em si é só um registro eletrônico, sem nenhuma limitação física real? Segundo — e essa é a que vamos carregar pelo resto do artigo: quantos sistemas diferentes você imagina que uma única transação Pix atravessa hoje, entre o toque no app e o dinheiro efetivamente aparecer na conta do outro lado?

Sobre a primeira: o horário nunca foi uma limitação técnica real — era uma decisão de design herdada de um tempo em que “transferência” significava um funcionário de banco processando algo manualmente. Guarde sua resposta para a segunda pergunta — vamos revisitar ela no fechamento do artigo, depois de percorrer os dois idiomas envolvidos.

O que é, de fato, uma Anti-Corruption Layer

Em termos simples

Uma Anti-Corruption Layer não é um cabo com dois plugues diferentes nas pontas. É uma embaixada inteira: existe gente cuja função exclusiva é garantir que nenhum conceito mal traduzido de um país vire um incidente diplomático no outro.

Formalmente, uma Anti-Corruption Layer (ACL) é uma camada intermediária colocada entre dois Bounded Contexts — dois domínios com seus próprios modelos e linguagens — cuja função é traduzir o que atravessa essa fronteira, para que nenhum dos dois lados precise adotar os conceitos do outro dentro de casa. O nome não é acidental: “anti-corrupção” porque o papel dela é literalmente impedir que o modelo de domínio de um sistema seja corrompido — contaminado, distorcido — pelos conceitos e pela estrutura de dados do outro.

“Essa camada traduz as solicitações que um subsistema faz para o outro subsistema.”- Microsoft Azure Architecture Center — catálogo oficial de padrões de arquitetura, que credita a origem do conceito a Eric Evans.

Repare que a definição não fala em “converter formato de dado” — fala em traduzir requisições entre dois mundos que não compartilham a mesma visão da realidade. Uma ACL entre Pix e core bank não troca só o nome de um campo; ela decide o que significa, dentro do vocabulário do core, um evento que nasceu com um significado específico no vocabulário do Banco Central.

Não podemos aceitar

Achar que “ACL” é só um apelido chique para qualquer camada de integração. Ela existe para um problema específico: proteger a integridade semântica do seu domínio contra um modelo externo que você não controla.

Como precisamos pensar

A pergunta certa não é “como eu conecto os dois sistemas” — é “o que, no vocabulário do sistema externo, eu NÃO quero que vaze para dentro do meu domínio, custe o que custar?”

🧠 Exercício de raciocínio

Pense num conceito do seu domínio atual — de qualquer sistema que você mantenha hoje — que, se fosse traduzido ao pé da letra pra outro sistema, mudaria de significado no caminho. Guarde esse exemplo: vamos usar esse tipo exato de armadilha no tópico, O que uma ACL faz exatamente, com um caso real do Pix.

De onde veio o conceito

A Anti-Corruption Layer não é invenção recente de arquiteto de fintech. Ela foi descrita formalmente por Eric Evans em 2003, no livro que fundou toda uma escola de pensamento em arquitetura de software: Domain-Driven Design: Tackling Complexity in the Heart of Software. Está na parte do livro dedicada a relações entre Bounded Contexts — ao lado de outras estratégias como Shared Kernel, Customer/Supplier, Conformist e Open Host Service, cada uma descrevendo um jeito diferente de dois domínios coexistirem.

O motivo de mencionar isso não é curiosidade histórica. É que Evans não propôs a ACL como a única opção — ele catalogou várias, cada uma adequada a uma relação de poder e confiança diferente entre os dois lados. Conformist, por exemplo, é quando um lado simplesmente aceita o modelo do outro sem tradução nenhuma — funciona quando você não tem escolha e o modelo externo é bom o suficiente para conviver com ele. A ACL é o oposto: você escolhe pagar o custo de traduzir porque não pode se dar ao luxo de deixar o modelo externo ditar as regras dentro de casa.

Não podemos aceitar

Escolher entre ACL e Conformist só porque “é o que todo mundo usa” — as duas resolvem o mesmo problema de formas opostas, e escolher errado tem consequências diferentes.

Como precisamos pensar

Pergunte quem tem menos a perder se o modelo do outro lado mudar sem aviso. Se a resposta for “eu tenho muito a perder”, ACL. Se for “tanto faz, o modelo deles já é bom o suficiente”, Conformist pode ser mais barato e igualmente correto.

🧠 Exercício de raciocínio

Por que a relação Conformist — aceitar o modelo do Banco Central sem tradução nenhuma, direto dentro do core — não é uma opção segura para um banco, mesmo sendo tecnicamente mais barata de implementar?

Pense em quem regula o quê: o Banco Central pode mudar a especificação do Pix (e já mudou, várias vezes, com Pix Automático e Pix por Aproximação). O core do banco carrega obrigações contábeis e regulatórias que não nasceram do Pix e não podem depender do ritmo de mudança dele.

O que uma ACL faz exatamente

Tradução de modelo, não só de dado

Aqui está o caso real que prova por que “traduzir campo por campo” não é suficiente. O SPI opera em RTGS: toda liquidação é individual, definitiva e irrevogável. Isso tem uma implicação direta e pouco intuitiva — quando um Pix precisa ser devolvido, o sistema não desfaz a transação original. Ele cria uma transação nova, no sentido contrário. Devolução de Pix não é estorno; é um segundo pagamento.

Agora imagine um core bank cujo modelo contábil tradicional trata “devolução” como sinônimo de “estornar o lançamento original” — apagar ou reverter o que foi feito, como sempre se fez com outros meios de pagamento. Se a ACL simplesmente mapear o campo tipo_operação: devolução do Pix para tipo_lançamento: estorno do core, sem traduzir o conceito, o relatório de conciliação enviado ao Banco Central vai registrar dois lançamentos que deveriam ser positivos e distintos como se um deles nunca tivesse existido de verdade — e a conciliação regulatória simplesmente não bate.

É exatamente esse tipo de armadilha que a ACL existe para evitar: ela não troca o nome do campo, ela garante que o conceito “devolução Pix” chegue ao core como o que ele realmente é — um novo lançamento de crédito, não uma reversão — porque só assim o modelo contábil do banco continua correto.

“A camada anti-corrupção atua como mediadora, traduzindo e adaptando entre os dois sistemas — evitando que a complexidade de um vaze para dentro do outro.” - Paráfrase de Sam Newman, Monolith to Microservices (2019), sobre o uso da ACL na integração entre sistemas legados e novos serviços

Não podemos aceitar

Um “de-para” de campos apresentado como se fosse uma integração completa. Nome de campo igual não significa conceito igual — e é exatamente aí que a conciliação regulatória quebra silenciosamente.

Como precisamos pensar

Para cada evento que atravessa a fronteira, pergunte: “esse conceito, no meu domínio, significa exatamente a mesma coisa que significa do outro lado — ou só parece significar, porque o nome do campo é parecido?”

🧠 Exercício de raciocínio

Se o core tratar uma devolução Pix como estorno contábil tradicional — desfazendo o lançamento original em vez de criar um novo — o que exatamente quebra no relatório de conciliação enviado ao Banco Central?

O volume total de transações reportado não bate com o volume real processado pelo SPI, porque uma operação que devia aparecer como dois lançamentos positivos (o Pix original + a devolução como novo pagamento) aparece como se o primeiro nunca tivesse acontecido.

ACL não é Adapter

Em termos simples

Um Adapter é um dicionário de bolso: troca palavra por palavra, rápido, sem entender o contexto. Uma ACL é um intérprete profissional: entende os dois idiomas de verdade, sabe quando uma expressão não existe do outro lado, e reformula a frase inteira para preservar o que ela realmente quer dizer.

✍️ Nota pessoal

Sendo sincero: essa diferença não foi óbvia pra mim da primeira vez que estudei DDD. Os dois nomes se pareciam demais, os dois “traduzem alguma coisa entre dois sistemas”, e por um bom tempo eu tratei os dois como sinônimos, só com nomes diferentes. Só entendi de verdade quando parei de pensar em “o que cada um faz” e comecei a pensar em “o que cada um protege” — e é esse o ângulo que eu quero te poupar de precisar descobrir sozinho, do jeito mais difícil, revisando código em produção.

“Converter a interface de uma classe em outra interface que os clientes esperam.” - Gamma, Helm, Johnson & Vlissides (”Gang of Four”) — Design Patterns: Elements of Reusable Object-Oriented Software (1994), definição do padrão Adapter

É uma definição precisa, e propositalmente estreita: o Adapter resolve um problema de interface — assinatura de método, formato de chamada, tipo de dado esperado. É um padrão estrutural, quase sempre aplicado classe a classe, ou serviço a serviço, num escopo pequeno e bem definido. Ele responde uma pergunta simples: “esses dois pedaços de código conseguem trocar bytes entre si?”

A ACL opera em outro nível — mais alto, mais amplo, e por isso mais difícil de enxergar de primeira. Ela protege um Bounded Context inteiro: não só o formato do dado que entra, mas o que aquele dado significa depois que entra. Na prática, uma ACL quase sempre usa um ou mais Adapters por dentro — junto com Facades e Translators — mas a diferença que realmente importa não é técnica, é de propósito. Um Adapter garante que duas peças de software conseguem se falar. Uma ACL garante que essa conversa não distorce o significado do que está sendo dito.

O mesmo caso da devolução Pix, visto pelos dois padrões

Vale voltar ao exemplo do Tópico anterior para deixar a diferença concreta, não abstrata:

Só com Adapter

O código converte tipo_operação: devolução (Pix) em tipo_lançamento: estorno (core) sem erro nenhum. A chamada funciona, os tipos batem, os testes técnicos passam.

O problema: o Adapter não tem como saber que “devolução” e “estorno” significam coisas diferentes no mundo real — ele só sabe converter formato. A distorção de significado passa despercebida.

Com ACL

A camada reconhece que “devolução Pix” é um conceito de negócio específico — uma transação nova, nunca uma reversão — e traduz isso para o lançamento contábil correto: um crédito novo, não um estorno do lançamento original.

O resultado: o core recebe o conceito certo, a conciliação com o Banco Central bate, e ninguém precisa descobrir o erro três meses depois, numa auditoria.

Por que todo programador precisa saber diferenciar os dois

Não é purismo acadêmico de nomenclatura. A diferença muda três coisas concretas no seu dia a dia:

Primeiro, muda a falsa sensação de segurança. Se você constrói um Adapter e o chama de ACL, o código vai parecer perfeitamente saudável — compila, os testes passam, a chamada funciona. Mas o domínio não está protegido de verdade, porque ninguém traduziu o conceito, só o formato. É o mesmo tipo de bug silencioso que já vimos antes neste artigo: não gera erro, não gera exceção, só gera um dado errado que ninguém percebe até alguém comparar com a realidade.

Segundo, muda quem consegue revisar o código com segurança. Um Adapter pode ser revisado por qualquer pessoa que entenda as duas interfaces técnicas envolvidas. Uma ACL só pode ser revisada de verdade por alguém que entenda os dois domínios de negócio — nesse caso, tanto as regras do Pix quanto o modelo contábil do banco. Se sua revisão de código só valida “os tipos batem”, ela nunca vai pegar um erro de ACL.

Terceiro, muda o que você constrói quando o requisito parece simples. “Só precisamos traduzir esse campo” é, quase sempre, a frase que introduz um Adapter disfarçado de ACL — e o disfarce só é descoberto quando o conceito de um dos dois lados muda, e a tradução simplista, que nunca protegeu significado nenhum, desmorona silenciosamente.

Não podemos aceitar

Chamar de “ACL” qualquer classe que só troca o formato de um payload — isso resolve incompatibilidade de interface, mas não protege domínio nenhum, e chamar do nome errado esconde uma lacuna real de proteção.

Como precisamos pensar

Pergunte em qual nível o problema realmente está: se é “os dois sistemas não conseguem trocar bytes”, é Adapter. Se é “os dois sistemas discordam sobre o que um mesmo conceito de negócio significa”, é ACL — e Adapter sozinho nunca vai resolver isso.

🧠 Exercício de raciocínio

Se você trocar só a assinatura do método que chama o DICT — sem tocar em como “chave Pix” é modelada dentro do seu domínio de conta corrente — você resolveu um problema de Adapter ou de ACL? E se amanhã o conceito de “chave” mudar sutilmente pro Bacen (como já aconteceu com o Pix Automático, que introduziu recorrência), seu Adapter sozinho aguenta essa mudança sem vazar inconsistência pro resto do core?

Trocar a assinatura é Adapter. Mas o Adapter sozinho não tem onde guardar a decisão de “o que fazer quando o conceito muda” — essa decisão precisa morar na camada que entende o domínio dos dois lados, que é exatamente o papel da ACL.

O idioma do Core Bank: contas, ledgers e o peso da história

Em termos simples

O core bancário é o país que construiu suas leis ao longo de décadas, uma emenda de cada vez, e ainda opera boa parte da burocracia em expediente — mesmo que a fachada do prédio tenha sido reformada recentemente.

Alguns termos valem explicação, porque sustentam o resto do raciocínio. Ledger é o livro-razão — o registro definitivo de todos os lançamentos financeiros de uma conta, seguindo o princípio de partida dobrada (todo débito tem uma contrapartida de crédito em algum lugar). Lançamento é cada entrada individual nesse livro. Tradicionalmente, bancos processam em lote (batch): uma janela específica da madrugada onde o dia é fechado, os saldos são consolidados, e o sistema — muitas vezes ainda rodando sobre mainframe, em COBOL — assume que não há mais nada acontecendo até o próximo expediente.

A realidade de 2026 é mais confusa do que esse retrato sugere. Plataformas modernas de core banking vêm substituindo sistemas monolíticos legados por arquiteturas de microsserviços, nuvem e mensageria em tempo real — mas essa transição é gradual, e a maioria dos bancos vive hoje num estágio intermediário: parte do core já modernizada, parte ainda presa ao modelo antigo. Para complicar, muitas instituições — especialmente fintechs e bancos menores — nem operam seu próprio core: dependem de provedores de BaaS (Banking as a Service), o que significa que nem sempre têm autonomia total para mudar a arquitetura por conta própria, mesmo quando sabem exatamente o que precisaria mudar.

Não podemos aceitar

Tratar “o core é legado” como desculpa genérica e permanente. É um fato operacional real — mas vira desculpa quando usado pra justificar nunca investir em desacoplar as duas realidades.

Como precisamos pensar

Pergunte não “quando o core vai ser modernizado”, mas “o que precisa existir HOJE para que o Pix não precise esperar essa modernização acontecer para funcionar direito?” — é exatamente a pergunta que a ACL responde.

O idioma do Pix: SPI, DICT, ISO 20022 e liquidação sem volta

Em termos simples

O Pix é o país que nasceu com constituição escrita num único fim de semana, por um comitê que decidiu que tudo seria padronizado, sem exceção, e que o expediente de atendimento seria vinte e quatro horas por dia, todos os dias do ano, para sempre.

O SPI opera em modelo RTGS — Real-Time Gross Settlement: cada transação é liquidada individualmente, no momento em que acontece, sem espera por lote nem compensação multilateral. Uma vez confirmada, a liquidação é definitiva e irrevogável — a infraestrutura do Banco Central não desfaz uma transação depois de liquidada. O DICT é o diretório que resolve uma chave Pix (CPF, e-mail, telefone, chave aleatória) na conta de destino, consultado antes de cada pagamento. E as mensagens entre participantes trafegam pela ICOM, seguindo o padrão internacional ISO 20022, em XML — o mesmo padrão usado por sistemas de pagamento em diversos países, o que abre a porta para interoperabilidade internacional no futuro.

A instituição que se conecta diretamente a essa infraestrutura — participante direto, o chamado “Pix Direto” — precisa cumprir requisitos técnicos rígidos de disponibilidade, latência e segurança. Não existe meio-termo: ou a mensagem está no formato certo, dentro do prazo certo, ou ela simplesmente não é aceita.

Não podemos aceitar

Achar que “irrevogável” é só um detalhe técnico de rodapé. É uma restrição de negócio com peso jurídico — molda como devolução, disputa e fraude precisam ser tratadas em todo o resto do sistema.

Como precisamos pensar

Toda vez que um conceito do Pix parecer “só mais um campo”, pergunte se ele carrega uma restrição regulatória por trás — porque no Pix, quase sempre carrega.

🧠 Exercício de raciocínio

O Bacen exige liquidação em menos de dez segundos, ponta a ponta. Se o seu core precisa de três segundos só para abrir uma transação tradicional de banco de dados relacional, quanto tempo sobra para todo o resto do fluxo — validação, DICT, ACL, resposta ao app?

Pouquíssimo — e é exatamente por isso que a integração não pode ser “chamar o core como se chama qualquer outra API interna”. A ACL, nesse contexto, também carrega a responsabilidade de decidir o que pode ser respondido de forma otimista ao SPI antes mesmo do core confirmar de verdade.

Onde a ACL entra: desacoplar, proteger e sobreviver às duas evoluções

A ACL senta exatamente na fronteira entre os dois idiomas descritos nos dois tópicos anteriores. Do lado do Pix, ela recebe eventos em ISO 20022, com semântica de liquidação irrevogável e restrições regulatórias específicas. Do lado do core, ela precisa entregar algo que o ledger entenda — um lançamento contábil coerente, respeitando partida dobrada, sem quebrar a lógica que o banco usa há anos. E o caminho inverso também existe: quando o core precisa responder algo ao Pix (confirmação, saldo, status), a ACL traduz de volta, sem expor os detalhes internos do ledger para fora dos muros do banco.

O ganho estratégico é que os dois lados passam a poder evoluir em velocidades diferentes, sem que uma mudança de um force uma reescrita imediata do outro. O Banco Central já mudou a especificação do Pix várias vezes desde 2020 — Pix Automático, Pix por Aproximação, Pix Parcelado — e cada mudança dessas bateria direto no core, sem aviso, se não existisse uma camada absorvendo o impacto. Do mesmo jeito, o banco pode modernizar seu core aos poucos — migrando de mainframe para microsserviços, por exemplo — sem que essa transição interna ponha em risco a conformidade regulatória do lado do Pix.

Antes de escrever a primeira linha: as perguntas que um arquiteto pragmático faz

Adicionar uma ACL não deveria ser reflexo automático só porque “é o padrão certo pra integração com sistema externo”. É uma decisão de investimento — toda ACL bem construída custa tempo de design, disciplina de manutenção, e mais um componente para alguém entender daqui a três anos. O arquiteto pragmático não pergunta “existe um padrão pra isso?” — pergunta se o problema específico que está na sua frente realmente exige essa proteção. Quatro perguntas ajudam a decidir com critério, não por reflexo:

1 · Quem é dono do modelo do outro lado?

O banco não escreve, não revisa e não vota na especificação do SPI, do DICT ou da ICOM — quem decide é o Banco Central, sozinho, e o banco só recebe a mudança quando ela já está definida.

Por quê isso importa: quando você não tem nenhuma influência sobre o modelo externo, aceitar esse modelo dentro de casa significa aceitar mudanças futuras que você nunca vai poder negociar. Isso é, sozinho, um sinal forte de que uma ACL vale o investimento.

2 · O que exatamente se perde se o conceito externo entrar sem tradução?

No caso do Pix, já vimos: tratar devolução como estorno quebra a conciliação regulatória. Esse é um custo real, mensurável, com consequência jurídica — não uma preferência estética de “código mais limpo”.

Por quê isso importa: se a resposta for “nada muito grave, só fica um pouco menos elegante”, talvez o problema não justifique uma ACL — só um Adapter simples já resolve, como vimos anteriormente.

3 · O ritmo de mudança dos dois lados é genuinamente diferente?

O Pix evolui no calendário regulatório do Banco Central. O core evolui no calendário de risco e investimento do banco. Nenhum dos dois espera o outro — cada mudança de um lado pode acontecer sem qualquer coordenação com o outro.

Por quê isso importa: quando dois sistemas mudam por razões diferentes, em ritmos diferentes, decididos por pessoas diferentes, é exatamente a definição de dois Bounded Contexts distintos que Evans descreveu — e é aí que uma fronteira explícita, traduzida, compensa o esforço de mantê-la.

4 · Existe irreversibilidade envolvida?

A liquidação Pix é definitiva. Não existe “desfazer” no protocolo — só uma nova operação no sentido contrário. Isso significa que um erro de tradução não é um bug que se corrige com um patch silencioso; ele já aconteceu no mundo real, com dinheiro de verdade, de forma irrevogável.

Por quê isso importa: quanto mais irreversível a consequência de um erro de tradução, menor a margem para “vamos simplificar por enquanto e ajustar depois”. É esse tipo de restrição, vinda diretamente do desenho técnico do sistema — não de preferência arquitetural — que transforma a ACL de boa prática em necessidade estrutural.

Reparar nessas quatro perguntas juntas explica por que, no caso específico do Pix, a resposta quase sempre aponta para o mesmo lugar: modelo controlado por terceiro regulador, custo real de tradução malfeita, ritmos de mudança desacoplados, e consequência irreversível em caso de erro. Não é o arquiteto “gostando” de DDD — é o próprio desenho técnico do sistema, com suas restrições de regulação e liquidação, empurrando a decisão nessa direção. É isso que significa dizer que o system design mostra a necessidade da camada: a decisão nasce das restrições reais do sistema, não de uma preferência de estilo de quem desenhou.

Não podemos aceitar

Tratar a ACL como um projeto “de uma vez só” que termina quando entra em produção. Ela existe justamente porque os dois lados continuam mudando — e precisa evoluir junto, para sempre, enquanto os dois mundos continuarem diferentes.

Como precisamos pensar

A pergunta permanente de quem mantém essa camada não é “ela está funcionando hoje”, é “ela ainda protege os dois lados da última mudança que o Bacen fez — ou já ficou desatualizada silenciosamente?”

Quando você NÃO precisa de uma ACL

Em termos simples

Construir uma embaixada para conversar com o vizinho que fala a mesma língua que você, sobre assuntos que nenhum dos dois lados considera sério o suficiente para gerar conflito, é desperdício de verba pública — vira burocracia que ninguém pediu.

Depois de um artigo inteiro argumentando a favor da ACL, é importante fechar com o contrapeso: nem toda integração externa precisa dela, e aplicar esse padrão por reflexo — “é boa prática, então uso sempre” — cria exatamente o tipo de complexidade acidental que a ACL deveria evitar, só que num lugar onde ninguém precisava dela.

1. Sinal de que talvez você não precise

   Os dois sistemas são mantidos pelo mesmo time, ou por times que se comunicam de perto e evoluem juntos por decisão consciente. Não existe fronteira real de propriedade — existe só uma separação técnica de deploy.

2. Sinal de que talvez você não precise

   O modelo externo já é bom o suficiente para conviver com ele sem tradução — é exatamente a relação que Evans chama de Conformist, mencionada no Tópico 3: você aceita o modelo do outro de propósito, porque traduzir custaria mais do que adotar.

3. Sinal de que talvez você não precise

   O erro de tradução, se acontecer, é barato de corrigir — um relatório interno que pode ser reprocessado, um dado que pode ser recalculado, nada com efeito jurídico ou financeiro irreversível.

4. Sinal de que talvez você não precise

   A integração é estreita e estável: um único endpoint, um formato que não muda há anos, sem sinal de que vai mudar. Nesse caso, um Adapter simples já resolve o problema todo — sem precisar de uma camada de proteção de domínio inteira por trás dele.

Um exemplo concreto, propositalmente mais simples que o resto do artigo: um banco constrói um painel interno, só para uso do próprio time de operações, que espelha alguns dados do Pix para fins de acompanhamento visual — sem escrever de volta em lugar nenhum, sem alimentar o ledger, sem nenhuma consequência regulatória se um campo estiver levemente desatualizado por alguns minutos. Nesse caso, um Adapter que converte o formato de resposta da API para o formato que o painel espera já é solução completa. Construir uma ACL inteira, com Facade, Translator e um modelo de domínio interno espelhando o do Pix, seria esforço de arquitetura para um problema que nunca teve o peso que justificasse esse esforço.

Não podemos aceitar

Usar “boa prática de DDD” como justificativa automática para adicionar camada de indireção em qualquer integração — inclusive nas que não carregam risco real de corrupção de domínio nem consequência irreversível.

Como precisamos pensar

Antes de desenhar a proteção, meça o que ela protege. Se o pior cenário de erro de tradução é baixo, reversível e barato de corrigir, o custo de manter uma ACL provavelmente supera o risco que ela evitaria.

🧠 Exercício de raciocínio

Pense numa integração que você mantém hoje, ou já manteve, que tem uma camada de tradução “por precaução” — construída seguindo o padrão certo, mas que, olhando com honestidade, nunca precisou proteger nada de fato grave. Pelas quatro perguntas do Tópico 8, ela deveria continuar existindo do jeito que está, ou poderia ser simplificada para um Adapter comum?

Se a resposta genuína for “nunca vi essa camada realmente evitar um problema sério”, isso não é motivo de vergonha — é sinal de que o julgamento arquitetural na época pode ter pesado mais o padrão do que o risco real. Vale revisitar, não vale se cobrar por isso.

Voltando ao número que você guardou

Lá no inicio, pedi para você guardar um número — quantos sistemas uma única transação Pix atravessa entre o toque no app e o dinheiro chegar do outro lado. Depois de passar pelo SPI, pelo DICT, pela ICOM, pela ACL traduzindo nos dois sentidos, pelo core com seu ledger e sua partida dobrada, e frequentemente por camadas adicionais de prevenção a fraude e notificação — é provável que o número real seja maior do que o que você escreveu. A maioria das pessoas subestima, porque a experiência de dez segundos no app foi desenhada, de propósito, para esconder exatamente essa distância.

É esse o ponto central do artigo: Pix não é simples porque o problema é simples — é simples porque alguém, em algum lugar da arquitetura, está absorvendo toda a complexidade de duas línguas que não deveriam, por padrão, conseguir se entender. A Anti-Corruption Layer é essa peça. Não é burocracia arquitetural nem exagero de quem gosta de over-engineering — é a diferença entre um banco que sobrevive à próxima mudança regulatória do Pix sem reescrever o core, e um banco que descobre, na pior hora possível, que os dois mundos nunca estavam de fato traduzidos — só coincidentemente compatíveis, até deixarem de ser.

Duas línguas nunca vão virar uma só. O trabalho do arquiteto não é forçar essa fusão — é construir, e manter viva, a embaixada entre elas.

Guia rápido — os 8 pontos

• Simplicidade aparente: o app esconde SPI, DICT, ICOM e ISO 20022 atrás de um toque de dez segundos.

• ACL: camada que traduz entre dois Bounded Contexts, protegendo o modelo de domínio — não só o formato do dado.

• Origem: Eric Evans, Domain-Driven Design (2003) — uma entre várias estratégias catalogadas para relação entre contextos.

• O que ela faz: traduz conceito, não campo — devolução Pix é transação nova, nunca estorno.

• ACL ≠ Adapter: Adapter resolve interface; ACL protege semântica de um domínio inteiro.

• Core Bank: ledger, partida dobrada, lote, legado, e muitas vezes sem autonomia total (BaaS).

• Pix: RTGS, liquidação irrevogável, 24×365, sem tolerância a mensagem fora do padrão.

• A embaixada: a ACL permite que os dois mundos evoluam em velocidades diferentes, para sempre.

• Quando evitar: mesmo time, modelo externo já bom o suficiente (Conformist), erro barato de corrigir, ou integração estreita e estável — nesses casos, um Adapter simples já basta.