Transaction Risk API- What value does it bring to the market? (Blog 3 of 3)

Our latest product innovation, Transaction Risk API, was specifically built for easy integration into sophisticated machine learning (ML) models and is designed to help eCommerce merchants, marketplaces, payment processors, and others manage payment fraud. In our three part Transaction Risk API blog series, we have covered why we built it, how we built it, and today we will walk through what value it brings to the market.

Understanding market requirements

In our first blog of the series, we covered the evolution of fraud and how the landscape of today requires fraud detection earlier in the transaction flow. Since the sophisticated ML models being leveraged were traditionally built using mainly internal data, the introduction of third-party identity verification brings with it a number of critical product requirements:

  • Low latency response times – Models make predictions that are acted on (e.g. approve payment for authorization, send to 3DS or other challenge point, or reject payment) in real-time flows that may occur prior to a payment authorization. Transaction Risk API delivers a response within 100 ms to meet this need.
  • Highly-predictive and feature-ready data elements – Data scientists and machine learning engineers spend a lot of time on feature engineering data that might not even improve the model’s performance. Transaction Risk API provides our top 14 most predictive identity verification features that are generally Boolean or numerical and ready for modeling.
  • Global data – Online businesses accept payments from customers all around the world, and data science teams need to build models that perform well regardless of geography. Transaction Risk API delivers data on name, phone, address, email, and IP in over 170 countries.

Measuring model performance

In addition to specific product requirements, there are also specific performance measures for assessing the efficacy of ML models. Before we dive into the results we are seeing with Transaction Risk API out in the market, it’s important to outline these metrics:

  • Area Under the ROC Curve (AUC) – standard way to determine if a model has a high true positive rate, while maintaining a low false positive rate
  • Precision – the fraction of flagged transactions (for fraud) that are actually fraudulent
  • Recall (also known as true positive rate) – the fraction of all fraud that is caught by a chosen ML model’s operating point
  • False positive rate – the fraction of legitimate payments that are incorrectly blocked

In the context of Transaction Risk API, customers use the metrics above to measure value and answer a simple question: does integrating this API improve the overall performance of the existing model? In other words, is the false positive rate decreasing, and is the model catching more fraud (recall)? Finding the correct balance is critical here.

Value of Transaction Risk API

We’ve covered how Transaction Risk API was built to meet specific market requirements and to improve specific model performance metrics. Now let’s move on to the really good part – how is it actually performing in the market?
A select group of our customers have already had the chance to test and evaluate features provided by Transaction Risk API, and to put it lightly – the results have exceeded expectations:

  • A leading global marketplace saw a 25% increase in fraud recall
  • One of the largest global travel companies saw a 20-25% improvement in payment fraud detection rate
  • A managed eCommerce business saw a 5-15% reduction in chargebacks across its payment fraud models

These exciting initial test results are just the beginning of a massive opportunity for Transaction Risk API to bring value to businesses around the world. For more information about Transaction Risk API, visit the product page or contact us here for a consultation on how it can improve your fraud detection models.

Start a Free Trial

See how Ekata can reduce fraud risk for your business, contact us for a Demo.