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 apontamento	Dicionário OK?	Swagger OK?	Comentário

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 apontamento	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: 1- quando chamado methodo GET deverá retonar o link para o próprio recurso consultado. 2- quando chamado methodo POST deverá retonar o link para o recurso criado. 3- quando chamado methodo PATCH deverá retonar o link para o recurso alterado	Força Tarefa	Parcialmente	Parcialmente	A solução definitiva foi incoporada no swagger apenas para as API Contas, Cartões de Crédito, Empréstimos, Dados Cadastrais, Consentimentos e Recursos.
BCLOG-F02-199	Sim	Sim	Credit-card-accounts	/accounts/{creditCardAccountId}/bills/{billId}/transactions /accounts/{creditCardAccountId}/transactions /accounts/{creditCardAccountId}/transactions-current	/data/ chargeIdentificator	Campo está como obrigatório	Condicionado (opcional + restrição) ao pagamento ter parcelas Descrição: Identificador da parcela que está sendo informada. Campo de livre preenchimento [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. Caso não existam parcelas, para padronizar os retornos entre as instituições transmissoras, informar PARCELA_UNICA	GT Especificações	Sim	Sim	A solução indicada na coluna "Orientação até a publicação do ajuste" foi incorporada no swagger. A solução definitiva foi incluída no backlog do GT Dados do Cliente para tratamento futuro.
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: "RN003: caso a Transmissora ainda esteja preparando a listagem dos recursos autorizados da API de Recursos (Resources), deve ser retornado o código HTTP Status Code 202 - accepted com o body vazio e a Receptora deverá seguir as recomendações de polling"	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	Parcialmente	Parcialmente	A solução indicada na coluna "Orientação até a publicação do ajuste" foi incorporada no swagger apenas para a API Empréstimos.
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	Parcialmente	Parcialmente	A solução indicada na coluna "Orientação até a publicação do ajuste" foi incorporada no swagger apenas para a API Empréstimos.
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	Parcialmente	Parcialmente	A solução indicada na coluna "Orientação até a publicação do ajuste" foi incorporada no swagger apenas para a API Empréstimos.
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 /postFixedRate	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	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	Sim	Sim	A solução indicada na coluna "Orientação até a publicação do ajuste" foi incorporada no swagger. A solução definitiva foi incluída no backlog do GT Dados do Cliente para tratamento futuro.
BCLOG-F02-207	SIM	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	Sim	A solução indicada na coluna "Orientação até a publicação do ajuste" foi incorporada no swagger. A solução definitiva foi incluída no backlog do GT Dados do Cliente para tratamento futuro.
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	Sim	Sim	A solução indicada na coluna "Orientação até a publicação do ajuste" foi incorporada no swagger. A solução definitiva foi incluída no backlog do GT Dados do Cliente para tratamento futuro.
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	Sim	Sim	A solução indicada na coluna "Orientação até a publicação do ajuste" foi incorporada no swagger. A solução definitiva foi incluída no backlog do GT Dados do Cliente para tratamento futuro.
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 minLength: 4 example: 1000.0400	GT Especificações	Sim	Sim	A solução indicada na coluna "Orientação até a publicação do ajuste" foi incorporada no swagger. A solução definitiva foi incluída no backlog do GT Dados do Cliente para tratamento futuro.
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	Sim	Sim
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	Sim	Sim	A solução indicada na coluna "Orientação até a publicação do ajuste" foi incorporada no swagger. A solução definitiva foi incluída no backlog do GT Dados do Cliente para tratamento futuro.
BCLOG-F02-218		Sim	Unarranged-accounts-overdraft	/contracts/{contractId}	/instalmentPeriodicityAdditionalInfo /amortizationScheduledAdditionalInfo	Na API Unarranged-accounts-overdraft, os campos instalmentPeriodicityAdditionalInfo e amortizationScheduledAdditionalInfo estão como obrigatórios, porém, deveriam ser condicionais e portanto não obrigatórios	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: isMain: FALSE townName: string vazia ("") country: string vazia ("") countryCode: ("XXX")	GT Especificações	Sim	Sim	A solução indicada na coluna "Orientação até a publicação do ajuste" foi incorporada no swagger. A solução definitiva foi incluída no backlog do GT Dados do Cliente para tratamento futuro.
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	Sim	Sim	A solução indicada na coluna "Orientação até a publicação do ajuste" foi incorporada no swagger. A solução definitiva foi incluída no backlog do GT Dados do Cliente para tratamento futuro.
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. Resumidamente, o endpoint /transactions permite uma consulta que se estende em 12 meses no passado mais 12 meses no futuro e o endpoint /transactions-current permite uma consulta dos últimos 7 dias mais 12 meses no futuro. Lembrando que, quando os filtros de datas não são informados, o dia corrente é adotado como data inicial e final. Portanto, os lançamentos futuros não serão retornados.	GT Especificações	Sim	Sim	A orientação até publicação" foi incorporada no swagger. A solução definitiva foi incluída no backlog do GT Dados do cliente para discussão futura.
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	Sim	Sim	A solução indicada na coluna "Orientação até a publicação do ajuste" foi incorporada no swagger. A solução definitiva foi incluída no backlog do GT Dados do Cliente para tratamento futuro.
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 GT Especificações Serviços GT Segurança GT Arquitetura	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) Caso já haja geração e envio do x-fapi-interaction-ID, não são necessários ajustes Caso não haja geração, deve haver adequação a orientação desse problema conhecido Para a transmissora (server) Não deve haver a devolução de um código de erro nos casos em que não houver o envio do x-fapi-interaction-ID pela receptora durante o período de adequação da mesma Deve ser seguida a orientação do item 6.2.1.11 do FAPI Profile 1.0 – Baseline: Final: Financial-grade API Security Profile 1.0 - Part 1: Baseline	GT Especificações Dados do cliente GT Especificações Serviços GT Segurança GT Arquitetura	Parcialmente	Parcialmente	A solução definitiva foi incoporada no swagger apenas para as API Contas, Cartões de Crédito, Empréstimos, Dados Cadastrais, Consentimentos e Recursos.
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	Sim	A solução indicada na coluna "Orientação até a publicação do ajuste" foi incorporada no swagger. A solução definitiva foi incluída no backlog do GT Dados do Cliente para tratamento futuro.
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	Sim	A solução indicada na coluna "Orientação até a publicação do ajuste" foi incorporada no swagger. A solução definitiva foi incluída no backlog do GT Dados do Cliente para tratamento futuro.
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		Parcialmente	Parcialmente	Desconsiderar a orientação dada no BCLOG-F02-222 A solução indicada na coluna "Orientação até a publicação do ajuste" foi incorporada no swagger apenas para a API Empréstimos.

Draft - Área do Desenvolvedor

v2.0.1 – Problemas conhecidos

Related pages