Orientação sobre tratamento de fuso horário nos testes funcionais Fase 3A - 1º CicloFase 3 – Tag de [Restrição] duplicada no campo proxy do swaggerFase 2 – Atualização da tabela de problemas conhecidosFase 2 – Alteração do conteúdo da seção Padrões/Pag...

Orientação sobre tratamento de fuso horário nos testes funcionais Fase 3A - 1º Ciclo

Atualmente, os cenários de testes do motor de conformidade funcional enviam o campo paymentDate da API Payments em formato UTC. Solicitamos às instituições que, por ora, processem essa data nesse formato.

Instituições que estejam processando esse campo de forma diferente poderão encontrar falhas em seus testes entre 21:00 a 23:59 (horário de Brasília). As equipes da Estrutura Inicial do Open Banking estão trabalhando em uma solução abrangente para esse tema.

Clique aqui para acessar a Área do Desenvolvedor - Tipos de Dados

Fase 3 – Tag de [Restrição] duplicada no campo proxy do swagger

Em response body do endpoint POST payments/pix/payments, foi corrigido a duplicação da tag [Restrição] e da regra de negócio localizada na descrição do campo proxy.

Para mais detalhes, consulte a área do desenvolvedor.

Clique aqui para acessar a Área do Desenvolvedor - Fase 3

Fase 2 – Atualização da tabela de problemas conhecidos

A tabela de problemas conhecidos das APIs de Fase 2 foi atualizada com a inclusão de recomendações para os seguintes problemas:

BCLOG-F02-194

Problema: o pattern das propriedades de links para paginação está incorreto, permitindo o preenchimento de um link sem https.

Recomendação: instituições devem preencher os campos com os links de paginação sempre com o scheme https.

BCLOG-F02-195

Problema: não há especificado o tratamento quando uma receptora solicitar um consentimento com permissões de dados cadastrais PF (CUSTOMERS_PERSONAL_IDENTIFICATIONS_READ/ CUSTOMERS_PERSONAL_ADITTIONALINFO_READ) e PJ (CUSTOMERS_BUSINESS_IDENTIFICATIONS_READ/ CUSTOMERS_BUSINESS_ADITTIONALINFO_READ) em conjunto.

Recomendação:

i. Para instituições receptoras: não deve ser solicitado consentimento com permissões de dados cadastrais PF e PJ em conjunto. Somente deve ser solicitado consentimento para compartilhar dados cadastrais PF ou para compartilhar dados cadastrais PJ.

ii. Para instituições transmissoras: caso receba uma solicitação de consentimento com permissões de dados cadastrais PF e PJ em conjunto, deve retornar um erro código HTTP 400.

Para mais detalhes, consulte a seção de problemas conhecidos da área do desenvolvedor.

Clique aqui para acessar a Área do Desenvolvedor - Fase 2

Fase 2 – Alteração do conteúdo da seção Padrões/Paginação/Regras Adicionais na área do desenvolvedor

Foi alterada a estratégia de paginação para todos os endpoints da Fase 2 em diante, de modo a solucionar o problema de diferentes limites superiores de page size. As orientações agora presentes na área do desenvolvedor são:

O tamanho máximo da página (page-size) é 1000 registros para qualquer endpoint (a menos que na API esteja especificado outros valores)

A instituição transmissora/detentora pode definir um tamanho máximo da página (page-size) inferior ao tamanho máximo permitido pela API, caso entenda necessário diminuir o limite para atender o SLA de resposta

Caso a instituição transmissora/detentora defina um tamanho máximo de página (page-size) inferior, se for requisitado uma quantidade de registros maior do que seu limite operacional, e desde que o valor esteja de acordo o tamanho máximo permitido pela API, esta deverá responder entregando os dados e utilizando o page-size do seu limite operacional definido

A instituição transmissora/detentora deve realizar os ajustes de paginação antes de efetivar a consulta:

