Policies are one of the main lines of defence in stopping fraud. But, for years they’ve been built wrong. It’s no one’s fault, it’s just there’s a better way.
A good policy is the key to success, it always has been. It’s the vanguard to security, ensuring the bad guys stay out and the good guys win. But the landscape is changing. New competition & technologies alongside changing markets, are fundamentally altering the way customers bank, pay for goods and perceive customer service. It’s also presenting new opportunities for the bad guys, who now have more technologies and attack vectors than ever before.
To stay one step ahead, companies need a clear oversight of how their policies are working. Here we take a look at three reasons why policies might not be performing.
Are we heading to Policy fatigue?
The problem with designing policies is that it’s difficult to know in advance whether they are going to be effective. When they are first implemented, best practice is to pick the fewest journeys possible. However, gaps form, user behavior changes, or new fraud methods are introduced, and the policy needs to adapt. Which, as is too often the case, means creating a new one.
Within a couple of years, what started off as a few unique defined policies is now a complex map of multiple policies built on top of each other, working to ‘solve’ the problems caused by the last one. It’s like rearranging the deckchairs on the titanic, it’s set for failure. This process of building another policy, rather than determine why the old one doesn’t work is where becomes too easy for the criminals. By layering, rather than fixing, weak spots develop that are easy for the bad guys to exploit.
Do you know what your policy really does?
With constantly evolving technology and an increasing number of channels for users to transact on, it’s hard for risk analyst and policy teams to keep on top of it all. Policies need to be regularly adapted to not only improve customer experience as technology changes but also mitigate the risks that it creates.
In order to solve this, we need to know what the policy is doing. But how much oversight do teams really have of them? With team members and processes regularly changing, it’s hard to understand the nature of each policy after it’s being built on so many times, especially as there is usually little documentation on its history. After a couple of years and multiple changes, it’s not necessarily clear whether the policy is still doing what it was created for, whether it duplicates another or whether it is really needed any more.
Without this oversight, policy management becomes difficult for any team, meaning it’s easier to create and override than to solve the problem.
Who’s in charge?
With constantly evolving technology and an increasing number of channels for users to transact on, it’s hard for risk analyst and policy teams to keep on top of it all. The problem is that current policy management is outdated for today’s landscape. Teams have clear rules and structures in place to create new policies and implement them. But, less so around the retirement of policies that aren’t needed. This stems from a lack of understanding as to what the existing policy is managing and how it compares against the newer version. Without clear visibility to the impact it would have on all the channels, retiring policies is just too much of a gamble and no one wants to take responsibility.
It should be noted that the champion / challenger model for implementing new policies gives some understanding of how a new policy might compare against the old one, but teams are not able to visualize these policy changes in production or sample an against a percentage of users. We can only compare one policy against another.
Another way…
Our approach to policy is different, we believe that policies don’t need to be like this. Just because the concept is complicated the process doesn’t need to be. By providing policy teams with the ability to create policies in a production environment using a Graphical User Interface (GUI) and simple language, including business specific nomenclature, teams can understand and clearly visualize the steps.
Combine this with the ability to test both new policies and changes to existing policies using multiple processes, including, champion / challenger, running legacy data through the policy and finally A/B testing in live environments. Teams can be assured that the policy they are implementing is likely to have a positive effect, reducing friction to the customer journey and most importantly, allow for older policies to be retired as appropriate.
Customers are moving to mobile based transactions and are looking for reduced friction. As we become more and more of a digital society, the number of variables to build a policy against isn’t likely to reduce, they’re going to keep growing. And, if we don’t change our ways, so are the number of policies. We need policies to be simple, with language and systems that can accommodate ever changing scope, context and data points that need to be interpreted to stay ahead of fraudsters.
