Event-based fraud detection with direct customer calls using Amazon Connect

AWS Feed
Event-based fraud detection with direct customer calls using Amazon Connect

Several recent surveys show that more than 80% of consumers prefer spending with a credit card over cash. Thanks to advances in AI and machine learning (ML), credit card fraud can be detected quickly, which makes credit cards one of the safest and easiest payment methods to use. The challenge with cards, however, is that in some countries when fraud is suspected the credit card is blocked immediately, which leaves the cardholder without a reason as to why, how, or when. Depending on the situation, it can take anywhere from a few hours to days until the customer is notified and even longer to resolve.

With Amazon Connect, a cardholder can be notified immediately of a suspected card fraud and interactively verify if the suspected transactions were indeed fraudulent over the phone. Amazon Connect enables an event-based reaction, which allows you to contact the cardholder directly via phone without the need for an agent-in-the-loop. This makes for a cost-effective and frictionless cardholder experience.

This post shows you how to build, train, and deploy a fraud detection model and rules using Amazon Fraud Detector and integrate predictions with Amazon Connect in order to connect with customers in real time. Amazon Fraud Detector is a fully managed service that uses ML and more than 20 years of fraud detection expertise from Amazon to identify potentially fraudulent activity so you can catch online fraud faster and more frequently. Amazon Connect is an omnichannel cloud contact center that helps you provide superior customer service at a lower cost.

Solution overview

In this post, we use the following services:

• AWS CloudFormation sets up the resources for our contact flow.
• Amazon Connect is your contact center in the cloud. It allows you to set up contact centers and contact flows. We use a template that you can upload that helps you create your first contact flow.
• Amazon DynamoDB is the NoSQL data storage used to store your customer data. You can exchange it in your existing cloud infrastructure for instance with Amazon Aurora
• Amazon Fraud Detector is the AI/ML service that lets you build, train, and deploy your ML models. We provide all the data and code for you in this artifact.
• AWS Lambda handles the event-driven request coming from a transaction and the connection between Amazon Connect and your DynamoDB table.

The following diagram illustrates our serverless architecture.

Whenever a transaction is made, you can send the metadata of that transaction to a Lambda function (Step 1). This function invokes your Amazon Fraud Detector model and predicts whether this transaction is fraudulent. If it is, the function looks up customer data from the DynamoDB table (2), sends these attributes to Amazon Connect, and calls the customer (3) whose credit card is affected. When the customer picks up the phone (4), they can interact with Amazon Connect and learn more about what happened. The customer can then decide whether it was fraud. If it was, another Lambda function is invoked through Amazon Connect (5) and blocks the corresponding credit card by setting a flag in the DynamoDB table (6).

Prerequisites

For this walkthrough, you should have the following prerequisites:

• An AWS account

Set up Amazon Connect and the associated contact flow

In this section, we walk through setting up Amazon Connect and our contact flow. We also discuss the contact flow in more detail.

Create an Amazon Connect instance

The first step is to create an Amazon Connect instance. For the rest of the setup, we use the default values, but don’t forget to create an administrator login.

Instance creation can take 1-2 minutes, after which we log in to the Amazon Connect instance using the admin account created previously. We’re now ready to create our flow and claim a number to attach to the flow.

Set up the contact flow

For this post, we have a predefined contact flow template that we can import from our GitHub repo.

1. In the repo, select the file contact-flow/credit-card-fraud and choose Import.

For detailed import instructions, see Import/export contact flows.

2. Under the name of the contact flow, choose Show additional flow information.

Here you can find the ARN of the contact flow.

3. Note the following information from the ARN to use in a later step: the contact flow ID and contact center instance ID.

Claim your phone number

For instructions on claiming a number, see Step 3: Claim a phone number. Make sure to choose the previously imported contact flow while claiming the number. If no numbers are available in the country of your choice, raise a support ticket.

Understanding the contact flow

The following diagram shows our contact flow.

The contact flow does the following:

• Enables logging
• Sets the output voice to Amazon Kendra
• Gets customer input using DTMF (only keys 1 and 2 are valid)
• Based on the user’s input, the flow takes the following action:
  • Prompts a goodbye message stating no action will be taken and exits
  • Prompts a goodbye message stating an action will be taken, invokes a Lambda function to log the credit card in your DynamoDB table, and exits
  • Fails with a fallback block stating that the machine will be shut down and exits

You can also enhance your system with an Amazon Lex bot.

Create the CloudFormation stack

We use a CloudFormation stack to set up our resources.

1. Choose Launch Stack:

2. In the Parameters section, provide the following information:
   1. The fraud detector entity name
   2. The event name of this detector
   3. The name of your fraud detector
   4. A name for your DynamoDB table, such as customer-table-fraud-detection
   5. The IDs of your Amazon Connect instance and your contact flow (which you noted when you set up the contact flow)
   6. The S3 bucket name you want to use (the word “sagemaker” needs to be present)
   7. The number you claimed in Amazon Connect
