Documento de Especificações - Versão 5-0

Especificações técnicas e de negócio
do ecossistema de pagamentos
instantâneos brasileiro
Versão 5.0
1
SUMÁRIO
Apresentação ...................................................................................................................... 5
1. ESPECIFICAÇÃO DAS TRANSAÇÕES DE TRANSFERÊNCIA DO PIX ................................ 8
1.1. Processo de efetivação do PIX .......................................................................... 10
1.1.1. Fluxo de transações entre participantes diretos ....................................... 12
1.1.2. Fluxo de transações entre participantes indiretos.................................... 15
1.1.3. Fluxo de transações nos livros do PSP....................................................... 19
1.2. Processo de inserção dos dados para iniciação do PIX ..................................... 20
1.2.1. Inserção manual dos dados pelo pagador ................................................ 21
1.2.2. Envio prévio sistematizado de informações ............................................. 25
1.2.2.1. QR Code estático ............................................................................... 26
1.2.2.2. QR Code dinâmico ............................................................................. 29
1.2.2.3. QR Code gerado pelo pagador .......................................................... 32
1.2.2.4. Padrão do QR Code: layout das informações .................................... 35
1.3. Cenários de insucesso na liquidação do PIX ...................................................... 38
1.3.1. Validação da mensagem de pagamento pelo SPI ..................................... 39
1.3.1.1. Diferença entre as respostas via ADMI.002 e via PACS.002 ............. 41
1.3.2. Saldo insuficiente na Conta PI do PSP do pagador.................................... 42
1.3.3. Validações efetuadas pelo PSP do recebedor ........................................... 44
1.3.4. Controle de timeout no SPI ....................................................................... 45
1.3.5. Problemas após a transação ser considerada final e irrevogável ............. 47
1.4. Devolução do PIX............................................................................................... 48
1.4.1. Criação de ordem de devolução................................................................ 50
1.4.2. Devolução entre participantes diretos...................................................... 52
1.4.3. Devolução entre participantes indiretos ................................................... 54
2. ESPECIFICAÇÕES TÉCNICAS DO PIX ........................................................................... 58
2.1. Participação no PIX ............................................................................................ 59
2.2. Padrão de comunicação .................................................................................... 59
2.2.1. Padrão de representação das mensagens ................................................ 60
2.3. Conectividade .................................................................................................... 61
2
2.3.1. Interface de comunicação ......................................................................... 62
2.4. Princípios de segurança..................................................................................... 62
2.5. Requisitos de segurança.................................................................................... 63
2.5.1. Criptografia e autenticação mútua na comunicação ................................ 63
2.5.2. Assinatura digital das mensagens ............................................................. 63
2.5.3. Certificados digitais a serem utilizados ..................................................... 64
2.5.4. Ativação e desativação de certificados digitais ......................................... 64
2.5.5. Manutenção de logs de segurança ........................................................... 64
2.6. Diretório de Identificadores de Contas Transacionais (DICT) ........................... 65
2.6.1. Chaves para endereçamento .................................................................... 65
2.6.2. Regras de acesso ....................................................................................... 69
2.6.3. Fluxo de registro de chave ........................................................................ 69
2.6.4. Fluxo de exclusão de chave ....................................................................... 76
2.6.4.1. Exclusão por solicitação do usuário .................................................. 77
2.6.4.2. Exclusão comandada pelo PSP .......................................................... 80
2.6.5. Fluxo de portabilidade .............................................................................. 83
2.6.6. Fluxo de reivindicação de posse ................................................................ 93
2.6.7. Fluxo de consulta de chave ..................................................................... 104
2.6.8. Processo de pesquisa de chaves ............................................................. 109
2.6.8.1. Pesquisa de chaves pelos PSPs para conciliação de dados ............. 109
2.6.8.2. Pesquisa de chaves pelos usuários finais ........................................ 112
2.6.9. Disponibilidade das funcionalidades ....................................................... 112
2.6.10. Interface de comunicação ....................................................................... 112
2.6.11. Mecanismos de prevenção a ataques de leitura .................................... 113
2.7. Autenticação digital dos usuários ................................................................... 114
2.8. Idempotência .................................................................................................. 115
3. SISTEMA DE PAGAMENTOS INSTANTÂNEOS .......................................................... 117
3.1. Arquitetura básica do SPI ................................................................................ 118
3.2. Participação no SPI .......................................................................................... 118
3.2.1. Participação direta no SPI ....................................................................... 119
3.2.2. Participação indireta no SPI .................................................................... 120
3.3. Mecanismos de liquidez providos pelo BC ...................................................... 120
3
3.3.1. Aportes e retiradas em Conta PI durante a grade regular de operações
dos participantes no STR ......................................................................................... 121
3.3.1.1. Aporte em Conta PI a partir de RB ou CL ........................................ 121
3.3.1.2. Aporte em Conta PI a partir de CCME ............................................. 124
3.3.1.3. Saque em Conta PI para crédito em RB ou CL ................................. 125
3.3.1.4. Saque em Conta PI para crédito em CCME ..................................... 127
3.3.2. Aportes na Conta PI após a grade regular de operações dos participantes
no STR 128
3.3.2.1. Janela adicional para aporte em Conta PI a partir de RB, CL e CCME
129
3.3.2.2. Aporte em Conta PI mediante operação com TPF no Selic para
Instituições Financeiras ....................................................................................... 132
3.4. Gestão da Conta PI .......................................................................................... 137
3.4.1. Consulta saldo da Conta PI ...................................................................... 138
3.4.2. Consulta relação de lançamentos ........................................................... 139
3.4.3. Consulta detalhes de um lançamento..................................................... 140
3.4.4. Atualização de responsáveis pela gestão da Conta PI............................. 142
3.4.5. Avisos sobre a operação do SPI ............................................................... 142
3.4.6. Resolução de pagamento não respondido.............................................. 144
3.4.6.1. Reenvio do estímulo pelo PSP do pagador ..................................... 144
3.4.6.2. Reenvio de estímulo pelo PSP do recebedor .................................. 146
3.4.6.3. Reenvio do estímulo pelo SPI .......................................................... 148
3.4.7. Registro de participante indireto para o qual o participante direto presta
serviço de liquidação no SPI .................................................................................... 148
3.4.7.1. Descontinuidade da prestação de serviço de liquidação no SPI ..... 150
3.4.8. Aviso de inclusão, de alteração ou de exclusão de Participante direto ou
indireto do SPI ......................................................................................................... 152
3.5. Contabilização da Conta PI .............................................................................. 154
3.6. Tarifas .............................................................................................................. 155
Glossário .......................................................................................................................... 156
Histórico de revisão......................................................................................................... 159
4
Apresentação
O objetivo deste documento é apresentar e detalhar as especificações técnicas e de
negócio do ecossistema de pagamentos instantâneos brasileiro. Ele está sendo
construído pelo Banco Central do Brasil (BC) com base em estudos internos que estão
sendo desenvolvidos e na interação com os agentes do mercado no âmbito do Fórum
Pagamentos Instantâneos. O ecossistema de pagamentos instantâneos brasileiro é o
ambiente formado pelo arranjo aberto que será instituído pelo BC, denominado PIX,
pelos prestadores de serviços de pagamento participantes do arranjo e pelo sistema
utilizado na liquidação das transações realizadas entre diferentes instituições
participantes do arranjo. Esse sistema, denominado Sistema de Pagamentos
Instantâneos (SPI), será construído, gerido e operado pelo BC.
Este documento é um trabalho em construção, sob constante atualização, e que serve

para organizar e para consolidar os direcionamentos que forem sendo tomados no
âmbito do Fórum. Ele está estruturado em três grandes seções. A primeira seção
aborda as especificações das operações de transferências. Nela podem ser
encontradas as características gerais e específicas e os fluxos dos tipos de
transferência que irão cursar no PIX, incluindo as diferentes formas de inserção dos
dados para iniciação dos pagamentos, inclusive questões relativas ao padrão de QR
Code do PIX. Os possíveis cenários de insucesso no processo de liquidação também
estão presentes nessa seção.
A segunda seção trata das especificações técnicas do PIX. Nessa seção são abordadas
questões relacionadas (i) aos critérios de participação no PIX; (ii) ao padrão de
comunicação; (iii) à conectividade entre os participantes, incluindo a infraestrutura de
liquidação; (iv) aos princípios e aos requisitos de segurança no ecossistema; (v) ao
diretório de endereçamento para facilitar a iniciação dos pagamentos, incluindo as
possíveis chaves para endereçamento; e (vi) à forma de autenticação digital dos
usuários.
O diretório de endereçamento é o componente do PIX que armazenará as

informações das chaves ou apelidos que servem para identificar as contas
transacionais dos usuários recebedores de maneira intuitiva e simplificada,
permitindo que o usuário pagador utilize informações que ele já possui sobre o
usuário recebedor para iniciar o pagamento. Esse diretório será centralizado, único e
estará disponível 24 horas por dia, sete dias por semana e em todos os dias do ano.
Esse diretório, denominado Diretório de Identificadores de Contas Transacionais
(DICT), será construído, gerido e operado pelo BC.
A terceira seção apresenta os tópicos diretamente relacionados à infraestrutura

centralizada e única de liquidação das transferências de pagamento instantâneo. Essa
infraestrutura de liquidação constitui o conjunto de regras e de estrutura
computacional para o processamento e a liquidação das transações de pagamentos
instantâneos entre as instituições participantes do PIX. Ela será operada pelo BC e
estará disponível 24 horas por dia, sete dias por semana e em todos os dias do ano,
5
operando em um modelo de liquidação bruta em tempo real. Ou seja, as operações
serão liquidadas transação a transação. Essa seção apresenta (i) a arquitetura básica
do SPI; (ii) os critérios de participação no SPI, incluindo os critérios para titularidade da
conta Pagamentos Instantâneos (Conta PI); (iii) os mecanismos de liquidez disponíveis;
(iv) questões relativas à gestão da Conta PI; (v) a forma de contabilização da Conta PI,
tanto para o BC quanto para os participantes do SPI; e (vi) os princípios tarifários do
SPI.
Serão inseridos neste documento os tópicos cujo direcionamento já está definido no

âmbito do Fórum Pagamentos Instantâneos. Contudo, como o documento está em
constante evolução, ajustes podem ser eventualmente realizados. Toda e qualquer
alteração realizada estará documentada no controle de versões, que está detalhado
ao final do documento. O quadro a seguir sintetiza os pontos que já estão definidos,
aqueles em que a discussão com os participantes do Fórum ainda está em andamento
e aqueles cuja discussão ainda não iniciou:
Tópico Status da discussão

Fluxo de transações entre participantes diretos Finalizada
Fluxo de transações entre participantes indiretos Finalizada
Fluxo de transações nos livros do PSP Finalizada
Inserção manual dos dados pelo pagador Finalizada
QR Code estático Finalizada
QR Code dinâmico Finalizada
QR Code gerado pelo pagador Finalizada
Padrão de QR Code Finalizada
Cenários de insucesso na liquidação Finalizada
Fluxo de devolução Finalizada
Participação no PIX Finalizada
Padrão de comunicação Finalizada
Conectividade Finalizada
Princípios e requisitos de segurança Finalizada
Diretório de dados para endereçamento Finalizada
Chaves para endereçamento Finalizada
Autenticação digital dos usuários Finalizada
Participação no SPI Finalizada
Gestão da Conta PI Finalizada
Contabilização da Conta PI Finalizada
Tarifação no SPI Finalizada
Liquidação não prioritária Finalizada
Informações contidas no QR Code Finalizada
Interface de comunicação com o SPI Finalizada
Criptografia e assinatura de mensagens Finalizada
Certificados Finalizada
Mecanismos de liquidez para o SPI Finalizada
Catálogo de mensagens ISO 20022 Em andamento
6
Especificações do diretório de endereçamento Em andamento
Especificações de iniciação de pagamentos Em andamento
Interfaces de comunicação Em andamento
Experiência do cliente Em andamento
Especificações de segurança Em andamento
Tarifação no âmbito do PIX Não iniciada
Fazem parte deste documento os seguintes anexos, que, por ora, estão sendo
divulgados de forma independente:
• Anexo I – Manual de Iniciação de Pagamentos

• Anexo II – Catálogo de Mensagens do SPI
• Anexo III – Manual das Interfaces de Comunicação
• Anexo IV – Manual de Segurança
• Anexo V – API do Diretório de Identificadores de Contas Transacionais
• Anexo VI – Requisitos Mínimos de Experiência do Usuário
Sugestões, críticas ou pedidos de esclarecimento de dúvidas devem ser enviados ao

BC por meio do e-mail [email protected].
7
1. ESPECIFICAÇÃO DAS TRANSAÇÕES DE
TRANSFERÊNCIA DO PIX
8
O objetivo desta seção é especificar as transações de transferência do PIX. As regras
gerais de funcionamento de cada um dos tipos de transferência especificados, bem
como seus fluxos de ponta a ponta, serão determinadas pelo BC. Os produtos para os
usuários finais, tanto pagadores quanto recebedores, deverão ser desenhados e
implantados pelos agentes de mercado de forma que os seus componentes
operacionais estejam em conformidade com as especificações aqui definidas.
No PIX, no processo de efetivação do pagamento, o usuário pagador poderá definir se

a liquidação das transferências será prioritária ou não prioritária. No caso das
transferências prioritárias, assume-se que a expectativa do usuário pagador é de que
o pagamento e a sua confirmação ocorram no menor tempo possível. No caso das
transferências não prioritárias, assume-se que o usuário pagador não considera a
velocidade do pagamento como fator determinante, mas sim outras características
oferecidas pelo PIX, como a conveniência e o fluxo de informações adicionais ao
pagamento. Nesse caso, seria possível iniciar um pagamento em um determinado dia
para que sua liquidação seja efetivada em alguma data futura. Cabe destacar que,
num primeiro momento, cursarão apenas transferências de crédito no PIX.
Para a inserção dos dados para iniciação do pagamento, haverá quatro opções:
inserção manual dos dados pelo pagador; envio prévio sistematizado de informações
pelo recebedor, por meio de QR Code estático; envio prévio sistematizado de
informações pelo recebedor, por meio de QR Code dinâmico; ou envio prévio
sistematizado de informações pelo pagador, também por meio de QR Code dinâmico.
O diagrama abaixo apresenta os tipos de liquidação e as opções para iniciação do

pagamento no PIX:
9
As características gerais e exemplos de transação para cada uma dessas opções estão
descritas nas seções 1.1 e 1.2 deste documento. É importante salientar que essa
organização das transferências resulta do entendimento de que as necessidades
específicas dos usuários pagadores e dos usuários recebedores não são relevantes
para os fluxos de iniciação e de efetivação do pagamento. Ou seja, os fluxos das
transferências são os mesmos independente de quem é o iniciador e de quem é o
beneficiário final do pagamento, sejam eles pessoas físicas, pessoas jurídicas ou entes
governamentais.
Esta seção apresenta (i) os fluxos do processo de efetivação do pagamento, incluindo

os fluxos da liquidação prioritária e da liquidação não prioritária, tanto para
participantes diretos quanto para participantes indiretos; e (ii) os fluxos do processo
de inserção dos dados para iniciação do pagamento. Esses fluxos contemplam o
processo de inserção manual dos dados pelo pagador e de envio prévio sistematizado
de informações, que incluem os fluxos dos três tipos de QR Code que existirão no PIX:
o QR Code estático, o QR Code dinâmico e o QR Code gerado pelo pagador, que pode
ser gerado inclusive sem acesso à rede de dados, o que amplia a acessibilidade do
arranjo. O padrão do QR Code, bem como as informações que estarão contidas neles,
também estão detalhados no final desta seção.
Além dos fluxos do processo de efetivação do pagamento e do processo de inserção

dos dados para iniciação do pagamento, esta seção também apresenta os possíveis
cenários de insucesso na liquidação do PIX e o fluxo de devolução do PIX.
1.1. Processo de efetivação do PIX

No âmbito do processo de efetivação do PIX, o momento em que a ordem de
pagamento é efetivamente enviada para o SPI é determinante para a aferição do
tempo máximo de processamento e para a caracterização do timeout da transação.
10
No caso de transferências enviadas para liquidação prioritária, a expectativa do
usuário pagador é de que o pagamento e a sua confirmação ocorram no menor tempo
possível. Para que essa expectativa seja cumprida e os usuários tenham a melhor
experiência possível, é necessário estabelecer limites de tempo para alguns dos
processos da transação, como também definir o momento no qual a transação é
considerada final e irrevogável.
A alternativa da liquidação não prioritária tem como objetivos: (i) diminuir o número
de transações processadas simultaneamente pelo SPI, o que minimiza a probabilidade
de timeouts nas transações em virtude de sobrecarga; e (ii) melhorar a experiência do
usuário pagador, que teria a opção de agendar seus pagamentos para liquidação em
um momento futuro. É importante salientar que a indicação de não prioridade da
transação, pelo usuário pagador ao seu prestador de serviços de pagamento (PSP),
será feita no momento da iniciação do pagamento. Cabe ao PSP do pagador enviar a
ordem de pagamento para o SPI apenas no dia indicado pelo pagador. Destaca-se que
a ordem de pagamento sujeita à liquidação não prioritária é apenas aquela agendada
pelo usuário pagador, não cabendo tratamento não prioritário de ordens não
agendadas ou agendamento de ordens por iniciativa do próprio PSP.
O usuário pagador, ao indicar que uma determinada transação pode ser liquidada em
momento futuro, demonstra que o tempo para processamento e para disponibilidade
dos recursos para o recebedor não são fatores essenciais. Nesse caso, o usuário
pagador está mais interessado na sua experiência de iniciação de pagamento e no
conjunto de informações que podem ser enviadas junto com a ordem de pagamento
do que na velocidade e na disponibilidade do sistema.
Do ponto de vista do SPI, a única diferença entre as ordens de pagamento para

liquidação prioritária e não prioritária é a característica do timeout da transação. No
caso das ordens para liquidação prioritária, a transação será rejeitada caso ela
extrapole o limite de tempo, a ser oportunamente estabelecido, entre a etapa em que
o SPI recebe a mensagem de pagamento do PSP do pagador e a etapa em que o SPI
efetiva a troca dos saldos nas contas PI dos PSPs do pagador e do recebedor1.
No caso das ordens para liquidação não prioritária, a transação será rejeitada caso ela
não seja liquidada até às 10 horas. O BC irá requerer que as ordens para liquidação
não prioritária sejam enviadas pelos PSPs para o SPI entre 0h e 8h do dia para o qual
as ordens de pagamento foram agendadas pelos usuários pagadores. Os PSPs dos
recebedores, por sua vez, terão até às 9h30 para validar a conta do usuário recebedor,
fazer a anotação de crédito e enviar a notificação ao SPI. Caberá ao SPI liquidar e enviar
as confirmações das ordens de pagamento aos PSPs até às 10 horas. Caso alguma
ordem não seja liquidada até essa hora, ela será rejeitada. O SPI também rejeitará
automaticamente as ordens de pagamento enviadas pelos PSPs dos pagadores e as
notificações enviadas pelos PSPs dos recebedores após os horários limites respectivos
1
Ver mais detalhes nos fluxos das seções 1.1.1 e 1.1.2.
11
estabelecidos acima. O estabelecimento desses limites tem como objetivo permitir a
organização das ordens de pagamento para liquidação não prioritária de forma a
incentivar os PSPs a enviarem suas ordens o mais cedo possível. Quanto mais cedo e
fora do horário de funcionamento do Sistema de Transferência de Reservas (STR) as
ordens para liquidação não prioritária forem enviadas, mais tempo o SPI terá para
processá-las, minimizando a quantidade de ordens processadas simultaneamente e a
probabilidade de timeouts.
Além desses limites que devem ser respeitados pelos PSPs e pelo SPI, também existem
restrições para os usuários pagadores. O agendamento pelo usuário pagador e o
cancelamento do agendamento junto a seu PSP poderão ser efetuados até às 23h30
do dia anterior. Essa restrição dá tempo suficiente para que os PSPs possam
operacionalizar de forma adequada eventuais cancelamentos de agendamento. Os
horários limites existentes para o agendamento de ordens de pagamento pelos
usuários pagadores e para o tratamento dessas ordens pelos PSPs e pelo SPI estão
sintetizados na figura abaixo.
D-n até D-1 D0
23h30 0h 8h 9h30 10h
Usuário pagador PSP do pagador

Agendamento e Envio das ordens
cancelamento de
agendamento PSP do recebedor
Envio das notificações
SPI
Liquidação das transações
A seguir, são apresentados e detalhados os fluxos das transferências enviadas para

liquidação prioritária e não prioritária nos casos em que existem apenas participantes
diretos do SPI envolvidos e nos casos em que participantes indiretos também estão
presentes.
1.1.1. Fluxo de transações entre participantes diretos

Nesta seção é apresentado o fluxo das transferências enviadas para liquidação
prioritária ou não prioritária, no caso em que tanto o PSP do pagador quanto do
recebedor são participantes diretos do SPI. A tabela após o fluxo detalha cada etapa
do processo.
12
# Camada Tipo Descrição
1 PSP do pagador Comunicação Início do processo. PSP do pagador recebe ordem de pagamento.
Caso se trate de ordem de pagamento para liquidação não
prioritária, o PSP do pagador deve armazenar a ordem até a data
2 PSP do pagador Ação
agendada pelo usuário pagador. Nessa data, o PSP deverá
encaminhar a ordem para liquidação no SPI.
PSP do pagador realiza bloqueio do valor do pagamento na conta
do usuário pagador.
PSP do pagador envia mensagem ao SPI solicitando troca de saldo
4 PSP do pagador Mensagem
na Conta PI para prosseguimento do pagamento.
SPI recebe mensagem enviada pelo PSP do pagador solicitando
5 SPI Mensagem
troca de saldo na Conta PI para prosseguimento do pagamento.
SPI efetua o bloqueio na Conta PI do PSP do pagador no
6 SPI Ação
montante do pagamento em questão.
13
SPI envia mensagem ao PSP do recebedor informando os dados
7 SPI Mensagem
da transferência.
PSP do recebedor recebe mensagem com os dados da
8 PSP do recebedor Mensagem
transferência.
PSP do recebedor valida a conta do usuário recebedor. Caso o
9 PSP do recebedor Ação retorno da validação seja positivo, PSP do recebedor faz anotação
provisória de crédito nessa conta.
PSP do recebedor envia mensagem ao SPI, solicitando o
prosseguimento do pagamento.
SPI recebe mensagem enviada pelo PSP do recebedor, solicitando
11 SPI Mensagem
o prosseguimento do pagamento.
SPI efetiva a troca de saldos nas contas PI: diminui o saldo da
Conta PI do PSP do pagador no valor do pagamento em questão e
12 SPI Ação aumenta o saldo da Conta PI do PSP do recebedor no mesmo
montante. Nesse momento, considera-se que a transação é final e
irrevogável.
SPI envia confirmação de conclusão da transação ao PSP do
13 SPI Mensagem
recebedor e ao PSP do pagador.
PSP do recebedor recebe mensagem de confirmação de
conclusão da transação.
15 PSP do recebedor Ação PSP do recebedor efetiva o crédito na conta do usuário recebedor
PSP do recebedor envia comunicação de confirmação de
16 PSP do recebedor Comunicação
conclusão da transação ao usuário recebedor.
Usuário recebedor recebe a comunicação informando a
17 Usuário recebedor Comunicação
conclusão da transação.
PSP do pagador recebe mensagem de confirmação de conclusão
da transação.
PSP do pagador efetiva o débito na conta do usuário pagador no
valor do pagamento.
PSP do pagador envia comunicação de confirmação de conclusão
20 PSP do pagador Comunicação
da transação ao usuário pagador.
Usuário pagador recebe a comunicação informando a conclusão
21 Usuário pagador Comunicação
da transação.
Existem dois pontos que devem ser destacados no fluxo. O primeiro é o momento em
que a transação é considerada final e irrevogável. Esse momento se dá na etapa 12,
após o SPI efetivar a troca dos saldos nas contas PI dos PSPs do pagador e do
recebedor. Isso implica que, mesmo que ocorra algum tipo de erro nas etapas
subsequentes, está assegurado que a transação foi, de fato, efetivada e que o PSP do
pagador deve debitar os recursos da conta do pagador e o PSP do recebedor deve
creditar os recursos na conta do recebedor. A irrevogabilidade da transação implica
que uma determinada ordem de pagamento não está sujeita a cancelamento.
Portanto, qualquer problema existente entre os PSPs envolvidos em uma
14
determinada transação deve ser resolvido por meio de acordos bilaterais entre as
partes.
O segundo ponto se refere aos conjuntos de etapas que estarão sujeitos a acordos de
nível de serviço. Esses acordos se referem exclusivamente às ordens enviadas para
liquidação prioritária. O primeiro conjunto vai da etapa 1 à etapa 4. O SPI, ao receber
a mensagem de pagamento do PSP do pagador, consultará o intervalo de tempo
passado entre o momento em que o PSP do pagador recebeu a ordem de pagamento
até o momento em que o PSP do pagador envia a mensagem de pagamento ao SPI.
O segundo conjunto vai da etapa 5 à etapa 7 e se refere ao tempo esperado de
resposta do SPI para fazer o bloqueio na Conta PI e enviar mensagem ao PSP do
recebedor informando os dados da transferência. O terceiro conjunto vai da etapa 7
à etapa 11. Espera-se um determinado nível de serviço por parte do PSP do recebedor
para que ele valide a conta do recebedor, efetue a anotação de crédito e envie a
notificação para o SPI. Esse processo é contabilizado até o momento em que o SPI
recebe a mensagem de notificação do PSP do recebedor. Por fim, o quarto e último
conjunto se refere ao tempo decorrido entre as etapas 11 e 12. Mais uma vez, espera-
se que o SPI tenha um determinado limite de tempo a partir do recebimento da
notificação do PSP do recebedor para efetuar o ajuste nas contas PI dos PSPs
envolvidos.
Note-se que, para as ordens de pagamento enviadas para liquidação prioritária, a

única possibilidade de timeout é a extrapolação do limite de tempo estabelecido entre
as etapas 5 e 12. Isso implica que é possível que uma eventual lentidão em uma etapa
específica do fluxo seja compensada por uma rapidez em outra(s) etapa(s). Esse
mecanismo minimiza a existência de timeouts no PIX, o que melhora a experiência dos
usuários finais.
Além das etapas cujos acordos de nível de serviço foram detalhados acima e que têm
relação direta com o limite de tempo que pode gerar timeout pelo SPI, também
existirão acordos de nível de serviço, exclusivos para as ordens enviadas para
liquidação prioritária, entre as etapas 1 e 4; 8 e 10; 14 e 16; e 18 e 20. Apesar de esses
conjuntos de tempo não serem controlados pelo SPI e, portanto, não afetarem a
existência de timeout, eles serão estabelecidos para garantir uma boa experiência para
os usuários finais, tanto pagadores quanto recebedores.
1.1.2. Fluxo de transações entre participantes indiretos

prioritária ou não prioritária, no caso em que tanto o PSP do pagador quanto do
recebedor são participantes indiretos do SPI. A tabela após o fluxo detalha cada etapa
do processo.
15
prioritária, o PSP do pagador deve armazenar a ordem até a data
agendada pelo usuário pagador. Nessa data, o PSP deverá
encaminhar a ordem para liquidação no SPI.
16
PSP do pagador realiza bloqueio do valor do pagamento na conta do
usuário pagador.
PSP do pagador envia comunicação ao participante direto pagador,
4 PSP do pagador Comunicação solicitando troca de saldo na Conta PI para prosseguimento do
pagamento.
Participante Participante direto pagador recebe comunicação solicitando troca de
5 Comunicação
direto pagador saldo na Conta PI para prosseguimento do pagamento.
Participante Participante direto pagador envia mensagem ao SPI solicitando troca
6 Mensagem
direto pagador de saldo na Conta PI para prosseguimento do pagamento.
SPI recebe mensagem enviada pelo participante direto pagador
7 SPI Mensagem solicitando troca de saldo na Conta PI para prosseguimento do
pagamento.
SPI efetua o bloqueio na Conta PI do participante direto pagador no
8 SPI Ação
montante do pagamento em questão.
SPI envia mensagem ao participante direto recebedor informando os
9 SPI Mensagem
dados da transferência.
Participante Participante direto recebedor recebe mensagem com os dados da
10 Mensagem
direto recebedor transferência.
Participante Participante direto recebedor envia comunicação ao PSP do
11 Comunicação
direto recebedor recebedor com os dados da transferência.
PSP do recebedor recebe comunicação com os dados da
transferência.
PSP do recebedor valida a conta do usuário recebedor. Caso o
13 PSP do recebedor Ação retorno da validação seja positivo, PSP do recebedor faz anotação
provisória de crédito nessa conta.
PSP do recebedor envia comunicação ao participante direto
recebedor, solicitando o prosseguimento do pagamento.
Participante Participante direto recebedor recebe comunicação enviada pelo PSP
15 Comunicação
direto recebedor do recebedor, solicitando o prosseguimento do pagamento.
Participante Participante direto recebedor envia mensagem ao SPI, solicitando o
16 Mensagem
direto recebedor prosseguimento do pagamento.
SPI recebe mensagem enviada pelo participante direto recebedor,
17 SPI Mensagem
solicitando o prosseguimento do pagamento.
SPI efetiva a troca de saldos nas contas PI: diminui o saldo da Conta
PI do participante direto pagador no valor do pagamento em
18 SPI Ação questão e aumenta o saldo da Conta PI do participante direto
recebedor no mesmo montante. Nesse momento, considera-se que
a transação é final e irrevogável.
SPI envia confirmação de conclusão da transação ao participante
19 SPI Mensagem
direto recebedor e ao participante direto pagador.
Participante Participante direto recebedor recebe mensagem de confirmação de
20 Mensagem
direto recebedor conclusão da transação enviada pelo SPI.
Participante Participante direto recebedor envia comunicação de confirmação de
21 Comunicação
direto recebedor conclusão da transação ao PSP do recebedor.
17
PSP do recebedor recebe comunicação de confirmação de conclusão
da transação.
23 PSP do recebedor Ação PSP do recebedor efetiva o crédito na conta do usuário recebedor
PSP do recebedor envia comunicação de confirmação de conclusão
da transação ao usuário recebedor.
Usuário Usuário recebedor recebe a comunicação informando a conclusão
25 Comunicação
recebedor da transação.
Participante Participante direto pagador recebe mensagem de confirmação de
26 Mensagem
direto pagador conclusão da transação enviada pelo SPI.
Participante Participante direto pagador envia comunicação de confirmação de
27 Comunicação
direto pagador conclusão da transação ao PSP do pagador.
PSP do pagador recebe comunicação de confirmação de conclusão
da transação.
PSP do pagador efetiva o débito na conta do usuário pagador no
valor do pagamento.
PSP do pagador envia comunicação de confirmação de conclusão da
transação ao usuário pagador.
Usuário pagador recebe a comunicação informando a conclusão da
transação.
Assim como no caso em que a transferência ocorre entre participantes diretos, a

transação também é considerada final e irrevogável no momento em que o SPI faz a
troca de saldos na Conta PI dos participantes diretos que tem relacionamento com os
PSPs do pagador e do recebedor (etapa 18 do fluxo).
Para a aferição do limite de tempo em que a ordem para liquidação prioritária

permanece válida, considera-se o tempo decorrido entre as etapas 7 e 18. Nesse fluxo,
acordos de nível de serviço, exclusivos para ordens de pagamento para liquidação
prioritária, também deverão ser estabelecidos entre as etapas1 e 3; 4 e 5; 9 e 10; 11 e
13; 14 e 15; 19 e 20; 21 e 23; 25 e 26; e 27 e 29.
Ressalte-se que os fluxos de comunicação envolvendo o SPI estão caracterizados

