Effective Fraud Origin Detection

The world needs a centralized place to collect unauthorized cardholder transactions. Currently issuers, bank transaction companies, acquirers, retailers, and cardholders do not have a single place to report suspected or confirmed attacks on cardholder accounts. Europe has a better handle on the problem than the US because European issuers must report number and method of cardholder losses (although recently the Fed conducted a survey to get the same data from the US retail payment industry).  Data is nice but quite worthless if it cannot forestall future attacks from the same perpetrators.

I believe I can create a fraud clearinghouse with little or no money, and I might do so if I have a couple of weeks to build it. The fraud clearinghouse I envision is simply a database that collects the following data from cardholders suffering unauthorized expenditures from their accounts:

1. Name and Address of Retailer, or URL, where unauthorized expenditure occurred
2. Name and Address of Retailer, or URL, used 30 days prior but not often by cardholder
3. Dates, times and amounts from 1 and 2 listed above

Look for statistically relevant intersects, find them and report the suspected thefts to the locals.  Once retailers and authorities discover a point of card data intercept on the down low while the attack is in progress, then the game of spy vs. spy can begin earnestly.

Of course if I build a clearinghouse, it might not have the public weight of an institution or firm such as a central bank or a group of central banks. Accurate and statistically valid responses from cardholders do not need to include more data than that listed above in the 3 data elements. More data, regardless of the temptation, may discourage participation, which is the primary ammo for this counterattack.  Requiring the payment system industry to report this data defeats a primary goal, making cardholders aware of their responsibilities to keep payment system costs down by keeping costs for the crooks high.

Next Blog: Events and payment hubs

Payment Systems Built for Ubiquitous Access, Not Profit – The EBT Story

Electronic Benefits Transfer (EBT) created by the United States Department of Agriculture to replace food stamps in the 1990s serves as a model of payment system as infrastructure not as a retailer choice of payment acceptance method. There have been many studies about the effectiveness of EBT as a nutrition redemption method for its beneficiaries, but few if any studies on the effect on small retailers or farmer market stall owners.

Since I have no data to analyze, I will make up thoughts based on absolutely no solid proof. It seems logical to me, that the lure of money showing up in the retailer bank account, without the risk of excessive cash in registers prompted some retailers that did not accept commercial cards for payments before EBT, decided to accept commercial cards because of the experience with EBT.  If they did, then those retailers increased their sales because consumer choice of payment increases sales (absolutely no proof of this, either).

EBT increased the velocity of money in small communities and helped grow the local economies. Couple the sophistication of a modern payment system with a low cost method for increasing demand (internet advertising),  and soon we see struggling brick and mortar businesses increasing sales enough to pay for more consumer choice in payment methods. The big brand cards then competed for State contracts for non-needs based method of cash distribution because they made money from retailer card acceptance and not a government debit card application. Payment acceptance costs rose, marginal retailers, could not pay the increased card acceptance cost, businesses closed, because money issued from government used a for-profit payment system instead of optional closed loop of EBT. (I don’t need facts when I can make up a perfectly logical assumption without basis in reality).

There is a lesson here, but somehow I feel too close to this sector of the industry to know what that lesson is. Perhaps there is a magic balance between public and private payment systems and if government policy promotes small retailers in an incubation stage based on sales or profitability, or some other factor gleaned from facts and not the idle musings of a blogger, then governments get strengthening economies and the payment industry gets graduates helping their collective bottom lines.

Are there too many isms here to look at different approaches for economic growth? Does our polarization prevent seeing if different paths at different stages help society more than attempting conformity to an ism? I think not, but here an opinion does not have to have a basis in fact.

Next Blog: More facts than fiction (in theory anyway)

Does Ubiquitous Access to Payment Systems mean the End of Poverty?

I often thought that people be they in the Bronx, or Outer Mongolia, need access to payment systems as retailers not as consumers, more than they need education, clothing, or proper housing.  If the underserved can sell their goods or services to a worldwide market with immediate payment guarantees, then the despair of poverty must decline. 

