The Authenticator’s Dilemma
It’s hard for your customers to remember their PINs, passwords, or their dog’s inside leg measurements. Your agents spend too much time asking these questions and waiting for customers to find pieces of paper. The whole process is just security theater, providing very little meaningful security, but expected, nonetheless.
Ten years ago, Opus Research coined the phrase “Intelligent Authentication” to encompass an approach, the technologies, and techniques that enterprises could use to create better customer and agent experiences that delivered real security efficiently. Whilst some enterprises have had great success adopting this approach, it is not without its challenges. The most feasible authentication technology at the time was Voice Biometrics, which proved technically complex to integrate while very secure and effective in the right use cases. Also, it was (and remains) dependent on customers enrolling, with associated privacy implications, and then calling back frequently enough to warrant the investment. In short, voice biometrics-based authentication isn’t the correct answer for everyone.
Phone Numbers to the Fore
In search of practical and affordable alternatives, organizations have often looked to Automatic Number Identification (ANI) or Caller Line Identifier (CLI) as a source of authentication. Like the caller’s voice, their phone number is inherent in their means of contacting the call centre. Yet there was a major problem. Before mobile phones and number portability were commonplace, however, the challenge was that less than half of all calls to a contact centre had a valid ANI and less than half of those matched a known customer record.
Most customers now contact enterprises from their mobiles, often keeping the same number for decades if not life. Many organizations now use the ANI or CLI to identify their customers, either overtly or in the background. As a result, it is not unusual to see more than 75% of calls recognised as customers, more than 3x the rate of 10 years ago, and we expect this will only increase further in the future. Opus Research strongly recommends using ANI as an identifier, especially when combined with strong authentication such as Voice Biometrics.
ANI for Authentication
As an authenticator, you can argue that ANI/CLI represents a possession factor because its use signals ownership by the known customer. In most cases, this is complicated because the customer does not own the number itself because it is assigned to phone users by their telecommunications provider, who can just as easily assign it to another handset. Thanks to readily available “Caller ID spoofing” services, a business can’t trust that the number they receive represents the call’s originating device. There are benign uses of Caller ID spoofing, like providing the proper callback number while working remotely. Yet it has become a common way for fraudsters to exploit weaknesses in a business’s security processes.
To further complicate authentication processes, the communications world is splintered into fixed-line, mobile, international and toll-free networks, among others. Calls often need to pass between many providers and, in many cases, enterprises are not on the same telecommunications network as their customers. Unfortunately, the standards used by telecommunications service providers are decades old and not designed with security in mind. Each carrier relies on implicit trust that its peers are telling the truth. Individuals working with less scrupulous providers can exploit this weakness such that you really shouldn’t trust the ANI presented to you. That’s why we say: “Don’t Trust Just Any ANI”.
Adding AI to ANI is the Solution
Fortunately, through partnerships with telecoms providers and the judicious application of artificial intelligence (specifically, machine learning), the technology now exists that can help you trust ANI.
Opus Research will be introducing this new Network Authentication and Fraud Detection category in our upcoming Intelligent Authentication Intelliview and eBook.