como “Mensagem”, enquanto os fluxos envolvendo participantes diretos e indiretos
estão caracterizados como “Comunicação”. As interações entre os participantes
diretos e o SPI envolverão necessariamente o uso de mensageria no padrão ISO
200222. As interações entre os participantes diretos e indiretos não precisam
necessariamente utilizar esse padrão. A forma de comunicação entre eles poderá ser
livremente estabelecida por meio de relação contratual bilateral3.
2
Ver seção 2.2 deste documento.
3
Ver seção 3.2 deste documento, sobre formas de participação no SPI.
18
1.1.3. Fluxo de transações nos livros do PSP
prioritária ou não prioritária, no caso em que o PSP do pagador e o PSP do recebedor
são a mesma instituição, independentemente de o PSP ser participante direto ou
indireto. A tabela após o fluxo detalha cada etapa do processo.

1 PSP Comunicação Início do processo. PSP recebe ordem de pagamento.
2 PSP Ação prioritária, o PSP deve armazenar a ordem até a data agendada pelo
usuário pagador. Nessa data, o PSP deverá executar a ordem.
PSP verifica se há saldo na conta do usuário pagador e valida a conta
3 PSP Ação
do usuário recebedor.
Caso as verificações de saldo e conta sejam positivas, PSP debita a
4 PSP Ação conta do usuário pagador e credita a conta do usuário recebedor,
efetivando a transação em seus livros.
19
PSP envia comunicação de confirmação de conclusão da transação
5 PSP Comunicação
ao usuário recebedor e ao usuário pagador.
Usuário Usuário recebedor recebe a comunicação informando a conclusão da
6 Comunicação
recebedor transação.
Usuário pagador recebe a comunicação informando a conclusão da
transação.
Note-se que, no caso em que os usuários pagador e recebedor são clientes do mesmo
PSP, a ordem de pagamento não é enviada para o SPI. Nesse caso, a liquidação ocorre
nos livros do próprio PSP. Apesar de a transação não passar pelo SPI, as regras do PIX
terão que ser cumpridas pelo PSP, como a obrigatoriedade de envio de notificação
para ambos os usuários e o cumprimento do limite máximo de tempo para
disponibilização dos recursos na conta do usuário recebedor, por exemplo. Nessas
transferências efetuadas nos livros do PSP, a transação é considerada final e
irrevogável após a etapa 4, em que o PSP debita a conta do usuário pagador e credita
a conta do usuário recebedor.
1.2. Processo de inserção dos dados para iniciação do PIX

A forma pela qual os dados de identificação dos usuários recebedor e pagador são
inseridos em uma ordem de pagamento é determinante para estabelecer o fluxo
prévio ao processo de efetivação do pagamento detalhado na seção anterior. No PIX,
existirão dois processos de inserção dos dados para iniciação do pagamento: a
inserção manual dos dados pelo pagador e o envio prévio sistematizado de
informações.
No caso da inserção manual dos dados, o pagador poderá enviar ao seu PSP alguma
chave específica que possibilite a identificação das informações completas do usuário
recebedor. Alternativamente, o pagador poderá inserir manualmente os dados
completos do usuário recebedor, similarmente ao processo executado atualmente
para a Transferência Eletrônica Disponível (TED).
No processo estruturado prévio, informações sobre o pagamento serão enviadas com

o objetivo de otimizar o processo e de agregar valor aos usuários finais pagadores e
recebedores. No PIX, as informações sobre o pagamento serão enviadas por meio de
QR Code4. Como o conjunto de informações que cursará junto com a ordem de
pagamento pode variar, definiu-se duas formas diferentes de geração do QR Code pelo
recebedor, que foram classificadas como QR Code estático e QR Code dinâmico. Cada
recebedor terá a liberdade de gerar o QR Code da forma que melhor lhe convir. Além
da geração do QR Code pelo recebedor, o pagador também poderá gerar seu QR Code
4
Existe a possibilidade de o PIX aceitar futuramente outras formas de envio prévio sistematizado
de informações, além do QR Code. A tecnologia Near Field Communication (NFC) é um exemplo de
tecnologia que pode ser futuramente adotada.
20
com seus dados transacionais. A geração desse QR Code poderá ser realizada mesmo
sem acesso à rede de dados.
A decisão sobre a prioridade da liquidação deve ser tomada pelo usuário pagador no
processo de inserção dos dados para iniciação do pagamento.
1.2.1. Inserção manual dos dados pelo pagador

Existirão duas alternativas nos casos em que o pagador opte ou tenha que inserir
manualmente as informações do beneficiário do pagamento. A primeira alternativa
será o envio de alguma chave específica pelo pagador para seu PSP5. Nesse caso, o
PSP deve ter acesso a um diretório de dados de endereçamento que permita que essa
chave enviada pelo pagador identifique informações relevantes do usuário recebedor
necessárias para viabilizar a transação.
A segunda alternativa será a inserção manual pelo pagador dos dados completos do
recebedor, similarmente ao modelo atualmente utilizado para a TED. Nesse caso,
como as informações do recebedor já estão disponíveis, não há necessidade de o PSP
consultar qualquer diretório de dados de endereçamento para conseguir enviar a
transação para o destinatário correto. Apesar de essa solução não facilitar a
experiência do usuário na iniciação do pagamento, prever essa possibilidade faz com
que seja possível o envio de pagamentos instantâneos para usuários que
eventualmente não estejam registrados no diretório de dados de endereçamento ou
no caso de indisponibilidade momentânea para consultas no diretório de dados de
endereçamento.
Existem dois fluxos diferentes, a depender da forma de acesso ao DICT. Apresenta-se

primeiramente o fluxo para os casos em que o PSP do usuário pagador possui acesso
direto ao diretório de endereçamento e, depois, o fluxo para os casos em que o PSP
do usuário pagador não possui acesso direto ao diretório.
5
As possíveis formas de identificação dos usuários estão documentadas na seção 2.6.1.
21
Início do processo. Usuário pagador acessa canal de pagamento
1 Usuário pagador Ação (tipicamente, um smartphone) para realização de transação de
pagamento.
Usuário pagador insere os dados necessários à realização do
2 Usuário pagador Ação
pagamento.
Usuário pagador escolhe entre as opções “Pagar” ou “Agendar”. A
opção “Pagar” gera uma ordem de pagamento para liquidação
prioritária. A opção “Agendar” gera uma ordem de pagamento
para liquidação não prioritária. Caso o usuário pagador escolha a
opção “Agendar”, ele deverá escolher a data para efetivação do
pagamento.
Dados inseridos pelo usuário pagador são encaminhados ao seu
PSP.
O PSP recebe os dados do pagamento inseridos pelo usuário
pagador.
22
Caso o usuário pagador tenha inserido os dados completos do
recebedor, o PSP do usuário pagador não precisa consultar o
DICT para validar os dados do recebedor. Nesse caso, a próxima
etapa do fluxo é a etapa 11.
Caso o usuário pagador tenha inserido apenas uma chave, o PSP
7 PSP do pagador Comunicação do usuário pagador encaminha mensagem ao DICT para
consulta das informações de identificação do usuário recebedor.
8 DICT Comunicação DICT recebe consulta de dados sobre usuário recebedor.
DICT consulta a chave recebida, faz a validação e retorna os
9 DICT Ação
dados de identificação encontrados.
DICT envia comunicação ao PSP do pagador com os dados de
10 DICT Comunicação
identificação do usuário recebedor.
PSP do pagador recebe comunicação do DICT com os dados de
PSP do pagador envia comunicação ao usuário pagador com os
dados do usuário recebedor, solicitando confirmação.
Usuário pagador recebe comunicação com dados sobre o
usuário recebedor, solicitando confirmação para o início do
processo de efetivação do pagamento. Caso o usuário pagador
confirme a transação, é gerada uma ordem de pagamento.
Apresenta-se, a seguir, o fluxo da inserção manual dos dados, no caso de o PSP do

pagador não possuir acesso direto ao diretório de endereçamento.
23
Início do processo. Usuário pagador acessa canal de pagamento
1 Usuário pagador Ação (tipicamente, um smartphone) para realização de transação de
pagamento.
Usuário pagador insere os dados necessários à realização do
pagamento.
24
Usuário pagador escolhe entre as opções “Pagar” ou “Agendar”. A
opção “Pagar” gera uma ordem de pagamento para liquidação
prioritária. A opção “Agendar” gera uma ordem de pagamento
para liquidação não prioritária. Caso o usuário pagador escolha a
opção “Agendar”, ele deverá escolher a data para efetivação do
pagamento.
Dados inseridos pelo usuário pagador são encaminhados ao seu
PSP.
PSP do pagador sem O PSP recebe os dados do pagamento inseridos pelo usuário
5 Comunicação
acesso direto ao DICT pagador.
Caso o usuário pagador tenha inserido os dados completos do
PSP do pagador sem recebedor, o PSP do usuário pagador não precisa consultar o
6 Ação
acesso direto ao DICT DICT para validar os dados do recebedor. Nesse caso, a próxima
etapa do fluxo é a etapa 15.
Caso o usuário pagador tenha inserido apenas uma chave, o PSP
PSP do pagador sem do usuário pagador se comunica com o participante com acesso
7 Comunicação
acesso direto ao DICT direto ao DICT para consulta das informações de identificação do
usuário recebedor.
Participante com O participante com acesso direto ao DICT recebe os dados do
8 Comunicação
Acesso direto ao DICT pagamento encaminhados pelo PSP do pagador.
Participante com O participante com acesso direto se comunica com o DICT para
9 Comunicação
Acesso direto ao DICT consulta das informações de identificação do usuário recebedor.
DICT consulta a chave recebida, faz a validação e retorna os
11 DICT Ação
DICT se comunica com o participante com acesso direto ao
12 DICT Comunicação diretório de endereçamento, informando os dados de
Participante com acesso direto ao DICT recebe comunicação do
Participante com
13 Comunicação diretório de endereçamento com os dados de identificação do
Acesso direto ao DICT
usuário recebedor.
Participante com Participante com acesso direto ao DICT se comunica com o PSP
14 Comunicação
Acesso direto ao DICT do pagador, informando os dados do usuário recebedor.
PSP do pagador recebe comunicação do participante com acesso
15 PSP do pagador Comunicação direto ao DICT com os dados de identificação do usuário
recebedor.
Usuário pagador recebe comunicação com dados sobre o
usuário recebedor, solicitando confirmação para o início do
processo de efetivação do pagamento. Caso o usuário pagador
confirme a transação, é gerada uma ordem de pagamento.
1.2.2. Envio prévio sistematizado de informações
25
O envio prévio sistematizado de informações pode ser feito tanto pelo usuário
recebedor quanto pelo usuário pagador. Caso as informações prévias sejam geradas
pelo usuário recebedor, caberá ao usuário pagador realizar a leitura do QR Code e
iniciar a transação por meio do seu PSP. Nesse caso, o usuário pagador deve
necessariamente ter acesso à rede de dados.
Para o caso em que o pagador esteja sem acesso à rede de dados, é possível que ele
próprio gere, sem troca de informações por redes de comunicação, um QR Code com
suas informações transacionais. Nesse caso, o usuário recebedor deverá ler as
informações contidas no QR Code gerado pelo pagador e prosseguir com o processo
por meio de seu PSP. Nesse caso, o usuário recebedor deve necessariamente ter
acesso à rede de dados6.
O usuário recebedor pode gerar as informações de pagamento de três formas

diferentes, à sua escolha. A primeira por meio da geração de um QR Code estático, a
segunda por meio da geração de um QR Code dinâmico e a terceira por meio da
geração de um link. Essa última situação é prevista principalmente para os casos em
que o pagador está utilizando o seu telefone celular para fazer uma transferência não
presencial para o recebedor. Nesses casos, o pagador é incapaz de ler um QR Code a
partir do próprio dispositivo. O link permite que as informações de pagamento do
recebedor sejam disponibilizadas sem a necessidade de leitura de um QR Code.
1.2.2.1. QR CODE ESTÁTICO

O QR Code estático é permanente e possui informações que não são alteradas. A
informação prévia gerada nesse processo não está necessariamente vinculada a uma
transação específica, ou seja, ela pode ser utilizada em diversas transações distintas.
Por isso, o fluxo está dividido em duas etapas: (i) geração pelo usuário recebedor; e (ii)
utilização pelo usuário pagador, quando ele possui acesso à rede de dados7.
A seguir, o fluxo de geração do QR Code Estático pelo usuário recebedor:
6
Situações em que tanto o pagador quanto o recebedor estejam sem acesso à rede de dados não
estão contempladas no PIX.
7
Caso o usuário pagador não possua acesso à rede de dados, o usuário pagador deve seguir o fluxo
do QR Code gerado pelo pagador descrito na seção 1.2.2.3.
26
Início do processo. Usuário recebedor acessa seu canal de
1 Usuário recebedor Ação
atendimento.
Usuário recebedor solicita, em seu canal de atendimento, a criação
de QR Code Estático.
Solicitação de QR Code Estático pelo usuário recebedor é
encaminhada ao PSP do recebedor.
Comunicação de solicitação de QR Code Estático pelo usuário
recebedor é recebida pelo PSP do recebedor.
5 PSP do recebedor Ação PSP do recebedor cria QR Code Estático.
6 PSP do recebedor Comunicação PSP do recebedor informa o QR Code gerado ao usuário recebedor.
Usuário recebedor recebe QR Code Estático em seu canal de
7 Usuário recebedor Comunicação atendimento e, da forma por ele escolhida, o disponibiliza ao
usuário pagador.
O fluxo de utilização do QR Code Estático pelo usuário pagador com acesso à rede de
dados é o seguinte:
27
Usuário pagador identifica a disponibilização de QR Code para
leitura.
Usuário pagador faz a leitura do QR Code disponibilizado pelo
usuário recebedor.
3 Usuário pagador Comunicação Dados lidos do QR Code são encaminhados ao PSP do pagador.
4 PSP do pagador Comunicação PSP do pagador recebe dados do QR Code.
PSP do pagador encaminha dados do QR Code ao diretório de

endereçamento.
DICT consulta os dados recebidos, faz a validação e retorna os
7 DICT Ação
8 DICT Comunicação
PSP do pagador recebe comunicação do DICT com os dados de
28
Usuário pagador recebe comunicação com dados sobre o usuário
pagador, solicitando confirmação para o início do processo de
efetivação do pagamento. Caso o usuário pagador confirme a
transação, é gerada uma ordem de pagamento.
1.2.2.2. QR CODE DINÂMICO

A diferença entre o QR Code estático e o QR Code dinâmico é que a informação contida
em cada QR Code dinâmico, diferentemente do que ocorre no QR Code estático, pode
ser utilizada apenas uma única vez, para uma transação específica. Ou seja, o QR Code
dinâmico é mutável e gera novas informações a cada transação.
Como a geração da requisição de pagamento é dinâmica, o sistema de conciliação dos

prestadores de bens e serviços consegue parametrizar a requisição de pagamento de
forma a obter um identificador por meio do qual se associa o pedido ao pagamento.
Apresenta-se, a seguir, o fluxo de geração do QR Code dinâmico pelo usuário

recebedor:
29
Início do processo. Usuário recebedor acessa seu canal
de atendimento.
Usuário recebedor solicita, em seu canal de
atendimento, a geração de QR Code dinâmico.
Solicitação de QR Code dinâmico pelo usuário recebedor
é encaminhada ao PSP do recebedor.
Comunicação de solicitação de QR Code dinâmico pelo
usuário recebedor é recebida pelo PSP do recebedor.
PSP do recebedor cria URL/URI e gera o QR Code
dinâmico. O QR Code dinâmico contém apenas a
5 PSP do recebedor Ação
URL/URI que aponta para o serviço web service
hospedado no PSP do recebedor.
PSP do recebedor envia o QR Code para o usuário
recebedor.
Usuário recebedor recebe QR Code dinâmico em seu
7 Usuário recebedor Comunicação canal de atendimento e, da forma por ele escolhida, o
disponibiliza ao usuário pagador.
30
Apresenta-se o fluxo de utilização do QR Code dinâmico pelo usuário pagador com
acesso à rede de dados8:

Usuário pagador identifica a disponibilização de QR Code
para leitura.
Usuário pagador acessa o aplicativo do seu PSP e faz a
leitura do QR Code por meio desse aplicativo.
Caso a opção seja dada pelo usuário recebedor, o usuário
pagador escolhe entre as opções “Pagar” ou “Agendar”. A
opção “Pagar” gera uma ordem de pagamento para
3 Usuário pagador Ação liquidação prioritária. A opção “Agendar” gera uma ordem
de pagamento para liquidação não prioritária. Caso o
usuário pagador escolha a opção “Agendar”, ele deverá
escolher a data para efetivação do pagamento.
Aplicativo do PSP do pagador consulta URL/URI lida no QR
Code e faz as validações de segurança9.
Aplicativo do PSP do pagador recupera payload json
servido na URL/URI e verifica assinatura com base na
8
Caso o usuário pagador não possua acesso à rede de dados, o usuário pagador deve seguir o fluxo
do QR Code gerado pelo pagador descrito na seção 1.2.2.3.
9
A URL/URI está hospedada no domínio do PSP do Recebedor. As validações de segurança incluem
a verificação da validade do certificado apresentado no domínio e a verificação da presença do
domínio na lista dos domínios autorizados a gerarem QR Codes no âmbito do SFN. Caso as
validações sejam positivas, o aplicativo também recupera a chave pública do PSP/domínio em
questão.
31
chave pública obtida. Caso as verificações sejam positivas,
o aplicativo do PSP do pagador solicita confirmação para o
início do processo de efetivação do pagamento. Caso o
usuário pagador confirme a transação, é gerada uma
ordem de pagamento.
1.2.2.3. QR CODE GERADO PELO PAGADOR

O QR Code gerado pelo pagador permite aos usuários pagadores iniciarem
pagamentos mesmo quando não possuam acesso à redes de dados. Nesses casos, o
usuário pagador gera o QR Code com seus dados transacionais, por meio do aplicativo
de seu PSP, sem a necessidade de efetuar troca de informações por meio de redes de
comunicação. Portanto, o usuário pagador é capaz de gerar esse QR Code em seu
smartphone mesmo que não possua qualquer acesso à redes de dados. A fim de
reduzir o risco de fraudes, o processo do QR Code gerado pelo pagador apenas se
inicia após a criação de QR Code estático ou dinâmico pelo usuário recebedor. Dessa
forma, o aplicativo utilizado pelo usuário pagador poderá ler os dados do QR Code do
recebedor e, com base nessa leitura, obter a identificação – chave de endereçamento
ou dados da conta transacional – do usuário recebedor. Ou seja, do ponto de vista do
pagador, a experiência de iniciar um pagamento instantâneo com o uso de QR Codes
sempre se inicia por meio da leitura de um QR Code gerado pelo usuário recebedor.
No caso do QR Code gerado pelo pagador, o seu aplicativo, ao ler o QR Code exibido
pelo recebedor, deve ser capaz de gerar um novo QR Code com as informações tanto
do próprio pagador quanto do recebedor. A partir desse novo QR Code gerado pelo
aplicativo do pagador, o processo é iniciado com a sua leitura pelo recebedor. Esse
processo uniformiza a experiência do usuário pagador nas transações envolvendo QR
Code e adiciona uma camada de segurança ao garantir que o QR Code gerado pelo
pagador será utilizado para um recebedor específico.
Por motivos de segurança, o QR Code gerado pelo aplicativo do PSP terá um tempo de
expiração, a critério de cada PSP. Entende-se que a autorização para efetivação do
pagamento é realizada pelo pagador no momento em que ele gera o QR Code por
meio do seu PSP. Dessa forma, é necessário que o identificador único do QR Code e a
sua assinatura contenham informações suficientes para garantir que o QR Code foi
realmente gerado pelo usuário pagador e que esse QR Code não será aceito em mais
de uma transação. Além desses controles sugeridos de segurança, outros elementos
também poderão ser inseridos, a critério de cada PSP. A leitura do QR Code e o início
da transmissão da ordem de pagamento são realizados pelo usuário recebedor,
conforme o seguinte fluxo:
32
Usuário pagador identifica a disponibilização de QR Code para
leitura.
33
Usuário pagador acessa o aplicativo do seu PSP e faz a leitura,
por meio desse aplicativo, do QR Code gerado pelo recebedor.
Usuário pagador gera, no aplicativo de seu PSP, sem troca de
3 Usuário pagador Ação informações em rede de dados, um novo QR Code, com base em
dados colhidos do QR Code do usuário recebedor.
O QR Code gerado é apresentado pelo usuário pagador ao
usuário recebedor. Essa apresentação implica em autorização
4 Usuário pagador Ação para o recebimento do valor em questão pelo usuário
recebedor, uma vez que não haverá pedido posterior de
confirmação.
Usuário recebedor recebe informação de que há QR Code
disponibilizado pelo usuário pagador. Não há fluxo
5 Usuário recebedor Comunicação sistematizado de informações nessa etapa. Trata-se de mera
sinalização, verbal, visual ou qualquer outra forma, de que há
um QR Code disponível para ser lido.
QR Code disponibilizado pelo usuário pagador é lido pelo
usuário recebedor.
A fim de garantir que o QR Code do pagador foi gerado
corretamente, o aplicativo do usuário recebedor confere se os
campos de identificação do usuário recebedor desse QR Code
7 Usuário recebedor Ação contêm sua chave de endereçamento (caso o QR Code gerado
pelo recebedor seja estático) ou os dados de sua conta
transacional (caso o QR Code gerado pelo recebedor seja
dinâmico).
Informações do QR Code lidas são encaminhadas ao PSP do
recebedor.
PSP do recebedor recebe informações encaminhadas pelo
usuário recebedor.
PSP do recebedor encaminha informações de pagamento ao
SPI. Caso ambos os PSPs envolvidos na transação se conectem
ao SPI por meio do mesmo Provedor de Serviços de Tecnologia
da Informação (PSTI)10, o PSTI em questão poderá encaminhar a
mensagem de pagamento ao PSP do pagador sem a
necessidade de enviá-la ao SPI.
SPI ou PSTI recebe mensagem encaminhada pelo PSP do
11 SPI ou PSTI Mensagem
recebedor.
SPI ou PSTI encaminha informações do pagamento ao PSP do
12 SPI ou PSTI Mensagem
pagador.
10
Ver seção 2.3 deste documento, sobre conectividade.
34
PSP do pagador recebe informações do pagamento
encaminhadas pelo SPI.
PSP faz validações de segurança do QR Code, a fim de
confirmar de que se trata de comando de pagamento
autêntico, encaminhado dentro do prazo e gerado
adequadamente pelo pagador.11 Caso o QR Code gerado pelo
recebedor, o qual iniciou o processo na etapa 1, seja dinâmico
e a transação seja validada, o PSP do pagador gera uma ordem
de pagamento e, nesse caso, o processo do QR Code gerado
pelo pagador se encerra nesta etapa.
Caso o QR Code gerado pelo recebedor, o qual iniciou o
15 PSP do pagador Mensagem processo na etapa 1, seja estático, o PSP do pagador encaminha
consulta ao diretório de endereçamento.
16 DICT Mensagem DICT recebe a consulta.
DICT efetua a consulta e retorna os dados de identificação do

17 DICT Ação
usuário recebedor.
18 DICT Mensagem
PSP do pagador recebe comunicação do diretório de
endereçamento com os dados de identificação do usuário
recebedor. Caso a transação seja validada, o PSP do pagador
gera uma ordem de pagamento.
1.2.2.4. PADRÃO DO QR CODE: LAYOUT DAS INFORMAÇÕES

O PIX utilizará o padrão EMV® para seus QR Codes12. As especificações EMV® para QR
Code têm o potencial de facilitar a interoperabilidade com outros arranjos de
pagamento que utilizam QR Code para a iniciação de um pagamento, tanto
nacionalmente quanto globalmente. A adoção desse padrão, que já é adotado em
diversos países, é o passo inicial para padronizar o uso de QR Codes para iniciação de
11
As validações de segurança podem incluir a requisição de autenticação off-line no momento da
geração do QR Code, como a requisição de senha autenticada no dispositivo do usuário ou o uso
de biometria. Além disso, o risco de fraude pode ser mitigado por meio da definição, a critério de
cada PSP, de limites de valor para esse tipo de iniciação de pagamento. Também podem ser criados
mecanismos que evitem que o usuário recebedor possa, de alguma maneira, alterar os dados
gerados no QR Code.
12
EMV® é uma marca registrada nos EUA e em outros países e uma marca não registrada em outros
lugares. A marca comercial EMV é de propriedade da EMVCo, LLC.
35
pagamentos no mercado de pagamentos de varejo brasileiro. A adoção do padrão
permite a racionalização da aceitação de QR Codes pelos varejistas brasileiros,
evitando que o varejo tenha que ter um QR Code diferente para cada arranjo de
pagamento que seja aceito como meio de pagamento. Além disso, a adoção do padrão
facilita o entendimento da utilização dos QR Codes pelos consumidores.
O fato de as especificações do padrão EMV® já estarem prontas facilita o processo de

adoção desse padrão tanto no PIX como nos demais arranjos de pagamento que
atuam no mercado brasileiro, evitando os custos associados à construção de um novo
padrão13.
No QR Code dinâmico, as informações relativas à transação serão disponibilizadas por

meio de um web service hospedado no PSP do recebedor. O QR Code deverá conter a
URL/URI que aponta para esse serviço14. O conjunto de informações a ser ofertado
será estruturado e padronizado de forma a possibilitar sua apresentação por meio de
aplicativos de pagamento de qualquer PSP autorizado a operar.
A solução por URL/URI apresenta três níveis de segurança:
a. o aplicativo leitor do QR Code só respeitará URLs https que apresentem um

certificado SSL válido;
b. uma lista de domínios autorizados será servida em ambiente a definir. O
aplicativo do PSP respeitará essa lista. Dessa forma, não será possível a um
fraudador criar uma URL que aponte para um domínio arbitrário; e
c. para completar a segurança, o payload json que será retornado ao se acessar
o serviço web apontado pela URL/URI poderá ser assinado pelo PSP que
hospeda o serviço. A lista de domínios autorizados mencionada no item
anterior também conterá uma chave pública associada ao PSP/domínio com a
qual o cliente do serviço pode verificar a assinatura do payload json.
O padrão EMV® para QR Codes é plenamente compatível com a solução por URL/URI.
Os endereços ficarão armazenados nos campos livres existentes no padrão.
13
É importante esclarecer que a adoção do padrão EMV® não se confunde com a utilização da
infraestrutura da indústria de cartões de pagamento. Pagamentos instantâneos iniciados por meio
de QR Codes utilizarão a infraestrutura do ecossistema de pagamentos instantâneos. Pagamentos
com cartão iniciados por meio de QR Codes utilizarão a infraestrutura da indústria de cartões. Ou
seja, cada arranjo cujo pagamento seja iniciado por meio de QR Codes que utilizem o padrão EMV®
irá utilizar suas infraestruturas correspondentes.
14
A URL/URI contida no QR Code dinâmico poderá, a critério do usuário recebedor, ser estável. As
informações contidas no payload json é que devem necessariamente ser diferentes para cada
transação.
36
A quantidade e o formato das informações contidas nos campos que compõem os QR
Codes estão vinculados a cada tipo de QR Code.
O QR Code estático conterá o seguinte conjunto de informações:
QR Code Estático
# Campo Tipo
1 Chave de endereçamento Obrigatório
2 Valor Opcional
3 Conjunto livre de caracteres, com limite de tamanho Opcional
O QR Code dinâmico conterá as seguintes informações:
QR Code Dinâmico
# Campo Tipo
1 Instituição do usuário recebedor Obrigatório
2 Tipo de conta do usuário recebedor Obrigatório
3 Número da agência do recebedor Obrigatório
4 Número da conta do recebedor Obrigatório
5 Link do URL/URI Obrigatório
Identificador único na origem (é o mesmo identificador contido na
Opcional
6 URL/URI)15
7 Valor Opcional
A URL/URI vinculada ao QR Code dinâmico conterá as seguintes informações:
Link URL/URI
# Campo Tipo
1 Instituição do usuário recebedor Obrigatório
2 Tipo de conta do usuário recebedor Obrigatório
3 Número da agência do recebedor Obrigatório
4 Número da conta do recebedor Obrigatório
5 CPF/CNPJ do usuário recebedor Obrigatório
6 Nome do usuário recebedor Obrigatório
7 Valor do documento Obrigatório
8 Identificador único na origem Obrigatório
9 Assinatura Obrigatório
10 Conjunto livre de caracteres, com limite de tamanho Opcional
11 Tempo de expiração do QR Code Opcional
15
Identificador único na origem é o código alfanumérico utilizado pelo usuário recebedor para
rastrear um pagamento e efetuar a conciliação entre o produto vendido ou o serviço prestado e o
respectivo recebimento.
37
12 Data de vencimento do pagamento Opcional
13 Juros/Multa Opcional
14 Desconto/Abatimento Opcional
15 Valor Obrigatório
Por fim, o QR Code gerado pelo usuário pagador conterá as seguintes informações:
QR Code gerado pelo pagador

