FAQ Geral

Como tratar campos Obrigatórios?

No Github, item Padrões – Convenções de payload – Atributos vazios / nulos encontram-se as orientações solicitadas quanto ao tratamento de campos: obrigatórios, opcionais e condicionais.

"Um atributo omitido (ou seja, um atributo que não está presente no payload) será considerado equivalente a um atributo que esteja presente com o valor null.

Uma string vazia (“”) não será considerada equivalente a null.

O valor booleano false não será considerado equivalente a null. Os atributos booleanos opcionais, por definição, possuirão três valores possíveis: verdadeiro (true), falso (false) e indeterminado (null).

Na situação onde o campo a ser informado no payload seja obrigatório e a Instituição, seja consumidora no envio ou transmissora no retorno, não a possuir, deve-se implementar o valor padronizado: “NA” - Não se Aplica, com exceção dos campos declarados como ENUM que deverão ser sempre preenchidos com os valores válidos para o ENUM correspondente."

Como tratar campos Opcionais?

No Github, item Padrões – Convenções de payload – Atributos vazios / nulos encontram-se as orientações solicitadas quanto ao tratamento de campos: obrigatórios, opcionais e condicionais.

"Um atributo omitido (ou seja, um atributo que não está presente no payload) será considerado equivalente a um atributo que esteja presente com o valor null.

Uma string vazia (“”) não será considerada equivalente a null.

O valor booleano false não será considerado equivalente a null. Os atributos booleanos opcionais, por definição, possuirão três valores possíveis: verdadeiro (true), falso (false) e indeterminado (null).

Na situação onde o campo a ser informado no payload seja obrigatório e a Instituição, seja consumidora no envio ou transmissora no retorno, não a possuir, deve-se implementar o valor padronizado: “NA” - Não se Aplica, com exceção dos campos declarados como ENUM que deverão ser sempre preenchidos com os valores válidos para o ENUM correspondente."

Por que todos os campos com domínio definidos não tem tamanho explicitado no dicionário de dados?

Por Padrão, explicitado no item Tipos de Dados Comuns, no Github, todos os possíveis conteúdos de Enum estão declarados. Não é informado o tamanho para este tipo de dado. Cada instituição definirá o tamanho máximo a ser adotado. Como regra observar que o tamanho máximo deve ser igual ou maior ao tamanho total da maior ocorrência da lista.

No momento, o compartilhamento dos dados relativos aos Terminais de autoatendimento compartilhados é facultativo?

A normativa nº 35 explicita a existência da API de Terminais de autoatendimento compartilhado, por isso o Github traz esta estrutura. Num primeiro momento, foi declarado através da normativa nº 35 que todos seus atributos são opcionais.

De que tipo de terminal o regulador está se referindo, pois temos algumas situações distintas em nossa instituição:

1. Terminais de nossa propriedade cujo demais bancos firmam convênio para que seus clientes os utilizem

2. Terminais de terceiros como Saque e Pague e Banco 24h, que possuímos convênio para uso de nossos clientes.

Para o segundo caso, se for esse o foco do pedido do regulador, não teremos os dados de forma atualizada para informar via API, uma vez que tal informação estará disponível no proprietário do terminal, como por exemplo a TecBan? Se precisarmos informar tais dados, não teremos como nos responsabilizar pela veracidade e integridade do mesmo.

O item 2.4.2, sobre terminais de autoatendimento compartilhados, do ANEXO À INSTRUÇÃO NORMATIVA BCB Nº 35, de 2020, , refere-se exatamente aos terminais de propriedade de terceiros, a exemplo do Saque e Pague e Banco 24h citados, contratados pelas instituições para a prestação de serviços a seus clientes. No que diz respeito à veracidade e à integridade dos dados fornecidos, trata-se de responsabilidade da instituição participante, conforme dispõe o art. 31 da Resolução Conjunta n.º 1, de 2020.

Na normativa nº 35, do BCB, para Correspondente Bancário os atributos weekday e phonestype aparecem como opcional, mas no Github aparecem como obrigatórios isto está correto?

O atributo weekday faz parte da lista availability, assim como phonestype faz parte da lista phones. As listas estão classificadas como opcionais, portanto caso a Instituição não tenha valores para informar em availability ou em phones estas listas como um todo estão classificadas opcionais não aparecerão na resposta solicitada. Porém, caso haja conteúdo a ser informado na lista availability ou phones o preenchimento dos atributos do tipo Enum: weekday ou phonestype passam a ser obrigatórios. Por isso estão assim classificados, seguindo protocolos das melhores práticas.

