A slightly long but hopefully simple primer
---------
1. The essence of a payment transaction
Actors:
Suresh, the sender, who needs to send the money
Ramesh, the recipient, who (obviously) receives the money
Ramesh, the recipient, who (obviously) receives the money
Props:
An amount, a certain quantity of money (which happens to be with Suresh)
A piece of cake, (which happens to be with Ramesh)
A piece of cake, (which happens to be with Ramesh)
Action:
Suresh hands over the amount to Ramesh.
Ramesh hands over the piece of cake to Suresh.
Ramesh hands over the piece of cake to Suresh.
End of scene. What you just saw was a payment in (bad) poetry followed up by a service delivery in lieu. Simple right?
2. The payment plot gets thicker…
Long time ago, with the advent of banking, people began to entrust the banks with their money and instead of directly making the payment (as you witnessed in the previous scene), began instructing their banks to make payments on their behalf. These instructions would mostly be in a written or printed form.
Now, banks by design had to deal with a lot of customers. So, they had to come up with some way to ensure that whenever Suresh asked them to movehis money through a written instruction, they would be able to know for sure that it was indeed Suresh who had asked them and no one else.
For a good part of banking history (even now), bankers (and the legal folks) relied on what is known as a ‘wet’ signature. That is, Suresh would take out a pen and draw a scribble that was supposedly unique to his hand. The bankers would visually match the scribble with the scribble they had on record (whenSuresh had ‘signed-up’ for the banking service). If the bank employee handling the written instruction deemed there was a match, the bank pretty much followed Suresh’s instructions and made the payment on behalf ofSuresh.
3. And thicker…
Then came the computers, the internet, data-centers and the age of digital banking. PINs (Personal Identity Numbers) and Passwords got introduced as the shared secrets between the banks and its customers in place of the signature scribbles.
So now, Suresh on his computer would open up a website of The Scissor Bank, fill in a form providing Ramesh’s account number, say:11223344 (more on this coming up!) as the recipient, the amount and his secret PIN/ password.
The Scissor Bank would then digitally match the secrets and move the money to Ramesh’s account.
Suresh and The Scissor Bank have to be triply sure that no third party gets to know his shared secret PIN/ Password. Why? Because if even one more entity gets to know it, it no longer remains their super special shared secret! Right?
That brings us to two more lil’ issues as well.
One, Ramesh has to reveal his unique financial identity (account number: 11223344) as recorded by his bank to Suresh for Suresh to be able to pay him.
Two, if Suresh happens to have an account with The Scissor Bank (the shiny new bank round the corner), there is a need to have a mechanism to first move money between The Scissor Bank and The Rock Bank and then for the banks to individually move money to the designated accounts (not necessarily in that order). This introduced the need for Ramesh to specify additional routing information to Suresh.
Not that this was not partly solved. Card networks (Visa, MasterCard et al) and other switch and settlement providers put the plumbing in place but individually, each left atleast one gap in their service. While one under-rated usability, another killed convenience and another sacrificed security.
4. Enter, the untrusted hero
Then came the online merchants. Shops began to get replicated in the digital world. Suresh could now visit Ramesh’s online ‘piece-of-cake.com’ shop and order a piece of cake and Ramesh would send over one of his delivery boys with what else but a piece of cake.
The Rock Bank and The Scissor Bank were of course happy, since Ramesh had agreed to pay them extra for enabling Suresh (and thousands of others likeSuresh) to buy from his ‘piece-of-cake.com’ shop. Secretly, Ramesh was their hero but they could simply not trust him!
5. The one tiny little big problem
Remember the fact that Suresh and The Scissor Bank had a shared digital secret?
It so happens that when Suresh pays Ramesh on piece-of-cake.com, he has to provide his financial id (account number: 99887766, The Scissor Bank). Which was kinda ok. The scary part was that, for a good while, he did not have to even provide his shared secret to authorize his payment! Which meant that Ramesh (or the evil digital pirate hacker Kruresh) could easily use this information to make Suresh pay for things Suresh had no intention to pay for (like buying a pirate ship).
So The Scissor Bank had to take Suresh’s shared secret and make sure that no one, not even Ramesh could see it. They achieved this but ended up with so many page hops that the payment experience ended up more like a trip down the adventure park. Why? because no page other than The Scissor Bank’s page could be trusted to fetch this information! So the experience ended up looking something like: Ramesh’s cake page hops to a generic payment gateway page, hops to a Scissor Bank page, which then hops to a bank confirmation page and then back to Ramesh’s payment receipt page. Whew! Each hop increased the chance of Suresh, simply dropping off.
Obviously, Ramesh wasn’t happy about it. Suresh certainly was not. Secretly,The Rock Bank was not happy about it and neither was The Scissor Bank.
6. Um… This was supposed to be about something called the UPI right?
Patience, my young friend.
The banking gods in India of course wanted to solve all the woes of all its people. So they decreed into being a not-for-profit super entity called theNPCI (National Payments Corporation of India). Its initial job was to provide a backbone for the inter-bank transactions, which it executed by creating the NFS (National Financial Switch).
Then it took on an even more ambitious product called IMPS (Immediate Payment System). This was a set of pipes that allowed 24x7, instant inter-bank transactions. Only a handful of countries have a payments infrastructure of this stature. Judging by its output, NPCI is evidently led by a set of really fine professionals.
Then, attempting to find a cure-all to all that ailed payments, in one shot, they gave software architecture rock-stars (these folks were also the tech forces behind the colossal UIDAI project) Pramod Verma and Sanjay Jain, among others, pretty much an open canvas to paint the picture of an ambitious piece of national payments infrastructure that would be a cure-all of sorts. Thus was born the Unified Payments Interface a.k.a. UPI.
7. Now back to the story
While UPI is capable of a lot of things related to payments and funds transfer, this story will only focus on a few things that are at its core. (Also, please be aware that these are the early days for UPI and my understanding may need improvements :). Anyway, here goes:
7.a. Introducing: The PSP
A PSP (Payment System Player) in the UPI ecosystem is a certified and trusted entity that acts on behalf of a bank (in the future, should technically be open to non-banks as well who are authorized to hold deposits). The PSP is actually the technology platform provider. Could be the bank itself or it could be an entity which works with a bank/ on behalf of the bank.
So, assume for now that The Rock Bank has a PSP named Rock and The Scissor Bank has a PSP named Scissor. The PSPs are the payment end-points as far as NPCI is concerned.
7.b. Introducing: The virtual address
Remember the problem where Suresh and Ramesh for various reasons had to make known to each other, their financial identities? While that by itself might sound benign, there are many situations where revealing one’s financial identity might be dangerous. For sure it is cumbersome.
So UPI talks about this thing called the virtual address. A virtual address takes the simple form of address@provider
For example, if Ramesh’s account with The Rock Bank may simply be calledramesh@rock and Suresh’s account may simply be called suresh@scissor
This is a simple format similar to email ids. Where this gets interesting is:
- Suresh could have a virtual address suresh@rock even though his bank isThe Scissor Bank!
- The validity of a virtual identity is absolutely flexible. So if The Rock Bank(which is the provider for @ rock addresses) so enables, this might be a permanent address or just a Monday address or even a one-time-use address or an address for only loose change! The definition and implementation is completely left to the provider. Neat!
Now, tokenization services already exist, especially where cards (ATM/ Debit/ Credit) have been involved, for similar reasons.
The virtual address concept however is fundamentally superior due to the following reason: While the token system is required to be provided only by the issuer (the entity which has issued the original card/ instrument/ holds money on your behalf), virtual address is a token service that is loosely coupled to the original issuer. Thus any PSP could issue a virtual address for any customer with any bank and on top of this, implement any business rule for its access. Also, the addressing scheme is much more inclusive and human-readable.
7.c. Introducing: The Common Library
Remember the fundamental ‘one tiny little big problem’ we talked about a bit earlier, due to which no one could ever safely collect customer’s shared secret except on the original issuer’s own interface?
UPI solves this by providing a mutually trusted interface. It does this through a common client library (currently provided as an Android SDK) that each PSP could embed in its customer facing app. The job of this piece of software is to provide a user interface to securely collect the user’s credentials (PIN/ password/ biometric) such that no one except the original issuer could decipher it.
Assume a case where Suresh is sending money to Ramesh but using a third PSP called Paper belonging to The Paper Bank.
[Recall that Suresh’s bank is The Scissor Bank and Ramesh’s Bank is The Rock Bank, it is eminently possible for Suresh to use neither of these two PSPs but a third one while still using the same underlying bank account! Why? Just because Suresh seems to like it so! - such a level of choice is customer empowerment by design]
The common library provides the underlying (acquiring PSP) Paper’s app only a context locked and encrypted credential block. Paper can only pass it on to NPCI through the UPI RequestPay API ‘as is’. The UPI framework will of course pass it on further to the original PSP (Scissor) for authentication along with the rest of the transaction payload.
There is another neat little trick up the sleeve of the common library. PSPs using the common library expose a deep linking hook (upi://pay/…) to merchant apps and web services that need to simply collect payments, without worrying about the implementation.
Imagine a merchant app JustAnotherKart which wants to collect payments, it simply has to invoke the deep link on the phone and the phone will display a list of all PSP apps available. The customer can then choose one and authenticate the payment.
7.d. Asynchronous by design
The most delightful thing about the way UPI has been constructed is by making everything asynchronous.
Most other online payment systems are synchronous request-response systems where the transaction acquiring system sends a transaction package and waits for a response. Asynchronous systems on the other hand are pretty cool. They send the transaction request and then chill out and do other stuff. Once the servers and other parties have processed the transaction, they call back on a designated API end-point exposed by the requesting party and simply update the status of the transaction. This enables robust implementations.
8. The creamy layer
Very interestingly, UPI is a set of services that sits as a layer on top of existing national financial pipes put in place by the NPCI. So it acts as a value adding layer, the creamy layer which does the following core functions:
a. Provide a layer of secure communications. By incorporating a cryptography protocol that requires each trusted end point viz. the PSPs to be able to communicate securely to the UPI APIs it ensures that a transaction is securely transmitted end-to-end.
b. Provide an address translation layer. Enables resolution of virtual addresses to the underlying financial addresses.
c. Provide a protocol for transaction request and response flows.
d. Provide a framework for liability, settlement, risk and issue resolution. This comprises of things that take place behind the scenes to make the actual flow of funds between the banks.
9. The end, almost
All in all, UPI is a futuristic payments infrastructure designed for India.
- It makes it easier for people like Suresh and Ramesh to participate in the new digital economy.
- It opens up the underlying banking infrastructure to payments and systems innovators to make apps and products that would otherwise never have seen the light of the day.
- It helps the banks to stay relevant in these times by decoupling the storage and movement of value from the interfaces that could enable it efficiently.
- A short-sighted view would be that it helps the banks compete with the new-age wallets. The better perspective is that it creates a more inclusive and inter-operable ecosystem comprising of all stakeholders (wallets will also be allowed in the near future, we are told).
- It empowers the customers by giving them choice. No longer will a customer of bank A be locked into using a sucky mobile banking app provided by bank A. It essentially decouples transaction initiation and collection of authentication from the banks’ interfaces.
- Improves the UX for merchant app checkouts. When implemented, this should be better than the page hop-skip-and-jump routine being imposed for securing transactions today.
- Presumably, it lowers the transaction costs because of its superior design, interoperability, scalability and systemic risk reduction.
In the end, it is good to remember that all that Suresh actually wanted was to eat a piece of cake and all that Ramesh wanted was to keep baking them! Banking, wallets and all the technology built around em are pretty much a bunch of necessary evils. The best that they can aspire to be is to become as invisible and trust-able, as soon as possible. UPI seems to be pointed in that direction.
Further reading:
No comments:
Post a Comment