Fraud check alert

Your business can maintain a list of known fraudulent IP addresses, or a list of customers that have placed fraudulent orders in the past. Orders must be validated by specific fraud checks at order capture time, and fraud analysts must be notified of the failures. The fraud check mechanisms are very specific to business needs and practices. Because of this, the application provides a general framework for fraud checks.

Solution

The following section describes APIs, user exits, services, and other components.

All orders are placed on the YCD_FRAUD_CHECK hold upon order creation or draft order confirmation. This hold prevents any transaction from processing the order and is processed by the Fraud Check agent. The Fraud check agent is derived from the Process Order Hold Type base transaction.

The Fraud Check agent calls the YFSProcessOrderHoldTypeUE user exit, which is implemented as the YCD_ProcessCustOrdMgmtHolds_1.0 service. In this case, the processFraudCheckHold custom API is called, which in turn calls the checkFraudOnOrder API, which finally calls the YCDProcessFraudCheckOnOrderUE user exit.

The user exit takes the following file as its input XML:

<INSTALL_DIR>/repository/xapi/template/merged/userexit/processOrderFraudCheck.0001.xml

If the user exit returns a message to the agent that indicates possible fraud, the ON_FRAUDULENT_ORDER event is raised, and the YCDFraudCheckAlert_1.0 service is invoked through the YCDOnFraudulentOrder action.

The YCD_FraudCheckAlert_1.0 service sends an alert to the Fraud Queue, which is monitored by the Fraud Analyst user.

Implementation

To use this feature, do the following steps:

Ensure that the YCD_FRAUD_CHECK hold type is implemented for the enterprise that does the fraud checks. Do the following steps to implement a Fraud Check hold type.
1. Launch Applications Manager -> Distributed Order Management, and load the enterprise that does the fraud checks.
2. Go to Distributed Order Management -> <Document Specific> -> <Document Type> -> Fulfillment -> Hold Types.
3. Click the Create icon to create the fraud check hold type with the following details:
  - In the Hold Type field, enter YCD_FRAUD_CHECK.
  - In the Hold Creation tab, select the following options:
    - On Draft Order Confirmation
    - On Order Creation
  - In the Hold Resolution tab, select Fraud Check On Order as the time triggered transaction that will process the created holds.
  - In the Hold Effects tab, you can specify the transactions that will be stopped from processing orders on this hold. Additionally, you can specify the modifications that are not allowed for orders on this hold.
4. Click Save. The hold type is saved.
Note: The attributes mentioned in the procedure are important. Additionally, you can specify other attributes for the hold type based on your business needs.
In the YCD_FraudCheckAlert_1.0 service, the alert sent to the Fraud Check queue uses the following XSL by default: <INSTALL_DIR>/repository/xapi/template/merged/exception_console/YCD_FraudCheckAlert.xsl.sample
This XSL must be copied to a file named YCD_FraudCheckAlert.xsl, customized as needed, and its path and name must be specified in the Template Name field of the Alert properties.

You can save it to another directory, but using the standard directory structure that is supplied by the Sterling™ Order Management System Software helps ensure consistency.

All of these services as well as the user exits can be customized as needed to fit your business needs.

The YCDProcessFraudCheckOnOrderUE user exit must return the response code of the fraud check in the FraudCheckResponseCode attribute, at the Order element level. This attribute value must be 'FAILED' if the fraud check failed and 'SUCCESS' if the fraud check succeeded. Additionally, a FraudCheckResponseMessage element must be returned under the Order element.

For more information about the user exits and APIs, see the Javadoc.

End-user impact

The user can prevent order-related fraudulent activities.