Gestão do Consentimento

O Guia de Experiência apresenta os requisitos e recomendações para o ambiente de Open Finance dentro das Instituições Receptoras e Transmissoras de Dados, e é nesse ambiente que o usuário terá acesso à seção Meus Compartilhamentos, na qual poderá ver os dados recebidos e enviados, bem como os detalhes e status dos seus compartilhamentos, sejam eles ativos, cancelados ou expirados.

Nesse ambiente será possível, também, acessar as ações referentes à gestão dos compartilhamentos, sendo possível revogar, alterar ou renovar um compartilhamento de dados seguindo as diretrizes específicas a cada tipo de ação.

As Instituições Receptoras de Dados deverão disponibilizar a ação de Revogação do consentimento dado e opcionalmente, podem disponibilizar as ações de Alteração e Renovação (padrão ou simplificada) dos consentimentos dados. Em caso de implantação das jornadas opcionais, deve-se seguir os requisitos previstos no Guia de UX.

As instituições Transmissoras de Dados deverão apenas disponibilizar a ação de revogação do consentimento dado. As demais ações, de Alteração ou Renovação só poderão ser realizadas nas Instituições Receptoras.

Dentro do ambiente Open Finance de cada instituição, será possível acessar os compartilhamentos, bem como as opções de:

• Revogar compartilhamento.

• Alterar compartilhamento.

• Renovar compartilhamento.

Revogação:

Ação de revogar um consentimento ativo. Pode acontecer tanto na Instituição Transmissora de Dados quanto na Instituição Receptora de Dados, em concordância com o Art. 15 da Resolução Conjunta nº1 .

Alteração e renovação padrão:

Ações complementares, realizadas apenas na Instituição Receptora de Dados, que oferecem uma experiência facilitada para criação de um novo consentimento com base nos dados de um consentimento prévio. Caso o consentimento prévio esteja ativo, alterá-lo ou renová-lo implica revogá-lo para criar um novo em seu lugar.

Renovação simplificada:

Ação complementar similar à renovação padrão, porém restrita a consentimentos ativos, já que trata da atualização do prazo, sem a substituição do consentimento atual por um novo. É dita simplificada pois dispensa a necessidade de redirecionamento e confirmação na Instituição Transmissora de Dados.

Ambiente Open Finance

Para fácil acesso às jornadas complementares, é importante criar o ambiente Open Finance, que vai disponibilizar, entre outros conteúdos, informações sobre os compartilhamentos do usuário.

Cenário: Acesso ao Open Finance

1. Disponibilização do Open Finance nos canais: disponibilizar o ambiente Open Finance nos seus canais, incluindo-o no primeiro nível do menu principal, para garantir acesso rápido e fácil ao usuário.

Cenário: Histórico de consentimentos

1. Exibição do histórico de compartilhamentos: disponibilizar, no ambiente Open Finance, uma seção dedicada à exibição do histórico completo de compartilhamentos.

   a. Diferenciar claramente os consentimentos transmitidos e recebidos para fins de consulta.

   b. Diferenciar claramente os consentimentos conforme o status: ativos, pendentes e inativos (revogados ou expirados).

2. Exibição dos detalhes do consentimento: disponibilizar acesso aos detalhes de cada consentimento no histórico, contendo, no mínimo:

   1. Validade do consentimento: prazo e data final. No caso de prazo indeterminado, identificar para o usuário como “Indeterminado” ou termo similar.

   2. Escopo dos dados compartilhados: dados cadastrais, contas, cartões de crédito, investimentos e operações de crédito etc.

   3. Finalidade do compartilhamento: quando a consulta ocorrer no ambiente da Instituição Receptora de Dados.

   4. Histórico completo de prazos anteriores: quando o consentimento tiver sido renovado por meio da jornada de renovação simplificada, garantindo visibilidade sobre renovações passadas.

   5. Identificação do usuário solicitante em consentimentos com múltiplos aprovadores: quando a consulta ocorrer no ambiente da Instituição Transmissora de Dados.

