Converting Credit Card Available Balances to Cash and Sidestepping FI Usury

When consumers travel by public conveyance they become captives. Moreover, long haul travelers become easy prey for diabolical payment architects blatantly blurring the lines between debit and credit payment applications.  

Consider the ubiquitous embedded screens on the seat backs of jumbo jets and place them on all modes of transportation where passengers wait patiently for their journeys to end. Next consider optional ticket prices to include cash available to gamble, access proprietary content (maybe not actually used), pay for contingent travel (such as discounted hotels if circumstances interrupt a trip) or other similar amenities. If the option includes winning money (not necessarily by gambling, but by contests, refunds, or a host of such promotional items) then effectively $x charged to a credit card becomes $x - $y where $y is cash received back by the consumer.

The cash strapped traveler may use their credit limit to access ready cash at a discount and the conveyance providers may well get the use of a generous float if weary travelers do not stop at a Kiosk to get their cash back but let it ride until their next trip. Further the conveyance providers have a source of data that shows what their custom want to do to wile away the hours.  The losers of course are financial institutions (FI) that get less money than they would otherwise for a cash advance on a credit card.

Providing cash to credit cardholders is not just for the travel industry. It is possible for inspired entrepreneurs to provide a cash delivery service to credit card customers.  The cash strapped consumer gives the credit card number to the delivery company that initiates a request for the cash, the card not present (CNP) fee, and a fee for the service. Once again all are happy except the FI that may complain that it violates card acceptance agreements somewhere way down in the small print.

There are many such ways to wring cash from credit cards without the regular FI fees and perhaps now there are certain unscrupulous merchants that ring up a sale, only to give the majority of the value back to their custom. There is likely an economic model that gives a price point for the cheap loan service including covering the risk that the evil merchant takes if discovery means the inconvenience of changing their merchant number or some other ruse. These after all are desperate times for a middle class under siege.

Next Blog: Bad Ed II: new filters for a new era of fraud

New Payment Systems Processes for Dispute Mitigation

Banking associations, clearing house associations, and central banks have rules and laws governing payments made in error. However the payment architectures described in this blog such as small value gross real time payment systems, push payment architectures, and issued digital currency have little in place to protect payers that move value to the wrong payee. Reversals used by debit card networks or voids used by credit card networks will not work with these new types of payment systems. Imagine reversing a digital currency payment and then imagine how ne’er-do-wells may exploit such a function. Similar security concerns exist for nullifying transactions using the evolving types of payment methodologies discussed in this blog. The other form of dispute processing designed for the unhappy payer, also needs a transparent and fair dispute mitigation process.

Issued (notably not mined) digital currency has the best prospects for dispute mitigation because properly designed digital currency contains more than value; it contains logic to process data about its container and other environmental factors. Further digital currency can have logic that signals the correct disposition of the goods (services have tougher hurdles) exchanged for the digital currency. 

For example, a consumer sends a digital amount to a retailer for an item marked with a universal product code (UPC). The currency determines if it arrived in the right till by checking public attributes of the till such as its certificate and perhaps a known precise geographical location. If the environment does not meet the expectation of the currency then it revokes its own certificate and if possible transmits the action to its certificate authority or some yet to be invented currency monitoring body.

If the currency finds its new environment matches expected after-transaction criteria then it signals OK and that status transfers to the brick and mortar security monitors mounted at exits. The payer walks past the monitor that matches the payment initiating device and the product UPC and allows an exit without raising an alarm.  On-line merchants may have more complex processing steps such as sending the initiating device the periodic status of the UPC as it moves from warehouse to shipper to payer door.  If the movement does not occur as expected within the times declared by the merchant then the buyer may have a legal right to revoke the digital currency certificate.

Smart tags too may add to the new automated dispute processing infrastructure. If the smart tag determines a jolt occurred past a known threshold then the tag record the fact and on arrival transmits the exact geographic location and time of the jolt to the payer and thus the entity liable for the damage.