# Campo Tipo
1 Instituição do usuário pagador Obrigatório
2 Tipo de conta do usuário pagador Obrigatório
3 Número da agência do pagador Obrigatório
4 Número da conta do pagador Obrigatório
5 CPF/CNPJ do usuário pagador Obrigatório
6 Valor Obrigatório
7 Identificador único do QR Code16 Obrigatório
Chave de endereçamento do usuário recebedor (deve ser preenchido apenas
8 se o QR Code do recebedor for estático) Obrigatório*
Instituição do usuário recebedor (deve ser preenchido apenas se o QR Code do
9 recebedor for dinâmico) Obrigatório**
Tipo de conta do usuário recebedor (deve ser preenchido apenas se o QR Code do
Número da agência do recebedor (deve ser preenchido apenas se o QR Code do
Número da conta do recebedor (deve ser preenchido apenas se o QR Code do
13 Assinatura Obrigatório
14 Tempo de expiração do QR Code Obrigatório
*apenas se QR Code do recebedor for estático

**apenas se QR Code do recebedor for dinâmico
A forma de inserção desses campos no padrão EMV® e o detalhamento do seu

preenchimento estão definidos no Anexo I (Manual de Iniciação de Pagamentos) deste
documento17.
1.3. Cenários de insucesso na liquidação do PIX
Nesta seção são apresentados os fluxos de tratamento de cenários de insucesso da

comunicação entre o SPI e os PSPs do pagador e do recebedor, participantes diretos
16
Identificador único do QR Code é o código gerado pelo aplicativo do usuário pagador, cujo
algoritmo de geração é determinado por seu PSP, para impedir que o pagamento de um
determinado QR Code seja efetivado mais do que uma vez.
17
Disponível em https://www.bcb.gov.br/estabilidadefinanceira/forumpagamentosinstantaneos.
38
do SPI, em relação à liquidação prioritária de pagamentos instantâneos detalhada no
fluxo apresentado na seção 1.1.1 (fluxo de transações entre participantes diretos).
Os cenários de insucesso aqui descritos apresentam validações do ponto de vista do

fluxo de negócio. Não obstante, todas as validações da consistência das camadas de
infraestrutura, de segurança e de comunicação, além de quaisquer outras camadas,
também devem ser atendidas.
Os tratamentos de insucesso descritos nesta seção se aplicam também aos casos em

que os PSPs participantes diretos do SPI estão atuando como liquidantes no SPI.
Nesses casos, a instituição deve fazer as devidas interpretações para mapear a
correspondência entre os passos descritos aqui, referentes ao fluxo 1.1.1, e as etapas
do fluxo 1.1.2 (fluxo de transações entre participantes indiretos).
O SPI enviará resposta para todos os pagamentos recebidos (etapa #5 do fluxo 1.1.1),
sejam mensagens de sucesso ou de insucesso. Contudo, em uma situação excepcional
e imprevista na qual o PSP não receba resposta alguma do SPI até o limite de tempo
estabelecido para caracterização de timeout, o PSP deverá adotar as ações previstas
na seção 3.4.6, que trata especificamente da resolução de pagamentos que não foram
respondidos pelo SPI. Isso implica que o PSP nunca deve inferir sucesso ou insucesso
de uma transação sem antes receber alguma resposta do SPI ou executar as ações
previstas na seção 3.4.6.
A má formação da mensagem de pagamento será comunicada por meio da

mensagem ADMI.002. Os erros decorrentes de validações de negócio serão
comunicados por meio da mensagem PACS.002. Essas mensagens estão disponíveis
no Catálogo de Mensagens do SPI.
1.3.1. Validação da mensagem de pagamento pelo SPI
Nesta seção é apresentado o fluxo de tratamento no qual o SPI valida a mensagem de

pagamento enviada pelo PSP do pagador, participante direto do SPI.
No momento em que o SPI recebe a mensagem de pagamento do PSP do pagador,

algumas verificações são efetuadas, como, por exemplo, a verificação (i) de existência
de erro sintático na formação da mensagem enviada; (ii) do tempo transcorrido entre
o momento em o PSP do pagador recebe a ordem de pagamento e o momento em
que o PSP do pagador envia a mensagem de pagamento para o SPI, no caso de
pagamentos para liquidação prioritária; e (iii) o horário de envio da mensagem de
pagamento pelo PSP do pagador, no caso de pagamentos para liquidação não
prioritária.
39
Caso se trate de um pagamento para liquidação não prioritária, o PSP do
2 PSP do pagador Ação pagador armazena a ordem para processamento na data escolhida pelo
usuário pagador.
usuário pagador.
PSP do pagador envia mensagem ao SPI solicitando troca de saldo na
Conta PI para prosseguimento do pagamento.
SPI recebe mensagem enviada pelo PSP do pagador solicitando troca de
5 SPI Mensagem
saldo na Conta PI para prosseguimento do pagamento.
Ao tentar validar a mensagem recebida na etapa #5, o SPI identifica

E1 SPI Ação
alguma das seguintes situações:
40
• erro de sintaxe (inconsistência na mensagem): a mensagem
enviada foi construída incorretamente pelo PSP do pagador 18;
• pagamento para liquidação prioritária enviado após extrapolação
do limite de tempo definido para caracterização de timeout;
• pagamento para liquidação não prioritária enviado fora do
horário limite estabelecido; ou
• outros erros que impeçam a aceitação da mensagem, que devem
ser detectados e devidamente informados pelo SPI durante a
validação da mensagem.
SPI envia informação de insucesso ao PSP do pagador, indicando o
E2 SPI Mensagem
motivo do insucesso do pagamento.
E3 PSP do pagador Mensagem PSP do pagador recebe informação de insucesso da transação.
E4 PSP do pagador Ação PSP do pagador desbloqueia o valor na conta do usuário pagador.
PSP do pagador informa insucesso da transação e o motivo do insucesso
E5 PSP do pagador Comunicação
ao usuário pagador.
1.3.1.1. DIFERENÇA ENTRE AS RESPOSTAS VIA ADMI.002 E VIA

PACS.002
ADMI.002
A ADMI.002 é uma mensagem de erro relativa a aspectos formais das mensagens

recebidas pelo SPI. Os erros indicados via ADMI.002 são identificados antes do efetivo
processamento das operações pelo sistema e indicam que as requisições são
invalidas.
Quando o SPI responde a um estímulo utilizando uma ADMI.002, isso significa que o
sistema não registrou em sua base uma nova operação de pagamento ou não alterou
o estado de uma operação existente nem os saldos das Contas PI relacionadas a essa
operação, conforme o caso.
Portanto, o idFimAFim (EndToEndId) de uma nova operação que foi respondida com
ADMI.002 não poderá ser considerado como aceito nem rejeitado.
Exemplos de situações que geram ADMI.002:
• XML inválido durante verificação pelo XSD;

• idFimAFim preenchido com data e hora anterior a 24h em relação ao
momento da validação realizada pelo SPI; e
18
Uma mensagem com erro sintático não poderá ser consultada posteriormente pelo PSP junto ao
SPI, pois o erro de formação impede o seu armazenamento na base de dados do SPI.
41
• requisições de operações de pagamento diferentes com mesmo idFimAFim.
PACS.002
A mensagem do tipo PACS.002 se refere ao retorno de sucesso ou de rejeição após o
efetivo processamento, pelo SPI, de uma operação recebida pelo sistema.
Assim, uma rejeição indicada na PACS.002 reflete a violação de uma regra de negócio.
Nesse caso, uma vez que a operação foi processada pelo SPI, o idFimAFim
(EndToEndId) da operação será reconhecido pelo sistema para fins de controle e de
consultas posteriores, tanto no caso de sucesso quanto de rejeição. Ademais, a
resposta fornecida na PACS.002 será sempre repetida pelos mecanismos de
idempotência em tentativas subsequentes em que essa situação se configure.
Exemplos de situações que geram PACS.002:
• insuficiência de saldo na Conta PI;

• booktransfer.
1.3.2. Saldo insuficiente na Conta PI do PSP do pagador
Nesta seção é apresentado o fluxo de tratamento no qual o SPI recusa o pagamento

instantâneo devido à insuficiência de fundos na Conta PI do PSP do pagador. Não
existe, no SPI, a figura de mensagem pendente por falta de saldo. Assim, caso não
existam fundos suficientes para liquidar um pagamento no momento da tentativa de
bloqueio do valor na Conta PI, o pagamento será prontamente rejeitado.
42
2 PSP do pagador Ação pagador armazena a ordem para processamento na data escolhida pelo
usuário pagador.
usuário pagador.
SPI recebe mensagem enviada pelo PSP do pagador solicitando troca de
5 SPI Mensagem
saldo na Conta PI para prosseguimento do pagamento.
SPI tenta efetuar o bloqueio, na Conta PI do PSP do pagador, do
6 SPI Ação
montante correspondente ao pagamento instantâneo em questão.
Ao tentar efetuar o bloqueio descrito na etapa #6, o SPI identifica que o
E1 SPI Ação saldo da Conta PI do PSP do pagador é insuficiente para liquidar o
pagamento instantâneo.
SPI envia informação de insucesso ao PSP do pagador, indicando o
E2 SPI Mensagem
motivo do insucesso do pagamento.
43
PSP do pagador informa insucesso da transação e o motivo do insucesso
ao usuário pagador.
1.3.3. Validações efetuadas pelo PSP do recebedor
Nesta seção é apresentado o fluxo de tratamento no qual o PSP do recebedor, no

processo de validação da conta do usuário recebedor, não consegue efetivar a
anotação de crédito. Isso pode ser ocasionado pela incapacidade de o PSP do
recebedor identificar o usuário recebedor, por razões relacionadas à prevenção à
lavagem de dinheiro ou por qualquer outro motivo.

Caso se trate de um pagamento para liquidação não prioritária, o PSP
2 PSP do pagador Ação do pagador armazena a ordem para processamento na data escolhida
pelo usuário pagador.
44
usuário pagador.
SPI recebe mensagem enviada pelo PSP do pagador solicitando troca
5 SPI Mensagem
de saldo na Conta PI para prosseguimento do pagamento.
SPI efetua o bloqueio, na Conta PI do PSP do pagador, do montante
6 SPI Ação
correspondente ao pagamento instantâneo em questão.
SPI envia mensagem ao PSP do recebedor informando os dados da
7 SPI Mensagem
transferência.
8 PSP do recebedor Mensagem PSP do recebedor recebe mensagem com os dados da transferência.
PSP do recebedor tenta validar a conta do usuário recebedor para fazer
9 PSP do recebedor Ação
anotação provisória de crédito.
Ao executar a etapa #9, o PSP do recebedor não faz a anotação
provisória de crédito. Isso pode ser ocasionado pela incapacidade de o
E1 PSP do recebedor Ação PSP do recebedor identificar o usuário recebedor, por razões
relacionadas à prevenção à lavagem de dinheiro ou por qualquer outro
motivo.
PSP do recebedor envia mensagem ao SPI informando insucesso e o
E2 PSP do recebedor Mensagem
motivo de ter recusado o recebimento do pagamento.
E3 SPI Mensagem SPI recebe informação de insucesso do pagamento.
SPI desbloqueia o montante do pagamento na Conta PI do PSP do
E4 SPI Ação
pagador19.
SPI envia mensagem ao PSP do pagador e ao PSP do recebedor
E5 SPI Mensagem
indicando o motivo do insucesso do pagamento.
E6 PSP do pagador Mensagem PSP do pagador recebe informação de insucesso do pagamento.
PSP do pagador informa insucesso da transação e o motivo do
insucesso ao usuário pagador.
E9 PSP do recebedor Mensagem PSP do recebedor recebe confirmação de insucesso do pagamento.
1.3.4. Controle de timeout no SPI
Nesta seção é apresentado o controle de timeout efetuado no SPI, exclusivamente

para pagamentos para liquidação prioritária. Caso o tempo transcorrido entre o
momento em que o SPI recebe a mensagem de pagamento do PSP do pagador (etapa
#5) e o momento em que o SPI ajusta os saldos nas contas PI dos PSPs envolvidos na
transação (etapa #12) exceda o limite de tempo, a ser oportunamente estabelecido,
para caracterização de timeout, o pagamento será rejeitado. Cabe destacar que, uma
19
O SPI irá realizar o desbloqueio no menor tempo possível. Isso é válido para todos os casos de
insucesso em que o SPI tenha que desbloquear os recursos na Conta PI.
45
vez que um pagamento seja considerado final e irrevogável, ele não estará mais
sujeito a rejeição.

Caso se trate de um pagamento para liquidação não prioritária, o PSP
2 PSP do pagador Ação do pagador armazena a ordem para processamento na data escolhida
pelo usuário pagador.
usuário pagador.
SPI recebe mensagem enviada pelo PSP do pagador solicitando troca
5 SPI Mensagem
de saldo na Conta PI para prosseguimento do pagamento.
46
SPI identifica extrapolação do limite de tempo para caracterização de
E1 SPI Ação
timeout20.
E2 SPI Ação SPI desbloqueia a Conta PI do PSP do pagador, se ocorreu o bloqueio.
SPI envia informação de insucesso ao PSP do pagador e ao PSP do
E3 SPI Mensagem
recebedor, indicando o motivo do insucesso.
PSP do pagador informa insucesso da transação e o motivo do
insucesso ao usuário pagador.
E7 PSP do recebedor Mensagem PSP do recebedor recebe informação de insucesso da transação.
PSP do recebedor desfaz anotação de crédito na conta do usuário
E8 PSP do recebedor Ação
recebedor, se a anotação tiver sido efetuada.
1.3.5. Problemas após a transação ser considerada final e

irrevogável
Após o ajuste dos saldos nas contas PI, definido como o momento em que a transação
é considerada final e irrevogável, é possível haver problemas nas etapas #13 a #21 do
fluxo de transações entre participantes diretos descrito na seção 1.1.1.
É possível, por exemplo, que os PSPs utilizem a função descrita na seção 3.4.6
(Resolução de pagamento não respondido pelo SPI), caso haja algum problema após
a transação ser considerada final e irrevogável que impeça os PSPs de receber a
confirmação enviada pelo SPI de que os saldos nas contas PI foram ajustados.
Recomenda-se que os PSPs utilizem a função descrita na seção 3.4.6 sempre que seus
usuários reenviem uma mesma ordem de pagamento, a fim de ter a informação
correta sobre a conclusão com sucesso ou insucesso de uma determinada transação.
Esse procedimento minimiza a probabilidade de pagamentos em duplicidade.
Problemas nas etapas #16, #17, #20 e #21 estão fora do controle do SPI, de forma que
são responsabilidade exclusiva dos PSPs.
Ressalte-se que o recebimento da confirmação da conclusão de uma determinada

transação por apenas um dos usuários já é suficiente para garantir que os saldos nas
contas PI foram efetivamente ajustados e que a transação foi, de fato, concluída. Essa
certeza elimina eventuais problemas em situações em que apenas uma das partes
recebe a confirmação de seu PSP.
20
Caso, na etapa #10, o PSP do Recebedor envie uma mensagem com erro de sintaxe, o SPI indicará
o erro ao PSP do Recebedor e continuará contando o tempo para efeitos de timeout.
47
1.4. Devolução do PIX
Após o fim de uma determinada transação, em que os fundos já estão disponíveis

para o usuário recebedor, é possível que exista a necessidade de devolução desses
fundos para o usuário pagador. Essa necessidade pode advir, por exemplo, de uma
eventual reversão do acordo comercial, como insatisfação com o bem ou serviço
transacionado, ou de algum erro no pagamento. A fim de facilitar esse processo de
devolução, de forma que os usuários finais tenham a melhor experiência possível,
prevê-se essa funcionalidade no PIX.
Trata-se de processo ágil e padronizado de devolução sem necessidade de inserção

de informações do usuário pagador da transação original para a realização da nova
transação. A operação permite que o recebedor da transação original, ao iniciar a
transação de devolução, não tenha que saber os dados da conta transacional do
usuário pagador. A transação é iniciada pelo usuário que recebeu a transação original.
Os PSPs, portanto, não podem iniciar transações envolvendo clientes, inclusive
aquelas de devolução. Para iniciar uma transação de pagamento, o usuário que
recebeu a transação original deve acessar o seu extrato de pagamentos 21, escolher
uma transação específica de recebimento e, caso esteja dentro do prazo, solicitar a
sua devolução. A funcionalidade da devolução deve estar disponível para todas as
transações recebidas nos últimos noventa dias. Essa interface de devolução é um
padrão mínimo, que será oportunamente especificada no anexo VI deste documento
(Requisitos Mínimos de Experiência do Usuário). Soluções complementares que
atendam necessidades específicas dos usuários são aceitas. Para tornar o processo
mais claro, haverá campo padronizado para que seja informado o motivo da
devolução.
Podem haver várias devoluções para uma mesma transação original, desde que o
valor de cada transação, assim como a soma total do valor dessas devoluções, não
ultrapasse o montante da transação de pagamento original. Isso implica que é
possível devolver uma transação com um valor diferente do valor da transação
original.
Cabe salientar que a devolução é uma funcionalidade do PIX com o objetivo de

melhorar a experiência do cliente. Sua utilização é realizada após a resolução de
disputa, nos termos do regulamento do PIX, que será oportunamente divulgado. Caso
21
Prevê-se que os PSPs ofertem a seus clientes extrato com todos os PIX enviados e recebidos
dentro de um determinado período. Esse extrato não deverá se restringir às operações passíveis
de devolução e deverá permitir que uma devolução seja iniciada de forma simples e rápida para
todas aquelas transações que podem ser devolvidas.
48
o usuário deseje devolver um valor que recebeu após o prazo limite para geração de
transações de devolução, ele deve realizar uma transação de transferência padrão
para o usuário pagador da transação original.
O PSP do remetente da devolução deve recuperar, com base no EndToEndId, a data do

pagamento22, o PSP do destinatário da devolução (ou seja, o PSP do usuário pagador
da transação original) e o valor da transação. Esses dados são, assim, comunicados ao
SPI, que apenas os repassa ao PSP do destinatário. O PSP do destinatário da
devolução, por sua vez, deve recuperar, para fins de conferência e de prosseguimento
da ordem de devolução, também com base no EndToEndId, a data do pagamento, o
PSP do pagador da transação original, o valor da transação e os dados da conta
transacional, inclusive CPF/CNPJ, do destinatário da devolução (ou seja, o usuário
pagador da transação original). Portanto, para fins do processo de devolução, os PSPs
devem armazenar os dados mencionados por noventa dias. A busca dos dados
armazenados nos PSPs é feita pelo EndToEndId, de forma que o SPI não faz a
recuperação nem a conferência de nenhum dado. Essa especificação do conjunto de
dados a serem armazenados pelos PSPs se refere exclusivamente ao processo de
devolução. Os dados completos das transferências devem ser armazenados por
ambos os PSPs de acordo com os prazos e as condições estabelecidas na legislação
vigente.
O processamento de ordem de devolução somente ocorre com o atendimento de

alguns parâmetros, os quais são controlados pelos PSPs do usuário remetente e do
usuário destinatário, não cabendo qualquer controle pelo SPI, a saber:
a. o limite para a geração de uma ordem de devolução é de noventa dias

contados a partir da liquidação da transação original;
b. somente o usuário recebedor da transação original pode gerar uma
ordem de devolução (esse controle é feito somente pelo PSP do remetente
da devolução);
c. a conta do remetente da devolução deve existir e estar ativa (conferência
feita apenas pelo PSP do remetente);
d. a conta do destinatário da devolução deve existir e estar e ativa
(conferência feita apenas pelo PSP do destinatário);
e. o valor da devolução pode ser inferior ou igual ao valor da transação
original. São possíveis múltiplas devoluções para uma mesma transação
original desde que a soma do valor dessas devoluções não seja superior
ao valor da transação original;
f. a devolução somente pode ser creditada para o usuário pagador da
transação original (controle feito somente pelo PSP destinatário da
devolução);
22
O EndToEndId e a data de pagamento são dados padronizados e informados pelo SPI.
49
g. somente o PSP recebedor da transação original pode iniciar uma ordem
de devolução solicitada pelo usuário remetente. O EndToEndId, portanto,
deve corresponder ao da mensagem PACS.008 objeto da devolução;
h. somente o PSP que originou, a pedido do usuário pagador, a ordem de
pagamento da transação original, pode dar curso à ordem de devolução
para usuário destinatário que seja seu cliente;
i. aplicam-se para as transações de devolução o timeout e, no que couber, os
acordos de nível de serviço das transações prioritárias usuais de
pagamento; e
j. é necessária a existência de fundos na conta transacional do usuário
remetente e na Conta PI de seu PSP.
Caso qualquer um desses parâmetros não sejam atendidos, deve haver a negação do
processamento e da liquidação da ordem de devolução. Não deve haver rejeição de
ordem de devolução por outro motivo que não a violação de um dos parâmetros
destacados acima. O usuário remetente deve ser informado, por seu PSP, sobre o erro
específico que eventualmente impeça o processamento da ordem de devolução.
Assim, negações de ordem pelo PSP do destinatário devem ser comunicadas ao SPI
por meio da mensagem PACS.002, o qual comunicará o PSP do remetente, para que o
usuário possa ser informado.
A ordem de devolução do PIX é feita por meio da mensagem PACS.004, cujos campos
e descrições dos campos serão oportunamente divulgados.
Aplicam-se aos fluxos de processamento da ordem de devolução, no que couber, os

mesmos tratamentos de erro da seção 1.3 – Cenários de insucesso na liquidação do
PIX.
1.4.1. Criação de ordem de devolução

Conforme destacado, a ordem de devolução é gerada somente pelo usuário
recebedor da transação original, que passa a ser chamado de usuário remetente da
devolução. Qualquer transação que o usuário remetente tenha recebido é passível de
devolução, por meio de comando em seu canal de acesso, no prazo de noventa dias
do recebimento. A solicitação é enviada pelo usuário remetente ao seu PSP junto com
o código da transação (EndToEndId). É por meio desse identificador que o PSP do
usuário remetente recupera as informações necessárias para a geração da ordem de
devolução, quais sejam: a data do pagamento, o usuário recebedor da transação
original (uma vez que apenas ele pode solicitar a devolução), o PSP do destinatário da
devolução (ou seja, o PSP do usuário pagador da transação original) e o valor da
transação original.
O fluxo abaixo trata do processo de criação de uma ordem de devolução pelo usuário
remetente:
50
Início do processo. Usuário remetente acessa seu canal de
1 Usuário remetente Ação
atendimento.
Usuário remetente solicita, em seu canal de atendimento,
2 Usuário remetente Ação devolução de determinada transação da qual ele foi o usuário
recebedor.
Usuário remetente envia comunicação ao seu PSP solicitando a
3 Usuário remetente Comunicação
devolução de transação, informando o EndToEndId.
PSP do remetente recebe comunicação de devolução com
4 PSP do remetente Comunicação
EndToEndId.
O PSP do remetente da devolução recupera, com base no
EndToEndId, a data do pagamento, o PSP do destinatário da
devolução (ou seja, o PSP do usuário pagador da transação
original) e o valor da transação. O valor de devolução solicitado
pelo usuário remetente pode ser menor ou igual ao valor da
5 PSP do remetente Ação transação original. No caso de diversas devoluções, o PSP deve
considerar a soma dessas devoluções, a qual não pode ser
maior que o valor da transação original. Caso a mensagem de
devolução seja validada com sucesso, ou seja, caso o
EndToEndId seja válido e a ordem tenha sido enviada pelo
usuário recebedor da transação original dentro do prazo de 90
51
dias do recebimento, deve ser gerada uma ordem de
devolução.
PSP do remetente envia comunicação, informando o
processamento da devolução ou sua rejeição.
Usuário remetente recebe comunicação do seu PSP a respeito
do processamento ou da rejeição da devolução.
1.4.2. Devolução entre participantes diretos

Nesta seção é apresentado o fluxo da devolução do PIX em que tanto o PSP do
pagador quanto o do recebedor são participantes diretos do SPI.
52
1 PSP do remetente Comunicação Início do processo. PSP do remetente recebe ordem de devolução.
PSP do remetente realiza bloqueio do valor da devolução na conta
2 PSP do remetente Ação
do usuário remetente.
PSP do remetente envia mensagem ao SPI solicitando troca de
3 PSP do remetente Mensagem
saldo na Conta PI para prosseguimento da devolução.
SPI recebe mensagem enviada pelo PSP do remetente solicitando
4 SPI Mensagem
troca de saldo na Conta PI para prosseguimento da devolução.
SPI efetua o bloqueio na Conta PI do PSP do remetente no
5 SPI Ação
montante da devolução em questão.
SPI envia mensagem ao PSP do destinatário informando os dados
6 SPI Mensagem
da devolução.
PSP do destinatário recebe mensagem com os dados da
7 PSP do destinatário Mensagem
devolução.
O PSP do destinatário da devolução recupera, com base no
EndToEndId, a data do pagamento, o valor da transação e os
8 PSP do destinatário Ação
dados da conta transacional do destinatário da devolução (ou
seja, do usuário pagador da transação original).
Em seguida, o PSP do destinatário valida a devolução: verifica se
atende ao prazo de 90 dias, se o destinatário é seu cliente, se o
valor está adequado e se a conta do usuário destinatário está
ativa.
Caso o retorno da validação seja positivo, PSP do destinatário faz
anotação provisória de crédito na conta do usuário destinatário.
PSP do destinatário envia mensagem ao SPI, solicitando o
prosseguimento da devolução.
SPI recebe mensagem enviada pelo PSP do destinatário,
12 SPI Mensagem
solicitando o prosseguimento da devolução.
Conta PI do PSP do remetente no valor da devolução em questão
13 SPI Ação e aumenta o saldo da Conta PI do PSP do destinatário no mesmo
montante. Nesse momento, considera-se que a transação de
devolução é final e irrevogável.
SPI envia confirmação de conclusão da transação ao PSP do
14 SPI Mensagem
destinatário e ao PSP do remetente.
PSP do destinatário recebe mensagem de confirmação de
conclusão da devolução.
PSP do destinatário efetiva o crédito na conta do usuário
destinatário
PSP do destinatário envia comunicação de confirmação de
17 PSP do destinatário Comunicação
conclusão da devolução ao usuário destinatário.
Usuário destinatário recebe a comunicação informando a
18 Usuário destinatário Comunicação
PSP do remetente recebe mensagem de confirmação de
19 PSP do remetente Mensagem
53
PSP do remetente efetiva o débito na conta do usuário remetente
no valor da devolução.
PSP do remetente envia comunicação de confirmação de
conclusão da devolução ao usuário remetente.
Usuário remetente recebe a comunicação informando a
1.4.3. Devolução entre participantes indiretos

Nesta seção é apresentado o fluxo da devolução do PIX em que tanto o PSP do
pagador quanto o do recebedor são participantes indiretos do SPI.
54
Início do processo. PSP do remetente recebe ordem de
devolução.
PSP do remetente realiza bloqueio do valor da devolução na
conta do usuário remetente.
55
PSP do remetente envia comunicação ao participante direto
3 PSP do remetente Comunicação remetente, solicitando troca de saldo na Conta PI para
Participante direto Participante direto remetente recebe comunicação solicitando
4 Comunicação
remetente troca de saldo na Conta PI para prosseguimento da devolução.
Participante direto remetente envia mensagem ao SPI
Participante direto
5 Mensagem solicitando troca de saldo na Conta PI para prosseguimento da
remetente
devolução.
SPI recebe mensagem enviada pelo participante direto
6 SPI Mensagem remetente solicitando troca de saldo na Conta PI para
SPI efetua o bloqueio na Conta PI do participante direto
7 SPI Ação
remetente no montante da devolução em questão.
SPI envia mensagem ao participante direto destinatário
8 SPI Mensagem
informando os dados da devolução.
Participante direto Participante direto destinatário recebe mensagem com os dados
9 Mensagem
destinatário da devolução.
Participante direto Participante direto destinatário envia comunicação ao PSP do
10 Comunicação
destinatário destinatário com os dados da devolução.
PSP do PSP do destinatário recebe comunicação com os dados da
11 Comunicação
destinatário devolução.
O PSP do destinatário da devolução recupera, com base no
PSP do EndToEndId, a data do pagamento, o valor da transação e os
12 Ação
destinatário dados da conta transacional do destinatário da devolução (ou
seja, o usuário pagador da transação original).
Em seguida, o PSP do destinatário valida a devolução: verifica se
PSP do atende ao prazo de 90 dias, se o destinatário é seu cliente, se o
13 Ação
destinatário valor está adequado e se a conta do usuário destinatário está
ativa.
PSP do Caso o retorno da validação seja positivo, PSP do destinatário faz
14 Ação
destinatário anotação provisória de crédito na conta do usuário destinatário.
PSP do PSP do destinatário envia comunicação ao participante direto
15 Comunicação
destinatário destinatário, solicitando o prosseguimento da devolução.
Participante direto destinatário recebe comunicação enviada
Participante direto
16 Comunicação pelo PSP do destinatário, solicitando o prosseguimento da
destinatário
devolução.
Participante direto Participante direto destinatário envia mensagem ao SPI,
17 Mensagem
destinatário solicitando o prosseguimento da devolução.
SPI recebe mensagem enviada pelo participante direto
18 SPI Mensagem
destinatário solicitando o prosseguimento da devolução
19 SPI Ação Conta PI do participante direto remetente no valor da devolução
em questão e aumenta o saldo da Conta PI do participante
56
direto destinatário no mesmo montante. Nesse momento,
considera-se que a transação de devolução é final e irrevogável.
SPI envia confirmação de conclusão da devolução ao
20 SPI Mensagem participante direto destinatário e ao participante direto
remetente.
Participante direto Participante direto destinatário recebe mensagem de
21 Mensagem
destinatário confirmação de conclusão da devolução enviada pelo SPI.
Participante direto Participante direto destinatário envia comunicação de
22 Comunicação
destinatário confirmação de conclusão da devolução ao PSP do recebedor.
PSP do PSP do destinatário recebe comunicação de confirmação de
23 Comunicação
destinatário conclusão da devolução.
PSP do PSP do destinatário efetiva o crédito na conta do usuário
24 Ação
destinatário destinatário
PSP do PSP do destinatário envia comunicação de confirmação de
25 Comunicação
destinatário conclusão da devolução ao usuário destinatário.
Usuário Usuário destinatário recebe a comunicação informando a
26 Comunicação
destinatário conclusão da devolução.
Participante direto Participante direto remetente recebe mensagem de confirmação
27 Mensagem
remetente de conclusão da devolução enviada pelo SPI.
Participante direto Participante direto remetente envia comunicação de
28 Comunicação
remetente confirmação de conclusão da devolução ao PSP do remetente.
PSP do remetente recebe comunicação de confirmação de
PSP do remetente efetiva o débito na conta do usuário
remetente no valor da devolução.
PSP do remetente envia comunicação de confirmação de
conclusão da devolução ao usuário remetente.
Usuário remetente recebe a comunicação informando a
57
2. ESPECIFICAÇÕES TÉCNICAS DO PIX
58
O objetivo desta seção é apresentar as especificações técnicas do PIX. Nela serão
tratadas (i) as diferentes formas de participação dos PSPs no PIX; (ii) o padrão de
comunicação entre os diversos participantes do PIX e o SPI; (iii) as diferentes
possibilidades de conexão entre os participantes do PIX e o SPI; (iv) os princípios e
requisitos gerais de segurança do PIX, incluindo aspectos relacionados à autenticação
e à criptografia das transações e aos certificados digitais que devem ser utilizados; (v)
as características gerais e a forma de funcionamento do diretório de endereçamento,
que facilitará a identificação do beneficiário final do pagamento; (vi) os requisitos para
autenticação digital dos usuários pagadores; e (vii) questões relacionadas ao princípio
da idempotência.
2.1. Participação no PIX
O PIX possuirá estrutura flexível e aberta de participação, a fim de garantir o acesso e

o surgimento de participantes que ofertem serviços inovadores e diferenciados que
atendam às necessidades dos usuários finais, admitindo duas modalidades de
participação:
a. prestador de serviço de pagamento que mantém conta transacional:

instituição financeira ou instituição de pagamento que oferta uma conta
transacional para o usuário final, inclusive as instituições de pagamento não
sujeitas à autorização de funcionamento pelo BC; e
b. ente governamental: órgão da administração direta, exclusivamente para
iniciar ou receber pagamentos próprios.
A participação no PIX é obrigatória para instituições financeiras e instituições de

pagamento, autorizadas a funcionar pelo BC, que tenham mais de 500.000 contas
transacionais ativas.
Além dessas duas modalidades, também será possível a participação de prestadores

de serviço de iniciação de pagamentos, assim que eles forem regulados 23. Esses
prestadores são instituições que não ofertam conta transacional para o usuário final,
mas que ofertam serviço de pagamento utilizando a conta transacional que o usuário
detém em um PSP que mantém conta transacional.
2.2. Padrão de comunicação
23
A regulação dos prestadores de serviço de iniciação de pagamento será realizada no âmbito da
implementação, no Brasil, do Sistema Financeiro Aberto (Open Banking). Ver Comunicado nº
33.455, de 24 de abril de 2019, disponível em:
<https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Comunicado&numero=33
455>.
59
O padrão internacional de comunicação ISO 20022 é usado para desenvolvimento de
mensagens para a indústria financeira. O padrão ISO 20022 vem sendo adotado em
diversas iniciativas do setor financeiro ao redor do mundo, principalmente nos
sistemas de pagamentos instantâneos. As principais justificativas para sua utilização
são:
a. interoperabilidade global: permite que diferentes sistemas se comuniquem

por meio das mesmas mensagens, impulsionando o comércio transfronteiriço
e diminuindo a barreira de entrada aos novos participantes do segmento
financeiro;
b. eficiência: a transmissão de informação detalhada sobre os pagamentos
efetuados e a possibilidade de cobrir toda cadeia de valor da indústria
financeira permitem a automação de processos internos aos usuários do
padrão ISO 20022, o que contribui para a redução de erros em processos
manuais, para a redução de custos dos processos e para o aumento da
eficiência das organizações;
c. inovação: a riqueza de informações sobre o pagamento, aliada à flexibilidade
tecnológica do padrão ISO 20022, possibilita a oferta de produtos inovadores
e competitivos, melhorando a experiência dos usuários finais. As mensagens
ISO 20022 são flexíveis às mudanças tecnológicas e às incorporações de
requisitos adicionais que atendam às necessidades de mercado; e
d. aderência regulatória: a expansão e o acréscimo de campos de informações,
característica do padrão de comunicação, pode facilitar o rastreamento e a
verificação de pagamentos, o que auxilia no cumprimento de procedimentos
regulatórios relacionados à mitigação de fraudes, ao combate à lavagem de
dinheiro, às políticas de know your customer e às atividades de auditoria fiscal.
Com base em todos os benefícios advindos do uso do padrão que foram identificados
em pesquisa de benchmarking internacional e na interação com participantes do
mercado financeiro brasileiro, decidiu-se pela utilização do ISO 20022 como padrão
de comunicação do PIX.
2.2.1. Padrão de representação das mensagens

A forma de representação das mensagens ISO20022 adotada no SPI é o padrão
Extensible Markup Language (XML), tal como apresentado no catálogo da norma (ver
https://www.iso20022.org/full_catalogue.page). A decisão por tal padrão objetiva
permitir uma utilização mais ampla dos recursos providos pela ISO20022, entre eles o
Business Application Header (BAH) e o padrão de assinatura digital associado, o
XMLDSig (https://www.w3.org/TR/xmldsig-core/).
Na avaliação de possíveis alternativas, foi descartado o padrão JSON (i) por exigir uma
conversão do catálogo da ISO, expresso no padrão XML; (ii) por exigir a geração de
JSON Schemas, derivados dos XSDs disponibilizados no catálogo; e (iii) por não
60
representar redução significativa no tamanho das mensagens, quando obedecidas as
regras de conversão estabelecidas pela norma.
2.3. Conectividade
No que concerne à conectividade ao SPI, o BC optou por adotar a Rede do Sistema
Financeiro Nacional (RSFN) para suportar o tráfego de comunicação dentro do
ecossistema de pagamentos instantâneos brasileiro. A RSFN é a estrutura de
comunicação de dados que tem por finalidade amparar o tráfego de informações no
âmbito do Sistema Financeiro Nacional (SFN) para serviços autorizados pelo Comitê
Gestor, conforme disposto na Circular nº 3.629, de 19 de fevereiro de 2013. Seu
objetivo principal é suportar o tráfego de dados diretamente relacionados a serviços
críticos, podendo, desde que não haja interferência em seu objetivo principal, suportar
o tráfego de dados de outra natureza.
Atualmente, o ingresso da instituição autorizada à RSFN ocorre por meio da

contratação de circuitos das operadoras de telecomunicação independentes que
proveem a rede, ou por meio de circuitos das redes homologadas pertencentes aos
Provedores de Serviços de Tecnologia da Informação (PSTI) autorizados pelo BC.
Com vistas a ampliar a forma de acesso à rede do SPI, o BC admite a possibilidade de

o PSTI ofertar, além da rede homologada, a Internet como meio de comunicação.
Detalhes acerca da conexão pela Internet, intermediada pelo PSTI, podem ser
encontrados na versão 9.0 do Manual de Redes do SFN24.
A figura abaixo mostra as três formas possíveis de conexão do participante direto ao

SPI.
24
Cabe salientar que não haverá acesso direto ao SPI por meio da Internet. O Manual de Redes
está disponível em
https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Manual_de_Redes_do_SFN_Ver
_9.pdf.
61
2.3.1. Interface de comunicação
A transmissão das mensagens ISO 20022 entre os PSPs e o SPI se dará através de
serviços HTTP disponibilizados pelo SPI.
O tráfego de mensagens obedecerá às seguintes regras:
a. o PSP enviará mensagens ao SPI através de requisição a um endpoint HTTP

específico para essa finalidade; e
b. o PSP receberá mensagens do SPI através de requisições por outro endpoint

do SPI, que retornará as mensagens disponíveis ao PSP. Caso não haja
mensagem alguma destinada ao PSP, o SPI poderá aguardar até que haja
mensagens disponíveis. Após o envio da resposta e a recepção, o PSP deverá
efetuar outra requisição para obter as mensagens seguintes.
Não haverá, portanto, serviços HTTP disponibilizados pelos PSPs para troca de
mensagens com o SPI.
Os fluxos de envio e de recepção de mensagens serão desenhados de modo a

oferecer garantia de entrega de mensagens em ambos os lados.
A versão utilizada do protocolo HTTP será a 1.1, e a comunicação se dará através de

HTTPS conforme especificado na seção 2.5.1.
2.4. Princípios de segurança

Todos os aspectos do ecossistema de pagamentos instantâneos deverão ser
projetados e desenvolvidos considerando boas práticas de segurança. É primordial
garantir a privacidade e a proteção dos dados dos cidadãos. Nesse contexto, é
necessário o atendimento aos requisitos de segurança do ecossistema, em que se
destacam:
62
a. disponibilidade: garantia de que as informações estejam acessíveis a pessoas
e a processos autorizados;
b. integridade: garantia de que a informação não foi modificada na origem, no
trânsito ou no destino;
c. confidencialidade: garantia de que a informação não esteja disponível ou não
seja revelada a pessoas e a processos não autorizados; e
d. autenticidade: garantia da veracidade da fonte das informações.
Adicionalmente, o ecossistema deverá estar aderente à Lei Geral de Proteção de

Dados Pessoais (LGPD)25, a fim de assegurar a proteção dos dados pessoais, tanto os
dados de identificação quanto os dados de registro das transações, dos usuários finais
do PIX. Portanto, deverão ser transmitidos e armazenados apenas os dados pessoais
estritamente necessários ao funcionamento do sistema. Deve-se considerar também
o uso das técnicas de anonimização e pseudonimização nos casos possíveis.
2.5. Requisitos de segurança
2.5.1. Criptografia e autenticação mútua na comunicação

Cada PSP deve se conectar ao SPI exclusivamente por meio do protocolo HTTP
utilizando criptografia TLS, conforme especificado no Manual de Segurança PI26.
Deverá haver autenticação mútua no estabelecimento da conexão, isto é, tanto o
cliente como o servidor deverão apresentar certificados digitais para se autenticar.
Mais detalhes sobre os certificados digitais constam na seção 2.5.3. As instituições são
responsáveis pela proteção e pelo sigilo do conteúdo das mensagens no âmbito dos
seus sistemas e bancos de dados internos.
2.5.2. Assinatura digital das mensagens

Todas as mensagens transmitidas no SPI deverão ser assinadas digitalmente pelo
emissor. O receptor validará a assinatura digital de cada mensagem para garantir sua
integridade e o não-repúdio. A assinatura deve constar no Business Application Header
(BAH) das mensagens ISO 20022, e o padrão adotado é o XMLDSig27, utilizando o
algoritmo RSA-SHA256 para assinatura.
25
Lei nº 13.709, de 14 de agosto de 2018, que dispõe sobre a proteção de dados pessoais.
Disponível em: <http://www.planalto.gov.br/ccivil_03/_Ato2015-2018/2018/Lei/L13709.htm>.
26
Manual de Segurança PI. Disponível em
https://www.bcb.gov.br/estabilidadefinanceira/forumpagamentosinstantaneos
27
Padrão XMLDSig. Disponível em: http://www.w3.org/Signature/.
63
A especificação detalhada do processo de geração e validação da assinatura digital
das mensagens, bem como a descrição dos algoritmos e padrões utilizados constam
no Manual de Segurança PI.
2.5.3. Certificados digitais a serem utilizados

Tanto para criptografia da comunicação (item 2.5.1) como para assinatura digital (item
2.5.2), deverão ser utilizados certificados ICP-Brasil no padrão SPB, gerados conforme
especificado no Manual de Segurança do SFN28. Recomenda-se que sejam utilizados
certificados distintos para cada fim.
As instituições participantes devem possuir processos adequados de gestão (geração,

guarda, ativação e revogação) dos seus certificados digitais utilizados no âmbito do
SPI. Nesse contexto, recomenda-se a utilização de dispositivos de criptografia
baseados em hardware (HSMs) para armazenamento das chaves privadas dos
certificados utilizados no SPI.
2.5.4. Ativação e desativação de certificados digitais

A ativação de um novo certificado para uma instituição participante se dará por meio
de envio de arquivo específico no Sistema de Transferência de Arquivos (STA)29,
conforme detalhado no Manual de Segurança PI. Após a validação do certificado pelo
BC, ele será ativado automaticamente. O BC comunicará às instituições participantes
somente sobre a ativação do seu próprio certificado, informando um prazo para que
as instituições passem a aceitar o novo certificado. Poderão estar ativos
simultaneamente múltiplos certificados por instituição – 1 ou mais certificados para
criptografia TLS e 1 ou mais certificados para assinatura digital. O mesmo se aplica aos
certificados do BC.
Os certificados serão automaticamente desativados às 03:00 UTC da sua data de

expiração e, portanto, não serão mais aceitos pelo BC. Caso seja necessário desativar
determinado certificado, a instituição poderá formalizar solicitação ao BC.
2.5.5. Manutenção de logs de segurança
Todos os participantes do ecossistema devem manter os logs de segurança para

registrar todas as mensagens enviadas e recebidas e permitir a auditoria das
mensagens trafegadas. Os registros deverão conter referências temporais que
identifiquem o momento em que as mensagens foram assinadas. O prazo de retenção
28
Manual de Segurança do SFN, versão 4.01. Disponível em:
https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Manual_Seguran%C3%A7a_SFN-
v4_01.pdf.
29
Sistema de Transferência de Arquivos do Banco Central. Disponível em: https://sta.bcb.gov.br.
64
dos registros será de 10 (dez) anos, contados da data da emissão e assinatura do
registro. Os certificados usados e identificação dos algoritmos utilizados para verificar
a assinatura das mensagens também deverão ser registrados. Os participantes devem
apresentar, havendo demanda da fiscalização do BC, seus arquivos de logs com os
dados em claro.
2.6. Diretório de Identificadores de Contas Transacionais

(DICT)
O DICT é o componente do PIX que armazenará as informações das chaves ou
apelidos que servem para identificar as contas transacionais dos usuários
recebedores de maneira intuitiva e simplificada, permitindo que o usuário pagador
utilize informações que ele já possui sobre o usuário recebedor para iniciar o
pagamento.
Esse diretório contribuirá para a conveniência e para a segurança dos pagamentos

instantâneos, uma vez que possibilita uma melhor experiência do usuário em diversos
casos de uso, além de agregar segurança ao PIX. Nesse sentido, seu adequado
desenho e funcionamento são essenciais, tanto no que diz respeito à promoção da
adesão dos usuários pagadores e recebedores quanto à imagem e à confiabilidade do
arranjo.
O DICT será único e centralizado, de forma a maximizar os ganhos de escala e os

efeitos de rede típicos da indústria de pagamentos. Além disso, o BC será o
desenvolvedor, o gestor e o operador desse diretório.
2.6.1. Chaves para endereçamento

A chave para endereçamento é uma forma de simplificar a identificação e a
comunicação de uma conta transacional. As contas transacionais são formadas por
diversos números que, além da conta em si, também identificam a instituição
responsável e, se houver, a agência. Além de não ser provido de significado para o
usuário pagador, o número de conta, usualmente, é um dado extenso, cujo processo
de comunicação e de utilização não é intuitivo para os usuários. O objetivo da chave
para endereçamento, portanto, é utilizar informações que sejam de fácil acesso e de
simples inserção pelo usuário pagador. Essas chaves estarão armazenadas no
diretório de endereçamento e estarão vinculadas à conta transacional do usuário
recebedor. De maneira simplificada, pode-se compreender a chave para
endereçamento como um apelido que identifica uma determinada conta transacional.
Um aspecto importante para facilitar a experiência de pagamento é permitir que o

usuário pagador utilize informações que, em geral, ele já possua do usuário
recebedor. Nesse ponto, deve-se atentar para o instrumento de pagamento que se
espera que seja usualmente utilizado nos pagamentos instantâneos: o smartphone. É
65
intuitivo, assim, que o número de telefone celular seja uma das chaves de
endereçamento. O usuário terá fácil acesso a essa informação, uma vez que, para
pessoas com quem o usuário tenha tido contato anteriormente, ela poderá estar
armazenada em sua lista de contatos, no mesmo aparelho que usualmente será
utilizado como instrumento de pagamento. Além de intuitivo, a utilização de número
de telefone celular como chave de endereçamento possui forte amparo na
experiência internacional.
Há, no entanto, usuários que possam preferir não serem identificados por seu número
de telefone celular. Supõe-se, por exemplo, que empresas de médio e de grande porte
não tenham interesse em utilizar esse tipo de chave, buscando algo mais fortemente
vinculado à sua marca. Em outros casos, usuários que troquem de número de telefone
celular com frequência ou que tenham o porte do aparelho celular, mas não a posse,
podem não se sentir confortáveis em utilizar o número de telefone celular como um
vínculo à sua conta transacional. Portanto, é razoável que outras opções de chave de
endereçamento estejam disponíveis para escolha dos usuários finais. Além do
número de telefone celular, optou-se por dois outros tipos de chave: CPF/CNPJ e
endereço de e-mail.
O CPF/CNPJ do usuário final é uma chave que pode ser utilizada com maior frequência
para pagamentos que envolvam formalidade. Em transações governamentais, por
exemplo, em que o órgão de governo já possui dados de CPF dos beneficiários, essa
chave pode facilitar os pagamentos, uma vez que será suficiente para identificar o
usuário recebedor, evitando a gestão de informações da conta transacional pela
instituição governamental. Empresas podem ter interesse em serem identificadas por
seu CNPJ quando tiverem fornecido ao usuário pagador documento de cobrança que
contenha essa informação, por exemplo.
O endereço de e-mail, dada a sua facilidade de criação e de validação, é uma chave de

endereçamento interessante, pois permite ao usuário estabelecer, sem custo
significativo, entradas alfanuméricas da forma que entender mais apropriada, dentro
das opções disponíveis no domínio de e-mail escolhido. O CPF/CPNJ e, para a maioria
dos usuários, o número de telefone celular, não são de livre escolha. O e-mail, devido
à sua facilidade de criação sem custo e à grande variedade de domínios disponíveis,
soluciona essa rigidez de escolha em relação às outras duas opções de chave e se
apresenta como uma chave de endereçamento de livre escolha. Além disso, em
diversos casos, assim como ocorre com o número de telefone celular, é possível que
o usuário pagador já possua, em seu smartphone, a informação de endereço de e-mail
do usuário recebedor.
Cabe destacar que se optou por limitar as chaves de endereçamento a opções

passíveis de validação pelo PSP, no momento de seu cadastro pelo usuário. Entende-
se que uma chave livre e não passível de validação poderia estimular a fraude e gerar
66
dúvidas em relação a quais parâmetros seriam utilizados para evitar o uso abusivo de
um campo de preenchimento totalmente livre.
O PSP, portanto, deve fazer uma validação ativa das chaves de endereçamento no
momento de seu cadastro, além de verificar se a chave pretendida está disponível no
diretório de endereçamento. No caso do CPF/CNPJ, a chave informada deve ser o
CPF/CNPJ do titular da conta, que deve ser confirmada por meio da base de dados da
Receita Federal ou por meio do cadastro do usuário final no próprio PSP. Para
endereço de e-mail e número de telefone celular, deve haver o envio de um código
para o e-mail ou para o número de telefone celular informado, que deve ser retornado
pelo usuário para fins de confirmação.
O usuário final poderá escolher um número limitado, a ser oportunamente definido,

de chaves de endereçamento para cada conta transacional da qual for titular. Nenhum
dos tipos de chave é obrigatório. Cada chave poderá estar vinculada a uma única conta
transacional. Ou seja, caso um determinado usuário seja titular de mais que uma
conta transacional, ele terá que vincular chaves diferentes para cada uma das contas
em que seja titular.
Além desses três tipos de chave para endereçamento, que demandam algum tipo de
validação por parte do PSP, também será possível a utilização de um quarto tipo de
chave: o Endereço Virtual de Pagamento (EVP). O EVP é uma chave que poderá ser
utilizada principalmente para a geração de QR Code estático.
Como detalhado na seção 1.2.2, o QR Code estático é um meio de armazenar

informações, que apresenta característica de livre leitura de maneira completamente
aberta. Ou seja, qualquer pessoa munida de um dispositivo leitor de QR, como uma
câmera simples em um smartphone, consegue ler as informações que estão ali
codificadas. Como o QR Code estático requer o uso de uma chave, é possível a
existência de problemas de privacidade, caso o usuário utilize dados pessoais como
chave para endereçamento, a exemplo do número do telefone celular, do e-mail e do
CPF/CNPJ. Caso o usuário não se sinta confortável em disponibilizar essas informações
no QR Code estático, ele poderá utilizar o EVP. O EVP é uma sequência alfanumérica
que não possui qualquer significado, a não ser o de servir como uma chave para
endereçamento. O EVP não é uma chave de determinação livre. Trata-se de uma chave
constituída por uma sequência de bits verdadeiramente aleatórios30, utilizando UUID31
30
https://tools.ietf.org/html/rfc1750 - Randomness Recommendations for Security
31
https://tools.ietf.org/html/rfc4122#page-14
67
versão 432, e sempre gerada pelo DICT. O EVP só pode ser registrado ou excluído. Ele
não é passível de portabilidade nem de reivindicação de posse.
No caso do EVP, o PSP deve solicitar sua geração, de maneira online, para o DICT. O
DICT gerará um EVP que será necessariamente atrelado a uma conta que o PSP
conhece, de forma que não é necessário nenhum processo de validação. Cada EVP é
único dentro do PIX e só pode estar atrelado a uma única conta. Assim como nas
demais chaves, uma conta pode estar vinculada a mais de um EVP.
O quadro abaixo resume as chaves para endereçamento que serão utilizadas no PIX:
Tipo Formato Descrição

O telefone celular usará o
padrão E.16433. Segundo
esse padrão, a máscara é
Número de
formada pelo símbolo ‘+’,
Telefone +XXXXXXXXXXXXX
seguido do código do país,
Celular
DDD, e número de celular
com nove dígitos (por
exemplo: +5511999998888)
O e-mail terá tamanho
máximo de 72 caracteres
(tamanho máximo do
campo e-mail no QR Code),
Endereço de
[email protected](.xx) será validado de acordo com
E-mail
uma expressão regular a ser
definida oportunamente e
seus caracteres estarão
todos em minúsculo.
O CPF/CNPJ será utilizado
com 11 números no caso do
XXXXXXXXXXX ou
CPF/CNPJ CPF e com 14 dígitos no
XXXXXXXXXXXXXX
caso do CNPJ (ambos com
dígitos verificadores).
32
Segundo https://en.wikipedia.org/wiki/Universally_unique_identifier#Version_4_(random) a
possibilidade de colisão de um UUID versão 4 é muito baixa. Para obter 50% de chance de colisão,
é preciso 2,71 quintilhões de UUIDs gerados. Esse número é equivalente a gerar 1 bilhão de UUIDs
por segundo durante 85 anos. Um arquivo contendo todos esses UUIDs precisaria de 45 exabytes,
o que seria, atualmente, uma capacidade de armazenamento muito superior ao de todas as bases
de dados do mundo somadas.
33
https://www.itu.int/rec/T-REC-E.164-201011-I/en.
68
Deverá ser informado sem
pontos ou traços.
Endereço
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Número hexadecimal com
Virtual de
Exemplo: b6295ee1-f054-47d1-9e90- 32 posições. Deverá ser
Pagamento
ee57b74f60d9 34
informado sem pontuação.
(EVP)
Destaca-se que o DICT será construído de forma a permitir qualquer tipo de chave
alfanumérica, limitada apenas a um número máximo de caracteres. Portanto, é
possível que, a qualquer momento e por decisão do BC, que será o gestor do diretório,
novos formatos de chave para endereçamento, além dos quatro tipos apontados no
quadro acima, sejam adotados posteriormente.
2.6.2. Regras de acesso

O DICT sempre será consultado no caso de transferências entre diferentes instituições
que sejam iniciadas por meio da inserção manual dos dados pelo pagador, através do
uso de uma chave para endereçamento, ou por meio de um QR Code estático, tanto
aqueles gerados pelo recebedor quanto aqueles gerados pelo pagador.
Todos os participantes do PIX deverão oferecer todas as formas de iniciação de

pagamentos previstas. Nesse sentido, todos os participantes do PIX devem ser
capazes de consultar o DICT. Existem duas formas de ter acesso aos dados do DICT:
diretamente ou indiretamente. Os participantes do PIX que sejam participantes
diretos do SPI devem necessariamente acessar o DICT de forma direta. Os demais
participantes do PIX podem optar por ter acesso direto ao diretório ou por acessá-lo
por meio de qualquer participante que tenha acesso direto. Para ter acesso direto ao
DICT é necessário que o participante esteja conectado à RSFN, seja diretamente ou
por meio de um PSTI. Ou seja, o participante direto do SPI poderá se conectar ao DICT
diretamente ou por meio de um PSTI.
Os fluxos relacionados ao registro, à exclusão, à portabilidade, à reivindicação de

posse e à consulta de chaves para endereçamento no DICT são sujeitos a atendimento
de níveis de serviço determinados pelo BC, que realizará o monitoramento necessário.
Em caso de não cumprimento desses níveis de serviço, os PSPs estão sujeitos à
aplicação de sanções.
2.6.3. Fluxo de registro de chave
34
Apenas exemplo de formato. Número gerado em https://www.uuidgenerator.net/version4.
69
O registro de chaves inicia-se a partir de solicitação do usuário final. A inclusão da
chave será aceita pelo PSP desse usuário apenas após a confirmação de que o usuário
tem a posse dela, conforme detalhado na seção 2.6.1. No caso de CPF, CNPJ e EVP, não
é necessária a validação de posse pelo usuário final. Os PSPs podem ofertar a seus
clientes a possibilidade de inclusão de chaves no DICT. Contudo, essa inclusão só
poderá ser efetivada após o consentimento do usuário final.
É importante ressaltar a necessidade de atualização dos bancos de dados internos do

PSP do usuário que solicitou a inclusão da chave. Essa atualização deve ser feita
apenas após a confirmação de inclusão dos dados no DICT. Garante-se, assim, a
coerência de informações entre os bancos de dados internos do PSP e o DICT. O
registro de informações nos bancos de dados internos do PSP é necessário porque as
consultas de chaves em transações nas quais os usuários pagador e recebedor são
clientes do mesmo PSP não deverão ser encaminhadas ao DICT, conforme fluxos
discriminados na seção 2.6.7. Esse tipo de consulta, portanto, é feita nos bancos de
dados internos do próprio PSP35.
Um ponto importante a ser ressaltado é a possibilidade de portabilidade e de

reivindicação de posse das chaves que já estejam registradas no DICT 36. A
possibilidade de portabilidade permite que um determinado usuário, que tenha a
posse de uma determinada chave em um PSP possa levar essa chave para outro PSP
sem a necessidade de excluí-la do DICT. Nesse caso, o fluxo inicia-se por meio de um
pedido de registro no novo PSP, que pode levar à situação em que o novo PSP
pergunta ao usuário se ele deseja iniciar o processo de portabilidade. O fluxo de
portabilidade é detalhado na seção 2.6.5.
A possibilidade de reivindicação de posse permite que um determinado usuário

reivindique para si uma determinada chave, como um número de telefone celular, por
exemplo, que esteja registrada no DICT para outro CPF/CNPJ. Isso pode ocorrer em
casos em que o usuário perdeu a posse desse número de telefone celular (por falta
de recarga em um celular pré-pago, por exemplo), mas não excluiu essa chave do
DICT. Nesse caso, o fluxo inicia-se por meio de um pedido de registro no PSP, que
pode levar à situação em que o PSP pergunta ao usuário se ele deseja iniciar o
processo de reivindicação de posse. O fluxo de reivindicação de posse é detalhado na
seção 2.6.6.
O PSP do usuário final pode possuir acesso direto ao DICT ou realizar esse acesso por
meio de outro PSP que possua acesso direto ao diretório. Há, assim, dois fluxos de
35
Nessa situação, os mecanismos de segurança implementados pelos PSPs devem ser análogos aos
adotados pelo DICT para prevenção de ataques de leitura, conforme descrito na seção 2.6.10
36
Como detalhado na seção 2.6.1, não existe portabilidade nem reivindicação de posse para CPF,
CNPJ e EVP.
70
registro de chave: um para participantes com acesso direto e outro para participantes
com acesso indireto ao DICT.
Abaixo, os fluxos de registro de chave de endereçamento e as respectivas tabelas

detalhando as etapas envolvidas. Primeiro, o fluxo para PSP com acesso direto e, em
seguida, para PSP com acesso indireto ao DICT.

1 Usuário final Ação Início do processo. Usuário final acessa seu canal de atendimento.
Usuário final informa qual chave deseja cadastrar entre os três tipos
possíveis: CPF/CNPJ, e-mail e número de telefone celular. Usuário final
2 Usuário final Ação
solicita inclusão da chave. O PSP pode perguntar ao usuário final se
ele deseja incluir alguma chave no DICT.
Usuário final encaminha sua solicitação e os dados necessários a seu
3 Usuário final Comunicação
PSP.
PSP do usuário final recebe a solicitação de inclusão de chave no
4 PSP do usuário final Comunicação
DICT.
71
PSP faz validação da posse da chave pelo usuário final. O objetivo é
impedir a fraude de criação de chave de endereçamento com dados
de outras pessoas. No caso de CPF/CNPJ, a conferência é feita com o
CPF/CNPJ cadastrado no PSP, que é um dos itens obrigatórios para
5 PSP do usuário final Ação abertura de contas transacionais. Para e-mail e número de telefone
celular, deve haver validação ativa. Exemplificando, o PSP poderia
enviar um código de confirmação para o e-mail ou número de
telefone celular (via SMS) informado pelo usuário. Esse código seria
então inserido e validado em algum canal de acesso do PSP.
6 PSP do usuário final Mensagem Solicitação de inclusão de chave é encaminhada ao DICT.
7 DICT Mensagem DICT recebe mensagem com a solicitação de inclusão de chave.
DICT realiza verificações de conformidade:
i) instituição que solicitou a inclusão, ou seja, o PSP com acesso direto,
deve possuir autorização para realizar a inclusão de chaves de
endereçamento; e
8 DICT Ação ii) PSP vinculado à chave deve ser o mesmo PSP do usuário final que
solicitou a inclusão da chave. Com esse passo, evita-se que um PSP
realize inclusão de chave de endereçamento vinculada a uma conta
de outro PSP, o que poderia gerar fraude ou dificuldade de gestão
dos bancos de dados internos dos PSPs.
DICT verifica se a chave de endereçamento solicitada já está
9 DICT Ação
registrada no diretório.
Caso a chave solicitada não esteja registrada no DICT, efetua-se seu
cadastro, vinculando a chave a um PSP, a uma agência, ao número da
10 DICT Ação conta transacional, ao tipo da conta transacional e ao nome e
CPF/CNPJ do usuário final, conforme dados encaminhados pelo PSP
do usuário.
Caso a chave solicitada já esteja registrada no DICT, é criada
11 DICT Ação mensagem indicando registro para aquela chave, com os dados da
chave existente.
DICT envia mensagem de resposta ao PSP do usuário final,
12 DICT Mensagem informando o sucesso da inclusão ou a existência de chave já
registrada.
13 PSP do usuário final Mensagem PSP do usuário final recebe mensagem de resposta do DICT.
No caso de sucesso na inclusão, o PSP do usuário final atualiza sua
14 PSP do usuário final Ação base de dados interna com a chave e os dados do usuário vinculados
a ela.
72
PSP do usuário final pode encaminhar três comunicações para o
usuário final:
i) caso a chave tenha sido registrada com sucesso, é enviada
comunicação confirmando o registro da chave;
ii) caso a chave não tenha sido registrada e a chave esteja de posse
do mesmo CPF/CNPJ que solicitou seu registro, é enviada
comunicação indicando os dados da chave já registrada e
15 PSP do usuário final Comunicação perguntando se o usuário deseja efetuar portabilidade da chave;
ou
iii) caso a chave não tenha sido registrada e a chave esteja de posse
de CPF/CNPJ diferente daquele que solicitou seu registro, é
enviada comunicação indicando os dados da chave já registrada e
perguntando se o usuário deseja efetuar reivindicação de posse
da chave.
Usuário final recebe comunicação do seu PSP. Caso a chave tenha

sido registrada com sucesso, o fluxo é encerrado.
Usuário final envia comunicação ao seu PSP, caso o usuário decida
solicitar portabilidade ou reivindicação de posse.
PSP do usuário final recebe comunicação do usuário.
Caso o usuário escolha solicitar a portabilidade da chave, o fluxo de
18 PSP do usuário final Comunicação portabilidade é iniciado (ver seção 2.6.5).
Caso o usuário escolha solicitar a reivindicação da chave, o fluxo de
reivindicação de posse é iniciado (ver seção 2.6.6).
73
Início do processo. Usuário final acessa seu canal de
1 Usuário final Ação
atendimento.
Usuário final informa qual chave deseja cadastrar entre os
três tipos possíveis: CPF/CNPJ, e-mail e número de telefone
2 Usuário final Ação celular. Usuário final solicita inclusão da chave. O PSP pode
perguntar ao usuário final se ele deseja incluir alguma chave
no DICT.
Usuário final encaminha sua solicitação e os dados
necessários a seu PSP.
PSP do usuário final recebe a solicitação de inclusão de chave
no DICT.
74
PSP faz validação da posse da chave pelo usuário final. O
objetivo é impedir a fraude de criação de chave de
endereçamento com dados de outras pessoas. No caso de
CPF/CNPJ, a conferência é feita com o CPF/CNPJ cadastrado
no PSP, que é um dos itens obrigatórios para abertura de
5 PSP do usuário final Ação contas transacionais. Para e-mail e número de telefone
celular, deve haver validação ativa. Exemplificando, o PSP
poderia enviar um código de confirmação para o e-mail ou
número de telefone celular (via SMS) informado pelo usuário.
Esse código seria então inserido e validado em algum canal
de acesso do PSP.
Solicitação de inclusão de chave é encaminhada a PSP com
acesso direto ao DICT.
PSP com acesso direto ao DICT recebe comunicação com a
7 PSP com acesso ao DICT Comunicação
solicitação de inclusão de chave.
PSP com acesso direto encaminha mensagem com a
8 PSP com acesso ao DICT Mensagem
solicitação de inclusão de chave ao DICT.
DICT recebe mensagem com a solicitação de inclusão de
9 DICT Mensagem
chave.
i) instituição que solicitou a inclusão, ou seja, o PSP com
acesso direto, deve possuir autorização para realizar a
inclusão de chaves de endereçamento. O DICT deve,
inclusive, verificar se o PSP com acesso direto ao DICT tem
autorização para incluir chaves para o PSP sem acesso direto;
ii) PSP vinculado à chave deve ser o mesmo PSP do usuário
10 DICT Ação
final que solicitou a inclusão da chave. Com esse passo, evita-
se que um PSP realize inclusão de chave de endereçamento
vinculado a uma conta de outro PSP, o que poderia gerar
fraude ou dificuldade de gestão dos bancos de dados
internos dos PSPs; e
iii) PSP com acesso ao DICT tem permissão para efetuar
registros em nome do PSP do usuário.
DICT verifica se a chave de endereçamento solicitada já está
11 DICT Ação
registrada no diretório.
Caso a chave solicitada não esteja registrada no DICT, efetua-
se seu cadastro, vinculando a chave a um PSP, a uma
12 DICT Ação agência, ao número da conta transacional, ao tipo da conta
transacional e ao nome e CPF/CNPJ do usuário final,
conforme dados encaminhados pelo PSP do usuário.
Caso a chave solicitada já esteja registrada no DICT, é criada
13 DICT Ação mensagem indicando registro para aquela chave, com os
dados da chave existente.
75
DICT envia mensagem de resposta a PSP com acesso direto,
14 DICT Mensagem informando o sucesso da inclusão ou a existência de chave já
registrada.
PSP com acesso direto ao DICT recebe mensagem de
resposta.
PSP com acesso direto ao DICT envia comunicação ao PSP do
16 PSP com acesso ao DICT Comunicação usuário final, informando a inclusão ou a existência de chave
já registrada.
17 PSP do usuário final Comunicação PSP do usuário final recebe comunicação.
No caso de sucesso na inclusão, o PSP do usuário final
18 PSP do usuário final Ação atualiza sua base de dados interna com a chave e os dados
do usuário vinculados a ela.
PSP do usuário final pode encaminhar três comunicações
para o usuário final:
i) caso a chave tenha sido registrada com sucesso, é
enviada comunicação confirmando o registro da chave;
ii) caso a chave não tenha sido registrada e a chave esteja
de posse do mesmo CPF/CNPJ que solicitou seu registro,
é enviada comunicação indicando os dados da chave já
registrada e perguntando se o usuário deseja efetuar
portabilidade da chave; ou
iii) caso a chave não tenha sido registrada e a chave esteja
de posse de CPF/CNPJ diferente daquele que solicitou seu
registro, é enviada comunicação indicando os dados da
chave já registrada e perguntando se o usuário deseja
efetuar reivindicação de posse da chave.
Usuário final recebe comunicação do seu PSP. Caso a chave

