With Raast, context is Key

Raast by the State Bank of Pakistan (SBP) has received a lot of excitement and interest from the financial payments industry, particularly from the young guns over on the fintech side of things. The SBP-backed gateway is a savior in providing confirmation of instant payments and access to debit accounts and low-cost transactions.

However, one distinctive feature of Raast has been overlooked and going forward will set Raast apart from all the contemporary payment rails available in Pakistan. That distinctive feature is Raast’s ability to capture the context of the payment.

To make things simple, payment rails such as Local Fund Transfer (within same bank), Credit/Debit Card Transaction, IBFT, ePay Gateway (NIFT/APPS) or BPS are different vehicles to transmit payment information and authorizations between two Financial Institutions using a technology intermediary. This transmission has always been restricted to the flow of payment information.

To make it simpler; imagine if the railway line between Karachi and Lahore was only used for moving passengers and not containerized or liquid cargo. That means the other transportation infrastructure would be required to move the cargo and that creates further inefficiencies and wastage of resources.

Getting two nodes connected, whether cities by means of road, rail or airways or banks by means of technology intermediation is a great infrastructure piece for the financial efficiency in any economy. But restricting it to just the movement of payment flows is sheer underutilization. Unfortunately, such design elements were either not foreseen or restricted to the optionality of narration or purpose in an IBFT transaction (which was never used or enforced effectively).

In 2016, I penned an article “The Context is Missing” and wrote a whitepaper for the industry and SBP on “Accelerating Corporate Digital Payments in Pakistan” where I explained my personal realization that the payment infrastructure does not support the movement of non-payment data i.e. the context of the payment, between two financial intermediaries and the sender/receiver. The key question that needs to be addressed before diving into the importance of the marriage between context and payments, is what Contextual Payments is.

Payment is not the end, but the means to an end, the end being a business transaction or exchange of goods/services. The trade or exchange is what the context captures. The context may include multiple data elements or documents such as the contract elements, invoice, sender profile, history, credit score, credit limits, SKU/Service information, tax incident(s), transactional reference(s) and any other corresponding data that is either a prelude to the payments, has to accompany it or has to come after it for audit/reconciliation. 

A practical issue that occurs in most business transactions. Reconciling bank statements against invoices in a way that the bank statement narration points to the underlying invoice/trade. Things get trickier in case of advance payment (no invoice), partial payments, multiple payments for a single invoice, and single payments for multiple invoices.

In these scenarios, the correlation between invoices, payments, and banking statements requires an army of receivable managers to institute audit controls and then update their financial ledgers. Bank systems are not designed to capture these complex scenarios and have too much inertia to innovate in this direction. Payment infrastructure such as cheques and digital payment infrastructure such as IBFT also do not address these issues effectively and throw the burden of managing contextual synchronization to the business users themselves.

Nowhere does this issue get further exasperated than in the handling of taxation. In 2016, FBR and SBP embarked on a program to digitize Duties and Tax collections. A single goods declaration submitted to Pakistan Customs Clearance System carries as many as 16 various tax heads that have to be settled in multiple Treasury accounts held by SBP. Federal Treasury Rules required SBP Treasury systems to issue CPR (Computerized Payment Receipt) separately for each Tax Head.

The taxpayer had to pay a single amount through check over the counter or digital payment, but it had to be split into multiple tax heads based on the Customs Tariff. This means that once the payment is initiated, SBP has to know that this single payment carries multiple tax heads that have to be settled in different accounts and their respective CPR to be issued and communicated back to the sender for the finalization of his tax returns.

Through the brilliant effort of the Payment System Department (SBP) and 1link a solution was designed that was then followed through by GoPB and other P2G use cases by SBP/1link. The same determination and agility that the Payment System Department (SBP) exhibited, in this case, cannot be matched by the new-age private sector processors in handling contextual payments.

Since 2017, the whitepaper has been studied by SBP Payment System Department and in my deliberations, with them, I was told that Raast will provide the infrastructure where context can be captured and moved between Banks/Merchants. In the recent industry engagements on Raast, it is very clear that the SBP Payment System Department, now a cluster within SBP called Digital Financial Services Group has delivered on its promise to make sure the payment rails can capture the context of the payments and then move it across the ecosystem.

This opens a world of opportunities for Banks and Fintechs who can use the easy access of Raast to move credit-related data, analytical insights, reconciliation, tax treatment, and vanilla invoice data. Fintechs are eagerly waiting for the disruptive power of Raast and are excited about how Raast brings about inclusion, efficiency, quicker time to market, and a reduction in cost. But what everyone is missing is the impact that Contextual Payments will make in the digitization of the economy and the effectiveness of payment use cases by moving context within the payment flow.

The latest phase of RAAST incorporates Request to Pay (RTP) functionality through which a business/merchant can initiate a Request for Payment and in doing so pass on structured and unstructured contextual data which will be delivered to the paying customer’s financial institution. Financial institutions can use the rich data to perform data analytics and build further insights about their customer’s profiles to offer them other products and services.