Integration with AWS Lambda

In this guide, we will explore the seamless integration of FraudAway with AWS Lambda. Specifically, we will illustrate this integration using a practical scenario where we examine a purchase attempt involving email, credit card details, and the associated IP address. To establish a robust rule for fraud detection, we will leverage two NPM packages and integrate an external API call to inspect the IP address. It's worth noting that users have the flexibility to expand upon this example by incorporating additional API calls, alternative packages, and custom logic to bolster and refine the rule according to their specific needs.

Creating lambda functions

Here is the source code of the first lambda, in which we will check if the email used for the purchase was disposable or not:

var disposable = require("is-disposable-email")

exports.handler = async(event, context, send) => {
  const email = event.email
  
  if (!email) {
    send(new Error('Missing property: email'))
  }
  
  if (disposable(email)) {
      send(null, {
        observedState: 'Invalid'
      })
  } else {
    send(null, {
        observedState: 'Valid',
        rawData: {email}
      })
  }
}

Note: we are omitting here an explanation how to create a lambda function with NPM packages. Please consult AWS documentation for details.

After this, we need to add two more tags in the configuration, which will tell FraudAway how to use this function in the design editor later. The first tag (waylay:sensor) tells the engine that the lambda function can be used for building rules, and the second one (waylay:states) tells the engine which states this function will produce as the output (Valid/Invalid):

Similarly, to check if the card is valid, we will create the following function:

var valid = require("card-validator")
exports.handler = async(event, context, send) => {
  const card = event.card
  
  if (!card) {
    send(new Error('Missing property: card'))
  }
  
  var numberValidation = valid.number(card);
  
  if (!numberValidation.isPotentiallyValid) {
      send(null, {
        observedState: 'Invalid'
      })
  } else {
    send(null, {
        observedState: 'Valid',
        rawData: {...numberValidation.card, ...{card }}
      })
  }
}

Finally, we will add the IP address check using the external API provided by ipqualityscore endpoint. In this check, validation of the IP address will come later, hence we are only interested in getting the response back as the state.

const axios = require("axios");
const { env } = require("node:process")

exports.handler = async (event, context, send) => {
  console.log("Handling event:", event)
  const IP = event.IP
  try {
      const targetUrl = "https://ipqualityscore.com/api/json/ip/"+ env.IP_QUALITY_SCORE + "/"+ IP;
      const payload = { };

      const response = await axios.get(targetUrl, {}, {});
      console.log(`HTTP Status Code: ${response.status}`);
      console.log("Response Data:", response.data)
      send(null, { observedState: 'Success', rawData: response.data });
  } catch (error) {
      send(null, { observedState: 'Error'})
  }
}

Note: Please note that the decision to provide only 'Success' or 'Error' states, rather than 'Valid' or 'Invalid,' is intentional. This API function generates a limited set of data points, including a score, indicators of Tor or VPN usage, and more. The intention is to leverage the rawData output from this function within the rule, allowing us to assess the risk associated with an IP address. This approach enables a more nuanced analysis, allowing us to make informed judgments based on the specific data characteristics provided by the function.

Creating the payment rule

Now, let's proceed to the rules designer to create the rule. As depicted in the image below, if any of the checks (card, email, or IP address) fail, we will categorize the transaction as risky. Furthermore, the specific reason for flagging this transaction will be included as part of the output:

Our template has four different variable settings:

At the time of invocation, these variables will be replaced with actual values. Meanwhile, we have the flexibility to maintain the fraud score threshold at 95. This threshold plays a crucial role in determining whether the IP score suggests a potentially fraudulent IP address, as indicated in the 'ipScoreRisk' node:

${nodes.IpScoreCheck.rawData.fraud_score} > ${variables.FRAUD_SCORE_THR}
 

With everything set up, we can now execute the rule and visually examine the results.

You can also take this rules template from here:

cardPaymentCheck

.json

Download JSON • 9KB

That's it, in 5 minutes you got your first payment rule ready!