The Invisible Tracks of Pix
When a user taps 'confirm' on a Pix, something remarkable happens: in less than 10 seconds, money leaves an account in one institution, crosses the Central Bank's infrastructure, and definitively arrives in another account — at another institution, in another bank, possibly in another state.
For the end user, it's magic. For those who operate the infrastructure, it's the result of a real-time gross settlement system operating with millisecond-to-millisecond precision, 24 hours a day, 365 days a year, with zero tolerance for financial inconsistencies.
This article dismantles that magic. We explain how the SPI, the DICT, and the PI Account work — individually and together — and we walk through the complete flow of a Pix transaction from start to finish. The goal is for Product Managers to have enough clarity to make informed product decisions, and for engineers and architects to have the necessary conceptual map before diving into the Central Bank's technical documentation.
📌 Context: If you are evaluating whether it is worth becoming a direct participant in Pix, we recommend starting with the strategic guide Direct Pix: what it is, how it works, and when it is worth it — which covers the business context before the technical architecture.
Os sete sistemas que sustentam o Pix Direto
A infraestrutura do Pix Direto não é um único sistema — é um ecossistema de componentes interdependentes, cada um com uma função específica. Antes de entrar em profundidade em cada um, vale ter o mapa completo:
Sigla | Nome completo | Operado por | Função no Pix Direto |
|---|---|---|---|
SPI | Sistema de Pagamentos Instantâneos | Banco Central do Brasil | Liquidação financeira definitiva das transações em tempo real na conta PI |
DICT | Diretório de Identificadores de Contas Transacionais | Banco Central do Brasil | Registro e consulta de chaves Pix — associação chave → conta |
Conta PI | Conta de Pagamentos Instantâneos | Banco Central do Brasil | Conta de liquidação da instituição no SPI — onde o dinheiro de fato entra e sai |
RSFN | Rede do Sistema Financeiro Nacional | Banco Central do Brasil | Canal de comunicação seguro entre participantes e a infraestrutura do BC |
FRAUD | Mecanismo de Prevenção à Fraude do Pix | Banco Central do Brasil | Base compartilhada de dados de fraude entre todos os participantes diretos |
ISO 20022 | Padrão internacional de mensageria financeira | ISO / SWIFT | Protocolo de formato das mensagens trocadas com SPI e DICT |
ICP-Brasil | Infraestrutura de Chaves Públicas Brasileira | ITI (gov.br) | Autenticação e assinatura digital das mensagens ao BC |
Os três primeiros — SPI, DICT e Conta PI — são o núcleo da operação. Os demais são a camada de suporte que torna esse núcleo seguro, confiável e regulatoriamente adequado. Nenhum participante direto funciona sem todos eles.
SPI — Sistema de Pagamentos Instantâneos
SPI is the backbone of Pix. It is the system operated by the Central Bank that performs the definitive financial settlement of each transaction — debiting the paying institution's PI account and crediting the receiving institution's PI account in real time.
The RTGS model and why it matters
SPI operates on the RTGS model — Real-Time Gross Settlement. This means that each transaction is settled individually, definitively, and irrevocably, at the moment it is processed. There is no subsequent clearing, no multilateral netting, no risk of reversal due to settlement failure.
This model has a critical implication for those who operate Direct Pix: settlement is final. Once the SPI confirms that the transaction has been settled, it cannot be undone by the infrastructure. Any returns are new transactions — not reversals of the original one. This has direct consequences for the design of anti-fraud and dispute management systems.
Availability and operating windows
SPI operates 24 hours a day, 7 days a week, 365 days a year — including holidays and weekends. There is no planned downtime window by the Central Bank that interrupts transaction processing.
For direct participants, this defines the minimum required SLA: 99.5% availability, with no exception for day or time. Any maintenance that affects the ability to process transactions must be communicated to the Central Bank in advance, and counts as planned downtime for SLA calculation purposes.
How SPI connects to the institution
Communication with SPI is done exclusively via RSFN — the National Financial System Network — using messages in ISO 20022 format. There is no REST API, no webhook, no connection via the public internet. It is a dedicated channel, with authentication via ICP-Brasil certificate and validation of format and signature on each message.
⚙️ Technical implication: Integrating with SPI is not a task of 'calling an API'. It is the implementation of a financial messaging protocol with strict rules for format, field order, digital signature, and error handling. Teams without prior experience in ISO 20022 should plan for an extended timeline for this phase of the project.
Os sete sistemas que sustentam o Pix Direto
A infraestrutura do Pix Direto não é um único sistema — é um ecossistema de componentes interdependentes, cada um com uma função específica. Antes de entrar em profundidade em cada um, vale ter o mapa completo:
Sigla | Nome completo | Operado por | Função no Pix Direto |
|---|---|---|---|
SPI | Sistema de Pagamentos Instantâneos | Banco Central do Brasil | Liquidação financeira definitiva das transações em tempo real na conta PI |
DICT | Diretório de Identificadores de Contas Transacionais | Banco Central do Brasil | Registro e consulta de chaves Pix — associação chave → conta |
Conta PI | Conta de Pagamentos Instantâneos | Banco Central do Brasil | Conta de liquidação da instituição no SPI — onde o dinheiro de fato entra e sai |
RSFN | Rede do Sistema Financeiro Nacional | Banco Central do Brasil | Canal de comunicação seguro entre participantes e a infraestrutura do BC |
FRAUD | Mecanismo de Prevenção à Fraude do Pix | Banco Central do Brasil | Base compartilhada de dados de fraude entre todos os participantes diretos |
ISO 20022 | Padrão internacional de mensageria financeira | ISO / SWIFT | Protocolo de formato das mensagens trocadas com SPI e DICT |
ICP-Brasil | Infraestrutura de Chaves Públicas Brasileira | ITI (gov.br) | Autenticação e assinatura digital das mensagens ao BC |
Os três primeiros — SPI, DICT e Conta PI — são o núcleo da operação. Os demais são a camada de suporte que torna esse núcleo seguro, confiável e regulatoriamente adequado. Nenhum participante direto funciona sem todos eles.
SPI — Sistema de Pagamentos Instantâneos
SPI is the backbone of Pix. It is the system operated by the Central Bank that performs the definitive financial settlement of each transaction u2014 debiting the PI account of the paying institution and crediting the PI account of the receiving institution in real time.
The RTGS model and why it matters
SPI operates on the RTGS (Real-Time Gross Settlement) model. This means that each transaction is settled individually, definitively, and irrevocably at the moment it is processed. There is no subsequent clearing, no multilateral netting, and no risk of reversal due to settlement failure.
This model has a critical implication for those who operate Direct Pix: settlement is final. Once SPI confirms that the transaction has been settled, it cannot be undone by the infrastructure. Any returns are new transactions u2014 not reversals of the original one. This has direct consequences for the design of anti-fraud systems and dispute management.
Availability and operating windows
SPI operates 24 hours a day, 7 days a week, 365 days a year u2014 including holidays and weekends. There is no planned downtime window by the Central Bank that interrupts transaction processing.
For direct participants, this defines the minimum required SLA: 99.5% availability, with no exception for day or time. Any maintenance that affects the ability to process transactions must be communicated to the Central Bank in advance, and counts as planned downtime for the purposes of SLA calculation.
How SPI connects to the institution
Communication with SPI is done exclusively via RSFN u2014 the National Financial System Network u2014 using messages in ISO 20022 format. There is no REST API, no webhook, and no connection via the public internet. It is a dedicated channel, with authentication by ICP-Brasil certificate and validation of format and signature on each message.
u2699ufe0f Technical implication: Integrating with SPI is not a task of 'calling an API'. It is the implementation of a financial messaging protocol with strict rules for format, field order, digital signature, and error handling. Teams without prior experience in ISO 20022 should budget for an extended timeframe for this phase of the project.
DICT — Diretório de Identificadores de Contas Transacionais
If the SPI is where the money moves, the DICT is where identities are resolved. The DICT is the centralized directory — also operated by the Central Bank — that associates each Pix key with a specific bank account.
Without the DICT, Pix would just be a faster TED transfer: you would need to know the recipient's branch, account, and bank. The DICT is what makes it possible to send money using only a CPF, a mobile number, or a random key — because it is what translates that key into a real account at a real institution.
Key types and their specifics
Key type | What it is | Usage | Operational specifics |
|---|---|---|---|
CPF / CNPJ | Account holder's document | High — most used key by individuals and legal entities | Requires validation with the Federal Revenue Service (Receita Federal) |
Holder's email address | Medium — common in digital accounts | Holder can have multiple emails per account | |
Mobile phone | Phone number with area code | High — especially in individual accounts | Frequent portability requires updates in the DICT |
Random key (EVP) | System-generated UUID, with no personal data | Growing — preferred by those who prioritize privacy | No link to personal data — good for billing |
Operations that the direct participant performs in the DICT
By integrating with the DICT, the institution is not just a consumer — it is also a data producer. The main operations a direct participant needs to implement are:
Key registration: when an institution's customer wants to create a Pix key, the institution registers the association between the key and the customer's account in the DICT.
Key query: before processing any outbound transaction, the institution queries the DICT using the key provided by the payer to obtain the destination account details.
Portability: when a customer wants to move a key from another institution to theirs, the institution initiates the portability process in the DICT, which has a defined regulatory timeframe.
Claim: when a customer wants to recover a key (such as their own CPF) that is registered at another institution, the institution conducts the claim process.
Deletion: when a customer closes the account or requests the removal of a key.
DICT and LGPD: what the direct participant needs to consider
The DICT stores and processes personal data of users — CPF, CNPJ, email, mobile phone. As a direct participant, the institution is responsible for processing this data in compliance with the LGPD, including consent, purpose, and retention period. The Central Bank also imposes restrictions on how data queried in the DICT can be used — key queries can only be made in the context of a legitimate transaction, not for registration data enrichment purposes.
Conta PI — a conta de liquidação no Banco Central
A Conta PI (Conta de Pagamentos Instantâneos) é o elemento que define estruturalmente um participante direto do Pix. É por meio dela que as transações são efetivamente liquidadas — o dinheiro que entra e sai das transações Pix passa pelo saldo da Conta PI da instituição no SPI.
Ter uma Conta PI não é apenas uma questão técnica — é uma posição regulatória. Ela representa que a instituição foi autorizada pelo Banco Central a participar diretamente do sistema de liquidação instantânea do país.
Conta PI vs. conta corrente: as diferenças que importam
Característica | Conta PI | Conta corrente comum |
|---|---|---|
Quem pode ter | Apenas participantes diretos do Pix autorizados pelo BC | Qualquer instituição financeira autorizada |
Onde é mantida | Banco Central do Brasil (SPI) | Banco comercial / IF autorizada |
Finalidade | Exclusivamente para liquidação de transações Pix | Movimentação financeira geral |
Rendimento | Remunerada pela taxa SELIC (overnight) | Variável conforme contrato |
Acesso | Via mensageria ISO 20022 ao SPI | Via sistemas internos da instituição financeira |
Saldo mínimo | Deve cobrir as obrigações de liquidação do dia | Conforme política da instituição |
Controle | BC monitora em tempo real | Monitoramento interno da instituição |
Risco de liquidação | Zero — liquidação é definitiva no BC | Risco de contraparte conforme instituição |
Gestão de liquidez na Conta PI
Um aspecto operacional crítico que frequentemente surpreende fintechs em implementação: a Conta PI precisa ter saldo suficiente para cobrir as obrigações de liquidação em tempo real. Diferente de um modelo de compensação (onde débitos e créditos são netteados ao fim do dia), no SPI cada débito é processado individualmente — e se a Conta PI não tiver saldo suficiente no momento da transação, ela é recusada.
Isso exige um sistema de gestão de liquidez em tempo real: monitoramento contínuo do saldo da Conta PI, regras de recomposição de saldo e alertas de nível crítico. Em dias de alto volume — como início de mês ou datas de pagamento de salários — a pressão sobre a liquidez pode ser significativa.
💡 Remuneração da Conta PI: O saldo mantido na Conta PI é remunerado pela taxa SELIC overnight. Para instituições com alto volume de transações e saldo médio relevante, essa remuneração pode representar uma receita financeira adicional que compensa parte do OPEX da operação.
Mensageria e protocolos: ISO 20022, RSFN e ICP-Brasil
The communication layer between the direct participant and the Central Bank's infrastructure is composed of three elements that work together: the format protocol (ISO 20022), the transport channel (RSFN), and the authentication mechanism (ICP-Brasil).
ISO 20022: the language of financial messaging
ISO 20022 is the international financial messaging standard adopted by the Central Bank for Pix. Messages are structured in XML, with strictly defined schemas that specify each field, its type, size, and mandatory status.
The standard defines different message types for different operations: transaction initiation, settlement confirmation, status query, error notification, DICT operations, among others. Each message type has its own XML schema and set of validations.
For the engineering team, this means: implementing XML schema parsers and validators, handlers for each message type, retry logic with backoff for transient failures, and a robust message logging and tracking system — because in the event of a dispute or audit, the message trail is the evidence.
RSFN: the dedicated channel
The RSFN (National Financial System Network) is the dedicated and secure network infrastructure through which ISO 20022 messages travel between participants and the Central Bank. It is a private network, separate from the public internet, with specific connectivity and redundancy requirements.
To connect to the RSFN, the institution needs to contract a connectivity provider certified by the BC. The contracting, configuration, and testing process of the RSFN connection is one of the first tasks of the implementation project — and one of those that usually surprise the most regarding deadlines, especially when the provider has a service queue.
ICP-Brasil: authenticity and integrity of messages
Each message sent to the SPI or DICT must be digitally signed with an ICP-Brasil certificate. This signature guarantees two things: that the message was sent by the institution claiming to have sent it (authentication), and that the content was not altered in transit (integrity).
ICP-Brasil certificates have an expiration date and must be renewed periodically. A poorly structured certificate management process — without expiration alerts and clear renewal procedures — is a real source of downtime incidents that can compromise the SLA.
Antifraude e segurança: a responsabilidade que não pode ser terceirizada
In the indirect model, the partnering direct participant is the primary party responsible for anti-fraud. In the direct model, this responsibility shifts entirely to the institution — and there is no regulatory middle ground.
The FRAUD mechanism
FRAUD is the Central Bank's centralized system that allows the sharing of information about suspicious transactions and fraudulent accounts among all direct Pix participants. Integration with FRAUD is mandatory and bidirectional: the institution queries data from other participants and reports data about identified frauds in its database.
Sharing via FRAUD is one of the most effective real-time fraud detection mechanisms in the Pix ecosystem — because fraudsters rarely operate in a single institution. An account reported as fraudulent by one participant becomes available for query by all others within minutes.
Own detection layer
In addition to integration with FRAUD, the BC requires each direct participant to maintain its own fraud detection and prevention layer — with rules, models, and processes appropriate to the risk profile of its customer base.
This layer must operate in real-time, within the same transaction cycle: the decision to approve or reject a transaction based on fraud criteria must happen before the debit message is sent to the SPI. This imposes significant latency constraints on anti-fraud systems.
Infrastructure resilience and security
In addition to transactional anti-fraud, the BC requires that the direct participant's infrastructure be resilient to attacks: DDoS, message injection attempts, unauthorized access to certificates, and production environments. Periodic security audits and intrusion tests are operational requirements, not optional.
🔗 Cost of this structure: The cost of setting up and operating the anti-fraud and security layer — including an in-house system, integration with FRAUD, audits, and a dedicated team — represents one of the largest lines of monthly OPEX for Direct Pix. Details can be found in the article How much does it cost to operate with Direct Pix?
Fluxo completo de uma transação Pix: do toque à liquidação
With the map of each component in hand, it is possible to follow the complete flow of a Pix transaction — from the user's action to the settlement confirmation at the Central Bank. The full process takes less than 10 seconds in the vast majority of cases.
# | Step | Who executes | What happens |
|---|---|---|---|
1 | Initiation | Payer | User enters Pix key, amount, and confirms the transaction in the app or website of the paying institution. |
2 | DICT Query | Paying institution → DICT | The institution queries DICT using the provided key. DICT returns: destination account, holder's name, and receiving institution. |
3 | Validation and authorization | Paying institution | The institution validates the data returned by DICT, applies anti-fraud rules, and authorizes (or rejects) the transaction. |
4 | Debit message to SPI | Paying institution → SPI | The institution sends an ISO 20022 message to SPI requesting the debit from its PI account and credit to the receiving institution's PI account. |
5 | Settlement in SPI | SPI (Central Bank) | SPI processes the message, checks the payer's PI account balance, debits the payer's PI account, and credits the receiver's PI account. Final and irrevocable settlement. |
6 | Confirmation to receiver | SPI → Receiving institution | SPI notifies the receiving institution of the settlement. The receiving institution credits the amount to the end user's account. |
7 | Confirmation to payer | Paying institution → Payer | The paying institution confirms to the end user that the transaction was completed successfully. |
What happens in less than 10 seconds
The total latency perceived by the user — from tapping 'confirm' to the 'Pix sent' screen — is the result of all the steps above happening in sequence, with communication via RSFN, processing in SPI, and notifications between institutions. The BC defines maximum latency limits for each step, and participants that consistently exceed these limits may receive regulatory notifications.
For the engineering team, this means that every component of the stack — from the initiation API to the SPI confirmation handler — must have its latency monitored individually. A slow component can make the user wait longer than expected, without it being obvious which part of the chain is the bottleneck.
Error flows: what happens when something fails
SPI defines precisely what happens when a transaction fails at each step: rejection messages with standardized error codes, retry timeframes, end-user notification obligations. A direct participant must implement handlers for each error scenario — and ensure the end user receives a clear and precise message about what happened, within regulatory deadlines.
⚠️ Attention point: Error flows are often underdeveloped in the first version of an integration to SPI. The focus naturally goes to the 'happy path'. But it is in error scenarios that the user experience differs most between institutions — and where regulatory incidents tend to appear.
Direct and indirect participants: how architecture reflects responsibility
The distinction between a direct and indirect participant is not just regulatory — it has direct consequences on the technical topology of the operation.
In the direct model, the institution maintains its own connection to SPI, its own DICT registration, and its own PI Account. It is, technically, an active node in the Pix infrastructure.
In the indirect model, the institution accesses Pix through the APIs of the partner direct participant — which in turn communicates with SPI, DICT, and other BC systems. From the perspective of the BC's infrastructure, the indirect participant does not exist: all messages arrive with the identity of the direct participant.
This has an important regulatory implication: the direct participant is liable for the behavior of all indirects operating under its infrastructure. If an indirect has inadequate anti-fraud or compliance practices, the hosting direct participant may face regulatory consequences for failures that were not its own.
📊 Strategic implication: For fintechs that intend to become direct participants and offer access to Pix to other players (BaaS model), the design of controls over indirect participants is as important as the technical integration to SPI itself. Resolution BCB No. 429/2024 defines the monitoring obligations that a direct participant has over its indirects.
Technical glossary of Direct Pix
A quick reference of the most relevant technical terms for those working with Direct Pix infrastructure:
Term | Definition |
|---|---|
RTGS | Real-Time Gross Settlement. Settlement model in which each transaction is processed individually and definitively at the time it occurs — without netting or subsequent clearing. SPI operates under this model. |
ISO 20022 | An XML-based international standard for financial messaging, developed by ISO. It defines the structure and content of messages exchanged between participants and SPI/DICT. It replaces legacy formats like SWIFT MT. |
ICP-Brasil | Brazilian Public Key Infrastructure. Digital certification system of the Brazilian government that ensures the authenticity and integrity of messages sent to the BC. Every direct participant needs an ICP-Brasil certificate. |
EVP | Virtual Payment Address. Technical name of the random key — a UUID generated by the system with no association with the holder's personal data. |
ISPB | Identifier of the Brazilian Payments System. A unique 8-digit code that identifies each participant in SPI. Equivalent to the bank code, but specific to the SPI environment. |
Netting | Multilateral clearing process in which debits and credits among multiple parties are consolidated before settlement. SPI does not use netting — each Pix transaction is settled individually (RTGS). |
DR / DRP | Disaster Recovery / Disaster Recovery Plan. Infrastructure and contingency plan for recovering operations in the event of a catastrophic failure. Required by the BC for direct participants. |
SLA | Service Level Agreement. In the context of Direct Pix, the BC requires a minimum availability of 99.5% for direct participants, with reporting of incidents affecting this rate. |
Key Portability | The process by which a user transfers a Pix key (e.g., their CPF) from one institution to another. It involves operations in DICT and has a regulatory timeframe defined by the BC. |
Indirect participant | An institution or company that accesses Pix through a direct participant, without having its own PI account inside SPI. The direct participant is responsible for the indirect's operation before the BC. |
Conclusão: a infraestrutura como vantagem competitiva
Understanding the Direct Pix architecture — SPI, DICT, PI Account, messaging, anti-fraud — is not an academic exercise. It is what separates well-founded product decisions from decisions based on wrong assumptions about what is possible, what is expensive, and what is fast to implement.
For Product Managers, this conceptual map is what allows specifying features with precision, estimating complexity with realism, and having productive conversations with the engineering team. For engineers and architects, it is the starting point before the Central Bank's technical documentation — which is detailed, but not contextualized.
The Direct Pix infrastructure is complex — but it is a structured complexity, with well-defined components and public documentation. Those who understand it deeply have a real advantage over those who treat it as a black box.
🚀 Next step: Explore how the PISP (Payment Initiation Service Provider) in Open Finance uses this infrastructure to create a new layer of financial products — and why checkout without redirection is changing conversion in Brazilian e-commerce. Read: PISP in Open Finance: how payment initiation via Pix is changing checkout.
Related reading in this cluster
→ Direct Pix: what it is, how it works, and when it is worth it
→ How to become a direct Pix participant: technical and regulatory requirements
→ How much does it cost to operate with Direct Pix? Infrastructure, compliance, and real TCO
→ PISP in Open Finance: how payment initiation via Pix is changing checkout
