Category Archives: Payments

Banking and payments – ACH, Image Exchange, Cards

Market Games

Recent record highs have focused a lot of attention on the stock market.  The broad market rise is largely due to Fed actions (quantitative easing and a near zero discount window), creating lots of excess cash and nowhere else good to put it. It’s a risky solution that props up markets while inflation is delayed.

But what about individual stocks? In this rising tide market that can gloss over things, how do you better discern individual winners? Of course, company metrics (fundamentals, earnings, balance sheets, etc.) and movers (news and innovation) are the mainstays. Technical analysis can be helpful, but that tends to focus on surface effects. Can big data look behind the scenes?

Just as tons of consumer market data now drive product marketing decisions, the wealth of available corporate stats increasingly influence stock buy and sell decisions, sometimes to a fault.  In this data mining era, we’re much better at correlation than causation, but that’s often good enough.

The individual investor is perhaps the only truly random walk (or uncertain walk) left in the stock market. Since prices are most influenced by large holders and program trades, movements can be partly predicted by comprehensive mathematical models on the big players and their trading strategies. With enough data and processing power, it’s possible to run rich behavior models in predictive mixed strategy games to forecast prices and actions. There’s been some interesting research in this area, and I think we’ll see more. At least while the current bubble continues to grow.

EMV Day Now

When it comes to consumer technologies, we in the US often let the rest of the developed world “leap frog” us, frequently with our own innovations.  The main culprits are typically our size and social adoption curves.  When you have an installed base of familiar and comfortable (but old) technologies numbering in the hundreds of millions, transition takes awhile.  So we’re stuck with broad use of anachronistic things like CDMA cell phone networks, Windows XP, checks, and skimmable mag stripe credit cards.  In payments, where adoption is key, it often takes significant financial and regulatory incentives to bring in the new.

As card fraud escalates, US payment networks are stepping up incentives to migrate to chip-embedded credit and debit cards using the Europay-Mastercard-Visa (EMV) standard.  For example, Visa’s new October, 2015 fraud liability shift (from issuer to merchant) for non-EMV transactions provides the looming punitive “stick,” while their recently-announced common debit solution and Technology Innovation Program (TIP) provide some “carrots.”  But that’s all “network push” with little “consumer pull.”  Hopefully, as more EMV cards roll out in the US, consumers will value the extra security, and competitive pressure will motivate issuers to send out those new cards quickly.  EMV doesn’t solve all card fraud problems, but it’s a step worth taking.  The costs of fraud affect us all, and it’s time we caught up with the rest of the world.


Every couple of years or so yet another patent troll impacts my work.  Whether it’s Data Treasury, LML, or other “companies” I can’t mention, these folks patent the obvious early enough (often while an idea is half-baked) and sit on it.  They then wait for others to build and/or buy products remotely similar to the vague patent, and then sue in East Texas courts to shake down licensing fees.

It’s a ridiculously bad situation that could actually get worse as the Supreme Court considers a case that could hold a programmer liable for writing code while being vaguely aware of neighboring patents.  Since so many obvious and trivial ideas in software have already been patented, the only safe harbor for some may be to stop programming.  For many of us, that’s like abandoning breathing.

Hence the constant cries for software patent reform.  Congress is currently taking up the issue, but, as in past attempts, the strong lobbies that are pushing it in the wrong direction may kill it.  And since legislative and judicial wheels turn at a glacier’s pace compared to the rate of technology advance, don’t hold your breath.

A better way to light a candle in this darkness is to simply defensively publish new ideas before a troll can patent them.  This has the extra benefit of sharing those ideas that really shouldn’t be regarded as competitive advantage.  The downside, of course, is that you may often have to publish something you’d really rather keep as a trade secret.  But that’s the price you pay to avoid the risk of trolls.

There’s clearly a place for those (rare) worthy and innovative software patents that offer a unique competitive advantage.  But you won’t find those with patent trolls nor in East Texas courts.

I’ve often said (and firmly believe) that an active, effective software developer produces at least one patentable idea each week.  It’s just what we do, but that’s also a commentary on the relatively low standard for US software patents. One primary reason we don’t have billions of software patents at the USPTO is that filing for patent protection is an expensive and inefficient process.  So a company’s patent portfolio is usually more a measure of its rapacity or the size of its legal staff than the degree of innovation.

I’m hopeful that the current woeful US software patent situation will one day be corrected, and the end result will be better protection, innovation, and collaboration: even beyond what’s currently found in FOSS work and licensing.  Until then, I’m afraid we’ll have to endure some stagnation while the trolls have their way.


Hats off to local SecureWorks for detecting and thwarting the massive BigBoss Russian check counterfeiting ring.  Their Counter Threat Unit (yes, 24 fans, there really is a CTU) uncovered an operation used to create over $9 million in counterfeit checks over the past year.

