Comparação de Páginas

Consentimento

No compartilhamento de dados cadastrais e transacionais, o "consentimento" denota a autorização concedida por um cliente de uma instituição participante do Open Finance para que outra instituição possa acessar informações sobre os produtos (recursos) detidos pelo cliente. Essa autorização é dada de forma explícita e detalhada.
O cliente, que é o principal interessado no compartilhamento de suas informações, detém o poder de determinar quais produtos a instituição terá acesso. Além disso, dependendo do tipo de produto, ele pode especificar a origem precisa dos dados. Por exemplo, no caso de produtos do tipo "conta", o cliente tem a capacidade de escolher quais contas específicas terão seus dados compartilhados. Para outras categorias de produtos, como operações de crédito, o cliente pode indicar as modalidades de compartilhamento. Isso inclui autorizar a consulta de dados relativos a produtos que estejam atualmente contratados, bem como produtos que possam ser adquiridos no futuro, durante o período de validade do consentimento.

...

A tabela abaixo indica, para cada produto, os agrupamentos de permissões válidos e como é realizado a seleção de recursos, por identificador ou por modalidade. Produtos cuja seleção de recurso seja por identificador devem ter o agrupamento de permissões removidos quando a instituição transmissora não oferecer o produto. Já produtos cuja seleção de recurso seja por agrupamento de recurso ou agrupamento de produtos deve ter as permissões mantidas mesmo quando a instituição transmissora não comercializar o produto solicitado.

Cenários de caso de erro

Foram mapeados alguns erros esperados durante o fluxo do usuário no ecossistema. Existem orientações específicas já tratadas no Guia de Experiência do Usuário. Aqui, trataremos a visão mais técnica do que pode ser feito em caso de erro:

...

• A transmissora deve validar documento fornecido (`loggedUser`; `businessEntity` quando aplicável) e token de acesso para executar a renovação de consentimento. Caso a transmissora detecte que se trata de acesso inválido por questões de segurança, é esperado status de erro 401 ou 403. Tipicamente, erros de segurança tem precedência, pois são avaliados primeiro, ao invés de erros de negócio. Por exemplo, status de erro 401 ocorrerá, mesmo que exista algum outro erro funcional (status 422) na requisição;

• Na tentativa de renovação de consentimentos no status REJECTED a transmissora deve retornar status de erro 422 (`ESTADO_CONSENTIMENTO_INVALIDO`);

• Na tentativa de renovação de consentimentos que exijam aprovações por múltiplas alçadas a transmissora deve retornar status de erro 422 (`DEPENDE_MULTIPLA_ALCADA`) ;

• A transmissora deve retornar status de erro 422 (`DATA_EXPIRACAO_INVALIDA`) na tentativa de renovação de consentimentos em que o novo expirationDateTime seja:

  • Menor que a data de requisição (currentDateTime ) do pedido de renovação, ou menor ou igual que a data de expiração atual;

  • Diferente de prazo indeterminado e maior que 12 meses da data de requisição (currentDateTime);

...

Mudanças para as transmissoras de dados somente para produtos cuja seleção é agrupada por produtos (Operações de Crédito e Investimentos) ou por recursos (Câmbio)

¹ Válido para todos os produtos, e não somente Operações de Crédito, Investimentos e Câmbio.

Mudanças para as receptoras de dados somente para produtos cuja seleção é agrupada por produtos (Operações de Crédito e Investimentos) ou por recursos (Câmbio)

Impactos e regras de transição

...

Mapeamento de mensagens retornadas pela API Consentimento

...