Este conteúdo foi adaptado da newsletter mensal da Opus.
Assine a newsletter mensal da Opus
Índice
Quick reference block
| O que é CIBA no Open Finance? | O que o CIBA possibilita fazer? |
| CIBA (Client Initiated Backchannel Authentication) é um protocolo de autenticação desacoplada que permite ao cliente autorizar uma solicitação por um canal separado daquele em que ela começou. | Obter consentimento sem redirecionamento a cada interação, com o aceite por push, SMS ou WhatsApp no modelo com vínculo. Também pode reduzir o atrito no consentimento de pessoa jurídica com múltiplos representantes, facilitando as aprovações por canais separados. |
O problema que o CIBA resolve: quando quem autoriza não está na tela
Uma empresa faz uma compra on-line.
O pagamento sai da conta da pessoa jurídica, e quem precisa autorizar é o sócio administrador, que naquele momento está em outra cidade, com outro celular, sem acesso ao computador em que a compra foi efetuada.
A jornada mais comum no Open Finance pede que o pagador seja levado ao aplicativo do banco, autentique ali e volte.
Quando quem autoriza não está no lugar em que a transação acontece, essa ida e volta deixa de ser um detalhe de experiência e passa a ser o motivo pelo qual a compra não sai do lugar.
O mesmo obstáculo aparece em formatos menos óbvios:
Em todos esses casos, a dificuldade não está no consentimento em si, e sim na exigência de que ele aconteça no mesmo canal e no mesmo instante da transação.
O que é CIBA no Open Finance?
CIBA é a sigla de Client Initiated Backchannel Authentication, e é o protocolo que permite autorizar uma transação fora do canal em que ela começou.
A especificação brasileira CIBA-BR o define como o protocolo que permite obter o consentimento do usuário "SEM realizar o fluxo FAPI Hybrid Flow (redirecionamento) em todas as interações".
A parte mais importante é “em todas as interações”: o redirecionamento não desaparece do ecossistema, ele apenas deixa de ser obrigatório em toda interação.
Elcio Calefi, diretor de tecnologia da Associação Open Finance, resumiu o mecanismo em entrevista ao Finsiders em junho de 2026:
Na mesma entrevista ele descreve o efeito dos dois lados
Na leitura da Opus Open Finance, as duas pontas se resumem a uma coisa só.
- Quem autoriza passa por menos etapas, porque o aceite chega pelo canal que a pessoa já usa, sem passar pela tela em que a transação começou.
- Quem recebe tem menos abandono, porque a jornada não expira pelo simples fato de o responsável não estar no dispositivo certo na hora certa.
Em uma empresa com vários responsáveis por aprovar pagamentos, a gestão de alçadas pode permanecer dentro do ERP que a companhia já opera.
Fluxo redirecionado vs fluxo desacoplado
O padrão que rege a autenticação do Open Finance Brasil vem da OpenID Foundation, que classifica os fluxos de autorização em duas famílias.
Fluxo redirecionado
O usuário é levado do aplicativo do iniciador até o ambiente do detentor da conta, autentica lá e retorna. É o FAPI Hybrid Flow, e sustenta a maior parte das jornadas em produção hoje
Fluxo desacoplado
O dispositivo que consome a API e o dispositivo em que a pessoa autentica são distintos, e a autorização viaja por um canal paralelo em vez de percorrer a tela do usuário.
CIBA é o nome desse segundo caminho.
Os sistemas envolvidos trocam as informações necessárias pelas APIs, enquanto a autorização chega ao responsável por outro canal, e o cliente não precisa acompanhar todo o processo na tela em que a transação começou.
Quais são os dois modelos do CIBA-BR?
A especificação brasileira descreve dois desenhos, e a escolha entre eles é decisão de produto antes de ser decisão de arquitetura.
Modelo com vínculo
Existe um redirecionamento inicial pelo fluxo tradicional, que estabelece a relação entre aquele cliente e aquela conta.
Depois disso, os pedidos seguintes chegam ao usuário por um canal de notificação, e a especificação nomeia push, SMS e mensagem por WhatsApp entre as possibilidades.
O usuário aceita ali, sem voltar ao aplicativo do banco.
Modelo sem vínculo
Não há esse primeiro redirecionamento. O pedido de autorização parte direto pelo canal paralelo, usando as informações do próprio consentimento.
A especificação descreve os dois desenhos sem indicar preferência.
Na leitura da Opus Open Finance, a diferença prática apareceria no atrito e na confiança.
O modelo com vínculo cobraria o atrito uma vez, no primeiro redirecionamento, para depois entregar uma jornada mais leve, o que combina com relações recorrentes.
O modelo sem vínculo dispensaria esse passo inicial e colocaria mais peso na forma como o detentor da conta identifica quem está do outro lado, o que combina com interações pontuais, em que não existe uma jornada inicial para aproveitar.
Desde quando o CIBA existe no Open Finance Brasil?
A aprovação de agosto colocou o CIBA nas notícias, mas o protocolo e a sua adaptação brasileira já estavam publicados bem antes disso.
O perfil que combina CIBA com o nível de segurança exigido pelo setor financeiro, o FAPI-CIBA, foi lançado pela OpenID Foundation em agosto de 2019, e o programa de certificação para provedores abriu em setembro daquele ano.
A adaptação brasileira também já tem idade. O Perfil CIBA de Segurança do Open Finance Brasil 2.0 está publicado desde 15 de setembro de 2025 e declara seu alcance sem meio-termo, aplicável a todos os participantes do Open Finance no Brasil.
O que o Conselho de Administração aprovou em agosto de 2026 foi o escopo e o cronograma do projeto de implementação.
Na prática, isso ajuda quem planeja roadmap: o material técnico já está público na Área do Desenvolvedor, então a discussão interna pode começar direto pelo desenho da jornada, sem esperar documento novo.
O que o CIBA permite na prática?
O que já está na norma
Quatro pontos, todos descritos na especificação CIBA-BR v2.0.0.
- O consentimento pode ser obtido sem redirecionamento a cada interação.
- O aceite pode chegar por push, SMS ou WhatsApp no modelo com vínculo.
- O prazo de aceite do consentimento recebido por CIBA se mantém igual ao do fluxo com redirecionamento, o que é uma restrição, e não uma liberdade nova.
- O registro de pagamento passa a carregar a identificação de qual dos dois caminhos originou a transação, o que dá ao ecossistema rastreabilidade por modalidade.
Saiba mais sobre como funciona o consentimento no Open Finance aqui →
O que o mercado projeta: consentimento PJ e múltipla alçada
Do mecanismo acima nascem possibilidades que ainda não foram regulamentadas, mas que o mercado já vem antecipando.
1. Consentimento de pessoa jurídica com múltiplos representante
Se a autorização pode chegar a quem não está no canal da transação, cada sócio poderia responder no seu tempo, pelo canal que já usa, sem que a jornada inteira expire porque um deles demorou.
A leitura da Opus Open Finance é que esse seria o efeito mais relevante do CIBA no curto prazo, pela simples razão de que o consentimento de pessoa jurídica é hoje um dos pontos em que mais jornada se perde.
Essa dor tem raiz na própria dinâmica do consentimento de pessoa jurídica. É comum que ele dependa de mais de uma aprovação, o que o ecossistema chama de múltipla alçada, quando mais de um representante da empresa precisa validar antes de o consentimento valer.
Cada aprovação extra tende a significar mais um contato fora do fluxo digital, às vezes com uma etapa em papel, e é exatamente esse tipo de atrito que um canal de autorização independente da tela poderia reduzir.
2. Autorização em canais sem tela para redirecionar
Ou seja, autorização em canais onde não existe navegador. Central de atendimento, ponto de venda físico e dispositivos sem tela são ambientes em que o redirecionamento encontra limite prático, e um fluxo desacoplado poderia atendê-los sem exigir invenção nova.
3. Transação iniciada por software
Um software inicia a transação em nome de alguém, mas a aprovação continua dependendo dessa pessoa. Um mecanismo em que a autorização humana acontece fora do canal da transação poderia ser a peça que falta para viabilizar esses casos. O tema segue em aberto no mercado, sem nada definido ainda no Open Finance Brasil.
Qual é o cronograma do CIBA no Brasil?
O Conselho de Administração do Open Finance Brasil aprovou o escopo e o cronograma do Projeto CIBA, divulgados no Informa #938 em 21 de agosto de 2026. Desde então o cronograma ganhou um segundo marco de certificação, e hoje tem quatro datas.
| Marco | Date | O que pede |
| Marco A1 | 23/09/2026 | Rodar o motor de conformidade sem falhas |
| Marco A2 | 06/10/2026 | Rodar a versão nova do motor, já com os testes de pessoa física e pessoa jurídica |
| Piloto | 19/01/2027 | Sobreviver a um piloto com contrapartes reais |
| Go-live | 19/04/2027 | Operação em produção estável |
O Informa #938 esclarece que as definições de versionamento em curso não alteram as datas do piloto e do go-live.
O que ele não detalha é o que cada marco exigirá de cada participante além dos testes.
A leitura da Opus Open Finance é que os marcos pedem coisas de natureza diferente, e que tratar o cronograma como um bloco único tende a atrapalhar o planejamento.
O que já saiu do papel
O motor de conformidade do CIBA está disponível para testes desde 13 de agosto de 2026, conforme o Informa #934, com os dois perfis do fluxo contemplados:
- Relying Parties, que correspondem aos receptores
- OpenID Providers, que correspondem aos transmissores.
O mesmo informe registrava que os testes começavam pelos cenários com cliente estático, deixando para depois os cenários com cliente, registro e gestão dinâmica.
Isso significava que quem dependia de registro dinâmico não conseguia exercitar a jornada completa naquele primeiro momento, e por isso o tempo real de preparação seria menor do que o sugerido pela leitura direta do calendário.
CIBA ou JSR: qual é a diferença?
A Jornada Sem Redirecionamento e o CIBA resolvem problemas vizinhos por caminhos distintos.
A JSR trata da experiência dentro do canal do iniciador, com o vínculo de dispositivo sustentando a autenticação.
O CIBA trata da autorização que acontece fora do canal da transação. São modalidades complementares, e o cronograma aprovado trata o CIBA como uma frente própria, com marcos próprios.
Daí decorre que instituições que já colocaram a JSR em produção passam a ter duas jornadas de autenticação para manter, com testes, certificações e monitoramentos próprios.
Na leitura da Opus, é justamente nesse ponto que surge um custo muitas vezes ignorado, porque o esforço de implementar aparece no orçamento uma vez, enquanto o de operar reaparece a cada mês.
Saiba mais sobre o que é e como funciona a Jornada Sem Redirecionamento (JSR) no Open Finance aqui →
Quando o CIBA não é prioridade agora
Nem toda instituição precisa tratar o CIBA como assunto imediato, e vale dizer em que casos o adiamento é a decisão certa.
1. JSR ainda não estabilizada
Quem ainda não estabilizou a Jornada Sem Redirecionamento tem um problema mais próximo e mais caro na frente. Rodar duas frentes de autenticação em paralelo, com uma delas ainda instável, produz um resultado pior do que terminar a primeira.
2. Sem caso de uso fora do canal
Quem não tem caso de uso de autorização fora do canal também pode esperar. Uma operação inteiramente concentrada em jornada digital própria, com o pagador sempre presente no mesmo dispositivo, extrai pouco valor imediato do fluxo desacoplado.
3. Outro prazo competindo pelo mesmo time
Há ainda quem tenha um prazo regulatório mais próximo competindo pelo mesmo time. O calendário do ecossistema concentra outras exigências no mesmo período, entre elas a adequação ao perfil FAPI-BR 2.2.1, com prazo em 30 de outubro de 2026, e priorização é uma escolha legítima quando é feita com consciência do que fica para depois.
Em todos esses casos, adiar a implementação não significa adiar a leitura. O go-live de abril de 2027 pressupõe um piloto em janeiro, e quem chegar em janeiro sem ter formado opinião sobre qual dos dois modelos quer implementar vai decidir sob pressão.
And what does this mean for my business?
Três perguntas ajudam a transformar o cronograma em plano.
Qual dos dois modelos, com vínculo ou sem vínculo, corresponde à jornada que a sua operação já tem? A resposta define o esforço, e quem responde primeiro é o time de produto.
Quantas jornadas de autenticação a sua instituição vai sustentar em produção ao mesmo tempo em abril de 2027, e quem responde pela operação de cada uma?
O seu Authorization Server suporta fluxo desacoplado hoje, ou isso entra como desenvolvimento novo? É a pergunta que separa um ajuste de configuração de um projeto.
How can Opus Open Finance help?
A pergunta sobre o Authorization Server é a que mais aparece nas conversas com times de implementação, porque costuma revelar dependências que não estavam no plano.
Identificá-las cedo dá à instituição mais tempo para escolher o caminho em vez de reagir ao prazo.
With +35 anos de mercado, A Opus Open Finance fornece plataforma modular para os quatro perfis do ecossistema.
With Authorization e FIDO Sever proprietários, a Opus assume a complexidade regulatória para que seu time se concentre no que realmente importa: gerar valor para o negócio.
Quer entender como aplicar isso na sua operação? Fale com os especialistas da Opus Open Finance →
FAQ
O que é CIBA no Open Finance?
CIBA é a sigla de Client Initiated Backchannel Authentication, o protocolo de autenticação desacoplada do Open Finance Brasil. Ele permite obter o consentimento do cliente sem exigir redirecionamento ao aplicativo do detentor da conta a cada interação.
O que é autenticação desacoplada?
É o modelo em que o dispositivo que consome a API e o dispositivo em que a pessoa autentica são distintos. A transação segue em um canal e a autorização chega por outro.
O aceite do consentimento pode chegar por WhatsApp?
A especificação CIBA-BR nomeia push, SMS e mensagem por WhatsApp entre os canais de notificação possíveis no modelo com vínculo, depois que a relação entre cliente e conta já foi estabelecida.
Quando o CIBA entra em produção no Brasil?
O go-live em produção está marcado para 19 de abril de 2027, com piloto a partir de 19 de janeiro de 2027. Os dois marcos de certificação anteriores foram o A1, em 23 de setembro de 2026, e o A2, em 6 de outubro de 2026.
O que é múltipla alçada no consentimento de pessoa jurídica?
É quando mais de um representante da empresa precisa validar antes de o consentimento valer. Cada aprovação extra tende a significar mais um contato fora do fluxo digital, e é um dos pontos em que mais jornada se perde hoje.
O CIBA resolve o consentimento de pessoa jurídica com vários sócios?
Essa é a possibilidade mais citada pelo mercado, porque a autorização poderia chegar a cada representante pelo canal que ele já usa, sem que a jornada expire. O uso não está regulamentado, e a especificação hoje descreve o mecanismo, não esse caso de uso.
O CIBA vale para todos os participantes do Open Finance?
O Perfil CIBA de Segurança do Open Finance Brasil 2.0 declara que se aplica a todos os participantes do Open Finance no Brasil.
CIBA substitui a Jornada Sem Redirecionamento?
Não. As duas são modalidades complementares. A JSR trata da autenticação dentro do canal do iniciador, e o CIBA trata da autorização que acontece fora do canal da transação.
Qual a diferença entre os modelos com vínculo e sem vínculo?
No modelo com vínculo há um redirecionamento inicial que estabelece a relação entre cliente e conta, e os pedidos seguintes chegam por canal de notificação. No modelo sem vínculo não existe esse primeiro redirecionamento, e o pedido parte direto pelo canal paralelo.
