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.
In this post, we use the following services:
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).
For this walkthrough, you should have the following prerequisites:
In this section, we walk through setting up Amazon Connect and our contact flow. We also discuss the contact flow in more detail.
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.
For this post, we have a predefined contact flow template that we can import from our GitHub repo.
For detailed import instructions, see Import/export contact flows.
Here you can find the ARN of the contact flow.
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.
The following diagram shows our contact flow.
The contact flow does the following:
You can also enhance your system with an Amazon Lex bot.
We use a CloudFormation stack to set up our resources.
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.
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.
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.
To add a record to your DynamoDB table, complete the following steps after the ML model is deployed:
A new window appears that displays an example JSON string.
Your first customer record is saved in the Amazon DynamoDB table.
To test the solution, complete the following steps:
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:
After you test the original payload, you can change numbers and see what prediction Amazon Fraud Detector makes based on new input.
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.
To avoid incurring future charges, delete the resources you created:
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!
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.