tenha sido registrada com sucesso, o fluxo é encerrado.
Usuário final envia comunicação ao seu PSP, caso o usuário

decida solicitar portabilidade ou reivindicação de posse.
PSP do usuário final recebe comunicação do usuário.

Caso o usuário escolha solicitar a portabilidade da chave, o
22 PSP do usuário final Comunicação fluxo de portabilidade é iniciado (ver seção 2.6.6).
Caso o usuário escolha solicitar a reivindicação da chave, o
fluxo de reivindicação de posse é iniciado (ver seção 2.6.7).
2.6.4. Fluxo de exclusão de chave

Em geral, a exclusão da chave de endereçamento deve ser iniciada por solicitação do
usuário detentor da chave. Existem dois casos específicos em que o processo de
exclusão pode ser iniciado pelo PSP. A exclusão de chave de endereçamento é
obrigatória quando houver encerramento de vínculo entre usuário final e PSP. Nesse
76
caso, assim que houver a efetivação do encerramento do vínculo, o PSP deve criar e
enviar solicitação de exclusão de chave. O PSP também pode iniciar o processo de
exclusão em caso de tentativa ou efetivação do uso fraudulento da chave.
Para diminuir o risco de fraudes e assegurar a melhor gestão das chaves de

endereçamento, um usuário apenas poderá solicitar exclusão das chaves que ele
pediu inclusão, e um PSP somente poderá excluir chaves que ele incluiu.
Conforme destacado anteriormente, o PSP do usuário final pode possuir acesso direto
ao DICT ou realizar esse acesso por meio de outro PSP que possua acesso direto ao
diretório, gerando dois tipos de fluxos de exclusão. Além disso, para cada um desses
dois tipos de fluxo, há a possibilidade de exclusão por solicitação do usuário ou por
comando do PSP. Assim, há quatro fluxos de exclusão de chave de endereçamento,
conforme apresentado a seguir.
2.6.4.1. EXCLUSÃO POR SOLICITAÇÃO DO USUÁRIO

Fluxos referentes à exclusão de chave por solicitação do usuário, divididos em função
da existência ou não de acesso direto do PSP do usuário final ao DICT.

2 Usuário final Ação Usuário final solicita a exclusão de chave de endereçamento.
77
Usuário final encaminha sua solicitação e os dados necessários a seu
PSP.
PSP do usuário final recebe a solicitação de exclusão de chave de
endereçamento.
PSP verifica se a chave pertence ao usuário. Uma vez que apenas o
PSP em que o usuário possui conta transacional pode solicitar a
exclusão de chave vinculada a essa conta, o PSP, nessa etapa,
identifica se a chave que o usuário final solicitou excluir está
5 PSP do usuário final Ação
vinculada a esse usuário em seu banco de dados interno. Não se
trata, portanto, de verificação ativa de chave nessa etapa, mas apenas
de verificação de que o usuário que está solicitando a exclusão
corresponde ao usuário que solicitou sua inclusão.
6 PSP do usuário final Mensagem Solicitação de exclusão de chave é encaminhada ao DICT.
7 DICT Mensagem DICT recebe mensagem com a solicitação de exclusão de chave.
i) instituição que solicitou a exclusão deve ser a mesma que efetuou a
inclusão. Não é permitido que uma instituição solicite a exclusão de
8 DICT Ação chave incluída por outra instituição (ou seja, que esteja vinculada à
conta de outro PSP); e
ii) chave deve pertencer ao usuário que solicitou a exclusão. Usuários
não podem solicitar a exclusão de chave vinculada a outro usuário.
9 DICT Ação DICT exclui a chave de endereçamento de seu banco de dados.
DICT envia mensagem de confirmação da exclusão ao PSP do usuário
10 DICT Mensagem
final.
PSP do usuário final recebe comunicação informando a exclusão da
11 PSP do usuário final Mensagem
chave.
PSP do usuário final atualiza sua base de dados interna, excluindo a
chave.
13 PSP do usuário final Comunicação PSP do usuário final envia confirmação de exclusão da chave.
14 Usuário final Comunicação Usuário final recebe confirmação de exclusão da chave solicitada.
78
2 Usuário final Ação Usuário final solicita a exclusão de chave de endereçamento.
Usuário final encaminha sua solicitação e os dados necessários a
seu PSP.
PSP do usuário final recebe a solicitação de exclusão de chave de
endereçamento.
PSP verifica se a chave pertence ao usuário. Uma vez que apenas o
PSP em que o usuário possui conta transacional pode solicitar a
exclusão de chave vinculada a essa conta, o PSP, nessa etapa,
identifica se a chave que o usuário final solicitou excluir está
vinculada a esse usuário em seu banco de dados interno. Não se
trata, portanto, de verificação ativa de chave nessa etapa, mas
apenas de verificação de que o usuário que está solicitando a
exclusão corresponde ao usuário que solicitou sua inclusão.
79
Solicitação de exclusão de chave é encaminhada ao PSP com
acesso direto ao DICT.
solicitação de exclusão de chave.
PSP com acesso direto encaminha mensagem de solicitação de
exclusão de chave.
i) instituição que solicitou a exclusão deve ser a mesma que
efetuou a inclusão. Não é permitido que uma instituição solicite a
exclusão de chave incluída por outra instituição (ou seja, que
esteja vinculada à conta de outro PSP). O DICT deve inclusive
10 DICT Ação
verificar se o PSP com acesso direto tem autorização para excluir
chaves para o PSP sem acesso direto; e
ii) chave deve pertencer ao usuário que solicitou a exclusão.
Usuários não podem solicitar a exclusão de chave vinculada a
outro usuário.
DICT envia mensagem de confirmação da exclusão ao PSP com
12 DICT Mensagem
acesso direto.
PSP com acesso direto ao DICT recebe resposta da exclusão da
chave.
PSP com acesso direto ao DICT encaminha comunicação ao PSP do
usuário final, informando a exclusão da chave.
PSP do usuário final recebe comunicação informando a exclusão
da chave.
PSP do usuário final atualiza sua base de dados interna, excluindo
a chave.
2.6.4.2. EXCLUSÃO COMANDADA PELO PSP

Fluxos referentes à exclusão de chave em razão de encerramento de vínculo entre
usuário e PSP ou por confirmação pelo PSP de fraude, divididos em função da
existência ou não de acesso direto do PSP do usuário final ao DICT.
80
Vínculo do usuário com o PSP é encerrado ou uso (ou tentativa de
uso) fraudulento de conta transacional e/ou de chave é confirmado.
2 PSP do usuário final Mensagem Solicitação de exclusão de chave no diretório é enviada ao DICT.

DICT realiza verificação de conformidade: instituição que solicitou a
exclusão deve ser a mesma que efetuou a inclusão. Não é permitido
4 DICT Ação
que uma instituição solicite a exclusão de chave incluída por outra
instituição (ou seja, que esteja vinculada à conta de outro PSP).
DICT envia mensagem de confirmação da exclusão ao PSP do usuário
6 DICT Mensagem
final.
PSP do usuário final recebe comunicação informando a exclusão da
7 PSP do usuário final Mensagem
chave.
PSP do usuário final atualiza sua base de dados interna, excluindo a
chave.
81
Vínculo do usuário com o PSP é encerrado ou uso (ou tentativa de
1 PSP do usuário final Ação uso) fraudulento de conta transacional e/ou de chave é
confirmado.
Solicitação de exclusão de chave é encaminhada a PSP com acesso
direto ao DICT.
solicitação de exclusão de chave.
PSP com acesso direto encaminha mensagem de solicitação de
exclusão de chave.
82
DICT realiza verificações de que a instituição que solicitou a
exclusão é a mesma que efetuou a inclusão. Não é permitido que
uma instituição solicite a exclusão de chave incluída por outra
6 DICT Ação
instituição (ou seja, que esteja vinculada à conta de outro PSP). O
DICT deve inclusive verificar se o PSP com acesso direto tem
autorização para excluir chaves para o PSP sem acesso direto;
DICT envia mensagem de confirmação da exclusão ao PSP com
8 DICT Mensagem
acesso direto.
PSP com acesso direto ao DICT recebe resposta da exclusão da
chave.
PSP com acesso direto ao DICT encaminha comunicação ao PSP do
usuário final, informando a exclusão da chave.
PSP do usuário final recebe comunicação informando a exclusão
da chave.
PSP do usuário final atualiza sua base de dados interna, excluindo
a chave.
2.6.5. Fluxo de portabilidade

A portabilidade tem como objetivo facilitar o processo de vinculação de chaves nos
casos em que o usuário muda o PSP em que ele possui conta transacional 37. O fluxo
de portabilidade é iniciado pelo usuário final após receber comunicação do seu PSP
de que a chave que foi solicitada para ser incluída já estava registrada no DICT. Nesse
caso, o registro anterior foi realizado pelo próprio usuário final.
Nos fluxos, identifica-se como PSP reivindicador aquele PSP no qual o usuário possui
conta transacional e solicita o registro da chave. O PSP doador é aquele PSP no qual a
chave está originalmente registrada. Os fluxos do PSP reivindicador e do PSP doador
são apresentados de forma separada a fim de facilitar o processo de entendimento.
Subfluxo de portabilidade para o PSP reivindicador com acesso direto ao DICT:
37
Tanto a portabilidade quanto a reivindicação de posse estão restritas ao número de telefone
celular e ao e-mail. CPF, CNPJ e EVP não estão sujeitos a esses processos.
83
O processo é iniciado, conforme fluxos da seção 2.6.3, após a
detecção de que já existe registro para a chave solicitada e depois
1 PSP reivindicador Mensagem
do pedido do usuário. O PSP reivindicador envia, então, pedido de
portabilidade ao DICT.
DICT recebe o pedido de portabilidade encaminhado pelo PSP
2 DICT Mensagem
reivindicador.
DICT cria um pedido de portabilidade com status “Aberto”, com os
3 DICT Ação dados da chave e do PSP reivindicador, e inicia a contagem da
quarentena.
84
Uma vez recebida a confirmação ou o cancelamento da
portabilidade do PSP doador, o DICT atualiza o status do pedido da
portabilidade para "Cancelado" ou para "Confirmado", conforme
ação do usuário. Caso o status seja "Cancelado", o DICT altera o
status do pedido para “Encerrado”.
4 DICT Ação
Caso tenha ocorrido a confirmação do PSP doador sobre a
portabilidade, a chave deve ser bloqueada pelo DICT até o
recebimento da confirmação pelo PSP reivindicador. O bloqueio da
chave significa que as consultas ao DICT com essa chave retornarão
mensagem de erro.
Após o envio do pedido de portabilidade, o PSP reivindicador

5 PSP reivindicador Ação periodicamente consulta o DICT sobre o status do pedido, até que
ele seja igual a "Cancelado" ou "Confirmado"38.
Caso o status do pedido seja "Confirmado", o PSP reivindicador

6 PSP reivindicador Ação atualiza seu banco de dados interno com os novos dados da chave,
conforme solicitado pelo usuário final.
Após a atualização do banco de dados interno, o PSP reivindicador

7 PSP reivindicador Mensagem confirma ao DICT a conclusão do processo e a atualização da chave
em seu banco de dados.
8 DICT Mensagem DICT recebe a informação de conclusão da portabilidade.
DICT atualiza a base de endereçamento com os novos dados da
9 DICT Ação
chave e altera o status do pedido de portabilidade para “Encerrado”.
PSP reivindicador informa o usuário final sobre o cancelamento ou
10 PSP reivindicador Comunicação
a confirmação do pedido de portabilidade da chave.
Usuário final recebe a informação de conclusão ou de cancelamento
da portabilidade da chave.
Subfluxo de portabilidade para o PSP reivindicador sem acesso direto ao DICT:
38
A periodicidade dessas consultas será definida oportunamente.
85
86
portabilidade ao PSP com acesso direto ao DICT.
PSP com acesso

2 Comunicação PSP com acesso direto ao DICT recebe pedido de portabilidade.
direto ao DICT
PSP com acesso

3 Mensagem PSP com acesso direto ao DICT encaminha pedido de portabilidade.
direto ao DICT
DICT recebe o pedido de portabilidade encaminhado pelo PSP

4 DICT Mensagem
reivindicador.
DICT cria um pedido de portabilidade com status “Aberto”, com os
5 DICT Ação dados da chave e do PSP reivindicador, e inicia a contagem da
quarentena.
6 DICT Ação
mensagem de erro.
Após o envio do pedido de portabilidade, o PSP com acesso direto

PSP com acesso
7 Ação periodicamente consulta o DICT sobre o status do pedido, até que
direto ao DICT
ele seja igual a "Cancelado" ou "Confirmado".
PSP com acesso Assim que identifica mudança no status do pedido, o PSP com
8 Comunicação
direto ao DICT acesso direto envia comunicação ao PSP reivindicador.
PSP reivindicador recebe comunicação do PSP com acesso direto

informando mudança no status do pedido.

87
11 PSP reivindicador Comunicação confirma ao PSP com acesso direto ao DICT a conclusão do
processo e a atualização da chave em seu banco de dados.
PSP com acesso PSP com acesso direto recebe confirmação de conclusão de
12 Comunicação
direto ao DICT atualização de chaves do PSP reivindicador.
PSP com acesso PSP com acesso direto encaminha confirmação de conclusão de
13 Mensagem
14 DICT Mensagem DICT recebe a informação de conclusão da portabilidade.

15 DICT Ação
chave e altera o status do pedido de portabilidade para “Encerrado”.
a confirmação do pedido de portabilidade da chave.
da portabilidade da chave.
Subfluxo de portabilidade para o PSP doador com acesso direto ao DICT:
88
89
Periodicamente, o PSP doador faz consultas ao DICT a fim de verificar a
1 PSP doador Ação existência de portabilidade com status “Aberto” que se referem a chaves
registradas por ele39.
Assim que identifica portabilidade com status “Aberto”, PSP doador envia
Mensagem/
2 PSP doador mensagem ao DICT e notifica o usuário final40, explicando a necessidade
Comunicação
de confirmação da solicitação.
3 DICT Mensagem DICT recebe mensagem do PSP doador.
DICT muda status do pedido para “Aguardando Resolução” e fica

4 DICT Ação aguardando o recebimento de informação sobre o processo de
portabilidade.
5 Usuário final Comunicação Usuário final recebe notificação do PSP doador.
6 Usuário final Ação Usuário final pode cancelar ou confirmar a portabilidade.
7 Usuário final Comunicação Usuário final envia comunicação ao PSP doador.
8 PSP doador Comunicação PSP doador recebe comunicação do usuário.
Caso o usuário responda solicitando o cancelamento da portabilidade, o

PSP avança para a etapa 12.
9 PSP doador Ação Caso o usuário responda solicitando a confirmação da portabilidade, o
PSP doador remove a chave de sua base interna de dados, uma vez que
não deverá mais ser utilizada para transações internas.
Caso a chave tenha sido excluída da base interna, o PSP doador comunica
o usuário final sobre a exclusão de sua chave, a fim de que ele fique ciente
10 PSP doador Comunicação de que não mais deverá utilizar essa identificação nos pagamentos
instantâneos, até receber a informação de que a chave foi atualizada no
PSP reivindicador.
Usuário final recebe a informação de que sua chave foi excluída e não
mais apontará para sua conta transacional no PSP doador.
PSP doador informa o DICT sobre a conclusão do processo, informando o
12 PSP doador Mensagem
cancelamento ou a confirmação da portabilidade, conforme o caso.
DICT recebe a informação de remoção da chave e continua o processo de

13 DICT Mensagem portabilidade (etapa 4 do fluxo de portabilidade do PSP reivindicador com
acesso direto)
39
40
A fim de minimizar potenciais fraudes, como aquelas decorrentes da troca de chips por
fraudadores (SIM swap), recomenda-se que seja evitada a comunicação por meio de SMS ou de
chamadas telefônicas.
90
Subfluxo de portabilidade para o PSP doador sem acesso direto ao DICT:
91
Periodicamente, o PSP com acesso direto faz consultas ao DICT a fim de
PSP com acesso
1 Ação verificar a existência de portabilidade com status “Aberto” que se referem
direto ao DICT
a chaves registradas pelo PSP doador que ele presta serviços.
PSP com acesso Mensagem/ Assim que identifica portabilidade com status “Aberto”, PSP com acesso
2
direto ao DICT Comunicação direto envia mensagem ao DICT e comunicação ao PSP doador.

portabilidade.
5 PSP doador Comunicação PSP doador recebe comunicação do PSP com acesso direto
PSP doador notifica o usuário final41, explicando a necessidade de

6 PSP doador Comunicação
confirmação da solicitação.
7 Usuário final Comunicação Usuário final recebe notificação do PSP doador.
8 Usuário final Ação Usuário final pode cancelar ou confirmar a portabilidade.
9 Usuário final Comunicação Usuário final envia comunicação ao PSP doador.
Caso o usuário responda solicitando o cancelamento da portabilidade, o

PSP avança para a etapa 14.
11 PSP doador Ação Caso o usuário responda solicitando a confirmação da portabilidade, o
PSP doador remove a chave de sua base interna de dados, uma vez que
não deverá mais ser utilizada para transações internas.
Caso a chave tenha sido excluída da base interna, o PSP doador comunica
o usuário final sobre a exclusão de sua chave, a fim de que ele fique ciente
12 PSP doador Comunicação de que não mais deverá utilizar essa identificação nos pagamentos
instantâneos, até receber a informação de que a chave foi atualizada no
PSP reivindicador.
Usuário final recebe a informação de que sua chave foi excluída e não
mais apontará para sua conta transacional no PSP doador.
PSP doador informa PSP com acesso direto sobre o cancelamento ou a
confirmação da portabilidade.
PSP com acesso
15 Comunicação PSP com acesso direto recebe informação.
direto
41
92
PSP com acesso direto informa o DICT sobre a conclusão do processo,
PSP com acesso
16 Mensagem informando o cancelamento ou a confirmação da portabilidade, conforme
direto
o caso.
DICT recebe a informação de remoção da chave e continua o processo de
17 DICT Mensagem portabilidade (etapa 4 do fluxo de portabilidade do PSP reivindicador com
acesso direto)
Caso o PSP doador não informe o cancelamento ou a confirmação da portabilidade

em até sete dias, que é o período estabelecido para a quarentena, o DICT irá entrar
em contato com o PSP doador (ou com o PSP com acesso direto ao DICT), por meio de
procedimento manual a ser oportunamente definido, solicitando a atualização da
base de dados interna e o envio da informação. A falta de comunicação do PSP doador
no período de quarentena constitui infração do regulamento do PIX, estando a
instituição infratora sujeita às sanções previstas.
Durante o processo de portabilidade, a partir do momento em que o DICT coloca o

status do pedido em “Aberto” até o momento em que o DICT troca o status para
“Encerrado”, a chave para endereçamento não está passível de pedidos de registro e
de exclusão. As consultas continuarão retornando normalmente a identificação da
conta transacional originalmente vinculada à chave. Enquanto o status do pedido
estiver com o status “Aguardando Resolução”, tanto o PSP reivindicador quanto o PSP
doador poderão cancelar o pedido, desde que solicitado pelo usuário ou em caso de
suspeita de fraude.
Alternativamente à portabilidade, o usuário final pode optar por excluir a chave para
endereçamento vinculada a uma conta transacional em seu PSP original para depois
registrar essa mesma chave em um novo PSP. Nessa opção, o usuário final deve seguir
primeiro o fluxo de exclusão exposto na seção 2.6.4. e, em seguida, o fluxo de registro
explicado na seção 2.6.3. O efeito prático é o mesmo. A principal vantagem dessa
segunda opção é a maior velocidade para a mudança da conta transacional vinculada
a uma determinada chave, que depende apenas de ações do usuário final. A vantagem
do fluxo de portabilidade é permitir que o usuário final acione apenas o seu novo PSP,
não precisando acessar ativamente nenhum canal de atendimento do PSP original.
2.6.6. Fluxo de reivindicação de posse

A reivindicação de posse tem como objetivo permitir que um determinado usuário
reivindique para si uma chave que esteja vinculada a outro usuário. O fluxo de
reivindicação é iniciado pelo usuário final após receber comunicação do seu PSP de
que a chave que foi solicitada para ser incluída já estava registrada no DICT. Nesse
caso, o registro anterior foi realizado por outro usuário final.
Nos fluxos, identifica-se como PSP reivindicador aquele PSP no qual o usuário possui
conta transacional e solicita o registro da chave. O PSP doador é aquele PSP no qual a
93
chave está originalmente registrada. Os fluxos do PSP reivindicador e do PSP doador
são apresentados de forma separada a fim de facilitar o processo de entendimento.
Subfluxo de reivindicação de posse para o PSP reivindicador com acesso direto ao

DICT:

1 PSP reivindicador Mensagem
reivindicação de posse ao DICT.
DICT recebe o pedido de reivindicação de posse encaminhado pelo
2 DICT Mensagem
PSP reivindicador.
94
DICT cria um pedido de reivindicação de posse com status “Aberto”,
3 DICT Ação com os dados da chave e do PSP reivindicador, e inicia a contagem
da quarentena.
reivindicação de posse do PSP doador, o DICT atualiza o status do
pedido da reivindicação de posse para "Cancelado" ou para
"Confirmado", conforme ação do usuário final que registrou a chave
originalmente. Caso o status seja "Cancelado", o DICT altera o status
4 DICT Ação do pedido para “Encerrado”.
reivindicação de posse, a chave deve ser bloqueada pelo DICT até o
mensagem de erro.
Após o envio do pedido de reivindicação de posse, o PSP
5 PSP reivindicador Ação reivindicador periodicamente consulta o DICT sobre o status do
pedido, até que ele seja igual a "Cancelado" ou "Confirmado


7 PSP reivindicador Mensagem confirma ao DICT a conclusão do processo e a atualização da chave
em seu banco de dados.
8 DICT Mensagem DICT recebe a informação de conclusão da reivindicação de posse.
9 DICT Ação chave e altera o status do pedido de reivindicação de posse para
“Encerrado”.
a confirmação do pedido de reivindicação de posse da chave.
da reivindicação de posse da chave.
Subfluxo de reivindicação de posse para o PSP reivindicador sem acesso direto ao

DICT:
95
96
reivindicação de posse ao PSP com acesso direto ao DICT.
PSP com acesso PSP com acesso direto ao DICT recebe pedido de reivindicação de
2 Comunicação
direto ao DICT posse.
PSP com acesso PSP com acesso direto ao DICT encaminha pedido de reivindicação
3 Mensagem
direto ao DICT de posse.
DICT recebe o pedido de reivindicação de posse encaminhado pelo

4 DICT Mensagem
PSP reivindicador.
DICT cria um pedido de reivindicação de posse com status “Aberto”,
5 DICT Ação com os dados da chave e do PSP reivindicador, e inicia a contagem
da quarentena.
6 DICT Ação
mensagem de erro.
Após o envio do pedido de reivindicação de posse, o PSP com

PSP com acesso
7 Ação acesso direto consulta o DICT sobre o status do pedido, até que ele
direto ao DICT
seja igual a "Cancelado" ou "Confirmado”.
PSP com acesso PSP com acesso direto envia comunicação ao PSP reivindicador
8 Comunicação
direto ao DICT informando status do pedido.
PSP reivindicador recebe comunicação do PSP com acesso direto

informando o status do pedido.

97
11 PSP reivindicador Comunicação confirma ao PSP com acesso direto ao DICT a conclusão do
processo e a atualização da chave em seu banco de dados.
PSP com acesso PSP com acesso direto recebe confirmação de conclusão de
12 Comunicação
PSP com acesso PSP com acesso direto encaminha confirmação de conclusão de
13 Mensagem
14 DICT Mensagem DICT recebe a informação de conclusão da reivindicação de posse.

15 DICT Ação chave e altera o status do pedido de reivindicação de posse para
“Encerrado”.
a confirmação do pedido de reivindicação de posse da chave.
da reivindicação de posse da chave.
Subfluxo de reivindicação de posse para o PSP doador com acesso direto ao DICT:
98
Periodicamente, o PSP doador faz consultas ao DICT a fim de verificar

1 PSP doador Ação a existência de reivindicação de posse com status “Aberto” que se
referem a chaves registradas por ele42.
Assim que identifica reivindicação de posse com status “Aberto”, PSP
Mensagem/ doador envia mensagem ao DICT e notifica o usuário final que
2 PSP doador
Comunicação registrou a chave originalmente 43, explicando a necessidade de
revalidação da posse da chave objeto de reivindicação.
42
43
99

reivindicação de posse.
Usuário final que
5 registrou a chave Comunicação Usuário final recebe notificação do PSP doador.
originalmente
Usuário final deve fazer validação ativa da posse da chave. O sucesso
Usuário final que
da validação ativa implica em cancelamento do processo de
6 registrou a chave Ação
reivindicação de posse. O fracasso da validação ativa implica em
originalmente
confirmação do processo de reivindicação de posse.
Usuário final que
7 registrou a chave Comunicação Usuário final envia comunicação ao PSP doador.
originalmente
Caso o usuário final que registrou a chave originalmente faça a

validação ativa da chave, o PSP avança para a etapa 12.
Caso não obtenha sucesso na validação da posse ou o período de
9 PSP doador Ação quarentena tenha encerrado (sete dias), o PSP doador remove a
chave de sua base interna, para garantir sincronia com o DICT e
evitar que sejam realizadas transações equivocadas dentro da
instituição.
Caso a chave tenha sido excluída da base interna, o PSP doador
comunica o usuário final sobre a exclusão de sua chave, a fim de que
ele fique ciente de que não mais deverá utilizar essa identificação nos
pagamentos instantâneos.
Usuário final que
Usuário final recebe a informação de que sua chave foi excluída e
11 registrou a chave Comunicação
não mais apontará para sua conta transacional no PSP doador.
originalmente
PSP doador informa o DICT sobre a conclusão do processo:
i) em caso de sucesso na validação de posse, o PSP doador informa o
cancelamento da reivindicação de posse; ou
12 PSP doador Mensagem
ii) caso não obtenha sucesso na validação da posse da chave pelo seu
usuário, o PSP doador informa a confirmação da reivindicação de
posse.
DICT recebe a informação de cancelamento ou de confirmação da
reivindicação de posse e continua o processo de reivindicação (etapa
13 DICT Mensagem
4 do fluxo de reivindicação de posse do PSP reivindicador com acesso
direto).
100
Subfluxo de reivindicação de posse para o PSP doador sem acesso direto ao DICT:
101
Periodicamente, o PSP com acesso direto faz consultas ao DICT a fim
PSP com acesso
1 Ação de verificar a existência de reivindicação de posse com status
direto ao DICT
“Aberto” que se referem a chaves registradas pelo PSP doador44.
Assim que identifica reivindicação de posse com status “Aberto”, PSP
PSP com acesso Mensagem/
2 doador envia mensagem ao DICT e comunicação ao PSP doador,
direto ao DICT Comunicação
informando existência de reivindicação de posse.
3 DICT Mensagem DICT recebe mensagem do PSP com acesso direto.

5 PSP doador Comunicação PSP doador recebe comunicação.
PSP doador envia notificação ao usuário final que registrou a chave

6 PSP doador Comunicação originalmente45, explicando a necessidade de revalidação da posse da
chave objeto de reivindicação.
Usuário final que
7 registrou a chave Comunicação Usuário final recebe notificação do PSP doador.
originalmente
Usuário final deve fazer validação ativa da posse da chave. O sucesso
Usuário final que
da validação ativa implica em cancelamento do processo de
8 registrou a chave Ação
reivindicação de posse. O fracasso da validação ativa implica em
originalmente
confirmação do processo de reivindicação de posse.
Usuário final que
9 registrou a chave Comunicação Usuário final envia comunicação ao PSP doador.
originalmente
Caso o usuário final que registrou a chave originalmente faça a

validação ativa da chave, o PSP avança para a etapa 14.
11 PSP doador Ação
Caso não obtenha sucesso na validação da posse ou o período de
quarentena tenha encerrado (sete dias), o PSP doador remove a
44
Ou seja, além de verificar as chaves que foram registradas por ele, o PSP com acesso direto
também deve verificar as chaves vinculadas aos PSPs para os quais ele presta serviço de liquidação
e de acesso ao DICT.
45
102
chave de sua base interna, para garantir sincronia com o DICT e
evitar que sejam realizadas transações equivocadas dentro da
instituição.
Caso a chave tenha sido excluída da base interna, o PSP doador
comunica o usuário final sobre a exclusão de sua chave, a fim de que
ele fique ciente de que não mais deverá utilizar essa identificação nos
pagamentos instantâneos.
Usuário final que
Usuário final recebe a informação de que sua chave foi excluída e
13 registrou a chave Comunicação
não mais apontará para sua conta transacional no PSP doador.
originalmente
PSP doador envia comunicação ao PSP com acesso direto,
informando resultado do processo de reivindicação de posse.
PSP com acesso
15 Comunicação PSP com acesso direto recebe comunicação.
direto ao DICT
PSP com acesso direto informa o DICT sobre a conclusão do
processo:
i) em caso de sucesso na validação de posse, o PSP com acesso direto
PSP com acesso
16 Mensagem informa o cancelamento da reivindicação de posse; ou
direto ao DICT
ii) caso não obtenha sucesso na validação da posse da chave pelo
usuário que registrou a chave originalmente, o PSP com acesso direto
informa a confirmação da reivindicação de posse.
DICT recebe a informação de cancelamento ou de confirmação da
reivindicação de posse e continua o processo de reivindicação (etapa
17 DICT Mensagem
4 do fluxo de reivindicação de posse do PSP reivindicador com acesso
direto).
Assim como no caso da portabilidade, caso o PSP doador não informe o cancelamento
ou a confirmação da reivindicação de posse em até sete dias, que é o período
estabelecido para a quarentena, o DICT irá entrar em contato com o PSP doador (ou
com o PSP com acesso direto ao DICT), por meio de procedimento manual a ser
oportunamente definido, solicitando a atualização da base de dados interna e o envio
da informação. A falta de comunicação do PSP doador no período de quarentena
constitui infração do regulamento do PIX, estando a instituição infratora sujeita às
sanções previstas.
Durante o processo de reivindicação de posse, a partir do momento em que o DICT

coloca o status do pedido em “Aberto” até o momento em que o DICT troca o status
para “Encerrado”, a chave para endereçamento não está passível de pedidos de
registro e de exclusão. As consultas continuarão retornando normalmente a
identificação da conta transacional originalmente vinculada à chave. Enquanto o
status do pedido estiver com o status “Aguardando Resolução”, tanto o PSP
reivindicador quanto o PSP doador poderão cancelar o pedido, desde que solicitado
pelo usuário ou em caso de suspeita de fraude.
103
2.6.7. Fluxo de consulta de chave
Consultas ao DICT deverão ser feitas com o propósito único e exclusivo de iniciar
pagamentos. Ou seja, o processo se inicia após a leitura de QR Code estático ou a
inserção manual de chave de endereçamento pelo usuário pagador.
Abaixo, os fluxos de consulta de chave de endereçamento e as respectivas tabelas

