PIX

Victor Quezado
7 min readDec 4, 2020

Instant Payments in Brazil

Although we have one of the most advanced banking system in the world, there are shortcomings here and there. That is why Brazil, or more specifically the central bank of Brazil (Banco Central or, for short, Bacen) intends to introduce a new payment system by the end of 2020. This payment system is meant to modernize our banking system for transfers, payment of bills, tax collections, service taxes and much more.

According to Bacen, PIX is expected to have 6 defining characteristics:

  1. Availability: any operation should be available 24 hours a day and 7 days a week, even in holidays.
  2. Speed: Most of the operations should be almost instantaneous, being processed in a matter of seconds. Some might be sorted by the banks for fraud analysis and it might take longer.
  3. Open environment: PIX will be available not only to banks but to financial companies (standard or fintechs), and so on. Any of those can build a system that interfaces with that of PIX and deliver the experience to its clients.
  4. Convenience: the user experience should be as intuitive as possible, aiming for the simplicity of physical money payment systems.
  5. Security: it is dealing with people's money, so it will not joke around. It shall use transactions based on the battle-tested Rede do Sistema Financeiro Nacional (RSFN) and use modern technologies and protocols for security.
  6. Multiplicity of use cases: PIX will allow transfers to happen with any value, between persons and entities alike, including government based ones.

Why?

First of all, it should be stated that the implementation of the customer-faced systems, as to offer PIX to its clients, are obligatory not only to every bank, but also to every financial institute that possess more that 500 thousand clients. Therefore, it is not a matter of institutions using or not, it is simply going to happen.

But to understand the motivation behind PIX creation, one should understand two other payment methods that existed when it came to inter-bank transfers.

The first I will talk about is DOC (Documento de Ordem de Crédito). It allows transfers only on business days, and the money would only reach the destination account the next business day (or 2 days after, if it is done after 10pm). It also possess a limiting value of R$ 4999,99 and thee cost for every such transfer is about R$ 15,00 (the value is dependent on the client's bank account plan).

The other one is TED (Transferência Eletrônica Disponível). It allows transfers only on business days as well, but the money would arrive at most by 17pm of the same day. There is no value limit (some banks might apply some restriction to avoid heavy damages from frauds), but the cost is slightly higher, about R$ 20,00 (again, the value is dependent on the client’s bank account plan).

That is when PIX (Pagamento Instantâneo, the X does not have an apparent reason to being) enter the fray. As stated before, it can happen any day (24/7, including holidays), the transfer happen in a matter of seconds (if not taken for fraud analysis), with no limitation (same as TED, banks might apply some limitation to avoid high-risk frauds), cheaper (almost every case will be free, but there are special cases), simpler (use of more intuitive keys, instead of the common bank/agency/account triplet).

It should be noted that, as of the moment, DOC and TED shall remain working in parallel with PIX with no expiration date. But it is not far from thought that, as PIX popularity rises, these products shall be deprecated, and, possibly, disappear in the future.

How it works?

Ok, all nice and dandy, but how it will work? Well, to understand that, first we should know the actors of the story:

  • Client: these are the person on entity that will make a PIX.
  • PSP (Prestadores de Serviço de Pagamento): they are thee ones that will settle the transactions, it can be thought as the banks or payment institutions.
  • SPI (Sistema de Pagamentos Instantâneos): it is the centralized architecture platform that will settle transactions between different participating institutions. It will communicate with thee PSPs using messages based on ISO 20022 and PACS. It will be developed by Bacen.
  • DICT (Diretórios de Identificadores de Contas Transacionais): Repository that will store the information of keys or nicknames that serve to identify the accounts of the receiving users. Also, developed by Bacen.

Then, we should know how can a PIX start. There are many ways and many more to come, but at this moment, the three most popular ones are:

  • Key: One key is mapped to an account and can be used as entry point. The existing types today are CPF/CNPJ, phone number, e-mail and random (UUID). Instead of passing bank-agency-account, one can simply pass his/her CPF or use the phone number and it is done.
  • Static QR Code: Compact feature list, basically: a DICT key, a transaction id (optional), free text (optional), and payment value (optional). Useful for payments that don't change frequently (shows fees, individual common products, etc.). Uses the EMVCo (Europay, Mastercard, Visa) standards to code the content.
  • Dynamic QR Code: More comprehensive feature roll, such as expiration date, payer-identification and so on. Useful for more dynamic type of content, such as shopping purchases. Uses the EMVCo (Europay, Mastercard, Visa) standards to code the content. It uses a JSON file to encode de dynamic part of the payment request.

Abaixo temos um exemplo de um QR Code estático:

Human-readable content of the QR Code. I apologize for portuguese, but this was the documentation I had (Nome=Name, Tam=Size, Valor=Value, chave=key, the rest is irrelevant for basic understanding).
The information on the table will be transformed in the string "00020101021126440014br.gov.bcb.pix0122fulano2019@example.com5204000053039865802BR5913FULANO DE TAL6008BRASILIA6304DFE3" and coded in QR Code format.

Example 1: common transfer

Many terms were thrown at you, and you might feel a little bit lost by now. But let's shed some light on what I just said with an example.

Let's imagine that Alice has an account in Bank A and I want to make a transfer to her friend Bob (Bank B) through PIX.

First of all, Alice should have a PIX key registered in DICT to the account in Bank A. So she requests to her PSP (Bank A) to associate some key (in this case, her phone number) to this account. Then, Bank A will communicate with Bacen (more specifically, DICT) to associate Alice's account with her phone number (provided by Alice herself). DICT, if successful, will store the key-account mapping and returns to the bank its success. After Alice receives the bank's confirmation, she's ready to go.

Bob does not necessarily need a key, but since this is an edge case, we will assume that Bob already has a phone number registered as key to his account at Bank B.

Since Alice already has (for the sake of convenience) Bob's phone number, she can simply insert the phone number in her bank's interface to find Bob. Behind the scenes, Bank A will get the phone number, consult DICT if the key exists, and if so, return the information it has on the key. It is usually a good practice to confirm the account data, to avoid scams or typos.

Done that, Alice insert the remaining information, such as value, with key it wants to use, and perhaps a message to Bob. After confirmation on Alice part, the payer's (Alice's) PSP will communicate with SPI, saying it wants to transfer some value to Bob. The SPI then communicates this to the receiver's (Bob's) PSP. If Bank B approves the transfer, it communicates back the success and the message returns to Bank A. Transfer done successfully!

