May 2023

CREATING THE
NEXT GENERATION OF
PAYMENT RAILS:
LESSONS FROM PIX
HOW TO BUILD A REAL-TIME PAYMENTS
PLATFORM AT ITS FULL POTENTIAL

,6%1
KWWSVGRLRUJVZFM
 TA B L E O F C O N T E N T
TABLE OF CONTENT

1. IntroductIon 3
1.1. About Pix
1.2. About the authors
1.3. About this paper

2. ProPertIes and Platforms: a hIgh -level vIew of PIx 7

2.1. Pix’s essential properties and their systemic consequences
2.2. Fast payment rail as a platform, not a specific product
implementation
2.3. Lessons from Pix

3. how PIx works: archItecture and PartIcIPants 24

3.1. Architecture and participants
a. Pix infrastructure
b. Pix participants
3.2. Deep-dive into the key features of Pix architecture and protocol
a. Payment state and error handling
b. Payment description and metadata
c. Account definition
d. Extensibility and sub-standardization
e. Protocols, standards, and interoperability
f. Joining Pix: certification and compatibility
3.3. Lessons from Pix

4. how PIx works: Payment flow 45

4.1. Payment flow: communication between PSPs and the settlement
chamber
4.2. Payment flow: communication between end-users’ devices/
interfaces and the PSPs
a. Full account information input
b. Account alias
c. QR Codes
d. Static QR Codes vs. Dynamic QR Codes
e. The problem with the EMVCo standard
f. The limits to QR Code application
g. Beyond QR Codes
4.3. Lessons from Pix

5. references 87
6. authors 88
7. about ctPI 90
 1.1.
About Pix
1.
INTRODUCTION
1.2.
About the
authors

1.3.
About this
paper

3
 ABOUT PIX
1.
Introduction

1.1.

PIX
About Pix

1.2. IS THE REAL-TIME PAYMENTS RAIL

About the created by the Brazilian Central
authors Bank (BCB). Since its launch in
late 2020, Pix has been gaining
1.3. notoriety for its numbers and its early impacts on the
About this lives of Brazilians of all social groups. According to BCB
paper
data, until February 2023, Pix reached the mark of over
148 million unique users (136 million individuals and
12 million legal entities). In the last three months, Pix
processed 8 billion transactions, amounting to R$ 3.4
trillion (~USD 650 billion).

These numbers alone are enough to recognize the

success of Pix as a fast payment system. Additionally,
its systemic effects are just as impressive. Since the Pix
launch, Brazil has reduced the total cash circulation
by 10%, as stated in Brazilian Central Bank. It is the first
time in history that the volume of Reais, the official
currency of Brazil, circulating declined instead of
increasing. A survey released in October 2021 by PayPal
also reveals that almost 80% of Brazilians welcome
abandoning cash in favor of electronic payment
methods.

The rail's social-economic impacts also started

to show early on. Numbers from BCB show the effect
Pix had on financial inclusion. During the first year of
Pix operation, over 45 million Brazilians, who did not
make electronic transfers using the old infrastructures,
started using Pix frequently. BCB also estimates that
Brazilian businesses saved almost R$ 5 billion
(~USD 1 billion) in card fees in the same period.

4
 ABOUT
1. THE AUTHORS
Introduction

1.1.

W
About Pix

1.2. HATEVER ASTONISHING MILESTONES

About the PIX HAS collected so far, they were
authors only possible due to a collection of
governance and technical decisions the
1.3. internal team at the Brazilian Central Bank has been
About this making since 2018. These brilliant public servants
paper
worked tirelessly to build something extraordinary
that would benefit all Brazilians.

Due to our professional affiliations at the time, we

had a once-in-a-lifetime opportunity to benefit from
the governance structure put in place and contribute
to the technical design of Pix from the very beginning
until the pre-launch. All this work was recognized by
the regulators as instrumental in defining the design
of Pix and many of its important features. Since 2018,
we have been immersed in the Pix ecosystem in Brazil
and are now ready to share our insights on what
makes Pix what it is and how to introduce the same
concept to other countries.

MARIANA JONAS
CUN HA E M E LO ABREU

5
 ABOUT
1. THIS PAPER
Introduction

1.1.

T
About Pix

1.2. HIS PAPER’S GOAL IS TO PROVIDE a

About the comprehensive deep dive into the works of
authors Pix, the critical decisions that enabled Pix’s
most essential features, and why they matter
1.3. so much. The paper also indicates where the authors
About this would recommend a different approach from the one
paper the Central Bank implemented, always highlighting the
tradeoffs between them.

Finally, this paper provides an in-depth technical

description of Pix’s design and protocol. We expect this
paper will help stakeholders worldwide to navigate
through design and architecture decisions while
building fast payment systems. Furthermore, we hope
countries can benefit from the positive impacts an
effective real-time payments platform can bring to
their people and economies.

6
 2.1.
Pix’s essential
properties and
2.
PROPERTIES
AND PLATFORMS:
their systemic
consequences

A HIGH-LEVEL
2.2.
Fast payment rail
as a platform, not

VIEW OF PIX
a specific product
implementation

2.3.
Lessons from Pix

Before getting into how Pix works,

it is worth making a few general
remarks about Pix's properties
and the fundamental decisions.
These will help contextualize the
payment system as a whole.

7
 PROPERTIES AND
PLATFORMS: A HIGH-
2.

LEVEL VIEW OF PIX

2.1.
2.1. PIX'S ESSENTIAL
PROPERTIES AND
Pix’s essential
properties and
their systemic
consequences
THEIR SYSTEMIC
2.2.
Fast payment rail
as a platform, not
CONSEQUENCES
a specific product
implementation

2.3.
Lessons from Pix
a. Nine properties of Pix

1 Government-driven

The Brazilian Central Bank was

responsible for creating the rail, its
rules, and its systems. It is also who
operates the system and provides
the necessary infrastructure. BCB is
the financial and payments market regulator. The
fact it was the financial system regulator that drove
the whole project had many advantages in Brazil's
case. Although it might be possible to make different
arrangements work in other countries, there are few
incentives for a market-driven solution to strive for
global optimization and build a truly open, cost-
effective, and flexible rail. To facilitate the process
of extrapolating Pix's case to a broader set of
circumstances, however, the role the BCB plays in the
Pix rail may be identified in this paper more generally
as a Payment System Operator or PSO.

8
 2.
PROPERTIES AND
PLATFORMS: A HIGH-
LEVEL VIEW OF PIX
2 High availability

2.1.
Pix’s essential Pix is, of course, available 24 hours a
properties and day, 7 days a week, 365 days a year,
their systemic with no downtime on payment or any
consequences other key services.

2.2.
Fast payment rail
as a platform, not
a specific product
implementation
3 Instant gross settlement

2.3.
Lessons from Pix
Pix offers instant payments, with
settlement and clearing in up to 10
seconds (P50 = 6s; P99 = 10s). After
that period, there is a timeout and the
transaction fails. So in 10 seconds either
the money is in the payee’s account or the payer can
safely try the transaction again.

4 Reliability

For both end-users and PSPs. For Payer

users, all information about the transaction
comes from accredited sources and is
presented on their screens for confirmation
before the money flow starts. So payers
can trust the information that is presented and verify the
destination and amount are correct before hitting send.
For Payee users, the fact all Payee PSPs are mandated to
notify the Payee every time a transaction is received also
contributes to the trust and reliance in the system. After

9
 2. all, the Payee can trust the notification from their bank
PROPERTIES AND
that the money is already available in their accounts.
PLATFORMS: A HIGH-
LEVEL VIEW OF PIX
For PSPs, both Payer PSP and Payee PSP can know
2.1. with certainty the status of a payment order at any
Pix’s essential given time for two reasons: every transaction is
properties and assigned a unique end-to-end ID that allows tracking
their systemic the transaction throughout the flow; and the Payments
consequences Systems Operator (BCB in the Pix rail) is the single
source of truth about the status of the payment so
2.2. that any PSP can query the status of any individual
Fast payment rail transaction. Apart from that, every message in the
as a platform, not payment flow is signed using digital certificates, so
a specific product
there is always cryptographic proof of every event
implementation
from end to end, increasing the system’s reliability.

2.3.
Lessons from Pix

5 Ubiquity

Over 90% of all active Brazilian accounts are

linked to Pix, according to Brazilian Central
Bank. For PSPs with more than 500,000 active
accounts, joining the Pix rail to allow
end-users to make and receive Pix
transactions is mandatory. No registration is needed from
end-users to join the service — they simply send or receive
funds as they would in any other online banking system.

6 Cost-effectiveness

PSPs are charged nothing to send

payments and around $0.0002 to
receive Pix transactions.

10
 2.

7
PROPERTIES AND Standardized user
PLATFORMS: A HIGH- experience requirements
LEVEL VIEW OF PIX

2.1.
An additional factor that aided Pix’s
Pix’s essential
properties and growth is the existence of a minimum
their systemic user experience standard on all PSPs.
consequences Brazil’s Central Bank mandated it
because they want clients from all PSPs
2.2. to use Pix easily. All participants must offer payment
Fast payment rail services using QR Codes, manual input, and alias keys.
as a platform, not However, they are only required to generate static
a specific product QRCs (and just for instantly natural persons).
implementation

2.3.
Lessons from Pix

8 Flexibility, extensibility,
and evolvability

Pix is both a transfer and a payment

rail and was built to absorb all existing
use cases with multiple payment
initiation capabilities (P2P, P2B, P2G,
B2P, B2B, B2G, G2P, G2B, etc). Pix’s
extensibility and evolvability allow the protocol to
adapt easily without the need to change the base
protocol. It was also built to last.

Besides, Pix’s simplicity, extensibility, and potential

for data richness make it a powerful tool. The entire
system was designed to function as a platform —
not just one payment product. Instead of relying
on QR Codes with the payment information in plain
text, Pix “dynamic” QR Codes contain a URI that
grants access to the routing information directly
from the Payee PSP’s servers. The consistency and
accuracy of the data are ensured by frequent
updates, as well as a formal communications
protocol that allows Payee PSPs to send virtually any
extra information relevant to the payment.

11
 2. BCB set up specific fields as mandatory, but
PROPERTIES AND it also created an “additional fields” schema
PLATFORMS: A HIGH-
where the Payee PSP could make any additional
LEVEL VIEW OF PIX
information appear on the Payer PSP app on the
2.1. payment confirmation screen. That is: BCB did
Pix’s essential not try to specify all the admissible fields but
properties and one admissible schema to add any other field.
their systemic
consequences

2.2.
Fast payment rail
as a platform, not

9
a specific product
implementation Security by design

2.3.
Lessons from Pix Pix was also projected to be secure
by design, managing sources of truth,
allowing confirmation of information
before transfers are initiated, and
reducing the complexity of the rail.
Furthermore, Pix’s design is anchored in the best
practices of distributed systems. The Pix rail is
idempotent, meaning that the same transaction can
be performed multiple times without the risk of the
value being credited multiple times.

Additionally, the BCB is used as a source of truth

when there are disputes about where the money
went — providing cryptographic proof to resolve such
questions. Another example is Pix’s use of powerful
abstractions and tools such as replication logs to
ensure that centralized data (alias keys) can be
replicated into each relevant PSP’s system without
downtime.

12
 2.
PROPERTIES AND
PLATFORMS: A HIGH-
b. Systemic consequences
LEVEL VIEW OF PIX that follow

T
2.1.
Pix’s essential
HE CRITICAL PROPERTIES OF PIX have many
properties and
their systemic systemic consequences. No longer is it a
consequences competitive advantage for companies to have
been in the market for a long time and to have
built up large customer bases. Any recently created
2.2.
Fast payment rail payments institution can now enable its users to send
as a platform, not money to as many recipients as the big incumbent
a specific product networks do — without paying for access or being pre-
implementation approved by the gatekeepers.

2.3. Furthermore, the payee can use the end-to-end ID

Lessons from Pix generated by a payment request to keep track of which
payments have been fulfilled and which haven't, thus
improving the management of cash flow and inventory.

Pix availability

24 HOURS PER DAY

7 DAYS PER WEEK
365 DAYS PER YEAR

In addition, the Payee PSP can create virtually any

content to be rendered in the Payer PSP app — meaning
it has a newfound capability of creating features
without owning that relationship with both payer and
payee. Traditionally, on credit card payments, the
primary interface between merchants and customers
is a credit card terminal (also called a point-of-sale
device) owned by the merchant. However, with QR

13
 2. Code payments, payment interfaces are controlled
PROPERTIES AND
directly from the Payer PSP's app on the Payer's phone.
PLATFORMS: A HIGH-
LEVEL VIEW OF PIX That allows Payer PSPs to offer POS credit and other
previously impossible features. It can also gather much
2.1. more information about the payment.
Pix’s essential
properties and
their systemic
consequences
10 SECONDS
2.2.
Fast payment rail OR LESS! THAT’S HOW
as a platform, not FAST A PIX TRANSACTION
a specific product CLEARS AND SETTLES
implementation

2.3.
Lessons from Pix
To summarize, Pix is a payment and transfer scheme
that operates and settles transactions in less than 10
seconds. The system operates 24/7/365 and is data-rich,
extensible, and ubiquitous. The Brazilian Central Bank
is the Pix scheme's settlor, managing its operation and
defining the rules governing Pix. The scheme operates
over an infrastructure consisting of a real-time gross
settlement chamber and an alias database, both of
which are under the Central Bank's direct operation. Pix
was created to foster innovation, competition, and the
digitalization of payments and the economy as a whole.

14
 PROPERTIES AND
PLATFORMS: A HIGH-
2.

LEVEL VIEW OF PIX

2.2.
2.1. FAST PAYMENT RAIL
AS A PLATFORM, NOT
Pix’s essential
properties and
their systemic

A SPECIFIC PRODUCT
consequences

2.2.
Fast payment rail
as a platform, not
IMPLEMENTATION
a specific product
implementation

