Managing policies in the IFP console

The console enables fraud managers to manage polices, search transactions, manage scores in the different Risk Management technologies and look at the audit trail.

Below is the login window for the IFP Console.

During first login a user will be asked to change the password according to the policy which is as follows:

• must be at least 10 characters long
• contains at least one lowercase letter [a-z]
• contains at least one uppercase letter [A-Z]
• contains at least one digit [0-9]
• contains at least one special character from the set [!@#$^&*()_-+=,.?]
• other characters are not supported
• not used recently is set to 3.

In addition to that user will be prompted to set Mobile Authentication:

This section is a quick walk through of the Policy Manager part of the IFP console. The policy manager is in the left panel.

Step 1: Defining policies

The first step is to define policies. Typically, each policy could match a given event: in the screenshot below, policy 1 is associated with a login event and policies 2 & 3 are associated with payment events. The policies are evaluated in numerical order.

Step 2: Creating the steps in the policy manager scenarios

A policy manager scenario has one or more steps. Each step is a condition and optionally can define a decision for that step if the condition is met. At the scenario level, there is optionally a default decision for the case where none of the conditions in the steps are met.

In the screenshot below, the fraud manager has defined a policy manager scenario within the “default login” policy. In this scenario, if the score returned by the Fraud Protection is below 50, the decision is to require the user to enter “OTP”.

Step 3: Creating a policy manager scenario using multiple Risk Management technologies

Let’s imagine that the eBanking or mBanking applications are configured to systematically request a password and an OTP in the case of money transfer between accounts. In the screenshot below, the fraud manager defines a scenario within the “transfer” policy. In this scenario, if the score calculated by a first partner is more than 50, and the score calculated by a second partner is high (meaning low risk), then it is possible to improve the user experience by requesting a password only.

Conversely, the fraud manager could decide that if both partners have bad scores, the transaction would be denied.

Step 4: Refining the policies and policy manager scenario thanks to context

In the example detailed in step 3, it might not be enough to make a decision based solely on an event – in this case, a fund transfer between accounts. The fraud manager could configure the scenarios to take one or more contexts into consideration:

Example 1: taking into account the “sensitivity of operation”:

• It might be wise to decline the transaction only if the context is a “highly sensitive operation” context. This context would be generated by the bank, for example, if the amount of the transaction is above a given threshold, and the transaction has been passed to OIP Risk Management to get a more finely-tuned decision.

Example 2: taking into account the “security expectation from the end user“

• Improving the user experience by requesting only a password only might make sense for some segments of end-users who are “not sensitive to security,” while it could create an impression of poor security for a segment of end-users who would be more comfortable having to provide an OTP to proceed with a fund transfer, even if the risk is actually low. Here again, using an “end-user security segment” context could enable a more accurate decision.

Step 5: Taking into account scores and flags calculated outside of OIP Risk Management

The goal here is to benefit from as many sources as possible, going beyond the engines that are embedded in OIP Risk Management to make a decision. It is very likely that the bank has already developed ways to raise flags or evaluate a score. Furthermore, the bank might already use some third parties to calculate these.

Example 1: Adding a flag related to transaction monitoring.

It is likely that the bank can estimate whether a transaction looks “usual” for a given user. In this case, such a flag could contribute to the decision of stepping down when associated with high scores for both partners.

Example 2: Adding a flag related to device fingerprinting.

In this example, the bank is already able to verify whether the device is already known thanks to powerful device fingerprinting capable of generating one or more flags or a scoring. Here again, this information can also be used to double-check the scoring of the fraud protection done within OIP Risk Management or, more simply, to contribute to making the right decision within a policy manager scenario.

Unlimited possibilities

A fraud manager may define as many policies and decisions as required. During the evaluation, the policy manager will evaluate the policies respecting the order defined by the fraud manager.