Orientações - [DC] Dados Cadastrais

Comportamento da API de Dados Cadastrais com relação a Recursos

Regras de negócio para implementação pela transmissora

• RN001 - Dados Cadastrais não geram recursos listáveis na API de Recursos (Resources). Eventuais fluxos de múltiplas alçadas terão os seus status reportados diretamente ao consultar os dados da API de Dados Cadastrais (Customers).

• RN002 - Ao consultar a API de Recursos (Resources) em que, no consentimento, se tenham somente permissões de compartilhamento de Dados Cadastrais, deve ser retornado o código 200 com lista vazia da API de Recursos (Resources)

• 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.

• RN004 – Caso a Transmissora não possua cadastro unificado, ela poderá entregar mais de um registro no endpoint de Identificação PN e PJ. No caso de PJ, deve-se indicar, no atributo “companiesCnpj”, a referência do CNPJ das empresas que fazem uso do respectivo cadastro.

Considerando o cenário abaixo: Marca 1, com as empresas CNPJ 1, CNPJ 2 e CNPJ 3.

Cadastro Não Unificado para PN.

"data": [
  {
    "personalId": "teste1",
    "civilName": "Pessoa da Silva",
    "companyCnpj": [
    "CNPJ 1"
    ]
    ... omitidos demais campos para exemplificar ...
  },
  {
    "personalId": "teste1",
    "civilName": "Pessoa da Silva",
    "companyCnpj": [
    "CNPJ 2",
    "CNPJ 3"
    ],
    ... omitidos demais campos para exemplificar ...
  }
],
"links": {
  "self": "https://api.banco.com.br/open-banking/api/v1/resource",
  "first": "https://api.banco.com.br/open-banking/api/v1/resource",
  "prev": "https://api.banco.com.br/open-banking/api/v1/resource",
  "next": "https://api.banco.com.br/open-banking/api/v1/resource",
  "last": "https://api.banco.com.br/open-banking/api/v1/resource"
},
"meta": {
  "totalRecords": 1,
  "totalPages": 1,
  "requestDateTime": "2021-05-21T08:30:00Z"
}

• RN005 - Caso a Transmissora possua cadastro unificado das empresas de sua respectiva marca, ela poderá entregar apenas um registro na lista do endpoint de Identificação PN e PJ, devendo esta indicar, no atributo “companiesCnpj”, a referência do CNPJ das empresas que fazem uso do respectivo cadastro.

Considerando o cenário abaixo: Marca 1, com as empresas CNPJ 1, CNPJ 2 e CNPJ 3.

Cenário: Cadastro Unificado para PN.

{
"data": [
  {
    "personalId": "teste1",
    "civilName": "Pessoa da Silva",
    "companyCnpj": [
    "CNPJ 1",
    "CNPJ 2",
    "CNPJ 3"
    ],
    ... omitidos demais campos para exemplificar ...
  }
],
"links": {
  "self": "https://api.banco.com.br/open-banking/api/v1/resource",
  "first": "https://api.banco.com.br/open-banking/api/v1/resource",
  "prev": "https://api.banco.com.br/open-banking/api/v1/resource",
  "next": "https://api.banco.com.br/open-banking/api/v1/resource",
  "last": "https://api.banco.com.br/open-banking/api/v1/resource"
},
"meta": {
  "totalRecords": 1,
  "totalPages": 1,
  "requestDateTime": "2021-05-21T08:30:00Z"
}
}

• RN006 – Se, a critério do transmissor, for aplicado fluxo de múltipla alçada para acesso aos Dados Cadastrais, deverá ser aplicado os status apresentados a seguir.

Códigos de uso para o erro 403 na API de Dados Cadastrais (Customers)

A Transmissora deve preencher do retorno do código HTTP Status Code 403 - Forbidden, conforme segue:

• PENDING_AUTHORISATION: code=’STATUS_RESOURCE_PENDING_AUTHORISATION’, title=’Aguardando autorização de múltiplas alçadas’, detail=(uso a critério do Transmissor)

• UNAVAILABLE: code= ‘STATUS_RESOURCE_UNAVAILABLE’,title=’Recurso indsponível’, detail=(uso a critério do transmissor)

• TEMPORARILY_UNAVAILABLE: code= ’STATUS_RESOURCE_TEMPORARILY_UNAVAILABLE’, title=’Recurso temporariamente indisponível’, detail=(uso a critério do transmissor)

Orientações sobre dados do empregador (endpoint /personal/financial-relations)

Na versão 2.1.0 da API houve a adição de dois objetos ao endpoint ‘/personal/financial-relations’, para possibilitar o compartilhamento de informações de dados do empregador. Dessa forma, os campos portabilitiesReceived e paychecksBankLink estão relacionados com Portabilidade Salarial. Nesse sentido, as informações compartilhadas nesses campos podem ser úteis para portabilidade salarial da conta salário do banco-folha para outras instituições:

• O objeto paychecksBankLink será utilizado para exposição de informações de conta salário ativas mantidas pelo cliente com a instituição transmissora de dados. Sua implementação é obrigatória por instituições transmissoras que atuam como instituição financeira contratada para a prestação de serviços de pagamento de salário (banco folha). O conteúdo deve ser enviado sempre que existente para o cliente que compartilhou seus dados cadastrais.

• O objeto portabilitiesReceived deverá conter informações de empregador recebidas pela transmissora na ocorrência de uma portabilidade de salário. Devem ser compartilhadas as informações de portabilidade aprovadas, mesmo que de forma compulsória, considerando prazo histórico de 5 anos. Caso o pedido seja posteriormente regularizado (negado) pela instituição detentora da conta salário, tal pedido deve deixar de ser compartilhado. A implementação do objeto portabilitiesReceived é obrigatória para instituições transmissoras que também são detentoras de conta, e seu conteúdo deve ser compartilhado quando já houver portabilidade de salário realizada pelo cliente para a instituição transmissora de seus dados no OPF. A transmissora terá tais informações apenas quando o pedido da portabilidade tiver sido solicitado em seu canais.

Orientações para instituições receptoras de dados

No objeto paychecksBankLink serão compartilhadas informações de conta salário que se encontram abertas, entretanto, pelo fato de haver uma conta salário aberta, não é possível afirmar que há um vínculo empregatício ativo para o cliente. Recomenda-se o cruzamento das informações obtidas desse objeto com as transações expostas na API Contas, para melhor compreensão dos dados.

No objeto portabilitiesReceived serão compartilhadas informações do empregador de portabilidade(s) recebida(s) pela transmissora, porém apenas por tais informações não é possível afirmar que tal portabilidade se encontre ativa ou que ainda exista o vínculo do cliente com o empregador ou com a instituição banco folha. Recomenda-se a análise das transações compartilhadas na API Contas para melhor compreensão dos dados.