What is a policy?

A policy is defined as the combination of a scope, a set of policy manager scenarios and a default decision.

The scope of a policy is a subset of an execution context to which the policy applies. It is passed to the policy manager when calling the GET /decision endpoint. The execution context may comprise information such as user characteristics (usergroups), security attributes (level of sensitivity), and so on.

A policy manager scenario groups together a set of conditions and a decision to be used if the conditions are fulfilled. Zero, one, or many scenarios can be defined for each policy.

A decision represents a recommendation resultant of the evaluation of a policy manager scenario or policy, it can be:

• Denied: Transaction should be blocked.

• Granted with authentication method: Transaction should be allowed if user correctly presents the suggested authentication method. The following methods are supported:

  • Password: User must present a password.

  • OTP: User must present a one-time-password

  • 1FA, 2FA or 3FA: User must present a custom authentication method managed by the bank. This decision can represent any method the bank wants, for example 1FA can mean "fingerprint" for one bank while it means "secret question", "QR code scanning", or a combination of methods such as "fingerprint + OTP" for another.

• Approved immediate or review: Indicates a transaction can be immediately accepted or that it needs to be reviewed by some specialist. For example this decision could be used for “New Account” use cases, or money transfer.

A default decision is the decision that is returned at the end of the policy evaluation if no other decision has been made during the evaluation.

OIP Risk Management must always have a global policy that is used as the default if none of the other policies apply. It has an empty scope, meaning it applies to any context, can optionally contain a set of policy manager scenarios and has a default decision which is returned by the policy manager in the event that no other policy matches during the evaluation.

A fraud manager may define several additional policies as required, up to a maximum of 20. In these additional policies, the scope and set of policy manager scenarios are always defined, but the default decision is optional; if absent, the policy manager evaluates the next policy.

The schema below illustrates the relation between all these components:

The policies defined for your organisation are evaluated by calling the endpoint POST /decision of the OIP Risk Management’s API.

The body of the HTTP request comprises the complete execution context of this evaluation (including the targeted event, usergroups, level of sensitivity, and so on). When this context contains data compliant with the scope defined for a policy, then the policy is considered as matched.

The policy manager evaluates the policies in the order defined by the fraud manager. In the case where none of these policies can be matched (that is, none of their scopes match the provided context), then the global policy is applied.

When a policy matches, then its policy manager scenarios are evaluated. The policy manager scenarios within a policy are evaluated in the order defined by the fraud manager. If none of the policy manager scenarios matches then:

• If a default decision is defined, the policy’s default decision is returned.
• If no default decision is defined for that policy, the next policy in the defined order is evaluated.

When evaluating a policy manager scenario, the policy manager evaluates all its conditions. If all of them are true, then this policy manager scenario is considered as matched and its decision is returned. On the contrary, if at least one condition is not true, then the policy manager scenario is considered as not matched, and the next scenario in the policy is evaluated.

The following diagram gives an overview of the policies and policy manager scenarios structures: