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 dados | Agrupamento | Permissões | Seleção de recurso |
|---|---|---|---|
| Cadastro | Dados Cadastrais PF | CUSTOMERS_PERSONAL_IDENTIFICATIONS_READ RESOURCES_READ | Por recurso |
| Cadastro | Dados Cadastrais PJ | CUSTOMERS_BUSINESS_IDENTIFICATIONS_READ RESOURCES_READ | Por recurso |
| Cadastro | Informações complementares PJ | CUSTOMERS_BUSINESS_ADITTIONALINFO_READ RESOURCES_READ | Por recurso |
| Contas | Saldo | ACCOUNTS_READ ACCOUNTS_BALANCES_READ RESOURCES_READ | Por recurso |
| Contas | Limites | ACCOUNTS_READ ACCOUNTS_OVERDRAFT_LIMITS_READ RESOURCES_READ | Por recurso |
| Contas | Extratos | ACCOUNTS_READ ACCOUNTS_OVERDRAFT_LIMITS_READ RESOURCES_READ | Por recurso |
| Cartão de crédito | Limite | CREDIT_CARDS_ACCOUNTS_READ CREDIT_CARDS_ACCOUNTS_LIMITS_READ RESOURCES_READ | Por recurso |
| Cartão de crédito | Transações | CREDIT_CARDS_ACCOUNTS_READ CREDIT_CARDS_ACCOUNTS_LIMITS_READ RESOURCES_READ | Por recurso |
Updated less than a minute ago