O
NE OF THE MOST IMPORTANT traits that
2.3. make Pix unique is the nature of its design
Lessons from Pix
core. Typically, when a company or a
government sets out to build a payment
rail, the focus is to solve a handful of use cases. And in
doing so, communications protocols fall prey to over-
specification and over-standardization, resulting in
unnecessary complexity and inefficiency. And whenever
a new use case emerges, those responsible for the rail
need to either make workarounds in the already existing
fields and messages or build an entirely new rail to
accommodate the additional needs.

To take Brazil as an example, before Pix, the Brazilian

Central Bank already operated the two settlement
chambers through which all money flow in Brazil has
to go through one for the movement of funds (STR)
and the other for custody and trade of federal bonds
(SELIC). On top of those two, however, the Central Bank
has authorized fifteen other centralized settlement
infrastructures to deal with several different financial
products: there is one for paper checks, one for card
schemes settlement, another for payroll accounts,
another for transfers of less than R$ 1 million in one
business day, another for transfers in D+2, a number
of others to register credit cards receivables, another
for bill payments, etc. Each of these rails was built
separately, as needed. So they implemented their own

15
 2. communications protocols, created their criteria for
PROPERTIES AND entry, and – as a general rule – are expensive to join
PLATFORMS: A HIGH-
and operate.
LEVEL VIEW OF PIX

2.1. Pix takes a fundamentally different approach to

Pix’s essential systems design. The rail was built not as a specific
properties and product implementation but as a true platform. In
their systemic fact, Pix was built to accommodate every payment
consequences method existent in Brazil at the time of launch and
any other that might come to play after. That was only
2.2. possible because all payment solutions and products
Fast payment rail necessarily share two foundational aspects:
as a platform, not
a specific product
implementation
1.
A MONEY FLOW: IT MOVES FUNDS
2.3.
FROM ACCOUNT A TO ACCOUNT B;
Lessons from Pix

2.
A DATA FLOW: EACH TRANSACTION
IS ASSOCIATED WITH SOME METADATA.

PAYMENTS = FUNDS TRANSFER + METADATA

Payer PSP Payee PSP

Therefore, any effective payment system should be

predicated on enabling a money flow and a flow of
arbitrary metadata between any two participants. That
statement gives rise to three problems that need solving:
an issue of protocol, an issue of trust, and an issue of
reach. Let's go through each of these separately.

16
 2.
PROPERTIES AND a. The protocol issue
PLATFORMS: A HIGH-
LEVEL VIEW OF PIX The system needs a communication method that
f fi s fo r ob e t es
2.1.
Pix’s essential
properties and
their systemic
consequences
1

Firstly, it must be standardized but not over-specified.

2.2.
The communications protocol of many payment rails
Fast payment rail
as a platform, not suffers from over-specification. Over-specification
a specific product happens when, during the protocol design process, one
implementation establishes all the use cases to be supported instead of
creating a backward-compatible extensible structure
2.3. that is able to represent all those use cases through
Lessons from Pix extension. A familiar example in the world of payments is
the ISO 20022 payment messages. Everything that goes
into the payment needs to have a specific and already
specified field in one of the messages. When another
type of payment appears, instead of simply extending the
message in a backward-compatible way, you need to
standardize the new type of payment and fully specify it in
the protocol, which can take years to happen.

The need for standardization is apparent. Without

it, the many participants of the system cannot
communicate with each other. But once the protocol is
built to accommodate one specific need with specific
fields and flows, it has to be extended by adding more
specific fields and re-signifying old fields to evolve.
The result is an intricate, inexpugnable web of old
grammar with new semantics to decipher, and a big
pile of unnecessary data travels in the system. That
is, on the off-chance that the new functionalities can
be hammered into the old protocol and a brand new
infrastructure is not called for to "simplify matters".

That is not to say that a genuinely future-proof

protocol is possible. But an effort to identify the
primitives from a system and translate them into
the communications protocol is possible and was
paramount to the success of Pix.

17
 2.
PROPERTIES AND 2
PLATFORMS: A HIGH-
LEVEL VIEW OF PIX
Secondly, the protocol must be accessible to all
2.1.
potential participants in the ecosystem. Connecting
Pix’s essential
properties and every account in a given country through one payment
their systemic system entails connecting all account service providers
consequences in the area. In that group, all kinds of institutions, big and
small, newcomers and incumbents, must be able to
communicate using the same protocol.
2.2.
Fast payment rail
as a platform, not For that reason, the newest buzzword piece of tech or
a specific product a patented technology only a selected few are licensed
implementation to use might get in the way of accessibility. Another
issue is the cost. A protocol that requires expensive
2.3. certifications may exclude smaller players. The same
Lessons from Pix goes to a protocol that is so complex to operate, it
requires huge teams of specialists to navigate.

Thirdly, the protocol must be secure, and

security requires simplicity. Saying this about the
communications protocol of the system that moves
trillions of dollars every quarter may sound too obvious.
But what it means and what it takes to ensure that goal
often needs to be clarified. In the context of protocol
security, simplicity is the key (or the lock, so to speak).
Complex protocols are harder to secure because
complex interactions are harder to analyze and ensure
that no harmful interactions can happen.

18
 2.
PROPERTIES AND 4
PLATFORMS: A HIGH-
LEVEL VIEW OF PIX
Finally, the protocol must be efficient. This is where
2.1.
great opportunities lie for building something truly
Pix’s essential
properties and transformative for the lives of every citizen. The protocol
their systemic bears a great share of the cost of infrastructure
consequences operation as a whole. The decisions made at the
protocol level impact the cost of processing, memory,
disk, bandwidth, and maintenance in general.
2.2.
Fast payment rail
as a platform, not The size, frequency, and flows of messages
a specific product exchanged between participants profoundly impact
implementation the overall price of each transaction. A protocol that
demands unnecessary data to travel, uses a data-
2.3. heavy format, or requires hiring proprietary services or
Lessons from Pix a big team to run it is likely unable to serve a system
that is supposed to cost micro cents per event and
enable its use for any possible need to transfer funds.
If it costs more than a loaf of bread to complete a
transaction, the system would not be suited to accept
payments in a bakery – and the goal is to create a
solution for all needs.

b. The trust issue

The trust issue is twofold. From a regulatory
standpoint, moving money around requires the
guarantee that money will not disappear or multiply
by mistake or by malicious design. For financial system
regulators, that is an issue of systemic resilience and
of currency stability. If a player is able to print digital
currency or loses track of where someone's money is
located, the value of the national currency or the trust
in the financial system may be severely affected. The
risk of a systemic failure is at the heart of the Brazilian
Central Bank's concerns in regard to payment systems.

19
 2. The second aspect of trust in this context is
PROPERTIES AND that connecting the financial system takes an
PLATFORMS: A HIGH-
arrangement between any two account service
LEVEL VIEW OF PIX
providers in the land. This requirement unfolds into
2.1. several issues, from the complexity of business
Pix’s essential arrangements to the technical arrangements and
properties and issues, such as determining the source of truth.
their systemic
consequences

2.2.
Fast payment rail
as a platform, not
a specific product c. The issue of reach
implementation

The issue of reach comes from the fact the payment

2.3.
system needs to connect any two accounts, from any
Lessons from Pix
two account services providers. Solving this issue is
the difference between having a walled garden where
only a few member institutions can provide access to
the payment service and having an ecosystem where
every user knows that whatever economic transaction
they are making, they can use the payment service
to liquidate the price because everyone is reachable.
That is what enables users to leave their houses with
only one payment method, because they know they
will be able to use it for their every need.

As with the issue of trust mentioned above, the

exponential nature of the task of integrating every
institution (n) to every other institution (n-1) also makes
the issue of reach all the more complex. What might
be a daunting feat to bootstrap the ecosystem right
out of the gate, may become an even bigger problem
as the ecosystem evolves. It may effectively increase
the cost of entry for new players to a point where only
big, consolidated institutions can effectively join the
ecosystem at a competitive price.

Left unsolved, this issue also gives rise to the

emergence of intermediaries empowered by the
impracticality of either competing with or operating
without them.

20
 2.
PROPERTIES AND 4 PSPS IN THE ECOSYSTEM
PLATFORMS: A HIGH-
LEVEL VIEW OF PIX
>>> 3 integrations are
2.1.
Pix’s essential required for each PSP
properties and
their systemic
consequences
Payee PSP

2.2.
Fast payment rail
as a platform, not
a specific product
implementation
Payer PSP Payee PSP

2.3.
Lessons from Pix

Payee PSP

>>> 1 integrations is
required for each PSP

Payee PSP

Payer PSP Clearing Payee PSP

House

Payee PSP

21
 PROPERTIES AND
PLATFORMS: A HIGH-
2.

LEVEL VIEW OF PIX

2.3.
2.1. LESSONS FROM PIX

T
Pix’s essential
properties and O ORCHESTRATE THE THREE ISSUES raised above,
their systemic
the Brazilian Central Bank took an approach
consequences
that can be summarized in four main
propositions:
2.2.
Fast payment rail
as a platform, not 1st
a specific product
implementation
To create a centralized infrastructure built and
run by the BCB itself that is in charge of the
2.3. clearing and settlement service. This ensures
Lessons from Pix that new members connect to all current and
future participants in the ecosystem with a single
integration into the centralized infrastructure. That
enables reducing the integration cost, allowing
greater reach, centralizing the issue of trust, and
reducing the need for intermediaries.

2st
To favor open source protocols, such as HTTP and
RESTful APIs over proprietary solutions that were
traditional in the industry until then, such as the
messaging software IBM MQ. This reduces the
overall operating cost, as well as the integration
cost, which also favors a greater reach.

3st
To create a messaging abstraction that was tailor-
made for payments, in a way that enables the
ecosystem to evolve at a much faster rate, thus
ensuring the evolvability of the ecosystem while
also reducing the computational and upfront
investment from the infrastructure operator.

22
 2.
PROPERTIES AND
PLATFORMS: A HIGH-
4st
LEVEL VIEW OF PIX
To embed in the system design and protocol some
2.1. of the best practices of distributed systems, such
Pix’s essential as eventual consistency, idempotency, a unified
properties and source of truth, and replication logs, thus creating a
their systemic symbiosis between security and trust features and
consequences the inner works of the system.

2.2.
Fast payment rail
as a platform, not These are the main characteristics that make Pix
a specific product a successful case. In line with that assumption, the
implementation few critiques we have about BCB's choices in building
Pix are in the areas where BCB deviated from these
2.3. four north stars or missed the chance to take full
Lessons from Pix advantage of them.

23
 2.1.
3.1.
Pix’s essential
Architecture and
3.
2.
HOW PIX
PROPERTIES
properties and
participants

AND PLATFORMS:
WORKS:
their systemic
consequences 3.2.
Deep-dive into

A HIGH-LEVEL
ARCHITECTURE
the key features
2.2.
Fast
of Pixpayment rail
architecture
as a andplatform, not
protocol

VIEW
AND OF PIX
PARTICIPANTS
a specific product
implementation 3.3.
Lessons from Pix
2.3.
Lessons from Pix

Before getting into how Pix works,

it is worth making a few general
remarks about Pix's properties
and the fundamental decisions.
These will help contextualize the
payment system as a whole.

24
 3.
HOW PIX
WORKS:
ARCHITECTURE
3.1.
ARCHITECTURE
AND PARTICIPANTS

AND PARTICIPANTS
3.1.
Architecture and
participants

3.2.
Deep-dive into
the key features
of Pix architecture a. Pix infrastructure
and protocol

3.3.

T
Lessons from Pix
HE PIX INFRASTRUCTURE WAS BUILT and is
operated by the Brazilian Central Bank, the
country’s financial markets regulator.
To support the new instant payments system,
BCB created two entities:

• SPI (Instant Payments System), an RTGS

settlement system that processes transactions;

• DICT, a payment alias database that facilitates

payment addressing within the system.

Besides these two entities, the Brazilian Central

Bank also leverages a broader infrastructure that
supports all of its operations, the National Financial
System Network (RSFN in Portuguese).

SPI is a settlement chamber that holds settlement

accounts from some of the members of the Pix
rail. These settlement accounts are called instant
payment accounts (IP Account or Conta PI, in
Portuguese). The institutions with IP Accounts are
named "direct participants" to Pix. Those who choose
not to have these accounts or who are excluded
from having them are called "indirect participants"
and must partner with a direct participant to be
able to make and receive Pix transactions.

25
 3.
DIRECT PARTICIPANTS =
HOW PIX
WORKS: INSTITUTIONS WITH IP ACCOUNTS
ARCHITECTURE
AND PARTICIPANTS INDIRECT PARTICIPANTS =
3.1. WHO CHOOSE NOT TO HAVE THESE ACCOUNTS
Architecture and OR WHO ARE EXCLUDED FROM HAVING THEM
participants

3.2.
Deep-dive into
The IP Account is managed through the older RTGS
the key features
of Pix architecture system BCB built called Reserves Transfer System (STR),
and protocol which runs only on working days and hours. The direct
participants must manage the cash flow from their IP
3.3. Accounts to make sure they don't run into a liquidity
Lessons from Pix problem, especially at night and on weekends. The
Brazilian Central Bank provides a limited liquidity credit
line for direct participants and allows other players
to offer similar services to the participants. The lines
of credit, however, are tied to the SELIC infrastructure,
which is also limited to working hours of working days.
To reduce the cost and the risk of managing the IP
Account, BCB later introduced modifications to the
regulation to instate a yield to be paid on top of the
overnight deposits on the IP Accounts.

DICT is an alias base that enables payees to link a key —

their tax ID, phone number, e-mail address, or a random
UUID — to a single account so that payers can make
payments using just this one piece of information.

Only one account can be linked

to each alias key. I.e., users can
have only one account linked
to their tax ID, primary email, or
phone number. However, Payees
can have multiple alias keys
related to the same account,
and Payees can have various
keys linked to multiple accounts. Payees can generate
a random UUID and embed it in a QR Code — so they
don't have to share their tax ID, e-mail address, or
phone number with someone they've never met.

26
 3.
HOW PIX
WORKS: The limit of alias keys
ARCHITECTURE tied to each account is:
AND PARTICIPANTS

3.1. 5 FOR
Architecture and INDIVIDUALS
participants

