Orientações para tratativa de consentimentos órfãos após desativação de rotação de refresh tokensGuia do Pix – Serviço de iniciação de transação de pagamento no Pix (Temporização de Transações)Esclarecimentos sobre o tamanho e comportamento do campo tr...

Orientações para tratativa de consentimentos órfãos após desativação de rotação de refresh tokens

Conforme informado no Informa #96, foi proibida a rotação do refresh token, com estabelecimento da data limite de 29/11/2021 para adequação das instituições. Esta definição pode ter levado ao surgimento de consentimentos órfãos, ou seja, consentimentos que possuem refresh tokens inválidos devido aos problemas ocasionados no passado com a rotação.

Na 92ª reunião do Conselho Deliberativo aprovou-se um processo padrão bilateral recomendado para a tratativa desses consentimentos órfãos, incluso cronograma e prazos.

Dada a desativação da rotação de refresh tokens em 29/11/2021, este processo será conduzido de forma pontual (uma única vez) entre as instituições para tratamento dos consentimentos órfãos estoque.

Processo resumido

Além do processo resumido abaixo, o processo todo detalhado em diagrama de sequência pode ser acessado por meio do botão ao final deste informe.

Cada Instituição participante oferece um sFTP para upload de seus consentimentos

Cada receptora gera um par de chaves arbitrário e submete ao diretório, notifica o KID ao transmissor

Instituição receptora gera uma listagem de CONSENT_ID com REFRESH_TOKEN órfão

i. A listagem precisa seguir um padrão CSV com um consentimento por linha

Instituição transmissora tem um prazo de até 10 dias úteis para geração dos

REFRESH_TOKENs correspondentes

i. Aplica criptografia pela chave pública correspondente ao KID do diretório (obrigatório)

ii. A listagem precisa seguir um padrão CSV com um consentimento por linha e REFRESH_TOKEN separado por “ponto e vírgula“

iii. Submete a extração ao sFTP da receptora

iv. Receptora decriptografa o arquivo recebido e possui 2 dias úteis para confirmar recebimento à transmissora

v. Receptora atualiza os dados em sua base.

Importante lembrar que, como este é um processo bilateral, as instituições podem:

Definir, entre elas, outro método de troca de arquivo

Em caso de não acordo entre as instituições, deve ser utilizado o sFTP ou a IF deve refazer o pedido de consentimento

Dar início ao processo antes da data indicada, desde que acordado entre as partes e respeitados os prazos limites

Cronograma e prazos do processo

Início do processo: 10/01/2022

Prazo máximo para envio do último pedido da receptora à transmissora: 27/02/2022

Prazo máximo para o término de todo o processo: 11/03/2022

Acompanhamento do andamento do processo

Conforme detalhado no diagrama, está previsto acompanhamento pela Estrutura do Open Banking Brasil do andamento do processo entre as instituições e estoque de consentimentos órfãos ainda sem tratamento. Uma pesquisa será enviada para este fim às Instituições participantes em dois momentos ao longo do calendário do processo (10/02/2022 e 10/03/2022).

Clique aqui para acessar o diagrama detalhado do processo

Guia do Pix – Serviço de iniciação de transação de pagamento no Pix (Temporização de Transações)

A respeito das orientações presentes no Guia do Pix abaixo, no item 2 da página 75, Serviço de iniciação de transação de pagamento no Pix - Recomendações e Obrigações.

“O usuário pagador deve ser notificado caso a transação seja suspeita de fraude, sempre que o PSP precise utilizar o tempo adicional para análise da transação. Durante o período em que a ordem de pagamento estiver sendo analisada, o participante prestador do serviço de iniciação de pagamento deve disponibilizar, para o usuário pagador, a opção de cancelamento da transação. Por isso, o PSP deve sempre notificar o PSI nesses casos.

Mensagem obrigatória: Deve evidenciar que a transação precisa de um tempo adicional de análise para ser autorizada e dar a opção de cancelamento da transação.

Exemplos:

-Precisamos de 30 minutos adicionais para analisar sua transação. Deseja cancelar o Pix?

-Sua transação precisa de aproximadamente 60 minutos para ser autorizada. Deseja cancelar a transação?”

Sobre as orientações acima, esclarecemos:

Caso a detentora temporize uma transação, a mesma deve ser informada à iniciadora com o status PDNG até que a transação seja iniciada no arranjo

No caso de rejeição:

2.1. (Assíncrona) Caso a detentora rejeite uma transação que foi temporizada a mesma deve informar à  iniciadora o status reject com o rejection reason AB11 (TIMEOUT_DEBTOR_AGENT)

A iniciadora deve interpretar esse status com a mensagem descritiva: “Transação rejeitada devida análise de fraude do detentor de conta”

