Tag Archives: Payments

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.


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.

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

WriteStreams.com 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.