24. Ciclo de Vida de Authorization Server

Matriz de orientações em caso de alterações dos Authorization Servers

Esta planilha é um material de trabalho elaborado com contribuições dos GTs Arquitetura, PRC e Infraestrutura, com suporte do Secretariado do Open Finance e contribuições de técnicos do Banco Central

 

 

VISÃO DE NEGÓCIO

VISÃO TÉCNICA

 

#

Cenário

Cliente

Transmissor

Recebedor

Transmissor

Recebedor

Considerações finais 

1

Transmissor encerra uma marca (usuário final ainda pode acessar histórico através de autoatendimento pela internet).

Não é necessário ação do cliente.

O compartilhamento de dados será mantido enquanto existir canal para gestão daquele produto.

Receberá os dados referente aos 12 meses anteriores previstos na regulação. Após esse período, não receberá mais dados

O transmissor deve continuar enviando as informações ao longo de 12 meses, e após esse período alterar o status do recurso para 'UNAVAIABLE' e encerrar o envio de informações

Pode consultar o status do recurso na API Resources referente aos 12 meses anteriores previstos na regulação

N/A

2

Transmissor encerra uma marca (usuário final ainda pode acessar histórico através da internet) e migra os clientes e os recursos para outra marca dentro da mesma instituição (mesmo CNPJ).

N/A

Consentimentos autorizados devem continuar vigentes.

Não é necessário ação do recebedor. Passará a receber dados da nova marca.

A informação deve ser disponibilizada enquanto estiver disponível no canal e dentro do prazo de compartilhamento

Os produtos a serem compartilhados serão ajustados a medida em que sua visualização for extinta do respectivo canal

N/A

3

Transmissor encerra uma marca (usuário final ainda pode acessar histórico através de autoatendimento pela internet) e migra os clientes e os recursos para outra marca dentro do mesmo conglomerado (CNPJs distintos).

N/A

Consentimentos autorizados podem continuar vigentes.

Não é necessário ação do recebedor.
Se houver a migração, a instituição receptora passará a receber dados da nova instituição. Caso contrário, os consentimentos serão revogados e a instituição receptora não receberá mais os dados.

A solicitação deve ser encaminhada ao Banco Central, preferencialmente, antes do fato gerador ou, na inviabilidade, em no máximo 10 dias corridos.

A solicitação deve ser encaminhada ao Banco Central, preferencialmente, antes do fato gerador ou, na inviabilidade, em no máximo 10 dias corridos.

A migração de AS com mudança da instituição transmissora de dados, no atual patamar do Open Finance, não é recomendável. Assim, em cenários que envolvem essa migração, os consentimentos podem ser revogados.

No entanto, nesse cenário específico, como estamos falando de mudanças dentro do mesmo conglomerado, cabe uma análise caso a caso. O caso deve ser descrito e solicitada autorização da Supervisão.

A solicitação deve ser encaminhada para DESUP/DESUC/DENOR, preferencialmente, antes do fato gerador ou, na inviabilidade, em no máximo 10 dias corridos.
Não se aplica ao cenário de cooperativas.

4

Transmissor encerra uma marca (usuário final não tem como acessar histórico através de autoatendimento pela internet – Portal não existe mais).

Não é necessário ação do cliente.

N/A

Não é necessário ação do recebedor. Não receberá mais dados dessa marca.

O consentimento deixa de existir.

Não há consulta pois não há mais API para consumo de dados.

N/A

5

Transmissor encerra um produto de uma marca.

Não é necessário ação do cliente.

Os consentimentos devem continuar vigentes. Apenas no caso de consentimentos restritos ao produto encerrado, eles poderiam ser revogados pelo transmissor após o fim do período de 12 meses

Não é necessário ação do recebedor. Não receberá mais dados desse produto.

API recurso muda para UNAVAILABLE após fim do período de 12 meses. API produto deixa de apresentar os dados.

Deve consultar o status do recurso na API Resources.

N/A

6

Marca de transmissor é adquirida por outra instituição e é mantida ativa.

Não é necessário ação do cliente.

N/A

Não é necessário ação do recebedor.

AS de origem fica em convivência pelo menos até expiração de todos os consentimentos ativos.

Os consentimentos devem ser migrados se houver anuência explícita do cliente. Caso contrário, devem ser revogados.

Não é necessário ação do recebedor.

A migração de AS com mudança da instituição transmissora de dados, no atual patamar do Open Finance, não é recomendável. Assim, em cenários que envolvem essa migração, os consentimentos podem ser revogados.

7

Transmissor é absorvido por outra instituição (incorporação).

Não é necessário ação do cliente.

Existem dois cenários possíveis: manutenção ou revogação dos consentimentos. O Banco Central avaliará cada caso.

Não é necessário ação do recebedor.

Caso a marca seja substituída deverá considerar os campos:

  • DeprecatedDate;

  • RetirementDate;

  • SupersededByAuthorizationIServerID;

  • Status.

Caso a marca anterior seja descontinuada deverá optar entre revogar e solicitar aos clientes que façam novo consentimento ou migrar os consentimentos atuais para o novo modelo, mantendo os mesmos IDs utilizados para servidores, clientes, serviços, consentimentos e infraestrutura previamente utilizados.