The trouble with the concept is there is no money in it. Placing a commercial small payment hub equipped with enough functions to make international commerce viable in a sparse agrarian culture costs quite a bit, especially if a crude infrastructure needs placement there first. Not only is there no money in it, it takes money out of the pockets of wholesalers that function as the sole buyer in many communities, and force them to compete with a broad retail market.

Allow me dear reader(s) to design a payment hub for an impoverished community with minimal modern infrastructure.  First it needs secure connectivity to a small value payment hub outside the region. Next it needs to create accounts for all members of the population that want to sell goods or services. Finally it needs to place funds in escrow, and, pay delivery costs from received amounts.  Such a hub means the community must have electricity, transportation, electronic communication, a viable means of currency conversion, and ability to physically redeem funds. Finally, the payment hub is not viable if the community has no way to communicate to the world what it is selling. Without demand, a supply has no value.

Is it possible to build such a system and ultimately make money from its operation? I think it is, if there is enough of these micro hubs supplied by the same firm that can make a small fee from currency conversions and fund redemption. The key to profitability is taking the same design and replicating it so many times that in the aggregate the small fees eventually pay for the infrastructure and start making a profit. I am not talking about turning a profit in the next fiscal quarter or the next fiscal year, and maybe not the next fiscal decade. How long before the US GDP showed increases due to the expenditure on construction of a national highway system? Can we do the same thing worldwide with Governments working together in harmony for the benefit of people in the Bronx and Mongolia? Yes, but only by recognizing national self interest is an integral part of worldwide growth.

Next Blog: Payment Torus and the gradual removal of payment hub controls or response to comments, or some other topic.

Current Fraud Detection Methods Create too many False Positives

There is a flaw in fraud detection methods employed by the payment industry today: too many false positives. How many transactions pop up as potentially fraudulent, receive human inspection, and may receive human rejection, without any proof whatsoever of a consumer intending to commit fraud.

On the other hand many fraudsters learn that by creating transactional data that does not set off normalcy meters, their  fraudulent transactions receive approval without going anywhere near a human eyeball. Yet there are elements within message that shows prima facie fraud, meaning you could bring the message into court and just the message, and gain a conviction of fraud from the consumer that caused the origination of the message.  The difficulty with the approach is the haphazard collection and discard of data that occurs while a transaction message is in-flight.

For example, say a store operates at an address and a purchase message arrives from a point of sale (POS). The acquiring node tossed the address associated with the phone number once the needle created a circuit; however that address may have nothing to do with the POS operational address. If the two addresses are not the same, then it is possible to say fraud exists because a party to the transaction created the message from a place not known to the authorizer.   

I define machine examination of disparate data maintained in the entire set of transactional data (not just data associated with a part of the journey) as a filter. Millions of potential filters exist but fraud detection engines do not use any of them, because the prejudice to use deviations from known behavior, or newness of a card initiator, waste enough time, without tracking and pulling transactions that contain data that confirms fraud without false positives.

The fraud detection filters have a companion. Evasion detection filters capture transactions deliberately created to evade fraud detection filters and the two filters together create a dialectic response to the cycle of criminal activity. They also show when filters fail because they are too well known by the attacker class.

Next Blog: Find out tomorrow, or response to comments, or is there a demand for payment escrow accounts?

Capitalism, Regionalism, and the Cost of Moving Small Value Payments

What will cost less to payment system users; large multi-national government projects, or, large single firm projects? Can a consortium of firms with in-country monopoly rights create the best cost for consumers, or will Ed’s Bait and Virtual Currency Shoppe, actually offer consumers the best prices for the same service?

Maybe dear reader(s) a consensus exits that security of currency during transport is a primary element to consider during payment system design phases. Speed of completion of an entire transaction from initial clearing to final settlement becomes a primary consideration for designers because of the common risks to payment systems, namely: liquidity, credit, operational, legal, and systemic risk.