Real time payments and push payments do not bring working code into transactions, however initiating and receiving devices attaching various data with payment information can precisely identify what the payer expected to purchase and when a transfer of goods completes after payment.  The smart tag recording of damage still applies. 

It is difficult to estimate the cost for exotic dispute mitigation infrastructure for modern payment methods, however no doubt the processes will be more satisfactory than the methods in place today with payment cards, their obscure rules, disgruntled merchants, and their custom.

Next Blog: Consequences of anonymous payment methods

Will Payment Cards go the way of the Dodo

The evidence is clear and the trend shows payment cards slowly leaving the retail payment infrastructure. Large retailers that issued their own private label cards sold their stock and processing to professional payment services firms. Telephone operators and Internet service firms assume the role previously occupied by issuers and acquirers. Retailers create their own payment initiation protocol to preempt hostile acquiring agents from increasing their fees. Something must give or retailers’ slim margins will force consumer payments back to riskier payment methods such as cash or paper check.

On the horizon sits a new form of payment architecture, cheaper, safer, and faster than anything card technologies offer. Clearing, settlement, and notification to the parties of transactions take place at the speed of light without middlemen pocketing fees from lack of a physical token at a payment acceptance device or a chargeback for dubious causes. The only question remaining is will the change occur quickly once a small value real time payment system becomes ubiquitous or will the old guard fight back with discounts and incentives.  Will a payment system that works equally well regardless if the payee is a retailer, a charity, or a government, trump a system loaded down with fees and designed only for retailer payees?

Consider Diagram 30 that contains a portrayal of a small value real time payment system.

Diagram 30: Small Value Real Time Payment System

