Real-time Retail Payments Platform (RPP) - Request to pay (RTP)

 

Overview:

Payments Network Malaysia (PayNet) is Malaysia's payments central infrastructure for financial markets. Real-time Retail Payments Platform (RPP) is a framework introduced by PayNet and aimed to support Malaysian’s Retail e‐Payment services in real time.

Request to pay service is one of those initiatives of the RPP to modernize Malaysia’s retail payments which facilitates the customer to initiate a request, to pay cost-effective and efficient manner. 

You can also refer to my other post for RTP Generic flow:

https://paymentstech.blogspot.com/2022/06/pay-with-flexibility-request-to-pay.html 

“Request to pay” service from RPP:

PayNet has developed the Core RPP infrastructure “Request-to-Pay” to address the needs of customers to have more flexible payment options for business models like Person to Person (P2P), Business to Consumer (B2C), Business to Business (B2B) and e-commerce.

The service enables Payee to send a request for Payment from Payer. The PayNet (Marchant or individual) can initiate a request for payment via a mobile application and upon authorization of request from the payer (person), payment is made instantly, easily & securely via Payer bank.

RPP is based on ISO20022 messaging standard with a highly resilient architecture built to handle high-volume retail transactions, which is connected to a real-time clearing infrastructure aimed to support Malaysia’s current and future Retail e‐Payment.

Request to pay - Use-cases:

• Customers prefer to have bill details available online for their review on the Internet or mobile banking platform and make payments at the time when they have funds available.
• Customers (e.g., Landlord) can forward the payment request received from Biller (e.g., electricity bill) as that pertains to another customer (e.g., Tenant)
• Customers can purchase from an e/m-commerce site/application and Marchant will redirect with their choice of banks to authorize the transaction/request of payment.
• Customer (eg. Friend) can pay the bill for any purpose (e.g., Dine-in bill) and later sends a request to make payments from individuals (e.g., other friends).

How does Request-to-pay work in Malaysia?

The RPP infrastructure has many payments flows to support different use-cases as below.

However, we will discuss couple of them in detail in this article.

    1. Request to Pay - Decoupled flow:

Merchant/Customer1 (Creditor) will send a payment request to pay Customer2 (Debtor). Based on the Debtor’s acceptance, a credit transfer is initiated and the Creditor account gets credited. 

•   Request to Pay - Decoupled flow:

 

Steps-by-Step flow:

