Welcome to another issue of CTPI Insights, your premium newsletter on technology design and policy.

Today we'll cover:

Why a platform is different than a product;
How you can build a platform;
CTPI’s proposal for the Automatic Pix and much more.

We are huge fans of how the whole process of Pix design has been conducted by the Brazilian Central Bank, and as long-time participants in this process, we are really excited about the possibilities this current round of contributions brings.

This round has a huge potential to increase competition to new heights in the Brazilian financial system and make Pix even more accessible to all Brazilians. Accessible to the point that it could be possible to do Pix transactions using feature phones, as the UPI does in India.

We are also changing things on our side, and once we are past the deadline for submissions of contributions, we’ll publish our full contributions to our subscribers. We hope these documents can help more people get interested in system design and participate in regulatory processes.

Now, let's get to it.

M. and J.

Automatic Pix and how to design a platform

During the past few weeks, we have spent considerable time working on our proposal on how the Brazilian Central Bank (BCB) should implement “Pix Automático”, a way to have recurring transactions, such as subscriptions, on top of the Pix rail. While the BCB proposal would definitely work, we believe that if it is implemented differently, the benefits would be substantially bigger and cheaper for society.

One of the driving forces behind our proposal is that we view Pix as a platform where regulated entities create products, and we see the “Pix Automático” as a product that BCB wants to happen on Pix. We'll go into detail below on why this distinction can change substantially the outcome.

How to design platforms

Before understanding how designing a platform differs substantially from designing a product, we must understand that a platform is not a product. It is not something that can be used by itself. The way to use a platform is to have a product built on top of that platform. The platform solves abstract problems while the product solves specific problems.

In Pix, the leading abstract problem that was solved by the rail was moving money between any two accounts in Brazil. On top of this abstraction, hundreds of financial companies have built products that solve customer needs. Some are mandatory products, such as offering fee-free payment with QR Codes. Others are optional, such as providing products on top of dynamic QR Codes. And anything else that relies on moving money from one account to another can be built on top of that. The platform Pix solved the abstract problem of “moving money between two accounts”, and the financial companies solved the problem of “how and when their customers need to move money”.

From this perspective, defining how “Pix automático” would work does not fit the rail. That is a specific solution to a problem, so it is a product. The platform needs to enable that product, so more modeling is necessary.

The way “Pix automático” was described by BCB was a recurring pre-authorized transaction that follows a schedule set up by the payee. The concept of scheduling is already part of the Pix rail and must be offered to all payers. The idea of pre-authorized transactions is not because Pix was initially modeled on top of Push Payments (payment initiated by the payer), and authorization would be made at the point of transaction initiation, which would not work for “Pix automático” that requires pre-authorization.

So, two key functionalities need to be added to the platform: Pix needs to support Pull Payments (payments initiated by the payee), and we need to model pre-authorizations of payment.

Supporting Pull Payments is relatively simple because Pix almost has support for that. The payload of a Pix dynamic QR Code is a complete description of a payment initiated by the payee because the payee is in charge of creating it. So, the change needed is to define a message that goes from the payee PSP to the payer PSP carrying a link to the payload of a Pix dynamic QR Code. Almost nothing new needs to be created if the payee PSP already supports dynamic QR Codes.

The second is an entirely new concept but a simple one. The way to do pre-authorizations when the exact value cannot be provided in advance is to establish a budget to be spent on those transactions, and in case one would not be automatically approved, we defined a fallback for exceptional authorizations. The payee suggests the budget (like in the case of historical analysis), but the payer always has the final say on the budget and can change that whenever. If a transaction fails because the budget is too low or already consumed, the payer PSP asks for specific authorization for that transaction.

With these changes, “Pix automático” can be implemented on top of Pix, but other products could also be created with these abstractions as part of the rail. A payment where the payer provides only the Pix key and receives a push to approve the transaction would be possible. The budgeting mechanism would also allow customers to receive a nudge when spending too much on Uber or Starbucks. Amazon-style one-click buy would also be possible.

The role of a platform

Many companies embraced the idea of platformization by calling their products platforms with close to no change. Platforms are product enablers and definitely not a product in the common sense.

One consequence of platforms is that, since it is pretty targeted at solving well a single problem, it tends to be simpler to model and implement because many rules are delegated to the platform consumers, i.e., the products. How a product solves a specific problem covered by the platform abstraction does not impact the platform abstraction.

And as we saw in the case of Pix, the power of combination is fundamental for a platform. Each part of the abstraction needs to be designed with interactions with the other elements in mind. With this, each new abstraction allows many more product classes to be created instead of a single new product or product class.

The value of a platform

What we've encountered on the technology side is something experts have been pointing out in regard to the business of platforms for a while now. There's a famous Bill Gates quote that goes:

"A platform is when the economic value of everybody that uses it, exceeds the value of the company that creates it. Then it’s a platform.”

In the same direction, from Stratechery:

“Platforms, though, while established through product leadership, flourish and sustain themselves by empowering and entrusting developers to build something so compelling that customers fall in love with not just the hardware [or, in the case of Pix, the rail] but the experience that runs on top of it”.

What allows, from the tech side, platforms to flourish and enable the development of many different products on top of it is building powerful abstractions that can be combined in multiple different specific applications to deliver value to the end user.

The role of a government-led platform

That logic is particularly important in the case of government-led platforms. The theory of regulation discusses the limits of government-driven interventions in the economy. One of the most relevant ones is the concept of local knowledge. According to the liberal theory, governments are not well-positioned to make decisions on behalf of the market because they lack local knowledge about the market.

A less radical view of the role of regulation acknowledges the government’s shortcomings in regard to local knowledge but still recognizes the importance of intervention where needed. To counterbalance the lack of local knowledge, this view advocates for more industry and societal participation in the regulatory process.

That's what the Brazilian Central Bank did when it created the Pix Forum to collaborate with the industry in designing Pix. However, even with constant participation from the industry, the amount of local knowledge that can permeate the Pix platform has one important limitation: the local knowledge that was available to the industry at the time of the design.

For that reason, building platforms based on combinable abstractions that allow multiple variants of products to be built on top of it is paramount. That's what allows the industry to do discovery, explorations, testing, and build additional local knowledge based on the use of the platform. That's how the platform can be truly open to local knowledge and evolve as the needs of the end-users evolve.

Summary of our new proposal for Pix evolution

The proposal outlines the concept of push payments and pull payments within the Pix transaction framework. Push payments, as the name suggests, are initiated by the payer. This can be done through various methods such as scanning a QR code, entering bank details, or using the Pix Key of the payee. On the other hand, pull payments, also known as request pay, are initiated by the payee through their payee PSP.

It is important to emphasize that the fundamental difference between the push journey and the pull journey lies in where the payment journey starts. In the push journey, the payer takes the responsibility of initiating the payment flow by performing actions such as scanning a QR code or entering the necessary details. In contrast, in the pull journey, the payee, with prior authorization from the payer, sends a payment request directly to the payer's PSP, without requiring any action from the payer.

However, it is worth noting that the pull journey is not limited to previously authorized payments. It can also be used in other cases to enhance user convenience. For example, instead of the payer scanning a QR code, they can receive a notification on their mobile device, prompting them to open the payment confirmation screen as if they had scanned the QR code. This alternative method still falls under the pull journey category.

Another important aspect is the transmission of payment information. In push payment initiation, the payee informs the payer of the transaction details through methods such as QR codes, Pix Key, or manual entry. On the other hand, in pull payment initiation, the payer informs the payee of the account from which they want to make the payment, and the payee PSP directly sends the necessary payment details to the payer's PSP via the ICOM (the clearing house's communications interface).

Once the payment information is established, the flow remains the same for both push and pull journeys. The payer's PSP presents a confirmation screen to the payer, allowing them to authorize the transaction details and operation. After the payer's authorization, the payer's PSP sends the payment order to the SPI (Pix’s clearing house) for further processing and settlement.

It is worth mentioning that future debit authorization does not have to occur exclusively through a pull journey. It can also be facilitated through methods like scanning an authorization QR code. This provides flexibility in how future debit authorization can be conducted.

The proposal emphasizes that the payment flow and future debit authorization flow are distinct and can follow either push or pull journeys. It is crucial to recognize that the functionalities described in the Pix Automático inquiry should be seen as a specific implementation of a future debit authorization flow and subsequent pull payment journey. This pull payment journey refers to the sending of a payment request from the payee PSP to the payer PSP, as opposed to the payment order that the payer PSP sends to the payee PSP for the settlement of a Pix transaction. These two flows should be specified independently to allow participants in the arrangement to combine them in different ways and create innovative and secure payment experiences.

Therefore, the alternative proposal suggests that instead of specifying a separate implementation of two evolving flows within the arrangement, the Central Bank should independently specify these two mechanisms in a more general way. This approach enables not only the use cases described in the proposal but also numerous others. By working at a higher level of abstraction and avoiding a prescriptive approach, this alternative proposal has the potential to reduce the cost of specification and implementation of these functionalities, making the ecosystem more evolutionary, competitive, inclusive, and efficient.

By elevating the level of abstraction and independently specifying the flows of future debit authorization and the sending of a payment request, the proposal can have a significant impact. At the end of the document, there are details provided on some possible use cases that could be enabled with this alternative design proposal.