|
Data |
Versão |
Descrição das alterações |
|
11.08.2020 |
1.0 |
Versão inicial. |
|
10.09.2020 |
1.1 |
Seção 6: Ajustes na redação do fluxo de reivindicação, para deixar mais claro seu funcionamento: • caso o usuário doador não se manifeste dentro do período de resolução, o PSP doador deve necessariamente confirmar a reivindicação no DICT; • no período de encerramento, o usuário doador pode somente validar a posse da chave, cancelando o processo. A confirmação não é possível durante esse período; e • previsão de que o PSP reivindicador deve cancelar o processo de reivindicação no DICT caso seu usuário não faça a validação ativa da chave até o trigésimo dia após o início do processo de reivindicação. |
|
|
|
Seção 6.1: ajustes nas etapas 5 e 7, para deixar a redação mais clara e para incorporar os ajustes feitos ne seção 6. Seção 6.2: ajustes nas etapas 7, 11, 12 e 13, para deixar a redação mais clara e para incorporar os ajustes feitos ne seção 6. Seção 6.3: • ajuste no fluxo; e |
|
|
|
• ajustes nas etapas 4, 12, 14, 15, 16, 17, 19 e 20, para deixar a redação mais clara e para incorporar os ajustes feitos ne seção 6. Seção 6.4: • ajuste no fluxo; e • ajustes nas etapas 6, 16, 18, 20, 21, 22, 23, 27 e 28, para deixar a redação mais clara e para incorporar os ajustes feitos ne seção 6. Seção 9: ajuste para deixar claro que a verificação de sincronismo não precisa ser realizada diariamente. Ela precisa ser realizada em intervalos máximos de 36 horas, conforme Manual de Tempos do Pix. |
|
|
|
Seção 10: ajuste para prever que a notificação de infração pode ser cancelada a qualquer tempo. Seção 10.1: ajuste na nomenclatura das mensagens enviadas para o DICT. Seção 10.2: ajuste na nomenclatura das mensagens enviadas para o DICT |
|
13.11.2020 |
2.0 |
Estrutura: inserção da seção 15 "Limitação de requisições à API do DICT". Seção 5: inserção de nota de rodapé para explicitar que é possível atualizar dados da conta vinculados à chave enquanto o status da requisição de portabilidade estiver "Aberto" ou "Aguardando Resolução". Seção 6: inserção de nota de rodapé para explicitar que é possível atualizar dados da conta vinculados à chave enquanto o status da requisição de reivindicação de posse estiver "Aberto" ou "Aguardando Resolução". |
|
|
|
Seção 9: inserção de texto para detalhar como deve ser o processo de correção de chave divergente após uma verificação de sincronismo. Seção 10: retirada do campo "Motivo" no processo de abertura de uma notificação de infração. Seção 14: retirada das informações, que o DICT armazena, relativas a transações com suspeita de infração à regulação de prevenção à lavagem de dinheiro e ao financiamento do terrorismo. |
|
17.11.2020 |
2.1 |
Seção 9: orientação para que eventuais divergências encontradas entre a base interna e o DICT, após processo de verificação de sincronismo, sejam corrigidas na base interna. |
|
18.03.2021 |
3.0 |
Estrutura: inserção das seções 16 "Fluxo de verificação de chaves Pix registradas" e 17 "Cache de existência de chave Pix". Seção 7.1: ajuste no fluxo e na tabela de passo a passo, para prever possibilidade de alteração do nome do usuário vinculado à chave Pix. Seção 7.2: ajuste no fluxo e na tabela de passo a passo, para prever possibilidade de alteração do nome do usuário vinculado à chave Pix. Seção 15: ajuste de forma e de texto na tabela que detalha a política de rate limit, com a inclusão dos limites para o keys.read. |
|
08.06.2021 |
4.0 |
Estrutura: inserção da seção 18 "Fluxo de solicitação de devolução". Estrutura: inserção das subseções 10.3 "Fluxo de notificação de infração para abertura de solicitação de devolução (participantes do Pix com acesso direto ao DICT)" e 10.4 "Fluxo de notificação de infração para abertura de solicitação de devolução (participantes do Pix com acesso indireto ao DICT)". Seção 5: previsão de possibilidade de cancelamento de uma portabilidade com status "Confirmado" pelo PSP reivindicador. |
|
|
|
Seção 10: inserção do campo "Motivo" e detalhamento dos campos na abertura de uma notificação de infração; detalhamento dos campos no fechamento de uma notificação de infração; e detalhamento do funcionamento do fluxo de notificação de infração para abertura de solicitação de devolução. Seção 10.1: alteração do nome da seção para "Fluxo de notificação de infração entre participantes do Pix com acesso direto ao DICT, por motivo 'fraude'". |
|
|
|
Seção 10.1: prazo máximo para abertura de notificação de infração passa a ser oitenta dias corridos (etapa 2). Seção 10.1: prazo máximo para análise de uma notificação de infração passa a ser sete dias (etapa 7). Seção 10.2: alteração do nome da seção para "Fluxo de notificação de infração entre participantes do Pix com acesso indireto ao DICT, por motivo 'fraude'". Seção 10.2: prazo máximo para abertura de notificação de infração passa a ser oitenta dias corridos (etapa 2). |
|
|
|
Seção 10.2: prazo máximo para análise de uma notificação de infração passa a ser sete dias (etapa 14). Seção 13: tamanho máximo do balde do usuário final passa a ser 1.000 fichas, com incremento temporal de 2 fichas a cada minuto; tamanho máximo do balde do participante passa a ser 20.000 fichas, com incremento temporal de 6.000 fichas a cada minuto; e inserção de texto para dar flexibilidade ao Banco Central do Brasil na gestão dos baldes. Seção 15: ajustes na tabela com os limites de requisições à API do DICT |
|
29.06.2021 |
4.1 |
Seção 15: incorporação de novos limites de requisição à API do DICT. |
|
22.07.2021 |
4.2 |
Estrutura: inserção das subseções 8.3 "Fluxo de consulta para o participante do Pix que atua como prestador de serviço de iniciação de transação de pagamento, com acesso direto ao DICT" e 8.4 "Fluxo de consulta para o participante do Pix que atua como prestador de serviço de iniciação de transação de pagamento, com acesso indireto ao DICT". Seção 10: inclusão das notas de rodapé 6 e 7, para deixar clara a data a partir da qual os prazos relacionados à notificação de infração começarão a valer. |
|
|
|
Seção 13: inserção dos mecanismos de prevenção a ataques de leitura para os participantes que prestem serviço de iniciação de transação de pagamento. Seção 15: inclusão da nota de rodapé 10, para deixar claro que os mesmos limites para a verificação de chaves Pix registradas são aplicáveis aos participantes iniciadores. |
|
24.08.2021 |
4.3 |
Seção 10: inserção de nota de rodapé para deixar claro que a notificação de infração para abertura de solicitação de devolução estará disponível somente a partir de 16 de novembro de 2021, nos termos da Resolução BCB nº 103. Seção 13: ajustes nos mecanismos de prevenção a ataques de leitura do DICT. As consultas sem liquidação para todos os tipos de chave passam a consumir fichas nos baldes, tanto para os usuários finais quanto para os participantes. Para isso, foi criado um novo balde, com 1.000 fichas, para as chaves CPF, CNPJ e aleatória para os usuários finais; e foi aumentado o incremento temporal de fichas para os participantes. |
|
|
|
Seção 13: inserção de nota de rodapé para explicar as novas regras de formação do campo PayerId. Seção 15: criação de um balde específico para o endpoint updateEntry. Com isso, o balde do createEntry e do deleteEntry foi diminuído. Seção 18: ajuste em nota de rodapé, para deixar claro que a solicitação de devolução estará disponível somente a partir de 16 de novembro de 2021, nos termos da Resolução BCB nº 103 |
|
21.09.2021 |
4.4 |
Seção 10: inserção de texto para deixar mais claro o funcionamento da funcionalidade. Seção 10.3: inserção de notas de rodapé para deixar claro os casos em que o Mecanismo Especial de Devolução não pode ser acionado. Seção 10.4: inserção de notas de rodapé para deixar claro os casos em que o Mecanismo Especial de Devolução não pode ser acionado. Seção 13: ajustes nos mecanismos de prevenção a ataques de leitura do DICT. Separação de baldes de consultas de usuários PF e PJ, com definição de parâmetros diferenciados, através da identificação do tipo de pessoa pelo campo PayerID. Além disso, os baldes de consultas de participantes passam a ter categorias com parâmetros diferenciados de tamanho e incremento, de forma a se adequar às necessidades de cada participante. |
|
|
|
Seção 13: ajuste na nota de rodapé 13, para deixar claro o formato a ser usado no campo PayerId. Seção 15: remoção da política geral entries.read e inclusão de nota de rodapé, para explicar que essa política está sendo tratada com mais detalhes na seção 13. Além disso, os parâmetros da política update.entries foram reduzidos. |
|
|
|
Seção 18: inserção de texto para deixar mais claro o funcionamento da funcionalidade. Seção 18.2: ajuste na etapa 15, para deixar o texto mais claro. Seção 18.3: ajuste no fluxo, para consertar a etapa 4, que estava identificando um estado de forma equivocada. Seção 18.4: ajuste no fluxo, para consertar a etapa 6, que estava identificando um estado de forma equivocada. Seção 18.5: inserção de notas de rodapé, para deixar mais claro o funcionamento da funcionalidade. |
|
03.11.2021 |
5.0 |
Estrutura: inserção da seção 19 "Consulta a informações vinculadas às chaves Pix para fins de segurança do Pix". Seção 8.1: alteração na etapa 7 do fluxo, para alterar a forma de identificação do usuário pagador na consulta (usuário pagador deve ser identificado por meio de seu CPF/CNPJ, e não mais por meio de um identificador pseudonimizado. Seção 8.1: alteração na etapa 9 do fluxo, para alterar a forma de identificação do usuário pagador na consulta (usuário pagador deve ser identificado por meio de seu CPF/CNPJ, e não mais por meio de um identificador pseudonimizado). |
|
|
|
Seção 10: ajustes no texto para prever os novos campos que permitirão a notificação de infração para transações liquidadas fora do SPI e para transações rejeitadas. Seção 10.1: ajustes para explicar como deve ser a interpretação do fluxo nos casos de transações liquidadas fora do SPI e de transações rejeitadas. Seção 10.2: ajustes para explicar como deve ser a interpretação do fluxo nos casos de transações liquidadas fora do SPI e de transações rejeitadas. Seção 13: alteração na forma de identificação do usuário pagador na consulta (usuário pagador deve ser identificado por meio de seu CPF/CNPJ, e não mais por meio de um identificador pseudonimizado). |
|
|
|
Seção 14: alteração nas informações para fins de segurança que são retornadas pelo DICT sempre que uma chave é consultada. |
|
19.11.2021 |
5.1 |
Seção 14: as informações para fins de segurança referentes a 3 dias continuarão, provisoriamente, sendo apresentadas sempre que uma chave é consultada. Seção 15: inserção da limitação de requisições ao endpoint "statistics_read". Seção 18: inserção de novo domínio no campo "RefundRejectionReason". Seção 19: previsão de que informações sobre transações rejeitadas que sofreram notificação de infração também serão retornadas na consulta a informações vinculadas às chaves Pix |
|
12.01.2022 |
5.2 |
Seção 10: ajuste no texto para prever que, em transações "INTERNAL" em que o PSP do pagador e o PSP do recebedor possuem um mesmo liquidante, quem fecha a notificação, concordando ou discordando, é a contraparte que não abriu a notificação. Seção 16.1: ajuste no fluxo e na tabela de passo a passo em decorrência da possibilidade de verificação de registro de todos os tipos de chaves Pix. Seção 16.2: ajuste no fluxo e na tabela de passo a passo em decorrência da possibilidade de verificação de registro de todos os tipos de chaves Pix. |
|
|
|
Seção 17: ajustes no texto em decorrência da possibilidade de verificação de registro de todos os tipos de chaves Pix. |
|
11.02.2022 |
5.3 |
Seção 13: alteração no modo de recomposição de fichas dos baldes de consulta do DICT, que passam a ser repostas após o recebimento da ordem de pagamento pelo SPI na PACS.008, e não mais após uma liquidação. Seção 15: inclusão da informação em nota de rodapé da quantidade máxima de 200 (duzentas) chaves passíveis de serem verificadas por cada requisição da operação checkKeys. |
|
01.09.2022 |
5.4 |
Seção 8.3: ajuste na etapa 5, para prever que o EndToEndId de uma transação deve ser gerado pelo prestador de serviço de iniciação. Seção 8.4: ajuste na etapa 5, para prever que o EndToEndId de uma transação deve ser gerado pelo prestador de serviço de iniciação. Seção 13: participantes que prestam serviço de iniciação devem passar a usar o mesmo endpoint para consulta de chaves que os participantes provedores de conta transacional. Como consequência, as regras de limites e de decréscimo e de acréscimo de fichas passam a ser as mesmas para todos os participantes. |
|
|
|
Seção 15: aumento do incremento do balde e do tamanho máximo do balde para a transação statistics_read. |
|
03.10.2022 |
6.0 |
Estrutura: inserção da seção 20 "Consulta de baldes". Seção 10.3: ajuste na tabela de passo a passo (passo 12), para deixar claro que não há especificação de valor a ser devolvido em uma notificação de infração. Seção 10.4: ajuste na tabela de passo a passo (passo 16), para deixar claro que não há especificação de valor a ser devolvido em uma notificação de infração. |
|
|
|
Seção 13: (i) aumento de 10 para 20 no decréscimo de fichas por consulta inválida de qualquer chave, para usuários pessoa natural e pessoa jurídica; (ii) aumento de 8.000 para 12.000 e de 5.000 para 8.000 no incremento de fichas por minuto dos baldes das categorias A e B, respectivamente; e (iii) ajuste no tamanho máximo do balde para usuários finais pessoa natural e pessoa jurídica. Seção 15: (i) alteração no nome da política de rate limit de keys.read para keys.check; e
(ii) inclusão de novas políticas de rate limit.
|