Example 2: Shopping

In case of purchases, it is better to use QR Codes, as merchants passing their keys is a hassle.

In our example, Alice now wants to shop for groceries. After checking out her purchases at the supermarket cashier, as one of the payment options, a (dynamic) QR Code will appear. To generate this QR Code, the supermarket system will contact its PSP, saying it wants to receive a payment of some given value. The PSP will give back to the supermarket team a QR Code (image or simply a string) containing the value, the supermarket key and a JSON containing some more options that the supermarket system might have sent. Then, the system will show the QR Code to Alice, who will simply scan with her bank (mobile) interface.

When the scan happens, her PSP will configure the payment accordingly and use the key to retrieve the supermarket information contained in DICT. From then on, it is the same process of a common transfer, except that the supermarket PSP will notify the supermarket system, so it can generate the receipt and what else is needed to make the purchase official.

Future

From the looks of it, PIX is here to stay, but it is wrong to assume that all of what I said it all there is to it. I did not want to make a comprehensive PIX tutorial, because there are some aspects that are still under discussion. So I tried to be as shallow as possible to avoid misdirection.

Also, PIX does not stop at simply at what is promised in 2020. It has a schedule for the years to come:

  • 2021: payment by approach (instead of scanning a QR Code, one might choose to use NFC to receive the payment request information), payer's QR Code (in the case of low signal for mobile, the merchant has a better chance at having a better connection, so the payer creates a QR Code containing the purchase information, then the merchant reads it and everything is processed the same, without the client need for connection);
  • 2022: scheduled payment (one can transfer some value at some specific date);
  • 2023: payment using document (entry points using other types of document, pdf for example).

And who knows what is comes after that. It sure is a revolution on Brazil payment methods and I sure hope that it brings all the advantages of the virtual world to this incredibly important industry.

--

--