Sendo consideradas somente as operações “contratadas” no mês da apuração no cálculo e disponibilização de informações relativas a distribuição de frequência de Taxas remuneratórias.

• Modalidades de crédito disponíveis para oferta que não tiveram nenhuma contratação no mês da apuração serão informadas trazendo este conjunto de informações ‘vazio’?

  • R.: Deve-se reportar a modalidade com o valor das taxas e tarifas representados como N/A (justamente para diferenciar de casos em que não oferecemos os produtos, nos quais não reportamos a modalidade, ou no caso de tarifa zerada, que efetivamente viria com um “0”).

• Produtos com características de rotativo, como cartão (rotativo e parcelamento saldo devedor) e cheque especial que têm a incidência das taxas remuneratórias durante a utilização do crédito contratado deverão ter suas taxas remuneratórias informadas na contratação?

  • R.: O entendimento é que seria apenas na referência de contratação de fato, ou seja na utilização do crédito (p.ex. o mês que o cliente entra no especial ou no rotativo)

Sendo consideradas somente as operações "contratadas" no mês da apuração no cálculo e disponibilização de informações relativas a distribuição de frequência de Tarifas.

• Modalidades de crédito como Contas, Cartão, Cheque Especial que têm em suas tarifas de serviços normalmente relacionadas a utilização do crédito durante a vigência do contrato só serão representadas se a utilização da tarifa incidir no mês da contratação?

  • R.: O entendimento é que seria apenas na referência de contratação de fato, ou seja na utilização do crédito (p.ex. o mês que o cliente entra no especial ou no rotativo); desde que a Modalidade de crédito informada ainda seja ofertável.

• No caso de se considerar no cálculo da distribuição de frequência sobre Tarifas todas as ocorrências relativas ao mês de apuração, o estoque de operações ainda vigentes de uma modalidade não mais disponível na oferta deve ser desprezada?

  • R.: Sim

• Modalidades de crédito comercializadas que têm Tarifas de serviços diferenciadas para funcionários deverão ser consideradas no cálculo da distribuição de frequência? Considerando assim, funcionários consumidores de produto também como clientes?

  • R.: O entendimento é que o funcionário é cliente nos produtos, ele deve sim entrar na conta (ele é um cliente com condições especiais de taxas e tarifas, assim como outros clientes que também conseguem negociar condições especiais por diversos outros motivos).

Orientações, padrões e exemplos sobre apuração dos valores para a distribuição de frequência de Tarifas e Taxas Remuneratórias

Podem ser encontradas no item Divulgação dos valores de tarifas e taxas de juros remuneratórias, em API – Produtos Serviços.

É possível incluir novos Tipos de cartão?

Informamos que nesta fase 1 não serão incluídas novas ocorrências no Enum dos tipos de cartão. Deve-se selecionar a opção 'OUTROS' e complementar a informação utilizando o atributo additionaInfo.

Como reportar Agências Digitais?

Para o item dependências e correspondentes, a grande referência foi o que as instituições já reportam via mensageria regulatória. (UNICAD).

RESOLUÇÃO Nº 4.072, DE 26 DE ABRIL DE 2012.

Vide 4015 - Art. 2º Os dados sobre os canais de atendimento objeto de compartilhamento de que trata o art. 5º, inciso I, alínea "a", da Resolução Conjunta nº 1, de 4 de maio de 2020, abrangem, no mínimo, aqueles obrigatoriamente divulgados na forma de dados abertos, de que trata a regulamentação vigente, no caso de dependências próprias e correspondentes no País RC1 - I - dados sobre: a. canais de atendimento relacionados com:

1. dependências próprias;

2. correspondentes no País;

3. canais eletrônicos; e

4. demais canais disponíveis aos clientes;

*IN-*35 - Divulga a versão 1.0 do Manual de Escopo de Dados e Serviços do Open Banking debatido em auto regulação e regulado pelo BACEN. Não discutimos os itens especificamente, mas entendo que se não está explicito nas regulações vigentes, não há obrigação de report.

