Showing posts with label data breach. Show all posts
Showing posts with label data breach. Show all posts

Friday, June 12, 2009

Too much data, too little information

So, you have this big 1000 user system, with its flows and checkpoints and flags and pointers. If you've grown it well you have a dashboard showing you login numbers, counts of transactions, dollars moving around. You control it all from your NOC, pressing the little red buttons whenever necessary, moving dials and reading graphs. But the thing is, that seeing the bits and pieces of online life on your screen doesn't necessarily, and sometimes doesn't at all, help understand what's going on.

What IS going on in your system? What are users doing, and will that translate into the bottom
line? What can the numbers tell you?

Well, we've been through a few ideas. Experts knowledge ties symptomatic indicators with identities and with what they intend to do, so that you can at least start making sense. Collecting the data is one aspect, and using it to understand is a whole new area. When we reach tips and tricks on how to develop your own methodology, some of this might start ringing a bell. But this post is about one system that shouldn’t be adopted as your main tool if you’re the risk management expert – it’s about advising you to not count on hindsight based on business results.

No, no, don’t get me wrong – business results are important, one of the most important aspects of the business (and some will argue – the single most important – but that is another discussion). But using the bottom line (or even a highly detailed version of it, including a drill down of, for example, every auth rejection code) to indicate what the risks are in the system or worse yet – to indicate what needs to be fixed – is a call for bad judgment. Consider my favorite example, a hospital. If you needed to weigh two hospitals one against another, would you use the percentage of deceased patients as an indicator? Would it matter that one has an oncology department and the other doesn’t? Would it matter that one is in Mozambique and the other is in Mexico? Of course it would, since when all else is equal (in staff, training and tools – like your company compared to other retailers), fraud-on-entry (the hospitals’ location and the indigenous diseases you’d expect) and fraud MOs (the types of diseases that are actually seen and treated or not treated) have a big impact on the bottom line. Trying to use the numbers post risk controls, chargeback, CHB dispute and collections to understand what could have happened is trying to pin down a moving target – and the wrong one at that. Worse of all would be trying to design future systems based on the current snapshot, since you do not have any indication of what users do – just how much money it costs you, and user behavior is much more volatile than your incoming chargeback count.

When you come to understand what’s going on, business results are highly important. But letting them steer all of your team from looking at user behaviors will put you exactly where you don’t want to be – patching up holes in your system using a highly delayed hindsight mode. To be successful, combining data analysis and behavioral research is a must.

Tuesday, April 14, 2009

That one small detail

"When the Chinese government instituted the policy in 1979, it touched off a wave of sex-selective abortions as pregnant couples decided that if they could have only one child they would benefit most from having a boy. That helped leave modern China with the largest gender imbalance in the world. Today, there are 37 million more men than women in China, and many of the boys are growing up unable to find a job or start a family.

So what are these “surplus” boys doing to fill their time?"

This isn't just a story about risk management - it's a story of pure business intelligence - it is a story of freakonomics. The German police has spent years chasing down someone that turned out to be a phantom, a woman who wasn't really a feared killer in many different, distant crime scenes - but merely a lab worker whose DNA "slipped" onto the cotton swabs German CSI people used to collect evidence (on another note, wouldn't it be just morbidly funny if that person turned out to be a real-life German "Dexter" copycat?).

So what does an unsanitized cotton swab have to do with abortions in China, and with risk management?

When one approaches modeling of complex situations (either to explain what just happened, or to improve decision making in the future), often the "sense" made in the process gets deterred by the fact that not all the data is revealed. This is why when Freakonomics' author Steven D Levitt says something along the lines of "if we had enough data, we could unravel the mysteries of the universe", many of us nod (however, I must say, we are not always right); we are in constant search for the added detail that, when added to the equation, will help the story make sense. It's not only as extreme as claiming that a rise in abortions is correlated with a drop in crime rates - retailers are always looking for the additional factor that will verify a bank account, provide details for a phone number or do this automated super sophisticated AVS check. But fact is that most of the added data doesn't do the trick, since looking for that additional detail requires a system.

Yes, having a single source of truth helps give foundation, but even the brightest have a hard time without a system - and the right one at that - for collecting, validating and understanding data. I've seen this in organizations here and there and the German CSI story demostrates it well. The CSI department has a system for examining a crime scene and extracting evidence, and they came up with a concrete linking theory between cases. It didn't shed light on the actual identity of the misterious killer, however it gave an interesting spin to a bunch of unsolved crimes, until it didn't make sense anymore.

What the CSI department lacked was a key component of creating robust linking stories - indetifying common resources. That common BIN number in your last week's transactions might be a result of a data breach in the processor level, but might also be a result of a marketing campaign for a new eCard; and that repeated IP creating new accounts may be a script attacking your system but may also be a whole trend-struck fraternity house shopping through the same computer for that special item only you are offering for a great price. Noticing the trend, understanding it and making the right call on how to handle it are key decisions we are facing every day, and not only in eCommerce. Common resources are one simple example where correct classification, using an external resource, makes the difference between turning away good business and letting the fraudsters in; between chasing a phantom killer and tracking down a less-than-perfect lab worker. Using the right contructs for doing this is key in our ever-changing profession.