Comparação de Páginas

...

• 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

...

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 renovação de consentimento possibilita que o cliente estenda ou reduza a data de expiração de um consentimento já existente. Ao contrário da criação de um novo consentimento, no qual há o redirecionamento e confirmação pelo cliente na transmissora, a renovação é feita via backend, sem redirecionamento.
Importante salientar que na renovação apenas a validade do consentimento (expirationDateTime ) e a finalidade podem ser alteradas.
Por não haver redirecionamento, nem todo consentimento é passível de renovação. A renovação aplica-se:

...

• Somente consentimentos ativos, no status AUTHORISED, podem ser renovados;

• A nova data de expiração do consentimento não pode estar no passado, deve minimamente ser maior que a data de requisiçãoexpiração atual;

• Para situações nas quais a renovação não seja para prazo indeterminado, o cliente pode alterar a validade do consentimento em até no máximo 12 meses da data de requisição da renovação;

• Para situações na qual o cliente escolha o prazo indeterminado, a receptora não deve enviar o campo expirationDateTime no pedido de renovação à transmissora, de forma que o consentimento fique, de fato, sem um prazo determinado;

• A renovação de consentimento ativo do cliente somente poderá ser aceita pela transmissora para um usuário logado na receptora, identificado por seu documento (`loggedUser`; `businessEntity` quando aplicável) e permitido a partir de token de acesso (informado no cabeçalho `Authorization`) conseguido anteriormente durante a criação e confirmação do consentimento vigente. A transmissora deve validar documento fornecido e token de acesso para executar a renovação de consentimento. Isso implica que qualquer usuário (`loggedUser`) com permissão para o consentimento associado deve ser capaz de finalizar o fluxo de renovação sem redirecionamento. No caso de pessoa jurídica o `businessEntity` deve ser igual ao do consentimento original.

Abaixo uma ilustração do fluxo esperado para o processo de renovação simplificado.

...

Casos de erro para a renovação simplificada do consentimento

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

...

Dessa forma, as instituições precisam tratar ambas as representações na experiência do usuário e exibir prazo indeterminado, de acordo com Guia UX, quando aplicável.