| | | | | |
|---|
Visão Geral dos Campos da PCM | 1.00 | 11/06/2026 | | 2026B | 906 - 11/06/2026 |
Dados Abertos |
Campos
Obrigatórios e
Opcionais | 1.01 | 11/06/2026 | Reestruturação da página, dando clareza dos campos que devem ser enviados no método POST da Opendata API e quais campos são retornados no response Remoção da coluna “Métodos” para evitar conflito com a reestruturação da página Inclusão da coluna “Regras de Preenchimento” processTimespan: correção do exemplo para refletir de forma correta o valor esperado statusCode: inclusão de regra de preenchimento - No contexto operacional do Open Finance, de acordo com a definição de governança, a instituição consumidora (Client) deve aguardar até 15 segundos pela resposta da instituição provedora (Server). Caso esse período seja atingido ou excedido (≥ 15 segundos) sem resposta, a instituição consumidora pode, por decisão própria e para preservar a experiência do usuário, encerrar a conexão. Nessa situação, o evento deve ser reportado com status code 408, caracterizando timeout na interação, ainda que a interrupção tenha sido iniciada pelo lado consumidor. Por sua vez, quando a instituição estiver atuando como provedora (Server) e encerrar a conexão por não ter recebido a requisição completa dentro do tempo esperado, também deverá reportar status code 408, em conformidade com a RFC 7231. endpoint: inclusão de regra de preenchimento - Identificação do Endpoint: Deve ser preenchido com o identificador padronizado do endpoint, conforme uma lista (ENUM) predefinida.Não usar o caminho real: É fundamental NÃO utilizar o caminho completo da requisição original, que inclui dados variáveis (ex: IDs).
Exemplo: Se a requisição foi para /open-banking/credit-cards-accounts/v1/accounts/123456789/transactions, o valor a ser enviado no endpoint deve ser /open-banking/credit-cards-accounts/v1/accounts/{creditCardAccountId}/transactions. O dado real 123456789 não deve ser enviado no campo endpoint processTimespan: alteração da definição - Tempo em milissegundos inteiros decorrido desde o recebimento do request até o momento imediatamente anterior ao envio do primeiro byte da resposta.
| 2026B | 906 - 11/06/2026 |
1.00 | 22/08/2025 | | 2025C | 781 - 22/08/2025 |
Regras de
Obrigatoriedade
de additionalInfo | 1.01 | 11/06/2026 | Remoção do campo tokenId, pois constava indevidamente na tabela, uma vez que o mesmo não faz parte do escopo de Dados Abertos Remoção da coluna “Regras de Preenchimento”, que estava somente replicando a coluna “Descrição” Atualização das versões de API Atendimento: v2 Previdência: v2 Seguros: v2 Títulos de Capitalização: v2 Remoção do grupo Produtos e Serviços, que foi desmembrado em grupos menores
Inclusão de novos grupos:
| 2026B | 906 - 11/06/2026 |
1.00 | 22/08/2025 | | 2025C | 781 - 22/08/2025 |
Regras de
Validação | 1.01 | 11/06/2026 | | 2026B | 906 - 11/06/2026 |
1.00 | 22/08/2025 | | 2025C | 781 - 22/08/2025 |
Regras de
Descarte | 1.01 | 11/06/2026 | | 2026B | 906 - 11/06/2026 |
1.00 | 22/08/2025 | | 2025C | 781 - 22/08/2025 |
Dados Cadastrais e Transacionais |
Campos
Obrigatórios e
Opcionais | 1.01 | 11/06/2026 | Reestruturação da página, dando clareza dos campos que devem ser enviados no método POST da Private API, quais campos são retornados no response e quais são adicionais ao método GET. Remoção da coluna “Métodos” para evitar conflito com a reestruturação da página clientSSIDd: correção nas roles obrigatórias, o correto é somente CLIENT processTimespan: correção do exemplo para refletir de forma correta o valor esperado statusCode: maior esclarecimento na regra de preenchimento - No contexto operacional do Open Finance, de acordo com a definição de governança, a instituição consumidora (Client) deve aguardar até 15 segundos pela resposta da instituição provedora (Server). Caso esse período seja atingido ou excedido (≥ 15 segundos) sem resposta, a instituição consumidora pode, por decisão própria e para preservar a experiência do usuário, encerrar a conexão. Nessa situação, o evento deve ser reportado com status code 408, caracterizando timeout na interação, ainda que a interrupção tenha sido iniciada pelo lado consumidor. Por sua vez, quando a instituição estiver atuando como provedora (Server) e encerrar a conexão por não ter recebido a requisição completa dentro do tempo esperado, também deverá reportar status code 408, em conformidade com a RFC 7231.
| 2026B | 906 - 11/06/2026 |
1.00 | 22/08/2025 | | 2025C | 781 - 22/08/2025 |
Regras de
Obrigatoriedade
de additionalInfo | 1.05 | 11/06/2026 | | 2026B | 906 - 11/06/2026 |
1.04 | 16/03/2026 | | | |
1.03 | 10/12/2025 | | | |
1.02 | 10/11/2025 | Inclusão do additionalInfo tokenId Inclusão do additionalInfo journeyIsLinked, referente à Jornada Otimizada
| 2025D | 815 - 18/11/2025 |
1.01 | 01/10/2025 | | | |
1.00 | 22/08/2025 | | 2025C | 781 - 22/08/2025 |
Regras de
Validação | 1.03 | 11/06/2026 | | 2026B | 906 - 11/06/2026 |
1.02 | 16/.03/2026 | Ajuste fino nas regras do consentId de Câmbio, Cartão de Crédito, Contas, Dados Cadastrais Retirada do endpoint %/payments/vx/consents, indevido no campo dropReason, pois é um endpoint de pagamentos
| | |
1.01 | 17/12/2025 | | | |
1.00 | 22/08/2025 | | 2025C | 781 - 22/08/2025 |
Regras de
Descarte | 1.01 | 11/06/2026 | | 2026B | 906 - 11/06/2026 |
1.00 | 22/08/2025 | | 2025C | 781 - 22/08/2025 |
Pagamentos |
Estados de
Pagamento | 1.03 | 11/06/2026 | Correção da descrição do campo paymentList, dando maior clareza quanto ao seu escopo Complemento da descrição do campo eventDateTime, incluindo o escopo de agendamento aos demais estados Complemento da regra de validação da quantidade de paymentIds distintos para um mesmo consentId, passando a validar também a data do último pagamento
| 2026B | 906 - 11/06/2026 |
1.02 | 10/12/2025 | | | |
1.01 | 03/10/2025 | | | |
1.00 | 22/08/2025 | | 2025C | 781 - 22/08/2025 |
Campos
Obrigatórios e
Opcionais | 1.01 | 11/06/2026 | |