Saturday, May 31, 2014

The Regressive movement to Europay, MasterCard, Visa, (EMV) Payments

Earlier in this blog (See Security and Payment Hubs), I wrote what I believe to be a fundamental truth about expenditures to prevent fraud, namely, if firms spend more to prevent fraud than they suffer in losses, they commit an economic folly. Certainly the projected expenses for converting the US to EMV exceed the cost of fraud significantly.

This blog shows that conversion to EMV far exceeds the amount of card present fraud existent in the US (EMV does nothing to stop card not present (CNP) fraud).  The blog also shows that prevention of fraud has nothing to do with the expected conversion, and (not surprisingly) everything to do with an expected huge windfall profit for the card processing firms.

The Federal Reserve estimated the value of fraud in the US at the end of 2012 was 6.1 billion dollars[1]. 65% of that was fraud committed with general purpose cards. That leaves $4 billion in general purpose card fraud of which half was CNP fraud. So there was $2 billion dollars of fraudulent transactions in the US in 2012 when the card was present. First Data Corporation estimates costs of $8 billion to implement the EMV solution in the US[2].  Thus, EMV implementation costs 4 times the amount of actual card present fraud in the US.

Why would card processing companies spend that much more to prevent fraud then what actually exists? The reasons for the folly follow:

·         EMV does not pay that much for the conversion; retailers will pay the lion’s share, and banks (issuing the more expensive cards) will pay most of the rest.

·         Those retailers that do not comply will receive huge fines and penalties.

The card processing companies will need those fees to make up for the losses they suffered when congress restricted the amount of interchange fees. Issuers received $48 billion dollars in interchange fees in 2009 and received approximately half that amount once the Durbin amendment went in to effect[3].

To make up for the loss of $24 billion dollars, merchants will become liable for fraudulent transactions made with an EMV card in a non-compliant merchant shop; the fines for non-compliance will make up the rest along with excessive charges for very small value transactions.

The conversion makes money for a slew of other parties including point of sale equipment manufacturers, card manufacturers, software developers, and a host of others.

I submit honest reader(s) that retail transaction processing is nothing more than a natural monopoly.  The Durbin amendment made the issuing banks a de facto monopoly requiring all to charge the same fees instead of requiring each issuing bank to charge their own fee without collusion with payment networks or other issuers.

So EMV leaves us in the worst possible world. We pay too much for transactions; we do not use the payment system provided by the Federal government; and the system we do use is wide open for attacks.  EMV is a boondoggle, but big lobby money assures our congress will look the other way.

[1] 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 see

[2] First Data Corporation (Morea, Dom); EMV in the U.S.: Putting It into Perspective for Merchants and Financial Institutions; (2011); p. 12. See

[3] Zhu Wang; Economic Quarterly Volume 98, Number 3ó Third Quarter 2012 Pages 159 - 183
Debit Card Interchange Fee Regulation: Some Assessments and Considerations; see

Monday, May 26, 2014

Musings on a Future Payment System Job

