Data Matters

I spent last week in a series of meetings with fraud professionals from various large and mid-market banks. The discussions hit on a wide variety of timely and compelling topics – online fraud, compliance, case investigations, internal fraud, and more. Wanting to share some of the key takeaways from my trip, I spent some time reflecting on the meetings during my 5-hour flight home. After reviewing my notes and replaying the discussions, I kept coming back to one of the bedrock principles of enterprise software in general, and fraud prevention in particular: the importance of good data. Put another way, data matters.

In the world of fraud prevention solutions, there's a lot of talk about detection techniques – things like business rules, predictive analytics, collusive fraud networks, neural nets, real-time prevention and many more. But no matter the technique, the one thing on which they all rely is good data. In every case, it means bringing together financial transactions as well as reference sources like account maintenance data, web logs for online banking, internal system access records, etc. The idea is to provide as rich a data environment as possible, so fraud decisions are made in context of everything that is going on with a customer and their account across all products and channels. As a general principal, the more data, the more context, the better.

But making good data available to a detection system is much easier said than done, and most technology solutions fail (some miserably) in this regard. Why is this? Well, one big reason is that the databases underlying most fraud detection and case management applications require data to be formatted in a very specific way. This data formatting step is commonly known as extract, transform and load (ETL), and it is often long, complex and cumbersome. Solutions that rely on ETL to get data into their system either pass off this problem to the IT department of the bank or credit union (nice thanks guys), or they charge for it in the form of a long (read: very expensive) professional services gig. And, to make matters worse, the resulting data environment is inflexible – getting additional data fields into it in the future requires doing the whole ETL process all over again. Not good when fraud is constantly evolving and the need for additional data in the future is a near certainty.

I'm sure there are some innovative solutions and recommendations out there, and we'd like to hear about them. How have you solved this problem?

Make a Comment

* = Required

* Name:

* Email:

Website:

* Comment:

*

Fill in the code shown on the left