Create Rule

Creating and setting up rules helps maintain security over the transaction process. These rules allow you to define specific conditions and criteria that must be met for transactions to be considered executed.

Access Rules

1 Navigate to Workspace, and click on Rules.

2 Click on the + CREATE RULE button.

3 Provide a unique name and click on the CREATE button.

4 You will be taken to the created rule, in order to manage your transaction rules, click on ADD RULE, the available list of rules will be displayed in the drop-down.

5 You can add and manage rules based on the specific requirements.

Manage Transaction Rules

Here are the available rules:

Note that, if multiple workflow modules are configured, and if one rule fails, It will proceed to the next workflow module.

METADATA

With the METADATA rule, you can configure various types of information with specified values based on the user metadata provided in the API request body. This information can relate to any aspect of user identity, such as; role, age, gender etc.

For example, if the rule specifies that a user must be above a certain age to initiate a transaction, and the provided age does not meet this requirement, the user might be denied or the transaction process might be skipped.

Note that multiple METADATA properties can be included within a single rule.

Name	Functions
METADATA PROPERTY	The metadata property serves as a key, and the value linked to this key, which is provided in the user metadata within the API request body, will be used for evaluation. For example, if the metadata key is "age" and the value provided is 25, this value will be considered when checking if the user meets the specified criteria for the verification process.
PROPERTY TYPE	There are four types, string: Used for textual data like usernames, email addresses, gender, and other identifiers. Should be enclosed in double quotes. int: Used for numerical data that does not require decimals, such as user IDs, age, and counts. boolean: Used for binary conditions like active/inactive status, success/failure, and conditions in control flow statements. double: Used for numerical data that requires decimals, such as financial figures, measurements, and percentages.
CONDITION	This condition determines how the expected value should be checked against the value provided by the user. Following are the conditions, equals: The provided value should be equal to the expected value. not equals: The provided value should not be equal to the expected value. greater than: The provided value should be greater than the expected value. greater than equal: The provided value should be greater than or equal to the expected value. lower than: The provided value should be less than the expected value. lower than equal: The provided value should be less than or equal to the expected value. contains: The provided value should contain the expected value. startswith: The provided value should start with the expected value. endswith: The provided value should end with the expected value.
EXPECTED VALUE	Provide the value that should be satisfied for the particular property. This expected value will be checked against the value provided by the user.

CHANGE IP HISTORY

This rule restricts a user's attempt to verify their identity based on their IP address. If the current IP address is different from the last few IP addresses used in previous verification attempts, the verification process will be blocked.

Specify the rule value with the number of previous verifications to check for IP changes.

WEBHOOK

This rule allows you to add a hook URL, to which the rule will send a POST request containing specific details such as the verification request details, user details and workspace details.

If the received response code is 200, the rule evaluation will return true, allowing the transaction process to proceed. Any other response code will result in a false evaluation, causing the transaction process to be denied or skipped.

NOT IN IP RANGE

The IP Range allows the specification of either an IPV4 range or a single IPV4 address. The rule outcome will be affirmative if the requested IP address is outside the defined IP range.

Accepted rule value formats include: 192.0.0.0 to 192.0.0.10, 192.0.0.0, or a list like 192.0.0.1; 192.0.0.2

IP WHITELISTING

This rule ensures that a user can only initiate the verifiaction process from an allowed IP address.

You can update by adding whitelist IP addresses separated by semicolons (;).

Rule Decision Strategies

Note that, when multiple rules are added, the Rule Decision Strategies option will be enabled.

Name	Functions
Unanimous	This is the default strategy, whereas in the absence of any provided strategy, all rules must yield a positive evaluation for the final decision to be considered positive.
Affirmative	In this scenario, for the final decision to be considered positive, it is required that at least one rule evaluate to a positive decision.