Oracle Payments supports risk management functionality. Electronic commerce applications can incorporate this feature and detect fraudulent payments. The following information describes how electronic commerce applications can utilize the risk management functionality of Oracle Payments.
Oracle Payments is bundled with a set of risk factors. Payees can configure these factors depending on their business model. The payees can create multiple formulas using different factors and weights depending on their specific requirements. The ability to create multiple formulas provides flexibility to payees to accommodate different business scenarios. Each formula must be set up so that the sum of the weights is equal to 100. If a risk factor value is missing at the time of risk evaluation, the risk for the missing factor is considered very high in the formula.
Oracle Payments also defines an implicit formula for each payee with default factors and weights. Administrators have the flexibility to modify the implicit formula. The following information describes how and where the implicit formula is used.
The following describes the process flow of risk evaluation.
To enable risk analysis during authorization, set up the explicit risk flag in the input transaction object or check the Enabled radio button in the Risk Management Status screen for that payee.
When an electronic commerce application makes a Payment Request API call, Oracle Payments first checks the risk flag and depending on its value, decides if the payee involved in the payment request is risk enabled or not. If the risk analysis field indicates that Oracle Payments should perform risk analysis, or if a default value is added in the field and a payee is risk enabled, Oracle Payments evaluates either the risk formula passed in the Payment Request API or the implicit formula associated with that payee.
Electronic commerce application can pass a specific risk formula name by calling the overloaded Payment Request API. This API takes PmtRiskInfo object in which electronic commerce application can set up the formula name and additional information. If PmtRiskInfo object is not passed and the payee is risk enabled, Oracle Payments evaluates the implicit formula of that payee.
Oracle Payments returns the Risk Response (RiskResp) object as part of the payment response. If risk evaluation is done successfully, Risk Response object contains the risk score obtained after evaluation and the threshold value that is set up with the payee. Based on the risk score and the threshold value, the electronic commerce application can decide whether a payment can be accepted or not.
If the risk score is more than the threshold value, the payment request is risky.
Risk API 1
When an electronic commerce application invokes Risk API 1, Oracle Payments evaluates the risk formula sent in the request or the implicit formula associated with that payee.
Oracle Payments evaluates all the risk factors that are configured as part of this formula, except the AVS Code risk factor.
After evaluation, Oracle Payments returns Risk response (RiskResp) object as a response to this API. This response object contains, the status of the API call, AVSCodeFlag indicating if AVS Code risk factor was part of the formula or not, risk score, and the risk threshold value that is setup for the payee. Depending on the AVSCodeFlag value, it is be decided whether to call Risk API 2 or not.
Note: Partial risk score is returned if AVS Code risk factor is part of the risk formula.
Risk API 2
Electronic commerce applications need to call this API with the same PayeeID and formula name that were used to call Risk API 1. The risk score that was returned as part of the Risk API 1 response also needs to be sent. When electronic commerce applications call this API, Oracle Payments checks again if the formula has AVS Code risk factor configured in it or not. If it is configured, Oracle Payments evaluates the AVS Code risk factor.
After evaluating the AVS Code risk factor, Oracle Payments calculates the final risk score of the formula using the previous risk score that was sent and the AVS Code risk factor score. This risk score is sent back to the electronic commerce application as part of the response object of this API.
The following are three business scenarios that describe how a merchant can use the Risk Management functionality.
In a small business, accepting risky instruments is a critical factor. If a customer is using a stolen credit card, the merchant should consider this transaction risky and assign this risk factor a higher weight than the other risk factors. Ship to/bill to address matching and payment history are also important risk factors. To include AVS Code risk factor, a merchant can set up a formula with weights as shown in Weight B column in the Risk Formula Setup-First Case table. The total of all the weights should be 100. For a formula that a merchant would set up in this case, see Risk Formula Setup for the First Case.
The table below shows the risk formula setup for a merchant selling books and low priced goods.
| Factors | Weight A | Weight B |
|---|---|---|
| Risky Instruments | 30 | 30 |
| Payment Amount Limit | 15 | 15 |
| Transaction Amount | 15 | 15 |
| Ship to/Bill to | 20 | 10 |
| Payment History | 20 | 10 |
| AVS Code | 0 | 20 |
Payment Amount Limit
The table below shows the risk levels and the associated payment amounts.
| Risk Levels | Greater than or Equal To |
|---|---|
| Low | 0 |
| Low medium | 100 |
| Medium | 200 |
| Medium high | 300 |
| High | 400 |
Transaction Amount
A transaction is high risk if the transaction amount exceeds 500 in one week. Otherwise there is no risk.
Payment History
The table below shows the risk levels and the number of payments made in the last six months by a particular customer.
| Risk Levels | Greater than or Equal To |
|---|---|
| Low | 6 |
| Low medium | 4 |
| Medium | 3 |
| Medium high | 2 |
| High | 0 |
AVS Code
The table below shows the risk levels and the associated AVS Codes. AVS Code risk factor evaluation is useful only for customers in the United States.
| Risk Level | AVS Code |
|---|---|
| No risk | S,Y,U,X,R,E |
| Low | A,Z,W |
| Low medium | |
| Medium | |
| Medium high | |
| High | N |
Ship To/bill To and Risky Instruments
These risk factors do not require any setup. The evaluation will be done with the data already existing in the database.
Risk Score
A typical threshold value would be between medium and medium high risk score. Risk Management module evaluates the payment request and returns an overall risk score. If an overall risk score exceeds the threshold value set up by the merchant, then the merchant has to decide whether to process the request or to block the request.
Risky instruments is a critical factor in this case. If a customer is using a stolen credit card, the merchant should consider this transaction risky and assign it a higher weight.
Frequency of purchase is the next important risk factor. Usually customers do not buy electronic goods frequently, and if they do, the purchases could be a fraudulent.
In this scenario, time of purchase is also should be considered as an important risk factor. If someone buys many goods after 2:00 AM, it might be a fraudulent purchase.
To include an AVS Code risk factor, a merchant can sets up a formula with weights as shown in column Weight B in Risk Formula Setup-Second Case table. The total of all the weights are 100. The AVS Code risk factor evaluation will be useful only for customers in the United States.
The table below shows the risk formula set up for a merchant selling electronic goods.
| Factor | Weight A | Weight B |
|---|---|---|
| Risky Instruments | 30 | 30 |
| Ship to/Bill to | 15 | 12 |
| Time of Purchase | 15 | 12 |
| Frequency of Purchase | 20 | 10 |
| Payment Amount | 10 | 8 |
| Transaction Amount Limit | 10 | 8 |
| AVS Code | 0 | 20 |
Payment Amount Limit
The table below shows the risk levels and the associated payment amounts.
| Risk Levels | Greater Than or Equal To |
|---|---|
| Low | 500 |
| Low medium | 1000 |
| Medium | 1500 |
| Medium high | 2000 |
| High | 2500 |
Transaction Amount
This risk factor is considered high risk if the amount exceeds 2,500 in one week. Otherwise there is no risk.
Frequency of Purchase
This risk factor is considered high risk if the frequency of purchase exceeds ten times in the previous one week.
AVS Codes
The table below shows the risk levels and the associated AVS codes. AVS codes risk factor evaluation is only useful for customers in the United States.
| Risk Level | AVS Code (Comma Separated) |
|---|---|
| No risk | S, Y, U, X, R, E |
| Low | A,Z,W |
| Low medium | |
| Medium | |
| Medium high | |
| High | N |
Ship To/Bill To and Risky Instruments
These risk factors do not require any setup. The evaluation is done through the data already existing in the database.
Risk Score
A typical threshold value is to be between medium and medium high risk score.
The risk management module evaluates the payment request and returns an overall risk score. If an overall risk score exceeds the threshold value set up by the merchant, the merchant has to decide whether to process the request or to block the request.
In a business to business scenario, a merchant has an established relationship with his customer. In this scenario, the Oracle Receivables risk factors take higher precedence. The merchant is interested in the customer's payment history, his credit rating, etc. All Oracle Receivables risk factors are set up through Oracle Receivables interface.
The table below shows a Risk Formula setup for a business to business customer.
| Factors | Weight |
|---|---|
| Overall Credit Limit | 30 |
| Transaction Credit Limit | 30 |
| Risk Codes | 15 |
| Credit Rating Codes | 15 |
| Payment History | 10 |
Overall Credit Limit: 100,000
Transaction Credit Limit: 50,000
Risk Codes are set up through Oracle Receivables codes.
The table below shows the risk codes and the associated risk scores set up through Oracle Payments administration user interface.
| Risk Codes | Risk Score |
|---|---|
| Low | Low |
| Average | Medium |
| Excellent | No risk |
Credit Rating Codes are set up through Oracle Receivables interface
The table below shows the set up of credit rating codes and the associated risk scores.
| Credit Rating Codes | Risk Score |
|---|---|
| Low | Low |
| Average | Medium |
| Poor | High |
| Excellent | No risk |
Risk Score
A typical threshold value is between medium and medium high.
Risk management module evaluates the payment request and returns an overall risk score. If an overall risk score exceeds the threshold value set up by the merchant, then the merchant decides whether to process or block the request.