detalhando as etapas envolvidas. Primeiro, o fluxo para PSPs com acesso direto e, em
seguida, o fluxo para PSPs sem acesso direto ao DICT.

Início do processo. Usuário pagador acessa seu canal de
atendimento.
Usuário pagador realiza input dos dados do pagamento, por
meio de sua inserção manual ou por meio de leitura de QR Code
104
estático. Esses dados referem-se a algum dos três tipos de chave
de endereçamento existentes.
Usuário pagador encaminha sua solicitação e os dados

4 PSP do usuário pagador Comunicação PSP do usuário pagador recebe dados de pagamento.
PSP verifica se a chave está cadastrada em seu banco de dados
5 PSP do usuário pagador Ação interno, a fim de identificar se a transação está ocorrendo entre
usuários finais que são ambos seus clientes.
Caso a chave esteja cadastrada em seu banco de dados interno,
o PSP cria mensagem de resposta, contendo a chave consultada,
6 PSP do usuário pagador Ação o PSP, a agência, o número da conta transacional, o tipo da conta
transacional e o nome e CPF/CNPJ vinculados à chave. Após,
segue-se direto para a etapa 15.
Caso a chave não esteja em seu banco de dados interno, o PSP
do usuário pagador envia mensagem de consulta ao DICT, na
qual deve informar, além da chave de endereçamento, o
7 PSP do usuário pagador Mensagem
identificador único da transação que será utilizado na mensagem
de liquidação46. Outra informação que deverá ser enviada é um
identificador pseudonimizado do usuário pagador47.
8 DICT Mensagem DICT recebe mensagem com solicitação de consulta.
9 DICT Ação DICT verifica se a instituição é autorizada a realizar consultas.
DICT verifica se a chave está cadastrada em seu banco de
10 DICT Ação
dados48.
Caso a chave esteja cadastrada, o DICT cria mensagem de
resposta contendo a chave consultada, o PSP, a agência, o
número da conta transacional, o tipo da conta transacional e o
11 DICT Ação nome e CPF/CNPJ vinculados à chave. Além disso, o DICT
também incluirá na resposta a data de criação do vínculo na
base de endereçamento e o tempo de validade do vínculo para
fins de cache.
46
Esse identificador único corresponde ao campo EndToEndId, que é um campo obrigatório da
mensagem de liquidação PACS.008. Ele deverá ser gerado pelo PSP e transmitido durante a
operação de consulta e novamente na PACS.008. As regras de formação desse campo serão
definidas no âmbito do catálogo de mensagens ISO 20022 para o SPI.
47
Essa informação será utilizada pelo DICT como um mecanismo de segurança. Ver detalhes na
seção 2.6.10.
48
Caso o PSP que realiza a consulta seja o mesmo PSP para o qual a chave aponta, o DICT irá rejeitar
a consulta e retornar mensagem de erro, uma vez que consultas referentes a transações dentro de
uma mesma instituição devem ser resolvidas pelo próprio PSP.
105
Caso a chave não esteja cadastrada, o DICT cria mensagem
12 DICT Ação
informando a inexistência da chave consultada.
DICT envia mensagem de resposta à consulta, contendo os
13 DICT Mensagem dados vinculados à chave ou informação de sua inexistência no
diretório.
PSP do usuário final recebe mensagem com a resposta à
14 PSP do usuário pagador Mensagem
consulta.
PSP do usuário final encaminha resposta à consulta contendo
somente, e tão somente, a chave de endereçamento, o nome, o
15 PSP do usuário pagador Comunicação
CPF (com máscara49)/CNPJ e o PSP vinculados à chave ou a
informação de que a chave não existe no diretório.
16 Usuário pagador Comunicação Usuário final recebe mensagem de resposta à sua consulta.
49
A máscara do CPF deverá ser do tipo 111.***.***-11 (substitui os números do meio por
asteriscos).
106
Início do processo. Usuário pagador acessa seu canal de
atendimento.
Usuário pagador realiza input dos dados do pagamento, por
meio de sua inserção manual ou por meio de leitura de QR Code
estático. Esses dados referem-se a algum dos três tipos de chave
de endereçamento existentes.
Usuário pagador encaminha sua solicitação e os dados
4 PSP do usuário pagador Comunicação PSP do usuário pagador recebe dados de pagamento.
PSP verifica se a chave está cadastrada em seu banco de dados
5 PSP do usuário pagador Ação
interno.
107
Caso a chave esteja cadastrada em seu banco de dados interno,
o PSP cria mensagem de resposta, contendo a chave consultada,
6 PSP do usuário pagador Ação o PSP, a agência, o número da conta transacional, o tipo da conta
transacional e o nome e CPF/CNPJ vinculados à chave. Após,
segue-se direto para a etapa 19.
Caso a chave não esteja em seu banco de dados interno, o PSP
do usuário pagador envia comunicação, ao PSP com acesso
direto ao DICT, solicitando consulta ao DICT, na qual deve
informar a chave de endereçamento.
solicitação de consulta à chave.
PSP com acesso direto ao DICT encaminha mensagem com
solicitação de consulta. A mensagem deve conter, além da chave
de endereçamento, o identificador único da transação que será
utilizado na mensagem de liquidação. Outra informação que
deverá ser enviada é um identificador pseudonimizado do
usuário pagador.
10 DICT Mensagem DICT recebe mensagem com solicitação de consulta.
DICT verifica se a instituição é autorizada a realizar consultas. O
11 DICT Ação DICT deve inclusive verificar se o PSP com acesso direto tem
autorização para consultar chaves para o PSP sem acesso direto.
12 DICT Ação DICT verifica se a chave está cadastrada em seu banco de dados.
Caso a chave esteja cadastrada, o DICT cria mensagem de
resposta contendo a chave consultada, o PSP, a agência, o
número da conta transacional, o tipo da conta transacional e o
13 DICT Ação nome e CPF/CNPJ vinculados à chave. Além disso, o DICT
também incluirá na resposta a data de criação do vínculo na
base de endereçamento e o tempo de validade do vínculo para
fins de cache.
Caso a chave não esteja cadastrada, o DICT cria mensagem
14 DICT Ação
informando a inexistência da chave consultada.
DICT envia mensagem de resposta à consulta, contendo os
15 DICT Mensagem dados vinculados à chave ou informação de sua inexistência no
diretório.
16 PSP com acesso ao DICT Mensagem PSP com acesso direto ao DICT recebe resposta da consulta.
PSP com acesso direto ao DICT comunica ao PSP do usuário final
a resposta da consulta.
PSP do usuário final recebe comunicação sobre a resposta à
consulta.
PSP do usuário final encaminha resposta à consulta contendo
somente, e tão somente, a chave de endereçamento, o nome, o
CPF (com máscara)/CNPJ e o PSP vinculados à chave ou a
informação de que a chave não existe no diretório.
108
20 Usuário pagador Comunicação Usuário final recebe mensagem de resposta à sua consulta.
2.6.8. Processo de pesquisa de chaves

Será possível que tanto os PSPs pesquisem as chaves cadastradas por eles no DICT
quanto que os usuários finais pesquisem todas as suas chaves cadastradas no DICT.
No caso da pesquisa pelos PSPs, o objetivo da funcionalidade é facilitar o processo de
conciliação de dados entre a base do DICT e a base interna de cada PSP.
2.6.8.1. PESQUISA DE CHAVES PELOS PSPS PARA CONCILIAÇÃO DE

DADOS
O PSP deve possuir uma base de dados interna na qual armazena as chaves de seus
usuários, a fim de que, em transações liquidadas nos livros do próprio PSP, a consulta
da chave seja realizada sem necessidade de comunicação com o DICT.
Para se evitar transferências utilizando chaves desatualizadas, é essencial a sincronia

entre as bases internas dos PSPs e o DICT. Nesse sentido, o fluxo de pesquisa de
chaves para conciliação permite que o PSP obtenha a lista de todas as chaves
cadastradas por ele no DICT e verifique se as informações associadas a cada chave
estão íntegras. A verificação da integridade será feita por funções de resumo
criptográfico. As inconsistências eventualmente identificadas poderão ser corrigidas
com a utilização dos fluxos normais de consulta, de exclusão e de registro de chaves.
A seguir os fluxos de pesquisa de chaves, divididos de acordo com o tipo de acesso ao

DICT. Primeiro, é apresentado o fluxo do PSP com acesso direto ao DICT. Em seguida,
o fluxo do PSP com acesso indireto:
109
PSP com acesso direto
1 Ação PSP acessa canal de comunicação com o DICT.
ao DICT
PSP com acesso direto Solicitação de pesquisa das chaves do PSP no DICT é enviada ao
2 Mensagem
ao DICT DICT.
DICT recebe mensagem com a solicitação de pesquisa das chaves do
3 DICT Mensagem
PSP com acesso direto.
DICT realiza consulta em seu banco de dados e lista todas as chaves

4 DICT Ação ativas cadastradas pelo PSP. A lista das chaves com seus resumos
criptográficos é, então, enviada.
5 DICT Mensagem DICT envia lista das chaves ao PSP com acesso direto.
PSP com acesso direto
6 Mensagem PSP com acesso direto recebe lista de suas chaves ativas no DICT.
ao DICT
110
PSP sem acesso direto acessa canal de comunicação
1 PSP sem acesso direto ao DICT Ação
com o PSP com acesso direto ao DICT.
PSP sem acesso direto solicita pesquisa de suas
2 PSP sem acesso direto ao DICT Comunicação
chaves no DICT.
PSP com acesso direto ao DICT recebe comunicação
3 PSP com acesso ao DICT Comunicação com a solicitação de pesquisa das chaves do PSP sem
acesso direto.
PSP com acesso direto encaminha mensagem de
4 PSP com acesso ao DICT Mensagem solicitação de pesquisa das chaves do PSP sem acesso
direto.
DICT recebe mensagem com a solicitação de pesquisa
5 DICT Mensagem
das chaves do PSP sem acesso direto.
111
O DICT deve verificar se o PSP com acesso direto tem
6 DICT Ação autorização para encaminhar solicitações para o PSP
sem acesso direto.
DICT realiza consulta em seu banco de dados e lista

7 DICT Ação todas as chaves ativas cadastradas pelo PSP sem
acesso ao DICT. A lista das chaves com seus resumos
criptográficos é, então, enviada.
8 DICT Mensagem DICT envia lista das chaves ao PSP com acesso direto.
9 PSP com acesso ao DICT Mensagem PSP com acesso direto recebe lista de chaves.
PSP com acesso direto encaminha lista de chaves ao
PSP sem acesso direto.
PSP sem acesso direto recebe lista de suas chaves
11 PSP sem acesso direto ao DICT Comunicação
ativas no DICT.
2.6.8.2. PESQUISA DE CHAVES PELOS USUÁRIOS FINAIS

Os usuários finais poderão obter todas as suas chaves cadastradas no DICT por meio
do Registrato50.
2.6.9. Disponibilidade das funcionalidades

As consultas ao DICT estarão disponíveis aos participantes do PIX 24 horas por dia,
sete dias por semana e em todos os dias do ano. As outras funcionalidades, por não
serem críticas e para minimizar as tentativas de fraude, terão uma disponibilidade
menor. O registro, a exclusão, a portabilidade e a reivindicação de posse estarão
disponíveis das 8 às 20 horas, apenas em dias úteis.
2.6.10. Interface de comunicação
50
O Registrato é um sistema administrado pelo BC que permite aos cidadãos terem acesso pela
internet, de forma rápida e segura, a relatórios contendo informações sobre seus relacionamentos
com as instituições financeiras, suas operações de crédito e operações de câmbio. Informações
sobre o Registrato estão disponíveis em
<https://www.bcb.gov.br/acessoinformacao/perguntasfrequentes-
respostas/faq_registrato/false>.
112
Por razões de segurança e de economicidade, para aproveitamento da infraestrutura
já existente, a comunicação entre os participantes do PIX e o DICT será realizada, num
primeiro momento, exclusivamente por meio da RSFN 51.
A interface do DICT proverá todas as funcionalidades para manutenção e obtenção de

dados da conta transacional vinculada a uma chave. Será uma interface RESTFul52,
síncrona, via HTTPS. As definições e requisitos de autenticação dessa interface serão
alinhados aos da interface de comunicação do SPI. O corpo das requisições e das
respostas, quando necessário, será enviado em formato XML.
Por não haver necessidade de não repúdio, as consultas ao DICT não precisarão de
assinatura digital. As operações de registro e de exclusão de vínculos deverão ser
assinadas.
Como o catálogo de mensagens da ISO 20022 não inclui mensagens para o propósito
de consulta e de manutenção de vínculos, será definido um schema específico para as
operações sobre o DICT. A estrutura das mensagens poderá usar elementos da ISO
20022, quando couber.
Para diminuir a carga de requisições ao DICT, consultas retornarão vínculos com um

prazo de validade. O PSP não precisará realizar novas consultas para vínculos que
estejam dentro do prazo de validade. O período de validade será, a princípio, da
ordem de poucos segundos. Isso permitirá que ações de marketing usando vínculos
não gerem requisições desnecessárias ao diretório de endereçamento, sem prejudicar
que atualizações ou remoções de vínculos surtam efeitos tempestivamente.
2.6.11. Mecanismos de prevenção a ataques de leitura

Para prevenir que um usuário realize um ataque de leitura e capture vínculos
existentes no DICT para propósitos distintos de realização de pagamentos, haverá um
mecanismo de limitação de consultas baseado em dois indicadores:
a. consultas sem transferências: quantidade de consultas realizadas por um

usuário final que não resultaram em transferência; e
b. consultas inválidas: quantidade de consultas realizadas por um usuário final

em que a chave não possuía vínculo no diretório de endereçamento.
51
É possível que desenvolvimentos futuros do DICT contemplem acessos por outros meios, como
a internet, por exemplo.
52
https://en.wikipedia.org/wiki/Representational_state_transfer.
113
Para contabilizar esses indicadores, o PSP sempre deverá informar um identificador
pseudonimizado do usuário que está originando a consulta como parte da requisição.
Esse identificador será formado a partir de um HASH sobre os campos:
a. CPF/CNPJ do usuário;
b. identificador do PSP; e
c. número aleatório (sal criptográfico).
Dessa forma, todas as consultas de um mesmo cliente de um mesmo PSP possuirão

o mesmo identificador, permitindo que o mecanismo de limitação atue. Esse
mecanismo será obrigatório. Consultas não identificadas retornarão erro.
O mecanismo de limitação atuará quando um cliente exceder, num determinado

espaço de tempo, um número de consultas inválidas ou sem transferências
efetivadas, bloqueando temporariamente novas consultas ao DICT. Os parâmetros
dessa limitação serão definidos oportunamente.
Para prevenir ataques de leitura com origem na própria infraestrutura do PSP (por
exemplo, se o PSP for invadido ou iniciar um código malicioso), haverá o controle dos
mesmos indicadores de consultas inválidas ou sem transferência por PSP, sem levar
em conta o identificador do usuário final. O número agregado de consultas inválidas
do PSP será monitorado e, caso seja identificada alguma anormalidade, o PSP poderá
ser notificado ou, em último caso, ter as consultas suspensas.
2.7. Autenticação digital dos usuários

Identidade digital é a forma análoga na rede ou Internet à identidade real de uma
pessoa ou entidade, quando usada para identificação em conexões ou transações
eletrônicas.
Confiar no elo entre a identidade real e a identidade digital exige que alguma
instituição valide essa identidade com requisitos de segurança. Ou seja, usar uma
identidade digital envolve algum tipo de autenticação para provar que o usuário que
está usando conexões digitais é ele mesmo.
A autenticação digital dos clientes dos participantes do PIX já é realizada nas

transações e nas operações existentes atualmente. Os métodos e elementos de
segurança usados pelos PSPs mostram-se relativamente eficazes. Sendo assim, o BC
decidiu que não regulamentará o assunto.
Portanto, para fins do ecossistema de pagamentos instantâneos brasileiro, cada

participante do PIX deve se responsabilizar pela correta identificação digital do seu
cliente.
114
Ressalta-se que é de suma importância a autenticação dos usuários de maneira
inequívoca, fazendo uso de mecanismos de autenticação por múltiplos fatores,
incluindo biometria sempre que possível, com vistas a minimizar o risco de fraudes.
Nos outros arranjos de pagamento, a autenticação já é um aspecto crítico de
segurança. Já no caso dos pagamentos instantâneos, uma falha de autenticação pode
ter consequências muito maiores e, por esse motivo, recomenda-se que os
participantes tenham constante preocupação com esse aspecto e aprimorem seus
mecanismos de autenticação sempre que for viável.
Nos casos envolvendo o prestador de serviço de iniciação de pagamentos, a forma de

autenticação digital dos usuários será definida no âmbito do projeto open banking.
2.8. Idempotência
Idempotência é o princípio adotado em matemática e em ciência da computação

segundo o qual algumas operações podem ser repetidas inúmeras vezes obtendo-se
sempre o mesmo resultado. Este princípio é adotado no ecossistema de pagamentos
instantâneos, o que exige que o BC e os demais participantes preparem seus sistemas
para que tratem eventuais solicitações em duplicidade repetindo a resposta anterior.
O princípio da idempotência permite uma simplificação dos sistemas na medida em

que reduz a quantidade de mensagens necessárias ao completo processamento de
transações. Não é necessário, por exemplo, que um participante envie uma consulta
para verificar se determinada operação obteve sucesso ou falha. Em caso de dúvidas
quanto ao processamento, pode-se simplesmente reenviar a operação anterior. Caso
ela já tenha sido processada, o participante receberá a mensagem de sucesso ou falha
anterior. Em caso negativo, o processamento iniciará naquele momento.
No SPI, este princípio será adotado no tratamento das transações que requerem
liquidação (notadamente as ordens de pagamento). Para isso, o sistema verificará os
identificadores únicos de cada transação (“EndtoEndId”).
O mecanismo de idempotência do sistema exige que sejam armazenadas as

transações recebidas, os identificadores correspondentes e as respostas enviadas. A
cada nova transação recebida, o sistema deve verificar se ela possui um identificador
já processado. Em caso positivo, a transação recebida é comparada com a transação
anterior de mesmo identificador. Caso as transações sejam idênticas, o sistema
responderá à nova transação com a mesma resposta já enviada para a anterior. Se as
transações forem distintas, mas com o mesmo identificador, o sistema retornará um
erro (“DuplicateEndToEndID”).
A idempotência deve ser garantida no ecossistema por um tempo a ser definido

posteriormente. Isso significa que, a partir do momento da criação da operação, a
mesma deve cursar obrigatoriamente na janela definida. Se uma operação for
recebida fora da janela, os sistemas devem rejeitá-la com um erro específico
115
(“InvalidEndToEndID”). A data e hora da criação da operação será aquela expressa no
próprio identificador único da transação (“EndtoEndId”)53.
53
O formato utilizado para o EndtoEndId inclui a informação de data e hora de criação. Maiores
informações sobre o seu formato podem ser encontradas no Catálogo de Mensagens do SPI (Anexo
II – ver Definições Detalhadas das Mensagens).
116
3. SISTEMA DE PAGAMENTOS
INSTANTÂNEOS
117
O objetivo desta seção é apresentar as caraterísticas operacionais da infraestrutura
centralizada e única de liquidação no ecossistema de pagamentos instantâneos,
denominada Sistema de Pagamentos Instantâneos (SPI). Nela serão abordadas (i) as
definições acerca da arquitetura tecnológica básica do SPI; (ii) os critérios de
participação no SPI; (iii) os mecanismos para provimento de liquidez para a Conta PI;
(iv) as funcionalidades que estarão disponíveis para gestão da Conta PI por seus
titulares; (v) os critérios de contabilização das transações de pagamento instantâneo,
tanto para o SPI quanto para os seus participantes; e (vi) as diretrizes gerais para a
cobrança de tarifas no SPI.
3.1. Arquitetura básica do SPI
A arquitetura do SPI está baseada em uma estrutura de liquidação centralizada,

acessível pelos participantes a partir de uma API HTTP, que recebe e envia mensagens
assíncronas.
Todos os elementos do sistema estão amparados em mecanismos de redundância,

que evitam a criação de pontos únicos de falha, de forma a suportar uma estrutura de
alta disponibilidade, com operação 24 horas por dia, sete dias por semana e em todos
os dias do ano.
3.2. Participação no SPI
A participação no SPI é:
a. obrigatória: para os participantes do PIX, para fins de liquidação de transações

envolvendo diferentes instituições participantes do PIX, sempre que
envolverem transferência entre diferentes Contas Pagamentos Instantâneos
(Contas PI); e
b. opcional: para as infraestruturas do mercado financeiro, exclusivamente para

fins de liquidação de operações privadas de fornecimento de liquidez para os
participantes do SPI no âmbito da infraestrutura.
O SPI admite duas modalidades de participação:
a. direta: caracteriza-se pela conexão direta da instituição participante ao SPI e

pela titularidade de Conta PI; e
b. indireta: a instituição não possui conexão direta ao SPI nem uma Conta PI. A
participação, neste caso, ocorre por intermédio de um participante direto do
SPI, responsável por registrar o participante indireto no sistema e por atuar
como liquidante no SPI para pagamentos instantâneos a ele relacionados.
Ressalte-se que, no SPI:
118
a. é vedada a participação na modalidade indireta aos bancos comerciais, aos
bancos múltiplos com carteira comercial, às caixas econômicas e às
infraestruturas do mercado financeiro;
b. é vedada a participação na modalidade direta às instituições de pagamento

que não possuem autorização para funcionamento concedida pelo BC; e
c. a STN e o BC também podem ser participantes diretos54.
3.2.1. Participação direta no SPI
A participação direta caracteriza-se pela conexão direta da instituição ao SPI e pela

titularidade de uma Conta PI.
Por conexão direta ao SPI entende-se a capacidade de enviar e receber mensagens do

sistema, conectando-se diretamente à Rede do Sistema Financeiro Nacional (RSFN) ou
por intermédio de um Prestador de Serviço de Tecnologia da Informação (PSTI).
A Conta PI, a ser devidamente e oportunamente regulamentada, mantida pela

instituição no BC, destina-se ao registro da liquidação das transações de pagamentos
instantâneos. Cada instituição titular poderá manter apenas uma Conta PI.
Ressalte-se que ser titular de conta Reservas Bancárias ou de Conta de Liquidação não
é um pré-requisito para ser titular de Conta PI.
As instituições titulares de Conta PI são obrigadas a receber os pagamentos

instantâneos cujos beneficiários sejam seus clientes.
A titularidade de Conta PI faculta às instituições:
a. emitir pagamentos instantâneos por ordem de seus clientes; e

b. atuar como liquidante de pagamentos instantâneos, por meio de
relacionamento contratual bilateral de prestação de serviços, para outras
instituições que sejam suas clientes e que sejam elegíveis a participar do SPI
na modalidade indireta.
54
Apesar de o BC poder ser participante direto do SPI, ele não será titular de Conta PI, da mesma
forma que ocorre no STR, em que o BC é participante do sistema, mas não é titular de Conta
Reservas Bancárias nem de Conta de Liquidação. BC e STN, enquanto participantes diretos do SPI,
poderão enviar e receber pagamentos instantâneos exclusivamente em transações em que
figurem como usuário pagador ou recebedor.
119
Demais implicações da titularidade de Conta PI:
a. pagamento das tarifas devidas pela liquidação de pagamentos instantâneos

no SPI, nos termos da seção 3.6;
b. identificação, por meio de um número de oito dígitos, denominado
Identificador do Sistema de Pagamentos Brasileiro (ISPB) 55;
c. gerenciamento da Conta PI, em tempo real, 24 horas por dia, sete dias por
semana e em todos os dias do ano:
i. não é permitido saque a descoberto na Conta PI (saldo inferior a zero);
ii. os pagamentos instantâneos enviados pelo participante sem a
provisão de fundos na Conta PI serão prontamente rejeitados; e
iii. para consultas ao histórico de pagamentos instantâneos, serão
utilizadas operações próprias do SPI; e
d. as movimentações na Conta PI são irrevogáveis e incondicionais. Após a
efetivação da movimentação dos recursos de ou para uma Conta PI, não é
possível cancelar ou estornar a ordem. A única opção, nesse caso, é a
realização de outra operação, que é independente, contrária e iniciada pelo
PSP do recebedor após ordem do seu cliente, nos termos da seção 1.4.
3.2.2. Participação indireta no SPI
Todo participante indireto do SPI, nos termos da seção 3.2, possuirá um registro ativo
no SPI, que será efetuado por um participante direto do sistema56. Nesse caso, o
participante direto atua como liquidante no SPI para o PSP que é participante indireto.
Os participantes indiretos também serão identificados no sistema por meio do código

de oito dígitos denominado Identificador do Sistema de Pagamentos Brasileiro (ISPB).
A responsabilidade pelo gerenciamento do relacionamento com os participantes

indiretos do SPI está a cargo dos participantes diretos que atuam como seus
liquidantes. Dessa forma, um PSP deixará automaticamente de ser participante
indireto do SPI caso o seu liquidante indique a descontinuidade da prestação do
serviço de liquidação57.
3.3. Mecanismos de liquidez providos pelo BC
55
Esse é o mesmo número que identifica os participantes do STR, para o caso das instituições que
participem também desse sistema. Apesar de o ISPB ser o mesmo número, o SPI terá um cadastro
próprio de participantes, autônomo em relação ao cadastro de participantes das outras
infraestruturas operadas pelo BC, como o STR e o Selic.
56
Ver fluxo na seção 3.4.7.
57
Ver fluxo na seção 3.4.7.1.
120
Os mecanismos de liquidez para o SPI se destinam a prover fundos suficientes na
Conta PI dos participantes do sistema para viabilizar a liquidação de pagamentos
instantâneos dentro e fora do horário de funcionamento do STR, inclusive em dias não
úteis.
3.3.1. Aportes e retiradas em Conta PI durante a grade

regular de operações dos participantes no STR
Durante a grade regular de operações dos participantes no Sistema de Transferência
de Reservas – STR58, o STR é a única fonte provida pelo BC para aporte e saque de
fundos na Conta PI.
Nesse intervalo, é livre a transferência de recursos entre a Conta PI e as contas

Reservas Bancárias (RB), de Liquidação (CL) e Correspondente a Moeda Eletrônica
(CCME).
Ademais, os participantes do STR contam com os mecanismos regulares de liquidez

para suprir a sua conta RB ou CL: redesconto, operações compromissadas no mercado
e saques do compulsório.
As movimentações serão realizadas por meio de eventos e mensagens do grupo de

serviços LPI (Serviços para Liquidez em Conta Pagamentos Instantâneos), no padrão
SPB, disponíveis a partir da versão 5.00 no Catálogo de Serviços do SFN59.
Ressalte-se que no caso de insuficiência de saldo as mensagens do grupo de serviços

LPI serão rejeitadas imediatamente, não havendo status de pendência. A seguir são
apresentadas as opções disponíveis para os prestadores de serviço de pagamento
(PSP) que sejam participantes diretos do SPI e titulares de Conta PI.
3.3.1.1. APORTE EM CONTA PI A PARTIR DE RB OU CL

Nesta seção são apresentados os fluxos a partir dos quais uma instituição participante
do STR solicita ao STR o débito em conta Reservas Bancárias (RB) ou de Liquidação
(CL) própria para crédito, no mesmo montante, em Conta PI. A Conta PI pode ser
própria ou de outro PSP participante direto do SPI que não seja participante do STR.
A solicitação ao STR deve ser feita pelo participante do STR por meio do evento
LPI0001 (IF requisita transferência de conta RB ou CL para depósito em Conta PI), do
Catálogo de Serviços do SFN.
58
Todos os dias úteis para o sistema financeiro, das 6h30 às 18h30, horário de Brasília, com
exceção do dia 24/12, se dia útil, e do último dia útil do ano, quando o horário de fechamento do
STR é 13h.
59
Disponível em: https://www.bcb.gov.br/estabilidadefinanceira/comunicacaodados.
121
Quando do crédito na Conta PI, os recursos aportados estarão imediatamente
disponíveis para uso pelo PSP para liquidação de pagamentos instantâneos.
Aporte em Conta PI própria a partir de RB ou CL própria

Este fluxo é destinado a um PSP, participante direto do SPI e titular de conta RB/CL,
solicitar o aporte em Conta PI própria mediante débito em conta RB ou CL própria.

Participante Início do processo. Participante direto do SPI envia mensagem de solicitação de
1 Mensagem
direto do SPI débito em sua conta RB/CL para aporte, no mesmo montante, em sua Conta PI.
2 STR Mensagem STR recebe mensagem de solicitação de transferência para aporte em Conta PI.
STR verifica se há fundos suficientes na conta RB/CL do participante direto do SPI
3 STR Ação e realiza a troca de saldos das contas: diminui a conta RB/CL e aumenta a Conta
PI do participante no mesmo montante.
4 STR Mensagem STR envia mensagem de confirmação de conclusão do aporte.
Participante Participante direto do SPI recebe confirmação de aporte na Conta PI.
5 Mensagem
direto do SPI
Aporte em Conta PI própria a partir de RB ou CL do Liquidante no STR

Este fluxo é utilizado quando um PSP, participante direto do SPI e não-titular de conta
RB/CL, solicita ao seu Liquidante no STR, de quem o PSP é cliente, que este envie ao
STR a mensagem de aporte em sua Conta PI mediante débito na conta RB ou CL do
Liquidante.
122
Quando da efetivação do aporte na Conta PI, o Liquidante no STR deve comunicar ao
PSP. Além disso, o próprio PSP será notificado diretamente pelo STR, via STR-Web.

Início do processo. Participante direto do SPI, não-titular de RB/CL, solicita
Participante
1 Comunicação ao seu liquidante no STR aporte em sua Conta PI, mediante débito no
direto do SPI
mesmo montante na conta RB/CL do liquidante no STR.
Liquidante
2 Comunicação Liquidante no STR recebe a solicitação de aporte na Conta PI.
no STR
Liquidante
3 Mensagem Liquidante no STR envia mensagem de solicitação ao STR.
no STR
STR recebe mensagem de solicitação de transferência para aporte em Conta
4 STR Mensagem
PI.
STR verifica se há fundos suficientes na conta RB/CL do Liquidante no STR e
realiza a troca de saldos das contas: diminui a conta RB/CL do Liquidante no
5 STR Ação
STR e aumenta a Conta PI do participante direto do SPI no mesmo
montante.
123
Liquidante
7 Mensagem Liquidante no STR recebe mensagem de confirmação de aporte.
no STR
Liquidante
8 Comunicação Liquidante no STR encaminha confirmação ao participante direto do SPI.
no STR
Participante
9 Comunicação Participante direto do SPI recebe a confirmação de aporte na Conta PI.
direto do SPI
10 STR Mensagem STR envia mensagem de aviso de crédito.
Participante
11 Mensagem Participante direto do SPI recebe aviso de crédito, via STR-Web.
direto do SPI
3.3.1.2. APORTE EM CONTA PI A PARTIR DE CCME

Nesta seção é apresentado o fluxo a partir do qual um PSP, que seja participante
direto do SPI e titular de Conta Correspondente a Moeda Eletrônica (CCME), solicita ao
STR o débito em sua conta CCME para crédito, no mesmo montante, em sua Conta PI.
A solicitação ao STR deve ser feita pelo titular da CCME por meio do evento LPI0002 (IF
requisita transferência de conta CCME para depósito em Conta PI), do Catálogo de
Serviços do SFN. Caso o titular da CCME não seja participante do STR, a solicitação
deve ser feita via STR-Web.

124
1 Mensagem
direto do SPI débito em sua CCME para aporte, no mesmo montante, em sua Conta PI.
2 STR Mensagem STR recebe mensagem de solicitação de transferência para aporte em Conta PI.
STR verifica se há fundos suficientes na CCME do participante direto do SPI e
3 STR Ação realiza a troca de saldos das contas: diminui a conta CCME e aumenta a Conta PI
do participante no mesmo montante.
Participante Participante direto do SPI recebe confirmação de aporte na Conta PI.
5 Mensagem
direto do SPI
3.3.1.3. SAQUE EM CONTA PI PARA CRÉDITO EM RB OU CL