It was a sophisticated attack utilizing ZeuS trojans, SQL injection, a couple thousand infected computers, and a VPN to transmit stolen data.  The perps stole over 200,000 check images from archive services and used these to create counterfeit checks.  They then overnighted these checks to U.S. recipients (drawn from a stolen database of job seekers) who were to deposit the checks and wire some of the funds back to them.  These unwitting money mules (who thought they were job candidates) did become suspicious, so the plan was apparently not very successful.

Compared with credit card fraud, widespread check fraud is less common and is typically easier to resolve.  However, check authorization systems are incomplete, so prevention is more difficult.  But solutions are well within reach, such as a secure national shared database of positive pay, authorization, negative list, and “stop” information that could be accessible to everyone, not just large commercial customers.  This could plug one of the last big security holes in our bank accounts.

Guilt By Association

Anyone who has done a little data mining knows that simple association rules (a.k.a., market basket analysis) and decision trees can reveal some of the most strange and wondrous things.  Often the results are intuitive, which builds confidence in the techniques.  But then let it run loose and you’ll usually find some (strongly correlated) wild surprises.

Folks who fold their underwear tend to make their bed daily.  I’ll buy that.  But people who like The Count on Sesame Street tend to support legalizing marijuana – are you kidding?

Those are some of the conclusions reached at  This site will happily make recommendations for you on all your life decisions, big or small.  There’s no real wisdom here – it just collects data and mines it to build decision trees.  So, as with most data mining, the results are based on pragmatics and association, and they never answer the question, “why?”  Yet “just because” is usually good enough for things like marketing, politics, and all your important life decisions.

In school they made me work through many of these data mining algorithms by hand: classifiers, associations, clusters, and nets using Apriori, OneR, Bayes, PRISM, k-means, and the like.  When it got too rote, we could use tools like Weka and DMX SQL extensions.  It was, of course, somewhat time-consuming and pedantic, but it made me realize that most of these “complex data mining techniques” that seem to mystify folks are actually quite simple.  The real value is in the data itself, and having it stored in such a way that it can be easily sliced and diced into countless permutations.  (NoSQL fans: that typically means a relational database.  Oh the horror.)

Yet simple associations can be valuable and entertaining.  I’ve run enough DMX and SQLs against large database tables (housing contact management, payment, and contribution data) to find some surprising ways to “predict” things like risk and likely contributors.  But since “past performance is no guarantee of future results”, these outputs must be used carefully.  It’s one thing to use them to lay out products in a store, quite another to deny credit or insurance coverage.

American Express, Visa, and others have caught a some flack lately for their overuse of these results.  “OK, so I bought something from and you’ve found that other cardholders who shop there have trouble paying their bills.  But that doesn’t mean I won’t pay my bill!  Don’t associate me with those guys!”  Well, associate is what data mining does best.  And, like actuarial science, it’s surprisingly accurate: numbers don’t lie.  But companies must acknowledge and accommodate exceptions to the rules.

Meanwhile, data mining will continue to turn wheels of business, so get used to it.  Just don’t let anyone know that you like The Count.

Maybe It’s Just a Fool’s Errand

I’ve been whining for some time about how we need “a unified blend of stateless operation, classic resource control, and higher-level concurrency semantics.”  That is, we need some way of making all those parallel programming building blocks easily fit in programmers’ heads: functional programming, lambdas, closures, futures, async callouts, delegates, TBB, and, if we must, semaphores and threads.  That would go a long way toward more widespread utilization of all those cores we’re now getting.

Larry O’Brien has answered the call, at least for futures. And it follows the metaphor of our highly-leveraged financial system, so even I can understand it (understand: yes, trust: no).  Bummer that scarcity really does exist in economics and CPU cycles, and this is just an April Fools’ spoof.

Oh well, at least we can continue to hope, while laughing (or whining) about it.

Haven’t I-RD Seen This?

In today’s sports action, we learned that Bank A has been returning Bank B’s re-presented IRDs (image replacement documents) as duplicates.  Bank B asked us to referee a bit, since both are customers.

It’s quite common for a collecting bank to re-present a returned item to the paying bank to “try again.”  This second presentment looks just like the first one, but with additional prior return data like return reasons and endorsements. If you ignore the additional data, it does in fact look like a duplicate transaction.  True duplicate transactions are a bad thing, but can happen with all the conversion that goes on between paper, image, IRD, and ACH.  Duplicates must be stopped, but separating potential duplicates from real ones can be tricky business.

Exactly where this prior return data shows up depends on when the item was truncated (converted from paper to electronic or image).  In this case, a paper check was converted to an electronic image (X9) for collection and return, and then converted to an IRD for re-presentment.  Because of the early conversion, there were no return reason stamps on the face of the image.  And, since it was a forward presentment IRD, there was no Region 7F to house the return reason on the front.  From looking at the IRD, the only clue that it was once returned is on the back: the return reason appearing in the (small and sideways) subsequent endorsements, after “RR”.  That’s how the standards go.

Bank A had kicked in some new aggressive duplicate detection rules that flagged re-presents as suspects.  It’s tough enough that operators had to review the images to check for returns, but they were only looking at the front image, and missing the fact that all these transactions were legitimate.

