Como funciona consentimento e consumo de dados

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.


Máquina de Estados

AWAITING_AUTHORISATION: estado inicial quando um consentimento é criado. Neste estado, o consentimento representa apenas uma intenção de compartilhamento, indicando quem é o cliente que irá realizar o compartilhamento, quais permissões estão sendo solicitadas e a sua data de validade. Neste momento ainda não estão definidos os recursos a serem compartilhados.

AUTHORISED: estado que indica que o consentimento foi aprovado pelo cliente e que é possível realizar o consumo de dados. Neste estado os recursos ao qual o consentimento dá acesso já foram selecionados, seja através dos seus identificadores ou através da sua modalidade. Apesar do consentimento estar aprovado, ainda poderão existir recursos cujo acesso dependa de uma aprovação de múltipla alçada.

REJECTED: estado que indica que o consentimento foi revogado. A revogação pode se dar por diferentes motivos, como expiração do tempo máximo para autorização e aprovação do consentimento, vencimento da data de validade do consentimento após a sua aprovação ou ainda uma revogação explicita solicitada pelo cliente.


Regras de transição de Estados











Regras para Criação de um consentimento

1. A receptora de dados deve enviar as permissões desejadas em grupo mínimo de permissões definidos para cada tipo de produto;

2. A receptora de dados pode solicitar mais de um grupo de permissões ao mesmo tempo, respeitando a intenção do cliente durante a criação do consentimento;

3. Para produtos com seleção por agrupamento de recursos ou agrupamento de produtos, a transmissora deve manter as permissões do agrupamento solicitado,
mesmo quando não os comercialize;

4. Para produtos que exigem a seleção individual de recurso na aprovação do consentimento, caso a transmissora ofereça o produto (contas e/ou cartões), a transmissora deve retornar as permissions no pedido de criação do consentimento independente se o cliente possui ou não este produto;

5. Se após a remoção de um agrupamento de produtos não restarem permissões funcionais, a transmissora deve rejeitar o pedido de criação do consentimento dando um retorno HTTP Status Code 422, com a mensagem "SEM_PERMISSOES_FUNCIONAIS_RESTANTES";

6. Nas situações abaixo, a transmissora deve rejeitar o pedido de criação de consentimento, dando retorno HTTP Status Code 422 com as mensagens especificadas abaixo:

a. Caso, no pedido da criação do consentimento, a transmissora valide a ausência de parâmetros PJ e presença de permissions CUSTOMERS BUSINESS deve retornar HTTP Status Code 422 com a mensagem “INFORMACOES_PJ_NAO_INFORMADAS”;
b. Caso, no pedido da criação do consentimento, a transmissora valide a presença de parâmetros PJ e presença de permissions CUSTOMERS PERSONAL deve retornar HTTP Status Code 422 com a mensagem “PERMISSOES_PJ_INCORRETAS”;
c. Caso recebam uma solicitação de consentimento com permissões de dados cadastrais PF e PJ em conjunto, retornar HTTP Status Code 422 com a mensagem “PERMISSAO_PF_PJ_EM_CONJUNTO”;
d. Caso a Instituição Receptora envie permissões divergentes ao agrupamento especificado na tabela abaixo, retornar HTTP Status Code 422 com a mensagem “COMBINACAO_PERMISSOES_INCORRETA”.
e. Caso a Instituição Receptora envie data de expiração maior que um ano ou uma data referente ao passado, deve-se retornar HTTP Status Code 422.

7. Caso seja identificado um cliente PJ na jornada de criação de consentimento, deve-se exibir apenas marcas que suportem públicos PJ ou ambos (PF e PJ) para escolha. As marcas que contemplam público PJ podem ser selecionadas no diretório nos casos em que a flag de seleção de público está preenchida com a opção “Suporta Contas PJ”​

8. Caso seja identificado um cliente PF na jornada de criação de consentimento, deve-se exibir apenas marcas que suportem públicos PF ou ambos (PF e PJ) para escolha. As marcas que contemplam público PF podem ser selecionadas no diretório nos casos em que a flag de seleção de público está preenchida com a opção “Suporta Contas PF”

Agrupamentos de permissões válidos

Categoria de dadosAgrupamentoPermissõesSeleção de recurso
CadastroDados Cadastrais PFCUSTOMERS_PERSONAL_IDENTIFICATIONS_READ
RESOURCES_READ
Por recurso
CadastroDados Cadastrais PJCUSTOMERS_BUSINESS_IDENTIFICATIONS_READ
RESOURCES_READ
Por recurso
CadastroInformações complementares PJCUSTOMERS_BUSINESS_ADITTIONALINFO_READ
RESOURCES_READ
Por recurso
ContasSaldoACCOUNTS_READ
ACCOUNTS_BALANCES_READ
RESOURCES_READ
Por recurso
ContasLimitesACCOUNTS_READ
ACCOUNTS_OVERDRAFT_LIMITS_READ
RESOURCES_READ
Por recurso
ContasExtratosACCOUNTS_READ
ACCOUNTS_OVERDRAFT_LIMITS_READ
RESOURCES_READ
Por recurso
Cartão de créditoLimiteCREDIT_CARDS_ACCOUNTS_READ
CREDIT_CARDS_ACCOUNTS_LIMITS_READ
RESOURCES_READ
Por recurso
Cartão de créditoTransaçõesCREDIT_CARDS_ACCOUNTS_READ
CREDIT_CARDS_ACCOUNTS_LIMITS_READ
RESOURCES_READ
Por recurso