3.2.
Deep-dive into 20 FOR
the key features COMPANIES
of Pix architecture
and protocol

3.3.
Lessons from Pix
Because Payees can have only one account
linked to each of their keys, there's a process that
institutions must follow when they want to change
which account is linked with a user's email or phone
number. Payees can also remove the alias on their
original institution's interface and link to a new
account on a different PSP.

Users do not need to register an alias key at DICT in

order to send or receive Pix. However, doing so makes
using Pix much more seamless because instead of
entering the account number and other personal
details for each transaction, the users only have to
use alias keys.

The National Financial System Network (RSFN in

Portuguese) is the Brazilian Financial System's private
network that supports data exchange to all critical
financial infrastructures in the country, including SPI
and DICT. To connect to RSFN, institutions must hire
a direct link to the private network, as well as hold a
digital certificate that meets certain criteria.

27
 3.
HOW PIX
WORKS:
b. Pix participants
ARCHITECTURE
AND PARTICIPANTS The Pix rail allows five different types of participants.

3.1.
Architecture and
participants

3.2.
Deep-dive into 1 Direct participants
the key features
of Pix architecture
and protocol Their role is to provide account services
to end-users. They are connected directly
3.3.
to SPI. That means it holds a “PI Account”
Lessons from Pix
with the Central Bank, used to settle Pix
transactions. It is important to remember
that direct participants may use IT service providers to
integrate SPI. However, what matters most in being a
direct participant is that the entity holds a PI Account
and engages in BCB’s settlement of transactions.

2 Indirect participants

They provide customer service to end

users and are indirectly connected to
SPI via a direct participant. The direct
participant mediates all Pix transactions
and has access to unencrypted data
from the indirect player transactions.

28
 3.
HOW PIX
WORKS:
ARCHITECTURE
3 Settlement service provider

AND PARTICIPANTS
It is a special type of participant on
3.1.
Architecture and the Pix system that doesn’t provide
participants account services to end users. It enables
participants who are not direct members
3.2. themselves to settle transactions through
Deep-dive into it.
the key features
of Pix architecture
and protocol

3.3.
Payment initiation
4
Lessons from Pix
service provider
(PISP OR ITP, IN PORTUGUESE)

A PISP does not provide account services.

It is a third party that operates between
the payer and its account service
provider, allowing transactions to happen
outside the interface offered by those
systems. Some account service providers can ask for
special authorization from BCB to operate as a PISP, in
addition to the other services they already deliver.

5 IT Service Provider (PSTI)

PSTIs are integrators that facilitate

connections to the broader Financial
System Infrastructure (RSFN). These
providers offer various levels of solutions
(including all the systems to start
operating with Pix).

29
 3.
HOW PIX
WORKS:
ARCHITECTURE
3.2.
A DEEP-DIVE INTO
AND PARTICIPANTS

THE KEY FEATURES

3.1.
Architecture and
participants

3.2.
Deep-dive into
OF PIX ARCHITECTURE
the key features
of Pix architecture
and protocol
AND PROTOCOL
3.3.
Lessons from Pix

a. Payment state
and error handling

P
IX’S CLEARING HOUSE HAS MODELED a payment in
an eventually consistent way. This means that,
after a period of time (in this case, 10 seconds
for payment timeout, plus time for PSPs to
query the information), all participants will agree on
the final state of the payment.

Even though this can look like an obvious and

necessary property for a payment rail, that is not the
reality of most payment systems. It is not uncommon
for a money movement to get to an inconsistent
state (PSPs disagree on the final payment state),
which requires manual intervention from specialized
professionals manually operating the funds. Another
evidence of the necessity of this property is how many
rails or PSPs decline identical transactions in origin,
destination, and value when they are too close in time
(usually same minute), even if they are not the same.

30
 3. One important enabler of this property in Pix is a
HOW PIX
Universally Unique Identifier (UUID), an alphanumeric
WORKS:
key that identifies the transaction in the rail and serves
ARCHITECTURE
AND PARTICIPANTS to query state or retry operations in case of errors.

3.1. Another key enabler is the clearing house,

Architecture and established as the source of truth for all payments.
participants Whenever an error happens, the way for the PSP to
recover is to retry the payment (which is safe because
3.2.
of the UUID) or to query the clearing house for the
Deep-dive into
UUIDs it received confirmation the clearing house
the key features
of Pix architecture accepted. No manual intervention is necessary
and protocol whenever an error occurs.

3.3.
Lessons from Pix

31
 3.
HOW PIX FLOW OF THE HTTP MESSAGING
WORKS:
ARCHITECTURE
AND PARTICIPANTS
Payment Order xyz
3.1.
HTTP status: 200 (ok)
Architecture and PSP Clearing
participants House

3.2.
Deep-dive into >>> Scenario 1
the key features network partition
(ex: internet down)
of Pix architecture
and protocol Payment Order xyz
?
3.3. PSP ? Clearing
House
Lessons from Pix ?

Retries + idempotency + timeouts =

eventual consistency
network partition
(ex: internet down)

Payment Order xyz

Payment Order xyz

PSP HTTP status: 200 (ok) Clearing

House

>>> Scenario 2
network partition
(ex: internet down)

Payment Order xyz

?
PSP ? Clearing
House
?
Retries + idempotency + timeouts =
eventual consistency
Payment Order xyz

HTTP status: 200 (ok)

network partition
(ex: internet down)

Payment Order xyz Clearing

PSP
(10 seconds...) House

Statusr xyz?
Payment xyz successfu

32
 3. In the image above, the normal flow of the HTTP
HOW PIX
messaging shows a payment order being sent from
WORKS:
ARCHITECTURE a PSP to the clearing house followed by a successful
AND PARTICIPANTS response — 200 response code. There are two different
network partition error scenarios where the PSP does not
3.1. receive the 200 status code after sending the payment
Architecture and order, explained bellow:
participants
• 1st scenario: the payment order never reached the
3.2.
clearing house;
Deep-dive into
the key features
of Pix architecture • 2nd scenario: the first message arrived at the
and protocol destination, but the response was cut off.

3.3. If the system was not idempotent, any retry from

Lessons from Pix the PSP could result in a doubled or tripled transaction.
However, since all transactions are identified by an end-
to-end identifier (e2e ID) unique to that transaction, the
PSP can resend the given payment order as many times
as it wants. The clearing house will always make sure to
not process two transactions with the same e2e ID.

Note that the end-to-end ID should always be a UUID

because it avoids collision and guarantees a specific
pattern for all e2e IDs. Therefore, the Payer PSPs should
be required to check if the payment metadata already
contains an e2e ID. If it does not, the Payer PSPs would
have to generate the UUID at the start of every money
flow. Initially, BCB did not allow for this possibility, but later
versions of the technical specification incorporated a
similar provision. The adjustment is essential because
Payee PSPs can leverage Pix's digital signatures to
provide cryptographic proof that a specific QR Code was
paid or not.

Regardless of the scenario, the PSP can retry the

transaction in the absense of a response. Additionally,
the whole payment flow has timeouts for each step
and for the transfer of funds to be finalized. Since the
settlement chamber is the one in charge of making the
actual funds transfer happen, it is the only source of truth
about the payment’s status. If the funds are exchanged,
it means the transfer was successful; if they are not, the

33
 3. transaction will fail after the timeout period runs out
HOW PIX
and the payer will be instructed to initiate it again. Thus,
WORKS:
ARCHITECTURE even if the communication between the Payer PSP or the
AND PARTICIPANTS Payee PSP and the settlement chamber fails, they can
query the settlement chamber as to the status of the
3.1. transaction after the 10 seconds run out.
Architecture and
participants

3.2.
Deep-dive into
the key features
of Pix architecture
b. Payment description
and protocol

3.3.
and metadata
Lessons from Pix

O
NE KEY DISTINCTION BETWEEN PIX and other
payment rails is its strict separation of
the money movement and the metadata
definition. Money movement messaging is
completely controlled by the clearing house, but the
metadata messaging is flexible and can be defined by
the Payee PSP.

This distinction has powerful implications. While in

most payment systems every single participant must
process and understand fields related to all kinds
of transactions — moving in lockstep —, with Pix, the
Payee PSP can independently define and then interpret
the transaction, enabling new types of payments to be
created unilaterally by the Payee PSP.

Unlike the Payer PSP, the Payee PSP is in the perfect

position to define what a payment is about (its
metadata), since it is the payee who understands
which parameters are necessary for each use case.
The role of the Payer PSP in this process is to show the
payment metadata sent by the Payee PSP to the payer,
without needing to process it in any meaningful way.

Another really interesting consequence of this

segregation is the friction reduction to create new
payment products. Most regulator’s concerns fall on the

34
 3. money’s destination, not the specifics of their use cases.
HOW PIX
Most frauds, money laundering, and other payment
WORKS:
ARCHITECTURE restrictions are related to the money movement. Since
AND PARTICIPANTS this is handled in the same way in Pix, a new payment
product will always have those capabilities enabled.
3.1.
Architecture and
participants

3.2.
Deep-dive into
the key features c. Account definition
of Pix architecture

S
and protocol
IMILARLY TO STR, PIX ALSO identifies accounts
3.3.
Lessons from Pix through information such as bank routing
number, bank account number, and account
owner tax ID, which allows participants to easily
migrate customer transfers from STR to Pix without having
the end user take active action for that to happen.

Pix also supports a mechanism to define an account

alias, named Pix Key (“chave Pix” in Brazilian Portuguese).
It can be:

• A phone number;
• An email address;
• A tax ID (CPF or CNPJ);
• A social security number;
• Or a random UUID.

The goal is to facilitate the use of Pix so people

can share information that is commonly memorized
with other people to make a transaction. In Brazil it is
really common to have your tax ID memorized and to
broadly share it, contrary to SSN in the US.

Contrary to the UPI model for account aliases that

is distributed and is local to the institution, BCB opted
to have a centralized alias database, called DICT. This
added a nice functionality: being able to provide only
the alias and not an alias/PSP combo. In doing so,
however, the DICT model also brought four issues that
needed to be addressed.

35
 3.
HOW PIX 1st
WORKS: issue Key scarcity
ARCHITECTURE
AND PARTICIPANTS
Having only the possibility of having three
3.1.
Architecture and aliases and those needing to be unique
participants on the system, could eliminate possible
use cases for Pix. The UUID alias was a
3.2. good solution for this issue.
Deep-dive into
the key features
of Pix architecture
and protocol

2nd Allowing for change

3.3.
Lessons from Pix issue in the account associated
to each alias

A second issue was creating processes

for changing the account an alias
points to. Since the change could be for
accounts of different PSPs, a process
needed to be defined to ensure both
PSPs have the same data. That process had to be
robust against attacks, such as account takeovers and
identity frauds.

3rd Ensuring consistency of data

issue between DICT and the PSPs

Because the state of the alias is critical

to define where the payment goes, this
could not be implemented with a simple
daily dump of information being sent to
PSPs. This was solved by establishing DICT
as the source of truth for alias state and having the
change of data on aliases being propagated through
events to the PSPs by the use of a write-ahead log.

36
 3.
HOW PIX 4th DICT needs to be working
WORKS: issue correctly at all times
ARCHITECTURE
AND PARTICIPANTS

3.1. This is necessary for a transaction to go

Architecture and through, instead of this requirement being
participants present only for the clearing house. From
a distributed system design perspective,
3.2. the smaller the number of systems
Deep-dive into required for an operation, the easier it is to maintain
the key features
that operation working. This is a direct consequence of
of Pix architecture
and protocol the centralization of the alias information and, as such,
is not solvable even though it is possible to mitigate
3.3. the risk of the service stop working, such as having
Lessons from Pix the service deployed to multiple physical locations,
an active-active approach to high availability and
other high availability practices. BCB is very well
versed in these practices since it has been operating
and maintaining critical country-wide infrastructure
services for decades.

d. Extensibility and
sub-standardization

A
S A PLATFORM, PIX WAS intentionally designed
to be extended. Its main extension point is
the metadata field on the dynamic QRCode
payload. This field specifies what that
payment is about and is meta-modeled, meaning that
only the way of presenting information is defined and
not which information can be added there.

37
 3. Many Brazilian government organizations