One option is to put the return reason on the face, but that would be bending the standards.  That’s because, in theory, things like this should never happen.  And so it goes when standards are involved: in theory, there is no difference between theory and practice, but, in practice there often is.

Minum Data Redaction is pleased to announce its new Minum Data Redaction (MDR) product.  MDR provides physical data security for sensitive bank and credit card information, complementing the electronic data security covered by IBM’s just-announced Optim Data Redaction product.  Used together, these products can help you achieve PCI DSS compliance with little or no coding.

IBM’s new Optim Data Redaction automatically removes account data from documents and forms.  You can get that wondrous XXXXXXXXXXX1234 credit card number formatting with little or no effort on your part (apart from buying software, of course).

Our new Minum Data Redaction product extends account number protection to the physical world, protecting the bank cards you carry.  Its super-strong rear adhesive and front opaque covering ensures that your sensitive credit card information stays protected.  It comes in a variety of colors (including duct silver and black), and our Premium version provides extra thickness to cover embossing.

But seriously now, we go to great lengths to protect electronic card information by encrypting it in stored files (56-bit DES isn’t good enough); redacting it on printed receipts, reports, and statements; and setting disclosure requirements that publicly embarrass companies who slip up.  But yet our simple payment process requires that we hand all this information over to any clerk or waiter who usually goes off with it for awhile: certainly long enough to copy it all down.  PCI DSS offers the classic false sense of security.

I was recently a victim of fraud against my Visa card.  A series of small (mostly $5) fraudulent charges hit my account over several days until I closed the account.  From what I learned, the charges where only authorized by account number and expiration date; there was no zip code verification.  I don’t know how the perps got my credit card number, but I doubt they grabbed data from a financial institution in the dark of night, nor devoted the $250,000 and 56 hours required to run an EFF DES crack against it.  It probably came from a clerk or waiter who handled my card.  My cards, like everyone else’s, have account number, expiration date, and CCV printed right on them.  Zip code isn’t there, but anyone who wants it can just ask to see my driver’s license for verification.  It’s a gaping hole.

Until credit cards gain better physical security, there is no “silver bullet.”  But banks and card companies could enlist help from their own customers.  For example, let me specify which types of charges I would allow/authorize.  It would spare consumers the hassles of disputing charges, and would save issuers the dispute processing fees and write-offs.

The Mute Button

Today, Craig Mullins and others took Larry Ellison to task about his sweeping, unfounded claims about Oracle vs. DB2.  Ellison’s comments often invite easy parody (remember the “Fake Larry Ellison”s?).  Apart from that, such remarks aren’t valuable and can safely be ignored.

Both Oracle and DB2 are solid databases and the ongoing TPC-C competition is good for both products.  But stick to facts and evidence; this is not a topic for uninformed, biased opinions from 50,000 feet.  See Craig’s post for some facts.  And Craig refers to our friend, the Viewpointe national check image archive.

Larry did comment on something that he knows and does have direct control over.  Recent history and guidance aside, Ellison said that, rather than laying off any Sun employees, he will be hiring 2,000 more in the next few months.  Great news!  We’ll be watching.

You Say Acquirer, I Say ODFI

I’ve been learning the details of Visa disputes processes and Visa Resolve Online (VROL); interesting stuff.  What strikes me each time I learn a new payment exceptions and returns workflow is just how similar they all are.  In many ways this is expected.  For example, NACHA and ECCHO built our ACH network from the old Electronic Check Presentment (ECP) systems, so it shouldn’t surprise us that it’s very “check-like,” complete with cash letters, batches, MICR data, overnight clearing, and very similar data interchange formats: ECP, ACH, X9.37, and X9.100-187.

But the Visa network didn’t have this legacy, so I’m surprised to find just how very conceptually similar it is to the check/image and ACH world.  Sometimes it looks like only the names were changed to protect the guilty.

So here’s my brief thesarus to translate Visa-speak to ACH-speak and check-speak:

Issuer = RDFI = Paying Bank

Acquirer = ODFI = Collecting Bank = (usually) BOFD

With these translations in hand, you can simply relabel the boxes in those issuer disputes and acquirer disputes diagrams and workflows, and you have classic check and ACH exceptions processes.  Voila!   Just relabel some screens and web pages and you can use a check or ACH system for Visa, right?

If only it were that simple.  There are clear technology and interface differences that keep the twain apart, yet consolidating these payment types is still very doable.  Perhaps the bigger issues are the organizational ones.  There have always been walls between the check/image, ACH, wire, and card departments, and those staffing/people issues are often the toughest to overcome.  But as payment trends continue to shift, clearly we’ll see more of that.

BTW, my little simplification assumes debit pull transactions.  That’s all check and card have, but ACH has credit push transactions, and these can be disputed and returned.  Do credit push exceptions/returns mean you change the workflow, or simply post and settle differently?  I’ve only done debit pulls, so I don’t know yet.