Intelligent Call Routing Using Amazon Fraud Detector and Amazon Connect

By Madhan Kandaswamy, Innovation Consultant at Tata Consultancy Services
By Deenadayaalan Thirugnanasambandam, Sr. Cloud Architect, AWS Professional Services

This post describes how you can use the recently introduced Amazon Fraud Detector service to detect spam calls and route them efficiently using Amazon Connect.

Each year, tens of billions of dollars are lost across the globe to online fraud. Companies conducting business online are especially prone to attacks, so they employ fraud detection applications to identify fraudsters.

The goal is to stop them before they cause costly business disruptions. However, these applications often rely on business rules that don’t keep up with the changing behaviors of fraudsters.

More recent fraud detection applications have tried to use machine learning (ML). Unfortunately, they often use a one-size-fits-all approach based on general datasets and fraud behaviors that aren’t specific to your business. That limits their accuracy.

Amazon Fraud Detector is a fully managed service that makes it easy to identify potentially fraudulent online activities such as online payment fraud and the creation of fake accounts.

Amazon Connect is a cloud contact center that you can set up in a few steps for agents who are located anywhere.

Tata Consultancy Services (TCS) is an AWS Partner Network (APN) Premier Consulting Partner with AWS Competencies in Migration, Industrial Software, SAP, and others. TCS is also an AWS Managed Service Provider (MSP) and has the Amazon Connect Service Delivery designation.

Recently, TCS has been integrating emerging AWS machine learning services with Amazon Connect to design a fully functional Amazon Connect contact center.

In this post, we describe how TCS worked with AWS ProServe to detect spam calls and route them using AWS services.

Solution Overview

In our solution, we use Amazon Fraud Detector to classify the callers into three risk categories: high, medium, and low.

We use the check_contact_attributes block in Amazon Connect to dynamically route each type of caller to the appropriate action, such as route the call, blacklist the caller, or add caller to spam list.

We can use this same method to route calls from critical customers, whom we could profile based on loyalty, frequency of call, and social influences such as Klear score. We could also use it to handle difficult customers, fraudulent calls from suspicious callers, spam calls, and types of callers.

To classify the calls, we use Amazon Fraud Detector and Amazon Connect with markers indicating which transactions are fraudulent or legitimate. Amazon Fraud Detector builds, trains, and deploys advanced ML models in a highly available and scalable environment.

Amazon Fraud Detector uses your data, machine learning, and more than 20 years of fraud detection expertise from Amazon. It combines them to automatically identify potentially fraudulent online activity so you can catch more fraud faster.

Amazon Connect is omnichannel, so it lets you create personalized experiences for your customers. For example, you can dynamically offer chat and voice contact based on such factors as customer preference and estimated wait times. Agents, meanwhile, conveniently handle all customers from just one interface.

Amazon Connect includes tools for skills-based routing, real-time and historical analysis, and management. It’s an open platform you can integrate with other enterprise applications, such as Salesforce.

We use AWS machine learning services to detect the anomalies in every transaction and help the call center handle odd scenarios. Using your organization’s historic call data and user profile data from Customer Relationship Management (CRM) systems, you can take advantage of these ML services with simple-to-use API actions.

Setting Up the Contact Center

Before beginning, we made sure to set up an Amazon Connect instance with a contact flow. The contact flow was an AWS Lambda invocation to the fraud detection services. Once the instance was available, we created an Amazon Fraud Detector training model with our dataset.

After those prerequisites were out of the way, we followed these steps:

1. Set up Amazon Connect instance.
2. Create a contact flow.
3. Set up an Amazon Fraud Detector model.
4. Invoke the Amazon Fraud Detector prediction API in Amazon Connect.

Step 1: Setting up an Amazon Connect Instance

We used an Amazon Connect instance to organize all the resources and settings related to the virtual contact center we were setting up. We used the same instance for the voice service. When you do this, you can either use the phone number that Amazon Connect provides, or port your current phone number to Amazon Connect.

For more information about setting up your instance, read the Amazon Connect Administrator Guide.

Step 2: Creating a Contact Flow

Contact flows are the building blocks for defining the customer experience. They define how the flow should work from start to finish. A single contact flow works for both voice and chat, which makes your design more efficient.

In our implementation, however, we used voice channel to create the flow shown in Figure 1. The same flow would work for an agent’s chat channel, as well.

Figure 1 – Creating a contact flow.

The contact flow in Figure 1 has two AWS Lambda invocations. With Lambda and Amazon Connect, you can pass and return custom key-value pairs allowing for multiple integration points within your contact flows.

We use the first Lambda to handle a data dip to get the caller information:

var mockDB = require('./mockDB');
var result = function result(phNo, timeStamp) {
    var dt = new Date();
    var resp = mockDB[phNo]
    resp.timestamp = `${dt.getFullYear().toString().padStart(4, '0')}/${(dt.getMonth()+1).toString().padStart(2, '0')}/${ dt.getDate().toString().padStart(2, '0')} ${dt.getHours().toString().padStart(2, '0')}:${ dt.getMinutes().toString().padStart(2, '0')}:${dt.getSeconds().toString().padStart(2, '0')}`
    return resp
}

exports.handler = function(event, context, callback) {

var phNo = "+11234567890"
if(mockDB[event.Details.ContactData.CustomerEndpoint.Address] != undefined) { phNo = event.Details.ContactData.CustomerEndpoint.Address }

    callback(null, result(phNo, 'demo'));
}

We can get the caller’s profile data from the endpoint address (phone number). In an actual production version, we would get the user profile from a CRM or Enterprise system.

Once we have the metadata about the caller (customer), the contact flow invokes the second Lambda function, which relies on the fraud detector prediction API.

Step 3: Setting up the Amazon Fraud Detector Model

As mentioned earlier, Amazon Fraud Detector finds anomalous events or transactions. In our solution, we used user profiles with history call activities to train our model to identify the pattern of a legitimate caller. Using that model, we then asked it to identify the anomalies present in a suspicious call.

To train the model, we first created the model, and then we generated the real-time fraud predictions.

Creating the Model

Following the instructions to build an Amazon Fraud Detector model, we associated training data with the template for Online Fraud Insights. Our training data includes the mandatory fields that Amazon Fraud Detector requires.

It also includes custom variables like call_duration (historic average call time spent by that caller), customer_class (like a loyalty membership status), and contact_type (voice or chat).

We can select different model variables for different industries, which helps us differentiate legitimate from fraudulent callers with greater accuracy:

response = client.put_model(
    modelId=_modelId,
    modelType=_modelType,
    description='Amazon fraud detector model to detect the potential risky users calling the service desk, this demo leverages amazon connect',
    trainingDataSource={
        'dataLocation': 's3://'+bucket+'/'+filename,
        'dataAccessRoleArn': 'arn:aws:iam::*********:role/service-role/AmazonFraudDetector-DataAccessRole-******'
    },
    modelVariables=[
        {
          "name": "ip_address"
        },
        {
          "name": "email_address"
        },
        {
          "name": "phone_number"
        },
        {
          "name": "event_timestamp"
        },
        {
          "name": "event_id"
        },
        {
          "name": "billing_name"
        },
        {
          "name": "contact_type"
        },
        {
          "name": "call_duration"
        },
        {
          "name": "customer_class"
        }
    ],
    labelSchema={
        "labelKey": "fraud_label",
        "labelMapper": {
          "FRAUD": [
            "1"
          ],
          "LEGIT": [
            "0"
          ]
        }
      }
)

When we wrote this post, the model template required an IP address as a mandatory variable. You can work around this requirement by creating a utility function that maps the phone number you want to use into an IP address. Use this format:

{0–255}.{0–255}.{0.255}.{0.255}.

Since the model checks for the uniqueness of this field, this hack helps.

Amazon Fraud Detector validates model performance using 15 percent of your data that was not used to train the model. You can expect your trained model to have real-world fraud detection performance similar to the validation performance metrics.

Amazon Fraud Detector provides the following model performance metrics. They help us create a balance between detecting more fraud and annoying our legitimate customers.

• True positive rate (TPR) – Percentage of total fraud the model detects. Also known as capture rate.
• False positive rate (FPR) – Percentage of total legitimate events that are incorrectly predicted as fraud.
• Precision – Percentage of fraud events correctly predicted as fraudulent compared to all events predicted as fraudulent.
• Area under the curve (AUC) – Summarizes TPR and FPR across all possible model score thresholds. A model with no predictive power has an AUC of 0.5, whereas a perfect model has a score of 1.0.

Figure 2 – Example of Amazon Fraud Detector model performance metrics.

After careful validation and analysis, we reviewed our model performance and deployed the model with the balance we wanted.

Generating Real-Time Fraud Predictions

Following the instructions to generate real-time fraud predictions, we created a detector that includes the deployed model version, decision rules, variables, and outcomes. Then we set the outcome based on a rule, as shown in Figure 3.

Figure 3 – Example of desired outcomes based on rules.

After creating, training, and activating the model, plus creating the detector, the outcomes and rules for the detector look like this:

response = client.create_detector_version(
    detectorId = _detectorId,
    description = 'Creating new detector version for' + _detectorId ,
    rules=[
        {
      "detectorId": _detectorId,
      "ruleId": "cc_high_risk",
      "ruleVersion": "1.0"
    },
    {
      "detectorId": _detectorId,
      "ruleId": "cc_medium_risk",
      "ruleVersion": "1.0"
    },
    {
      "detectorId": _detectorId,
      "ruleId": "cc_low_risk",
      "ruleVersion": "1.0"
    }
    ],
    modelVersions = [
        {
        'modelId' : _modelId,
        'modelType' : _modelType,
        'modelVersionNumber' : '2.0'
        },
    ]
)