HOW PIX
have already started to use this metadata field
WORKS:
ARCHITECTURE to encode the information they need for their
AND PARTICIPANTS payment processes, starting to substitute other
rails such as DARFs (a federal tax-specific payment
3.1. rail named "Documento de Arrecadação de
Architecture and Receitas Federais" in Brazilian Portuguese). Utility
participants companies are starting to use this field to create
utility bill payments, replacing the barcode rail they
3.2.
Deep-dive into use today. Many companies are replacing their
the key features barcodes for the Boleto (electronic bill payment
of Pix architecture method used extensively across Brazil) rail by
and protocol adding the required information to the metadata
field. Merchants are starting to include the items
3.3. bought in this field, so their customers can later
Lessons from Pix
check what that payment was about directly from
their banking app.

The examples above were developed unilaterally

or along their PSP. In other words, the BCB, the
clearing house, and other parties did not have
to participate in or validate the creation process
nor had to develop any additional code for it to
work. This indicates that Pix is more extensive than
most payment rails; however, there is space for
improvement.

It is possible to develop standards on how to

interpret specific information in this metadata field,
effectively creating sub-standards that interested
PSPs can choose to participate in while all the others
will still be able to execute the payment without the
added functionality. All that without the need to
change the underlying rail.

38
 3.
HOW PIX e. Protocols, standards,
WORKS:
ARCHITECTURE
AND PARTICIPANTS and interoperability

I
3.1.
Architecture and
T IS NOT FEASIBLE TO build a platform without relying
participants
on several protocols or standards. The strategy of
3.2. reuse is fundamental for the speed and price of
Deep-dive into creating something new, so it is not a surprise that
the key features some of the hardest decisions in designing Pix were
of Pix architecture choosing a protocol or standard for a specific part of it.
and protocol
These decisions may seem innocuous, but they
3.3.
have a direct impact on the final price of the platform,
Lessons from Pix
cost of integration for the PSPs, possible functionality
for the platform, and implementation time. Depending
on the choices made, you are choosing who can
participate in the ecosystem.

BCB’s audacious goal of Pix was to enable all entities

regulated by BCB to become a PSP. This includes
multi-billion dollar full-blown banks with thousands of
software engineers to the smallest credit cooperatives,
with all systems outsourced, passing through small
and medium banks that have internal systems which
are integrated and maintained by external companies.

Another characteristic of Brazil’s banking industry

is that service provider contracting can take six
months or more to happen. Banks tend to be quite
conservative and perform strict due diligence to
ensure the service provider complies with all relevant
regulations while granting the service at the level
needed. These characteristics and requirements
substantially limited which protocols or standards
could be applied in Pix, but they were also essential for
the rail’s success.

Open protocols and standards play a big role in

Pix because they are cheaper than the alternatives
available, while being widely used and familiar to most
software engineers. Additionally, they are generally

39
 3.
easier to extend for specific use cases. Instead of
HOW PIX
choosing IBM MQ, licensed by IBM, the BCB opted for
WORKS:
ARCHITECTURE using the HTTP protocol, which is free.
AND PARTICIPANTS
Some other choices favored proprietary standards,
3.1. such as the use of ISO 20022 data formats and
Architecture and the EMVco QRCode format. Even though that is not
participants necessarily the case, both standards introduced
additional complexity and limitations to the
3.2.
ecosystem.
Deep-dive into
the key features
of Pix architecture The choice of ISO 20022 data format was mainly
and protocol motivated by the possibility of interoperability with
rails that also use the message format. Interoperability
3.3. is an interesting goal to have but in the case of a
Lessons from Pix payment platform that is far from solved by the data
format. Authentication, authorization, connectivity,
data requirements, and many other aspects need to
be established before the data format can have an
impact on interoperability.

The other motivation for ISO was not having to

define a message format, which is perfectly valid
since it takes a lot of effort to define and maintain a
standard. Unfortunately, Pix is substantially different
from other payment rails, so the ISO format had to be

Benefits of open protocols and

standards in Pix’s design

OPERATIONAL COST:
THEY ARE CHEAPER THAN THE
ALTERNATIVES AVAILABLE

ADOPTION COST:
THEY ARE WIDELY USED AND FAMILIAR BY
MOST SOFTWARE ENGINEERS

EXTENSIBILITY:
THEY ARE GENERALLY EASIER TO EXTEND
FOR SPECIFIC USE CASES

40
 3. adapted for Pix and is now maintained independently
HOW PIX from the ISO format.
WORKS:
ARCHITECTURE
It was possible to define a much simpler standard
AND PARTICIPANTS
than ISO 20022 that is strictly tailored for Pix, which could
3.1. have reduced costs and implementation time even
Architecture and further.
participants
The choice of EMVco QRCode standard also
3.2. introduced unnecessary limitations for no
Deep-dive into apparent gain. Once more, the goal was to achieve
the key features
interoperability but it failed. Apart from the unclear
of Pix architecture
and protocol mapping of some IDs (26 through 51 that are
inconsistently and incompatibly used in many different
3.3. rails across the world) a choice of data format will not
Lessons from Pix enable interoperability.

Moreover, the many restrictions in the EMVco QRCode

format introduced additional complexity. One example
is the need to encode information like the merchant’s
name on the QRCode. This does not make sense for
Pix because such information must come from DICT.
Pix had to add specific rules that PSPs need to follow
in case the information on the QRCode diverges from
what gets returned from DICT.

Another limitation added is the 99-character limit

of a data field in the format. Pix uses Capability URIs
to represent more complex payments. Even though
99 characters is sufficient for most use cases, it is too
small to use Payload URIs. If there was enough room
for Payload URIs, PSPs would be able to have the full
payment information directly encoded in the URI, which
could be used to avoid a round trip to the Payee PSP
or be able to have a stateless and offline approach to
generating payment QRCodes.

It is important to note once again that interoperability

is a great goal to have but that needs to be one of the
main goals for it to work and everything needs to be
designed to be interoperable with other systems. If that
is not the case, attempts to drive interoperability will
mostly bring additional complexity without the benefits.

41
 3.
HOW PIX f. Joining Pix: certification
WORKS:
ARCHITECTURE
AND PARTICIPANTS and compatibility

F
3.1.
Architecture and
OR AN INSTITUTION TO BE part of Pix, it must
participants
undergo a process filled with certifications
3.2. and technical validations. The Brazilian Central
Deep-dive into Bank created a sandbox environment where
the key features aspiring Pix participants can implement their internal
of Pix architecture systems against a test environment, facilitating
and protocol the implementation process. Once finished, new
participants must take an extra step: pass a series
3.3.
Lessons from Pix of technical tests to make sure the implementation
works with the BCB’s systems and that payments
can be successfully made, received, or initiated. This
reduces the risk of having compatibility issues going
into production, which could damage the Pix brand.

The Brazilian Central Bank also defined multiple

Service Level Agreements regarding API quality
(latency and others) that PSPs must comply with.
BCB closely monitors this requirement, helps
guarantee Pix’s excellent levels of availability and
reliability.

42
 3.
HOW PIX
WORKS:
ARCHITECTURE
3.3.
LESSONS FROM PIX
AND PARTICIPANTS

3.1.
Architecture and
participants

A
3.2.
Deep-dive into S MENTIONED PREVIOUSLY, ONE OF the most
the key features important lessons from Pix’s architecture is
of Pix architecture the pivotal role of a centralized settlement
and protocol chamber operated by a centralized Payment
System Operator — the SPI and the Brazilian Central
3.3. Bank, respectively. The possibility of having institutions
Lessons from Pix
joining the rail as either direct or indirect participants
was also critical to reduce the cost of entry for smaller
players who can enjoy the advantages of Pix without
the need for a full-blown infrastructure. Yet, the value
of the payment initiation service provider role in Brazil
is still very questionable, given the restrictions imposed
by the regulation and the strength of alternative
solutions on top of Pix. The role of PISPs and the
impacts of the Open Finance agenda on Pix is not,
however, the main focus of this paper and should be
discussed at a future opportunity.

The first valuable lesson worth replicating is that Pix

was intentionally designed to be eventually consistent.
This decision permeates the entire infrastructure and
APIs, facilitating all error handling in the system. That
approach impacts most Pix's key properties, such as
24/7 availability, reliability, and cost-effectiveness.

Eventual consistency was chosen as the most

suitable consistency model for Pix, based on the CAP
theorem. The theorem states that any distributed
data store can provide only two of the following three
guarantees:

• Consistency
• Availability
• Partition Tolerance.

43
 3. For Pix, the possible 10s delay in payment
HOW PIX
consistency is a small price to pay to have the highest
WORKS:
ARCHITECTURE possible levels of Availability and tolerance to network
AND PARTICIPANTS failures (Partition Tolerance).

3.1.
Architecture and
participants 1st LESSON

3.2. Is that Pix was intentionally designed to be

Deep-dive into eventually consistent.
the key features
of Pix architecture
and protocol Another place where we can see the power of this
consistency model is on the DICT. In the initial proposal,
3.3. DICT was supposed to have a two-hour update
Lessons from Pix
downtime every day so all participants would be able
to synchronize the data. By using a write-ahead log
and the change for an eventual consistency model,
the DICT can now operate with all functionalities
24/7, without periodically scheduled periods of
unavailability.

The second feature that makes Pix the current

protagonist of the instant payment disruption is
the approach that allows arbitrary metadata to be
associated with any given transaction, opening the rail
up to extensibility and evolvability.

2st LESSON

Is the approach that allows arbitrary metadata to

be associated with any given transaction, opening
the rail up to extensibility and evolvability.

It is worth reiterating that security was a central

aspect when designing Pix. Besides improving the
system’s safety, the ample use of digital signatures
across the infrastructure made it easier to identify the
responsible for adding bad data in the system – be it
because of a bug or in consequence of an attack –,
helping to solve issues promptly.

44
 4.1.
Payment flow:
4.
2.
HOW PIX
PROPERTIES
communication
etween P Ps and
t Pix’s
2.1.
essential
e settlement
properties and
chamber
AND PLATFORMS:
WORKS:
their systemic
consequences 4.2.
Payment flow:
A HIGH-LEVEL
PAYMENT FLOW
communication
VIEW OF PIX
2.2.
Fast payment
etween rail
end-users
as a platform, not
devices/interfaces
a specific
and tproduct
e P Ps
implementation
4.3.
essons from2.3.Pi
Lessons from Pix
Before getting into how Pix works,
it is worth making a few general
remarks about Pix's properties
and the fundamental decisions.
These will help contextualize the
payment system as a whole.

45
 T
4. HE DATA FLOW CONSISTS OF sending the
HOW PIX
Payer PSP all necessary information to start
WORKS: PAYMENT
the money transfer along with other details
FLOW
required by a particular payment method.
4.1. For a financial transaction to happen, it is mandatory
Payment flow: to have the following information:
communication
between PSPs and • Origin
the settlement
chamber • Amount

4.2. • Data and time

Payment flow:
communication
• Authorization from the account holder
between end-users’
devices/interfaces
This is true for any kind of electronic payment
and the PSPs
use case debit and credit cards, vouchers, bill
4.3. payments, tax payments, payroll, etc. Apart from
Lessons from Pix those, the various use cases mentioned before

TWO KINDS OF COMMUNICATION

*one-time set up
Alias Base before first
transaction*

13
6 7
B B
11
10

A 12
A
Payer PSP Clearing Payee PSP
House
14
14
15

15 8 9 5 3 1

2
Payer Payee

46
 4. require additional metadata to fulfill the users'
HOW PIX
needs. For example, food vouchers need to verify
WORKS: PAYMENT
FLOW if the payee is registered as a restaurant; credit
cards have to defer the settlement of transactions.
4.1. The proper protocol abstraction accounts for both of
Payment flow: these kinds of use cases.
communication
between PSPs and The flow of information can vary greatly, but
the settlement at the end of the day, all payments use cases
chamber
require mandatory and additional information
4.2. to reach the Payer PSP. And that information
Payment flow: flows through two kinds of channels: (A) the one
communication between the PSPs and the settlement chamber
between end-users’ (steps 10 through 14 in the diagram below), and (B)
devices/interfaces the communication channel between the end-
and the PSPs users and the PSPs (steps 1, 5, 8, 9, and 15).

4.3.
Lessons from Pix

COMPLETE PIX COMMUNICATION FLOW: DYNAMIC QR CODE

*one-time set up
Alias Base before first
transaction*

13
6 7

11
10

12

Payer PSP Clearing Payee PSP

House
14
14
15

15 8 9 5 3 1

2
Payer Payee

47
 4.
HOW PIX COMPLETE PIX COMMUNICATION FLOW:
WORKS: PAYMENT
FLOW DYNAMIC QR CODE

4.1. The diagram above illustrates one possible use

Payment flow: of the Pix rail in the case of a Dynamic QR Code.
communication
The particularities of this kind of payment initiation,
between PSPs and
as well as other possible flows, will be discussed
the settlement
in a later section, as will the inner works of the
chamber
clearing and settlement chamber, called SPI (Instant
4.2. Payments System, in Portuguese). For now, it is worth
Payment flow: going through the flow end to end to understand the
communication whole better.
between end-users’ In the example given, the Payee is a merchant who
devices/interfaces generated a Dynamic QR Code with the Payee PSP
and the PSPs ( 1 ) and presented it for the Payer to scan ( 2 ). When
the Payer selects their Payer PSP app on their device
4.3.
and scans the QR Code, the Payer PSP app decrypts
Lessons from Pix
the QR Code image into text. Then, the Payer PSP app
accesses the link embedded in the QR Code and uses
it to access the Payee PSP´s servers ( 3 ). The Payee
PSP replies to the call with the Pix Key and any other
kind of information needed for the payment ( 4 ).
The Payee PSP app forwards all the information to the
Payer PSP´s servers ( 5 ). The Payer PSP then accesses
the Pix Key Database (DICT) to look up the routing
number associated with the Pix Key ( 6 and 7 ).
The Payer PSP then renders all the payment
information to the Payer ( 8 ), who confirms the
information and authorizes the payment ( 9 ). After
the confirmation, the Payer PSP sends a message
to the Settlement Chamber with the amount, the
routing information, and any other data the Payer PSP
might have added to the payment message( 10 ). The
Clearing House forwards the payment message to
the Payee PSP using the routing information provided
by the Payer PSP ( 11 ). If the Payee PSP confirms the
account information is correct and the payment
can be received ( 12 ), the Clearing House settles
the transaction by transferring the amount from the
Payer PSP´s account to the Payee PSP´s account ( 13 )
and notifies both the Payee PSP and the Payer PSP of
the success of the transfer ( 14 ). Once the payment is
confirmed, the Payee PSP notifies the Payee ( 15 ), and
the Payer PSP notifies the Payer.

48
 4.
HOW PIX
WORKS: PAYMENT
FLOW
4.1.
4.1.
Payment flow:
PAYMENT FLOW:
communication
between PSPs and COMMUNICATION
BETWEEN PSPS AND
the settlement
chamber

4.2.
Payment flow: THE SETTLEMENT
CHAMBER
communication
between end-users’
devices/interfaces
and the PSPs

4.3.

A
Lessons from Pix
TYPICAL PAYMENT MONEY FLOW STARTS
when the Payer PSP receives the payment
request from the Payer. As mentioned
previously, all types of payment solutions
have that in common. The method through which this
communication happens, on the other hand, can vary
depending on the use case and will be discussed in
length in the next section. For now, the focus should be
on the moment the Payer PSP receives the payment
request and starts the money flow.

On Pix, the money flow always goes through the

clearing and settlement chamber, called SPI. The
existence of the Settlement Chamber is what enables
the massive reach that Pix enjoys. It also plays a
crucial role as the source of truth about the status
of any given payment. The Settlement Chamber is,
therefore, a fundamental piece of the system that
guarantees the eventual consistency of the whole
platform and the idempotency of all payments.

The communication between the PSPs and the

Settlement Chamber happens through HTTP protocol,
RESTful APIs implemented by the Settlement Chamber,
and the long polling technique. From an operational

49
 4. standpoint, this is not the most efficient choice
HOW PIX
but it avoids the inconvenience of having all PSPs
WORKS: PAYMENT
FLOW implement and certify APIs on their end. After two
years, this approach seems to have paid off since the
4.1. integration of new members to Pix is relatively agile
Payment flow: and the payment flow works seamlessly.
communication
between PSPs and The reason why the Settlement Chamber can
the settlement function as the single source of truth of payment
chamber
status is a simple but powerful concept. All PSPs
4.2. members of the Pix rail must be connected to the SPI,
Payment flow: directly or via a partner who, in turn, is connected
communication directly to the SPI. That direct connection means two
between end-users’ things:
devices/interfaces
and the PSPs 1. The PSP is integrated to SPI's APIs;

4.3. 2. And the SPI holds an account in the name of

Lessons from Pix
the PSP that is then used to settle the gross
transactions in real-time.

If the Payer transfers $ 100,00 to the Payee, the

Settlement Chamber transfers $ 100,00 from the
Payer PSP's account to the Payee PSP's account. From
that moment forward, the payment is definitive and
cannot be canceled.

INSTANT GROSS SETTLEMENT

$ 100,00

Payer
= Payee

$ 100,00

Payer PSP Payee PSP

50
 4. As a result, and since every transaction is identified
HOW PIX
through a UUID, if for any reason either of the PSP does
WORKS: PAYMENT
FLOW not receive a payment success confirmation, they can
send a request at any time to the settlement chamber
4.1. and query whether the transfer between the PSPs was
Payment flow: successful or not. Since the whole flow has a timeout
communication of 10 seconds, the PSPs know that they can query the
between PSPs and status of the payment and get a definitive answer if they
the settlement
have not heard back from the Settlement chamber in 10
chamber
seconds. According to the rail regulations, the Payer PSP
4.2. and the Payee PSP have to communicate the success or
Payment flow: failure of every transaction to their clients, which closes
communication the loop of information regarding the payment status.
between end-users’
devices/interfaces
and the PSPs
a. Full account AT ALL TIMES, BOTH PSPS CAN KNOW WHERE THE
information input
MONEY IS, WHICH IS NOT TRUE FOR MANY OTHER
b. Account alias TRANSFER OR PAYMENT RAILS
c. QR Codes
d. Static QR Codes vs.
Dynamic QR Codes
That is a crucial feature for the system as it provides
e. The problem with a more secure and trustworthy rail. When someone
the EMVCo standard
uses Pix to pay for their groceries, the store knows the
f. The limits to QR payment will either undoubtedly work, and they will
Code application
instantly see the money in their account, or it will just as
g. Beyond QR Codes surely fail, and the person will need to retry the payment.
4.3.
Lessons from Pix The image below shows the communications
between the PSPs and the settlement chamber. It is a
subset of the complete payment flow depicted above.

51
 4.
HOW PIX COMMUNICATIONS BETWEEN THE
WORKS: PAYMENT
FLOW PSPS AND THE SETTLEMENT CHAMBER
4.1.
Payment flow: 13
communication 11
between PSPs and 10
the settlement
chamber
12
4.2.
Clearing
Payment flow: Payer PSP House Payee PSP
14
communication 14
between end-users’
devices/interfaces
and the PSPs 10 Comes after all payment metadata has been
collected and the Payer PSP is ready to send the
4.3. payment order to the settlement chamber with
Lessons from Pix the amount, destination, and any additional
information that might be relevant to the
transaction (e.g., reconciliation ID). At this point,
the Payer PSP generates an end-to-end ID to
guarantee the idempotency of the money transfer.

11 The settlement chamber forwards the payment

order to the Payee PSP, as indicated by the Payer
PSP. At this stage, the Payee PSP can also check if
the payee account is available to receive funds.
That is,
if the routing number is correct, if the account
exists, is active, and is not subject to any sanctions.
12 Once completed the verification, the Payee PSP
informs the settlement chamber if the transfer can
be accepted.
13 If the money transfer is accepted, the
appropriate funds will be transferred between
the Payer PSP IP Account and the Payee PSP IP
Account. From that moment forward, the Pix
transaction is settled and cannot be undone.
The payee can easily refund the payment if
they choose to, however, from the Settlement
Chamber’s point of view, it is processed as a
new money transfer in the opposite direction.
14 The settlement chamber informs the success or
failure of the transfer to the PSPs.

52
 4. So far, this payment flow has been working
HOW PIX
well. However, we believe that a minor adjustment
WORKS: PAYMENT
FLOW could unlock many opportunities in Pix. Between
Steps 11 and 12 — when the Payee PSP verifies if the
4.1. payment can be accepted, BCB presents a very
Payment flow: limited list of valid reasons to reject a transaction.
communication The reason, among other things, could have been
between PSPs and a concern that incumbents could use it to degrade
the settlement
the Pix experience, thus damaging its brand.
chamber
Notwithstanding this is a reasonable concern, we
4.2. believe that if Payee PSPs could block the transfer for
Payment flow: other reasons, new use cases could arise.
communication
between end-users’ There are cases where a Dynamic QR Code can
devices/interfaces have an expiration date or accept payment only
and the PSPs once and therefore prevent a double payment by
mistake. That feature, however, could also be built
4.3.
Lessons from Pix into the money flow if Payee PSPs could refuse
payment when detecting a duplicate payment,
avoiding errors. Another use case could be the
possibility of refusing a payment before the payer
digitally signs a contract or accepts the terms of
Service (ToS).

53
 4.
HOW PIX
WORKS: PAYMENT
FLOW
4.2.
4.1. PAYMENT FLOW:
COMMUNICATION
Payment flow:
communication
between PSPs and
the settlement
chamber BETWEEN END-USERS’
4.2.
Payment flow:
DEVICES/INTERFACES
communication
between end-users’
devices/interfaces
AND THE PSPS

I
and the PSPs
N THE PIX ECOSYSTEM, THE different kinds of flow of
4.3. mandatory and additional information toward the
Lessons from Pix Payer PSP are called “payment initiation methods”.
They are data flows that ensure all required
information is delivered to the Payer PSP. The BCB
created several types of payment initiation methods
and structured a roadmap for future implementations,
which are detailed in the following image:

LIVE LIVE LIVE LIVE

FULL ACCOUNT ACCOUNT MERCHANT- MERCHANT-

INFORMATION ALIASES PRESENTED STATIC PRESENTED DYNAMIC
INPUT QR CODES QR CODES

LIVE LIVE LIVE

PIX TEXT SCHEDULED CASH DIRECT DEBIT /

(copy/paste) TRANSACTIONS WITHDRAW AND RECURRING
CASH BACK PAYMENTS

EQUATED MONTHLY NFC ONE-CLICK CROSS-BORDER

INSTALMENTS SIGN AND PAY TRANSFERS

CUSTOMER- PAYEE
PRESENTED DYNAMIC PSP API
QR CODES

54
 4. It is important to observe that most payment initiation
HOW PIX
methods listed above are payer-initiated — a significant
WORKS: PAYMENT
FLOW difference between real-time payment rails and card rails.
In the later system, the payment initiates in the merchant’s
4.1. device (the POS machine). That leads to several security
Payment flow: issues since all sensitive payment information will be
communication input into a single device. The risk of credit card cloning, of
between PSPs and replay attacks on the POS machine, and other frauds are
the settlement
a constant concern regarding card rails. This issue is even
chamber
more critical in locations where crime and fraud rates are
4.2. elevated. Moreover, many people are wary of using credit
Payment flow: and debit cards for security reasons, curbing the adoption
communication rate of those payment methods in several countries, such
between end-users’ as Germany or Argentina.
devices/interfaces
and the PSPs Apart from the direct debit, the customer-presented QR
Code standard, and an eventual API-enabled payment
4.3.
Lessons from Pix initiation, all other bank-to-bank payment mentioned
above begins on the payer's phone. That is a gigantic shift
in the payment dynamics and may have implications for
reducing skepticism and building trust in the system.

a. Full account information

input certification

I
N PIX’S CONTEXT, THE FULL
account information input
has been called “manual
Payer PSP
input”. It consists of the
Payer opening the Payer
Full name: .......................
PSP’s app and inputting
Routing number: .........
all mandatory transaction
Bank: .................................
information directly into
Amount: ..........................
the app. In essence, the
Date: .................................
user experience is very
similar to the traditional rails TRANSFER
used all over the world to
make account-to-account
transfers.

55
 4.
It may seem innocuous to account for a payment
HOW PIX
initiation method filled with so much friction while more
WORKS: PAYMENT
FLOW sophisticated alternatives are available. However, to
expressly recognize this as a valid form to initiate real-
4.1. time payments has its virtues. Since the end-user step-
Payment flow: by-step is strictly the same, the adoption cost for those
communication customers is reduced to zero. The advantage of such an
between PSPs and
approach is, therefore, very clear. No matter the age of
the settlement
the user or where they are in the technology adoption
chamber
lifecycle, everyone can start using the new rail as soon
4.2. as it’s live. That was, in fact, the case with Pix. Payment
Payment flow: Service Providers started pushing for the adoption of
communication Pix in a scenario where the cost of a Pix transaction
between end-users’ was much lower than what existed before, and the
devices/interfaces
user experience was, at worst, strictly the same as the
and the PSPs
previous, more costly solutions. Another advantage is
4.3. that there is always a baseline fallback in case of issues
Lessons from Pix with any other payment initiation method.

PAYMENT FLOW: FULL INFORMATION INPUT

6
5

Clearing
Payer PSP House Payee PSP
9
9
10
10
3 4 2

Payee
Payer

56
 4.
HOW PIX PAYMENT FLOW: FULL INFORMATION INPUT
WORKS: PAYMENT
FLOW
1 The merchant sends the full banking routing details
4.1. to the payer
Payment flow: The payer inputs all the information in their PSP
2
communication interface, along with the transfer amount and, if
between PSPs and
needed, a small message.
the settlement
chamber The Payer PSP sends all the information to the and
3
presented it for the Payer to scan ( 2 ). When the
4.2. Payer selects their Payer PSP app on their device and
Payment flow: scans the QR Code, the Payer PSP app decrypts the
communication
QR Code image into text. Then, the Payer PSP app
between end-users’
accesses the link embedded in the QR Code and
devices/interfaces
and the PSPs uses it to access the Payee PSP‘s servers ( 3 ). The
Payee PSP replies to the call with the Pix Key and any
4.3. other kind of information needed for the payment
Lessons from Pix ( 4 ). The Payee PSP app forwards all the information
to the Payer PSP‘s servers ( 5 ). The Payer PSP then
accesses the Pix Key Database (DICT) to look up the
routing number associated with the Pix Key ( 6 and
7 ).

The Payer PSP then renders all the payment

information to the Payer ( 8 ), who confirms the
information and authorizes the payment ( 9 ). After
the confirmation, the Payer PSP sends a message
to the Settlement Chamber with the amount, the
routing information, and any other data the Payer
PSP might have added to the payment message
( 10 ). The Clearing House forwards the message to
the Payee PSP using the routing information provided
by the Payer PSP ( 11 ). If the Payee PSP confirms the
account information is correct and the payment
can be received ( 12 ), the Clearing House settles
the transaction by transferring the amount from the
Payer PSP‘s account to the Payee PSP‘s account ( 13 )
and notifies both the Payee PSP and the Payer PSP of
the success of the transfer ( 14 ). Once the payment
is confirmed, the Payee PSP notifies the Payee ( 15 ),
and the Payer PSP notifies the Payer.

57
 4.
HOW PIX b. Account alias
WORKS: PAYMENT
FLOW

T
4.1. HE ACCOUNT
Payment flow: ALIAS IS REFERRED
communication to in Brazil as
between PSPs and Pix Keys. These Payer PSP
the settlement are stored in an alias
chamber
database called DICT –
Alias key: .........................
4.2. Transactional Account
Information Database. Amount: ...........................
Payment flow:
communication DICT, as mentioned Date: ..................................

between end-users’ before, was built and

devices/interfaces is maintained by the
and the PSPs Brazilian Central Bank
and allows payee users
4.3.
Lessons from Pix to link the information
about a certain account
to an alias so that,
instead of sending the
full routing information to the payer, they can inform
just the alias and receive the transfer. The alias can
be a telephone number, the payee tax ID (CPF), an
e-mail address, or what is referred to as a “random
key”, which consists of a UUID generated by the
Payee PSP and registered as a Pix Key.

The registration of any alias, however, is not a

requirement to start sending or receiving funds
through Pix. As mentioned above, payees can receive
Pix transactions by providing their complete account
information, and the payers can pay through any
kind of payment initiation method without prior
registration.

The Pix Key offers a vital feature to the ecosystem

by facilitating the process of inputting mandatory
information about the payee. Besides, the payment
routing information comes from a secured source
of truth, adding an extra layer of security to the
transaction. After typing the Pix Key, the payer can
double-check the name of the payee retrieved from

58
 4. the alias base, making
HOW PIX
sure the money is going
WORKS: PAYMENT
FLOW to the correct account.
As noted previously, the Payer PSP
4.1. mechanism of ensuring
Payment flow: all relevant information
communication Full name: Mom &
comes from a trusted Pop‘s
between PSPs and and verified source is Routing number:
the settlement 123456
present in all Pix payment
chamber Bank: Bank Corp
initiation methods. It is
Amount: USD 2.70
4.2. one of the main features Date: Today
Payment flow: responsible for building
communication trust in the system. CONFIRM
between end-users’
devices/interfaces When debating on
and the PSPs account aliases, the
Brazilian Central Bank
4.3.
Lessons from Pix had a clear outcome in mind. It was important to the
institution that any payer could make a transaction
just by knowing the payee’s telephone number. To
accomplish this goal, creating the alias database
was the only solution available.

However, it is worth noting that other options could

have been implemented to provide the rail with
an alias feature without the need to build a highly
centralized database. A model based on a unique
identifier of the account coupled with the information
about who the Payee PSP is could have been a
simpler solution. In such a model, similar to the UPI
ID, the alias could follow a format similar to that of
an email address, such as “payee-jane-doe@payer-
psp”. The information to the right would indicate to
the settlement chamber to which PSP to route the
request. Once the message got to the intended Payee
PSP, they could check on their internal registry which
account is identified by the “payee-jane-doe” handle.

However, an alias base and the power of the

default option on important keys like the tax ID and
the phone number triggered a race between PSPs
to persuade payees to register these aliases to
accounts held by each of them.

59
 4.
HOW PIX PAYMENT FLOW: PIX KEY
WORKS: PAYMENT
FLOW

4.1. 1 The Payee PSP registers the Payee’s Pix Key

Payment flow:
communication 2 The merchant sends the Pix key to the payer
between PSPs and
3 The payer inputs the Pix key in their PSP interface,
the settlement
along with the transfer amount and, if needed, a
chamber
small message.
4.2. The Payer PSP accesses the alias database and
4
Payment flow: asks for the full routing information associated to
communication the Pix Key
between end-users’
devices/interfaces 5 The alias database provides the full routing
and the PSPs information

4.3. 6 The Payer PSP sends all the information back to the
Lessons from Pix payer for confirmation

7 The payer confirms the transaction.

8 The Payer PSP starts the money flow

o e t e set before first

Alias Base transaction*

11
4 5
9
8

10

Payer PSP Clearing Payee PSP

House
12
12
13

6 7 3 1 13

Payer Payee

60
 4.
HOW PIX c. QR Codes
WORKS: PAYMENT
FLOW

Q
4.1. R CODE IS, PERHAPS, PIX’S most noticeable
Payment flow: feature. In fact, many of the Brazilian Central
communication Bank’s decisions regarding QR Codes made it
between PSPs and possible to create secure and powerful tools
the settlement that enable Pix to work well for P2M use cases instead
chamber
of just the P2P transfers the first two mechanisms are
4.2. more suited for. However, through a detailed assessment,
Payment flow: we found this decision has been proven suboptimal
communication for BCB’s own goals in building Pix. Firstly, it is necessary
between end-users’ to explain how QR Codes work in general and how they
devices/interfaces apply to the Pix scheme.
and the PSPs

4.3.
Lessons from Pix QR CODES ARE TEXT STRINGS ENCODED AS IMAGES.

When a QR Code reader scans a QR Code printed

on a piece of paper, it decodes the image back to the
original string. Therefore, they are a protocol designed
to share information between two different means.
The text that was in the paper is now on the device
that scanned the image. In that sense, QR Codes are
somewhat similar to protocols like Bluetooth, NFC,
and WiFi. Conversely, QR Codes cannot transfer large
datasets nor establish a continuous data exchange.

They also do not need to create a programmatic

connection with the source of the original data. In fact,
the data source does not need to be electronic; it can
be a piece of paper. It is a protocol for the passive
exposure of information for extraction by a different
device. All of these aspects make QR Codes very
powerful in the payment’s ecosystem .

Additionally, there is no need to worry about the

security of end-user devices, and the entire process
can be done by using a smartphone camera.

61
 4. The limit of data that is possible to encode as a QR
HOW PIX Code is an issue that deserves attention. Since they
WORKS: PAYMENT
are a special way of encoding text, the more text it is
FLOW
encoded, the bigger the code will be.
4.1.
Payment flow: Take both QR Codes as an example. The one on the
communication left, is a title of a beloved poem written by John Donne. On
between PSPs and the right side, the entire poem is encoded as an image.
the settlement It is possible to observe that the additional characters
chamber make the code much bigger and harder to read with a
medium-quality camera than the QR Code on the left.
4.2.
Payment flow:
communication
between end-users’
devices/interfaces
and the PSPs

4.3.
Lessons from Pix

Depending on the amount of information a specific

payment use case requires, the limitations of the protocol
could considerably impact the system’s functionality.
Besides, such limited data capacity could make it difficult
to incorporate any security mechanism to guarantee the
integrity of the data, such as digital signatures. Attacks
commonly involve pasting fraudulent QR Codes with the
wrong payment routing information on top of the original
one so that the payer makes the transaction to the
attacker’s account instead of the intended recipient.

Both problems can be solved with a simple solution:

instead of embedding the payment metadata in the QR
Code itself, a URI must be used in its place. By doing so,
the payer will be sent to an environment containing all the
information needed.

This is how it works in the context of payments:

62
 4.
HOW PIX DYNAMIC QR CODE IN THE PIX RAIL
WORKS: PAYMENT
FLOW

4.1.
Payment flow:
communication
between PSPs and 3
the settlement Payer PSP Payee PSP
chamber

4.2. 1
Payment flow: 5
4
communication
between end-users’
devices/interfaces
and the PSPs

4.3. 2
Lessons from Pix Payer Payee

1 The Payee PSP generates a URI containing a domain they own and a UUID. The
presence of a UUID adds a security layer by making it virtually impossible for
anyone to guess the URI, shielding it from attacks. This type of URI is commonly
known as “capability URIs”. After generating the URI, the Payee PSP creates a Pix
QR Code and sends it to the payee.

2 The payee presents the QR Code to the payer, who scans it with their phone
using their Payer PSP app.

3 The Payer PSP app accesses the Payee PSP URI. This communication is secured
by HTTPS and requires a signed response from the Payee PSP to be completed.
It is worth mentioning that the signature must use a previously registered
certificate on a database controlled by the Payment System Operator (BCB, in
the Pix rail).

4 Then, the API call returns all data pertaining to the transaction: account
number, payee identification, and other information that the payee may
find helpful to present to the payer or to help the process of payment
reconciliation.

5 The Payer PSP’s app on the payer’s device sends the routing and additional
information to the Payee PSP’s servers to initiate the money flow.

63
 4. This mechanism
HOW PIX
defines a Dynamic QR
WORKS: PAYMENT
FLOW Code in the Pix rail. It is
dynamic because even
Payer PSP
4.1. if the QR Code itself does
Payment flow: not change (it has the
communication same URL), the data the Full name: Mom & Pop‘s
between PSPs and Payee PSP returns to the Routing number: 123456
the settlement
Payer PSP — as shown in Account number:
chamber 789012
step 4 — can be renewed
Bank: Bank Corp
4.2. several times. That Amount: USD 2.70
Payment flow: enables a merchant to Date: Today
communication print and display one QR
between end-users’ Code in front of a cashier CONFIRM
devices/interfaces and update the payment
and the PSPs
information to show the
4.3. amount due by each
Lessons from Pix customer.

d. Static QR Codes versus

Dynamic QR Codes

S
TATIC QR CODES ARE THE counterpart of
Dynamic Codes. They are called static
because they do not contain a link but rather
the information directly; that means the
amount of data inserted into the image is far more
limited. However, similarly to the Dynamic type, Static

64
 4. QR Codes also have a mechanism to ensure the
HOW PIX
integrity of the information about the payee and the
WORKS: PAYMENT
FLOW routing information with a slight difference. Instead
of adding the routing information in plain text, the
4.1. protocol determines that the Static QR Codes must
Payment flow: have a Pix Key so the Payer PSP can obtain the routing
communication information in a trusted source, the Alias Base (DICT).
between PSPs and
the settlement
chamber

4.2.
Payment flow: {
communication “pix_key_type”: “tax_id”,
between end-users’
“pix_key”: “99999999999”,
devices/interfaces
and the PSPs “amount”: 2.7,
“identifier”: “mp-10-06-2022-00050”
4.3. }
Lessons from Pix

Static QR Codes also have some range of flexibility

and functionality. Pix’s technical specifications state
that if the QR Code’s “amount” field is blank, the Payer
PSPs must render a field for the payer to fill with the
total due. That is a simple but effective feature that
allows some flexibility in QR Codes’ payments. In Brazil,
it is being largely used by street vendors and cab
drivers, who benefit from the convenience of QR Codes
without needing a fancy sales system.

Pix documentation also prescribes an optional

field on Static QR Codes where payees can add an
identifier, facilitating the reconciliation of payments.
However, the system presents challenges; it identifies
the QR Code, not each payment individually.
Nevertheless, it has been proven good enough for
several use cases.

65
 4.
HOW PIX PAYMENT FLOW: STATIC QR CODE
WORKS: PAYMENT
FLOW
1 The Payee PSP registers the Payee’s Pix Key. Either the
4.1.
Payee PSP, a third party, or the Payee themselves
Payment flow:
generates a Static QR Code, containing optional
communication
between PSPs and fields for an identifyer and a message to the Payer.
the settlement 2 The Payer scans the QR Code using the Payer PSP
chamber app. If the QR Code did not contain a payment
amount, the Payer inputs it.
4.2.
Payment flow: 3 The Payer PSP app sends the Pix key, the optional
communication fields, and the amount to the Payer PSP server.
between end-users’ 4 The Payer PSP accesses the alias database and asks
devices/interfaces for the full routing information associated to the Pix
and the PSPs
Key.
4.3. 5 The alias database provides the full routing
Lessons from Pix information.
6 The Payer PSP sends all the information back to the
payer for confirmation.
7 The payer confirms the transaction.
8 The Payer PSP starts the money flow.

o e t e set before first

Alias Base transaction*

11
4 5
9
8

10

Payer PSP Clearing Payee PSP

House
12
12
13

7 3 1 13
6

Payer Payee

66
 4. Another benefit of
HOW PIX
Static QR Codes is the
WORKS: PAYMENT
FLOW level of autonomy it gives
payees regarding their
Payer PSP
4.1. PSPs. To implement card
Payment flow: payments, merchants
communication must contact a bank and Full name: Mom & Pop‘s
between PSPs and firm a deal, which can be Routing number: 123456
the settlement Account number: 789012
rather expensive. Then,
chamber Bank: Bank Corp
they have to buy or rent
Amount: USD 2.70
4.2. a specific hardware and Date: Today
Payment flow: follow the operation rules Shopping list:
communication established by the bank. • Bagel – $1.50
between end-users’ Static QR Codes empower • Coffee – $1.00
devices/interfaces • To go – $0.20
merchants and other
and the PSPs
payees to start receiving CONFIRM

4.3. and managing their

Lessons from Pix pay-ins independently
from their PSPs. Since
virtually all PSPs in Brazil
must accept Pix payments and register Pix Keys for
their customers, any payee can print a Static QR Code
to begin to accept Pix payments seamlessly. Since the
QR Code standard is widely available on the Brazilian
Central Bank’s website, anyone can generate Pix QR
Codes through free softwares.

On the other hand, Dynamic QR Codes include

interesting additional properties by virtue of storing
the information directly in the Payee PSP’s servers. For
instance, Payee PSPs can guarantee the same bill will
never be charged twice by returning a 410 HTTP status
code (“gone”) if the Payer PSP calls the URI in the QR
Code after the bill is paid. Payee PSPs can also return,
along with the payment information, an end-to-end ID
that is then transmitted through the whole payment
flow. So, instead of being generated by the Payer PSP,
the Payee PSP sends the e2e ID along with the other
payment metadata through the Payer, then the Payer
PSP, then the Settlement Chamber, and then back to
the Payee PSP. That allows for a much more accurate
reconciliation of payments.

67
 4. Another pivotal
HOW PIX property of Dynamic QR
WORKS: PAYMENT
Codes is that they can
FLOW
potentially transmit any
Payer PSP
4.1. kind or amount of data
Payment flow: since the QR Code image
communication itself contains nothing Full name: Cool Trip Co.
between PSPs and but an address where Routing number: 123456
the settlement to get the information Account number: 789012
chamber Bank: Bank Corp
the Payer is after. So the
Amount: USD 149.99
4.2. Pix documentation can
Date: Today
Payment flow: easily add features to
Terms ^ Conditions:
communication the Dynamic QR Codes. https: / /cooltrip.co /
between end-users’ One of such features was legal /tos
devices/interfaces the creation of specific
and the PSPs rules to generate and CONFIRM

read QR Codes with the

4.3.
Lessons from Pix due date, information
about eventual late
fees, and whether or not
overdue payment may
be received.

Moreover, the Brazilian Central Bank developed a

special field to receive arbitrary information. It’s a field
type array where Payee PSPs can create extra fields
following the overall Pix field syntax. Because the syntax
is standardized, Payer PSPs can correctly render the
arbitrary additional fields in the payment confirmation
screen without needing a revised Pix specification. This
strategy of specifying how to create fields instead of
developing an exhaustive list of possible fields opens
Pix for innovation, evolvability, and extensibility.

Even though the Brazilian Central Bank decided not

to allow these additional fields to be returned to the
Payer to fill out any information needed, the capability
of rendering arbitrary information to payers that are
not necessarily their clients is groundbreaking for Payee
PSPs. They can find other ways of delivering value to
payees by exploring this new communication channel.
It is now possible to send the payee a link with the terms
and conditions of a service they are paying.

68
 4. Another path to be explored with the flexibility of
HOW PIX
Dynamic QR Codes is the development of over-the-
WORKS: PAYMENT
FLOW top products such as point-of-sale credit, loyalty
programs, as well as other partnerships between Payer
4.1. PSPs and Payee PSPs, without the need to create a new
Payment flow: communication channel, with another integration to
communication develop and maintain.
between PSPs and
the settlement • The possibilities are truly endless. All because of
chamber
two key features:
4.2.
Payment flow: • A URI that contains an address where all the
communication information can be found;
between end-users’
devices/interfaces And a protocol describing how to create additional
and the PSPs fields in a way that any Payee PSP can return arbitrary
information that any Payer PSP can parse and render
4.3. to the payer, no additional integration needed.
Lessons from Pix
It is important knowing that QR Codes should be
understood as mere means of communication along
the payment flow. What is truly important is that the
URI gets to the Payer PSP. If that happens by the payer’s
device scanning a QR Code or any other way should
not be relevant. The same result could be reached with
a connection via Bluetooth, NFC, API, or even through a
Payee PSP-initiated flow with the Settlement Chamber.
They should all work in the exactly same way.

e. The problem with the

EMVCo standard

T
HE BRAZILIAN CENTRAL BANK DECIDED to
implement the EMVCo Merchant-Presented
QR Code standard as mandatory for all QR
Codes payments-related, including those in the
context of Pix. The reasoning behind this decision was
the ease of implementing a standard that was already

69
 4. in effect across several countries, the concern about
HOW PIX
the emergence of several QR Code standards for each
WORKS: PAYMENT
FLOW payment solution and the international interoperability.
Although the reasons might be understandable, we
4.1. believe they do not justify the use of EMV Co.
Payment flow:
communication Firstly, EMVCo is a form-like QR Code standard with
between PSPs and mandatory and optional fields that then have to be
the settlement mapped out to match the needs of each particular
chamber
payment system. Thus, although the standard exists,
4.2. the effort to unravel the meaning of each field still
Payment flow: burdens the regulators and the institutions that need
communication to implement the extended standard.
between end-users’
devices/interfaces Secondly, the EMVCo standard was created to
and the PSPs encompass a multitude of specific payment use cases,
overspecifying some fields, including the mandatory
4.3.
ones. That means the regulator in charge of setting
Lessons from Pix
the standard must make workarounds to avoid pieces
of the original standard that do not fit perfectly with
the payments system that is being developed. At the
same time, the prolific standard limits the size of other
relevant fields to accommodate unnecessary ones. The
result is an inefficient standard that has too much and
too little data at the same time.

Thirdly, no EMVCo QR Code standard

implementations are alike, so international
interoperability is not possible without a
translation layer. That means field 26 in the EMVCo
implementation in Singapore is drastically different
from what it means in India, which is different from the
one in Brazil. In other words, if a Brazilian PSP scans an
EMVCo QR Code from Singapore, it will not be able to
parse the information correctly.

Finally, the fact the EMVCo standard can support

several payment options in one single QR Code does
not mean merchants will be able to display one
single QR Code on their counter. After all, the EMVCo
standard is just a form template. In order to assemble
multiple payment solutions in one QR Code (e.g., Pix,
Mastercard, or PayPal), there must be an intermediary

70
 4. generating the multi-rail QR Codes. Furthermore, it
HOW PIX
would be possible to do that even in the lack of an
WORKS: PAYMENT
FLOW overarching standard, provided there was a clear
need in the market to do so.
4.1.
Payment flow: On the other hand, a standard tailor-made for
communication Pix would have taken less time to craft and could
between PSPs and have been much more efficient and flexible. Below
the settlement is the table with the Pix Static QR Code fields and the
chamber
corresponding EMVCo fields.
4.2.
Payment flow:
communication
between end-users’ ID Nome BR Code Tam Valor
devices/interfaces Payload Format
00 02 01
and the PSPs Indicator
ID Nome Tam Valor
4.3.
Lessons from Pix Merchant 00 GUI 14 br.gov.bcb.pix
26 Account 58
Informations22 123e4567-e12b-
01 chave 36 12d1-a456-
426655440000
Merchant
52 04 0000 (não unformado)
Category Code

Transaction
53 03 986 (R$)
Currency
58 Country Code 02 BR
59 Merchant Name 13 Fulano de Tal
60 Merchant City 08 BRASILIA

Additional Data ID Nome Tam Valor

62 07
Field Template 05 txid 03 ***
0x1D3D – incluindo “6304”
63 CRC1623 04
(ID 63 e tamanho 04)

00020126580014br.gov.bcb.pix0136123e4567-e12b-12d1-
a456-4266554400005204000053039865802BR5913Fulano
deTal6008BRASILIA62070503***63041D3D

71
 4. Note that the fields merchant category code,
HOW PIX
merchant name, and merchant city are useless for
WORKS: PAYMENT
FLOW the Pix use case since all information comes from
a trusted source, and not the QR Code itself (e.g.,
4.1. the Alias Base or the Payee PSP). In Pix Static QR
Payment flow: Code’s documentation, there are only four pieces of
communication information relevant to the payment:
between PSPs and
the settlement • The Pix Key;
chamber
• The BRL amount;
4.2.
Payment flow: • An additional information field;
communication
• A transaction ID for reconciliation purposes.
between end-users’
devices/interfaces
and the PSPs The superfluous mandatory fields and the
restrictions from the EMVCo standard also limit the
4.3. amount of data that can be stored for those fields that
Lessons from Pix are functionality-defining for Pix. If BCB were to create
a standard based on URIs instead of the EMVCo, the Pix
Static QR Code could look like this:

“https://pay-pix/pix-key/BRL/amount/
“additional-information-field/transaction-id

This standard uses the HTTPS URI scheme for a

reason: in case the Payer scans the QR Code with their
phone camera instead of their payment app, they could
be redirected to a page hosted by the Brazilian Central
Bank where they could find instructions on how to scan
the QR Code correctly. However, the scheme could also
be something new, such as "pix-bcb" or "pay-pix".

The relevant part of adopting URIs is the fact it is

a simple, flexible, well-known communication URI
scheme that has survived the test of time and mass
implementation. The specifics of how to use the
standard — e.g., if the Pix Key should be placed before

72
 4. or after the amount or if the protocol should be HTTPs
HOW PIX or anything else — are far less relevant to the outcome
WORKS: PAYMENT
we expect with the use of URIs in this context and can
FLOW
be adapted to the proper context of each payment
4.1. system.
Payment flow:
communication Here is an example of the application of such
between PSPs and standard:
the settlement
chamber

4.2.
Payment flow:
communication
between end-users’
devices/interfaces
and the PSPs
mhttps://pay-pix/0136123e4567-e12b-12d1-a456-42665544000/
4.3. mBRL/100/mom-and-pops-cookie/99999999999
Lessons from Pix
As to the Dynamic QR Codes, their content should
be a URI that can be used to access all payment
information directly from the Payee PSP servers. That
means these QR Codes can communicate more
relevant information from a trusted source, which
significantly amplifies the possibilities of applications.
Besides, Dynamic QR Codes allow Payee PSPs to update
the information as convenient for each use case.

hhttps://payee-psp-domain/
“ sub-domain/uuid

A Dynamic QR Code standard should not be much

more different than the Static QR Code proposed above:

The application of HTTPS URI scheme is also valid in

this case. The relevant part is using a registered Payee
PSP domain and a UUID to complete the URI. Both
measures increase the security of Dynamic QR Codes.

73
 4. Payee PSPs should register their domains with the
HOW PIX
Payment System Operator so Payer PSPs can validate
WORKS: PAYMENT
FLOW if the URI is related to a participant PSP. Also, the
Dynamic QR Code becomes a capability URL by using
4.1. a UUID as the identification key of the URI. That feature
Payment flow: protects the information the Payee PSP returns to the
communication Payer PSP from enumeration attacks since it is virtually
between PSPs and impossible to guess any valid URI.
the settlement
chamber

4.2.
Payment flow:
communication
between end-users’
devices/interfaces
and the PSPs
bhttps://the-bank/pay-pix/418a34b8-4e5a-11ed-bdc3-
b0242ac120002
4.3.
Lessons from Pix
Because Dynamic QR Codes contain no information
about the payment itself, an additional standardization
is required: a return message from the Payee PSP with
all payment information.

As mentioned before, the mandatory information for

all kinds of payments are:

• Routing information (account, Payee PSP, Payee

identification)

• Amount

• Date

However, there are extra fields that may be relevant

for each type of payment. For instance, while paying
the electricity bill, it may be relevant for the Payee to
link a QR Code to an internal ID for the house or to send
the monthly electricity consumption to the Payer. A
loyalty program may want to limit the use of specific
accounts so that they can be used exclusively at
affiliated establishments by arranging that a passcode

74
 4. should be sent on the
HOW PIX
related QR Codes. When
WORKS: PAYMENT
FLOW paying for taxes and
other state fees, the Payer
Payer PSP
4.1. might need to fill out
Payment flow: a form with additional
communication information to guarantee Full name: Mom & Pop‘s
between PSPs and the money will be routed Routing number: 123456
the settlement Account number: 789012
to the correct agency.
chamber Bank: Bank Corp
Amount: USD 2.70
4.2. Even if it were possible
Date: Today
Payment flow: to list all existing payment
Shopping list:
communication use cases and the extra • Bagel – $1.50
between end-users’ fields they may require • Coffee – $1.00
devices/interfaces from the Payments • To go – $0.20
and the PSPs System, the result CONFIRM
would be a convoluted,
4.3.
Lessons from Pix over-specified, over-
engineered, and dated
protocol. It would not take
long until a new use case
is created, and the Payment System protocol would
have to be changed to support it.

A better approach is to specify the schema of

additional fields in the communication between
Payee PSP and Payer PSP and how the Payer PSP
renders the information to the Payer. In the context
of Pix, the Brazilian Central Bank created a “free field”
enabling Payee PSPs to add as many fields as they
may require. The type of this field is an array and
can therefore contain multiple other fields. As long
as the fields follow the same schema as the other
fields, Payer PSPs should have no problem parsing the
additional information, even if they do not know what
the fields mean.

75
 4. To live up to its full potential, our recommend that
HOW PIX
the additional information field of Dynamic QR Codes
WORKS: PAYMENT
FLOW should follow this schema:

4.1.
Payment flow:
communication {
between PSPs and ‘field’: type,
the settlement
chamber ‘name’: string,
‘value’: string,
4.2. ‘visible’: boolean
Payment flow:
}
communication
between end-users’
devices/interfaces
and the PSPs
It is important that the fields created can accept
4.3. multiple types, as the use cases may have different
Lessons from Pix needs. Apart from that, there are two critical nuances
in this proposal. Although the additional field exists as
an array Pix’s documentation, and they can receive
multiple value types, they do not support the following
functionality.

The first is giving the Payee PSP an option to ask the

Payer PSP to hide the field from the Payer. Recall that
all mandatory and additional information the Payee
PSP sends to the Payer PSP can be rendered to the
Payer for confirmation before the money flow actually
begins. It is an extra security layer to ensure the Payer
knows where and how much money they are sending
and confirms it is indeed the intended recipient
and amount. The Payer does not have to see all the
information exchanged between Payee PSP and Payer
PSP. For instance, Payee PSPs may want to send Payer
PSPs a code related to a loyalty program or other
feature built on top of the Payment System for their
business partners.

76
 4. Thus, the first nuance
HOW PIX
is to allow for hidden
WORKS: PAYMENT
FLOW fields traveling with the
payment information.
Payer PSP
4.1. That wouldn’t be the only
Payment flow: way for Payee PSPs to
communication communicate with Payer Full name: Cool Trip Co.
between PSPs and PSPs without polluting the Routing number: 123456
the settlement Account number: 789012
payment confirmation
chamber Bank: Bank Corp
screen. Since all the
Amount: USD 149.99
4.2. communications
Date: Today
Payment flow: between Payee PSP and Terms & Conditions:
communication Payer PSP are through https://cooltrip.com/
between end-users’ HTTP protocols and legal/tos
devices/interfaces RESTful APIs, Payee PSPs Accept terms? [ ]
and the PSPs
could (as they can in CONFIRM

4.3. the Pix rail) send hidden

Lessons from Pix tags or ids in the header
of the HTTP messages.
We believe, however,
that embedding the functionality into the protocol
is a preferable choice to PSPs having to rely on
workarounds such as this one.

The second nuance of the proposal above is that

the protocol should stipulate that, if the ‘value’ field
of the additional field is empty, the Payer PSP should
interpret that as an input field for the Payer to fill out.
There are multiple use cases where the Payee requires
from the Payer additional information to facilitate
reconciliation or other post-payment processes – such
as delivery of goods. The possibility of having the Payer
filling out information to be later delivered to the Payee
opens up new avenues of opportunity for innovation.
If this functionality is coupled with the ability of the
Payee PSP to create a curated list of rules to reject
payments, the possibilities are even more promising.
The Payee PSP could reject payments, for example, if
the appropriate fields are not filled out or do not meet
certain conditions.

77
 4.
HOW PIX f. The limits to
WORKS: PAYMENT
FLOW
QR Code application
4.1.

A
Payment flow:
communication
LTHOUGH QR CODE PAYMENTS ARE powerful
between PSPs and
the settlement tools, they have a significant limitation: users
chamber cannot scan their own screens, restricting the
use of QR Codes in mobile commerce.
4.2.
Payment flow: Going back to the basic primitives of payment
communication methods, the core of
between end-users’ any payment initiation
devices/interfaces
is communicating the
and the PSPs
payment information to
4.3. the Payer PSP. To address
Payer PSP
Lessons from Pix this, the Brazilian Central
Bank instructed all PSPs
to create a section on
their app where users Paste the Pix Text Code

could paste the plain text

content of the QR Code.
That way, payers can
copy the "text code" at
the checkout, manually
paste it on their Payer PSP CONFIRM
app, confirm the payment
information, and go back
— also manually — to the
merchant's website or app.

In this flow, the Payer does by hand what the Payer

PSP app can do by scanning the QR Code and parsing
its image into text. That is far from being an ideal user
experience. However, the fact is that this small change
in Pix’s rules enabled its use on mobile ecommerces,
which have been growing exponentially since the
launch of the real-time payment system in Brazil.

There are several alternatives Payment System

Operators can consider in order to optimize the
checkout experience on mobile commerce. One of

78
 4. them is the use of payment links for bank-to-bank
HOW PIX transfers. However, the Brazilian Central Bank decided
WORKS: PAYMENT
against creating a mandatory standard for payment
FLOW
links, opting for a more straightforward workaround.
4.1. Before diving into the Pix solution and the payment link
Payment flow: alternative, it is worth explaining the reason behind the
communication BCB’s decision. A parallel with the card industry may
between PSPs and help clarify the matter.
the settlement
chamber As mentioned before, in credit card rails the
payment flow starts necessarily with the merchant
4.2.
Payment flow: through the acquirer. Thus, on m-commerce, the
communication acquirer asks the payer for their card information and
between end-users’ sends the payment request to the card issuer through
devices/interfaces the network's communication system. On bank-to-
and the PSPs bank payments, however, the transaction usually
initiates with the payer, which requires the existence of
4.3.
a protocol so the payment information can travel from
Lessons from Pix
the merchant's website to the Payer PSP.

The goal of the payment link alternative is to create

an app-to-app experience where the payer goes from
the mobile commerce website to their payment app
with one click to then confirm the payment information
— just as they would after scanning a QR Code. That
solution places the onus on the Payer PSP and the
Payee PSP to make the payment information travel
from one to the other.

The Brazilian Central Bank studied the possibility

of adding such functionality on Pix but ultimately
decided against it. One of the proposals discussed the
development of a prefix for Pix Links, such as pix.bcb.
gov.br/pay, so that all PSPs could register their apps
with smartphone operating systems to open links with
the pix.bcb.gov.br/pay prefix. This approach presented
two problems:

• 1st problem: any app – not only from the Pix-

registered PSPs – could register to open the links;

• 2nd problem: the definition of the default app

to open the links would vary depending on the
smartphone's operating system and would not

79
 4. necessarily be compatible with the Payer user's
HOW PIX
best interest and the fundamental principles of Pix,
WORKS: PAYMENT
FLOW especially related to increased competition.

4.1. However, there is a better alternative to improve the

Payment flow: user experience on m-commerces payments: having
communication a database of registered domains that can be used
between PSPs and to open each participating Payer PSP app on both
the settlement Android and iOS devices. The Payee PSP, then, could
chamber
present the list of Payer PSPs participating on Pix.
4.2. After selecting their preferred app, the user would be
Payment flow: redirected accordingly to confirm the payment and
communication return to the original screen. The Payees could also
between end-users’ store the information of the Payer PSP used in the last
devices/interfaces payment so that the Payer could benefit from a default
and the PSPs option that is convenient to them from their second
payment onwards. In comparison with the card rails,
4.3.
Lessons from Pix where merchants can maintain a "card on file", here
they could store a "bank on file".

The Brazilian Central Bank also entertained this

option but decided not to implement it because the
private companies would be in a good position to do it
themselves.

Note that the experience the Payer has in this context

is very similar to that of the QR Code payment. The
process of selecting their Payer PSP (browsing on their
phone or on the merchant's website), confirming the
payment on the Payer PSP interface, and going back to
the context of the purchase is present in both flows.

This flow is similar to the one supported by

Open Finance Payment Initiation Service Providers.
However, while the Open Finance solution requires
one-to-one back-end integrations, the payment link
communications can be implemented on top of the
app-to-app communication protocols already existing
on Android and iOS (universal links/app links). Therefore,
the solution would demand solely one integration with
the registered links database so that each PSP can
register their universal link/app link address and look
up those of the other PSPs.

80
 4. In terms of the front-end adaptation to support the
HOW PIX
payment universal link/app link, it would also not be
WORKS: PAYMENT
FLOW very onerous. As mentioned, the payment confirmation
screens would be exactly like the ones of the QR Code
4.1. flow. The only additional effort this solution would
Payment flow: require is processing the universal link itself in order
communication to trigger the payment confirmation screen and then
between PSPs and redirect the payer back to the merchant's interface.
the settlement
See below one example of how the payment link
chamber
standard could be implemented:
4.2.
Payment flow:
communication
between end-users’ www.payer-psp-domain/standardized-path
devices/interfaces
/qr-code-string/return-url
and the PSPs

4.3.
Lessons from Pix

Merchant Inc. Payer PSP

Select the app you want Full name: Merchnt Inc.

to use to pay wth Pix Routing number: 123456
Account number: 789012
Bank: Bank Corp
Amount: USD 2.70
Date: Today

CONFIRM CONFIRM

The payment link is a URL Payee PSP creates to

prompt the Payer PSP app to open, thus ensuring
app-to-app communication and redirect. For that

81
 4. to happen, the Payment System Operator – or any
HOW PIX
other interested party – can define a path to every
WORKS: PAYMENT
FLOW payment link. That would be the case of "pix-link" in the
context of Pix. The way universal/app links work is that
4.1. the Payer PSP would register a universal link/app link
Payment flow: such as “www.payer-psp.com.br/pix-link/*” so that all
communication links following that pattern prompt the app to open.
between PSPs and This registration varies depending on the Operating
the settlement
System and is common knowledge among mobile
chamber
front-end specialists. It is what guarantees app-to-
4.2. app communication. Once the app is prompted by
Payment flow: the payment link call, the Payer PSP app would be
communication configured to process the link and navigate through
between end-users’ the appropriate screens.
devices/interfaces
and the PSPs The link also contains the QR Code string, which in
the context of Pix is an EMVCo-compliant data form
4.3.
Lessons from Pix (the copy/paste text code mentioned above). However,
in the alternative proposal detailed above the string
could be a RFC 3986-compliant URI. In any case,
either the link or the URI should contain what the Payer
PSP app would extract from the image if they were
scanning the QR Code. After being prompted to open,
the Payer PSP app would obtain the QR Code string
from the payment link and process it as if it was a QR
Code scanning or a copy/paste operation.

After the QR Code string, there should be a return

URL to redirect the Payer to the original app once the
payment is completed, avoiding the need for a second
database of returned links.

One last alternative is having the whole URL

signed by the Payee PSP using the digital certificates
registered with the Payment System Operator, allowing
the Payer PSP to process the link only if it is signed
by another registered PSP. We do not believe this
would increase the system’s overall security since the
customer has to review all the payment information
before confirming the transaction on the Payer app.
After all, the mechanics is equivalent to scanning a QR
Code with a payment app, which is also not typically
signed. The recommendation is that the security

82
 4. guarantee should rest on the source of the data –
HOW PIX
either the PSP or a centralized alias base.
WORKS: PAYMENT
FLOW
However, this approach can make sense depending
4.1. on the specific requirements around how payment
Payment flow: orders can be generated. See below two examples of
communication how it could succeed:
between PSPs and
the settlement
chamber

4.2. Following the URI QR Code standard

Payment flow:
communication https://payer-psp.com.br/pix-link
between end-users’
/payee-psp.com.br/pay-pix/418a34b8-
devices/interfaces
and the PSPs 4e5a-11ed-bdc3-0242ac120002
/www.payee-psp.com.br/return-url/6a101a34-
4.3.
82ed-4dbd-b734-0b85e63fbd6c
Lessons from Pix
/fc11bbe5-180a-462d-b33f-56df7d61fb02

Following the EMVCo standard

https://payer-psp.com.br/pix-link
/00020126580014br.gov.bcb.
pix0136123e4567-e12b-12d1-a456-
4266554400005204000053039865802BR5913Fula
no deTal6008BRASILIA62070503***63041D3D
/www.payee-psp.com.br/return-url/6a101a34-
82ed-4dbd-b734-0b85e63fbd6c
/fc11bbe5-180a-462d-b33f-56df7d61fb02

It is important to notice that we believe that

restrictions on how payment orders can be created
can have unintended consequences, even eventually
impacting adoption.

83
 4.
HOW PIX g. Beyond QR Codes
WORKS: PAYMENT

T
FLOW

4.1. AKING THE CONCEPT OF PAYMENT initiation as a

Payment flow: communication protocol to the next level, the
communication idea of building payment solutions by creating
between PSPs and new ways of sending the payment information
the settlement from the Payee PSP to the Payer PSP can stretch
chamber into several additional applications. One example is
contactless payments via Bluetooth, NFC, or other
4.2.
Payment flow: wireless communication. As long as the Payee PSP is
communication available to send the payment information in EMVCo
between end-users’ or URI standard, the payment initiation will follow the
devices/interfaces same flow as when the payer scans a QR Code.
and the PSPs
However, vast the pool of applications of this
4.3.
concept, it is also worth mentioning another type of
Lessons from Pix
payment initiation: merchant-initiated payment. In
this kind of payment initiation, the role of the Payer
PSP is reduced or displaced. Use cases vary from
direct debit, customer-presented QR Codes, variable
recurring payments, and other implementations of
the Open Finance concept of third-party payment
initiation (3PI).

In each of these transactions, the payment flow

starts with the Payee PSP – either the Payee’s account
holder or a third party commonly known as a Payment
Initiation Service Provider, PISP. In either case, the first
step of the payment flow, where the payer agrees
to transfer a certain amount to a specific account,
happens in the Payee’s interface.

There are two ways to make this shift in the payment

flow:

• By creating a new type of message the Payee PSP

can send the Payer PSP through the Settlement
Chamber indicating they want to initiate a
payment;

• Or by establishing a new protocol for one-to-one

integration between the participating PSPs.

84
 4. The first solution is how the Brazilian Central Bank
HOW PIX
is implementing direct debit into Pix. The second
WORKS: PAYMENT
FLOW approach is often used in Open Finance ecosystems.

4.1. In a scenario where all PSPs in the country are

Payment flow: connected through one centralized Settlement
communication Chamber, it does not seem reasonable to create
between PSPs and a separate protocol for one-to-one integrations.
the settlement However, it is worth noting that the Brazilian Central
chamber
Bank did that by creating a one-to-one Open Finance
4.2. protocol for payment initiation even after creating Pix.
Payment flow:
communication To make matters worse, the Open Finance payment
between end-users’ initiation flow is required by law to be subject to
devices/interfaces confirmation on the Payer PSP app before the payment
and the PSPs is processed. As mentioned above, however, this level
of experience could be attained using app-to-app
4.3.
communications via universal links/app links without
Lessons from Pix
needing to create complex standards or one-to-one
API integrations.

An alternative approach could have been to specify

the messaging between Payee PSP and Payer PSP via
Settlement Chamber and allow PISPs to play the role of
Payee PSPs in this context. The one-to-one integration
protocol should only be used on two occasions:

• If the PISPs are allowed to initiate payments without

the confirmation step on the Payer PSP app;

• And if it is either impossible or too inefficient

to route the communication flow through the
Settlement Chamber.

85
 4.
HOW PIX
WORKS: PAYMENT
FLOW
4.3.
4.1.
Payment flow:
LESSONS
communication
between PSPs and
the settlement
FROM PIX
chamber

P
4.2.
Payment flow: IX’S PAYMENT FLOW HAS UNDOUBTEDLY
communication
proven its success. There are a few minor
between end-users’
improvements that could be made,
devices/interfaces
and the PSPs such as:

4.3. • Allowing the Payer to input information on the

Lessons from Pix additional fields in Dynamic QR Codes;

• Creating a standard for redirect links for mobile

payments;

• And relying more heavily on URIs to simplify the

payment initiation standard for QR Codes and
beyond.

All of which the Brazilian Central Bank had good

reasons to leave out of Pix, but could be considered
and eventually incorporated into new real-time
payment rails with little additional specification efforts.

86
 REFERENCES

79% dos brasileiros gostam da ideia de abrir mão do

dinheiro vivo, diz PayPal (Época Negócios)

A Plea for Simplicity (Schneier on Security)

Banco Central do Brasil – Instant Payment System

Ciro Nogueira infla prejuízo dos bancos e engana ao

dizer que Bolsonaro criou Pix (Aos Fatos)

Com o Pix, circulação de dinheiro em espécie caiu

R$ 40 bi (Terra)

Complexity and Security (Schneier on Security)

Em um ano, Pix ‘bancariza’ 45,6 milhões de pessoas

e pode poupar R$ 4,8 bi em tarifas para empresas
(O Globo)

Fim do dinheiro: Pela primeira vez na história

valor do dinheiro em circulação cai no Brasil
(Cointelegraph Brasil)

Pesquisa do PayPal revela: 80% dos brasileiros não

querem mais usar dinheiro e 93% adotariam o Real
Digital (Cointelegraph Brasil)

What is Pix? (Banco Central do Brasil)

87
 AUTHORS

MARIANA
CUN HA E M E LO

Mariana Cunha e Melo is a NYU-educated

lawyer with almost 15 years of experience in strategic
litigation, public policy, legal research, and regulated
markets. In her early career as a lawyer in Brazil,
Mariana worked with Supreme Court justices,
participated as a guest researcher in the Supreme
Court public hearing about the right to be forgotten,
and built the internet law team at a top law firm,
representing Google on high courts and strategic
litigation cases.

Mariana joined Nubank in 2018, where she helped

structure the Public Policy team and developed the
company’s regulatory positioning and key advocacy
thesis. She then transitioned to business and product
strategy, leading Nubank in its efforts to work with
the Brazilian Central Bank on designing its Real-Time
Payments rail. She has since worked in early-stage
startups as a strategic projects owner and director of
regulation and strategy.

She is also a writer, having published books and

articles on privacy, free speech online, and regulation
of fintech companies. As a speaker, she has numerous
international events.

88
 AUTHORS

JONAS
ABREU

Jonas de Abreu is a seasoned security

engineer with deep experience in software engineering
and security engineering. In his early career, he worked
on several projects as an external consultant and was
an instructor in various training programs.

Jonas dedicated almost a decade to helping

build and scale Nubank, LATAM’s leading financial
technology company. He joined Nubank in early 2015
as one of the first engineers onboard. He served as
the company’s Chief Information Security Officer for
several years. In late 2019, he switched to a Principal
Engineer position, where he continued to make
significant contributions to the company’s security
strategy.

Besides his role in shaping Nubank’s infosec

team and strategy, one of Jonas’s most notable
achievements at Nubank was his instrumental impact
on the Brazilian Central Bank’s decisions regarding the
technology adopted in the Pix rail. He was the engineer
responsible for Nubank’s technical proposals during
the Pix Forum. His contributions were highly valued
by the industry experts and played a pivotal role in
shaping the future of payment systems in Brazil.

89
 ABOUT CTPI

T
HE CENTER FOR TECHNOLOGY AND Public Interest
is a subscription-based research center. We are
here to transform the future of the tech industry
through information, training, and research
toward a systemic and sustainable approach to
technology. Our purpose is to bridge the gap between
technology, business, and regulation to create
systemic and sustainable solutions to the problems
that neither the industry nor the regulation can solve
on their own.

www.ctpi.io

https://www.linkedin.com/company/ctpi-io/

Email addresses:

[email protected]

[email protected]

[email protected]

Address:

CENTER FOR TECHNOLOGY AND

PUBLIC INTEREST, SOCIEDAD LIMITADA
Carrer de Bailèn, 11, Barcelona,
Spain, 08010

90