> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mangopay.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Overview

export const Signal = ({content}) => <Tooltip tip="Attribute of a user’s session detected by the fraud prevention profiler.">
        {content}
    </Tooltip>;

## Introduction

Mangopay’s fraud prevention solution lets you define custom logic to detect and mitigate fraudulent attempts on your platform.

On the **Essential** plan, you can use the solution without additional integration from within the [Mangopay Dashboard](https://hub.mangopay.com/) to monitor transactions, create and test your rules, and leverage network-wide insights from Mangopay. In this case, the solution relies only on information already available in the transaction data (such as IP address, user and payment details, etc).

On the **Advanced** plan, you can also integrate the profiler in your user-facing pages to collect additional data from their browsing session which can enhance your fraud-detection capabilities thanks to proprietary technology. This option leverages a wide range of data signals that can help detect bots, VPNs, and abnormal network settings or user behavior.

#### Safeguard your platform

Enjoy a 30-day free trial of our Advanced fraud prevention plan and see our solution in action. No charges apply, subscribe when ready.

[Sign up from the Dashboard](https://hub.mangopay.com/)

## How it works

Mangopay’s fraud prevention solution safeguards your platform by screening events. The solution analyzes data of events screened and, based on your custom rules, generates recommendations.

The diagram below shows the example of pay-in fraud prevention:

<div>
  <iframe width="100%" height="600" src="https://cdn.swimlanes.io/dist/embeded.html#ddDBTgIxEAbge59izptsjIqYcCDhonAwIeLNeKgwkInd6TJt3XDzHXwBnoVH8UmcroHIul6b/5vOP08UHY7gTmxaQS34jhzJM3x9fMLUN0ARGi9vwZhJXcMFNPgaKCKU5RjOXkZQFM+XL0UBj4l1kl+TI95AwBB0YJePYe5sXHupWniV4QJZd7C7SncAwW3CEM0xlsmD5Y3XAEzms5Zdt//9JLMsic3vUEbdai0cnP4j3iaSnflzgfI/e3MsKcmh9ouhB/csO8zuHhnF6gUEl77SpiubQWfrPn6r/LCfVbXDfKDD/nzCNw==#ddDw" />
</div>

<Steps>
  <Step title="Profiling session (optional)">
    Optionally, the profiler runs a profiling session to collect data (if integrated).
  </Step>

  <Step title="Event to be screened">
    A user proceeds to checkout and makes a payment on your app or website.
  </Step>

  <Step title="Pay-in request">
    Your server requests a pay-in (and includes the `ProfilingAttemptReference` if applicable).
  </Step>

  <Step title="Inquiry">
    Your pay-in request triggers an inquiry, which is a request to screen the pay-in event.
  </Step>

  <Step title="Rule sets">
    The fraud prevention solution runs your custom rules and Mangopay's default rules.
  </Step>

  <Step title="Recommendation">
    The solution generates a recommendation for the inquiry: Accept, Review, or Refuse.
  </Step>

  <Step title="Action to be applied">
    The recommendation is implemented by the API for Active rules in Active rule states:

    * Accept – Request payment
    * Review – Request payment with 3DS
    * Refuse – Set pay-in status to `FAILED`
  </Step>
</Steps>

## Events screened

In the pay-in scope, the following API requests are screened:

* Pay-ins of all types, including [pay-ins to virtual IBANs](/api-reference/virtual-accounts/external-instruction-bank-wire-payin-object)
* Recurring pay-in registrations
* Preauthorizations
* Deposit preauthorizations

<Note>
  **Note - All API requests are screened**

  All API calls from the platform are screened by the fraud prevention solution, regardless of what rules you have configured and whether the profiler is integrated.
</Note>

The API object must be successfully created to be screened, meaning it returns a 200 HTTP code, regardless of the object’s status.

Other scopes for event screening are planned in future, such as payouts.

## Actions triggered by recommendations

<Note>
  **Note - Actions only automated by Active rules in Active rule sets**

  The Mangopay API automatically applies the following actions in response to a recommendation generated by an Active rule in an Active rule set. The Simulation state does not automatically trigger action based on a recommendation. See [States](/guides/fraud-prevention/rules#states) for more information.
</Note>

For Active rules in Active rule sets, recommendations automatically trigger the following actions in the Mangopay API depending on the event:

<table>
  <thead>
    <tr>
      <th class="header">Recommendation</th>
      <th class="header">Pay-in: Card, Google Pay</th>
      <th class="header">Pay-in: Other</th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td class="table-content">**Accept**</td>
      <td class="table-content">Payment requested</td>
      <td class="table-content">Payment requested</td>
    </tr>

    <tr>
      <td class="table-content">**Review**</td>
      <td class="table-content">Payment with 3DS requested (regardless of `SecureMode` value)</td>
      <td class="table-content">Payment requested</td>
    </tr>

    <tr>
      <td class="table-content">**Refuse**</td>
      <td class="table-content">Payment not requested</td>
      <td class="table-content">Payment not requested</td>
    </tr>
  </tbody>
</table>

#### Accept

For pay-ins, the payment is requested by Mangopay from the issuer (who may still refuse the transaction as usual).

#### Review

For card pay-ins, Mangopay requests 3DS authentication from the issuer, regardless of the choice of the platform indicated by the `SecureMode` parameter. The issuer may not enforce SCA (see the [3DS](/guides/payment-methods/card/3ds.mdx) article for more information).

For non-card pay-ins, the Review recommendation has the same effect as Accept.

#### Refuse

For pay-ins, the payment is not requested from the issuer and the pay-in object `Status` is set to `FAILED` with the following error:

* [008500](/errors/codes/008500) - Transaction blocked by fraud policy

#### Other recommendations

There are other recommendations which have the following functions:

* **Overriding Accept** - Accepted regardless of the other recommendations returned (by other rules in the rule set, or by other rule sets for the inquiry).
* **Trust** - Should not be used by platforms. In future, Mangopay intends to manage 3DS exemptions using the Trust recommendation. Until then, if used, Trust would have the same effect as Accept.

In the details of an inquiry you can see the full logic that generated the final recommendation, including which sets were run to generate which recommendations (at the level of the rule set and the rules within it).

<Tip>
  **Best practice – Send a maximum of inquiry data (where possible)**

  The more data you send to the Mangopay API for an event screened, the more effective your fraud prevention rules can be.
</Tip>

## Inquiry data

The following table shows how the data points of the Mangopay API feed the fraud prevention panel displayed in the Mangopay Dashboard.

<table>
  <thead>
    <tr>
      <th class="header">Fraud prevention panel</th>
      <th class="header">Mangopay API data</th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td class="table-content">Inquiry reference, transaction reference</td>
      <td class="table-content">Transaction’s `Id`</td>
    </tr>

    <tr>
      <td class="table-content">Inquiry origin</td>
      <td class="table-content">Indicates the payment method</td>
    </tr>

    <tr>
      <td class="table-content">User reference</td>
      <td class="table-content">Transaction’s `AuthorId`</td>
    </tr>

    <tr>
      <td class="table-content">Person type</td>
      <td class="table-content">Whether a Natural or Legal user</td>
    </tr>

    <tr>
      <td class="table-content">KYC validated</td>
      <td class="table-content">True if User’s `KYCLevel` is `REGULAR`</td>
    </tr>

    <tr>
      <td class="table-content">Is blocked</td>
      <td class="table-content">True if User has either outflows or inflows blocked (see [User Regulatory Status](/api-reference/user-regulatory-status/user-regulatory-status-object))</td>
    </tr>

    <tr>
      <td class="table-content">Registration datetime</td>
      <td class="table-content">User’s `CreationDate`</td>
    </tr>

    <tr>
      <td class="table-content">Registration address</td>
      <td class="table-content">User’s `Address` (if Natural) or `HeadquartersAddress` (if Legal)</td>
    </tr>

    <tr>
      <td class="table-content">Billing address</td>
      <td class="table-content">Billing address of the pay-in</td>
    </tr>

    <tr>
      <td class="table-content">Delivery address</td>
      <td class="table-content">Shipping address of the pay-in</td>
    </tr>
  </tbody>
</table>

### Card data in inquiries

The fraud prevention solution uses a `card_token` to identify a unique physical card. This token contains:

* The first 6 digits of the card number (the BIN)
* A series of random alphanumeric characters
* The last 4 digits of the card number

The `card_token` is not itself a parameter of the Mangopay API, but it is closely related to two parameters of the [Card](/api-reference/cards/card-object) object:

* **Alias** – This contains the same 6 initial and 4 last digits of the card number, but the random characters are replaced with Xs.
* **Fingerprint** – Like the `card_token`, the `Fingerprint` identifier is unique to a physical card, meaning the same `Fingerprint` always corresponds to the same `card_token`.

## Rules

Rules let you decide the specific cases in which you want to return a given recommendation.

The rule builder gives you complete control over how recommendations should behave, and allows you to tailor, test, and simulate the impact of your fraud rules before activating them for live data.

[Learn more about rules](/guides/fraud-prevention/rules)

## Profiler

The profiler is code implemented into the platform’s app or website which monitors browser and behavioral data during a user’s session. The profiling session runs on your payment page, and the profiler enables you to monitor a vast array of data <Signal content="signals" /> which can be used when defining rules.

Once the profiler is integrated, you can create rules based on users' behavioral interactions and browsing traits, and leverage enhanced data.

You can integrate the profiler directly, or by integrating Mangopay's [Checkout SDK](/sdks/checkout) which has the profiler built in.

For more about the profiler, see:

<Card title="Profiler SDK" href="/sdks/profiler">
  Integrate the profiler on web, iOS, and Android
</Card>

For more about Checkout SDK, see:

<Card title="Checkout SDK" href="/sdks/checkout">
  Simplify your payment experience and leverage the profiler
</Card>