Cenário: Revogação do consentimento

1. Disponibilização da opção de revogação: no histórico e nos detalhes dos consentimentos, disponibilizar ao usuário a opção de revogar qualquer consentimento ativo, seja transmitido ou recebido.

2. Consequências da revogação: antes da efetivação da revogação, exibir uma tela de confirmação, informando de forma clara as consequências da ação.

3. Abrangência da revogação: garantir que a revogação do consentimento contemple todos os dados objeto do compartilhamento.

4. Respeito às regras de poderes: respeitar, no processo de revogação, as regras de poderes já estabelecidas nas instituições.

5. Manutenção do consentimento no histórico: após a revogação, manter o consentimento e seus detalhes acessíveis no histórico, com status e informações devidamente atualizados.

6. Notificação entre instituições: notificar a outra instituição quando o usuário realizar a revogação do consentimento.

Cenário: Alteração e renovação do consentimentos

1. Alteração e renovação: a Instituição Transmissora de Dados não deve oferecer as jornadas de alteração ou renovação do consentimento, enquanto para a Instituição Receptora de Dados, a oferta é facultativa.

2. Comunicação sobre nova confirmação: informar claramente ao usuário que será necessária uma nova confirmação na Instituição Transmissora de Dados, e direcioná-lo para essa instituição.

3. Requisitos aplicáveis às jornadas: aplicar às jornadas de alteração e renovação os mesmos requisitos de todas as etapas da jornada de criação de consentimento, excetuando-se as limitações de configuração dos parâmetros inerentes a esses tipos de jornada. Dessa forma, não é necessário apresentar possibilidade de seleção da Instituição Transmissora de Dados nessas jornadas.

4. Manutenção do histórico após alteração ou renovação: após a efetivação da jornada, manter acessíveis no histórico os detalhes do consentimento revogado e do novo consentimento, com status e informações devidamente atualizados.

Caso a jornada de alteração seja oferecida:

5. Disponibilização da jornada de alteração: oferecer a jornada de alteração apenas para consentimentos ativos.

6. Caracterização da jornada de alteração: durante a jornada, apresentar, além das informações do consentimento previstas nos requisitos do Ambiente de Gestão de Consentimentos, ao menos um dos elementos a seguir para caracterizar a jornada como alteração, e não como renovação:

   1. Possibilidade de alteração dos dados (inclusão ou exclusão).

   2. Possibilidade de redução do prazo.

   3. Possibilidade de alteração da finalidade, para casos em que a Instituição Receptora de Dados tiver mais de uma opção vigente.

7. Exibição da finalidade: quando houver apenas uma finalidade do consentimento, exibi-la explicitamente ao usuário, mesmo que a finalidade utilizada no consentimento anterior não esteja mais vigente na Instituição Receptora de Dados.

Caso a jornada de renovação padrão seja oferecida:

8. Restrições na jornada de renovação padrão: não permitir, na jornada de renovação padrão, a alteração do escopo de dados compartilhados ou a alteração da Instituição Transmissora de Dados.

9. Restrição na alteração da finalidade: permitir a alteração da finalidade apenas nos casos em que houver necessidade de atualização por parte da Instituição Receptora de Dados.

10. Cálculo da nova data de validade: calcular a nova data de validade do consentimento a partir da data em que ocorrer a renovação, permitindo ao usuário modificá-la apenas para uma data posterior à data de expiração vigente, inclusive para prazo indeterminado. Ex.: Caso um consentimento tenha vigência de 01/01/2023 a 01/01/2024 (prazo de 12 meses), em qualquer opção de prazo apresentada ao usuário e independentemente do momento da renovação, a data final do consentimento renovado deve ser sempre posterior à data final do consentimento original.

Cenário: Renovação simplificada do consentimentos

