O Banco Multi-Trilho em 2026: Cartões, A2A, Stablecoins, RTP, FedNow e Open Banking em uma única estratégia
Os pagamentos de atacado dos Estados Unidos rodam hoje sobre cinco trilhos vivos em paralelo. Os cartões percorrem os mesmos trilhos de intercâmbio de Visa e Mastercard desde os anos 1970. O ACH ainda transporta o grosso da folha de pagamento e do B2B a custo fracionário com liquidação T+1. A rede RTP ⧉ é instantânea desde 2017, 24/7, e opera pela conta conjunta do The Clearing House no Fed. O FedNow ⧉ entrou em produção em julho de 2023 com arquitetura paralela e pool de liquidez separado. USDC e depósitos bancários tokenizados liquidam atomicamente no Ethereum, no Solana e em redes permissionadas operadas por bancos.
Nenhum desses trilhos está substituindo os outros. O banco que escolher um e apostar a estratégia nele estará errado em dois ciclos de produto. O banco que operar todos sem uma camada de orquestração descobrirá, por volta do terceiro ano, que construiu cinco projetos de integração e não opera nenhum deles com eficiência.
Este artigo trata de como a orquestração efetivamente funciona.
Sumário Executivo / Pontos centrais
- O motor de orquestração é o produto. A lógica de roteamento que escolhe FedNow sobre RTP sobre ACH sobre USDC por transação — em função de custo, finalidade, capacidade da contraparte e disponibilidade de liquidez pré-financiada — é o que define o banco multi-trilho. Todo o resto é detalhe de implementação.
- Liquidez é o custo operacional que ninguém menciona. FedNow e RTP exigem saldos pré-financiados 24/7/365 em contas conjuntas no banco central. Um rollout multi-trilho ingênuo dobra essa armadilha de capital. Um orquestrador consciente de compensação a reduz de volta na direção de um único pool.
- ISO 20022 pacs.008 é a única ponte viável. Sistemas de core bancário emitem MT103 ou campos proprietários. APIs A2A e endpoints de Open Banking consomem dados estruturados pacs.008. A camada de tradução no orquestrador é o que carrega BICs de agentes devedor/credor, informação de remessa estruturada e códigos de finalidade sem mapeamento com perda.
- A liquidação atômica em trilhos de stablecoin reformata o banco correspondente. Uma transferência USDC entre duas carteiras liquida em segundos sem conciliação Nostro/Vostro. Isso é uma ameaça estrutural à linha de receita do banco correspondente, não um detalhe de fintech.
- APIs de Open Banking são o espelho do lado do consumidor para o A2A. O mesmo motor de orquestração que decide FedNow vs ACH em um pagamento B2B decide PIS (Payment Initiation Service) vs cartão salvo em um checkout de consumidor — guiado pelos mesmos fatos de roteamento.
- O banco que controla a lógica de roteamento controla a margem. Se o motor de roteamento for alugado de um fornecedor, é o fornecedor que define o take rate em cada transação que o banco contabiliza.
Como um motor de orquestração efetivamente roteia um pagamento B2B de USD 500 #
Uma empresa média sediada nos EUA dispara um pagamento de USD 500 para um fornecedor a partir do seu ERP. O pagamento chega ao motor de orquestração do banco como mensagem ISO 20022 pacs.008 com informação de remessa estruturada, dados da conta do fornecedor, janela de liquidação de "hoje se possível" e tolerância declarada de "próximo dia útil é aceitável".
O motor lê quatro fatos da mensagem e do estado atual do banco:
- Capacidade de trilho da contraparte. O banco do fornecedor é participante do TCH RTP. Também é endereçável no FedNow. Aceita créditos ACH. Não tem carteira USDC cadastrada.
- Custo por trilho. O FedNow cobra uma tarifa fixa de USD 0,045 do remetente. O RTP cobra USD 0,045 mais o custo interno de liquidez do banco sobre o saldo da conta conjunta no TCH. O ACH custa USD 0,0029 por crédito, liquidado T+1. USDC: gas + custo interno de manter inventário de stablecoin, irrelevante aqui porque o receptor não tem carteira.
- Disponibilidade de liquidez pré-financiada. São 23h, horário do leste. A conta conjunta FedNow do banco no Fed tem hoje USD 42 milhões. A conta conjunta TCH tem USD 61 milhões. Ambas estão acima de qualquer limite plausível de pagamento individual. O custo marginal de usar qualquer um dos trilhos agora é o ganho overnight perdido sobre os USD 500 utilizados — medido em frações de centavo.
- Valor da janela de liquidação para o pagador. O pacs.008 declarou "próximo dia útil é aceitável". Esse é o sinal de roteamento que decide a balança.
O orquestrador roteia para ACH. A tolerância do pagador a T+1 significa que não há razão comercial para gastar 4,2 centavos adicionais (tarifa FedNow menos tarifa ACH) por uma finalidade que o pagador disse explicitamente ser opcional. A instrução pacs.008 é reescrita como entrada CCD no formato NACHA, a informação de remessa estruturada é preservada em registro de adenda e a transação entra na fila da próxima janela ACH.
Se o mesmo pagamento chegar às 9h do horário do leste com "liquidar hoje" no bloco de janela de liquidação do pacs.008, o roteamento pende para FedNow. Se chegar marcado como "liquidação atômica em dólar, carteira anexada", o roteamento pende para USDC. O motor não tem opinião sobre qual trilho é "moderno". Tem opinião sobre qual trilho minimiza o custo total — tarifa mais custo de oportunidade da liquidez — na finalidade que o pagador pediu.
Essa lógica de decisão é o motor de orquestração. Construí-la é o produto.
A armadilha da liquidez pré-financiada 24/7 #
Todo trilho instantâneo em produção hoje opera sob modelo pré-financiado. O Fed não concede crédito intradia aos participantes do FedNow. O The Clearing House não o concede aos participantes do RTP. A liquidação em ambos os trilhos ocorre contra um saldo pré-financiado em conta conjunta que o banco participante estaciona no operador correspondente — no Fed para FedNow, no TCH para RTP — e reabastece 24/7/365.
A consequência operacional é severa. Um banco que opera FedNow para um pico diário de pagamentos instantâneos de USD 100 milhões mantém dezenas de milhões em saldo ocioso só para cobrir os picos intradia. Operar o RTP em paralelo adiciona um segundo pool ocioso. Os dois pools não podem se compensar mutuamente porque estão em operadores diferentes. Cada pool rende a taxa relevante de juros sobre reservas (FedNow) ou zero (conta operacional TCH) e abre mão do que o banco poderia ganhar com o mesmo saldo em repo, fundos de money market ou Treasuries de curta duração.
Esse é o custo operacional silencioso dos pagamentos instantâneos multi-trilho. Um banco que financia dois trilhos instantâneos sem estratégia de orquestração estaciona o dobro do saldo ocioso pelo dobro do ganho perdido.
O orquestrador minimiza a armadilha de três maneiras:
- Roteamento concentrado. Direcionar o volume marginal de trilho instantâneo para qualquer conta conjunta que esteja mais bem financiada no momento. Reabastecer a outra de forma preguiçosa. O resultado é um pool quente e um frio, em vez de dois pools meio cheios.
- Discriminação por janela de liquidação. Tudo o que o pacs.008 marcar como "próximo dia útil é aceitável" deixa por completo os trilhos instantâneos e liquida em ACH. Isso retira da demanda por saldo pré-financiado toda a cauda longa de tráfego sem urgência.
- Varreduras de tesouraria atreladas a volume previsto. A demanda prevista de pagamentos instantâneos para as próximas 6, 12 e 24 horas dita o tamanho do saldo pré-financiado. Tudo acima dessa previsão migra para repo overnight.
Sem o orquestrador, o banco financia a demanda de pico-do-pico. Com o orquestrador, financia a demanda prevista mais uma margem. A diferença, em um negócio de pagamentos instantâneos de USD 5 bilhões por dia, é dezenas de milhões em saldo ocioso e cifras de sete a oito dígitos em ganho overnight perdido.
A ponte ISO 20022 pacs.008 #
Sistemas de core bancário construídos nos anos 1980 e 1990 emitem campos MT103 ou formatos internos proprietários. APIs A2A (PIS de Open Banking, endpoints FedLine do FedNow, mensageria RTP do TCH) consomem ISO 20022 pacs.008. A camada de tradução no orquestrador é o que carrega o payload estruturado adiante sem perder os campos dos quais os consumidores A2A dependem.
Uma mensagem pacs.008 carrega — no mínimo:
- Identificação do devedor e do credor com nome estruturado, endereço (BIC + LEI quando disponível) e números de conta em formato IBAN ou BBAN.
- Identificação dos agentes devedor e credor (o BIC de cada banco participante) e a cadeia de liquidação.
- Informação de remessa estruturada — campos tipados para números de fatura, códigos de motivo de pagamento (ISO 20022 ExternalPurposeCode) e fallback em texto livre.
- Blocos de reporte regulatório para jurisdições que exigem códigos estruturados de motivo AML embutidos.
- Prioridade de liquidação e instrução para o agente credor — campos que as regras de esquema A2A leem diretamente.
Uma tradução ingênua de um payload MT103 plano para pacs.008 perde ou deturpa a maior parte desses campos estruturados. A remessa em texto livre cai no bloco errado. Os códigos de finalidade são reconstruídos por correspondências de substrings e chegam como OTHR (a categoria genérica). O reporte regulatório é descartado por completo porque o MT103 de origem não tinha slot estruturado para ele. O banco receptor — e o ERP do tesoureiro receptor — recebe a confirmação de pagamento sem metadados parseáveis por máquina. A conciliação volta para revisão manual.
A camada de tradução do orquestrador precisa fazer três coisas que os conversores MT-para-MX de prateleira não fazem:
- Enriquecer em vez de traduzir. Adicionar os campos estruturados que faltavam no MT103 de origem lendo-os do cadastro de clientes do banco, do sistema de faturas ou da integração com o ERP. O pacs.008 que sai do orquestrador carrega mais dado estruturado do que o MT103 que entrou.
- Preservar idempotência. O mesmo MT103 de origem, retraduzido, produz um pacs.008 bit-idêntico. É isso que torna os reenvios seguros nos trilhos A2A que esperam semântica de entrega exatamente uma vez.
- Validar contra o perfil do esquema receptor. O perfil pacs.008 do FedNow difere em detalhes do perfil do RTP, do SCT Inst e de cada implementação de Open Banking. O orquestrador valida contra o perfil de destino antes do envio, não depois de o trilho rejeitar.
Bancos que pulam essa camada acabam com pipelines de tradução específicos por trilho duplicados em três ou quatro integrações. Bancos que a constroem uma vez, corretamente, roteiam qualquer pagamento para qualquer trilho sem reimplementar a lógica de mensageria.
Arquitetura multi-trilho, por camada técnica #
A arquitetura abaixo substitui o enquadramento genérico de "workflow, dados, controle" que serve para apresentação de conselho. As camadas que realmente carregam a carga são estas.
| Camada | O que faz em produção | Modo de falha se mal tratada | Diretiva arquitetônica |
|---|---|---|---|
| API Gateway e motor de orquestração | Aceita a intenção de pagamento vinda de ERPs, apps móveis e sistemas core. Lê capacidade da contraparte, estado de liquidez atual, participação em esquemas e preferências do pagador. Decide qual trilho usar. | O banco aluga o motor de roteamento de um fornecedor de pagamentos. O fornecedor define o take rate em cada transação. A margem do banco desaparece dentro da precificação do fornecedor. | Ser dono do motor de roteamento. Construí-lo como serviço interno com drivers específicos por trilho atrás de uma interface interna estável. SDKs de fornecedor viram implementações de driver, não o próprio motor. |
| Camada de liquidez e ledger | Administra saldos pré-financiados em conta conjunta no Fed (FedNow), TCH (RTP), bancos de liquidação das bandeiras de cartão (Visa, Mastercard) e carteiras on-chain (inventário USDC, posições de depósito tokenizado). Faz varreduras de saldos ociosos para repo overnight. | O banco estaciona saldos ociosos em todo operador de trilho ao mesmo tempo. O ganho perdido sobre um livro de pagamentos instantâneos de USD 5 bilhões por dia chega a sete ou oito dígitos por ano. | Prever a demanda de pagamentos instantâneos por hora. Financiar as contas conjuntas até a previsão mais uma margem. Varrer todo o resto. A função de Tesouraria é dona da política diária de reabastecimento, não a equipe de produto do trilho. |
| Camada de mensageria e tradução ISO | Traduz entre o formato interno de pagamento do banco, MT103 (onde ainda usado), pacs.008 / pain.001 / camt.053 (ISO 20022), NACHA CCD/PPD (ACH), ISO 8583 das bandeiras de cartão e primitivas de transação on-chain. Enriquece à medida que traduz. Valida contra o perfil do esquema de destino. | Tradução com perda derruba a informação de remessa estruturada e os códigos de finalidade. Receptores não conseguem conciliar de forma programática. A fila de investigação manual cresce. | Construir um único tradutor com consciência de enriquecimento e validação por perfil de esquema de destino. Conversores MT-para-MX são insumo, não a resposta. Testar contra os perfis de referência de cada esquema em CI. |
| Registro de contrapartes e capacidades | Sabe em quais trilhos cada contraparte é endereçável, quais perfis de esquema aceita, quais são seus limites por transação, quais jurisdições impõem quais reportes. | O orquestrador roteia para um trilho que o receptor não aceita. O pagamento falha ou liquida devagar com intervenção manual. | Manter o registro como produto de dados de primeira classe. Atualizá-lo diariamente contra diretórios de esquema, listas de participantes de bancos centrais e feeds de capacidade de agregadores de Open Banking. O registro é o que torna a decisão de roteamento auditável. |
| Fraude, sanções e autorização | Roda triagem em tempo real em cada intenção de pagamento contra listas de sanções, modelos de fraude, regras de autorização e registros de consentimento. Devolve permitir/bloquear/escalonar em milissegundos. | A triagem roda depois da submissão ao trilho. Pagamentos sancionados saem do banco e precisam ser revogados. Cada revogação é incidente reportável ao regulador. | Triar no ponto de entrada da orquestração, antes da seleção de trilho. O mesmo resultado de triagem deve ser válido em cada trilho que o orquestrador possa escolher. |
| Conciliação e reporte de liquidação | Concilia cada pagamento de saída contra confirmações de liquidação, atualizações de status (pacs.002) e extratos camt.053 de entrada. Detecta divergências em horas, não em dias. | A conciliação roda T+2 em planilha. Divergências de liquidação se acumulam. Disputas de clientes escalam. | Conciliar por trilho com modelo de dados unificado. A mesma lógica de detecção de divergência roda contra FedNow, RTP, arquivo de retorno ACH, arquivo de liquidação das bandeiras e confirmação de transação on-chain. |
O que isso significa por tipo de banco #
Bancos globais #
Bancos globais já operam o parque de trilhos mais fragmentado. Cada região financiou suas próprias integrações sob seu próprio P&L de produto. O resultado são três ou quatro rollouts multi-trilho paralelos, cada um rodando sua própria camada fina de roteamento, cada um negociando separadamente com os mesmos fornecedores.
A diretiva: financiar uma única camada de orquestração agnóstica acima dos cores legados, alocada à engenharia de plataforma e não a qualquer grupo de produto. O orquestrador é dono da decisão de roteamento globalmente; os grupos regionais de produto a consomem como serviço. Os SDKs de fornecedor que cada região trouxe viram drivers específicos por trilho atrás da interface interna do orquestrador, não motores de roteamento paralelos disputando o mesmo pagamento.
O argumento econômico vai bater na mesa do CFO. Um único orquestrador global captura cada decisão de roteamento, cada ponto de margem e cada dado estruturado de pagamento que o banco gera. Três orquestradores regionais não capturam nada disso no nível do grupo.
Bancos regionais #
Bancos regionais enfrentam um problema distinto. Têm menos trilhos a integrar, mas proporcionalmente menos capital para estacionar em contas conjuntas pré-financiadas. Um banco regional com um livro diário de pagamentos instantâneos de USD 500 milhões estaciona, de forma conservadora, USD 30-50 milhões no Fed para FedNow mais USD 20-30 milhões no TCH para RTP — fatia relevante do balanço discricionário rendendo zero ou perto disso.
A diretiva: construir um orquestrador consciente de liquidez antes de adicionar o segundo trilho instantâneo. Um regional que entra em FedNow e RTP simultaneamente sem estratégia de compensação dobra a armadilha do saldo pré-financiado sem aumento proporcional de volume. A sequência certa é FedNow primeiro, instrumentar o perfil de demanda, financiar a conta conjunta até o pico observado e só então adicionar RTP, quando o orquestrador puder rotear o pagamento marginal para o pool que estiver mais bem financiado.
A questão de capital domina. Tesoureiros de bancos regionais devem quantificar o ganho perdido sobre saldos pré-financiados como linha do business case multi-trilho, e não absorvê-lo como custo não declarado de inovação.
Fintechs e PSPs #
Fintechs e prestadores de serviços de pagamento ficam entre o corporativo ou o lojista e o trilho bancário. A pergunta competitiva para eles é se agregam abstração que o banco não consegue construir por conta própria.
A diretiva: entregar a orquestração como serviço para bancos médios que não podem financiar a sua própria. Vender o motor de roteamento, a previsão de liquidez e a tradução ISO 20022 como plataforma gerenciada. As fintechs que tentarem competir com bancos globais em lógica de roteamento perderão na economia de margem do motor de orquestração. As fintechs que venderem a mesma lógica para bancos pequenos demais para construí-la dominarão o segmento regional.
Tesoureiros corporativos #
Tesoureiros consomem as saídas dos trilhos por suas integrações com ERP. A pergunta de 2026 para eles é se o dado estruturado que o banco emite é rico o suficiente para automatizar a conciliação sem revisão manual.
A diretiva: exigir dado de remessa rico em pacs.008 em cada confirmação de pagamento recebida. Especificamente, exigir referências estruturadas de fatura em RmtInf/Strd/RfrdDocInf, exigir códigos de finalidade da lista ISO 20022 ExternalPurposeCode em vez do OTHR genérico e exigir atualizações de status (pacs.002) no mesmo endpoint de API da confirmação. Bancos que não conseguem entregar esses dados estão sinalizando que sua camada de tradução ainda faz conversão MT-para-MX com perda. Essa é a pergunta certa de RFP para o ciclo de seleção de banco em 2026.
O argumento de conciliação vai bater na mesa do próprio tesoureiro. A correspondência automatizada de faturas contra remessa pacs.008 estruturada reduz a fila de exceções da equipe de AP em 60-80%. Esse é o ganho de produtividade duradouro que o tesoureiro pode exigir e medir.
Como contexto comparativo, o mercado brasileiro já viveu essa lição com o PIX, o trilho instantâneo do BACEN: a liquidez pré-financiada em contas no banco central também é restrição operacional e os times de tesouraria já tratam o tema como linha de custo. As decisões de governança do orquestrador para FedNow e RTP nos EUA seguem a mesma lógica que tesoureiros brasileiros aplicam para dimensionar a posição PIX.
O que vem a seguir #
Os marcos visíveis de 2026 são em nível de esquema: cruzamento de volume entre FedNow e RTP, a cobertura PIS de Open Banking ultrapassando 60% dos checkouts de consumidor no Reino Unido, o primeiro banco sediado nos EUA operando uma stablecoin emitida pelo banco em produção para B2B cross-border. Esses são os fatos de release de imprensa.
O trabalho invisível de 2026 é o orquestrador. Os bancos que o financiarem em 2026 serão os bancos que rotearão 80% dos pagamentos B2B dos EUA em 2028. Os bancos que financiarem mais uma integração de trilho sem o orquestrador gastarão os mesmos dólares e terminarão onde começaram — operando três ou quatro produtos de trilho em paralelo sem captura de margem.
O banco multi-trilho em 2026 não é um banco que opera mais trilhos. É um banco que construiu o motor de roteamento, o livro de liquidez e o tradutor pacs.008 sobre os quais os trilhos se assentam.
Perguntas frequentes #
FedNow ou RTP vai vencer?
Nenhum dos dois. Os dois trilhos vão rodar em paralelo no horizonte previsível. As listas de participantes se sobrepõem significativamente, mas não por completo — há bancos no FedNow que não estão no RTP e vice-versa. Enquanto a sobreposição de participantes não for quase total, o orquestrador roteia para o trilho que alcança a contraparte.
Um banco médio deve construir o próprio motor de orquestração ou comprar?
Construir a lógica de roteamento internamente se o volume diário de pagamentos for acima de aproximadamente USD 1 bilhão. Abaixo disso, o custo de engenharia para construí-la não se amortiza contra a margem capturada. Comprar de uma fintech que vende a orquestração como serviço gerenciado e negociar duramente o take rate por transação.
O que liquidação atômica significa de fato para o banco correspondente?
Uma transferência USDC entre duas carteiras de custódia liquida on-chain em 15-30 segundos sem conta Nostro/Vostro intermediária. O mesmo movimento de dólar pelo banco correspondente tradicional toca de três a cinco contas, cada uma com sua janela de liquidação, e se concilia em horas a dias. Em corredores onde ambas as contrapartes têm infraestrutura de carteira, o caminho on-chain é estruturalmente mais barato e mais rápido. A receita do banco correspondente nesses corredores vai comprimir.
Qual é o ponto de partida correto para a camada de tradução ISO 20022?
Começar com pacs.008 de saída, pain.001 de entrada (a iniciação de transferência de crédito do cliente) e pacs.002 de reporte de status. Essas três mensagens cobrem 80% do fluxo de pagamento de atacado. Adicionar conciliação camt.053 e retornos pacs.004 na segunda onda. Não começar pela biblioteca de mensagens — começar pelo perfil de esquema que cada trilho receptor exige e trabalhar de trás para frente.
Quanto saldo pré-financiado o FedNow efetivamente exige?
Depende do volume do participante. Um banco com pico horário de saída de pagamentos instantâneos de USD 50 milhões precisa aproximadamente dessa ordem de grandeza em sua conta conjunta FedNow no Fed, dimensionada para a hora seguinte. Com automação de varredura atrelada à demanda prevista, o saldo de regime pode rodar mais perto da mediana do que do pico — mas o pico ainda precisa ser coberto com poucos minutos de aviso.
Referências #
- The Clearing House, (2026). RTP Network ⧉.
- Federal Reserve Financial Services, (2026). The FedNow Service ⧉.
- ISO 20022, (2024). pacs.008.001.10 — FIToFI Customer Credit Transfer message definition ⧉.
- NACHA, (2026). ACH Operating Rules and Guidelines ⧉.
- BIS Committee on Payments and Market Infrastructures, (2025). Fast payments and the future of the financial system ⧉.
- Open Banking Limited, (2026). Variable Recurring Payments specification ⧉.
- Circle Internet Financial, (2026). USDC Treasury & Reserves ⧉.
Última revisão .
Última revisão .