How Fraud Management works in a payment
Last updated:October 23, 2026
Draft reviewReview before publishing (remove this box before publishing)
- This page is written only from the Configuration Sheet and the flow diagrams. Please have the SME confirm the wording of each concept.
- Meaning of the NOSCORE response is not defined in the sources, so it is only mentioned where the diagrams show it.
When you combine Fraud Management with a payment, the Secure eCommerce Gateway calls Fraud Management at defined points of the payment and acts on its decision. This page explains those points and decisions. For parameters, flow diagrams and settings, see the integration guide.
Two legs
A payment can be screened twice. Each screening is called a leg.
| First leg (pre-authorization) | Second leg (post-authorization) | |
|---|---|---|
| When | Before the payment goes to the acquirer. In 3D Secure payments it runs after the 3D check, unless Dynamic 3D Secure is on. | After the payment, for both synchronous and asynchronous payments. It carries the result of the payment. |
| Enabled by | "Activate Fraud Management risk" | "Activate Fraud Management risk check after payment" |
| Payment types | PA, DB, CD and RF | PA, DB, CD, RC and FI |
The second leg gives Fraud Management the acquirer response, CVV result and AVS result, so it can take the real outcome of each payment into account.
Decisions
Fraud Management answers with ACCEPT, CHALLENGE or DENY. The gateway then decides what happens to the payment, based on your settings:
| Situation | Setting | Default | Result |
|---|---|---|---|
| Fraud Management returns CHALLENGE | Reject on challenged | TRUE | The payment is rejected. With FALSE, the payment continues to the acquirer. |
| Communication error | Reject on communication error | FALSE | The payment is rejected only if set to TRUE. |
| System error (response 901) | Reject on system error | TRUE | The payment is rejected. |
| Validation error (response 902 or 903) | Reject on validation error | TRUE | The payment is rejected. |
Challenged transactions can be reviewed by an analyst. See Review and tieback.
RTR versions and Full RTR 2.0
Fraud Management Direct supports three RTR (real-time risk) versions: v1.0 (Critical Path), v1.5 (rollback) and v2.0 (Full RTR). You switch between the old and the new implementation with a setting.
With "Enable Full RTR - v2.0", the second leg is also sent when the payment never reaches the bank, for example when a challenge or deny stops it. Fraud Management therefore sees both legs of every transaction, and the gateway returns the second-leg details to the merchant in the response.
Dynamic 3D Secure
By default, when 3D Secure and Fraud Management are both enabled, the Fraud Management check runs after the 3D Secure check. With Dynamic 3D Secure, the order is reversed: Fraud Management is checked first, and 3D Secure runs only when your settings say so, based on the Fraud Management response.
If Fraud Management returns a communication or system error and your settings do not reject the payment, 3D Secure is executed.
Rollback
If the payment does not complete after the first leg, a rollback tells Fraud Management that the transaction did not go through. The gateway sends it when the payment is declined by the acquirer or by 3D Secure, when the acquirer times out or returns a communication error, or when a deny or challenge rejects the payment. The gateway does not process the response to a rollback.
Review and tieback
Transactions flagged as challenged are available for review in the Fraud Management Case Manager (CSI). When an analyst decides, CSI sends a tieback notification to the gateway, which:
- updates the status of the risk transaction,
- sends a webhook notification to the merchant, and
- optionally reverses or refunds the payment automatically, for the "Approve on Challenge" model, when the review ends in a cancel.