The payer financial institution (FI) retrieves the payee data from a common data store and acts on the instructions from the payer and notifies the payee and payer in real time about the results of the transaction and then moves the value of the payment to the payee’s FI. This is a valuable service and warrant fees (including a reasonable profit).  If the infrastructure exists (and it seems that plans are under way for its completion; see positive movements in that direction http://paymentnetworks.blogspot.com/2014/10/movement-to-small-value-gross-real-time.html ) then the funds for the infrastructure and the processing environment must come from somewhere. The operators need to charge a fee similar to what the Fed charges for use of Fed Wire, namely whatever is necessary to cover the cost of running and maintaining the system, however without profit. FIs also can charge whatever fees they want as long as they do not collude with each other to set one illegal fee. Payers and Payees negotiate with each other to determine the payer of the bank fees.

So what will a few bits of data cost to transport from one point to another. That is a question of conjecture but logically it will cost a lot less than what payers and payees pay for the archaic structure currently run by huge monopolies.

Next Blog: The new entrepreneurs selling a push system to an eager public

Using Throughput Measurements to Detect Data Scraping Attacks

If retailers insist on using out-of-the box operating systems to process card payments in electronic cash registers (ECR) then the least they can do is perform the minor calculations needed to determine that throughput within the ECR meets nominal expectations. Microsoft has provided various functions to monitor processing such as QueryPerformanceCounter (QPC). It is possible to use these functions to determine if there is unusual activity within an ECR.

ECR suppliers can create benchmarks for movement of financial data across their platforms both before and after distribution to customers. Timing begins before reading a port containing external financial data and ends at the point after clearing memory containing financial data just before returning control to a non-financial data processing application. 

A terminate stay resident (TSR) application then can read the measurements on a continual basis and determine if increased processing time indicates a likely data scraping attack. The following rough pseudo code gives an example of this type of countermeasure to a data scraping attack

.

            Read Timer with highest resolution possible

                        Process Financial Transaction

                        Wipe financial data from application memory and I/O buffers

            Read Timer with highest resolution possible

            Write End timer results – Begin timer results to next position of data store for TSR

The TSR then continually looks at the values in its data store and if the values start increasing consistently beyond a reasonable deviation variable then the TSR performs actions based on its configuration.

This simple method comes from descriptions of data scraping attacks in various media. The presumption that these attacks originate within the ECR ensure that monitoring activity occurs for only one financial transaction at a time. If the data scraping attacks occur further up stream then similar methods of measuring throughput are possible, however the complexity of the approach increases.

The pseudo code mentions the wipe of application memory containing financial data. If applications do not contain this step then this monitoring approach is futile. So please developers and ECR manufacturers, wipe after flushing.

Next Blog: Something pseudo wicked lurks nearby

Is the Diversity of Payment Origination a Symptom of Struggling Middlemen

Points of sale are one of the few places where it is known people exchange money for goods or services. In the Halcyon days before payment cards, a merchant accepted cash or checks and consumers carried those payment methods with them. Now central banks want to eliminate the paper check and no one carries cash with them unless to buy illegal goods or services. In some cases underground outlets accept plastic. Yet for the many diversified ways to pay, the fees for payment keep increasing to the point that merchants make ridiculous attempts to avoid them (see http://paymentnetworks.blogspot.com/2014/10/why-retailers-cant-build-payment-systems.html for my discussion on CurrentC) and charlatans create fatally flawed crypto currencies such as Bitcoin (see http://paymentnetworks.blogspot.com/2014/06/an-analysis-of-bit-coins.html ) to prevent middlemen from picking retailer pockets.

Now point of sale (POS) equipment manufactures recognize that consumers will originate payment from continually changing technologies and so build machines to accept all of them (see http://www.paymenteye.com/2014/10/30/former-head-of-google-wallet-debuts-alternative-payments-terminal/ ). Is it not time to ask if the diversity is unwanted and used not for efficiency, security, or cost advantage, but because retailers must offer all the choices foisted on the consumers by all those eager souls desiring to sit just between the wallet and the till.

A retailer that does not accept a method of payment that a consumer uses will lose a sale, which is the main reason they bow to the ridiculous requirement of a chip card when their current POS devices effectively do the same thing with PIN entry and derived unique key per transaction (DUKPT). The card service industry sells consumers a pack of lies on a routine basis by insinuating consumer laws do not protect their accounts or that theft of card data necessarily means a successful attack against consumer accounts. How many parrots out there clamor incessantly about the growing threat of cyber attacks against payment systems when actual details of the percentage of successful attacks compiled by the Fed in the US and many other European and other countries show successful attacks against brick and mortar retailers pale in comparison to the value successfully cleared and settled. When a PIN accompanies a purchase request, there are few claims of a successful intercept of payment data and subsequent attack (See Federal Reserve System; The 2013 Federal Reserve Payments Study Recent and Long-Term Payment Trends in the United States: 2003 – 2012 Summary Report and Initial Data Release; (December 2013); p.32 and ff http://www.frbservices.org/files/communications/pdf/research/2013_payments_study_summary.pdf ).

The retailers are not helping their own cause, because they keep insisting that consumer payments originate from retailer payment requests to the consumer financial institutions. The complaints about payment service monopolies, interchange fees, and charge backs occur because of the firm but unsubstantiated belief that knowledge of customer payment data increases marketing and future sales opportunities. The CurrentC architecture uses the current payment system architecture with “pull” logic. The only difference is knocking out Apple Pay and all other Near Field Communication (NFC) origination technology but unless a retailer issues the payment card or routes the card correctly to the authorizer, transaction costs remain virtually the same, regardless of promises of huge discounts.

There is the possibility that consumers do not care how they pay for their goods and services as long as a payment does not result in a successful and uncompensated attack on their account and the initiation method is not overly awkward or time consuming. If the origination method also means a discount over another method, then cost conscience consumers use the least expensive method. So why do financial institutions (FI) issue debit cards and let their consumers use them over credit card networks? The interchange fee seems like the most logical answer. So how do retailers get money from consumer FIs without astronomical fees? They ask consumers to push money to retailer accounts and let them do it for less than a percentage plus a fixed fee and both sides of a transaction split the middleman’s money.

Next Blog: New Musings