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. | 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. |
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:
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:
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 |
---|---|---|
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.