INSTRUÇÃO NORMATIVA BCB Nº 593, DE 19 DE MARÇO DE 2025 (parte 2 de 3)

ANEXO
Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT)
. .Data .Versão .Descrição das alterações
. .11/8/2020 .1.0 .
. .10/9/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/3/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.
. .8/6/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/6/2021 .4.1 .Seção 15: incorporação de novos limites de requisição à API
do DICT.
. .22/7/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/8/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/9/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.
. .3/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/1/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/2/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.
. .1/9/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.
. .3/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.
. .2/1/2023 .6.1 .Seção 10: ajustes no texto para enfatizar que o PSP do pagador
deve abrir a notificação de infração no DICT imediatamente após
a reclamação do usuário pagador.
Seção 10.3: ajuste no fluxo e na tabela de passo a passo para
remover a condição em que o PSP não pode acionar o MED.
Seção 10.4: ajuste no fluxo e na tabela de passo a passo para
remover a condição em que o PSP não pode acionar o MED.
Seção 18: (i) ajuste no texto para esclarecer que a solicitação do
cancelamento de devolução deve ser criada pelo PSP do
recebedor; (ii) inclusão
. . . .do detalhamento sobre o monitoramento a ser realizado pelo
PSP em caso de devoluções parciais; e (iii) remoção da condição
em que o PSP não pode acionar o MED.
Seção 18.1: ajuste no fluxo e na tabela de passo a passo para
remover a condição em que o PSP não pode acionar o MED.
Seção 18.2: ajuste no fluxo e na tabela de passo a passo para
remover a condição em que o PSP não pode acionar o MED.
Seção 18.3: ajuste no fluxo e na tabela de passo a passo para
remover a condição em que o PSP não pode acionar o MED.
. . . .Seção 18.4: ajuste no fluxo e na tabela de passo a passo para
remover a condição em que o PSP não pode acionar o MED.
. .5/11/23 .7.0 .Estrutura: exclusão da seção 14 "Informações vinculadas às
chaves para fins de segurança" e renumeração das seções
posteriores
Seção 8: inclusão das informações retornadas pelo DICT quando
uma chave é consultada.
Seção 10: reestruturação da seção, com criação de duas
subseções: uma para detalhar a notificação de infração para
solicitação de devolução ou para cancelamento de devolução; e
outra para detalhar a notificação de infração para marcação de
fraude transacional. O detalhamento da funcionalidade foi
atualizado para incluir novas informações de segurança a serem
compartilhadas com os participantes. As subseções 10.1 e 10.2
. . . .da versão anterior foram transformadas em subseções 10.2.1 e
10.2.2, respectivamente, com ajustes no fluxo. As subseções 10.3
e 10.4 da versão anterior foram transformadas em subseções
10.1.1 e 10.1.2, respectivamente. Foram criadas, ainda, duas
subseções, 10.1.3 e 10.1.4, para detalhar, respectivamente, o
fluxo de notificação de infração do tipo "cancelamento de
devolução" entre participantes com acesso direto ao DICT e o
fluxo de notificação de infração do tipo "cancelamento de
devolução" entre participantes com acesso indireto ao DICT
Seção 13: criação de duas subseções: 13.2.1 Mecanismos
adotados pelo DICT (que manteve o texto da versão anterior,
com a atualização da
. . . .política de crédito de ficha em transações envolvendo
prestadores de serviço de iniciação e o detalhamento da política
de limitação para a nova operação getKeyStatistics) e 13.2.2
Mecanismos que devem ser adotados pelos participantes do
Pix.
Seção 14 (corresponde à seção 15 da versão anterior): ajuste na
política de limite de requisições da operação getOwnerStatistics
e criação da política de limite de requisição para as novas
operações getKeyStatistics e createFraudMarker.
Seção 17 (corresponde à seção 18 da versão anterior): ajuste no
texto para deixar claro que a conta deve ser monitorada em caso
de devolução
. . . .parcial ou de rejeição da solicitação de devolução, desde que a
conta transacional não tenha sido encerrada, pelo usuário ou
pelo próprio PSP.
Seção 18 (corresponde à seção 19 da versão anterior):
reestruturação completa da seção, inclusive de seu título, para
refletir as novas informações de segurança que serão retornadas
pelo DICT quando um CPF, um CNPJ ou uma chave é consultada
no endpoint statistics.
Seção 18.1 (corresponde à seção 19.1 da versão anterior): ajuste
no título e no fluxo.
Seção 18.2 (corresponde à seção 19.2 da versão anterior): ajuste
no título e no fluxo.
. .1/12/2023 .7.1 .Seção 13.1: Inclusão de duas novas categorias de baldes para
participantes no mecanismo de prevenção a ataque de leitura do
DICT e ajustes nos parâmetros de tamanho máximo e incremento
temporal dos baldes.
Seção 17.5: Inserção de determinação para que o PSP do
pagador, caso aceite a notificação de infração para cancelamento
de devolução, cancele imediatamente a notificação de infração
para solicitação de devolução que ele criou para solicitar a
devolução da transação original.
. .2/5/2024 .7.2 .Seção 5: Ajuste no texto para informar que uma portabilidade
pode ser cancelada pelo PSP reivindicador enquanto o status do
pedido for "Aberto".
Seção 6: Ajuste no texto para informar que uma reivindicação de
posse pode ser cancelada pelo PSP reivindicador enquanto o
status do pedido for "Aberto".
Seção 10.1: Inserção de explicação sobre notificação de infração
contra usuário recebedor que atua como intermediário de
pagamentos.
. . . .Seção 10.1: Inserção de determinação para que o PSP do
pagador cancele a solicitação de devolução aberta caso ele tenha
cancelado a notificação de infração que deu origem a ela. Se tiver
havido devolução, o PSP do pagador deverá devolver os recursos
para o PSP do recebedor através de uma nova transação Pix e
abrir uma notificação de infração para marcação de fraude
contra seu usuário se concluir que ele agiu de má fé.
Seção 13.1: Aumento da taxa de reposição por consulta de
qualquer chave após o recebimento da ordem de pagamento
pelo SPI para 2 fichas para o balde de usuário PJ e aumento do
incremento temporal para 20 fichas a cada minuto em cada
balde de usuário PJ.
. . . .Seção 13.1: Inserção da informação de que, excepcionalmente, a
critério do Banco Central do Brasil, os parâmetros de balde de
um usuário PJ podem ser alterados.
Seção 13.1: Inclusão de trecho na nota de rodapé para deixar
claro que solicitações de aumento de categoria de balde devem
estar devidamente fundamentadas em dados históricos, e não
em projeções futuras.
Seção 17: Inclusão de trecho para permitir que o PSP do
recebedor encerre o monitoramento da conta do usuário
recebedor caso a notificação de
. . . .infração para solicitação de devolução seja cancelada pelo PSP
do pagador.
. .02/09/2024 .7.3 .Seção 1: criação da subseção 1.1 para orientações sobre chaves
bloqueadas por ordem judicial
Seção 8: reestruturação da seção, com criação de uma subseção
8.1 para detalhar quais informações devem ser exibidas ao
usuário na consulta de chave. As subseções 8.1, 8.2, 8.3 e 8.4 da
versão antiga foram transformadas 8.2, 8.3, 8.4 e 8.5
respectivamente
Seção 8.2 (antiga 8.1): inserção de texto, na tabela do fluxo, para
deixar claro que os dados da chave podem ser informados de
forma manual ou via leitura de QR Code.
. . . .Seção 8.3 (antiga 8.2): inserção de texto, na tabela do fluxo, para
deixar claro que os dados da chave podem ser informados de
forma manual ou via leitura de QR Code. Inserção de mais uma
etapa para o PSP com acesso direto ao DICT, para que verifique
se a chave está cadastrada em sua base interna.