1. Merchant/Customer (customer) initiate Account inquiry with help of Crediting Agent. Bank sends a request with DuitNow id (prxy.003//Trnx type 510) or Account number (pacs.008/Trnx type 510) to PayNet.
2. Debtor bank receives requests from PayNet, validates messages and performs debtor account Enquiry and sends the response back with a positive response (pacs.002/Trnx type 510).
3. Creditor initiates RTP request (pain.013.001.07), Creditor agent sends to PayNet
4. Debiting agent sends the response as (pain.014) once debiting agent identifies the message is valid.
5. Debiting agent receives the request and forwards the request to Debtor.
6. Debtor Authorizes Request (via mobile/Net Banking application)
7. Debiting Agent debit the customer (debtor) account and initiates Credit Transfer (pacs.008) and sends to PayNet.
8. Crediting agent receives from the PayNet and post validation credit to the crediting party.

• Successful Rejection Flow

Refer above diagrammatic representation.

Step-by-step flow:

1. Debtor customer rejects the RTP request, which is forwarded from the Debiting Agent to RPP and then to Crediting Agent (steps 1 to 3).
2. Crediting Agent will notify the Creditor about RTP Reject (step 4).
3. Crediting Agent will send an acknowledgment response back to the Debiting Agent (steps 2A and 3A).

. 

       2. Request to Pay – Refund:

In case if Biller/Merchant wants to refund their customer then, Merchant will enquire about the transaction from PayNet and initiate a refund. The refund will be formatted as a request to pay and will be sent to Merchant’s Bank for approval. Once the Merchant authorizes then RTP-credit transfer flow will continue to credit back to the Customer.

Step-by-step flow:

1. In some circumstances when Biller/Merchant is required to refund their customer, Biller/Merchant can make use of Request-to-Pay Refund flow.
2. Biller/Merchant login to RPP Backoffice, search for the transaction and initiate refund request for the transaction.
3. The refund request will be formatted into a payment request and sent to Biller/Merchant's bank for approval.
4. Customer will get their money back upon Biller/Merchant approval of the payment request.

3. Request to pay – Redirect flow:

Once the customer is ready to make payment from Merchant’s/Biller’s site/application, The customer (Debtor) will be redirected to the bank of their choice to authorize the payment.

4. Request to Pay – Forward:

Some scenarios, the Merchant may send a request to pay, for a bill payment to the Customer (Debtor1) which is supposed to pay by another customer (Debtor2). So Debtor1 will forward the request to Debtor2 via PayNet.

    5. Request to Pay - Batch Processing:

Sometimes corporate/merchant (Creditor) instead of sending individual payment requests to multiple customers, can choose to upload the file containing all the requests they would like to send out via Merchant Bank (Crediting Agent). On receiving requests from Crediting agent, PayNet debulks and sends all the requests to respective customers via their participants.

Used message types for Request to pay:

RPP payment solution is based on the rules and constraints specified in the PayNet RPP Specifications and on the UNIFI (ISO20022) Payments as well as Industry Standard Messages for Request to pay. Specific messages and unique transaction types signify different payment flows as below.

Request to Pay	Transaction Type	Request messages	Response Messages
Request to Pay by Proxy Request	851	pain.013.001.07	pain.014.001.07
Request to Pay by Account Number	853	pain.013.001.07	pain.014.001.07
Request to Pay (Refund)	854	pain.013.001.07	pain.014.001.07
Request to Pay by Proxy (Forward)	855	pain.013.001.07	pain.014.001.07
Request to Pay by Account Number (Forward)	856	pain.013.001.07	pain.014.001.07
Credit Transfer (RTP Decoupled)	060	pain.013.001.07	pain.014.001.07
Credit Transfer (RTP Redirect)	070	pacs.008.001.06	pacs.002.001.08
Reject Request to pay (Decoupled)	852	camt.007.001.08	camt.025.001.05
Request to Pay (Refund)	854	pain.013.001.07	pain.014.001.07
Credit Transfer (Refund)	012	pacs.008.001.06	pacs.002.001.08
Request to Pay (Redirect)	861	pain.013.001.07	pain.014.001.07
Account enquiry	510	pacs.008.001.06	pacs.002.001.08

Conclusion:

Real-Time retail payment platform is an innovative resilient architecture, that supports high-volume transactions with ISO20022 XML standards, carrying extended data of payment and same time providing secured cost-effective real-time payment. 

The service Request to pay is already launched and is expected to transform the Malaysian retail payment landscape. Some financial institutions are already go-live with the Request to pay service and others are in different phases of implementation. Soon Malaysians will avail the benefit of Request to pay and be part of the modernized digital payment ecosystem.

 

Pay with flexibility – Request to Pay

 

Overview:

Globally financial institutions are innovating and improving their capability to address evolving consumer expectations, razor-thin margins, and increased competition. With the continued adoption of real-time payment schemes across the globe, a set of overlay services are also being developed in parallel, to leverage the low-value instant settlement capabilities provided by the real-time schemes. An overlay service that is gaining a lot of ground is Request to Pay. The service not only enables businesses to manage cashflows more efficiently but also enables payers to have more control over their payment obligations.

Current Pain Points:

• Cash flow management: Some businesses accept partial payments to have greater control over their cash flows. However, in many cases, businesses do not have proper systematic architecture and enabling processes to receive partial funds, reconcile against underlying unique transactions and track the next payment due date details, etc.
• Optimization of working capital: Often in credit card payments, after authorization of payment by the payment provider, transactions take several days to process and settle. Also, charges associated with the processing of transactions are high, which can end up costing millions each year and delaying the final settlement for the merchant.
• Direct debit payments: Used typically for recurring payments like household bills, subscriptions, memberships, charitable donations, etc. Organizations debit the customer account on an agreed date. However, the service generally takes more than two to three working days to process the payments.

What is the Request to Pay?

Request to Pay can be defined as allowing a Payee (or creditor) to claim an amount of payment from a Payer (the debtor) for a specific transaction. Request to Pay is an enhanced messaging service that can facilitate real-time payments by supplementing the existing payments infrastructure to provide more flexibility to businesses and consumers.

How does it work?

Request to Pay acts as an overlay service that provides the ability for consumers or businesses (acting as a payee) to send a payment request to consumers or businesses (acting as a payer).

The payer can access the payment request details including reference number, amount, and due date, and act on the request, including choices to make the full or partial payments, and choose a payment date (if allowed).

Additionally, the service can be enhanced to have features such as

Status report: On acceptance or refusal by the payer, the status would be sent back to the payee via the payee’s payment service provider.

Choice of Payment Method: Making the requested payment via an instant payment scheme might be the most efficient method. However, in some instances, the payment may need to be paid via other payment methods.

With the objective of a real-time and payment scheme agnostic process, Request to Pay can be used to supplement the existing payment methods to provide more control and flexibility to both corporate and retail customers.

Hence this versatile overlay service has the potential to improve service levels in many different contexts like

• Customer-to-Business (C2B)
• Business-to-Customer (B2C)
• Business-to-Business (B2B)
• Person-to-Person (P2P)
• Government-to-Customer (G2C)
• Government-to-Business (G2B)
• e-invoicing
• online commerce

Request to Pay business scenarios

The scope of the Request to Pay standard framework can support a range of payment scenarios, which can cover generic, region, scheme, or business-specific use cases. A few of the scenarios are illustrated below:

A Payer can ‘Accept’ or ‘Decline’ the Request to Pay instruction.

As part of acceptance, the payer can pay immediately or on a future date, if the payee allows.

For both the above payment options, the payer would have the choice to choose a specific payment scheme to initiate the payment, such as low-value ACH, high-value wires, or Instant payment.

Additionally, the payee would be allowed to modify the amount indicated in the Request to Pay instruction.

Payer acceptance or refusal can be transmitted to the Payee via a status report message.

Logical business models

Request to Pay functionality can be achieved by multiple frameworks and established models. The models illustrated below provide a view of the actors involved and the overall ecosystem.

o  Banks or PSPs are connected to the national clearing system.

Illustration of Request to Pay regulated by a clearing scheme.

o  Banks are publishing standardized open banking APIs (application programming interfaces) which can be accessed by fintech use.

Illustration of Request to Pay initiated from Open Banking API.

Standard messages for Request to Pay

Most of the payment schemes consider standard ISO20022 XML format to build Request to Pay framework more or less with same message type including some variations.

• Request to payment to the payer: pain.013 (Creditor Payment Activation Request)
• Response to Request for payment: pain.014 (Creditor Payment Activation Request Status Report)

Applications impacted

Implementation of Request to pay may impact several banking applications as below.

• Core banking system
• Mobile/Web-based application
• Payment processing application
• Sanction/AML/Risk application
• Report/Advices application

Countries adopted R2P

Request to Pay overlay services has been adopted by several real-time payment schemes across the world. For Example, UPI/IMPS (India), TCH RTP (US), SCT Inst (EU), Faster Payments (UK), NPP (Australia), and FAST (Singapore) to name a few.

Additionally, SWIFT gpi (SWIFT Global Payment Initiative), which ensures that globally cross-border payments meet the industry’s expectation with respect to speed, traceability, and transparency, also support R2P implementation.

Benefits

In general, Request to Pay helps improve transparency, improve controls around payment execution and enable smoother end-to-end processing and reconciliation.

The speed, security, and convenience of Request to Pay is expected to provide real value to consumers, and businesses, specifically small and medium-sized enterprises.

Receive authorization from Biller and pay the bill revised future date.

Receive authorization from Biller and pay the bill revised future date.

Explain the problem and request Biller for additional days to pay the bill.

Bill payment is pending due to their busy life or insufficient funds.

Consumer

Allow donating a later full, or partial amount as per the donor’s convenience

Lack of flexibility for recurring or partial payments for donors to donate to Charity.

Non-profit organization

The flexibility of payment with real-time status updates keeps up the connection with donors.

Small Business

Due to delays in payments cash flow challenges and follow-ups with vendors.

Request to Pay can help to build communication between the parties.

Flexibility to pay bills upfront in full or in installments and track those payments in real-time.

Large Business

Payment requests and transactions contain customer reference and remittance information.

Reconciliation of High-value payments is expensive and often takes more time.

Simple, easy, cost-effective, and time-saving reconciliation process.