One of my areas of coverage is security, and one of the specific areas I follow is bank card fraud, largely because it happened to me once. A few years back, my wife and I apparently bought an SUV without knowing it. Fortunately, our case involved a credit card and, thanks to Citibank, the remedy was pretty painless. Had it happened with our ATM card, though, things could have been expensive and painful; ATM cards don't have the same protections as credit cards.
That's why, when I found out about the HP/ReD solution for Pulse, which is one of the largest card transaction handlers, I got interested. Using ReD and HP technology, Pulse implements real-time fraud protection.
Prior to this, folks could only approach near-real-time, which means the bank finds out the transaction is fraudulent at about the time the criminals drive away in the car you bought them. While this may prevent them from buying a nice sports car to go along with the SUV, you are still out that first purchase.
Real-time means the criminals don't screw you over at all. To make that happen, the solution didn't just need to be fast, it needed to be cheap. That's the appliance computing part of this story.
For Banks, Fighting Card Fraud Not Worth the Cost
Until recently, most banks accepted credit and ATM card fraud as a cost of doing business, largely because the cost of prevention appeared to them to exceed the benefit. Realize that much of the cost for fraud, particularly in the case of ATM fraud, is born by the customer. In a case of broad fraud, it can cost up to 9 months of near full-time work and around $250,000 to fix you identity and credit scores—and you may never again get the high rating you once had.
Commentary: ATM Fraud Refunds May Not Come Quickly—If At All
For a solution to work, then, it has to be very inexpensive. Since banks don't want false positives—after all, they make money on the transaction and don't want you using another card—they won't accept a system that so aggressively blocks transactions that legitimate ones are accidently blocked as well.
Pulse picked the ReD platform because it came closest to meeting its fraud prevention needs. However, to meet both speed and cost requirements, it needed to reside on a far simpler baseline of technology.
HP's Appliance Allowed for Growth Where Oracle's Didn't
Pulse was running its initial near-real-time system on IBM servers, EMC storage and Cisco networking, all against an Oracle database. This was working, but the overhead of keeping this high number of vendors talking to and working with each other became a problem. Several of these vendors compete, after all and the software cost (more on this in a moment), the inability to grow quickly and the maintenance complexity made the result too slow and far too expensive.
With HP, IBM and Oracle already in house, Pulse felt an appliance from one of these vendors would be a better approach. Oracle's Exadata was knocked out early, and the company wasn't asked to bid—Pulse felt it simply wasnt competitive. Even though the company use IBM System Z for transaction processing, the team implementing this solution didn't know it well enough and believed it wasn't tuned for this particular use. (It is generally wise to pick a platform that the folks who are implementing the solution know, since learning a new system or having to replace key staff prior to a major deployment can be catastrophic.)
Pulse picked the HP Non-Stop Blade System, which has had a great deal of success in banking and government. In the process, the company was able, with one vendor, to replace four. The resulting simplicity and cost savings met or exceeded the design goals, one of which was the capability to be fully redundant and to double in size rapidly since the Pulse solution, at least for a time, would be unmatched in the market.
One thing that came out of the conversation with Pulse was what a problem Oracle had become. Oracle's pricing is very aggressive, apparently far more aggressive than the HP alternative, and Pulse's already high Oracle costs would have been up to four times higher because Oracle charges both for redundancy and for excess capacity. In effect, Oracle was penalizing them for having redundant systems and for building in advance of expected massive growth—both of which are best practices, mind you. HP did not and only charged the company for what it was using.
The end result was that the money saved from switching from Oracle, which was considerable, partially paid for this solution and dramatically increased its potential ROI. More importantly, Pulse was able to better prepare for future problems and growth after stepping away from Oracle. I expect this would have become a long-term problem for the company.
Large Appliances, Deep Planning Can Work
My big takeaway here is that this large appliance approach works by reducing the massive complexity that often results from vendor diversity in a solution. Of course, the other big takeaway is that Oracle is at cross purposes to firms that intend to grow or want to use redundancy to assure uptime. As I understand it, the mixed solution provided Pulse about 97 percent uptime, likely because of the complexity and the cost of redundancy. The HP/ReD appliance solution is at five nines (99.999 percent) and Pulse expects to approach seven nines, which is far closer to the high availability that a financial institution requires.
Keep in mind that this system is still in beta, at only 10 percent capacity and under a 12-month deployment target that, to date, has only slipped one month. At the same time, Pulse has done full load testing; part of the deployment has been to put in place strong metrics and benchmarks, and those are all holding.
In many ways, this is one of the most impressive deployments I have ever seen, largely because it was well-considered, well-planned, well-measured and benchmarked, backed by experienced people, and simple. Pulse also had the vendors on sight throughout the testing and implementation processes, which helped assure the solution's success. Pulse has showcased an impressive number of best practices with this equally impressive deployment.
Rob Enderle is president and principal analyst of the Enderle Group. Previously, he was the Senior Research Fellow for Forrester Research and the Giga Information Group. Prior to that he worked for IBM and held positions in Internal Audit, Competitive Analysis, Marketing, Finance and Security. Currently, Rob writes on emerging technology, security and Linux for a variety of publications and appears on national news TV shows that include CNBC, FOX, Bloomberg and NPR.