The Role of Alias Databases in Real-Time Payment Networks: Centralized or Decentralized?

Sulivan Rocha

Sr. Analyst

Real-time payment systems (RTPs), also referred to as fast payment systems (FPS) and account-to-account (A2A) payments, are playing a key role in the evolution of digital payment methods in Latin America and globally. In addition to systems developed more than a decade ago, such as iDEAL in the Netherlands (2005) and Swish in Sweden (2012), newer systems such as UPI in India (2016) and Pix in Brazil (2020) are significantly changing the way people pay for products and services and deal with cash.

Their impact has been so great that other countries are eager to follow their examples, creating their own versions of instant payment rails, whether through public or private channels. The United States launched FedNow, and other Latin American countries, such as Chile and Colombia, signaled that they are taking the first steps toward creating their own systems.¹

In addition to the payment infrastructure itself — which countries can build from scratch or even use a rail that has been around for decades — it is also important to develop an alias database to facilitate the user experience and encourage the use of the payment system. To do this, one of the first steps will be to define the architecture of this alias database: whether it will be centralized or decentralized.

Countries have used different strategies to deal with the challenges of developing a real-time payment system, according to their regulatory and market characteristics. Brazil developed both the payment rail and the centralized alias directory for the creation of Pix from scratch — as the system was created by the country’s Central Bank, the rules allow the regulatory body to be the operator of the system and also to maintain the centralized alias database.

In India, although the payment rail and alias database of the UPI were also created from scratch by the NPCI, the institution chose to use decentralized architecture to store user information. In other words, each transactional account provider participating in the payment system stores the aliases of its own customers.

Diving deeper into a centralized alias database: Pix (Brazil)

In Brazil’s Pix, both the payment rail (Instant Payment System or SPI, as per the Portuguese acronym) and the centralized alias database (Transaction Accounts Identifier Directory or DICT) are managed and controlled by Brazil’s Central Bank. Linked to the recipient’s account information, a Pix alias can be a mobile phone number, an e-mail address, the Taxpayer Identification Number (CPF or CNPJ), or a randomly generated alphanumeric string (for users who do not want to link their personal data to their transactional account information).²

The institutions participating in Pix have direct access and connection to the SPI and the DICT, so when a user initiates a transaction via Pix, the payer’s bank first consults the DICT to find the payee’s transactional account using the identifier provided by the payer and then uses the SPI to send the amount informed by the payer to the payee.

Diving deeper into a decentralized alias database: UPI (India)

India’s UPI has some differences from Pix. First, it is managed by the National Payments Corporation of India (NPCI) — an umbrella organization made up of 65 institutions, created by the Reserve Bank of India and the Indian Banks Association. Since the NPCI is not the country’s central bank, it has some legal and regulatory limitations to the activities it can perform, such as managing the payment rails and the alias directory.

With UPI, users register an alias following the format “username@psp,” in which the suffix after “@” is automatically included by the account provider (or payment service provider, PSP) and is used to route that transaction to that specific entity.³ When users initiate a transaction, they must enter the payee’s alias. The transaction is then sent to the NPCI, which then routes the transaction to the identifier’s PSP.

The system operates on a decentralized architecture, so only the PSP has the information to link the bank account to that specific username. After the confirmation of the bank details is sent from the payee’s PSP to the payer’s PSP, the NPCI instructs the payer’s PSP to debit the amount entered by the payer.⁴

You should also read: How Pix Compares to UPI and what FedNow can learn from both of them

How can countries improve the user experience to boost real-time payment systems?

Many other countries besides Brazil and India also have real-time payment rails — such as Chile, Peru, South Africa, and Argentina — but none have had the success achieved by Pix and UPI in terms of volume handled, number of transactions, number of users, and overall impact. This is because these other countries have not developed a sophisticated alias directory suitable for optimizing the user experience when making everyday low-value payments.

The whole point of real-time payment systems is to solve customer needs across multiple use cases, so it’s essential that users can make payments as easily as possible — and this totally depends on how the alias database is structured and how it operates

Countries like Costa Rica and Mexico are examples of how payment systems can be improved and optimized from existing systems. In Costa Rica, SINPE (Sistema Nacional de Pagos Electrónicos) was created in 1997 as the country’s first electronic payment system, but it wasn’t until 2015 that an additional system called SINPE Móvil was created to facilitate the user experience, allowing P2P and P2B payments to be made using cell phone numbers as aliases.⁵ In Mexico, the SPEI payment rail was created in 2004 and over the years different supplementary systems have been added to optimize the user experience, most recently DiMo.