2.2 (Síncrona) Caso a detentora opte por rejeitar a transação devido às suas políticas de fraudes, a mesma deve informar à iniciadora o status 422 com o Code NAO_INFORMADO

Caso a decisão seja prosseguir com a transação, o fluxo continua seguindo a máquina de estados do pagamento

Além disso, será incluído na planilha de problemas conhecidos da Fase 3, o seguinte ponto:

API/Sessão: API Payments / Schema EnumPaymentStatusType

Endpoint: GET /payments/v1/pix/payments/{paymentId}

Campo: status

Qual o problema: A respeito das orientações presentes no Guia do Pix, no item 02 da página 75, Serviço de iniciação de transação de pagamento no Pix - Recomendações e OBRIGAÇÕES

“O usuário pagador deve ser notificado caso a transação seja suspeita de fraude, sempre que o PSP precise utilizar o tempo adicional para análise da transação. Durante o período em que a ordem de pagamento estiver sendo analisada, o participante prestador do serviço de iniciação de pagamento deve disponibilizar, para o usuário pagador, a opção de cancelamento da transação. Por isso, o PSP deve sempre notificar o PSI nesses casos.

Mensagem obrigatória: Deve evidenciar que a transação precisa de um tempo adicional de análise para ser autorizada e dar a opção de cancelamento da transação.

Exemplos:

-Precisamos de 30 minutos adicionais para analisar sua transação. Deseja cancelar o Pix?

-Sua transação precisa de aproximadamente 60 minutos para ser autorizada. Deseja cancelar a transação?”

As orientações do Guia demandam maiores esclarecimentos e a criação de um campo TEMP.

Como deveria ser: Deve ser criado um status TEMP para transações temporizadas – comportamento desse novo status deve ser realizada em conjunto com GT PRC / Fraudes.

Orientação:

Caso a detentora temporize uma transação a mesma deve ser informada a iniciadora com o status PDNG até que a transação seja iniciada no arranjo.

No caso de rejeição:

2.1 (Assíncrona) Caso a detentora rejeite uma transação que foi temporizada a mesma deve informar à iniciadora o status reject com o rejection reason AB11 (TIMEOUT_DEBTOR_AGENT). A iniciadora deve interpretar esse status com a mensagem descritiva: “Transação rejeitada devida análise de fraude do detentor de conta”.

2.2 (Síncrona) Caso a detentora opte por rejeitar a transação devido suas políticas de fraudes, a mesma deve informar àiniciadora o status 422 com o Code NAO_INFORMADO.

Caso a decisão seja prosseguir com a transação, o fluxo continua seguindo a máquina de estados do pagamento.

Esclarecimentos sobre o tamanho e comportamento do campo transactionIdentification da API Payments

A estrutura do Open Banking esclarece:

Serão adicionadas à planilha de problemas conhecidos os três itens abaixo, que orientam a respeito do uso do campo transactionIdentification:

Ajuste no texto descritivo atualmente aplicado ao campo transactionIdentification

API/Sessão: API Payments

Endpoint: POST/payments/v1/pix/payments

Campo: transactionIdentification

Qual o problema: Esclarecimento sobre utilização do campo para os diferentes tipos de localInstrument.

Como deveria ser: Conforme ‘orientação’ descrita.

Orientação: Se localInstrument for igual a INIC, o campo transactionIdentification deve ser preenchido obrigatoriamente. Se localInstrument for igual a MANU, DICT, QRDN ou QRES, o campo transactionIdentification não deve ser preenchido. A detentora de conta deve validar se a condicionalidade do campo foi atendida pela iniciadora de pagamento.

Uso do código 422 no transactionIdentification

API/Sessão: API Payments

Endpoint: POST/payments/v1/pix/payments

Campo: 422ResponseErrorCreatePixPayment

Qual o problema: Detalhamento sobre o código de erro em caso de envio incorreto do transactionIdentification, conforme orientações contidas no problema conhecido BCLOG-F03-009.

Como deveria ser: Criação de código de erro específico para o caso citado no problema conhecido BCLOG-F03-009.

Orientação: uso do 422 com o Code NÃO_INFORMADO para o caso citado no problema conhecido BCLOG-F03-009.

Alteração do tamanho do campo de transactionIdentification

API/Sessão: API Payments

Endpoint: POST/payments/v1/pix/payments e GET /payments/v1/pix/payments/{paymentid}

Campo: transactionIdentification

Qual o problema: Problema de incompatibilidade de tamanho de campo transactionIdentification da api payments com o regulamentado pelo arranjo pix.

Como deveria ser: API Payments prevê 25 caracteres e o arranjo pix, de 26 a 35 caractereres - somente para QR Code dinâmico

Orientação: Considerar o campo como tamanho máximo de 35 caracteres, desconsiderando o pattern no swagger.