Thursday, June 5, 2014

Cutting out the Middle Man, Small Value Consumer Payments without Acquirers, Payment Networks, or Special Equipment

If we look around our payment environment we see a huge amount of money spent on messaging and more money on secure messaging. We spend this money at increasing rates although users of every other communication platform see their costs dropping.  What makes payment communication cost so much more than any other type of communication? Tradition and paranoia are the culprits behind the extravagant prices paid for this specialized chatter.

If we examine the PayPal model, we see that it is a good, effective, and cheap way to transmit funds from consumer to consumer and sometimes between consumers and retailers. Regardless of its much lower cost than the traditional acquirer authorizer networks, PayPal really has not made significant penetration into the retailer market. The reason for low usage appears to be risk. It takes too long for payment to actually arrive in a payee account; thieves escape long before a retailer knows that a payment will never arrive.

The first criterion of a cheap safe system design is speed.  Today a retailer expects to receive an authorization within a few seconds and everyone in line gets impatient if the approval takes longer than 10 seconds. The approval is not money in the bank, but it is a guarantee (or will be until we switch to EMV) that funds will arrive within the time expected.  Charge backs exist; however, they are not the norm.

I want to refer back to diagram 1 (SVGRTP in Chapter 2: A Small Value Gross Real Time Payment System) and blow up the routing process in diagram 7 below.

Diagram 7: SVGRTP Routing

Diagram 7 depicts the 3 critical steps of a payment transaction. The translation need not use LDAP (my technical prejudices are showing), but a translation of some sort is a critical requirement. The 3 processes need to take place in that exact sequence and without interruption (in my humble opinion). Another critical aspect of the process is its use of bank data in a secure manner.

To cut out the middle man, a payer needs to look up a payee account to fund it. However, the payer cannot gain access to the payee account or view any detail about it, because of security concerns.  Retailers need a common depository that banks access to securely retrieve account data. Diagram 8 shows the required structure graphically.

Diagram 8: Retailer Depository of Banking Data

The structure depicted in diagram 8 can only exist if retailers build it. Once built, however, the dominating payment architecture will soon be a quaint obsolete artifact of a bygone age.

Next Blog: Cutting out the Middle Man, Part II

No comments:

Post a Comment