DecisionRules model situation — Product Offer (Part 1)
Tags: Banking, Bank, Discount, Ruleengine, Rule

We will bring you a series of articles to show how to use DecisionRules in a real environment for real situations. In this article, we are going to operate in a corporate financial world.

Photo by Dmitry Demidko on Unsplash.

Intro

DecisionRules can be used for solving several different tasks typical for financial or insurance institutions. In our case, we will focus on a general retail bank where one of the primary goals is to offer an appropriate product at the right time to the right client. In this particular example, we will use DecisionRules to solve it.

What is product offer?

We consider the product offer being a part of a broader process called the product life cycle. First off we need to create products static definition, the product structure, labels, general attributes, set prices, etc. Once the product definition is ready, we need to deliver it to the customer. That is where the product offer comes into the picture. It is a container — an offer facility or vehicle that helps deliver simple or structured products, as singletons or combined into various product bundles to the relevant clients. Not only What but also How matters, hence we usually intend to deliver the new products to the client via various communication channels (Internet Banking, Mobile Banking, a banker communicating thru Branch Front-End system, etc.).

In this paper, we have confined our scope to offer the general discounting schemes applied to an underlying product which in our particular case will be an essential Personal Current Accounts (PCA).

The problem

Let’s take any bank which is in your country and name it YourBank. One of the products YourBank has to offer is a Personal Current Account (PCA). Most of us have at least one, but we have more in one or more banks in many cases. What does a personal account offer to us? Many of its (sub)products like — bank account, debit card, smart banking, online banking. You can also have a credit card, etc.

For the sake of our example we consider YourBank has 3 types of these PCAs:

Personal Current Account White (PCAW)

Personal Current Account Green (PCAG)

Personal Current Account Red (PCAR)

You can imagine that these accounts consist of different combinations of (sub)products based on the client's preference. Different combinations also lead to the different prices of individual PCA types.

For better understanding, we can choose Personal Current Account White (PCAW) which consists of (sub)products with its price (just an example):

5 ATM withdrawals — 1 USD

4 international wire transactions 2 USD

credit card monthly fee — 3 USD

If we count it up, we get 6 USD, which will be our monthly fee for PCAW.

To make YourBank personal current accounts more competitive, product managers come up with colorful marketing campaigns that translate to a set of discounting schemes applying to individual product types (PCAW, PCAG, PCAR) under certain circumstances. These discounting schemes (under certain generalization can be viewed as sub(products)) modify the price of an underlying PCA. To distinguish which discounting scheme can be offered, when, and if at all, is the issue at hand.

Solution

First, we define the term Current Client Position (CCP) — a client contract, if you will, a set of product instances that the respective client currently possesses. At this stage, we represent CCP as a flat list abstracting from its potentially complex hierarchy. CCP is a decision rule INPUT.

Next, we assume an OUTPUT in terms of a set of eligible discounting schemes returned to the calling system and ultimately displayed to the client.

Basic architecture model of communication

The architecture model shows the basic flow of how the decision is made. On the Front End, which can be an internal banking system, smart banking, or internet banking, we have the CCP information (based on a back-end call) constituting a set of product instances the client currently possesses. We send this set to a DecisionRules through API call. It then executes the respective rules and returns the Eligible Product Offer (which means products that the client qualifies for) to the Front End.

We define quite arbitrarily, for the sake of this example, three different categories of the discounting schemes with the following behavior:

Acquisition Discount Scheme (DSA) — to attract new customers by adjusting the price of the PCA at the beginning of the contract — typically linked to a public marketing campaign. Retention Discount Scheme (DSR) allows the bank to retain customers as part of the retention process. Individual Discount Scheme (DSI) — any other individually-based price modification.

We go for a simple representation of eligibility matrix represented in DecisionRules.io as: