Fintomico
A latência entre a liquidação no DICT e a disponibilidade do dado na API de Open Banking varia de 5 a 120 segundos, dependendo da arquitetura de sincronização do participante.
A resposta curta que você busca como desenvolvedor ou arquiteto de sistemas não é um número fixo, mas uma janela de probabilidade. Em 2026, a experiência prática mostra que um dado de transação PIX levada via Open Banking leva, em média, entre 15 e 60 segundos para estar disponível para consulta em um endpoint de /transactions. O cenário ideal — onde o dado aparece quase instantaneamente após a liquidação — ocorre em menos de 5% dos chamados, geralmente limitado a participantes com arquiteturas event-driven maduras.
O problema técnico não reside na velocidade do PIX em si (o DICT — Diretório de Transações de Valores do Bacen — liquida em menos de 2 segundos), mas sim no gap de sincronização entre o saldo finalístico na conta corrente do usuário no banco emissor e a camada de exporação de dados do Open Banking. Quando um cliente seu faz um PIX via App do Banco A, mas o seu dashboard precisa ler esse dado através da API do Banco B (agregador) ou até mesmo do próprio Banco A, você está dependendo de três sistemas distintos conversarem: o DICT, o Core Bancário (ou Coreplus) e o Gateway de Open Banking.
Para entender a latência, precisamos separar a transação financeira do dado informativo. O PIX é uma mensagem de liquidação bruta e irrevogável. Quando o Bacen processa a transação, ele envia uma resposta de sucesso ao participante. Neste momento, o dinheiro já mudou de dono na conta reserva do Bacen. No entanto, dentro do banco participante, esse dinheiro ainda precisa "pousar" na conta do cliente.
Esse "pouso" envolve a atualização dos saldos no sistema legado ou no novo Core. Em bancos de grande porte que ainda operam com processos batch noturnos para alguns tipos de conciliação, a atualização do saldo na conta corrente (disponível para saque ou transferência) é imediata por exigência regulatória, mas a geração do registro histórico da transação (o extrato) pode levar alguns segundos a mais para ser persistida em tabelas de leitura.
Se o Gateway de Open Banking do banco lê diretamente da base de escrita (master database), você verá o dado rápido. Se ele lê de uma replica ou de uma base de dados otimizada para leitura (estratégia comum para não travar a transação), existe um lag de replicação. Já vi implementações onde esse lag de replication lag chega a 30 segundos simplesmente porque a infraestrutura de banco de dados estava saturada. Nesse intervalo, seu endpoint GET /accounts/{accountId}/transactions retorna um 200 OK, mas o JSON não contém o último PIX.
Agora, vamos pular para o participante que está lendo esse dado. Mesmo que o banco que processou o PIX já tenha o dado persistido, o padrão Open Banking impõe uma camada de cache obrigatório ou fortemente recomendado para o endpoint de transações. A especificação doCouncildefine que, para o endpoint de transações, os dados podem ser servidos com uma idade máxima de "T+1 dia" para o saldo inicial, mas para as transações individuais, a expectativa do mercado empurrou para quase tempo real.
Contudo, para proteger a infraestrutura de spikes de leitura (especialmente em fintechs de gestão financeira que atualizam a tela a cada 5 segundos), a maioria dos participantes implementou um caching de 30 a 120 segundos na camada de API Gateway.
Isso cria um comportamento frustrante para o usuário final. O cliente vê o dinheiro sair no app oficial do banco (que consulta o Core) e abre o seu app (que consulta Open Banking) e não vê o movimento. O dado está lá, mas a API que você consome está te servindo uma "foto" de 45 segundos atrás.
Se o seu sistema de polling fizer requisições a cada 10 segundos, você consumirá cota de rate limit sem necessariamente obter um dado novo durante o período de cache do participante. Eu recomendo ajustar seu polling para intervalos de 60 a 90 segundos para endpoints de transações, respeitando a maturação do dado no lado do Data Holder. Quem ainda tenta bater na porta a cada 2 segundos acaba bloqueado por segurança, pois esse comportamento mimica ataques DDoS ou ferramentas de scraping rudimentares.
No mercado atual, dividimos os participantes em três blocos de comportamento de latência.
Bloco 1: Grandes Bancos v1 (Legado com camada moderna). Instituições como Banco do Brasil, Caixa ou Itaú (em alguns de seus produtos herdades) costumam ter uma latência maior. O PIX sai rápido, mas o dado aparece na API de Open Banking entre 60 e 120 segundos após o fato consumado. Eles utilizam pesadamente buffers para garantir a consistência entre o saldo de contas de depósito e contas de pagamento pré-pagas, algo comum em suas arquiteturas complexas. Se você estiver construindo um controle financeiro que soma saldos, considere sempre um "atraso de visibilidade" de 2 minutos para estas instituições.
Bloco 2: Neobancos e Digitais Nativos. Nubank, Inter, PagBank e similares têm latências mais agressivas. Como nasceram na nuvem, o Core geralmente conversa via eventos de mensageria (Kafka/RabbitMQ) diretamente com o Gateway de Open Banking. Aqui, a média cai para 10 a 30 segundos. O gargalo aqui é raramente o banco, mas sim o intermediador Open Banking se você estiver usando um hub ou BaaS que faz um "fan-out" das requisições. Se você conectar direto na API oficial, a experiência é visceralmente mais rápida.
Bloco 3: Crédito e Investimentos com conta corrente. Instituições onde a conta corrente é um "produto a mais" (Bancos de Investimento) costumam ter o pior desempenho na atualização de dados via Open Banking. Como o foco delas não é o volume de transações de pagamentos de varejo, a prioridade de replicação de dados é menor. Já observar latências superiores a 3 minutos para atualização de PIX na API em alguns players de crédito consignado que lançaram contas digitais recentemente. Para o usuário final, parece que o sistema "quebrou", mas tecnicamente é apenas uma fila de prioridade baixa no data lake deles.
Muitos desenvolvedores acham que implementar webhooks resolve o problema da latência. O ideal seria: o PIX acontece -> Banco dispara webhook para seu sistema -> Seu sistema chama a API para buscar o dado. Na teoria, é perfeito. Na prática brasileira de 2026, o delivery de webhooks ainda não tem garantia de entrega em tempo real definida no padrão Open Banking (diferente do padrão PIX, que tem a notificação callback do DICT).
Muitas instituições implementam o webhook de forma assíncrona e em lote (batching). Você pode receber o aviso de "nova transação" 2 minutos depois do evento. Pior, esse webhook muitas vezes não traz o payload da transação, apenas um sinal de "há atualizações, venha buscar". Isso te obriga a fazer um polling forçado no exato momento em que o servidor do banco pode estar congestionado.
Para contornar isso, arquiteturas robustas hoje utilizam uma estratégia de dual-read. Confiam no polling periódico (ex: a cada 60s) para garantir consistência eventual e usam o webhook apenas como um "gatilho de antecipação" para tentar ler o dado antes. Se o webhook falhar ou chegar atrasado, o polling garante que o dado não se perca. Nunca construa uma tela de sucesso de pagamento dependendo exclusivamente do webhook do Open Banking para confirmar que um débito saiu; use o comprovante do DICT retornado na sua própria chamada de iniciação de pagamento para isso.
Existe um motivo técnico não negligenciável para essa latência toda: a segurança. O padrão de segurança exigido pelo Open Banking Brasileiro, o Financial-grade API (FAPI), adiciona uma camada pesada de validação de tokens (JWT), validação de claims e verificação de binding entre o token e a requisição (MTLS, DPoP).
Essa validação criptográfica não é "de graça" em termos de processamento. Para escalar, as instituições precisam balancear carga de autenticação. Se cada requisição de transação exigisse uma validação FAPI completa em tempo real sem qualquer cache, o custo de infraestrutura dispararia e a latência de resposta subiria para segundos, mesmo para dados que não mudaram.
Portanto, parte da latência que você sente é o tempo de fila na autorização OAuth2. O usuário (ou seu sistema client credentials) tem o token validado, o consent é checado no banco de dados de permissões, e só então a requisição cai no domínio de conta. Muitos desenvolvedores junior culpam o "banco lento", mas muitas vezes é a camada de segurança imposta pelo regulador que cria esse buffer necessário para evitar fraudes e ataques de injeção de identidade.
O erro clássico — e o que mais gera tickets de suporte — é tratar o saldo do Open Banking como "saldo em caixa". Se o seu aplicativo de gestão pessoal exibe "Saldo Atualizado: R$ 1.500,00" baseado na última chamada da API, e o usuário acabou de gastar R$ 100 via PIX, você está mostrando um dado falso por, potencialmente, um ou dois minutos.
A solução técnica correta é implementar um "estado de otimismo controlado" ou um indicador de sincronização. O sistema deve reconhecer que acabou de ler o dado e exibir "Saldo há 1 minuto". Se o usuário realiza uma ação na sua própria interface (inicia um PIX via sua iniciação de pagamento), você atualiza a UI localmente instantaneamente (otimista) e marca aquele valor como "pendente", sem esperar a confirmação do Open Banking, pois o fluxo de Payment Initiation é mais rápido e determinístico que o de Data Sharing.
Outra falha comum é não tratar a inconsistência temporal. Se o usuário ler um extrato às 10:00:00 e fazer um PIX às 10:00:05, e você chamar a API novamente às 10:00:15, não assuma que o débito já está lá. Construa sua lógica de negócio sabendo que o universo do Open Banking tem uma inércia de 30 a 60 segundos. Não prometa "tempo real" no seu marketing se o back-end depende puramente do padrão de dados. Prometa "atualização automática", gerencie a expectativa.
Para responder a pergunta inicial com a precisão que uma arquitetura de produção exige: um dado de transação PIX atualiza no padrão Open Banking entre 5 e 120 segundos após a liquidação no DICT. A média de mercado está em torno de 40 segundos. Não existe um padrão único porque isso depende da arquitetura interna de persistência de dados do participante (Core vs. API Gateway) e da estratégia de caching adotada para proteção de rate limit.
Se você está projetando um sistema hoje em 2026, projete sua lógica de polling para intervalos de 60 segundos e considere o dado da API como "eventualmente consistente". Jamais use a API de leitura do Open Banking como fonte de verdade única para bloqueios ou validações de segurança sensíveis ao segundo; para isso, você precisa de uma integração direta ou depender do fluxo de iniciação de pagamentos. Entender essa latência não é apenas uma questão de performance, é a única forma de evitar frustrar o usuário que acredita ver "dinheiro que já saiu" ainda disponível na tela.
A dependência de screen scraping coloca em risco a operação de fintechs; entenda o porquê a migração para Open Banking é uma questão de sobrevivência técnica e legal.
Entenda por que implementar apenas o fluxo padrão OAuth 2.0 é insuficiente para o Banco Central e como o perfil FAPI 1.0 protege o token de acesso contra replay e vazamento.
