Zinrelo has a rule-based anomaly detection feature for detecting anomalies that can arise from member actions, e.g., fraudulent behavior in uploading fake receipts, or non-member actions inadvertently, e.g., an admin or a POS cashier mistakenly entering wrong data or configuration.

Administrators have the flexibility to define and adjust thresholds for anomaly detection, allowing for vigilant monitoring and control over potential fraud/anomalous behavior within the program.

Rule Types

Administrators can define the thresholds for anomaly detection by setting up rules at 3 levels:

1. Program: In this case, the anomaly threshold can be set either on the total number of points earned or redeemed by the member.

2. Activity: In this case, the anomaly threshold can be set based on either the total number of points earned per activity or the total number of times a member performs an activity.

Note: You can select "any" in total activity count, if you wish to set a threshold on all of the enabled or listed activities. This will include campaign activities as well.

3. Reward: In this case, the anomaly threshold can be set based on either total number of points redeemed per reward or the total number of times a reward redeemed by a member.

Note: You can select "any" in total reward count, if you wish to set a threshold on all rewards within Zinrelo admin console. This will include campaign rewards as well.

How to configure anomaly rules?

To set anomaly rules, navigate to General >> Anomaly Rule.

1. Click the Create button to begin configuring a new rule.

2. Select the type of anomaly for which you want to configure the rule, then click Create.

3. Assign a name to the anomaly rule for easy identification and search. Specify the transactions that should trigger an anomaly alert.

4. Save the rule.
5. You can edit or delete any anomaly rule as needed.

What happens when an anomaly is detected?

1. Anomaly Listing

All detected anomalies will be displayed under the Detected Anomalies section. To access this, navigate to General >> Detected Anomalies.

Here we can have detailed information about the detected anomaly.

• Detection Date: The date on which the anomaly was detected.
• Anomaly Name: The name of the detected anomaly.
• Detected Value: All member’s transactions that were flagged as anomalies are listed here. Click on the dropdown for a detailed view.
• Threshold: The threshold set for detecting the anomaly.
• Member ID: The member ID associated with the detected anomaly.
• Anomaly Type: Specifies whether the anomaly is related to an activity, reward, or program.
• Sub-type: The activity or reward on which anomaly rules will be set. In case of program rule type, the sub-type will always be "all."
• Parameter: The parameter defined for anomaly detection.

You can filter anomalies by various criteria, such as anomaly name, date range, type, subtype, parameter, and member ID.

2. Anomaly Review

You can review all listed anomalies in the "Anomaly" section and decide whether they should be classified as anomalies. In certain cases, such as promotional activities where you expect members to reach the set threshold, you can mark these detections as "non-anomaly" or delete them.

Note: When marking a transaction as non-anomaly, providing a reason is mandatory.

3. Email Notification for detected anomaly

Email notifications for all anomalies detected in a day will be sent once daily to the email addresses of admin with full access and limited access admin having access to anomaly.

Admins can click on the hyperlinked text "here" to view a list of all detected anomalies. This will redirect them to the Zinrelo Admin Console, where they can access detailed information for each anomaly detected that day, including the detection date, detected value, and associated member ID.

📘

Please Note:

• Threshold value must be a number greater than 0.
• The anomaly rule will remain applicable for the specified duration as long as it is active. Anomaly detection will cease only when the rules are deleted.
• Only Approved Points will be summed up and compared with the anomaly threshold.
  Editing anomaly rules(either the threshold or the time period) will not do a retroactive check and re-evaluate historical transactions for anomalies. Only new transactions post the edited rule would be checked for anomalies.
• Anomaly evaluation takes a maximum of 30 minutes after a transaction is processed.
• No transactions, whether earned or redeemed, will be blocked or denied if they are detected as anomalies. The end-user experience will remain unaffected.
• Anomalies are evaluated based on all previous transactions within the set duration, but only when a member makes a new transaction. For example, if an anomaly threshold is set at 1,000 points for a 10-day period, each time a member makes a new transaction, all their transactions from the past 10 days, including the new one, will be evaluated for anomalies.
• The duration for anomaly evaluation can be set anywhere between 1 to 365 days only.