Payments- Framework

Payment system policy prefers interoperability between PSPs

Policy preferences for interoperability sets forth a vision and goal for payment networks and PSPs to follow.

Payment system facilitates cross-domain and/or domain-specific interoperability

Indicates whether or not the switch can be used by payment service providers who have not set it up.Does not discriminate between types i.e. the switch does not have to be interoperable to several types of players (wallets, banks) to be considered interoperable.

Payment system has the infrastructure to facilitate (near) real-time settlement of transactions between users

The focus is on instant settlement between users, not necessarily between PSPs. As far as settlement systems go, both RTGS and DNS systems can allow this, with differing cost structures for PSPs and incentives to participate in the fast payment system. However, instant payment systems can enable this for users irrespective of the banking settlement system involved. For this reason, this indicator is measured both through the settlement system and in instant payment network involved.

Documentation for PSPs to use RTPS architecture is publicly disclosed

These standards look different for authentication (P2P, P2M), retail or bill payments (P2M) or G2P. They are typically security standards and technical spcifications, so that PSPs can ensure their ability to comply with the network's norms.

Technical standards/ specifications are compliant with international standards/ specifications

Provides an added layer of scrutiny to the reliability and validity of standards used.

RTPS is governed by a central bank/ financial regulator

This ensures that even private networks facilitating RTPs are subject to public-interest governance norms.

RTPS is transparent about the rules and conditions of participation

For an RTPS to achieve scale and volume that promotes financial inclusion, the inclusion of several participant types is expected. Open rules on participanting in RTP networks is the first step towards new participants understanding their eligibility, and participation norms.

Non bank RTPS services are subject to payment system rules

A scheme document can be any document that outlines participation rules and accountability rules. This does not capture enforcement.

Payment system operator performance is regularly reviewed and reported on

This review and reporting focuses on transparency and accountability mechanisms. Specific evidence for this performance reporting need to be identified in a manner that is not prescriptive. Public reporting on this fuels transparency but might be counterproductive to system security, further challenging any benchmarking for this indicator.

Payment system design is informed by a multi-stakeholder group of representatives

Payment system design, especially around interoperability and inclusion, when informed by a diversity of stakeholders (especially from civil society, domain experts) can contribute to a more inclusive design. However, practices around system design and almost always closed-door. These practices are hard to benchmark.

Procedural rules for the RTPS's data handling are established

Rules specific to purposes for which transaction data may be stored and shared, participation, pricing structure, transaction limits and financial requirements, initiation methods.

Fraudulent transactions on the RTPS are proactively prevented and managed

Critical trust and safety measure. While not all transactions may be recalled (if settled between PSPs before it is reported), having this feature, or some mechanism like it, ensures proactive management of fraud.

RTPS is subject to relevant security compliance and consumer protection laws

Includes AML law, consumer protection law

There exists a process to notify individuals and general public about personal data related to the RTPS data leaks or threats

Pertains to data and information management systems in the country, rather than the technical DPI architecture itself. Focuses on proactive management of threats, and promoting transparency of data management system with the data subject/ principal.

Personal data linked to RTPS is protected by law

Relates to DPA enforcement ambit as well

RTPS uses unique aliases to encrypt personal information

This is most relevant to RTPS for P2P/P2M transactions. Using aliases that do not reveal the name/ bank account of the individual to all transacting actors. This information is expected to be encrypted and traceable only by relevant oversight bodies. However, this indicator cannot be gauged through publicly available sources, and is a security feature that is not highly prevalent.

Merchants accepting retail payments are subject to security and fraud prevention compliance measures

This is especially relevant for private actors leveraging an RTPS that might not always allow for transactiosn to be recalled before settlement between PSPs. In such instances, preventative security compliance measures can be effective. However, other than measuring for legal measures (AML laws, consumer protection laws), measures for merchant compliance are hard to establish.

There exist laws and institutions that individuals can seek protection under if their rights are infringed or they are discriminated against through the payment system

While this serve as a useful system indicator to maintain individual privacy and security, these laws and institutions may be highly variable across contexts of the RTPS and across countries.

Data and system security standards are publicly disclosed

While this serve as a useful system indicator to maintain individual privacy and security, these standards may be variable across contexts and are hard to ascertain without being prescriptuve.

RTPS enables key transaction types for financial inclusion: P2P, G2P payments

P2P/G2P transactions have been regarded as the most common use cases that enable financial inclusion. This indicator is inferred based on participants who are allowed to use the switch and the value of transactions they are allowed to conduct.

Transactions are enabled through multiple access channels and non-digital means

Makes sure that RTPS is not only for the digitally literate, or favouring a certain kind of access that systematically excludes segment(s) of users. Indicators look into non-digital and contactless options like PoS terminals and ATM machines.

Transaction fee for retail users is low/none

Ensures that RTPS is accessible and affordable.

Budget for management of payment system is dedicated, reliable, sufficient

This includes a budget for lifecycle of the DPI, including maintenance, development, docs, training, knowledge transfer, version upgrades and major migrations etc.

Strategy for skills training and retention (improving the interoperability and efficiency of the payment system) is established

Building the capacity of the payment system to serve as infrastructure will require the state to invest in the talent and skills to improve the interoperability and efficiency of the payment system. This might involve identifying a balance between internal and outsourced functions to create and manage the system. This indicator is aspirational and challenging to benchmark or measure.

Public entities (that are not the same as the architect of the payment system) use the payment system for G2P/P2G transactions

Looks at whether public entities, apart from the system’s operator, actively utilize the data exchange. It considers how these entities leverage the system to improve their operations.

Private entities use the payment infrastructure to accept retail payments (P2M)

While not financial inclusion directly, payment as DPI is actualised for the private sector when retail transactions can be conducted through it.This is inferred through the switch design, which specifies the types of participants and volume of transactions. Keyword search for "retail payment/P2M/merchant payments"

Private entities use the payment infrastructure (B2B)

Specifically for high value payments