A mined virtual currency fails because of the time for validation. One cycle takes ten minutes and during that time the status of the coin remains uncertain. In the real world, when the coin leaves the bum’s pocket the transaction takes as long as the time it takes for the coin to move from the bum to the bum’s friend.  There may be recrimination about the consequences of the movement, but the time of final settlement is quite clear.

Diagram 13 shows a virtual currency system run by a single nation for the purposes of discussion.

Diagram 13 A Virtual Currency Operated by a Central Bank

If the currency has nominal counterfeit protection, potential payees may not use the validation window much regardless of the value size of the transaction.  If the system cannot prevent unauthorized value from entering the system the validation window will not prevent desertion by its users regardless of the cost of the transaction. Validation needs to occur in microseconds from any correctly formatted query regardless of its source.

Replace the Central Bank in diagram 13 with text of your choosing, say giant bank network company, or Ed’s Bait and Virtual Currency Shoppe, or giant bank network monopoly. The diagram stays constant, but confidence and cost does not.

Next Blog: Response to comments, or, new functions for virtual currency

Does Issuing Virtual Currency Fix its Fatal Flaws?

There are quite a few fatal flaws with Bitcoins; the 10 minute validation time perhaps is the most obvious, but credit and liquidity risks with large brokers also cause concern. I do not want to examine these risks closely with this blog, rather, I want to consider the mitigation of risks if companies or governments issued virtual coins, and allow immediate validation and conversion to a fiat currency of choice.

Virtual currency must have a few characteristics that seem to me to be critical to the acceptance of the new medium of exchange including:

• Transparency of Accounting, velocity and acceleration of funds held by the Issuer 
• Reputation of issuer
• Mandated reserves
• Minimal issuer legal, credit, or liquidity risk
• Ubiquity
• Ease of use

If the currency becomes acceptable the issuer necessarily becomes an important large institution and not just a financial institution; define it as an issuing payment hub.  Governments need to accept these issuing payment hubs as beneficial to trade of all kinds, however sensible regulation ensuring the security of user funds, need to be in place before a single issuance takes place.

Governments also need to respect the anonymity of financial transactions except if there is probable cause to investigate a criminal act.  In the current environment, if a US firm or government entity, issued virtual money, and competed against a foreign entity, the foreign entity with clear rules of intercept for cause, trumps the warrantless search or seizure possibilities in the US.

The worst government reaction possible is a ban of the use of virtual money. That reaction invariably leads to loss of trade within the borders of the banning country, and loss of growth of small independent sellers of goods and services accessible to worldwide buyers. An intriguing government reaction would be a small tax on the use of virtual money. Users pay $1.01 for a $1.00 issuance. The penny goes into the government general coffers. The virtual money then circulates as any normal currency and exchangeable with other fiat currencies with published exchange rates. To me taxing issuance is intriguing because with growth, a small issuance tax may be able to replace more regressive taxes such as payroll taxes in the US.

Is a virtual currency the same as a small value gross real time payment system (SVGRTP)? Functionally it is, operationally it is quite a different beast. Virtual money sets up a peer to peer relationship between buyers and sellers without a third party that conducts the exchange and holds the results. Without brokers, liquidity and credit risks remain with the issuer at the time of redemption.

Next Blog: New risks to virtual money, what happens if the lights go out?

Analytics, and a new Virtual Currency

Bitcoins created a new category of payment system, which I called a gross delayed payment system. The worldwide demand for a payment system that is cheap, safe, and fast settled for cheap because nothing else existed.