Nesta seção são apresentados os fluxos a partir dos quais um PSP, que seja
participante direto do SPI, solicita ao STR o débito em sua Conta PI para crédito, no
mesmo montante, em conta Reservas Bancárias (RB) ou de Liquidação (CL). A RB/CL
pode ser própria ou do Liquidante do PSP no STR, caso o PSP não seja participante do
STR.
A solicitação ao STR deve ser feita pelo PSP titular da Conta PI, por meio do evento
LPI0003 (PSPI requisita transferência para saque em Conta PI e depósito em conta RB
ou CL), do Catálogo de Serviços do SFN.
Saque em Conta PI para crédito em RB ou CL própria

Este fluxo é destinado a um PSP, participante direto do SPI e titular de conta RB/CL,
solicitar o saque em sua Conta PI para crédito em conta RB ou CL própria.
125
Início do processo. Participante direto do SPI envia mensagem de solicitação de
Participante Mensage
1 saque em sua Conta PI, mediante crédito no mesmo montante em sua conta
direto do SPI m
RB/CL.
Mensage
2 STR STR recebe a mensagem de solicitação de saque na Conta PI.
m
STR verifica se há fundos suficientes na Conta PI do participante direto do SPI e
3 STR Ação realiza a troca de saldos das contas: diminui a Conta PI do participante e aumenta
a sua conta RB/CL no mesmo montante.
Mensage
4 STR STR envia confirmação de conclusão do saque.
m
Participante Mensage Participante direto do SPI recebe confirmação de saque na Conta PI e depósito na
5
direto do SPI m RB/CL.
Saque em Conta PI para crédito em RB ou CL do Liquidante no STR

Este fluxo é destinado a um PSP, participante direto do SPI e não-titular de conta
RB/CL, solicitar o saque em sua Conta PI para crédito em conta RB ou CL do Liquidante
no STR, de quem o PSP é cliente.
A solicitação deve feita pelo PSP via STR-Web.
126
Início do processo. Participante Direto do SPI solicita ao STR, por meio do STR-
Participante
1 Mensagem Web, saque de fundos da sua Conta PI, para crédito no mesmo montante na
Direto do SPI
conta RB/CL do Liquidante no STR.
2 STR Mensagem STR recebe mensagem de saque da Conta PI.
STR verifica se há fundos suficientes na Conta PI do Participante Direto do SPI e
3 STR Ação realiza a troca de saldos das contas: diminui a Conta PI do Participante Direto
do SPI e aumenta a conta RB/CL do Liquidante no STR, no mesmo montante.
4 STR Mensagem STR envia mensagem de confirmação ao Participante Direto do SPI.
Participante
5 Mensagem Participante Direto do SPI recebe a confirmação do saque em sua Conta PI.
Direto do SPI
6 STR Mensagem STR envia mensagem de aviso de crédito.
Liquidante no
7 Mensagem Liquidante no STR recebe mensagem de aviso de crédito em sua conta RB/CL.
STR
3.3.1.4. SAQUE EM CONTA PI PARA CRÉDITO EM CCME
127
direto do SPI e titular de Conta Correspondente a Moeda Eletrônica (CCME), solicita ao
STR o débito em sua Conta PI para crédito, no mesmo montante, em CCME própria.
A solicitação ao STR deve ser feita pelo PSP titular da Conta PI, por meio do evento
LPI0004 (PSPI requisita transferência para saque em Conta PI e depósito em CCME),
do Catálogo de Serviços do SFN. Caso o titular da Conta PI não seja participante do
STR, a solicitação deve ser feita via STR-Web.

1 Mensagem
direto do SPI saque em sua Conta PI, mediante crédito no mesmo montante em sua CCME.
2 STR Mensagem STR recebe a mensagem de solicitação de saque na Conta PI.
STR verifica se há fundos suficientes na Conta PI do participante direto do SPI e
3 STR Ação realiza a troca de saldos das contas: diminui a Conta PI do participante e
aumenta a sua CCME no mesmo montante.
4 STR Mensagem STR envia confirmação de conclusão do saque.
Participante Participante direto do SPI recebe confirmação de saque na Conta PI e depósito
5 Mensagem
direto do SPI na CCME.
3.3.2. Aportes na Conta PI após a grade regular de operações

dos participantes no STR
128
A seguir são apresentadas as opções disponíveis para os prestadores de serviço de
pagamento (PSP) que sejam participantes diretos do SPI aportarem recursos em suas
Conta PI após a grade regular de operações dos participantes no STR.
3.3.2.1. JANELA ADICIONAL PARA APORTE EM CONTA PI A PARTIR DE

RB, CL E CCME
Quando do fechamento da grade regular de operações dos participantes no STR, o
sistema enviará uma primeira mensagem STR0016 (STR informa Saldo fechamento).
Ressalte-se que os cumprimentos do compulsório sobre recursos à vista e do

equivalente a moeda eletrônica em espécie serão verificados nesse momento.
Em seguida, será disponibilizada uma janela adicional60 para que as instituições

movimentem valores que possuam em conta Reservas Bancárias (RB), Conta de
Liquidação (CL) e Conta Correspondente a Moeda Eletrônica (CCME) para sua Conta
PI.
As movimentações nessa janela adicional, portanto, resultarão em aportes em Conta

PI, para serem utilizados para fins de liquidação de pagamentos instantâneos, que não
prejudicarão os cumprimentos de compulsório sobre recursos à vista e de equivalente
a moeda eletrônica em espécie, os quais já foram verificados anteriormente.
Ao fim da janela adicional, o STR enviará uma segunda mensagem STR0016 (STR
informa Saldo fechamento), informando os saldos finais nas contas RB/CL após as
movimentações descritas nesta seção.
A seguir estão descritas as operações disponíveis durante a janela adicional.
Aporte em Conta PI própria por ordem do PSP titular da conta

RB/CL/CCME debitada
O PSP titular da conta RB/CL/CCME debitada pode solicitar diretamente ao STR o
aporte em sua Conta PI. Para tanto, o PSP deve utilizar os eventos e os fluxos descritos
nas seções 3.3.1.1 (Aporte em Conta PI a partir de RB ou CL) e 3.3.1.2 (Aporte em Conta
PI a partir de CCME), resguardada a restrição de transferência para Conta PI própria.
Aporte em Conta PI própria por meio de configuração de transferência

automática de valores
O PSP titular das contas RB/CL e/ou CCME a serem debitadas pode realizar uma
configuração prévia no STR para que o próprio STR transfira automaticamente, na
60
Entre o envio pelo STR da primeira mensagem STR0016 (STR informa Saldo fechamento) e as
19h, horário de Brasília, em todos os dias úteis para o sistema financeiro, com exceção do dia
24/12, se dia útil, e do último dia útil do ano, quando a grade adicional será encerrada às 13h30.
129
janela adicional após o fechamento da grade regular de operações no STR, uma parte
ou a totalidade dos valores existentes nas contas RB/CL e/ou CCME do PSP para a
Conta PI própria desse PSP.
A facilidade de configuração é de uso facultativo. Caso o PSP nunca tenha enviado a

mensagem de configuração, o STR entende que não deve realizar a transferência
automática de valores. Caso a instituição já tenha enviado alguma mensagem de
configuração, o STR considera a última versão enviada. Uma dada configuração é
válida até ser substituída pelo PSP. Uma nova configuração substitui completamente
a anterior.
O PSP pode configurar a transferência de um percentual dos valores existentes na

conta RB/CL e/ou na CCME. Nesse caso, o valor efetivo a ser transferido será calculado
diariamente, no momento da efetivação da transferência.
Alternativamente, o PSP pode configurar a transferência de um valor específico das

contas RB/CL e/ou CCME. Nesse caso, quando da tentativa de efetivação da
transferência, a operação somente será concluída caso exista saldo suficiente na conta
de origem indicada. Não existe, neste caso, a figura de mensagem pendente por falta
de saldo.
Caso o PSP possua RB/CL mas não possua CCME, ou vice-versa, o campo referente ao
percentual ou valor do tipo de conta que o PSP não possui deverá ser informado com
valor zero.
Caso o PSP deseje parar de utilizar a facilidade de transferência automática, deverá

enviar uma nova mensagem de configuração na qual os percentuais ou valores a
serem transferidos deverão ser informados com valor zero para todas as suas contas.
Fluxo da configuração prévia realizada pelo PSP

A configuração no STR deve ser feita pelo PSP titular da(s) conta(s) debitada(s), por
meio do evento LPI0005 (PSPI informa configuração de transferência automática de
valores para depósito em Conta PI), do Catálogo de Serviços do SFN.
Por exemplo, um PSP titular de RB e CCME pode optar por transferir automaticamente
apenas valores da RB, apenas valores da CCME, ou valores de ambas as contas.
A configuração deve ser realizada durante a grade regular de operação de

participantes no STR, entrando em vigor a partir do momento em que é aceita pelo
STR.
Caso o PSP não seja participante do STR, a configuração para transferir valores da sua
CCME deve ser feita via STR-Web.
130
Participante Início do processo. Participante direto do SPI envia mensagem de configuração
1 Mensagem
direto do SPI de uso de valores em sua(s) conta(s) RB/CL e/ou CCME.
2 STR Mensagem STR recebe mensagem de solicitação de configuração.
STR atualiza a configuração para uso de valores existentes em RB/CL e CCME do
3 STR Ação
Participante direto do SPI para aporte na Conta PI própria.
4 STR Mensagem STR envia a confirmação da configuração.
Participante
5 Mensagem Participante direto do SPI recebe mensagem de confirmação de configuração.
direto do SPI
Fluxo da transferência automática de valores realizada pelo STR

Após o fechamento da grade regular de operação de participantes no STR, o sistema
verifica a configuração de transferência automática de valores registrada pelo PSP
(conforme item b.1 desta seção) e, em seguida, efetiva a transferência.
O aviso da transferência é realizado por meio do evento LPI0006 (STR informa

transferência automática de valores para depósito em Conta PI), do Catálogo de
Serviços do SFN.
Caso o PSP não seja participante do STR, o aviso da efetivação da transferência será
recebido pelo PSP via STR-Web.
131
STR Ação Início do processo. Após o fechamento da grade regular de operação de
participantes no STR, o STR verifica configuração e realiza a troca de saldos das
1
contas: diminui a(s) conta(s) RB/CL e/ou CCME do Participante direto do SPI e
aumenta a sua Conta PI no montante do somatório.
STR Mensage STR envia mensagem de aviso de conclusão da operação de liquidez ao PSPI.
2
m
Participante Mensage Participante direto do SPI recebe o aviso de conclusão da operação de liquidez.
3
direto do SPI m
3.3.2.2. APORTE EM CONTA PI MEDIANTE OPERAÇÃO COM TPF NO

SELIC PARA INSTITUIÇÕES FINANCEIRAS
O BC, por intermédio do Selic, disponibilizará operação de liquidez com títulos
públicos federais (TPF) às instituições financeiras participantes diretas do SPI, para
aporte de recursos diretamente na Conta PI própria da instituição.
Esta operação de liquidez com TPF está restrita às instituições financeiras em

observância à limitação imposta pelo disposto no art. 164, §1º, da Constituição
Federal.
Aporte em Conta PI de IF mediante operação com TPF no Selic

Nesta seção é apresentado o fluxo a partir do qual um PSP, que é uma instituição
financeira participante do Selic e participante direto do SPI, solicita ao Selic a
132
contratação de uma operação de liquidez com títulos públicos federais (TPF) para
crédito dos recursos financeiros diretamente na Conta PI própria da instituição.
Trata-se de operação de compra com compromisso de revenda61 de TPF registrados

no Selic que integrem a posição de custódia própria da instituição e que não sofram
restrição à negociação.
Não serão aceitos títulos que possuam pagamento de eventos (resgate, juros ou
amortização) coincidente com o vencimento da operação.
A solicitação ao Selic deve ser feita pelo PSP participante do Selic por meio do evento
SEL1009 (IF requisita liquidez em Conta PI), disponível no Catálogo de Serviços do SFN.
O comando da operação SEL1009 deve ser transmitido com o PU divulgado pelo BCB
e vigente no dia (PU de lastro de D+0), ao longo da grade regular de operações com o
STR58. Ao receber a operação, o Selic realiza validação básica (que não inclui a custódia)
e, caso esteja tudo certo, o comando fica acumulado, sem que haja transferência de
custódia ou financeiro neste momento. Então, o Selic informa ao PSP que registrou a
solicitação.
Após o envio da primeira mensagem STR0016 pelo STR (encerramento da grade

regular de operações com o STR em D+0), as operações SEL1009 acumuladas serão
liquidadas no movimento de D+0 do Selic, com a respectiva transferência de custódia
para o BCB.
Será disponibilizada uma grade complementar, imediatamente após o encerramento

da grade regular de operações com o STR e com duração até as 19h do movimento
corrente (D+0), para que o PSP possa comandar operações SEL1009 adicionais, com o
objetivo de suprir eventual falha por falta de saldo de títulos.
Tanto no caso das operações SEL1009 acumuladas quanto das SEL1009 adicionais, se
o PSP não possuir títulos suficientes para liquidar a operação no momento da
verificação da custódia, o Selic rejeita imediatamente a operação, não havendo status
de pendência.

61
Operação de compra de TPF, pelo BCB, com compromisso de revenda, conjugadamente com a
venda de TPF, pela instituição financeira, com compromisso de recompra.
133
Fluxo para operações requisitadas durante a grade regular de operações com o STR

Início do processo. Participante direto do SPI envia mensagem de
Participante
1 Mensagem solicitação de aporte em sua Conta PI, mediante operação com TPF
direto do SPI
de sua titularidade no Selic.
2 Selic Mensagem Selic recebe mensagem de solicitação de liquidez.
Selic realiza validação básica (que não inclui a custódia) e, caso todas
3 Selic Ação as condições sejam satisfeitas, acumula o comando. Neste
momento, a custódia ainda não é verificada.
4 Selic Mensagem Selic envia mensagem informando que acumulou a solicitação.
Participante Mensagem Participante direto do SPI recebe informação de que a operação foi
5
direto do SPI acumulada e está pendente de processamento.
Após o encerramento da grade regular de operações com o STR, o
Selic dá curso à solicitação de liquidez: verifica a custódia e, caso o
6 Selic Ação
participante direto do SPI possua títulos suficientes para liquidar a
operação, o Selic realiza o bloqueio dos títulos.
Selic repassa a operação ao STR para movimentação financeira (com
7 Selic Mensagem
movimento e PU de D+0).
134
8 STR Mensagem STR recebe a operação de liquidez.
STR debita o BCB e credita a Conta PI do Participante direto do SPI
9 STR Ação
no mesmo montante.
10 STR Mensagem STR envia confirmação da parte financeira da operação ao Selic.
11 Selic Mensagem Selic recebe a confirmação da parte financeira da operação.
Selic transfere a custódia dos títulos do Participante direto do SPI
12 Selic Ação
para o BCB.
13 Selic Mensagem Selic envia mensagem de aviso de operação atualizada.
Participante direto do SPI recebe aviso de operação atualizada,
Participante
14 Mensagem confirmando a conclusão da operação de concessão de liquidez em
direto do SPI
sua Conta PI.
Obs.: Durante o offline, o Selic calcula e registra o PU de retorno, informando ao participante via SEL1611.
Fluxo para operações adicionais na grade complementar para operações com o STR

1 Mensagem
direto do SPI aporte em sua Conta PI, mediante operação com TPF de sua titularidade no Selic.
2 Selic Mensagem Selic recebe mensagem de solicitação de liquidez.
135
Selic verifica a custódia e, caso o participante direto do SPI possua títulos
3 Selic Ação
suficientes para liquidar a operação, o Selic realiza o bloqueio dos títulos.
Selic repassa a operação ao STR para movimentação financeira (com movimento
4 Selic Mensagem
e PU de D+0).
5 STR Mensagem STR recebe a operação de liquidez.
STR debita o BCB e credita a Conta PI do Participante direto do SPI, no mesmo
6 STR Ação
montante.
7 STR Mensagem STR envia confirmação da parte financeira da operação ao Selic.
8 Selic Mensagem Selic recebe a confirmação da parte financeira da operação.
9 Selic Ação Selic transfere a custódia dos títulos do Participante direto do SPI para o BCB.
10 Selic Mensagem Selic envia mensagem de aviso de operação atualizada.
Participante Participante direto do SPI recebe aviso de operação atualizada, confirmando a
11 Mensagem
direto do SPI conclusão da operação de concessão de liquidez em sua Conta PI.
Obs.: Durante o offline, o Selic calcula e registra o PU de retorno, informando ao participante via SEL1611.
Pagamento pela IF de operação com TPF no Selic mediante fundos

disponíveis em sua Conta PI
A liquidez concedida pela operação com TPF no Selic, de que trata a seção anterior,
deve ser paga pelo PSP que a contratou ao longo da grade regular de operações com
o STR no dia útil seguinte à contratação (D+1).
Deve ser utilizado, para pagamento, PU de ida atualizado pela taxa a ser fixada pelo
BCB, a ser oportunamente divulgada.
A solicitação de pagamento da liquidez deve ser feita pelo PSP participante do Selic
por meio do evento SEL1016 (IF requisita pagamento de liquidez em Conta PI),
disponível no Catálogo de Serviços do SFN. O comando de pagamento da liquidez
pode ser integral ou parcial (até pagar-se a parte final).
Os pagamentos recebidos pelo Selic serão imediatamente processados. Se o PSP não

possuir fundos suficientes em sua Conta PI para suportar o pagamento, o pagamento
será rejeitado, não havendo status de pendência.
136
Início do processo. Participante direto do SPI envia mensagem de pagamento
Participante
1 Mensagem total ou parcial de operação com TPF, mediante fundos disponíveis em sua Conta
direto do SPI
PI.
2 Selic Mensagem Selic recebe mensagem de solicitação de pagamento.
3 Selic Ação Selic bloqueia títulos que estão na custódia do BCB.
4 Selic Mensagem Selic repassa a operação ao STR para movimentação financeira.
5 STR Mensagem STR recebe a operação de pagamento.
STR debita a Conta PI do Participante direto do SPI e credita o BCB, no mesmo
6 STR Ação
montante.
7 STR Mensagem STR envia confirmação do pagamento da operação ao Selic.
8 Selic Mensagem Selic recebe a confirmação do pagamento.
Selic transfere a custódia dos títulos, que estavam com o BCB, de volta para o
9 Selic Ação
Participante direto do SPI.
10 Selic Mensagem Selic envia mensagem de confirmação do pagamento.
Participante
11 Mensagem Participante direto do SPI recebe a confirmação do pagamento da operação.
direto do SPI
3.4. Gestão da Conta PI
137
Esta seção apresenta as ações ordinárias que um PSP, que seja participante direto do
SPI, pode executar para gerir a Conta PI de sua titularidade.
3.4.1. Consulta saldo da Conta PI

direto do SPI, consulta o saldo em sua Conta PI.
Caso o filtro de consulta indique uma data passada, o SPI informará o saldo existente
no fechamento do dia consultado. Caso o PSP indique a data corrente, o SPI informará
o saldo atual, existente na Conta PI no momento do processamento da consulta pelo
SPI.
O saldo será sempre estratificado em dois componentes: a parcela disponível e a

parcela bloqueada. A parcela bloqueada é a soma dos valores dos Pagamentos
Instantâneos comandados pela instituição que, no fluxo 1.1.1, já passaram pela etapa
#6 (bloqueia Conta PI), mas ainda não concluíram a etapa #12 (ajusta saldo Conta PI).
Já a parcela disponível corresponde ao valor total existente na Conta PI, menos a
parcela bloqueada.
A consulta ao saldo deve ser feita por meio da mensagem CAMT.060 e será respondida
pela mensagem CAMT.053, ambas disponíveis no Anexo II – Catálogo de Mensagens
do SPI.
Ressalte-se que o prazo máximo dentro do qual o saldo de fechamento do dia de uma
data passada estará disponível para consulta via CAMT.053 é de cinco anos.
138
Participante Início do processo. Participante direto do SPI envia mensagem de consulta de
1 Mensagem
direto do SPI saldo da sua Conta PI, com filtro de “data”.
2 SPI Mensagem SPI recebe a mensagem de consulta.
SPI recupera o saldo da Conta PI, estratificado em dois componentes: a parcela
disponível e a parcela bloqueada.
• caso o filtro de consulta indique uma data passada, o SPI informará o
saldo existente no fechamento do dia consultado; e
3 SPI Ação
• caso o PSP indique a data corrente, o SPI informará o saldo atual,
existente na Conta PI no momento do processamento da consulta pelo
SPI.
4 SPI Mensagem SPI envia informação de saldo.

Participante
5 Mensagem Participante direto do SPI recebe informação de saldo da Conta PI.
direto do SPI
3.4.2. Consulta relação de lançamentos

direto do SPI, consulta a relação de lançamentos de pagamentos instantâneos de um
período.
Os lançamentos retornados englobam aqueles em que o PSP figurou na ponta

pagadora (inclui as operações liquidadas e aquelas que receberam rejeição de negócio
informada por meio da mensagem PACS.002, conforme explicação contida na seção
1.3.1.1) e na ponta recebedora (neste caso, apenas as operações efetivamente
liquidadas).
O PSP pode consultar lançamentos em qualquer faixa de horário menor ou igual a um

intervalo de 24 horas, inclusive englobando viradas da data-calendário. Assim, por
exemplo, o PSP pode consultar lançamentos entre às 5h e às 20h de um mesmo dia,
ou entre às 21h de um dia e às 3h do dia seguinte.
A consulta de lançamentos deve ser feita por meio da mensagem CAMT.060. A

mensagem de resposta, CAMT.052 será um aviso de que o arquivo contendo os
lançamentos está pronto para download. As mensagens estão disponíveis no Anexo II
– Catálogo de Mensagens do SPI, e o arquivo será oportunamente divulgado.
Ressalte-se que o prazo máximo dentro do qual a relação de lançamentos estará

disponível para consulta via CAMT.052 é de cinco anos.
A forma de download do arquivo será divulgada oportunamente.
139
1 Mensagem
direto do SPI extrato da sua Conta PI, com o filtro de “período”.
SPI recupera a relação de lançamentos. Cada lançamento contém:
• Número único da transação, PSP do pagador (participante direto), PSP
3 SPI Ação
do pagador (participante indireto), PSP do recebedor (participante
direto), PSP do recebedor (participante indireto), data, horário e valor.
SPI SPI envia mensagem informando que o arquivo com a relação de lançamentos
4 Mensagem
está pronto para download.
Participante direto do SPI recebe informação de que o download está
Participante
5 Mensagem disponível. As instruções para download são fornecidas junto com a
direto do SPI
informação.
Participante
6 Ação Participante direto do SPI efetua download conforme instruções recebidas.
direto do SPI
3.4.3. Consulta detalhes de um lançamento

direto do SPI, consulta os detalhes de um lançamento de pagamento instantâneo no
qual figurou na ponta pagadora ou na ponta recebedora.
Operações rejeitadas devido a aspectos de formatação da mensagem (conforme

explicação contida na seção 1.3.1.1) não poderão ser posteriormente consultados
junto ao SPI, uma vez que o erro de formatação da mensagem impede o seu
140
armazenamento na base de dados do sistema. Nesse caso, o PSP deve tratar a
resposta de erro recebida no momento da validação inicial efetuada pelo SPI.
Ressalte-se que pagamentos para os quais o PSP ainda não recebeu resposta alguma,
mesmo após transcorrido o tempo máximo definido para caracterização de timeout
no SPI, devem ser consultados por meio da função descrita no fluxo contido na seção
3.4.6. Para todos os demais casos, sejam de sucesso ou de insucesso, o PSP deve
utilizar a função descrita nesta seção para consultar os detalhes de um lançamento.
A consulta aos detalhes do lançamento deve ser feita por meio da mensagem
CAMT.060 e será respondida pela mensagem CAMT.054, ambas disponíveis no Anexo
II – Catálogo de Mensagens do SPI.
O prazo máximo dentro do qual os detalhes de um lançamento estarão disponíveis

para consulta via CAMT.054 é de cinco anos.

1 Mensagem
direto do SPI detalhes de um lançamento, com o filtro de “número único da transação”.
SPI recupera os detalhes do lançamento que corresponde ao número único da
3 SPI Ação
transação. Como resultado, o SPI envia os dados completos do lançamento.
4 SPI Mensagem SPI envia informação com os detalhes do lançamento.
Participante
5 Mensagem Participante direto do SPI recebe os detalhes do lançamento.
direto do SPI
141
3.4.4. Atualização de responsáveis pela gestão da Conta PI
direto do SPI, solicita a atualização dos funcionários responsáveis pela gestão e pela
operação da Conta PI junto ao SPI.
A atualização de responsáveis deve ser feita por meio da mensagem CAMT.015 e será
respondida pela mensagem CAMT.025, as quais serão oportunamente divulgadas.

Participante Início do processo. Participante direto do SPI envia mensagem de atualização
1 Mensagem
direto do SPI de responsáveis pela gestão e pela operação da Conta PI.
2 SPI Mensagem SPI recebe a mensagem de atualização.
3 SPI Ação SPI cadastra as informações fornecidas pelo participante direto do SPI.
4 SPI Mensagem SPI envia confirmação de atualização.
Participante
5 Mensagem Participante direto do SPI recebe confirmação de atualização.
direto do SPI
3.4.5. Avisos sobre a operação do SPI

Nesta seção é apresentado o fluxo a partir do qual o SPI envia aviso a um ou mais
PSPs, que sejam participantes diretos do SPI, sobre a operação da infraestrutura.
142
Cabe aos participantes diretos do SPI que atuam como liquidante repassarem os
avisos aos participantes indiretos do SPI para os quais prestam serviço de liquidação
de pagamentos instantâneos, quando for o caso.
O aviso será feito por meio da mensagem ADMI.004, a ser oportunamente divulgada.

Início do processo. Ocorrência de evento relevante que deve ser
1 SPI Ação
comunicado a um ou mais participantes do SPI.
SPI envia mensagem de aviso a um ou mais participantes diretos do SPI.
2 SPI Mensagem
Por exemplo, um aviso de mudança da data-contábil.
Participante
3 Mensagem Participante direto do SPI recebe mensagem de aviso.
direto do SPI
Participante
4 Ação Participante direto do SPI adota as providências cabíveis.
direto do SPI
Participante Participante direto do SPI repassa o aviso aos participantes indiretos do SPI
5 Comunicação
direto do SPI para os quais presta serviço como liquidante, quando for o caso.
143
Participante
6 Comunicação Participante indireto do SPI recebe mensagem de aviso.
indireto do SPI
Participante
7 Ação Participante indireto do SPI adota as providências cabíveis.
indireto do SPI
3.4.6. Resolução de pagamento não respondido
Idealmente, todos os pagamentos instantâneos submetidos à liquidação no SPI serão

respondidos pelo SPI dentro do prazo previsto, tanto ao PSP do pagador quanto ao
PSP do recebedor que sejam participantes diretos do SPI.
Não obstante, podem ocorrer situações excepcionais e imprevistas que levem ao não
recebimento de uma resposta por um PSP participante direto do SPI. Exemplos dessas
situações incluem, de forma não exaustiva, uma perda da mensagem de resposta
pelos sistemas do PSP ou mesmo uma eventual falha momentânea da rede de
comunicação ou do próprio SPI. O procedimento descrito nesta seção destina-se a
tratar essas situações excepcionais e imprevistas.
A resolução de um pagamento não respondido pelo SPI se dá pelo reenvio, por parte
do PSP que não recebeu a resposta do SPI, da mesma mensagem de estímulo enviada
anteriormente, utilizando-se inclusive o mesmo número único da transação. Consiste,
portanto, no uso do princípio de idempotência descrito na seção 2.8.
Assim, considerando-se as etapas descritas no fluxo da seção 1.1.1, caso o PSP do