Ex: ao solicitar a segunda página 1000 registros, para uma instituição que trabalha com page-size máximo de 800, a transmissora deve retornar os itens de 801 a 1600

Se for requisitado uma quantidade de registros maior que o suportado pela API, o retorno será o código HTTP status code 422 Unprocessable Entity, indicando que o servidor entendeu a requisição, mas não é possível processá-la conforme foi solicitado

Para mais detalhes, consulte a área do desenvolvedor (Paginação).

Clique aqui para acessar a Área do Desenvolvedor - Paginação

Fase 2 – Alteração do conteúdo da seção Padrões/Paginação/Links na área do desenvolvedor

Foi realizado um ajuste no texto de paginação apresentado na área do desenvolvedor para a seção Links. As orientações agora presentes são:

O objeto links passará por revisão subsequente de modo a atender as próximas Fases do Open Banking, em especial a partir da Fase 2.

Os links devem sempre ser validados de acordo com o pattern publicado no swagger.

Quando preenchidos, devem ter a mesma estrutura (schema, host, api, versao e recurso) do que está sendo paginado.

No objeto links, serão retornadas hypermedia (referências para os recursos relacionados) de paginação conforme parâmetros estabelecidos na área do desenvolvedor

Para mais detalhes, consulte a área do desenvolvedor (Paginação).

Clique aqui para acessar a Área do Desenvolvedor - Paginação

Fase 2 – Inclusão de restrição nos campos fromBookingDate e toBookingDate

Foram realizadas alterações para os parâmetros fromBookingDate e toBookingDate de forma a solucionar problemas envolvidos com estes campos:

Caso seja enviado um valor com data inválida ou valor nulo à API, por parte de qualquer um dos campos fromBookingDate e toBookingDate, deve ser retornado um erro HTTP status 400.

Caso ambos os campos não sejam enviados:

Caso fromBookingDate não seja enviado, é assumido o dia corrente.

Caso toBookingDate não seja enviado, é assumido o dia corrente.

Caso um dos campos seja enviado, o outro se torna obrigatório:

Quando um dos campos (fromBookingDate e toBookingDate) for enviado, o envio do outro campo se torna obrigatório. Caso contrário, deve ser retornado um erro com HTTP status 400.

Para mais detalhes, consulte a área do desenvolvedor.

Clique aqui para acessar a Área do Desenvolvedor - Fase 2

Processo de notificação em caso de incidentes

Para cumprir com a exigência regulatória, é necessário que o Open Banking Brasil seja notificado da ocorrência de qualquer incidente que esteja relacionado com o Open Banking. Essa notificação deverá ser realizada através do registro do incidente no Service Desk.

No catálogo de serviços, selecionar “Incidentes”, depois “Service Desk” e por último “Indisponibilidade”, informando os detalhes do incidente. A partir de 2 de novembro, haverá um item específico para notificação no Service Desk, bastando selecionar “Incidentes”, depois “Segurança da Informação” e por último “Notificação”, informando os detalhes do incidente.

Em caso de comprometimento dos certificados utilizados ou do cliente na iniciação de pagamento, um dos administradores da instituição deverá entrar no diretório de participantes e revogar todos os certificados de assinatura que estão associados ao Software Statement comprometido.

A revogação do certificado de assinatura é feita ao nível da organização no menu “Certificados de organização”, na lixeira localizada em ações.

Uma vez revogado o certificado, as suas informações não irão mais figurar no Jason Web Key Set (JWKS) do diretório, o que irá impedir a validação das mensagens assinadas com esse certificado e consequentemente impede a comunicação com outras instituições do ecossistema.

Uma vez revogado o certificado na AC, o mesmo irá constar como revogado de forma automática no diretório, não sendo necessária a realização do processo acima. Porém, a revogação do certificado no diretório não é espelhada de forma automática na Autoridade Certificadora (AC), logo a instituição também deverá informar sua AC que seu certificado foi comprometido.

Clique aqui para acessar acessar o Service Desk