An earlier post described the single “on-us” small value gross real-time payment system (SVGRTP) and showed how money moved instantaneously on the receipt of instructions from the payer. (See http://paymentnetworks.blogspot.com/2014/06/motivation-to-eliminate-bank-card.html .) Amazon comes close to something similar with Paypal, but uses a deferred netting system (such as ACH) to settle accounts (this is a presumption on my part based on my experience with the service). 

The question haunting this blog is a simple one, why doesn’t one of the big network data companies create real-time accounts containing real credits based on a fiat currency? There seem to be plenty of banks for sale that could form the base of such a system. It’s not like the Googles, Amazons, or other major internet firms don’t have the cash to do it, and it’s not because they don’t have the know-how, and it’s not because they can’t make a lot of money from such a platform?

Once one of these firms does create the SVGRTP, the scary bit also becomes a reality. All the data needed to monitor the flow of money becomes an instant reality as well. The firm that sees in minute detail the flow of a $79 trillion dollar river will have a license to print cash. So the world waits and sees who will build it first, government or the private sector.  My guess is the private sector because government in the US is not capable of seeing the harm in it, and does not take its responsibility of regulating the flow of money seriously.

Once in place in the US, the SVGRTP can connect to other banks purchased in the Group of 20, so the international flow of money without the credit card will become the dominant form of retail payment.

Next Blog: Can Hybrid Payment systems work with small values?

An Analysis of Bit Coins

 I needed to get the math out of the way because the prejudice today is to analyze payment systems using risk as the primary filter.  The math back there described a method for analyzing operational risk. Now we can look at the operational risk of virtual currency and bit coins in particular in a meaningful way. 

Operational risk is a single creature in the risk zoo of payment systems. The other major risks are:

·         Liquidity

·         Credit

·         Legal

·         Systemic

·         Other non-traditional risks I will talk about in future blogs

Diagram 12 shows a bit coin payment hub.

Diagram 12 Bit Coin Payment Hub

There are two operational elements raising concerns. First the broker sets the controls for access to the wallet data store. Human beings show little restraint accessing asset data stores in payment hubs if the controls exist only within the internal process. Second back pressure building up from a 10 minute update ensures that people cannot measure the value within the data store precisely at an instant of time.

Next Blog: More analysis of bit coin risks or response to comments or other payment hub phenomena 

Basic Concepts Part II - Backpressure

Last part of the basic concepts theme. The same poor man's copyright applies to this piece. This introduces the concept of back pressure which is a well known phenomena in payment systems. I attempt to measure back pressure and believe I do so, however with luck, a reader may disagree.

Some Basic Concepts of Payment Systems

I apologize for using this format but I could not find any other good way to enter the symbols I use into the blog editor. I will go back to the normal format when I finish with the basic concepts or get this editor to work the way I want it to work. I have a poor man's copyright on this material I wrote a while back and never used much. Feel free to copy and use it; please attribute it correctly, as with any work copied on the internet. 

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.

Motivation to Eliminate Bank Card Networks

Recapping from the last two blogs, we have in place a standard specification for the transmission of payment data from a personal electronic device (PED), and a secure retailer database. If we could use the infrastructure put in place by central banks then we would be done; however active users of Fedwire and the like do not like penny-ante transactions polluting their pristine flows, so we must build our own.

I think it’s best to start with a small scale model and show scalability for size than it is to propose a world-wide SVGRTP built by the private sector.  Diagram 10 shows the concept of a single SVGRTP contained within a single bank.

Diagram 10: Single SVGRTP

Ideally, maybe in two or three years we won’t have to use this cumbersome message architecture at all. Our PEDs will have entangled quanta with corresponding quanta at our bank, and the device will spin the quanta to corresponding quanta at the bank with message details. No chance of data intercept limits attacker tools. However, in case there are technical issues developing a quanta payment system I will press on with stone knives and bearskins (apologies to Star Trek “City on the Edge of Forever” fans[1]).

Diagram 10 shows a simple “on-us” transaction that corresponds with a retailer and a cardholder having their accounts at the same financial institution. However Diagram 10 shows the transaction with the newly minted SVGRTP.

   

Bank_a in the diagram translates the retailer id to an account that exists at Bank_a and translates the device ID to an account that exists at Bank_a and moves the payment amount on receipt of the message. The diagram leaves out the notification and security details.

I think it might be possible to select a small town with lots of cell phone users and a few shops and one major bank popular with local retailers.  How might we convince such a bank to go along with this madcap scheme?  If the bank is in the US then Regulation E does not cover the transaction because it does not meet the definition of an electronic fund transfer as defined in the regulation, namely:

Electronic fund transfer (EFT) is a transfer of funds initiated through an electronic terminal, telephone, computer (including online banking) or magnetic tape for the purpose of ordering, instructing, or authorizing a financial institution to debit or credit a consumer’s account. EFTs include, but are not limited to, point-of-sale (POS) transfers; automated teller machine (ATM) transfers; direct deposits or withdrawals of funds; transfers initiated by telephone; and transfers resulting from debit card transactions, whether or not initiated through an electronic terminal (12 CFR 1005.3(b)).[2]

The SVGRTP defined earlier does not give instructions to debit or credit a consumer account, the SVGRTP gives instructions to credit or debit a retailer account. I am not a lawyer, and if you accept my interpretation without legal advice then you are quite mad. However, it seems the whole purpose of Regulation E is to prevent a retailer from falsely accessing a consumer account, which is not what happens in the SVGRTP. The PED instructs the consumer bank to credit the retail bank; the retailer does not instruct the bank to debit the consumer account.

So, without Reg E, retailers do not have to worry about charge backs and banks do not have to worry about Reg E claims. By ditching the bank card networks, both retailers and banks drop the most costly aspects of the current system.  

Next Blog: ?, or reply to comments, or the math of payment system architecture

---

[1] Spock: I am endeavoring, ma'am, to construct a mnemonic memory circuit using stone knives and bearskins. From http://www.imdb.com/title/tt0708455/quotes

[2] http://www.federalreserve.gov/boarddocs/supmanual/cch/efta.pdf

The Payment Initiation Boom makes Cards, POS, and EMV Obsolete

Immediate, safe, and cheap access to money is a primary indicator of a healthy retail payment system. Personal Electronic Devices (PED) provide the immediate and cheap access parts; intelligent payment system architecture provides the safe part.

Referring back to the first diagram posted on this blog (Diagram 1: Operational SVGRTP) I wish to focus again on the dynamic junction of PED and the point of presence (POP) as shown in diagram 9.

Diagram 9: POP and PED Dynamic

A standard protocol for communication between payment applications and POPs does not exist. Instead we have a patchwork of protocols based loosely on VISA 1 and VISA II and a bunch of roll-your-own protocols to add diversity to the zoo. ISO 20022 is a protocol for a Payment Vs Demand system used primarily to settle financial market trades. Its key feature is the use of HTML tags. Issuing banks got together in the 1980s to build a standard protocol between acquirers and authorizers called ISO 8583. The primary expense of retail payment systems today is passing transactions back and forth between the VISA I/II protocol and the ISO 8583 protocol. Replacing these archaic structures by one protocol based on HTML tags such as ISO 20022 will cut costs dramatically.

Acquirers and issuers see such a standard as a threat to their business model. The internet allows a PED to connect directly to an issuer, so why do we need acquirers at all? That question prevents a common standard from being developed. Once the standard exists, however, the consumer demand to use it will drive the payment system industry to use it.

So who will pay to build a standard to bypass the middlemen? The natural payers in my view are the wireless communication providers around the world, large and small. The mobile communication providers know how to create standards and one worldwide payment standard will increase the demand for all of their services. Yet these companies are feisty and competitive; joining hands for a payment system Kumbaya is not on the horizon.  

The standard (call it ISO 201501) will have an impetus if and only if the current archaic structures fail from its cost or from lack of trust (trust is the critical ingredient in all payment systems).  There is a lot of noise about successful attacks on the current retail payment system in the United States, however monetary losses as a percentage of aggregate value of yearly transactions are miniscule.  Where we do see some prickly skins is payment system costs, and the proof is the Durbin amendment capping interchange fees, and law suits from retailers against the brand name payment networks.

If the wireless providers see the griping as a sign that they can take over the payment system infrastructure and provide the secure data movement at significant reduction in the current cost and at significantly higher margins than normal wireless communication sessions, then the gig is up as long as a small value gross real time payment system comes into existence.

Next Blog: Cutting out the Middle Man, Part III

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