[Open Finance] Informa #912

Informe nº 912 | 23/06/2026

API Contas – Informações da Contraparte

Conforme pauta apresentada e discutida no GT de Dados do Cliente, na data 23/06/206, sobre o envio das informações de identificação de contraparte (CPF ou CNPJ) destacamos que do ponto de vista da especificação técnica, a API está em conformidade com o que está disposto na IN 724 no que tange a possibilidade de envio de dados da contraparte aliado a tabela de contraparte que informa quais condições tornam o envio obrigatório.

Ressaltamos que embora o campo seja opcional tecnicamente, as casas devem observar a condicionalidade de envio de acordo com critérios estabelecidos pela IN 724 e a tabela de contraparte encontrada na área do desenvolvedor, o não envio das informações em caso de obrigatoriedade poderá gerar um apontamento de não conformidade das regras estabelecidas.

Para os tipos classificados como S na documentação, o envio da contraparte é obrigatório; para os tipos classificados como N, não é obrigatório; e para os classificados como R, o tratamento permanece em avaliação pelo Banco Central​, conforme tabela disponível na área do desenvolvedor.

Clarificação sobre escopos associados ao refresh_token

Prezados participantes,

Durante os testes da Jornada Otimizada, foi identificada uma divergência de interpretação sobre o comportamento esperado na renovação de access_token por meio de refresh_token, especialmente quando o receptor/iniciador solicita apenas parte dos escopos originalmente autorizados pelo cliente.

A Associação Open Finance Brasil esclarece que, quando um refresh_token estiver associado a consentimentos válidos, o Authorization Server deve manter como referência a base de escopos originalmente autorizada pelo cliente.

Assim, a solicitação ou emissão de um access_token com subconjunto de escopos pode limitar o token emitido naquela renovação específica, mas não deve reduzir permanentemente a base de escopos elegíveis associada ao refresh_token.

Esse entendimento é aplicável à Jornada Otimizada e aos demais cenários do Open Finance Brasil em que um refresh_token esteja associado a múltiplos escopos, independentemente de estarem relacionados a dados, pagamentos ou outros produtos do ecossistema.

O fundamento principal é que a autorização realizada pelo cliente representa a manifestação explícita de sua vontade quanto aos dados e/ou serviços autorizados. Já a renovação de access_token por meio de refresh_token é uma etapa técnica para execução das APIs e não representa, por si só, alteração dessa manifestação de vontade.

Esse entendimento será refletido no Perfil de Segurança FAPI-BR como clarificação do comportamento esperado, com o objetivo de promover interpretação uniforme pelos participantes.

Atenciosamente,

Associação Open Finance Brasil

CNPJ Alfanumérico | Alterações e Orientações complementares relacionadas aos Testes de Sandbox — Open Finance Brasil

Motor disponível em: 29/06/2026 | Período de testes: 01/07/2026 a 31/07/2026

1. Orientações complementares

Em complemento ao Informe nº 904, de 02/06/2026, comunicamos a atualização e definições relacionadas aos testes de CNPJ Alfanumérico, incluindo a nova data de disponibilização do Motor de Conformidade, bem como ajustes no escopo dos testes em ambiente de sandbox.

As demais orientações publicadas anteriormente permanecem válidas, exceto quando expressamente substituídas por este comunicado.

As demais orientações publicadas anteriormente permanecem válidas, exceto quando expressamente substituídas por este comunicado.

2. Escopo das Alterações

Atualização da data de disponibilização do Motor de Conformidade para 29/06/2026.

Remoção das validações relacionadas ao CNPJ alfanumérico da instituição responsável pelo cadastro nos produtos de Dados Abertos e Dados do Cliente.

Remoção da validação relacionada ao CNPJ alfanumérico da instituição credora no produto de Portabilidade de Crédito.

Inclusão de dois novos módulos de testes para validação do suporte ao CNPJ alfanumérico no produto de Pagamentos.

Manutenção das demais orientações e obrigações estabelecidas no comunicado anterior.

3. Atualização das datas relevantes

4. Referência de APIs e Campos para o Motor de Conformidade

5. Orientações às Instituições Participantes

Garantir que os pedidos sejam aceitos e processados no novo formato contendo letras e números, desde que estejam em conformidade com as regras de validação estabelecidas pelas expressões regulares das APIs.

Sobre testes em DCR: Todos os módulos de teste conterão a etapa de registro de um Client contra o Authorization Server selecionado nas configurações (DCR) e, ao final, a etapa de deleção desse Client. A etapa de deleção será realizada automaticamente e independentemente de falha em outros steps do teste, para garantir que um novo client possa ser criado posteriormente.

Realizar a execução de todos os planos de testes, de acordo com os produtos ofertados por cada instituição.

Garantir que as APIs de Dados Abertos, Dados do Cliente, Pagamentos, Pagamentos Automáticos, Enrollments (JSR) e Portabilidade de Crédito estejam devidamente operantes antes do início do período de testes

Dados Abertos e Dados do Cliente: foram removidas validações relacionadas ao CNPJ alfanumérico da instituição responsável pelo cadastro.

Portabilidade de Crédito: foi removida a validação relacionada ao CNPJ alfanumérico da instituição credora.

Pagamentos: foram adicionados dois novos módulos de testes.

Em caso de dúvidas, recomenda-se a abertura de ticket no Service Desk.

Observação: Os sumários e módulos de testes correspondentes serão divulgados em Informe específico, a ser publicado oportunamente.