Several weeks ago I introduced the Shape AI Fraud Engine (SAFE), a product to identify and mitigate manual fraud for F5 customers (Shape AI Fraud Engine (SAFE): Mitigating Manual Fraud Using Machine Learning). In this article, I will describe the actions that may be taken by SAFE to alert the customer to potential fraud or to block it outright. Much of the information in this post comes directly from SAFE documentation which can be found in this guide on Sharepoint (guide largely created by Payal Shah, Pragyan Sharma, and Yesenia Barajas).
How SAFE Works in Real Time - SED Customers
For SED enterprises, Shape inserts 1JS through a bootloader on all flows. Any additional flows (relevant for SAFE use-case) are also routed through SED for more coverage. Important flows which may be of interest for financial customers include money transfer and billpay pages and the account profile page, where a customer can change their personal and contact information. Having visibility into these flows allows SAFE to detect anomalous behavior through actions which may lead to loss for the enterprise. For retail customers, we would like 1JS loaded on checkout and payment pages so that anomalies in these flows can be observed. The enterprises who do not have SED JS tag on all the webpages, it’s recommended to have customers insert 1JS tag directly into all the web pages and not update SED JS to invoke 1JS.
The figure below shows how SAFE operates for an existing SED customer.
First, 1JS is added to every page on the customer’s website. Next, all relevant URLs for which a customer will want SAFE to take an action are then routed through SED. For financial customers, this may include URLs such as the login page, the money transfer page, the billpay page, and the profile update page. It should be ensured that SAFE collects an identifier that can be shared between the customer and Shape to identify the transaction. This may include a username, account number, order number, session ID, etc. This will ensure that Shape and the customer can exchange information regarding specific transactions without confusion. Once SAFE’s 1JS is injected, SAFE will begin collecting data. This data includes default features such as keyboard and mouse events performed on each page as well as browser and IP characteristics. With permission from the customer, SAFE will often collect additional fields which may be helpful to identifying fraud. These may include credit card names and billing and delivery zip codes, which can be helpful in determining retail fraud.
Once SAFE is deployed, each time a device accesses the customer’s site, the SED calls 1JS and collects the necessary data to predict manual fraud. The prediction response is then returned to the enterprise and the device, which may be consumed in real time. These possible predictions include: (1) no fraud, (2) mitigate, (3) challenge, and (4) review. SAFE recommendations are sent in the SAFE cookie within the fr “fraud recommendation” dictionary, which is URL encoded and AES-GCM encrypted. For transactions to be mitigated (i.e., blocked), SAFE can mitigate those transactions using the same mechanism used to block automation using SED. For other actions such as challenge (i.e., MFA) or review, the customer can use their own solution to take actions on those transactions. Shape can also provide a file feed of transactions in these categories for the customer to review and action on offline. Shape recommends that customers take action on SAFE recommendations asynchronously as to avoid giving fraudsters real-time feedback. This way, fraudsters will not know which action(s) contributed most to the positive fraud recommendation. This can be done by only blocking on a small number of URLs or not alerting the user immediately when a transaction has been blocked. The customer may also serve a generic message to avoid giving the user specifics on why the transaction was mitigated.
How SAFE Works in Real Time - BIG-IP Enterprises
For Big-IP customers not utilizing SED, SAFE operates through BIG-IP instead of SED. 1JS is hosted on the enterprise's domain -- allowing Shape to run invisibly.
The figure below shows how SAFE operates for an existing BIG-IP enterprise.
Quoted from the SAFE documentation, the series of requests that take place are:
How SAFE Works in Real Time - New Enterprise of Non-SED/Non-BIG-IP
If an enterprise is not a current Shape enterprise and not a BIG-IP enterprise, then Shape recommends the enterprise insert 1JS via any method of their choice (i.e. tag manager, code update, app server). Shape recommends enterprises use first party 1JS insertion. If the customer is not willing to make the necessary routing changes for 1JS and API requests, third party 1JS insertion can be considered.
The figure below shows how SAFE operates for new enterprises not currently using SED or BIG-IP solutions.
Per the SAFE Deployment guide, the following describes how SAFE operates for non-SED and non-BIG-IP customers:
The series of requests that take place are: