What is a policy, How to use a policy, How to create a policy-Fraud Detection(Fraud Detection)-阿里云帮助中心

This topic describes how to create a default policy.

Background information

What is a policy? A policy is a set of orchestrated calculation logic. When the decision engine receives an event data request, it evaluates the request against your configured policies. If a policy's conditions are met, the system returns the policy's result.
Use cases: You can configure a policy to evaluate complex logical rules. For example, in a credit loan approval scenario, you might need to screen for high-risk applicants. You can create a policy that flags an applicant as high-risk if their phone number, email address, or account ID appears on a blocklist.

Basic policy information

Note

You must create an event before you can configure a policy. For details, see Create an Event.

Navigate to the Policy Management page and click Create Policy.
Configure the policy's basic parameters, such as its name and description.
Select an Associated Event, and enter a Policy Name and Policy Description.
Important
Variables are linked to their associated event. You cannot change the associated event after submitting the policy. This prevents misconfigurations that could disable variables and disrupt policy calculations.

Calculation logic

The following terms and settings are used on the policy calculation logic configuration page:

Condition Name: This field is optional. We recommend entering a descriptive name to clarify the policy logic in the visualization preview.
Left variable: You can select an event field, device variable, custom variable, system variable, or intermediate variable. For event fields, you can also select a function to apply to the field.
Operator: Select an operator to evaluate the left variable. The system displays available operators based on the left variable's data type. For example, if the left variable is a string, operators for numerical comparison (such as greater than or less than) are unavailable.
Right variable: After selecting the left variable and operator, you can enter a constant or select another variable as the right variable.

Note

Event fields support function-based calculations. For example, to convert an email address to lowercase, you can select the event field for the email address and then apply the lowercase conversion function.
To configure multiple conditions, click Add Calculation Logic. You can also copy an existing condition to quickly create a similar one.

Calculation logic preview

Basic elements. You can orchestrate the calculation logic by combining condition ordinal numbers (such as 1, 2, 3) with logical symbols such as |, &, and parentheses ( ).
- | indicates a logical OR.
- & indicates a logical AND.
- ! indicates a logical NOT.
- Use ( ) to set operator precedence.
Visualization preview. After orchestrating the logic, click View Rules Tree to see a real-time preview. The system reads the number and name of each condition and displays them in the preview. Named conditions are displayed by name, while unnamed ones are shown by number.
For example, if the first three conditions are named, but the fourth condition is unnamed and uses a NOT operation, the preview appears as follows:

Policy output

The policy output is what the decision engine returns when a policy's conditions are met. Supported outputs include tags, scores, intermediate variables, and output variables.

Output tags: Use easy-to-understand values, such as highRisk or pass. Separate multiple tags with commas (,). If multiple policies for the same event share a tag, the system deduplicates the tag in the final output.
Output score: The score must be an integer from -1000 to 1000. When a policy's conditions are met, its score is added to the event score. The event score is the sum of the scores from all triggered policies for that event.
Output intermediate variables: An intermediate variable is a temporary variable used during policy evaluation. When a policy is triggered, it calculates or outputs its defined intermediate variables. Other policies for the same event can then use these variables.
Output variables: In addition to scores and tags, you can define custom output variables, such as event input parameters or intermediate variables. When a policy's conditions are met, these custom variables are included in the response.
Event-specific actions: When a policy is triggered, the system executes a predefined action, such as accumulating a variable. To use this feature, select an action and configure its mapping parameters. The action then runs automatically, enabling real-time risk control.
Output decision result: From the drop-down list, you can select REJECT, PENDING, PASS, or leave the field blank. Configuring this field adds the finalDecision field to the API response.
Note
If multiple policies that output a decision result are triggered, the final output is determined by priority: REJECT > PENDING > PASS.

Policy publishing and verification

A policy can have one of several statuses: Draft, Trial Run, or Official Run. To minimize risk from misconfiguration, we recommend first using the Trial Run status to monitor the policy's behavior before promoting it to Official Run. The following table describes the different policy statuses.

Policy status	Save	Execute	Output
Draft	√	×	×
Trial Run	√	√	×
Official Run	√	√	√

After you configure a policy, you must publish it. Follow these steps:

Change status: By default, a new policy is saved in the Draft status. Click Run or Trial Run to change the policy status.
Activation: After the policy status is changed, the policy takes effect within two minutes.

Verify results: After creating the event, connecting its data, and creating the policy, verify the policy output to ensure the configuration matches your risk control design. You can test with OpenAPI to verify the event and policy results.