Awaken now at last
And tell us how to save us from ourselves
and how to survive our own rulers
who would make a plutocracy of our democracy
in the Great Divide
between the rich and the poor
in whom Walt Whitman heard America singing"
Ok, no politics. Here's the first rule of proper engagement with complex decisions: know the truth. It's so simple yet one of the hardest tasks ever in a large organization, especially one that deals with transactions every day. Because the Knowledge Boom hits hardest where you actually need to make sense of it. This isn't just going through your Google reader and finding the 5 interesting posts to read between the dozens you got last night from TechCrunch and Slashdot. It is (first and foremost) about finding those pieces that really matter, and using them to make money, or prevent from losing it; it is about finding what's the most important piece of data you aren't logging or don't have, and getting it; and finally, it is about making it all connect. Because without all of these, you're left with a blur called your payment system, and your best chance is third party vendors and Chargeback representment, and you know my opinion - it's not the best place to be in.
So, you say, what's the problem? I'll hire someone who understands Risk and I'm good.
Not quite. Here's an interesting dynamic: since many merchants either relate risk management to CS or demand a clear ROI for any headcount they're hiring, the risk or fraud management department often ends up as an underdeveloped group with CS responsibilities. Yes, this means that they'll start calling a lot of people. On the other hand, when the organization grows, in comes the industry veterans with their zest for business intelligence, segmentations and graphs. So you end up with a group of "factory" workers on one hand - who feel the "field" but do not know what to do with this knowledge (little to say generalize on it), and on the other hand you have the top squad, segmenting the world but never actually meeting the real fraud cases on a non-aggregate level. When the second group need to find what is happening exactly, they cannot rely on the first group, and they end up reverse-engineering the answer to "what really happened?" by digging deeper into your already-huge data warehouse, always reaching something that is just that-much better than a random variable, but never the actual answer. I know this is industry standard, I know it works well to a certain extent, I also know it loses flexibility and degrades after a while. In addition, I can tell you that this is the reason to not only fraudsters having a ball, but also (and much worse!) for legitimate people not making it through the grid of filters. So my advice to you is: get an oracle.
Who's or what's an oracle? You can think of this position as, at the very least, the missing link between your field agents and the BI experts. The "oracle" knows what's a good transaction and what's a bad one; they can rationalize the case and furthermore, they can generalize. Because proper usage of rationalization and generalization are key for an efficient decision making process: they lay the foundations for understanding why bad things happen, how do you spot them on time (and not in restrospect analysis of business performance or when the processor is already knocking on your door with chargeback fines), and what should you check. They have the ability to dive into the material and resurface with additional insight, and the ability to test your systems while you develop them. This is much more than a field agent becoming the newest member of the BI team - the oracle is not only a person with a specific talent, but also has the right system to enable their way of thinking that has nothing to do with Customer Support - as important as CS might be in your organization.
What's the talent profile, and what's the right system? Allow me to call this my little trade secret. But you have an important tip now - find an oracle. Find two. Have your own source of truth, that isn't just your most experienced field agent, and make sure they are all in sync (which is a challenge in its own). Then, finally, you'll be able to start planning automated systems that actually do the work your way.