Adding an alias database after the fact: DiMo (Mexico)

Aware of the importance of providing a good user experience to scale instant payments, in 2023, Mexico’s Central Bank launched a new way to link users’ bank accounts to their cell phone numbers, called Dinero Móvil (DiMo, meaning “mobile money”). DiMo operates within the country’s Interbanking Electronic Payment System (SPEI), its real-time gross settlement system.⁶ Before DiMo, to make a bank transfer using SPEI, payers had to know the payee’s full 18-digit bank account number (Clave Bancaria Estandarizada – or CLABE), and this made the system difficult for consumers to use for everyday purposes. Now with DiMo, the only information payers need from payees is their cell phone numbers.⁷

Centralized versus decentralized databases

When choosing between a centralized and a decentralized database architecture, several factors must be considered to make an informed decision because these factors significantly impact a database system’s performance, scalability, and overall efficiency.

3 factors in choosing between the two models

Data access and security. One of the most important considerations is the level of control and access. In a centralized database, data is stored and managed in a single location, offering better control and security. However, decentralized databases distribute data across multiple nodes or locations, which can be beneficial for redundancy and fault tolerance but may complicate access control and data consistency. It’s essential to assess the sensitivity of the data, compliance requirements, and the necessity for granular control when determining whether to centralize or decentralize.

An example of the importance of security is the improvement to the rules surrounding Pix-related incidents made by the Central Bank of Brazil in September 2023, since, with the success of the system, it is increasingly targeted by hackers to access user data. The Central Bank increased the criteria for transparency and communication of security breaches to consumers even in cases of minor impact, as well as improved the rules on penalties for Pix participants, making it possible to increase penalties in cases of greater impact.⁸

Scalability and performance. Scalability is another critical factor. Centralized databases can struggle to handle high loads and may require expensive hardware upgrades to scale effectively. In contrast, decentralized databases can be more scalable as they distribute data across multiple institutions. However, this can introduce complexity in maintaining data consistency and may require careful partitioning and complex strategies.

An example of the importance of the scalability of systems is the history of the creation of SPEI in Mexico. The system was developed as a result of a regulatory push from Banxico to replace the real-time gross settlement system that previously existed (SPEUA). SPEUA had been built on a database that could not cope with the growing volumes of transactions and was frequently failing.⁹

Cost and maintenance. The cost implications and maintenance requirements of centralized versus decentralized databases are significant factors. A centralized database has much higher set-up and management costs since the institution controlling it needs sophisticated infrastructure and a technical team. Meanwhile, decentralized databases — which use the individual databases of each participant in the system — end up having a much lower operational cost because the marginal cost of storing a directory of identifiers for each participant in the system is much lower since they already have several databases of their own operations and only need to create additional storage for alias data.

Conclusion

The choice between a centralized and decentralized database architecture is a decision that carries far-reaching consequences for an organization’s data management. The data sensitivity, compliance requirements, and the need for control should guide the decision on centralization or decentralization, with security concerns often favoring centralization. Scalability is essential, and the chosen architecture should be capable of handling future growth. Finally, the cost implications and maintenance requirements differ significantly, with centralized databases incurring higher initial and management costs.

In addition to the technical factors, there are also regulatory issues that will impact the success or failure of the developed real-time payment system. If the developer and operator of the payment system is a regulatory body such as a Central Bank and has the autonomy to set the rules for the main players in the country, it will be much easier to operate the system with a centralized alias database. However, if the developer and operator is a consortium of different companies or even a private company that relies on partnerships, it is more likely that the decentralized architecture of the database will present fewer bottlenecks for the implementation and operation of the system with all the participants.

In addition, partnerships between public and private institutions with fintechs can also be viable ways of enabling alias databases, as is the case with the fintech YellowPepper, acquired by Visa in 2020,¹⁰ which allowed the interoperability of wallets in Peru. In the US, Visa announced the launch of Visa+, utilizing an alias database that links digital wallet accounts from various providers to users, creating interoperability between competing wallets. Whatever the model, the alias database is a key component to enabling faster payments. It is a technology component frequently overlooked when, in reality, it is essential to unlock the full power of instant payment rails.

Sources