1. Consentimentos ativos: a renovação simplificada é realizada exclusivamente pela Instituição Receptora de Dados e apenas para os consentimentos ativos.

2. Comunicação sem acionamento do usuário: para atualização do prazo de vigência do consentimento, realizar a comunicação entre a Instituição Receptora de Dados e a Instituição Transmissora de Dados exclusivamente via backend, sem direcionar o usuário para confirmação no ambiente da Instituição Transmissora de Dados.

3. Restrição de alteração de dados e da transmissora: não alterar o escopo de dados compartilhados, ou a Instituição Transmissora de Dados.

4. Limitação na alteração da finalidade: alterar a finalidade apenas quando houver necessidade de atualização por parte da Instituição Receptora de Dados, desde que não resulte em alteração do escopo de dados, comunicando de forma clara ao usuário o novo objetivo do compartilhamento.

5. Cálculo da nova data de validade: calcular a nova data de validade do consentimento a partir da data em que ocorrer a renovação, permitindo ao usuário modificá-la apenas para uma data posterior à data de expiração vigente, inclusive para prazo indeterminado. Ex.: Caso um consentimento tenha vigência de 01/01/2023 a 01/01/2024 (prazo de 12 meses), em qualquer opção de prazo apresentada ao usuário e independentemente do momento da renovação, a data final do consentimento renovado deve ser sempre posterior à data final do consentimento original.

6. Restrição à renovação simplificada em múltiplas alçadas: não oferecer a renovação simplificada de consentimentos que envolvam múltiplas alçadas.

7. Exibição do resultado da renovação: ao final do processo, exibir uma tela de sucesso ou insucesso com a resposta da Instituição Transmissora de Dados, em padrão visual semelhante ao da tela de efetivação, reforçando ao usuário se a renovação foi concluída ou não com sucesso.

8. Falha da renovação simplificada: em caso de insucesso da renovação de forma simplificada, exibir mensagens conforme o motivo do erro retornado, conforme exemplos abaixo:

   1. DEPENDE_MULTIPLA_ALCADA: “O compartilhamento de dados não pôde ser renovado pois depende de múltipla alçada.”.

   2. DATA_EXPIRACAO_INVALIDA: “O compartilhamento de dados não pôde ser renovado pois a data final ficou anterior à data de requisição do pedido de renovação ou igual à data de expiração atual ou diferente de prazo indeterminado e maior que 12 meses da data de requisição do pedido de renovação.”

   3. REFRESH_TOKEN_JWT: “O compartilhamento de dados não pôde ser renovado com esta Instituição Transmissora.”

   4. ESTADO_CONSENTIMENTO_INVALIDO: “O compartilhamento de dados não pôde ser renovado pois está encerrado ou foi cancelado.”

   5. ERRO GENÉRICO: “O compartilhamento de dados não pôde ser renovado devido a problemas técnicos. Tente novamente mais tarde.”

Cenário: Onboarding Open Finance

1. Onboarding: na primeira utilização do usuário, realizar onboarding objetivo, apresentando as funcionalidades disponibilizadas pela instituição no ambiente Open Finance. Disponibilizar, também, link de acesso à Área do Cidadão para consulta de informações relacionadas ao Open Finance.

Cenário: Ambiente Open Finance

1. Acesso aos consentimentos: disponibilizar ao usuário o acesso aos consentimentos pelas opções a seguir.

   1. Logo após o usuário acessar a opção Open Finance.

   2. Por meio de Meus compartilhamentos, acessado pela Open Finance.

2. Localização do ambiente Open Finance: disponibilizar o ambiente Open Finance em áreas dedicadas aos produtos nos canais da instituição para facilitar o acesso do usuário.

3. Revogação múltipla de consentimentos: permitir, de forma opcional para cada instituição, a seleção de mais de um consentimento para revogação, com o objetivo de facilitar a experiência do usuário.