pagador não receba resposta alguma do SPI após transcorrido o tempo máximo para
caracterização de timeout, esse PSP deve reenviar a mensagem de pagamento descrita
na etapa #4. Caso o PSP do recebedor não receba resposta alguma do SPI após
transcorrido o tempo máximo para caracterização de timeout, esse PSP deve reenviar
a notificação descrita na etapa #10.
3.4.6.1. REENVIO DO ESTÍMULO PELO PSP DO PAGADOR
Nesta seção é apresentado o fluxo a partir do qual o PSP do pagador, que seja
participante direto do SPI, reenvia a mensagem de pagamento, previamente
encaminhada (etapa #4 do fluxo 1.1.1), para a qual não obteve resposta do SPI até o
tempo máximo definido para caracterização de timeout.
A mensagem de pagamento deve ser reenviada com os mesmos dados utilizados na

etapa #4, inclusive com o mesmo número único da transação.
144
PSP do
1 Comunicação Início do processo. PSP do pagador recebe ordem de pagamento.
pagador
PSP do
2 Ação pagador armazena a ordem para processamento na data escolhida pelo usuário
pagador
pagador.
PSP do PSP do pagador realiza bloqueio do valor do pagamento na conta do usuário
3 Ação
pagador pagador.
PSP do PSP do pagador envia mensagem ao SPI solicitando troca de saldo na Conta PI
4 Mensagem
pagador para prosseguimento do pagamento.
Enquanto aguarda receber a confirmação sobre o pagamento enviado ao SPI,
entre as etapas #4 (Envia msg pagamento) e #18 (Recebe confirmação), o PSP do
PSP do
C1 Ação pagador identifica lentidão excessiva para recebimento da resposta. A lentidão
pagador
excessiva é caracterizada pela extrapolação do limite de tempo para
caracterização de timeout.
PSP do PSP do pagador reenvia a mensagem de pagamento enviada ao SPI na etapa #4,
C2 Mensagem
pagador com os mesmos dados, incluindo o mesmo número único da transação.
C3 SPI Mensagem SPI recebe mensagem enviada pelo PSP do pagador.
SPI efetua uma das seguintes possíveis ações:
• caso a mensagem reenviada na etapa #C2 já tenha sido recebida e
C4
processada (com sucesso ou insucesso), o SPI reenviará ao PSP a mesma
a SPI Ação
resposta gerada quando do processamento da mensagem original (ou o
C8
sucesso da etapa #18 do fluxo 1.1.1, ou um dos cenários de insucesso
previstos na seção 1.3); ou
145
• caso a mensagem reenviada na etapa #C2 não tenha sido recebida e
processada (isso é, o SPI não possui qualquer registro sobre ela), o SPI
prossegue a partir da etapa #6 do fluxo descrito na seção 1.1.1, como se
a mensagem fosse uma nova ordem de pagamento.
3.4.6.2. REENVIO DE ESTÍMULO PELO PSP DO RECEBEDOR
Nesta seção é apresentado o fluxo a partir do qual o PSP do recebedor, que seja
participante direto do SPI, reenvia a mensagem de notificação, previamente
encaminhada (etapa #10 do fluxo 1.1.1), para a qual não obteve resposta do SPI até o
tempo máximo definido para caracterização de timeout.
A mensagem de notificação deve ser reenviada com os mesmos dados utilizados na

etapa #10, inclusive com o mesmo número único da transação.
146
PSP do Início do processo. PSP do pagador recebe ordem de pagamento.
1 Comunicação
pagador
PSP do Caso se trate de um pagamento para liquidação não prioritária, o PSP do pagador
2 Ação
pagador armazena a ordem para processamento na data escolhida pelo usuário pagador.
PSP do PSP do pagador realiza bloqueio do valor do pagamento na conta do usuário
3 Ação
pagador pagador.
PSP do PSP do pagador envia mensagem ao SPI solicitando troca de saldo na Conta PI
4 Mensagem
pagador para prosseguimento do pagamento.
SPI recebe mensagem enviada pelo PSP do pagador solicitando troca de saldo na
5 SPI Mensagem
SPI efetua o bloqueio na Conta PI do PSP do pagador no montante do pagamento
6 SPI Ação
em questão.
7 SPI Mensagem SPI envia mensagem ao PSP do recebedor informando os dados da transferência.
PSP do
8 Mensagem PSP do recebedor recebe mensagem com os dados da transferência.
recebedor
PSP do PSP do recebedor valida a conta do usuário recebedor e faz anotação provisória
9 Ação
recebedor de crédito nessa conta.
PSP do PSP do recebedor envia notificação ao SPI, solicitando o prosseguimento do
10 Mensagem
recebedor pagamento.
Enquanto aguarda receber a confirmação sobre a notificação enviada ao SPI, o
PSP do PSP do recebedor identifica lentidão excessiva para recebimento da confirmação
C1 Ação
recebedor do SPI. A lentidão excessiva é caracterizada pela extrapolação do limite de tempo
para caracterização de timeout.
PSP do PSP do recebedor reenvia a mesma notificação enviada ao SPI na etapa #10, com
C2 Mensagem
recebedor os mesmos dados, incluindo o mesmo número único da transação.
C3 SPI Mensagem SPI recebe mensagem enviada pelo PSP do recebedor.
SPI efetua uma das seguintes possíveis ações:
• caso a notificação reenviada na etapa #C2 já tenha sido recebida e
processada, o SPI reenviará ao PSP a mesma resposta gerada quando do
C4 processamento da mensagem original (ou o sucesso da etapa #14 do
e SPI Ação fluxo 1.1.1, ou um dos cenários de insucesso previstos na seção 1.3); ou
C8 • caso a notificação reenviada na etapa #C2 não tenha sido recebida e
processada (isso é, o SPI não possui qualquer registro sobre ela), o SPI
prossegue a partir da etapa #11 do fluxo descrito na seção 1.1.1, como se
a notificação fosse nova.
C5 SPI Mensagem SPI envia informação sobre a situação do pagamento ao PSP do recebedor.
PSP do
C6 Mensagem PSP do recebedor recebe informação do SPI sobre a situação do pagamento.
recebedor
Caso o pagamento tenha sido concluído com sucesso, o PSP do recebedor deve
prosseguir a partir da etapa #15 (Credita conta) do fluxo 1.1.1.
PSP do Caso o pagamento tenha sido frustrado devido a alguma das situações de
C7 Ação
recebedor insucesso previstas na seção 1.3, o PSP do recebedor deve adotar as medidas
definidas no respectivo fluxo de tratamento da situação de insucesso, conforme o
caso.
147
3.4.6.3. REENVIO DO ESTÍMULO PELO SPI
Em situações de falha de comunicação entre o SPI e o PSP Recebedor, especialmente
quando o SPI não obtiver confirmação do recebimento da mensagem de crédito
(etapa #7 do fluxo 1.1.1), o SPI fará o reenvio da mensagem.
Por essa razão, é necessário que o PSP Recebedor assuma, também para essa
operação, um comportamento idempotente.
3.4.7. Registro de participante indireto para o qual o

participante direto presta serviço de liquidação no SPI
direto do SPI e que atenda aos critérios para atuação como liquidante no SPI, registra
um PSP participante indireto do SPI.
Após o liquidante no SPI receber a comunicação de uma instituição que deseja se

tornar participante indireto do SPI, o liquidante deve registrar o participante indireto
no SPI. O registro é feito um a um, para cada participante indireto para o qual o serviço
de liquidação será prestado. Não obstante, cada liquidante no SPI poderá prestar
serviço de liquidação no SPI para quantos participantes indiretos desejar.
Ao receber a solicitação do liquidante, o SPI registra o participante indireto e vincula o

ISPB dele, informado pelo liquidante no SPI, ao ISPB do próprio liquidante.
Nenhum liquidante poderá registrar um ISPB que já se encontre com registro ativo no
SPI. Caso haja essa tentativa, o SPI irá identificar a duplicidade e deixará o novo pedido
de registro em suspenso, até que o antigo liquidante no SPI encerre o seu
relacionamento com o participante indireto62. Registros que estão em suspenso serão
expirados se não forem confirmados dentro do prazo de vinte e quatro horas.
Portanto, em um dado momento, cada participante indireto no SPI pode ter apenas
um único liquidante.
O registro do participante indireto deve ser feito por meio da mensagem REDA.014 e
será respondido pela mensagem REDA.016, a serem divulgadas oportunamente.
62
Ver fluxo na seção 3.4.7.1.
148
Início do processo. Participante indireto envia comunicação ao liquidante
Participante
1 Comunicação no SPI (participante direto), solicitando a prestação de serviço de
indireto do SPI
liquidação.
2 Liquidante no SPI Comunicação Liquidante no SPI recebe a solicitação do participante indireto.
Liquidante no SPI envia mensagem ao SPI solicitando o registro do
3 Liquidante no SPI Mensagem
participante indireto no SPI para o qual presta serviço de liquidação.
4 SPI Mensagem SPI recebe a mensagem de solicitação de registro.
SPI SPI registra o participante indireto do SPI e vincula o seu identificador
5 Ação
único ao participante direto no SPI que atuará como seu liquidante.
6 SPI Mensagem SPI envia confirmação de registro.
7 Liquidante no SPI Mensagem Liquidante no SPI recebe confirmação de registro.
8 Liquidante no SPI Comunicação Liquidante no SPI envia confirmação de registro ao participante indireto.
Participante
9 Comunicação Participante indireto do SPI recebe confirmação de registro.
indireto do SPI
149
3.4.7.1. DESCONTINUIDADE DA PRESTAÇÃO DE SERVIÇO DE
LIQUIDAÇÃO NO SPI
direto do SPI e atue como liquidante, registra a descontinuidade da prestação de
serviço de liquidação. O registro de descontinuidade deve ser feito um a um, para cada
participante indireto do SPI.
Ao receber a solicitação, o SPI desvincula o identificador único do participante indireto

do SPI. A partir desse momento, nenhuma transação originada ou endereçada ao
participante indireto será aceita pelo SPI até o momento em que algum liquidante no
SPI (o mesmo ou outro) recadastre o identificador único do participante indireto. Por
outro lado, se houver um pedido de registro pendente por duplicidade, submetido por
outro liquidante no SPI, o SPI efetua a troca de liquidante de imediato, sem
interromper a aceitação das transações originadas ou endereçadas ao participante
indireto.
Portanto, um participante indireto será reconhecido pelo SPI apenas se existir um

registro ativo de prestação de serviço mantido por um liquidante.
O registro da descontinuidade da prestação de serviço de liquidação deve ser feito por

meio da mensagem REDA.031 e será respondido pela mensagem REDA.016, a serem
oportunamente divulgadas.
150
Início do processo. Participante indireto envia comunicação ao liquidante
Participante
1 Comunicação no SPI (participante direto) solicitando a descontinuidade da prestação do
indireto do SPI
serviço de liquidação.
2 Liquidante no SPI Comunicação Liquidante no SPI recebe a solicitação.
Liquidante no SPI envia mensagem ao SPI solicitando a descontinuidade da
3 Liquidante no SPI Mensagem
prestação do serviço de liquidação.
4 SPI Mensagem SPI recebe a mensagem de solicitação.
SPI desvincula, do participante direto no SPI que atua como liquidante, o
identificador único do participante indireto do SPI. Se houver um pedido de
5 SPI Ação registro pendente por duplicidade, submetido por outro liquidante, o SPI
efetua a troca de liquidante de imediato, sem interromper a aceitação das
transações originadas ou endereçadas ao participante indireto.
SPI envia confirmação. Se estiver ocorrendo uma troca de liquidante, o SPI
6 SPI Mensagem envia também a confirmação de registro descrita na etapa #6 do fluxo
descrito na seção 3.4.7.
Liquidante no SPI recebe confirmação da descontinuidade do serviço. Se
7 Liquidante no SPI Mensagem estiver ocorrendo uma troca de liquidante, o novo liquidante recebe a
confirmação descrita na etapa #7 do fluxo descrito na seção 3.4.7.
151
Liquidante no SPI envia notificação de descontinuidade de serviço. Se
8 Liquidante no SPI Comunicação estiver ocorrendo uma troca de liquidante, o novo liquidante envia a
confirmação descrita na etapa #8 do fluxo descrito na seção 3.4.7.
Participante indireto recebe notificação da descontinuidade do serviço. Se
Participante estiver ocorrendo uma troca de liquidante, participante indireto recebe
9 Comunicação
indireto do SPI também a confirmação descrita na etapa #9 do fluxo descrito na seção
3.4.7.
3.4.8. Aviso de inclusão, de alteração ou de exclusão de

Participante direto ou indireto do SPI
Nesta seção é apresentado o fluxo a partir do qual o SPI envia aviso, a todos os PSPs
que sejam participantes diretos do SPI, sobre um participante direto do SPI ou um
participante indireto do SPI que foi ou que será incluído ou excluído em determinada
data, ou que teve os seus dados alterados.
Os participantes diretos que atuam como liquidante devem, obrigatoriamente e de

forma tempestiva, repassar esses avisos aos participantes indiretos para os quais
prestam serviço de liquidação.
No caso de aviso de inclusão, ou de exclusão, de participante direto do SPI, a data

informada no aviso indica o momento a partir do qual o participante direto do SPI
poderá movimentar, ou deixará de movimentar, a sua Conta PI. Os avisos de inclusão
ou de exclusão de participantes indiretos do SPI serão enviados no momento em que
o respectivo registro pelo liquidante for efetuado.
Todos os participantes, diretos e indiretos, devem estar preparados para tratar esse
aviso tempestivamente, disponibilizando, ou inibindo, o PSP incluído, ou excluído,
conforme o caso, em seus respectivos canais de operação e de atendimento.
O aviso será feito por meio da mensagem CAMT.014, a ser oportunamente divulgada.
152
Início do processo. SPI identifica participante direto do SPI ou participante
1 SPI Ação indireto do SPI que foi ou que será incluído ou excluído em determinada data,
ou que teve os seus dados alterados.
2 SPI Mensagem SPI envia aviso a todos os participantes diretos do SPI.
Participante
3 Mensagem Participante direto do SPI recebe mensagem de aviso.
direto do SPI
Participante direto do SPI adota as providências cabíveis, tempestivamente.
Participante
4 Ação Por exemplo, disponibilizando o PSP incluído, seja ele um participante direto
direto do SPI
ou indireto do SPI, em seus canais de operação e de atendimento.
Participante Participante direto do SPI repassa, tempestivamente, o aviso aos participantes
5 Comunicação
direto do SPI indiretos do SPI para os quais presta serviço de liquidante.
Participante
6 indireto do Comunicação Participante indireto do SPI recebe mensagem de aviso.
SPI
153
Participante Participante indireto do SPI adota as providências cabíveis, tempestivamente.
7 indireto do Ação Por exemplo, disponibilizando o PSP incluído, seja ele um participante direto
SPI ou indireto do SPI, em seus canais de operação e de atendimento.
3.5. Contabilização da Conta PI
Ao longo de um dia útil (a partir das 0h) e até o final desse dia útil (até as
23h59min59seg), a data-contábil utilizada para contabilização das operações cursadas
no SPI corresponderá à data-calendário do dia útil corrente (DU).
Quando ocorrer a virada da data-calendário ao fim desse dia útil, a data-contábil

utilizada para contabilização no SPI passará a ser a data do dia útil seguinte (DU+1).
Em fins de semana e feriados, os pagamentos instantâneos liquidados deverão ser

contabilizados na data-contábil equivalente ao dia útil seguinte (DU+1), com data de
referência ao dia em que efetivamente ocorreram (data-calendário não útil).
Ressalte-se que o sistema contábil do BC utilizará essa mesma referência de horário

para virada da sua data de movimento contábil. O diagrama a seguir ilustra a data
para contabilização dos lançamentos na Conta PI:
Sempre que ocorrer a virada da data-contábil, o SPI passará a utilizar a nova data-
contábil para liquidação das transações. Ademais, o SPI informará aos PSPs do
pagador e do recebedor a data do movimento contábil em todas as respostas às
operações liquidadas, atuando como ponto focal de referência para essa informação.
A data do movimento contábil é registrada no momento da troca de saldos nas contas
PI.
154
Alterações no Cosif a respeito dos critérios e dos procedimentos contábeis a serem
observados pelos participantes na contabilização dos eventos relacionados aos
pagamentos instantâneos serão oportunamente divulgadas pelo BC.
3.6. Tarifas
As tarifas cobradas pela utilização do SPI serão estabelecidas pelo BC com vistas,
exclusivamente, ao ressarcimento das despesas por ele incorridas na gestão e na
operação do SPI. A metodologia de cobrança dessas tarifas será detalhada
oportunamente63.
63
Questões tarifárias envolvendo outros aspectos do PIX serão oportunamente tratadas em seção
específica deste Documento.
155
Glossário
Chave para endereçamento
Informação relacionada ao titular de uma conta transacional, que é utilizada para

obter as informações sobre o usuário recebedor e a respectiva conta transacional, a
fim de facilitar o processo de iniciação do pagamento pelo usuário pagador.
Conta Pagamentos Instantâneos (Conta PI)
Conta mantida no BC, de titularidade de um participante direto, utilizada para fins de

liquidação de pagamentos instantâneos.
Conta transacional
Conta mantida por um usuário final em um prestador de serviços de pagamento e

utilizada para fins de pagamento ou de recebimento de um pagamento instantâneo.
Pode ser uma conta de depósitos à vista, uma conta de depósitos de poupança ou
uma conta de pagamento pré-paga.
Diretório de Identificadores de Contas Transacionais (DICT)
Componente do PIX que armazena as informações dos usuários recebedores e das

respectivas contas transacionais, que podem ser localizadas por meio das chaves para
endereçamento.
Ecossistema de pagamentos instantâneos brasileiro
Ambiente formado pelo arranjo aberto que será instituído pelo BC, denominado PIX,
pelos prestadores de serviços de pagamento participantes do arranjo, pelo Diretório
de Identificadores de Contas Transacionais e pelo Sistema de Pagamentos
Instantâneos, que será utilizado para a liquidação das transações realizadas entre
diferentes instituições participantes do arranjo.
Inserção manual dos dados
Processo no qual o usuário pagador deve inserir manualmente os dados de

identificação do usuário recebedor e da respectiva conta transacional para iniciar uma
transação de pagamento instantâneo.
Liquidante no SPI
Participante direto que presta serviço de liquidação a um participante indireto. Em um

dado pagamento, pode atuar como participante direto recebedor ou como
participante direto pagador, conforme o caso.
Pagamento instantâneo
156
Transferência de fundos eletrônica na qual a transmissão da ordem de pagamento e
a disponibilidade de fundos para o usuário recebedor ocorre em tempo real e cujo
serviço está disponível durante 24 horas por dia, sete dias por semana e em todos os
dias no ano.
Participante direto
Instituição autorizada a funcionar pelo BC que oferta uma conta transacional para um
usuário final e que, para fins de liquidação de pagamentos instantâneos, é titular de
Conta PI.
Participante indireto
Instituição que oferta uma conta transacional para um usuário final, mas que não é
titular de Conta PI no BC nem possui conexão direta com o SPI. Utiliza os serviços de
um liquidante no SPI para fins de liquidação de pagamentos instantâneos.
PIX
Nome do arranjo de pagamentos instantâneos que será instituído pelo BC, que
também corresponde ao instrumento de pagamento.
Prestador de Serviços de Pagamento (PSP)
Instituição ou empresa que provê serviços de pagamento para um usuário final.
PSP do pagador
PSP no qual o usuário pagador detém a conta transacional que será debitada para a
realização de um pagamento instantâneo.
PSP do recebedor
PSP no qual o usuário recebedor detém a conta transacional que será creditada em
decorrência de um pagamento instantâneo.
Provedor de Serviços de Tecnologia da Informação (PSTI)
Entidade autorizada pelo Comitê Gestor a prestar serviços de processamento de

dados, para fins de acesso à RSFN, a instituições financeiras e a demais instituições
autorizadas a funcionar pelo BC, por meio de centros de serviços de informática
compartilhados, nos termos do Capítulo VII da Circular nº 3.629, de 19 de fevereiro de
2013. Corresponde às empresas de conectividade referenciadas no Comunicado nº
32.927, de 21 de dezembro de 2018, como switch.
QR Code
Código de barras bidimensional gerado por um usuário final, com a finalidade de

facilitar a iniciação da transação de pagamento no âmbito do PIX.
157
QR Code Dinâmico
QR Code gerado pelo usuário recebedor, para ser utilizado uma única vez, para iniciar
um pagamento instantâneo.
QR Code Estático
QR Code gerado pelo usuário recebedor, que pode ser utilizado para iniciar mais de
um pagamento instantâneo.
QR Code Gerado pelo pagador
QR Code gerado pelo usuário pagador, que pode ser gerado sem utilização de rede
de dados, para ser utilizado uma única vez, para iniciar um pagamento instantâneo.
Sistema de Pagamentos Instantâneos (SPI)
Infraestrutura centralizada e única de liquidação bruta e em tempo real do

ecossistema de pagamentos instantâneos brasileiro.
Timeout
Extrapolação do limite de tempo, determinado pelo gestor do sistema, que causa a

rejeição de uma transação de pagamento instantâneo.
Usuário final
Pessoa natural ou jurídica ou ente governamental que utiliza um serviço de

pagamento instantâneo, como pagador ou como recebedor.
Usuário pagador
Usuário final que, no processamento da transação de pagamento instantâneo, tem a

sua conta transacional debitada.
Usuário recebedor
Usuário final que, no processamento da transação de pagamento instantâneo, tem a

sua conta transacional creditada.
158
Histórico de revisão
Data Versão Descrição das alterações
28/5/2019 1.0
22/7/2019 2.0 1 – Estrutura: introdução da seção “3. Sistema de
Pagamentos Instantâneos”, que apresenta tópicos
diretamente relacionados ao SPI.
2 – Apresentação: ajustes no texto e inserção de

quadro-síntese sinalizando o status da discussão dos
diversos tópicos que estão sendo tratados.
3 – Seção 1: mudança no diagrama que apresenta os

tipos de liquidação e as opções para iniciação do
pagamento no PIX.
4 – Seção 1: introdução das subseções “1.3. Cenários de

insucesso na liquidação de pagamentos instantâneos”,
que apresenta os fluxos de tratamento de cenários de
insucesso da comunicação entre o SPI e os PSPs do
pagador e do recebedor e “1.4. Diagrama de estados na
liquidação de pagamentos instantâneos”, que
apresenta os possíveis estados de cada um dos
participantes envolvidos numa transação de
pagamento instantâneo, incluindo os usuários finais.
5 – Seção 1.1: mudança nas situações em que ocorrerá

timeout nas transações que cursam no PIX.
6 – Seção 1.1.1.1: ajustes no fluxo. A confirmação do

pagamento deve fazer parte de etapa prévia ao fluxo de
pagamento. Assim, esse fluxo tem início com o
recebimento de ordem de pagamento.


159
9 – Seção 1.2: inseridas subseções relativas ao envio
prévio sistematizado de informações, que passam a ser
caracterizados como QR Code estático, QR Code
dinâmico e QR Code Gerado pelo pagador. Além disso,
questões relativas ao padrão e ao layout das
informações no QR Code foram transferidas da seção 2
para essa seção.
10 – Seção 1.2.1: ajustes no fluxo. A confirmação do

pagamento deve fazer parte de etapa de inserção dos
dados para iniciação do pagamento.
11 – Seção 2: inclusão da seção “2.1. Participação no

arranjo”, que apresenta os critérios de participação no
arranjo. Transferência da seção sobre a arquitetura do
sistema de liquidação para a seção 3, subseção 3.1,
agora denominada “Arquitetura básica do SPI”.
Transferência da seção sobre QR Code para a seção
1.2.2.4.
12 – Seção 2.5: introdução da seção “2.5.1. Chaves para

endereçamento”, que apresenta as chaves que serão
aceitas pela base de dados de endereçamento.
3/9/2019 3.0 1 – Estrutura: exclusão das seções “1.1.1. Liquidação

prioritária” e “1.1.2. Liquidação não prioritária”. Fluxos
de liquidação, prioritária e não prioritária, são iguais,
não havendo a necessidade de seções específicas sobre
cada tipo de liquidação.
2 – Estrutura: ajustes na nomenclatura em todas as

subseções da seção “1.3. Cenários de insucesso na
liquidação de pagamentos instantâneos”, para deixar a
redação do texto mais clara e objetiva.
3 – Estrutura: exclusão da seção “1.4. Diagrama de

estados na liquidação de pagamentos instantâneos”. Os
fluxos da seção já estão disponíveis ao longo do texto
deste Documento.
4 – Estrutura: ajuste na nomenclatura da seção 2.1.

“Participação no ecossistema” para “Participação no
arranjo”. Ajuste para refletir a diferença conceitual entre
ecossistema, arranjo e infraestrutura de liquidação.
160
5 – Estrutura: inserção da seção 2.5. “Requisitos de
segurança”.
6 – Estrutura: ajustes na nomenclatura de diversas

subseções da seção 3.4. “Gestão da Conta PI”, para
deixar a redação do texto mais clara e objetiva.
7 – Estrutura: inserção das subseções 3.4.7 e 3.4.8, que

tratam de funções que o SPI ofertará para a gestão de
participantes indiretos.
8 – Estrutura: inserção da seção 3.6. “Tarifas”, que trata

dos princípios de tarifação do SPI.
9 – Estrutura: inserção de glossário, com definição dos

principais conceitos utilizados neste Documento.
10 – Apresentação: ajustes e atualização do texto, com

destaque para a definição de ecossistema de
pagamentos instantâneos brasileiro.
11 – Seção 1.1: ajustes nos fluxos, a fim de incorporar

etapas necessárias para ordens de pagamento para
liquidação não prioritária.
12 – Seção 1.2: ajustes nos fluxos, a fim de incorporar

etapas necessárias para ordens de pagamento para
liquidação não prioritária.
13 – Seção 1.2.2.4: inserção do conjunto de informações

contido em cada tipo de QR Code.
14 – Seção 1.3: ajuste no conceito de timeout.
15 – Seção 2.1: ajuste no texto para refletir a diferença

conceitual entre ecossistema, arranjo e infraestrutura
de liquidação.
16 – Seção 2.5: incorporação do texto que reflete

decisão do BC tornada pública por meio do Comunicado
nº 34.085, de 28 de agosto de 2019.
17 – Seção 2.5.1: ajustes no texto para deixar a redação

mais clara e objetiva.
18 – Seção 3.2: ajuste no texto para refletir a diferença

conceitual entre ecossistema, arranjo e infraestrutura
de liquidação.
161
19 – Seção 3.4: ajustes no texto e nos fluxos para deixá-
los mais claros.
20 – Seção 3.5: incorporação de texto.
10/10/2019 3.1 1 – Estrutura: inserção da subseção 2.2.1. “Padrão de

representação das mensagens”.
2 – Estrutura: inserção da subseção 2.3.1. “Interface de

comunicação”.
3 – Estrutura: inserção da subseção 2.5.5. “Manutenção

de logs de segurança”.
4 – Apresentação: atualização do status das discussões.
5 – Seção 1.2.2.1: pequena alteração de texto e inclusão

de nota de rodapé fazendo referência ao fato de que o
fluxo do pagador ali estabelecido é, na verdade, do
pagador online e que o pagador off-line usa o fluxo do
QR Code gerado pelo pagador.
6 – Seção 1.2.2.2: divisão do fluxo (e do passo a passo)

de QR Code dinâmico em duas partes: do recebedor e
do pagador.
7 – Seção 1.2.2.3: novo fluxo do QR Code gerado pelo

pagador.
8 – Seção 1.2.2.4: inclusão de campos nos QR Codes

estático, dinâmico e gerado pelo pagador.
9 – Seção 2.5.2: definido padrão de assinatura digital.
10 – Seção 3.1: definição da arquitetura básica do SPI
11 – Seções 3.4.1, 3.4.2 e 3.4.3: ajustes no texto para

deixar a redação mais clara e prestar mais
esclarecimentos.
21/11/2019 4.0 1 – Estrutura: inserção das subseções 2.6.2, 2.6.3, 2.6.4,

2.6.5, 2.6.6, 2.6.7, 2.6.8, 2.6.9 e 2.6.10 na seção sobre o
DICT.
2 – Estrutura: inserção da seção 2.8. “Idempotência”.
3 – Estrutura: inserção da seção 3.3. “Mecanismos de

liquidez providos pelo BC”.
162
5 – Seções 2.5.1, 2.5.2, 2.5.3 e 2.5.4: ajustes pontuais no

texto.
6 – Seção 2.6.1: ajustes pontuais no texto.
7 – Seção 3.2.1: exclusão de nota de rodapé sobre

liquidante no SPI.
8 – Seção 3.4.1: ajuste na definição do saldo de

fechamento de dia anterior.
9 – Seção 3.4.6: ajustes para refletir o conceito de

idempotência.
21/2/2020 5.0 1 – Estrutura: introdução do nome PIX para identificar o

arranjo instituído pelo BC e o meio de pagamento que
será utilizado pela população.
2 – Estrutura: inserção da seção 1.4. “Devolução do PIX”,

que apresenta a especificação do fluxo de devolução do
PIX.
3 – Estrutura: inserção da seção 2.6.5. “Fluxo de

portabilidade”, que é uma nova funcionalidade do DICT.
4 – Estrutura: inserção da seção 2.6.6. “Fluxo de

reivindicação de posse”, que é uma nova funcionalidade
do DICT.
5 – Estrutura: inserção da seção 2.6.9. “Disponibilidade

das funcionalidades”, que apresenta as janelas de
disponibilidade de cada funcionalidade do DICT.
7 – Seção 1.3.1.1: definição da diferença entre as

respostas do SPI enviadas via ADMI.002 e via PACS.002.
8 – Seção 1.3.3: inclusão da mensagem de confirmação

de insucesso ao PSP do recebedor.
9 – Seção 2.1: detalhamento dos critérios e das

modalidades de participação no PIX.
10 – Seção 2.3: menção à versão 9.0 do Manual de Redes

do SFN, que apresenta detalhes acerca da conexão à
RSFN pela Internet, intermediada pelo PSTI.
163
11 – Seção 2.5: ajustes e atualizações.
12 – Seção 2.6.1: introdução de uma nova chave para

endereçamento: EVP.
13 – Seção 2.6.2: ajustes nas regras de acesso.
14 – Seção 2.6.3: ajustes decorrentes da inserção das

seções sobre o fluxo de portabilidade e o fluxo de
15 – Seção 2.6.4: nova possibilidade de exclusão

comandada por PSP e ajustes no texto decorrentes da
inserção das seções sobre o fluxo de portabilidade e o
fluxo de reivindicação de posse.
16 – Seção 2.6.7 (seção 2.6.6 da versão 4.0):

determinação de que o CNPJ não será mascarado.
17 – Seção 2.6.8: introdução de texto na seção

(corresponde à seção 2.6.7 da versão 4.0).
18 – Seção 3.2: detalhamento dos critérios e das

modalidades de participação no SPI.
19 – Seção 3.3.2.1: definição da grade da janela adicional

para aporte em Conta PI a partir de RB/CL e CCME e
detalhamento da possibilidade de configuração de
transferência de percentual dos saldos em conta
RB/CL/CCME ou de valor específico.
20 – Seção 3.3.2.2: detalhamento da operação de

liquidez com TPF no Selic para instituições financeiras.
21 - Seções 3.4.1, 3.4.2 e 3.4.3: esclarecimento do prazo

máximo para consulta de saldo de fechamento de dias
anteriores e de relação e detalhes de lançamentos.
22 – Seção 3.4.7: esclarecimento do identificador

utilizado para vincular um participante indireto ao
liquidante no SPI.
164

Documento de Especificações - Versão 5-0

Enviado por

Direitos autorais:

Formatos disponíveis

Documento de Especificações - Versão 5-0

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Documento de Especificações - Versão 5-0

Enviado por

Direitos autorais:

Formatos disponíveis

Especificações técnicas e de negócio

Este documento é um trabalho em construção, sob constante atualização, e que serve

O diretório de endereçamento é o componente do PIX que armazenará as

A terceira seção apresenta os tópicos diretamente relacionados à infraestrutura

Serão inseridos neste documento os tópicos cujo direcionamento já está definido no

Tópico Status da discussão

• Anexo I – Manual de Iniciação de Pagamentos

Sugestões, críticas ou pedidos de esclarecimento de dúvidas devem ser enviados ao

No PIX, no processo de efetivação do pagamento, o usuário pagador poderá definir se

O diagrama abaixo apresenta os tipos de liquidação e as opções para iniciação do

Esta seção apresenta (i) os fluxos do processo de efetivação do pagamento, incluindo

Além dos fluxos do processo de efetivação do pagamento e do processo de inserção

1.1. Processo de efetivação do PIX

Do ponto de vista do SPI, a única diferença entre as ordens de pagamento para

D-n até D-1 D0

23h30 0h 8h 9h30 10h

Usuário pagador PSP do pagador

A seguir, são apresentados e detalhados os fluxos das transferências enviadas para

1.1.1. Fluxo de transações entre participantes diretos

Note-se que, para as ordens de pagamento enviadas para liquidação prioritária, a

1.1.2. Fluxo de transações entre participantes indiretos

Assim como no caso em que a transferência ocorre entre participantes diretos, a

Para a aferição do limite de tempo em que a ordem para liquidação prioritária

Ressalte-se que os fluxos de comunicação envolvendo o SPI estão caracterizados

# Camada Tipo Descrição

1.2. Processo de inserção dos dados para iniciação do PIX

No processo estruturado prévio, informações sobre o pagamento serão enviadas com

1.2.1. Inserção manual dos dados pelo pagador

Existem dois fluxos diferentes, a depender da forma de acesso ao DICT. Apresenta-se

Apresenta-se, a seguir, o fluxo da inserção manual dos dados, no caso de o PSP do

1.2.2. Envio prévio sistematizado de informações

O usuário recebedor pode gerar as informações de pagamento de três formas

1.2.2.1. QR CODE ESTÁTICO

A seguir, o fluxo de geração do QR Code Estático pelo usuário recebedor:

4 PSP do pagador Comunicação PSP do pagador recebe dados do QR Code.

PSP do pagador encaminha dados do QR Code ao diretório de

1.2.2.2. QR CODE DINÂMICO

Como a geração da requisição de pagamento é dinâmica, o sistema de conciliação dos

Apresenta-se, a seguir, o fluxo de geração do QR Code dinâmico pelo usuário

# Camada Tipo Descrição

1.2.2.3. QR CODE GERADO PELO PAGADOR

16 DICT Mensagem DICT recebe a consulta.

DICT efetua a consulta e retorna os dados de identificação do

1.2.2.4. PADRÃO DO QR CODE: LAYOUT DAS INFORMAÇÕES

O fato de as especificações do padrão EMV® já estarem prontas facilita o processo de

No QR Code dinâmico, as informações relativas à transação serão disponibilizadas por

A solução por URL/URI apresenta três níveis de segurança:

a. o aplicativo leitor do QR Code só respeitará URLs https que apresentem um

O QR Code estático conterá o seguinte conjunto de informações:

O QR Code dinâmico conterá as seguintes informações:

A URL/URI vinculada ao QR Code dinâmico conterá as seguintes informações:

QR Code gerado pelo pagador

*apenas se QR Code do recebedor for estático

A forma de inserção desses campos no padrão EMV® e o detalhamento do seu

1.3. Cenários de insucesso na liquidação do PIX

Nesta seção são apresentados os fluxos de tratamento de cenários de insucesso da

Os cenários de insucesso aqui descritos apresentam validações do ponto de vista do

Os tratamentos de insucesso descritos nesta seção se aplicam também aos casos em

A má formação da mensagem de pagamento será comunicada por meio da