I want to depart from my light hearted analysis of payment system structures and enter a world of pure whimsy. I am in a darkened room somewhere deep in the bowels of the NY Fed and performing a job I created myself; I am the tax tickler adjusting tax rates on subject transactions running through the combined value gross real time payment system. The system moves about 2.8  trillion dollars a day (whimsy alert 2.8 trillion represents money flowing through US gross real time payment systems (Fedwire, NYCH) and all non-cash payments (see 2013 Federal Reserve Payment Study  and data at )

At first most firms claimed the funds moving were tax exempt, but when it became overly burdensome to show how the funds met the definition of tax exempt and no reporting requirements at all if the funds were taxed, the target .07% tax became a bargain.  The added bonus of no income taxes, no payroll taxes, and no user fees for most industry made the concession that much more valuable.

I sit in front of a screens that present the current aggregate position of tax revenue and payment flow. I am reading a novel, sipping a glass of chardonnay, and completely ignoring the screen.  The video phone comes on and the director of the national weather service pops into the monitor. She tells me the hurricane off the gulf coast is a category 4 and expected to make land fall in 3 hours; her economist estimated a FEMA requirement of 2.5 billion dollars. I nod, close the phone window, pull up a menu, click FEMA, enter 2.5 when queried, and click the “apply” key. The monitor shows the tax per transaction increase .005 %, and the flow stayed pretty much the same.  I go back to reading my novel. Ahh, I think to myself, every day is holiday.

My imaginary screen:

Next Blog: The Regressive Move to the Europay, MasterCard, Visa, (EMV) Payment System

Saturday, May 24, 2014

Security and Payment Hubs

Security is a broad generic term and I need to define my usage of it here in this blog. Security means (for the purposes of this blog) detection and prevention of the intercept of banking data. I define the term only for electronic movement of money.  Banking data means accounts and associated routing numbers to those accounts or substitutions (mappings) for accounts and associated data. 

Data typically associated with security such as personal identification numbers, personal information, and other data used for identity protection are not the subject of this blog because these types of data need validation and verification outside the flow of payment information.

If my faithful reader(s) recall(s) the interface between a payment application (software resident on any device with a processor able to execute the software) and a point of presence (POP) for a SVGRTP then diagram 5 shows just the pertinent part of early diagrams except the destination POP fronts a payment hub not a SVGRTP.

Diagram 5: Payment App and POP interface

Diagram 5 shows no transmission of banking data to the payment hub. However, if the same data shows up at the POP ordering a push of the amount from the account associated with the device number to an account associated with the payee number,  then an attacker does not need the banking data, interception of  substitute data suffices to commit a theft.

The purpose of removing account data from the initiating command is not to prevent identity theft; it is to prevent the intercept of bank account data, exactly as I defined security at the beginning of this article.  By placing the verification of identity at the payment application level and not at the payment hub level we remove a one size fits all approach to electronic payments and allow consumers to pay for the security they need when accessing various sized payment hubs.  Diversity of security approaches also hampers professional ne’er-do-wells. Yet transmission of information from a device to a POP requires a minimum level of security to protect the data, and prevent unauthorized access to the POP. At a minimum then (in my view, and I am not claiming to be a security analyst, so I hope I have dissent), the POP validates the device, the device validates the POP, the device sends one encrypted message, and tears down the circuit. Notification of results goes to the POP that then delivers result notifications to addresses registered with the bank account data.

I have met some amazing professional security analysts over the years and they know all the tricks down to the nodes on a chip card. And yet cold analytic reasoning on risks and vulnerabilities accompanied with statistics, false positives, false negatives, and attack history, lacks a key ingredient. There are two questions needed to approach security, one quite rightly is how to prevent an intercept by detecting it, but the other approach, how I can intercept the data to commit a theft, remains the road very much less traveled.
So, I thought it might entertain my dear reader(s) to look at the universe of payment hubs and see it as a group of potential targets, not as potential vulnerability. Figure 6 shows payment hubs as I imagine a thief might see them.

Figure 6: Payment Hubs as Targets

A budget is primary element for a thief and certainly there is likely a relationship between the size of the thief’s budget and the size of the transaction flow between payment hubs.  If that is true, and I sincerely hope it is true, then just like the rest of society there are only a few whale thieves in the cyber ocean.

I am going to state an equation that shows my understanding of the relationship between a thief’s budget and transaction flow. Before writing such an equation that rips humanity from individuals, let me state that if these types of equations work at all, they only work on aggregate human behavior such as military units, or sociological categories, and are still suspect.

Leaving the thorny problem of determinism alone let there be a fixed sum BT (Thief’s budget) that is a dollar value equal to the highest minimum amount for a successful attack, the flow itself (TF ), and C equal to the cost of an efficient detection system. (Examples of efficient detection systems abound see for example:  Philip K. Chan, Florida Institute of Technology, Wei Fan, Andreas L. Prodromidis, and Salvatore J. Stolfo, Columbia University; “Distributed Data Mining in Credit Card Fraud Detection”; (November, 1999); or for an opposing view:  Clifton Phua, Vincent Lee , Kate Smith, Ross Gayler ; “A Comprehensive Survey of Data Mining-based Fraud Detection Research” (November, 2007)


BT  ≥ C/TF at an instant of time, t, for a successful attack.  

Thus if TF = $1.00/sec the thief’s budget must exceed the cost, say $1.00 at time t, and the thief’s budget must be greater than or equal to $1 multiplied by the entire time of the attack (including planning stages).

It is a hypothesis with absolutely no data to confirm it, and there likely never will be such evidence unless we can get a hold of a statistically valid sample of thieves’ budgets and pry bank fraud data from banks ( to the wag muttering under your breath, they are indeed separate things). I press on, undaunted by lack of facts.
Let C = P*(ʃ TF) where P ≤ .1 (and preferably a lot less)

If C is greater than the fraud suffered by a payment hub, then clearly it is a waste of money, so if F is the dollar value of successful attacks over a set period of time C ideally has bounds namely:

BT  ≤ C ≤ F at any instant of time, t.

Note that F increases with each successful attack.

Armed with a budget and looking at the seams between payment hubs, non-whale thieves will target transaction flows that have lower value TF but with a high throughput (high number of transactions regardless of value). If thieves need to make two separate attacks, one to intercept bank data or substitute bank data, and another attack to intercept user validation data, then the thief’s budget must increase but the cost for defense of bank data remains the same.

By insisting on having two way traffic (requests and responses) using third parties without a reason to gain access to bank account data, the payment system providers recklessly create unnecessary risks for the entire payment infrastructure.  We have quite recently seen a myriad of successful attacks against moderate sized payment hubs, and instead of recognizing why these attacks succeeded, the payment system providers insist on keeping the request/response with banking data methodology in place and will continue to do so until successful attacks overwhelm the costs of security, and F (aggregate amounts of successful attacks) undermines the trust of electronic payments and consumers substitute less expensive means to conduct trade.

Next Blog: Analysis of the Target attack and payment industry response, or an alternate payment system model using current data

Thursday, May 22, 2014

A Generic Payment Hub 

What is it?

A payment hub is a single junction where streams of money intersect. Usually such a junction contains a collection of other functions that route, track, administer, and tax money flow.  My accounting software is a payment hub. So are quasi-government agencies or commercial bank wire rooms. I don’t use half the functions of my accounting software, and it does not have half the functions needed by payment infrastructure institutions. However, size does not define a payment hub, functionality does. If you have a single junction where streams of money intersect you have a generic payment hub. Diagram 4 shows the concept.

Diagram 4: A Generic Payment Hub

A fancy drawing of a bum’s pocket becomes more interesting with electronic flows instead of manual ones.

I wanted to describe an electronic payment hub because it is the fundamental building block of macroeconomic payment architecture. We will need it later to critique the payment architecture we have in place, grown haphazardly as any human sprawl, and to design solutions for interactions within a common market place controlled by diverse governments.

Next Blog: Security and payment structures, or payment hub interface design concepts (the control process)

Wednesday, May 21, 2014

Use of Feedback Loops in a SVGRTP

Chapter 3: Use of Feedback Loops in a SVGRTP

A feedback loop is a device created to monitor flow to and from an account. Earlier we defined taxes as cost of government functions and defined it as percentage of GDP. We now for the purposes of building a measuring device need to define taxes as a flow.  For the purposes of this discussion Tax flow (TF) is defined as d$/dt or the change in dollars divided by the change in time. 
Building the feedback loop requires the measurement of TF and depending where the measurement takes places, requires calibration (making time a reasonable increment for the flow going past the point of measure (POM)).
 Policy analysts, budget forecasters, and others certainly need to look at the change of the rate of tax flow but that is not a requirement for the simple feedback loop described here. The device measures current events, and does not determine causality or potential government actions.  Diagram 3 shows the feedback loop.

Diagram 3: Feedback loop

Governments create budgets and flow is TF = Projected Receipts– Budgeted Dollars for one year = Projected deficit or surplus. After a year has passed TF = Actual Revenues – Actual expenditures for the year (or fiscal quarter in some cases).

Citizens determine the priorities of continuous tax expenditures for one year with passionate debates over the funding requirements of critical government functions. Administrations then execute a budget, set the funding in stone; and hope projections of revenue are not too far off the mark.
If the same budgeting method exists and taxes flow to government from the SVGRTP then a government can use a feedback loop to change tax flow based on current fiscal phenomena. For instance if a government budgeted X dollars for say snow removal for X number of snow events and at the end of the winter season there were Y number of snow events for Y dollars, then the administers can react immediately to adjust tax rates or move money to other budgeted projects.
Feedback loops monitor tax flow and provide fiscal policy administrators an ability to adjust flow if and only if a SVGRTP becomes the primary method to collect taxes. It allows for intelligent control of scarce resources other than haphazard (at best) approaches we see today.

The feedback loop is a primitive mechanism and adjusting TF requires a skilled hand with knowledge of elasticity of sales tax. Put simply, lower taxes too much, receive too little tax revenue; increase taxes too much, receive too little tax revenue.

Next Post: Generic Payment hubs

Monday, May 19, 2014

 A Vision of Government Functions 

This blog is dedicated to discussions on payment systems architecture worldwide. All payment system types are up for discussion, gross real time payments, deferred netting systems, payment vs. demand, small value, large value, internet currencies, hybrids, or galactic payment modules; soup to nuts.  

Payment system infrastructure and design by necessity brings out conspiracy theories and hate speech which have nothing to do with the mechanics of payment systems.  That being the case I though I would lay out where I see payment systems and government coexist. I start with my definition of government (which may be a wee to the left for some, but it gives context to my understanding of payment system architecture. What follows I hope will be an entertaining discussion.

Government must provide the following services to its people:

·         Creation and periodic removal of laws
·         Law enforcement
·         Universal healthcare
·         Housing for the homeless
·         Daycare for working childcare providers
·         Food for the hungry
·         Clothing for the ragged
·         Transportation if the situation warrants
·         Universal education
·         Defense
·         Treasury services
·         Foreign diplomatic services
·         Unbiased scientific evaluation of significant phenomena
·         Protection from pluralistic bias (equal protection under the law)
·         Independent self examination for corruption
·         Archival Services
·         Unbiased and independent judicial processes
·         Regulation of finance
·         A Central Bank (The Fed)
·         Regulation of environment
·         Regulation of industry making life and death decisions for its employees or the public
·         Full retirement funding
·         Infrastructure development
·         Disaster recovery services
·         Funding itself

All people within the borders of the Government will have the following universal right:

There will be no criminal penalties for willing adults participating in free commerce if the goods or services exchanged are not the product of theft or assault. Government however can regulate trading in  commerce affecting children, endangered species, or products resulting from harmful environmental techniques, the only exceptions to free commerce. Combined Government taxation of such commerce should never exceed 15% of the cost of the goods or services people and firms exchange.

Chapter 1 Taxes

A government must fund itself to provide the necessary functions of government.  As time progresses political administrations of changing times will adjust the priorities of funding and during emergencies may suspend funding of some functions all together. Except for emergencies, budgets include funding for all functions.

Types of Taxes

Worldwide government tax types include:

·         Sale of goods and services (VAT included)
·         Income
·         Inheritance
·         Employment
·         Fees for businesses
·         Fines from legal judgments
·         Property
·         Voting
·         Intellectual designs and creations
·         Use of property
·         Imports and exports
·         Seizure
·         Regulatory fees (licenses, excise, etc)

Without judging the merits of a particular tax, it is easy to see there are too many methods for taxation, creating redundant government administrators for the same function.

Judging the list provides targets for elimination. Regulatory fees, fines, and sale taxes survive.
Taxes need to cover the cost of all government functions, and depending on its administration, may create a rainy day jar.

Let C = Cost for functions; T=Taxes; P = GDP; then

T = (C/P) * P

For example given a $16 Trillion GDP and a government cost of $4 trillion then taxes need to be set at 25% of sales. because  4/16 * 16 = 4.

There exists a relationship between GDP and T such that as T decreases, sales increase (if T is a percentage of sales) and sales decrease as taxes increase.

So, taxes on sales are elastic, as shown in Figure 1.

Figure 1: Elasticity of Taxes

When a government outlaws an activity, or substance, it in this model drives the tax rate to 100% and so no tax revenue results. The actors providing outlawed goods and services in actuality treat their activity as not taxed so their incentive to sell and buy increases. The orange actual taxes line shows an estimated elasticity of lower or increased taxes.

When civilian actors trade across governmental boarders, a potential for unfair tax practices exists. When governments use import and export taxes instead of negotiating the sales tax receipt of international transactions, then governments introduce harmful inefficiencies into what should be a worldwide sales tax system. If large regional bodies such as the European Union, Russia, China, US, etc., can negotiate a 50/50 split of the worldwide tax rate then civilian actors do not discriminate about their operational regions. If a sales transaction occurs within one region that results in goods or services arriving in another region (or regions) then the civilian actors’ governments equally split the sales tax. Increased administration cost for such a system is minimal if taxes from transactions use an internationally recognized standard for clearing and settling. 

Civilian actors can negotiate who pays the tax on a given transaction and the payers move those funds into an independent stream for settlement.  For example, I buy a $60,000 Porsche Boxster; then either the dealer, me, or both of us pay the combined local, super local, or federal tax which say is a combined rate of 25%. In this instance $15,000 separates from the original transaction and goes to a separate clearing house with a result of $7500 going to either Germany or the European Union; and $7500 going the taxing parties in the US, split correctly according to agreements from the different regional entities.

At the Federal level, sales tax rates can be set on a daily basis by the central bank. Regional governments can do the same thing and those rates transmitted at any periodicity to the tax-clearing exchange.

In the case of my Porsche, my county, Fairfax, would receive 5% of the transaction ($3,000), VA would receive 4% of the transaction ($2400) and the US would receive the remainder ($2,100). If I purchased a Corvette instead of a Porsche then combined tax rate would apply but the US might change the chain of receipts and receive $7,500 instead of $2100 (and then divide that among the other authorities with a right to a tax payment).

If governments cannot criminalize commercial behaviors then the need for anonymous cash transactions disappears and the use of cash (potentially tax-free transactions) becomes minimal and may not be necessary at all in the future.

Dreams aside, whatever the regulatory conditions, a basic architectural model for a publicly provided payment network exists, however not tuned for small value payments. If central banks within the Group of 20 provided a small value gross real time payment system (SVGRTP) then banking domination of a critical public infrastructure, which creates huge costs to the detriment of all but the payment system industry,  functions correctly, and does not tax the small small firms and individuals unfairly because of monopolistic practices.

Chapter 2: A Small Value Gross Real Time Payment System

What is it?

Functionally a small value gross real time payment system (SVRTP) works the same as any gross real-time payment systems such as Fedwire, however the design optimizes cost effectiveness for small values. Commercial banks use the central bank (CB) to move small values to accounts registered with the central bank.  A user from the public creates the registration directly with the CB and the CB maps the registered account to commercial bank accounts with deposits at the CB.  Diagram 1 shows the operational processes once registrations become ubiquitous.

Diagram 1: Operational SVGRTP

Although the central bank moves funds, the private payment system industry will thrive. The CB authorizes or licenses auditors for payment applications. The costs for payment applications will be borne by the payers.  Actual use of the SVGRTP needs to stay free; operations funded from other sources. Funding comes from fees for payment industry certifying new devices or new software for devices. Further funding, if needed, will be CB fees to their account holders, transferable to their customers using the SVGRTP.

International Requirements

The System must have interoperability within the Group of Twenty. Enhancing small trade commerce is the goal of the SVGRTP. Users making small payments seamlessly across international borders will measurably increase the viability of micro, small, medium, and large firms worldwide.


There are many vested interests aligned against a public provided payment network, The current network providers, card manufacturers, point of sale providers, key management firms, issuing banks, acquirers, forwarders, gateway providers, deferred netting providers, and other function providers necessarily would disappear or adapt to a publicly provided worldwide payment system.

Governments too will have concerns about such a structure, particularly with payment access to contraband and potential for tax evasion.


Payment transactions cost become much lower. Security becomes exponentially greater. Trade increases.

Benefits for Governments

Tax modules instantly move funds from transaction to multiple tax accounts defined by legitimate regional, federal, and local governments. Diagram 2 shows the tax modules with the operational SVGRTP.

Diagram 2: Operational SVGRTP with Tax Modules

Some local governments would be too small to have accounts with a CB, however they will always have a relationship with a government that will have an account.

Immediate access to tax funds will be a strong selling point for the SVGRTP. Further with the right treaties in place to cooperatively assign jurisdictions for prosecution of criminal cases arising from the use of the SVGRTP, most objections will be from those lobbied to protect the profits of the status quo firms. 

Next Blog: Either a feed back loop for the SVGRTP connected to a government treasury, or, a generic payment hub for less.