Não é necessário ação do recebedor.

A migração de AS com mudança da instituição transmissora de dados, no atual patamar do Open Finance, não é recomendável. Assim, em cenários que envolvem essa migração, os consentimentos podem ser revogados. Solicitação deve ser encaminhada para DESUP/DESUC/DENOR

8

É feita a migração do AS para outra instância do mesmo produto tecnologico dentro do mesmo cnpj transmissor

Não é necessário ação do cliente.

Consentimentos autorizados devem continuar vigentes.

Não é necessário ação do recebedor.

O transmissor deve garantir que os consentimentos permaneçam vigentes sem impacto ao cliente durante o período de migração 

Não é necessário ação do recebedor.

A migração de AS com mudança da instituição transmissora de dados, no atual patamar do Open Finance, não é recomendável. Assim, em cenários que envolvem essa migração, os consentimentos podem ser revogados. Esse cenários também pode ser aplicável às cooperativas

9

Cooperativa muda de sistema cooperativo (dois ou três níveis) – o serviço técnico de TI é provido pelo sistema cooperativo.

Após revogação ou manutenção automática na marca de origem o cliente deverá criar um novo consentimento na nova marca.

Existem dois cenários possíveis: manutenção ou revogação dos consentimentos. O Banco Central avaliará cada caso

Não é necessário ação do recebedor.

Os consentimentos serão revogados ou alterados na marca original.

Não é necessário ação do recebedor.

Casos de exceção deverão ser analisados pontualmente pelo regulador.

10

Cooperativa muda de sistema cooperativo – o serviço técnico de TI era provido pela própria cooperativa, agora será provido pelo sistema cooperativo.

Após revogação ou manutenção automática na marca de origem o cliente deverá criar um novo consentimento na nova marca.

Existem dois cenários possíveis: manutenção ou revogação dos consentimentos. O Banco Central avaliará cada caso

Não é necessário ação do recebedor.

A marca atual deverá indicar os campos no authorisation server cadastrado no diretório:

  • DeprecatedDate;

  • RetirementDate;

  • SupersededByAuthorizationIServerID;

  • Status.

Os consentimentos serão revogados com a descontinuação da marca original.

Deve solicitar novo consentimento ao cliente

N/A

11

Cooperativa muda de sistema cooperativo – o serviço técnico de TI era provido pela mesma cooperativa, agora será provido pelo sistema cooperativo. Sistema cooperativo anterior permanece operacional.

Após revogação ou manutenção automática na marca de origem o cliente deverá criar um novo consentimento na nova marca.

Existem dois cenários possíveis: manutenção ou revogação dos consentimentos. O Banco Central avaliará cada caso

Não é necessário ação do recebedor.

Transmissor irá revogar ou alterar os consentimentos da cooperativa na marca original da qual está sendo desvinculada.

Deve solicitar novo consentimento ao cliente

Casos de exceção deverão ser analisados pontualmente pelo regulador.

12

Cooperativa é incorporada por outra cooperativa do mesmo sistema cooperativo.

Não é necessário ação do cliente.

Consentimentos autorizados devem continuar vigentes.

Não é necessário ação do recebedor.

A Resources deve listar os números antigos como UNAVAILABLE e os novos como AVAILABLE.

Não é necessário ação do recebedor.

Casos de exceção deverão ser analisados pontualmente pelo regulador.

13

Cooperativa participante da fase de dados muda para sistema cooperativo que não participa da fase de dados

Não é necessário ação do cliente.

Consentimentos devem ser revogados pela própria cooperativa no sistema cooperativo original

Não é necessário ação do recebedor. Não receberá mais dados dessa marca.

A revogação de consentimento deve ser avaliada pelo regulador.

Não é necessário ação do recebedor.

Casos de exceção deverão ser analisados pontualmente pelo regulador.

Para a utilização dos campos de descontinuação do servidor de autorização disponíveis no Diretório as instituições transmissoras/detentoras devem preencher os campos no Diretório e as instituições receptoras/iniciadoras devem consumir as informações através da API do Diretório.

Campos

Transmissora/Detentora

Receptora/Iniciadora

Campos

Transmissora/Detentora

Receptora/Iniciadora

Deprecation Date

Data programada para iniciar a descontinuação do servidor de autorização.

Data limite para solicitação de novos consentimentos naquele servidor.

Retirement Date

Data programada para a aposentadoria do servidor.

Data limite para consultas de consentimentos naquele servidor.

SupersededByAuthorisationServerId

ID do servidor de autorização que substituirá o servidor atual.

Redirecionamento das solicitações de novos consentimentos.

Status

Indica se o servidor está Ativo, Inativo ou Descontinuado.

 

Os campos Deprecation Date e Retirement Date serão obrigatórios no contexto de descontinuação de marcas e o campo SupersededByAuthorisationServerId só será obrigatório no caso de substituição do servidor de autorização.

O campo Deprecation Date deve ser informado com pelo menos 10 dias antes do início da descontinuação.