> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.mangopay.com/guides/fraud-prevention/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.mangopay.com/_mcp/server.
# Fraud prevention
## Docs
- [Rules](https://docs.mangopay.com/guides/fraud-prevention/rules.md): Build high-precision rules based on your exact needs and leverage the power of Mangopay’s fraud prevention solution.
> **Note:** This page contains both a page directory (above) and the landing page content (below). The page directory is generated for agent use and does not appear on the landing page.
> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.mangopay.com/guides/fraud-prevention/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.mangopay.com/_mcp/server.
# Overview
## 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:
#### Profiling session (optional)
Optionally, the profiler runs a profiling session to collect data (if integrated).
#### Event to be screened
A user proceeds to checkout and makes a payment on your app or website.
#### Pay-in request
Your server requests a pay-in (and includes the `ProfilingAttemptReference` if applicable).
#### Inquiry
Your pay-in request triggers an inquiry, which is a request to screen the pay-in event.
#### Rule sets
The fraud prevention solution runs your custom rules and Mangopay's default rules.
#### Recommendation
The solution generates a recommendation for the inquiry: Accept, Review, or Refuse.
#### 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`
## 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
* Extended 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.
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.
For Active rules in Active rule sets, recommendations automatically trigger the following actions in the Mangopay API depending on the event:
|
**Accept**
|
Payment requested
|
Payment requested
|
|
**Review**
|
Payment with 3DS requested (regardless of
`SecureMode`
value)
|
Payment requested
|
|
**Refuse**
|
Payment not requested
|
Payment not requested
|
#### 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) 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).
> **Check**
>
> **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.
## Inquiry data
The following table shows how the data points of the Mangopay API feed the fraud prevention panel displayed in the Mangopay Dashboard.
|
Inquiry reference, transaction reference
|
Transaction’s
`Id`
|
|
Inquiry origin
|
Indicates the payment method
|
|
User reference
|
Transaction’s
`AuthorId`
|
|
Person type
|
Whether a Natural or Legal user
|
|
KYC validated
|
True if User’s
`KYCLevel`
is
`REGULAR`
|
|
Is blocked
|
True if User has either outflows or inflows blocked (see
[Regulatory Status object](/api-reference/user-regulatory-status/regulatory-status-object)
)
|
|
Registration datetime
|
User’s
`CreationDate`
|
|
Registration address
|
User’s
`Address`
(if Natural) or
`HeadquartersAddress`
(if Legal)
|
|
Billing address
|
Billing address of the pay-in
|
|
Delivery address
|
Shipping address of the pay-in
|
### 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
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:
#### [Profiler SDK](/sdks/profiler)
Integrate the profiler on web, iOS, and Android
For more about Checkout SDK, see:
#### [Checkout SDK](/sdks/checkout)
Simplify your payment experience and leverage the profiler