A couple years ago I drove to the forest preserve to go for a run. I had done it so often that it never crossed my mind that something like this would happen. When I made it back to my car, I found my window had been bashed in. I was the victim of a smash-and-grab.
While replacing my car window wasn’t something I wanted to dish out money for, I wasn’t totally distraught because I thought I had outsmarted the crooks. You see, when I head to the forest preserve for my run, I only bring my driver’s license and phone, and I keep them with me while I’m out on the trail. There was nothing in the car for the crooks to steal. A Pyrrhic victory, but a win for the good guy nonetheless. Or was it?
When I got home, I found out that my wife had used the car earlier that day and had accidentally left her wallet in the middle console…which we always leave unlocked. Her wallet, credit card, ID…gone. Fortunately, soon after our discovery we received a call from the credit card company. Their fraud detection system identified suspicious activity on my wife’s card and wanted us to verify whether we’d been behind the transactions.
Cat vs. Mouse
Let’s take a step back. A common sequence of events is for the thief to do a small transaction with the stolen credit card to verify if it has been deactivated. Typically, this is done at a gas station. Pump some gas, pay with the stolen card, and if everything goes through, drive off to the real target - a more substantial transaction. And that’s exactly what happened to us. This person tried buying a couple hundred dollars’ worth of merchandise at another store. And that was the red flag that triggered the call to us.
Fraud, in any form, is a never ending cat-and-mouse game to see who can outsmart the other guy. When we apply that principle to software applications built for detecting fraud, we can see the obvious advantage a rule engine can provide in getting the upper hand.
For example, let’s say my credit card company had the following business rule in place to catch this type of stolen card fraud:
Scenarios like this may be legitimate, but what if I, as the consumer, want to be the one who adjusts the parameters that trigger a fraud alert? Maybe I’m going on a family vacation and I know there are going to be some hefty transactions north of the $500 line. If this application was self-service, I could tweak that rule so that I wouldn’t get notified or my card wouldn’t get deactivated while I’m on that vacation. And speaking of travel, we could even create rules to account for something like the following:
Even in this scenario, I may want to be the one who adjusts the rule for determining what is meant by “current location.” I could easily drive from Chicago to Dallas in which case I don’t want this rule to fire. To avoid that, maybe I want to change the rule. Note the addition of my current location condition that I added.
While elements of fraud will never go away, configurable business rules give us some leverage in staying one step ahead of the perpetrators.
For more information about self-service applications, check out a previous post by our Chief Technology Officer, Loren Goodman.