v2.0.1 – Problemas conhecidos
Disponibilizamos a lista de problemas conhecidos das especificações da API da Fase 2 na versão 2.0.1, contendo orientações às instituições participantes até que se publiquem as correções.
Este arquivo poderá ser atualizado conforme novos itens sejam identificados.
Sua eventual atualização será previamente comunicada através dos informes do Open Finance Brasil.
ID | Solucionado? | Crítico | API / Sessão | Endpoint | Campo | Como está? Qual o problema? | Como deveria ser? | Orientação até publicação do ajuste | Responsável | Dicionário OK? | Swagger OK? | Comentário |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
BCLOG-F02-198 |
| Sim | Todas da Fase 2 | Todos da Fase 2 | O campo self dentro do objeto links | Não existe uma definição clara de como este campo deve ser utilizado | O atributo self no caso de uso do methodo GET deverá retonar o link para a propria pagina. No caso do methodo Post deverá retonar o link para o recurso criado | O atributo self do objeto link: | Força Tarefa | Sim | Sim | Precisa ser ajustado no portal do desenvolvedor |
BCLOG-F02-199 | Sim | Sim | Credit-card-accounts | /accounts/{creditCardAccountId}/bills/{billId}/transactions | /data/ chargeIdentificator | Campo está como obrigatório | Condicionado (opcional + restrição) ao pagamento ter parcelas Descrição: [Restrição] O campo deve ser preenchido quando houver parcelas relacionadas a transação. | Identificador da parcela que está sendo informada. Campo de livre preenchimento quando existir parcelas. | GT Especificações | Não | Não |
|
BCLOG-F02-200 | Sim | Sim | API Recursos | /resources | - | A previsão de resposta 202 não está contemplada no Swagger | A resposta 202 deveria ter sido declarada | A instituições receptoras devem aceitar o http Status 202 body vazio e adotar o comportamento descrito nas páginas 68, 74 e 88 do Guia de Implementação das APIs da Fase 2: | GT Especificações | Sim | Não | O guia de implementação teve suas informações distribuídas para as páginas de orientações de acordo com a API à qual a orientação se refere |
BCLOG-F02-201 |
| Sim | Todas as APIs de crédito | /contracts /contracts/{contractId} | /ipocCode | Hoje o pattern ( ^\d{22,67}$ ) aplicado inviabiliza a utilização de caracteres alfabéticos, na composição do ipocCode | O REGEX precisa ser corrigido levando em consideração as regras do IPOC | Utilizar o pattern ^[\w\W]{22,67}$ | GT Especificações | Não | Não |
|
BCLOG-F02-202 |
| Sim | Todas as APIs de crédito | /contracts | /contractNumber | Hoje o pattern ( ^\d{1,100}$ ) aplicado inviabiliza a utilização de caracteres alfabéticos, na composição do contractNumber | O REGEX precisa ser corrigido para que viabilize o preenchimento com caracteres alfabéticos e especiais | Utilizar o pattern ^[\w\W]{1,100}$ | GT Especificações | Não | Não |
|
BCLOG-F02-203 |
| Sim | Todas as APIs de crédito | /contracts/{contractId}/scheduled-instalments | /paidInstalments /dueInstalments /pastDueInstalments | Atualmente o tamanho máximo dos atributos paidInstalments, dueInstalments e pastDueInstalments, está em 999, porém existem cenários de parcelas que podem chegar até 4 dígitos,. | Revisar os três campos para levar em consideração maximum do campo /totalNumberOfInstalments | Considerar maximum: 999999999 | GT Especificações | Não | Não |
|
BCLOG-F02-204 | Sim | Não | API Consents | - | Descrição do Swagger | Alteração obrigatória do status AWAITING_AUTHORISATION para REVOKED após 60 minutos | Alteração obrigatória do status AWAITING_AUTHORISATION para REJECTED após 60 minutos | Seguir o diagrama de estados de consentimentos, descrito no Guia de implementação da v2.0 das APIs de Dados Cadastrais e Transacionais | GT Especificações | Sim | Sim | O guia de implementação teve suas informações distribuídas para as páginas de orientações de acordo com a API à qual a orientação se refere |
BCLOG-F02-205 |
| Sim | Todas as APIs de crédito | /contracts/{contractId} | /preFixedRate | Nas APIs de crédito, os campos preFixedRate e postFixedRate estão como obrigatórios, porém, os contratos possuem características de possuir somente uma das taxas, ou pré-fixada ou pós-fixada. Anteriormente, era permitido o envio de NULL | Os campos deveriam ser opcionais ou condicionais | Preencher o campo não aplicável ao contrato com zeros, seguindo o pattern (0.000000) | GT Especificações | Não | Não | Este problema conhecido foi substituído pelo BCLOG-F02-217 |
BCLOG-F02-206 |
| Sim | Credit-card-accounts | /transactions | /billPostDate | O Campo billPostDate é obrigatório da API de Cartão de crédito, ENDPOINT /accounts/{creditCardAccountId}/transactions, porém, as transações são enviadas de forma online, conforme uso do cliente, antes da postagem na fatura, portanto, nesse momento, não há a Data em que a transação foi inserida na fatura ainda | O campo deveria ser opcional | Preencher o campo com a data dummy: 0001-01-01, apenas para os casos nos quais ainda não houver a data de inserção na fatura | GT Especificações | Não | Não |
|
BCLOG-F02-207 |
| Não | Credit-card-accounts | /limits | pagination-key (parâmetro) | O endpoint limits prevê o uso do parâmetro pagination-key, entretanto, não possui os parâmetros page e pagesize, o que inviabiliza o seu uso | O parâmetro pagination-key não deveria existir ou ele poderia existir complementado pelos parâmetros page e pagesize | Não utilizar o parâmetro pagination-key para este endpoint | GT Especificações | Sim | Não |
|
BCLOG-F02-208 |
| Não | Accounts | /transactions /transactions-current | /partieCompeCode | A descrição do campo indica a possibilidade de informar NA porém o pattern não permite | A descrição do campo não deveria indicar a possibilidade de informar NA no campo | Não informar NA | GT Especificações | Não | Não |
|
BCLOG-F02-209 |
| Não | Accounts | /accounts/{accountId} | /compeCode | A descrição do campo indica a possibilidade de informar NA porém o pattern não permite | A descrição do campo não deveria indicar a possibilidade de informar NA no campo | Não informar NA | GT Especificações | Não | Não |
|
BCLOG-F02-210 |
| Sim | Accounts | /accounts/{accountId} /accounts/{accountId}/balances /accounts/{accountId}/transactions /accounts/{accountId}/transactions-current /accounts/{accountId}/overdraft-limits | - | Na tabela descritiva das possibilidades de interação entre API de Recursos (Resources) e API de Contas (Accounts) página 73, do Guia de Implementação das APIs de Dados Cadastrais e Transacionais, não foi definido um código de erro para o cenário: Com consentimento autorizado (conta inexistente) | Deveria existir um código de erro padronizado para esta situação | Utilizar o Status 403 com o código de erro: RESOURCE_FORBIDDEN | GT Especificações | Sim | Sim | Esta situação se aplica tanto para contas inexistentes, quanto para contas que existem mas não estejam no consentimento. O guia de implementação teve suas informações distribuídas para as páginas de orientações de acordo com a API à qual a orientação se refere |
BCLOG-F02-211 |
| Sim | Credit-card-accounts | /accounts/{creditCardAccountId} /accounts/{creditCardAccountId}/bills /accounts/{creditCardAccountId}/bills/{billId}/transactions /accounts/{creditCardAccountId}/limits /accounts/{creditCardAccountId}/transactions /accounts/{creditCardAccountId}/transactions-current | - | Na tabela descritiva das possibilidades de interação entre API de Recursos (Resources) e API de Cartões de Crédito (Credit-card-accounts) (Análoga ao caso de Accounts) página 83, do Guia de Implementação das APIs de Dados Cadastrais e Transacionais, foi definido o uso do HTTP Status 404 para o cenário: Com consentimento autorizado (conta inexistente) | Deveria ser utilizado o HTTP Status 403 como o código de erro padronizado para esta situação | Utilizar o status 403 com o código de erro: RESOURCE_FORBIDDEN | GT Especificações | Sim | Sim | Esta situação se aplica tanto para contas inexistentes, quanto para contas que existem mas não estejam no consentimento. O guia de implementação teve suas informações distribuídas para as páginas de orientações de acordo com a API à qual a orientação se refere |
BCLOG-F02-212 | 0 | Sim | Todas as APIs de crédito | /contracts/{contractId} /contracts/{contractId}/warranties /contracts/{contractId}/scheduled-instalments /contracts/{contractId}/payments | - | Na tabela descritiva das possibilidades de interação entre API de Recursos (Resources) e as APIs de Operações de Crédito na página 105, do Guia de Implementação das APIs de Dados Cadastrais e Transacionais, foi definido o uso do HTTP Status 404 para o cenário: Com consentimento autorizado (recurso inexistente) | Deveria ser utilizado o HTTP Status 403 como o código de erro padronizado para esta situação | Utilizar o status 403 com o código de erro: RESOURCE_FORBIDDEN | GT Especificações | Sim | Sim | Esta situação se aplica tanto para contas inexistentes, quanto para contas que existem mas não estejam no consentimento. O guia de implementação teve suas informações distribuídas para as páginas de orientações de acordo com a API à qual a orientação se refere |
BCLOG-F02-213 |
| Sim | Todas as APIs de crédito | /contracts/{contractId} /contracts/{contractId}/warranties /contracts/{contractId}/scheduled-instalments /contracts/{contractId}/payments | - | Na tabela descritiva das possibilidades de interação entre API de Recursos (Resources) e as APIs de Operações de Crédito na página 103, do Guia de Implementação das APIs de Dados Cadastrais e Transacionais, foi definido o uso do HTTP Status 404 para o cenário: Com consentimento autorizado (aprovado múltipla alçada) | Deveria ser utilizado o HTTP Status 403 como o código de erro padronizado para esta situação | Utilizar o status 403 com o código de erro: RESOURCE_FORBIDDEN | GT Especificações | Sim | Sim | Esta situação se aplica tanto para contas inexistentes, quanto para contas que existem mas não estejam no consentimento. O guia de implementação teve suas informações distribuídas para as páginas de orientações de acordo com a API à qual a orientação se refere |
BCLOG-F02-214 |
| Sim | Accounts | /accounts/{accountId}/balances | /data/automaticallyInvestedAmount/amount | O pattern do campo não permite valores negativos e por regra de negócio será um cenário possível | O pattern deveria aceitar valores negativos | Instituições Financeiras devem considerar: string($double)pattern: ^-?\d{1,15}\.\d{2,4}$maxLength: 21 | GT Especificações | Não | Não |
|
BCLOG-F02-215 |
| Sim | Accounts Customers Credit-card-accounts | Todos (exceto listagem) | errors/code (quando ocorre um erro 403) | Nas págs 70, 77 e 101-106 temos o código definido fora do padrão contendo letras maiúsculas e minúsculas, conforme abaixo: status_RESOURCE_PENDING_AUTHORISATION status_RESOURCE_UNAVAILABLE status_RESOURCE_TEMPORARILY_UNAVAILABLE | Os códigos deveriam ter apenas letras maiúsculas, conforme abaixo: STATUS_RESOURCE_PENDING_AUTHORISATION STATUS_RESOURCE_UNAVAILABLE STATUS_RESOURCE_TEMPORARILY_UNAVAILABLE | Utilizar o formato com letras maiúsculas | GT Especificações | Sim | Sim |
|
BCLOG-F02-216 |
| Sim | Customers | /personal/identifications /business/identifications | /data/contacts/phones/number | O pattern ^([0-9]{8,11})$ do campo data/contacts/phones/number não é adequado para telefones de alguns países (ex: Alemanha), que podem ter a quantidade de números inferiores a 8 ou superiores a 11 | O pattern deveria contemplar a quantidade de dígitos de telefone de todos os países | Neste momento não devem ser compartilhados telefones de outros países além do Brasil, ou seja, não compartilhar telefones com DDI diferente de 55 | GT Especificações | Não | Não |
|
BCLOG-F02-217 |
| Sim | Loans Unarranged-accounts-overdraft | /contracts/{contractId} | /preFixedRate /postFixedRate | Nas APIs Loans e Unarranged-accounts-overdraft, os campos preFixedRate e postFixedRate estão como obrigatórios, porém, os contratos possuem características de possuir somente uma das taxas, ou pré-fixada ou pós-fixada. Anteriormente, era permitido o envio de NULL | Os campos deveriam ser opcionais ou condicionais | Preencher o campo não aplicável ao contrato com zeros, seguindo o pattern (0.000000) | GT Especificações | Não | Não |
|
BCLOG-F02-218 |
| Sim | Unarranged-accounts-overdraft | /contracts/{contractId} | /instalmentPeriodicityAdditionalInfo /amortizationScheduledAdditionalInfo | Na API Unarranged-accounts-overdraft, os campos instalmentPeriodicityAdditionalInfo e | Os campos deveriam ser opcionais ou condicionais | Preencher os campos com string vazia ("") | GT Especificações | Não | Não |
|
BCLOG-F02-219 |
| Sim | Customers | /business/identifications | /data/contacts/postalAddresses | A lista de objetos /data/contacts/postalAddresses que está no Endpoint /business/identifications da versão 2.0.1 exige no mínimo um objeto, ou seja, um endereço que nem sempre existe para os cadastros PJ | Deveria ser adotada a mesma proposta do endpoint /personal/identifications, que permite uma lista vazia | Caso não exista um endereço a ser comunicado, criar um objeto "Dummy" com os seguintes valores para seus atributos: | GT Especificações | Não | Não |
|
BCLOG-F02-220 |
| Sim | Customers | /business/identifications | /address /townName | O REGEX ('^\w{2}[\w\W\s]*$') dos campos não permite o uso de abreviaturas no início do nome | O REGEX deveria permitir abreviaturas | Utilizar o pattern [\w\W\s]* | GT Especificações | Não | Não |
|
BCLOG-F02-221 |
| Sim | Accounts | /transactions /transactions-current | - | Regras para consulta de lançamentos futuros não são claras | Regras de lançametos futuros devem ser revistas | Conforme descrição, os endpoints /transactions e /transactions-current devem retornar às transações realizadas e os lançamentos futuros. Desta forma, para se obter os lançamentos futuros, deverá ser fornecido o intervalo de datas contemplando as datas do lançamento futuro. A consulta de lançamentos futuros estará restrita a 12 meses no futuro. | GT Especificações | Sim | Sim |
|
BCLOG-F02-222 |
| Sim | Todas as APIs de crédito | /contracts/{contractId}/warranties |
WarrantyType | A opção SEM_TIPO_GARANTIA foi removida do ENUM definido para o campo WarrantyType, que continua como obrigatório. Alguns tipos de operações de crédito não possuem garantia e precisariam de tal opção | Deveria haver a possibilidade de preenchimento do campo com o ENUM adequado para operações que não possuem garantias ou o campo ser opcional | Considerar como opção válida o ENUM SEM_TIPO_GARANTIA | GT Especificações | Não | Não |
|
BCLOG-F02-223 |
| Sim | Customers | /business/identifications | /data/parties/civilName | A restrição está orientando o preenchimento obrigatório quando o person type for PESSOA_JURIDICA | O correto deveria ser PESSOA_NATURAL |
[Restrição] O campo civilName deve ser obrigatoriamente preenchido quando personType for PESSOA_NATURAL. | GT Especificações | Não | Não |
|
BCLOG-F02-224 |
|
|
|
|
|
|
|
|
|
|
| ID utlizado para criação de um item na planilha de problemas conhecidos da v1.x da fase 2 |
BCLOG-F02-225 |
| Não | Invoice Financings | /contracts/{contractId}/payments | paymentId | O pattern aplicado para paymentId diverge do utilizado para o mesmo campo em outros endpoints das demais APIs de operações de crédito | O correto deveria ser ^[a-zA-Z0-9][a-zA-Z0-9-]{0,99}$ | Considerar o pattern ^[a-zA-Z0-9][a-zA-Z0-9-]{0,99}$ | GT Especificações Dados do cliente | Não | Não |
|
BCLOG-F02-226 |
|
|
|
|
|
|
|
|
|
|
| ID utlizado para criação de um item na planilha de problemas conhecidos da v1.x da fase 2 |
BCLOG-F02-227 |
| Não | Todas da Fase 2 | Todos | x-fapi-interaction-ID | Na documentação de segurança, o x-fapi-interaction-ID não precisa ser gerado pelo consumidor do serviço, o que pode gerar inconsistências na Plataforma de Coleta de Métricas (PCM) na ocorrência de erros de integração entre consumidor e provedor | Alterar especificação de forma a tornar o x-fapi-interaction-ID obrigatório para envio pelo consumidor do serviço (receptor de dados) | Informar cabeçalho x-fapi-interaction-id obrigatoriamente na requisição | GT Especificações Dados do cliente | Sim | Não | Problema conhecido substituído pelo BCLOG-F02-228 |
BCLOG-F02-228 |
| Não | Todas da Fase 2 | Todos | x-fapi-interaction-ID | Na documentação atual de segurança, o x-fapi-interaction-ID não tem geração obrigatória pelo consumidor do serviço, entretanto a IN306, na sua seção 5.2, determina que o seu envio seja obrigatoriamente feito pelo consumidor do serviço (receptor). Esta informação necessita ser enviada pelo consumidor e pelo provedor à Plataforma de Coleta de Métricas – PCM e também é necessária na abertura de tickets bilaterais no Service Desk | O x-fapi-interaction-ID é de geração e envio obrigatório pela receptora (client) e o seu valor deve ser "reproduzido" pela transmissora (server) no cabeçalho de resposta | Para a receptora (client)
Para a transmissora (server)
| GT Especificações Dados do cliente | Sim | Não |
|
BCLOG-F02-229 |
| Não | API Accounts |
|
| Existe a possibilidade de alguns tipos de conta não possuírem limites associados. Para esses cenários o endpoint espera que nenhum dado seja preenchido no objeto “data” (objetos internos opcionais), porém não existem instruções detalhadas sobre esse cenário e isto gerou dúvidas sobre qual o comportamento correto para algumas instituições | A descrição da API deveria explicitar o comportamento para este cenário | Para as instituições financeiras transmissoras que tenham contas nessa situação a orientação é retornar HTTP Status 200 com o objeto “data” vazio, sem nenhum atributo interno | GT Especificações Dados do cliente | Sim | Não |
|
BCLOG-F02-230 |
| Não | API Credit Cards Accounts | GET /credit-cards-accounts/v2/accounts | name e creditCardNetwork | Para algumas instituições os campos “name” e “creditCardNetwork” podem retornar nomes de bandeira distintos para o cenário de troca de bandeira de conta cartão. Por exemplo: name=”INSTITUIÇÃO MASTERCARD” , (herda o nome da conta cartão com a nova bandeira) e creditCardNetwork=”VISA” (herda a bandeira do cartão físico em uso e quando a ativação do novo cartão é feita a bandeira assume a da conta cartão). | Em cenários ideais, o nome da bandeira contido no nome do cartão de crédito deveria ser coerente com o nome da bandeira informada no campo “creditCardNetwork”. | As instituições financeiras receptoras de dados devem estar cientes de que em situações específicas podem haver divergências entre o nome do cartão e a bandeira. Está no backlog do GT o levantamento de regras de negócio que impliquem nesse cenário. | GT Especificações Dados do cliente | Sim | Não |
|
BCLOG-F02-231 |
|
| Todas de Operações de Crédito | Warranties | - | A documentação da API não dá clareza de como tratar produtos nos quais não se aplica o produto de garantia | Nos casos em que não haja garantia para o produto deve se enviar lista vazia para o campo data | Enviar lista vazia para o campo data caso não haja garantia |
| Não | Não | Desconsiderar a orientação dada no BCLOG-F02-222 |