4. Filtros de busca de consentimentos: disponibilizar, de forma opcional para cada instituição, filtros de busca para facilitar a localização dos consentimentos.

5. Termos e condições: as ITs poderão, a seu critério, disponibilizar termos e condições referentes ao serviço de compartilhamento de dados, no Ambiente de Gestão de consentimento.

Cenário: Renovação simplificada do consentimento

1. Aviso de renovação padrão:

   1. Comunicar o usuário sobre a proximidade da data de vencimento do consentimento, considerando a proporcionalidade em relação ao prazo total do compartilhamento.

   2. Permitir a revogação do consentimento anterior após a renovação, caso ele ainda esteja vigente.

2. Aviso de renovação simplificada: comunicar o usuário sobre a proximidade da data de vencimento do consentimento, considerando a proporcionalidade em relação ao prazo total do compartilhamento.

Status do Compartilhamento de dados

Para padronizar e facilitar o entendimento do usuário nas Jornadas de Compartilhamento de Dados e Iniciação de Pagamento, são apresentados a seguir os status que devem ser apresentados ao usuário.

As tabelas têm como objetivo deixar claro o De/Para entre o status apresentados para o usuário e os status técnicos das APIs.

Cenário: Geral

1. Status: o status do compartilhamento deve estar relacionado com a combinação do status do consentimento e, conforme aplicável, das resources associadas a ele e do efetivo compartilhamento de dados cadastrais.

PENDING AUTHORISATION > AVAILABLE > TEMPORARILY UNAVAILABLE > UNAVAILABLE

Por exemplo: se um consentimento vigente está compartilhando normalmente dados de cadastro e transacionais, mas tem algum recurso com status UNAVAILABLE, o status para o usuário deve ser Ativo, pois status AVAILABLE na ordem de precedência, vem antes do status UNAVAILABLE . Por outro lado, se algum recurso está com status PENDING AUTHORISATION, então o status para o usuário final deve ser Pendente de autorização.
Confira outros exemplos para casos de API com diferentes status a seguir.

2. Diferentes status: caso haja diferentes status de recursos em um mesmo consentimento (AVAILABLE, PENDING_AUTHORISATION, TEMPORARILY UNAVAILABLE e UNAVAILABLE) e considerando, também, se há ou não impedimento no tráfego de dados cadastrais (pois não geram recursos listáveis na API Resources) , o peso de cada status para consolidação e demonstração do status do consentimento deve seguir o seguinte:

3. Rejection_reasons: os rejections_reasons podem ser utilizados para mostrar detalhes sobre os status. Para três deles, temos os seguintes requisitos:

   1. INTERNAL_SECURITY_REASON: por se tratar de um consentimento rejeitado devido às políticas de segurança aplicadas pela Instituição Transmissora (prevenção a fraudes), não deverão ser utilizados, na consulta do detalhamento do consentimento, termos que afirmem se tratar de fraude.

   2. CONSENT_MAX_DATE_REACHED: deve ser mostrado ao usuário com o status Vencido.

   3. CONSENT_EXPIRED, CUSTOMER_MANUALLY_REJECTED e CONSENT_ TECHNICAL_ISSUE: não precisam ser demonstrados na consulta dos consentimentos, pois o usuário não chegou a concluir sua solicitação.

   4. CUSTOMER_MANUALLY_REVOKED: deve ser mostrado ao usuário com o status Encerrado.

Cenário: Geral

1. Detalhamento de motivo de encerramento de consentimento: para consentimentos encerrados, apresentar o detalhamento do motivo do encerramento, conforme o rejection_reason associado.

2. Recurso não acessível: caso o compartilhamento esteja com status ativo, porém, com algum recurso não acessível, a Instituição Receptora dos Dados pode, a seu critério, sinalizar a existência da pendência na lista de consentimento e sugerir que o usuário verifique o detalhamento do consentimento. Fica a critério da instituição apresentar o status isolado por resource na consulta do usuário.