As operações de repasse são reportadas no Documento 3050 – Estatísticas agregadas de Crédito e Arrendamento Mercantil em: Financiamento de investimentos com recursos do BNDES e Financiamento Agroindustrial com recurso do BNDES. No Documento 3040 – Dados Individualizados de Risco de Crédito, essas operações são reportadas como 08.02. Financiamentos Rurais – Investimentos, porém, com a origem do recurso como direcionado (02 – BNDES, 03- Finame). Devemos incluir essas operações de repasse dentro do reporte do Open Finance Brasil?

As operações informadas no documento 3040, que encontram sua Modalidade representada nas listas das APIs constantes do Github devem ser informadas no Open Banking. Quanto à fonte do recurso (02 – BNDES, 03- Finame), esta informação não está discriminada para ser disponibilizada. Para esclarecimento, reiteramos que a modalidade 08.02 não faz parte do reporting. Citar a origem dos recursos nunca foi escopo das discussões da fase 1.

Temos participação obrigatória na Fase 3, porém queremos saber detalhes sobre a participação optativa da Fase 1 e Fase 2. As dúvidas iniciais são:

1. Como optativa: Podemos participar da Fase 2 parcialmente?

2. Como optativa: Podemos somente consumir dados da Fase 2?

3. Como optativa: É preciso fazer cadastro do BCB para somente consumir dados da Fase 2?

Salvo possíveis ressalvas do regulador, entendemos, conforme trecho da regulação mais abaixo que não existe participação parcial.

1. O cadastramento para compartilhamento de informações é obrigatório - compartilhamento neste contexto engloba também o consumo de informações.

2. A participação voluntária na Fase II implica na disponibilização das interfaces dedicadas ao compartilhamento de dados das Fases I e II.

3. A instituição poderá decidir se consome ou não os dados no ecossistema - como receptora, mas uma vez participante, torna-se obrigatoriamente transmissora - daí a obrigatoriedade de disponibilizar as interfaces dedicadas.

RESOLUÇÃO CONJUNTA Nº 1, DE 4 DE MAIO DE 2020

"Seção II

Da Participação no Open Banking

Art. 6º São participantes do Open Banking: [...]

§ 1º É obrigatório o compartilhamento dos dados e dos serviços, observados os prazos de implementação mencionados no art. 55: [...]

§ 3º A participação voluntária de que trata o inciso I, alínea "b", do caput, pressupõe a disponibilidade de interface dedicada de que trata o art. 23 na condição de instituição transmissora de dados."

Considerar data da concessão ou data da liberação para o Cálculo da distribuição de frequência para operações com característica de liberações parciais?

No que diz respeito a contratos de crédito guarda-chuva, entendemos que deveria se entender, para todos os efeitos, que a contratação ocorre na data da liberação do recurso. Entendimento similar já foi dado para contratos de cheque especial, por exemplo, podendo, a nosso entender, também ser replicado no caso ilustrado pelo demandante de operações de crédito rural e de custeio de projetos.

Como devemos tratar distribuição de frequência sobre taxas remuneratórias para outras operações de crédito relacionadas ao Produto Cartão?

A princípio não há exigência normativa para se apresentar a distribuição de frequência para essas outras modalidades de crédito relacionadas à cartão de crédito. Conforme a Instrução Normativa BCB 35, de 2020, somente recairia essa exigência, no caso de cartão de crédito, sobre as operações de crédito rotativo e de parcelamento do saldo devedor da fatura, que já são operações que observam alguma espécie de padronização. De qualquer forma, esse é o escopo mínimo de dados, o que não impede que o GT e o conselho deliberativo deliberem por sua expansão em algum momento.

É permitido a utilização de PKI Privada para emissão de certificados responsáveis por autenticação (cliente) e assinatura no Open Finance Brasil?

De acordo com a MEDIDA PROVISÓRIA No 2.200-2, DE 24 DE AGOSTO DE 2001, a utilização de PKI Privada é autorizada como mecanismo válido para autenticação e assinatura. Para o Open Finance Brasil, a utilização de PKI Privada para emissão de certificados de autenticação (cliente) e assinatura é permitido apenas quando provisionado pela entidade atuando como transmissora de dados, e quando a entidade receptora de dados não participa do Ecossistema de Open Finance Brasil de maneira a possuir cadastro no Serviço de Diretório do Open Finance Brasil e o certificado emitido deve possuir as mesmas características de chaves criptográficas, e atributos conforme especificados pelo Open Finance Brasil.