This is not just a technology project
There is a common perception in the early stages of evaluating Direct Pix: 'it is just an API integration'. Technically, there is truth to that — but operationally, it is a simplification that usually costs dearly.
Becoming a direct participant of Pix is an organizational transformation. It involves engineering, compliance, legal, risk, operations, and product — all simultaneously, with interdependencies that do not become evident until someone gets stuck in a phase because they expected another to be ready.
This guide was written for teams that are past the 'is it worth it?' stage and need to understand what is concretely involved. We cover the Central Bank requirements, the mandatory technical integrations, the teams and responsibilities, the project steps with a realistic timeline — and, mainy, the most common mistakes fintechs make that delay or derail the process.
📌 Context: If you are still in the phase of deciding between Direct and Indirect Pix, we recommend starting with the article Direct Pix vs. Indirect Pix: which model makes more sense for your fintech? — which includes the decision matrix by company profile and the comparative cost analysis.
Requisitos do Banco Central: o que é inegociável
O Banco Central define com precisão as condições para que uma instituição seja aceita como participante direta do Pix. Não há grau de flexibilidade nesses requisitos — eles são a linha de corte entre estar ou não apto a operar.
A Resolução BCB n.º 429/2024 é o documento normativo central, mas o quadro regulatório completo inclui também o Regulamento do Pix, o Manual de Padrões para Iniciação do Pix (MP Pix) e circulares complementares. O processo de adequação precisa contemplar todos esses instrumentos — não apenas a resolução mais recente.
Requisito | Descrição | Criticidade |
|---|---|---|
Autorização do BC | Obrigatória — a instituição deve ser autorizada a funcionar pelo Banco Central (IF ou IP) | Alta |
Tipo de instituição | IF (banco, cooperativa) ou IP (emissor de moeda eletrônica, credenciadora, ITP) autorizado | Alta |
Capital mínimo | Variável conforme tipo de instituição e segmento regulatório — verificar Res. BCB 429/2024 | Alta |
Disponibilidade operacional | SLA mínimo de 99,5% — operação ininterrupta 24h/7d/365d sem janelas não planejadas | Alta |
Sistema de antifraude | Solução própria integrada ao mecanismo FRAUD do Banco Central | Alta |
Certificado digital ICP-Brasil | Obrigatório para autenticação nas mensagens ao SPI e DICT | Alta |
Conexão ao RSFN | Rede do Sistema Financeiro Nacional — canal seguro de comunicação com o BC | Alta |
Gestão de continuidade | Plano formal de contingência e recuperação de desastres (BCP/DRP) | Alta |
Proteção de dados (LGPD) | Políticas e controles de proteção de dados dos usuários finais | Média |
Time de compliance | Estrutura interna de risco, jurídico e compliance dedicada à operação Pix | Média |
⚠️ Atenção: A autorização do BC não é um pré-requisito que pode ser resolvido no final do projeto. O processo de solicitação e análise pode levar de 2 a 6 meses. Começar pelo desenvolvimento técnico e deixar o processo regulatório para depois é o erro mais caro que uma fintech pode cometer nessa jornada.
Integrações técnicas obrigatórias
The technical infrastructure of Pix Direto is composed of six interdependent systems. Understanding the role of each one — and how they connect — is the prerequisite for any realistic estimation of scope and development timeline.
System | Full name | Function | Criticality |
|---|---|---|---|
SPI | Instant Payment System | Real-time transaction settlement in the PI account | Very high — core of the operation |
DICT | Directory of Transactional Account Identifiers | Registration, query, and portability of Pix keys | Very high — required for every transaction |
RSFN | National Financial System Network | Secure communication channel with the BC infrastructure | High — connectivity prerequisite |
FRAUD | Pix Fraud Prevention Mechanism | Fraud data sharing among participants | High — regulatory requirement |
ISO 20022 | International financial messaging standard | Format of messages exchanged with SPI and DICT | High — mandatory protocol |
ICP-Brasil | Brazilian Public Key Infrastructure | Authentication and digital signature in messages to the BC | High — message security |
SPI: the heart of settlement
The Instant Payment System is where transactions are definitively settled, in real-time, in the institution's PI account. Integration with the SPI requires full implementation of the ISO 20022 protocol — which is not a conventional REST API. It is a financial messaging protocol with an XML structure, strict validation rules, and digital certificate authentication. Teams without prior experience in financial messaging often underestimate this complexity.
DICT: the key directory
The Directory of Transactional Account Identifiers is the infrastructure that associates Pix keys (CPF, CNPJ, email, cell phone, random key) with user accounts. Integration with the DICT allows the institution to register, query, and manage its customers' keys. It is through the DICT that the system identifies which account a key points to before settling the transaction in the SPI.
RSFN: the secure channel
The National Financial System Network is the dedicated and secure communication channel through which messages travel between the institution and the Central Bank's infrastructure. Unlike a public internet connection, the RSFN requires hiring an approved provider and specific network configuration. It is a connectivity prerequisite — without it, there is no communication with SPI or DICT.
FRAUD: the shared anti-fraud mechanism
The Pix FRAUD mechanism allows participants to share information about suspicious transactions and fraudulent accounts in near real-time. Integration with FRAUD is mandatory and requires the institution to implement its own fraud detection layer — which feeds into and queries this centralized system. It is not enough to integrate: you must have an operational anti-fraud policy before go-live.
🔗 Technical deep dive: To understand in detail how the SPI, DICT, and PI Account work architecturally — including the complete flow of a Pix transaction from start to finish — read the article SPI, DICT and PI Account: the infrastructure behind Pix Direto explained.
Segurança e disponibilidade: o que 99,5% significa na prática
The Central Bank requires a minimum availability of 99.5% for direct participants. It seems like an abstract number until you calculate what it implies: a maximum of 43.8 hours of downtime per year — and this includes planned maintenance, which must be communicated to the Central Bank in advance.
Achieving and maintaining this SLA is not a code decision — it is an architectural and operational culture decision. Some practical implications:
Active redundancy: there is no tolerance for single points of failure. The architecture needs multi-layer redundancy — application, database, network, availability zone.
Automatic failover: disaster recovery cannot depend on manual intervention. Each critical component needs an automatic failover mechanism with detection and switching times in seconds.
Real-time monitoring: performance degradation alerts need to arrive before the SLA is affected, not after. This requires defining precise SLIs (Service Level Indicators) and well-calibrated alert thresholds.
Structured on-call: someone with the capability to act must be available at any time, any day. This is not an informal shift — it is an escalation structure with runbooks, tools, and clear responsibilities.
Communicated maintenance windows: any maintenance that affects availability must be communicated to the Central Bank within regulatory deadlines. Uncommunicated maintenance counts as unplanned downtime.
💡 Reference: The cost of building and maintaining this operational structure — including redundant cloud infrastructure, observability tools, and the on-call model — is detailed in the article How much does it cost to operate with Direct Pix?, which includes monthly OPEX ranges by size of institution.
Teams involved: who does what
One of the greatest risks of direct participation projects is being treated as an exclusive engineering project. In practice, it spans at least six areas of the organization — and the lack of alignment between them is one of the most common causes of delays.
The table below maps the teams, their specific responsibilities in the project, and the central role of each:
Team | Responsibilities in the project | Key role |
|---|---|---|
Engineering / Platform | Technical integration with SPI, DICT, RSFN, and FRAUD. Development of the ISO 20022 messaging layer. Cloud infrastructure and observability. | Leads the technical execution of the project |
Compliance & Regulatory | Analysis of BCB Resolution 429/2024, compliance with BC requirements, regulatory reporting, incident management with BC. | Responsible for the relationship with the Central Bank |
Risk & Anti-Fraud | Definition of fraud policies, implementation of the prevention system, integration with the FRAUD mechanism, and continuous monitoring. | Defines the rules that protect the operation |
Legal | Analysis of contracts with suppliers, compliance with LGPD, review of terms and conditions with indirect participants. | Transversal support to the project |
Operations / SRE | Definition of on-call, incident runbooks, 24/7 SLA management, availability monitoring. | Ensures operational continuity post go-live |
Product | Definition of native Pix features, user journey, prioritization of the post-infrastructure roadmap, management of internal stakeholders. | Ensures that the infrastructure becomes a product |
Information Security | Management of ICP-Brasil certificates, access policies, pen tests, security auditing. | Ensures security compliance |
A point that deserves special attention: the product team tends to be mobilized too late in these projects. Direct participation infrastructure only generates value when it becomes a product — and this requires that product is involved from the beginning, defining which features will be launched at go-live and what the roadmap for the next iterations will be.
🏗️ Build vs. Buy vs. Tech Partner: For teams with no prior experience in integrating with SPI, the option of hiring a specialized supplier can reduce the implementation timeframe by 30–50% and significantly lower the technical risk. The build vs. buy decision must be made formally, with TCO analysis, before allocating the engineering team.
Etapas do projeto e timeline realista
The complete process — from initial analysis to go-live in production — typically takes between 12 and 24 months. This wide range reflects real market variations: an institution already authorized by the BC (Central Bank), with a technical team experienced in financial messaging that chooses a technological partner, can reach go-live in 12 months. An institution that needs to request authorization from scratch, build everything internally, and has no prior SPI experience can take 24 months or more.
Phase | Name | Typical duration | What happens |
|---|---|---|---|
Phase 1 | Regulatory analysis and gap assessment | 1–3 months | Mapping of BC requirements, analysis of the institution's compliance, build vs. buy decision, vendor selection. |
Phase 2 | Authorization request to the BC | 2–6 months | Submission of the formal request to the Central Bank, technical and operational documentation, analysis by the BC. Highly variable timeframe. |
Phase 3 | Development and technical integration | 4–9 months | Integration to SPI, DICT, RSFN, and FRAUD. Implementation of ISO 20022 messaging. ICP-Brasil certificates. High-availability infrastructure. |
Phase 4 | Testing in the BC Sandbox/Testing Environment | 2–4 months | Testing in the Central Bank's sandbox/testing environment. Validation of all transactional flows. Correction of non-conformities. |
Phase 5 | Certification and final approval | 1–2 months | Formal certification process. BC approval for production operations. Go-live preparation. |
Phase 6 | Go-live and stabilization | 1–3 months | Controlled launch (gradual rollout recommended). Intensive monitoring. Operational adjustments. 24/7 on-call activation. |
Two phases deserve special attention during planning:
Phase 2 — BC Authorization: the most unpredictable timeframe
The BC's analysis does not follow a fixed, public schedule. The timeframe depends on the completeness of the submitted documentation, the queue of requests at the time, and the nature of any queries from the BC. Submissions with incomplete or inconsistent documentation may have the process restarted. The recommendation is to start this phase in parallel with technical development — never after.
Phase 4 — Testing/Homologation: where the problems appear
The Central Bank's sandbox/testing environment is where technical integration meets reality. It is common for this phase to reveal messaging incompatibilities, certificate errors, unexpected behaviors in error flows, and higher-than-acceptable latencies. Allocating a generous time buffer in this phase — at least 50% above the initial estimate — is one of the most important planning decisions of the project.
Os 5 erros mais comuns — e como evitá-los
These errors were identified in real direct participation projects. None of them are uncommon — and all of them are preventable with proper planning.
Common error | How it manifests | How to avoid |
|---|---|---|
Underestimating the regulatory timeline | Treating the BC (Central Bank) authorization as quick bureaucracy. The BC's analysis process can take from 2 to 6 months — and any incomplete documentation restarts the cycle. | Starting the regulatory process in parallel with technical development, not after. |
Building without observability | Launching the SPI integration without proper instrumentation of logs, metrics, and alerts. The first production incident will reveal what was missing. | Defining the observability strategy before writing the first line of integration code. |
Underestimating 24/7 on-call | Assuming that the engineering team will absorb support outside of business hours without a formal structure. This leads to burnout and compromised SLAs. | Designing the on-call operational model as a project requirement — not as a post-go-live detail. |
Ignoring indirect participants | Focusing all attention on the BC integration and neglecting the architecture for onboarding indirect participants — if that is the strategy. | Defining from the start whether there will be indirect participants and designing the architecture to support them. |
Total build without evaluating buy options | Deciding to build everything internally without comparing with specialized platforms, due to technical pride or lack of market knowledge. | Conducting an RFI for vendors before deciding on a total build. The opportunity cost can be significant. |
Checklist de prontidão: antes de iniciar o projeto
Antes de alocar budget, montar o time e disparar o projeto formalmente, valide os 10 critérios abaixo. Não é necessário que todos estejam 100% resolvidos — mas cada 'não' ou 'não sei' precisa ter um plano de ação antes do kick-off.
Categoria | Critério de prontidão |
|---|---|
Regulatório | A instituição possui ou tem caminho claro para autorização do BC? |
Regulatório | O tipo de instituição (IF ou IP) é elegível para participação direta? |
Regulatório | Há equipe ou assessoria jurídica especializada em regulação do BC? |
Técnico | Existe time com experiência em mensageria financeira / ISO 20022? |
Técnico | A infraestrutura cloud suporta alta disponibilidade e failover automático? |
Técnico | Há estratégia definida de observabilidade (logs, métricas, alertas)? |
Operacional | O modelo de on-call 24/7 está desenhado e tem responsáveis definidos? |
Operacional | Existe plano formal de continuidade de negócios (BCP/DRP)? |
Estratégico | O volume atual ou projetado justifica o investimento no modelo direto? |
Estratégico | A decisão de build vs. buy vs. parceiro tecnológico foi formalmente avaliada? |
Se 7 ou mais critérios estão com resposta positiva, o projeto tem condições de avançar com risco controlado. Se menos de 5 estão endereçados, o momento é de preparação — não de execução.
Conclusão: o projeto que transforma a instituição
Becoming a direct participant of Pix is not an infrastructure project. It is a project that changes the institution's strategic position in the financial ecosystem — and that, if executed well, opens up opportunities that the indirect model simply does not allow: total product autonomy, structural reduction of transactional cost, and the possibility of becoming an infrastructure benchmark for other players.
The complexity is real. The timeline is long. The involvement is broad. But for institutions at the right stage — with volume, strategy, and execution capability — it is exactly this kind of project that defines who will lead the next cycle of the instant payments market in Brazil.
The next step after validating the decision and mapping the requirements is understanding the total cost of operation — because it is the TCO that will define if the fee savings justify the investment, and within what timeframe.
💰 Next article: We details the real cost of operating as a direct participant of Pix — infrastructure, compliance, 24/7 operation and the TCO simulation that shows when the ROI makes sense — in the article How much does it cost to operate with Direct Pix? Infrastructure, compliance and real TCO.
Leituras relacionadas
→ Direct Pix: what it is, how it works, and when it is worth it
→ Direct Pix vs. Indirect Pix: which model makes the most sense for your fintech?
→ SPI, DICT, and PI Account: the infrastructure behind Direct Pix explained
→ How much does it cost to operate with Direct Pix? Infrastructure, compliance, and real TCO
