Fraud Management: Configuration
Last updated:October 23, 2026
Draft reviewReview before publishing (remove this box before publishing)
- iovation is marked internal and must not be used. The only reference is in "Device ID scans" and is marked red. Please also decide whether the three "Collect DeviceId" settings (which enable Device ID scans) may be published.
- "Enable Full RTR - v2.0" has an incomplete list item ("The Selected Transaction") in the source. It is marked inline. SME to complete.
- Tieback: the source body string had "¬e=" damaged to "¬e=" (a character-encoding error). I restored it to
¬e=nt.note. Please confirm. - Tieback host URLs and the external CSI URLs are now placeholders, because endpoints cannot be shared in the draft. In the source, the LIVE host link also pointed to the STAGE host. Please check both when you fill them in.
- Tieback guide: both sheets linked the same guide under two paths (confirmed). I use /sites/default/files/uploads/dl-0305b2c3beed.pdf only. The guide is version 1.5, dated June 2017 (last revision 2 Jan 2018). SME to confirm it is still current.
- The Integration Sheet shows the tieback body string without "¬e=" (it reads "cancelReason=po.cancelCode=nt.note"). I kept the repaired version from the Configuration Sheet. Please confirm.
- The three screenshots (two "allowed payment methods" screens and the Dynamic 3DS screen) are not shown. They are replaced by references to the Merchant Portal guide. The link
/tutorials/mp-guideis temporary and marked inline. - The tieback guide file opened without a login on the test portal, so it sits in the public folder. That is fine for a customer-facing guide, but not for the CID (see Field Mappings).
- Edits: "ACI Fraud Management" is now "Fraud Management", "OPP Field" is now "API field", typos fixed, and the introduction moved to the tutorial. UI field names (for example RIRO, OPP COPYandPAY) are kept as they appear in the product.
Full functionality has been released in production. Connectivity and functional testing have not been performed in the production environment.
This page describes the Fraud Management setup. For flows and parameters, see the integration use cases. For an introduction, see Fraud Management.
Set up the merchant account
The risk connector configuration is at Risk-Management > Risk Checks > Fraud Management > Fraud Management (RE).
For the configuration screens, including the payment methods supported for pre-payment and post-payment risk scans, see the Merchant Portal guide Temporary link: replace with the right section.
For the supported payment brands and whether each supports a pre-scan or a post-scan, see Supported payments and brands.
Configuration fields
Settings are grouped by purpose. The last column shows whether a field is mandatory, optional or conditional. Many settings do not apply when Fraud Management is used in standalone mode, that is, without a payment transaction.
When the risk check runs
| UI field name | Meaning | Comment | Mandatory / Optional / Conditional |
|---|---|---|---|
| Activate Fraud Management risk | Enables the risk check before the payment (in 3D payments, it will be triggered after 3D check is done but before the payment is done). | Default: FALSE It does not apply when used in standalone mode. | |
| Activate Fraud Management risk check after payment | Enables the risk check after the payment (both for sync and async). | Default: FALSE | |
Activate Fraud Management risk data feed (Root Only Rights ) | Enables the data feed to send all transaction data to Fraud Management after the Payment Completion. This data feed helps for the intelligence based on all the transactions patterns. | Default: FALSE It does not apply when used in standalone mode. | Covers the Transaction Types: PA, DB, CD, RV, RF, RC,CP and Finalize |
Skip Data feed if fraud screening done (Root Only Rights ) | This feature enables not to pass data feed transaction data when to Fraud scan already enabled. This feature avoids passing the duplicate data to Fraud Engine. | Default: TRUE It does not apply when used in standalone mode. | When Enabled, data feed will not be passing when already a risk scan happened for the same transaction |
| Activate for transactions with a maximal ticket size of | Defines the maximum ticket size for which the risk check will be executed. | Default: 999999999.99 It does not apply when used in standalone mode. | |
| Activate for transactions with a minimal ticket size that enables risk check (use 0.00 to disable lower limit) | Defines the minimum ticket size for which the risk check will be executed. The risk check will be executed if the ticket size is zero. | Default: 0.0 It does not apply when used in standalone mode. | |
| Allowed Payment Brands | Defines the payment brands for which the risk check will be executed before the payment. This does not apply when used in standalone mode. | Default: None All payment brands will be risk scanned. | |
| Allowed Payment Methods | Defines the payment methods for which the risk check will be executed before the payment. This does not apply when used in standalone mode. | None | |
| Allowed Payment Types | Defines the payment types for which the risk check will be executed before the payment. This does not apply when used in standalone mode. | Can be Enabled for : PA, DB, CD and RF Default: None - All of the above mentioned supports. | This Setting should enabled for RF support: Trigger Fraud Management risk check on referenced transaction (e.g. DB over DB) |
| Allowed after Payment Brands | Defines the payment brands for which the risk check will be executed after payment. This does not apply when used in standalone mode | Default: None All payment brands will be risk scanned. | |
| Allowed after Payment Methods | Defines the payment methods for which the risk scan will be executed after the payment. This does not apply when used in standalone mode | None | |
| Allowed after Payment Types | Defines the payment types for which the risk check will be executed after payment. This does not apply when used in standalone mode. | Can be Enabled for : PA,DB,CD,RC and FI Default: None - All of the above mentioned supports. | |
| Allowed Bin Data Fields for Wallet(s) | Defines the bin data fields only for wallet transactions for which the risk check will be executed | Default: bin All bin data fields | |
| Trigger Fraud Management risk check on referenced transaction (e.g. DB over DB) | When set to TRUE, it submits the referenced transactions for Fraud manager Scan. Examples: RF, PA on PA and DB on DB type to the risk check. | Default: FALSE | This setting needed to enable RF scan |
| Enable risk scan on registrations with payment | Enables the risk scan on registration with payment transactions in pre-auth mode. | Default: FALSE | |
| Enable risk scan on standalone registrations | Enables the risk scan on standalone registrations in pre-auth mode. | Default: FALSE | |
| Enable CPF Validation | Enables CPF validation of the specified parameters in the request. | Default: FALSE |
Merchant and transaction identity
| UI field name | Meaning | Comment | Mandatory / Optional / Conditional |
|---|---|---|---|
| EBT_MERCHANTID | Configure merchant ID. | None | Mandatory |
| EBT_NAME for Pre-Auth Scanning | Configure EBT name for risk check before payment. | None | Mandatory |
| EBT_NAME for Post-Auth Scanning | Configure EBT name for risk check after payment. | None | Mandatory |
| EBT_SERVICE | Configure EBT service. | None | Mandatory |
| EBT_SERVICE for Declined Payments | If the transaction was declined by the acquirer, we will send it to Fraud Management using the EBT_Service. | None | |
Select EBT_MERCHANTID Population (Configure EBT_MERCHANTID value if Merchant ID is selected) | If Entity ID option is selected, the entity id will send in EBT_MERCHANTID. Otherwise, configure the EBT_MERCHANTID value if Merchant ID is selected. | Default: Merchant ID | |
| Merchant Category Code | Configure the merchant's category code. | None | Mandatory |
| Merchant Country | Configure the merchant's country. | Default: None | |
| Merchant Postal Code | Configure the merchant's postal code. | None | Mandatory |
| Merchant Time Zone | Configure the merchant's time zone. | Default: UTC | Mandatory |
| Send selected ShortId to Fraud Management as Transaction ID | If 'Payment Transaction' is selected, the short ID of the payment transaction leg will be sent. Otherwise, the short ID of the risk transaction leg will be sent to Fraud Management as the transaction ID. | Default: Risk Transaction (RE) | |
| Transaction ID Priority | If Short ID is selected, the priority should be short ID over merchant transaction ID will be sent to Fraud Management | Default: None | |
| Map merchantTransactionId to ebUSERDATA(n) | If it is set to a number(between 1 to 100)-> merchantTransactionId will be mapped to ebUSERDATA(n) field | Default: None | Example: if the RIRO is set with number 24, then merchantTransactionId will be mapped to field ebUSERDATA24. No mapping in case ebUSERDATA field is already used for any other field or merchantTransactionId is not present in the request |
| Max cart items (Configure number of cart items allowed) | Configure maximum cart items should be allowed, we will send it to Fraud Management | Default: None (allows all cart items present in the request) |
Decisions, errors and rollback
| UI field name | Meaning | Comment | Mandatory / Optional / Conditional |
|---|---|---|---|
| Reject on challenged | Defines if the transaction will be rejected when the "challenged" response from Fraud Management occurs i.e. Fraud Manager responds with 'CHALLENGE' | Default: TRUE | |
| Reject on communication error | Defines if the transaction will be rejected when a communication error in the system occurs. | Default: FALSE | |
| Reject on system error | Defines if the transaction will be rejected when a system (internal) error occurs i.e. Fraud Manager responds with '901' (System Error from Fraud) | Default: TRUE | |
| Reject on validation error | Defines if the transaction will be rejected when a validation (internal) error occurs i.e. Fraud Manager responds with '902' (Data Format Error from Fraud) or '903' (Length Exceeds Error from Fraud) | Default: TRUE | |
| Indicate Fraud Management status challenged in payment response | Indicates the status in the payment response if the transaction will be rejected when the "challenged" response from Fraud Management occurs. | Default: FALSE It does not apply when used in standalone mode. | |
| Enable Full RTR - v2.0 | Enables full RTR, version 2.0. | Default: FALSE |
|
| Activate risk rollback for declined transactions | Enables the risk rollback request to be sent to Fraud Management when the acquirer or Fraud Management declines. | Default: FALSE It works only when "Activate Fraud Management risk" is enabled. | Note: Fraud Management Service to be enabled to support this feature. |
| Activate risk rollback for acquirer timeout or communication error | Enables the risk rollback request to be sent to Fraud Management when there is a timeout or communication error from the acquirer. | Default: FALSE It works only when "Activate risk rollback for declined transactions" is enabled. | Note: Fraud Management Service to be enabled to support this feature . |
Tieback and web cancellation
| UI field name | Meaning | Comment | Mandatory / Optional / Conditional |
|---|---|---|---|
| Activate update on Tieback notification | Enables the update on a Tieback notification. | Default: FALSE | |
| Activate Auto-Reversal on Tieback cancel notification | Executing auto reversal for a payment transaction in case a risk check notification is received with status "CANCEL". | Default: FALSE | |
| Basic Authorization credentials for Tieback | Add the API credentials for Tieback. | Format should be username:password and Base64 encoded. Example: dXNlcm5hbWU6cGFzc3dvcmQ= | |
| Username to login to Fraud Management Case Manager | Configure the username for web cancellation. | None | Conditional |
| Password to login to Fraud Management Case Manager | Configure the password required for web cancellation. | None | Conditional |
| Reason code used in cancelling challenged risk transactions through Case Manager | Configure the cancel reason code for web cancellation. | None | Conditional |
BIN detection
To get BIN detection information for Fraud Management, enable this RIRO setting:
Administration > Processing > Activate External Features > Enable extended card information based on BIN in the response
Test data
Test values for the merchant account configuration.
| UI field name | Test value set 1 |
|---|---|
| Merchant Category Code | 1212 |
| EBT_MERCHANTID | 123456123456 |
| Merchant Postal Code | 12345 |
| EBT_NAME for Pre-Auth Scanning | 000503000001 |
| EBT_NAME for Post-Auth Scanning | 000503000001 |
| EBT_SERVICE | I |
Simulate a risk recommendation (UAT only)
Using the test data above, you can simulate a risk recommendation. This works in UAT only.
| API field | Value | Risk Recommendation |
|---|---|---|
| customer.email | A@RED.COM | ACCEPT |
| C@RED.COM | CHALLENGE | |
| R@RED.COM | DENY | |
| risk.serviceId | X | 901 (System Error) |
| EBT_SERVICE (RiRo config) | ||
| Invalid Data in API Fields | 902 (Data Format Error) | |
| Huge Data in API Fields | 903 (Length Exceed Error) | |
| customParameters(SIMULATE_TIMEOUT_AFTER_SEC) | 1 to 60 | Timeout after configure Seconds |
Dynamic 3D Secure with Fraud Management
Dynamic 3D Secure lets you run 3D Secure conditionally, after the Fraud Management assessment.
When both 3D Secure and Fraud Management risk checks are enabled and Dynamic 3D Secure is disabled (the default), the Fraud Management check runs after the 3D Secure check. When Dynamic 3D Secure is enabled, the Fraud Management check runs first, and 3D Secure runs conditionally, based on the Fraud Management response and the settings below.
If the Fraud Management result is a communication error or a system error, and the check is not configured to reject the transaction in those cases (see Reject on communication error and Reject on system error), 3D Secure is executed.
How to set it up
The settings are at Risk-Management > Risk Checks > Fraud Management > Fraud Management Dynamic 3DS.
For the settings screen, see the Merchant Portal guide Temporary link: replace with the right section.
| UI field name | Meaning | Comments |
|---|---|---|
| Activate Dynamic 3D Secure | Enables the Dynamic 3D Secure (with Fraud Management) functionality. IMPORTANT! Dynamic will be enabled only when this RIRO configuration is enabled and also when all the following conditions are met:
| Default: FALSE |
| Execute 3D Secure on Fraud Management Accept response | When Dynamic 3D Secure (with Fraud Management) is enabled, always execute 3D Secure if the Fraud Management response is Accept. | Default: FALSE |
| Execute 3D Secure on Fraud Management Challenge response | When Dynamic 3D Secure (with Fraud Management) is enabled, always execute 3D Secure if the Fraud Management response is Challenge. IMPORTANT! The Risk-Management > Risk Checks > Fraud Management > Fraud Management (RE) > Reject on challenged is still taken into consideration. This means that if 'Reject on challenged' is set to TRUE, all challenged transactions will be rejected. | Default: FALSE |
| Execute 3D Secure when Fraud Management RCF code contains "3DS" | When Dynamic 3D Secure (with Fraud Management) is enabled, execute 3D Secure if the RCF field from the Fraud Management response contains the "3DS" code. | Default: FALSE |
Execute 3D Secure on Fraud Management Accept response and Execute 3D Secure on Fraud Management Challenge response take priority over Execute 3D Secure when Fraud Management RCF code contains "3DS" if both are enabled.
Fraud Management tieback
The Secure eCommerce Gateway can consume tieback notifications sent by the Fraud Management Case Manager Portal (CSI). This applies to all transactions that Fraud Management flags as "Challenged" and that are available for review in CSI.
The integration provides:
- a status update for the risk transaction,
- a webhook notification to the merchant on each status update, and
- auto-reversal or auto-refund for the "Approve on Challenge" model.
To configure tieback notifications in CSI, see the Tieback configuration guide (PDF) Guide version 1.5, June 2017: confirm it is current..
Settings to configure in CSI
Host URLs
Placeholder PH-30Endpoint: tieback host URL, STAGE
Insert the STAGE host URL for tieback notifications as a code block. Remove this box.
Placeholder PH-31Endpoint: tieback host URL, LIVE
Insert the LIVE host URL for tieback notifications as a code block. Remove this box.
External CSI URL
The link to a transaction in CSI. The payment ID is a variable part of the path.
Placeholder PH-32Endpoint: external CSI URL, STAGE
Insert the STAGE CSI link, with the payment ID as a variable. Remove this box.
Placeholder PH-33Endpoint: external CSI URL, LIVE
Insert the LIVE CSI link, with the payment ID as a variable. Remove this box.
Header
Enter the same password you configured in Basic Authorization credentials for Tieback.
Authorization: Basic {password}Body
Add this string:
riskOrderId=om.oid&merchantTransactionId=om.transactionId&risk.channelId=om.txMerchant.number&reviewAction=po.status&reviewAction=qo.status&cancelReason=po.cancelCode¬e=nt.note&reviewActionTimeStamp=po.processedDatetime&reviewActionTimeStamp=qo.queuedDateTime&userId=po.processByUser&userId=qo.processByUserFor the flows, see Tieback in the integration use cases.
Fraud Management web cancellation
To auto-cancel transactions in the Fraud Management Case Manager (CSI), configure these settings at Risk Management > Risk Checks > Fraud Management Configuration > Fraud Management risk check (RE):
- Activate Fraud Management risk check
- Username to login to Fraud Management Case Manager
- Password to login to Fraud Management Case Manager
- Reason code used in cancelling challenged risk transactions through Case Manager
Device ID scans
Device ID captures the browser fingerprint to identify the shopper. These settings enable Device ID scans at the Fraud Engine. They must also be enabled in the Fraud Engine set-up and rules.
| UI field name | Meaning | Comment | Mandatory / Optional / Conditional |
|---|---|---|---|
| Collect DeviceId in mSDK | Device Id is used to capture the browser fingerprint to uniquely identify the shopper through the mobile app.
Note: These features should be also enabled at Fraud Engine Set-Up and Rules | Default: FALSE | |
| Collect DeviceId in Multi-Domain Recognition | Device Id is used to capture the browser fingerprint to uniquely identify the shopper and share the information with a third-party domain.
Note: These features should be also enabled at Fraud Engine Set-Up and Rules | Default: FALSE | |
| Collect DeviceId in OPP COPYandPAY | Device Id is used to capture the browser fingerprint to uniquely identify the shopper.
Note: These features should be also enabled at Fraud Engine Set-Up and Rules | Default: FALSE |
Not for publicationInternal. Do not publish.
Refer to more details at Fraud Management Device Id for OPP COPYandPAY (iovation).
iovation is internal and must not be used. Keep this reference in the draft, and remove it from the final document.