Dia Oficial

Diário Oficial da União · 07/03/2023 · pág. 93

DOU 07/03/2023 - Diário Oficial da União - Brasil

Baixar página em PDF · Criar alerta deste tema

O visualizador interativo precisa de JavaScript — baixe a página original em PDF.

TEXTO OFICIAL · ÍNTEGRA

Documento assinado digitalmente conforme MP nº 2.200-2 de 24/08/2001, que institui a Infraestrutura de Chaves Públicas Brasileira - ICP-Brasil. Este documento pode ser verificado no endereço eletrônico http://www.in.gov.br/autenticidade.html, pelo código 05152023030700093 93 Nº 45, terça-feira, 7 de março de 2023 ISSN 1677-7042 Seção 1 3.1.1 Perguntas frequentes Nesta área, deverão ser encontradas as respostas para os questionamentos mais frequentes relacionados ao suporte técnico, ao Diretório de Participantes, às APIs, aos dados e serviços compartilhados entre as instituições participantes e aos processos deste compartilhamento, de modo que algumas dúvidas possam ser sanadas de maneira rápida e independente. O conteúdo dessa seção deverá ser reavaliado ao menos a cada lançamento de versão major das APIs, de forma a atender seu objetivo de esclarecer dúvidas frequentes do público. 3.1.2 Canal de atendimento Deve ser disponibilizado canal de atendimento para suporte técnico, que pode ser implementado com atendimento de forma automatizada, sem intervenção humana. Nesse canal, poderão ser obtidas respostas para dúvidas de menor complexidade. As respostas devem ser classificadas conforme o grau de sensibilidade, devendo ser fornecidas com observância do perfil do demandante. Caso não seja possível atender às necessidades do demandante por meio do canal automatizado, deverá ser oferecida a possibilidade de abertura de ticket. 3.2 Suporte na abertura de tickets 3.2.1 Tipos de tickets O Service Desk deve suportar pelo menos dois tipos de tickets: I - requisições: pedidos de informações ou sugestões de melhorias; e II - incidentes: comunicação de falhas ou degradação de qualidade em algum serviço. 3.2.2 Gerenciamento de tickets 3.2.2.1 Princípios para o gerenciamento de tickets Deve ser implementada sistemática que permita a definição dos estados de atendimento dos tickets, bem como as transições entre os estados, de forma a permitir a adoção de ações adequadas ao seu tratamento, a exemplo de: triagem, enfileiramento, atribuição, resposta, avaliação e devolução. Essa sistemática deve estar detalhada no Portal do Open Finance no Brasil mantido pela Estrutura Responsável pela Governança do Open Finance. 3.2.2.2 Abertura de tickets O Service Desk deve permitir a abertura de tickets, via canal de atendimento, por: I - instituições participantes; II - desenvolvedores; e III - cidadãos. Para o atendimento a dúvidas e a requisições de cidadãos, o Service Desk deverá prover um ambiente com interface amigável e intuitiva e adaptado ao público em geral, de forma que as pessoas interessadas possam endereçar suas demandas à Estrutura Responsável pela Governança do Open Finance sem a necessidade de conhecimento técnico específico. No caso de recepção de demandas de cidadãos que envolvam reclamações contra instituições participantes, o demandante deve ser orientado a procurar primeiramente a instituição envolvida e, caso não consigam resolver o problema, registrem a reclamação no Banco Central do Brasil. Adicionalmente, no caso de uma instituição participante, deve ser possível a abertura de tickets por meio de API específica. Na abertura de um ticket, deverá ser gerado um número de protocolo, que deve ser informado ao demandante. Nesse momento, começará a contar prazo para atendimento da demanda, conforme acordo de nível de serviço especificado no item 3.2.2.5. 3.2.2.3 Classificação do prazo máximo de resolução do ticket O prazo máximo de resolução do ticket deve estar associado ao mesmo antes do direcionamento às instituições participantes. Esses prazos estão definidos no item 3.2.2.5. 3.2.2.4 Trilha de auditoria do ticket Toda atualização que gerar uma mudança do estado de atendimento ou do conteúdo do ticket deve ser devidamente registrada e armazenada para acesso futuro e para fins de verificação ou auditoria, observados os prazos de armazenamento previstos na regulamentação vigente. 3.2.2.5 SLAs para atendimento dos tickets 3.2.2.5.1 Metas de atendimento de requisições As metas para atendimento dos tickets por tipo de requisições são: . Tipo de requisição Prazo máximo Esclarecimentos adicionais . Solicitações de informações 5 dias úteis O prazo se refere ao fornecimento das informações solicitadas, ou à indicação do canal adequado para a obtenção das informações. . Sugestões de melhorias 10 dias úteis O prazo se refere ao fornecimento de resultado de análise preliminar da proposta, também informando prazo estimado de implementação, caso aplicável. 3.2.2.5.2 Metas de atendimento de incidentes sem indisponibilidade As metas para atendimento dos tickets relacionados a incidentes que não causem indisponibilidade de serviços são: . Tipo de incidente Prazo máximo Esclarecimentos adicionais . Degradação de qualidade de serviço 2 dias úteis O prazo se refere à implantação de correção ou de solução de contorno (análise e solução) para reparar falhas que degradem algum serviço sem causar sua interrupção. . Erros de desconformidade de certificação 5 dias úteis O prazo se refere à implantação de correção ou de solução de contorno (análise e solução) para reparar falhas que, sem causar interrupção dos serviços, produzam resultados divergentes dos obtidos durante o processo de certificação. . Erros de desconformidade de implementação 10 dias úteis O prazo se refere à implantação de correção ou de solução de contorno (análise e solução) para reparar falhas que, sem causar interrupção dos serviços, produzam resultados divergentes da especificação. . Somente poderão ser enquadrados neste erro os casos em que a implementação for divergente da especificação e não for demonstrada inconsistência técnica na referida especificação. . Demais erros Análise: 5 dias úteis Correção/solução de contorno: 45 dias corridos O prazo de análise se refere à avaliação preliminar em relação ao caso apresentado, também informando prazo estimado para correção, de acordo com o esforço esperado para a correção e os impactos para o cidadão. . O prazo de correção ou de solução de contorno (análise e solução) se refere à implantação de correção ou de solução de contorno visando reparar demais erros sem causar interrupção dos serviços. . Os incidentes deste tipo deverão ser avaliados pela Estrutura Responsável pela Governança do Open Finance, cabendo consideração sobre a possibilidade de cobertura do problema pelos testes de certificação. Em relação aos incidentes "Erros de desconformidade de implementação" e "Demais erros", o Banco Central do Brasil poderá estabelecer prazos diferenciados para sua correção em virtude de análise quanto ao esforço requerido e ao impacto para o cidadão. 3.2.2.5.3 Metas de atendimento de incidentes com indisponibilidade As metas para atendimento dos tickets relacionados a incidentes que causem indisponibilidade de serviços devem ser estipuladas pela Estrutura Responsável pela Governança do Open Finance, garantindo o atendimento dos seus respectivos SLAs de disponibilidade. Uma vez reestabelecido o serviço, o ticket relativo ao incidente deve ser fechado em até 1 dia útil. 3.2.2.6 Contagem de prazo dos tickets Os prazos se referem ao tempo total de atendimento, desde a geração do protocolo até o encerramento do ticket, englobando o tempo dispendido no Service Desk e nos participantes demandados. Caso haja necessidade de complementação de informações essenciais em relação aos tickets, a contagem de prazo fica suspensa até que as referidas informações sejam prestadas. 3.2.2.7 Notificação de atualização dos tickets Toda atualização no ticket (conteúdo e/ou estado de atendimento) deverá ser notificada ao demandante. Os participantes demandados também poderão receber notificações. 3.3 Suporte a notificações O Service Desk deve dispor de funcionalidade para notificação e divulgação de informações relevantes para as instituições participantes e demais interessados. O processo envolve o reporte, a inserção em quadro de notícias e o envio de informações às instituições participantes. 3.3.1 Tipos de notificações As seguintes informações devem ser reportadas: I - problemas nas implementações das APIs; II - atualizações tempestivas sobre indisponibilidade de APIs; III - atualizações tempestivas sobre degradação de qualidade de serviços; IV - notificações sobre indisponibilidades programadas; e V - notificações sobre reestabelecimento de serviços. Também devem ser reportadas as seguintes mudanças técnicas: I - atualizações nas implementações das APIs; II - atualizações de políticas de segurança e/ou participantes; III - atualizações no Diretório de Participantes; e IV - atualizações nas definições de APIs. O detalhamento das informações e das formas de notificação deve estar previsto no Portal do Open Finance no Brasil. 3.4 Suporte aos serviços prestados pela Estrutura Responsável pela Governança do Open Finance O Service Desk deve prover suporte aos seguintes tópicos relacionados aos serviços prestados pela Estrutura Responsável pela Governança do Open Finance: I - registro dos participantes no Diretório de Participantes; II - acesso ao Diretório de Participantes; III - atualizações do Diretório de Participantes; e IV - consultas, reporte de problemas e reclamações quanto aos serviços prestados pela Estrutura Responsável pela Governança do Open Finance. 3.5 SLAs do Service Desk O Service Desk deve observar o seguinte nível mínimo de serviço: Disponibilidade: I - 24 horas por dia, 7 dias por semana; II - 95% a cada 24 horas; e III - 99,5% a cada 3 meses. Desempenho das APIs: Tempo de resposta de percentil 95 em, no máximo, 1500ms. 4. Plataforma de Resolução de Disputas A plataforma de resolução de disputas é ambiente que integra o mecanismo para resolução de disputas de que trata o art. 44, inciso IV, da Resolução Conjunta nº 1, de 2020. Complementarmente ao disposto neste manual, a plataforma de resolução de disputas deve ser desenvolvida de acordo com os padrões técnicos e outras questões operacionais definidas em documentos elaborados pela Estrutura Responsável pela Governança do Open Finance.