Once the detector is in an active state, we can test the results by sending events to Amazon Fraud Detector and getting a fraud prediction. We can now use the prediction API to predict fraudulent calls in real time.

Step 4: Invoking the Amazon Fraud Detector Prediction API in Amazon Connect

We were now able to use the Amazon Fraud Detector prediction API generated by the previous step to invoke the second Lambda function that we added in the contact flow:

Var mockDB = require('./mockDB');
var util = require('./util');
var AWS = require('aws-sdk');

var frauddetector = new AWS.FraudDetector({region:'us-east-1'});


var getnamefromphno = function(phNo) { return mockDB[phNo].fullname }
var getUserAvgDurationfromphno = function(phNo) { return mockDB[phNo].avgDuration }
var getEmailfromphno = function(phNo) { return mockDB[phNo].email }
var getUserClassfromphno = function(phNo) { return mockDB[phNo].class }
var get_ip_ = function(phNo) { return util.getUniqueIPfromPh(phNo); }
var dt = new Date();

exports.handler = function(event, context, callback) {
console.log(JSON.stringify(event.Details))
var phNo = "+11234567890"
if(mockDB[event.Details.ContactData.CustomerEndpoint.Address] != undefined) { phNo = event.Details.ContactData.CustomerEndpoint.Address }
   var inputMap = {
       call_duration: String(getUserAvgDurationfromphno(phNo)),
       customer_class: getUserClassfromphno(phNo),
       email_address: getEmailfromphno(phNo),
       ip_address: get_ip_(phNo),
       event_id: event.Details.ContactData.ContactId,
       phone_number: phNo,
       contact_type: event.Details.ContactData.Channel,
       event_timestamp: `${dt.getFullYear().toString().padStart(4, '0')}/${(dt.getMonth()+1).toString().padStart(2, '0')}/${ dt.getDate().toString().padStart(2, '0')} ${dt.getHours().toString().padStart(2, '0')}:${ dt.getMinutes().toString().padStart(2, '0')}:${dt.getSeconds().toString().padStart(2, '0')}`
/*event.Details.Parameters.timestamp*/,
       billing_name: getnamefromphno(phNo)
   }
var params = {
 detectorId: 'aws_connect_detector_1', /* required */
 eventId: inputMap.event_id, /* required */
 detectorVersionId: '3.0',
 eventAttributes: inputMap,
};
frauddetector.getPrediction(params, function(err, data) {
 if (err) console.log(err, err.stack); // an error occurred
 else
 {
 console.log(data);
 var resp = {}
 resp.fullname = inputMap.billing_name;
 resp.prediction = data.outcomes[0]
  callback(null, resp);
 }
});
}

That’s all it takes to integrate the two services. After that, whenever a user called our contact center, the first Lambda function in the contact flow does a data dip. It sends the caller’s details to the fraud detector Lambda function, which outputs the outcome predicted by the model.

Using the custom rules set we wrote, the outcome is determined by the model score, and can be one of:

• pass_to_skilled_agent (for high risk)
• pass_to_agent (for medium risk)
• pass_to_bot (for low risk)

If the model detects a high-risk caller, the contact flow redirects them to a queue with experienced agents. If it detects a spam call, it can simply hang up. If the model indicates a caller of medium risk, the contact flow could direct it to a typical agent. Finally, if the model indicates low risk, the contact flow directs the call to a bot.

In the latter case, we could take advantage of Amazon Lex automatic speech recognition (ASR) and natural language processing/understanding (NLU) capabilities. They would help us create great self-service experiences for our customers.

Conclusion

Amazon Fraud Detector can complement Amazon Connect to optimize the contact flow to route calls efficiently. Used together, they distinguish your genuine customers from spam or fraudulent callers.

You can also use other AWS machine learning services to provide customer experience intelligence to Amazon Connect.

TCS has a proven record of delivering industry-leading contact center solutions, with associates who are trained and certified in implementing custom Amazon Connect contact centers. To learn more about TCS’s experience and consulting with Amazon Connect, please contact us.

The content and opinions in this blog are those of the third party author and AWS is not responsible for the content or accuracy of this post.

.

.

Tata Consultancy Services (TCS) – APN Partner Spotlight

TCS is an APN Premier Consulting Partner and Managed Service Provider (MSP). An IT services, consulting, and business solutions organization, TCS has been partnering with many of the world’s largest businesses in their transformation journeys for the last 50 years.

Contact TCS | Practice Overview

*Already worked with TCS? Rate this Partner

*To review an APN Partner, you must be an AWS customer that has worked with them directly on a project.