Adding AWS fraud detection to SugarCRM

As the title suggests, we will explore and build a fraud detection system inside Sugar Sell by utilizing AWS prediction and machine learning services.

Fraud is a multi-billion dollar a year problem. Companies are adding multiple sales channels like e-commerce systems that can be targets for fraud. CRM systems are a valuable source of customer information and a reference for "normal behavior" that can be used to identify fraud. Sales reps and Service agents using Sugar are on the front lines of the fight against fraud.

A recent research from Aite Group reveals that 65% of fraud and anti-money laundering (AML) pros believe that synthetic identities are now a bigger issue for banks than regular identity theft.

This particular topic, fraud prevention, is awesome to talk about but can be complex so we’re going to turn it into a blog series. All the material we create will be released on GitHub with as much detail as needed to let you try it out for yourself. Please reach out if something is not clear enough!

We will start our series by providing a high level architecture design and scenarios we intend to cover.

Fraud Detection Goals

Our goal is to catch and prevent online fraud on two different fronts. There are others but these are the most common and costly.

  • New Accounts: distinguish between legitimate and fake accounts
  • Online payments: detect and flag fraudulent transactions

Solution Scenario

A customer (1) would like to make a purchase in our e-commerce app (2) that backfeeds data to Sugar Sell. At customer sign-up, we check in Sugar if that account already exists. If not, we create will create the account (3) in Sugar which triggers an AWS fraud detection process (4,5,6) that assesses the risks. If the account is flagged as fraudulent, then the e-comm system will not allow checkouts for this new account.

Later, at checkout, we will ask for billing information, along with credit card details, which we will validate using the Stripe API. For this series, we will not store any credit card information in Sugar. PCI compliance is a very serious and complex piece of architecture not required for our series. We will use other relevant data for our fraud detection.

With that card data pre-validated, the e-commerce app will call the Sugar API to create purchases and purchase line items from these online orders where they will be processed via a new Fraud Detection Module (7).

Our Sugar user will have access to the Fraud Detection Module which contains lists, details, and dashboards to allow users to monitor, identify, and react to suspected fraud. These tools will be used to determine the end result of each transaction and/or account within Sugar. Don't worry, we will explore this module in future posts, but just so you know we will support end-user actions and automated BPM (8) processes.

For the sake of simplicity, our shopping process ends when the e-commerce orders are scored by AWS fraud process and subsequent are taken which leaves these purchases & orders in either a “Ready to Fulfill” or “Fraudulent” status.

We’re gonna focus this series on the real-time integration points, we could definitely explore our batching capabilities in a new future series.

Integration Use Cases

New E-Commerce Account:

  • E-Commerce Customer to Sugar Sell Account
  • Sugar Sell to AWS Fraud Prediction

New E-Commerce Order:

  • E-Commerce Order to Sugar Sell Purchase
  • Sugar Sell to AWS Fraud Prediction

I’m super excited with this use case to learn more about sugar and its integration capabilities. What do you, as a community, think about it? Should I cover more areas? Is it realistic enough? Please share your thoughts.

References:

https://aws.amazon.com/blogs/machine-learning/reviewing-online-fraud-using-amazon-fraud-detector-and-amazon-a2i/

https://aws.amazon.com/fraud-detector/

Anonymous