3. Choose Next.

4. Acknowledge the creation of new AWS Identity and Access Management (IAM) resources and choose Create stack.

After the stack is deployed, you can find your AWS Lambda function, Amazon DynamoDB table, and an up-and-running Amazon SageMaker notebook called event-based-fraud-detection.

Build, train, and deploy the Amazon Fraud Detector model

In this section, we build, train, and deploy the Amazon Fraud Detector model using an example Jupyter notebook. You can build your model on the Amazon SageMaker console. For programmatic deployment, access the Amazon SageMaker notebook instance you created by choosing Open Juypter.

The instance contains a clone of the GitHub repository. It contains the example Jupyter notebook and example dataset. A config JSON was also created for you. To view these items, navigate into event-based-amazon-fraud-detector/fraud-detector-example.

Open the Fraud_Detector_End_to_End_Blog_Post.ipynb notebook to get started. For more examples on Amazon Fraud Detector, see the GitHub repository.

The notebook walks you through building and training the model. It also contains a lot of explanations and additional code that helps you deploy your first fraud detector.

Model metrics

This example also contains functionality to see and analyze the training metrics of your model. You can view these metrics interactively on the Amazon Fraud Detector console. On the Models page of the Amazon Fraud Detector console, choose the model that was trained. From there you can see several versions, if applicable, that were trained. Choose a version (for this post, version 1.0). The Model performance section contains an interactive graph similar to the following screenshot.

You can change thresholds to see how the confusion matrix changes. Furthermore, you can look at the ROC curve in the Advanced metrics section.

You’re model is now ready to be called on demand, for example from a website.

Add a customer record to your DynamoDB table

To add a record to your DynamoDB table, complete the following steps after the ML model is deployed:

1. On the Amazon DynamoDB console, choose the table you created with the AWS CloudFormation template (for this post, thefraudtable).

2. Choose Create item.

A new window appears that displays an example JSON string.

3. Enter the JSON file example-customer.json provided in the examples folder of the downloaded GitHub repository.
   1. Change the fields last_name, first_name, phone_number, and salutation).
   2. Leave the customer­_id field as is. We use this ID when we test our whole architecture.
4. Choose Create item.

Your first customer record is saved in the Amazon DynamoDB table.

Test your event-based architecture

To test the solution, complete the following steps:

1. On the AWS Lambda console, choose the function fraud-detection.

We add a test event to this function, which is also part of the cloned GitHub repository and can be found in examples/lambda-test-event.json. In this test event, you find four different keys:

• customer – The customer ID you gave your contact in the Amazon DynamoDB table. If you followed our guidance and didn’t change the ID when creating a customer in Amazon DynamoDB, you can leave this number as is.
• card_number – Any number (this number is passed into Amazon Connect and the last four digits are read to the customer).
• amount – A sample dollar amount that the customer hears when they are called.
• payload – The metadata generated during the transaction. We use this to predict whether the transaction was fraud (for this test, it’s a fraudulent case to demonstrate that the fraud detector is working).

After you test the original payload, you can change numbers and see what prediction Amazon Fraud Detector makes based on new input.

2. Choose Test.
3. For Event name, enter a name.
4. Enter the JSON example code.
5. Choose Create.

6. Choose Test

The Lambda function starts running, and you should get a phone call to the phone number you have placed in your Amazon DynamoDB table. If you choose to block your credit card during the call, your Amazon DynamoDB customer entry changes the field is_blocked from false to true.

Clean up

To avoid incurring future charges, delete the resources you created:

• Amazon Fraud Detector model, events, entities, and detector
• AWS CloudFormation stack
• Amazon S3 bucket created by the build.sh script

Conclusion

Congratulations! You just developed your first event-driven fraud detection architecture. We deployed a complete serverless architecture in which we integrated Amazon Fraud Detector with Amazon Connect to connect with customers in real time if credit card fraud is detected. You can putting the AWS Lambda function fraud-detection behind an Amazon API Gateway and call it directly from your website. Or integrate the architecture into your existing transaction chain and call the AWS Lambda function any time a new transaction is made.

The advantage of this event-driven architecture is that the building blocks are completely exchangeable. For example, instead of predicting fraud, you might want to classify images on your shop floor. To do so, you could use Amazon Lookout for Vision as your backend ML model. An example for this can be found here. The opportunities are almost limitless. So, get started today!

About the Author

Michael Wallner is a Global Data Scientist with AWS Professional Services and is passionate about enabling customers on their AI/ML journey in the cloud to become AWSome. Besides having a deep interest in Amazon Connect, he likes sports and enjoys cooking.