The Anathema of Reversals in Retail Payment Systems

As we reduce the time between clearing and settling within retail payment systems, (merging them completely in a small value gross real time payment system (SVGRTP)), we lower risk, but magnify the effects of mistakes. The bank that moves a $100 million overseas does not think an instant later, “Maybe I only wanted to move $20 million”. Retail payments systems, however are fraught with buyer’s guilt, and erroneous entry of amounts. The severance of communications between transactions creates the great bane of all payment system buffs, the system generated reversal. 

We eliminate the system generated reversal in a SVGRTP because either the communication arrives in order at the point of presence (POP) or not. If the message arrives intact at the processing point then the transaction executes, if not then the receiver (after a few seconds) says try it again with no cause for worry of a double debit.

If the process moving the funds (call it funds transfer) receives a duplicate message then it moves nothing and calls the notification procedures with the list of notification addresses. If the fund transfer is not a duplicate, funds transfer completes instantaneously on message receipt.  A standards committee needs to polish the protocols; however the elimination of system generated reversals does not make a SVGRTP immune to the errors and whims accompanying the human experience.

The consumer that wants to return goods or the clerk that transmitted the wrong amount to pay, need a mechanism to move funds from the retailer account back to the consumer account that is equal to or less than the amount that originally moved from the consumer to the retailer.

I want to stick with the principles of using account numbers or their surrogates sparingly, and not making the recipient of the funds the originator of a transaction. For every personal electronic device (PED) that initiates payment transaction it must have an associated unique retailer ID. That retailer ID (belonging to the consumer) becomes part of the notification details. Returns and voids then become separate transactions, originate from the original payee and use the retailer number carried in the payment notification to create the destination for the return or void payment. Theoretically using this method for a return, a consumer and a retailer could bounce the same payment back and forth forever.  Diagram 11 shows the dynamic relationship.

Diagram 11: Voids/Returns within a Single SVGRTP

Next Blog:  Response to comments, or new equipment for a new age, or risks and vulnerabilities of a SVGRTP, or expanding the beast.