After I posted my recent article on Exceptions, the Decision Management Community brought my attention to a challenge they posted a year ago, that refers to mitigation rules overriding the actual policy. This is a slightly different perspective on exceptions. I thought that it would be interesting to illustrate how I would solve that challenge.
Here is the definition of the challenge:
Decision Model: “Borrowing PASS/FAIL Decision with Mitigation Criteria“
Rule # 1:
New Borrowings cannot exceed 30% of Total Assets.
If the executive committee flag is set to “Y” and the executive committee exposure override is set to a percentage higher than the new borrowings/total assets ratio then PASS
Rule # 2:
New Borrowings cannot exceed 1-4 Threshold.
The new borrowings is less than the non-repo collateral available for the customer
Customer #200: ABC Bank
Total Assets = 20,000,000
Executive Committee Flag = “Y”
Executive Committee Exposure Override = 35%
1-4 Threshold = 1,000,000
Non-Repo Collateral = 2,500,000
Customer #500: Bank One
Total Assets = 50,000,000
Executive Committee Flag = “N”
Executive Committee Exposure Override = 0%
1-4 Threshold = 3,000,000
Non-Repo Collateral = 3,250,000
The Sparkling Logic SMARTS solution
First, I would start with data. As part of a brand new project, I can define the data structure — which we call the form, and start filling up the test cases. As I will create the business rules, the data will be updated real-time to reflect the actions commanded by the business rules.
I decided to store all the test data in a Customer section, and I created a Request section for the new borrowings requested, as well as the decision computed by the business rules.
You may notice that I created a calculation to reflect the New Borrowings to Total Assets ratio. While I could have calculated it in the business rule, having a calculation in place allows me to reuse it consistently, and to see what value it actually holds.
The next step is to start capturing the business rules. I sequenced the 2 rulesets as 2 separate decision steps in a decision flow to illustrate the multi-step process. The links check for current status, assuming that one failure would be sufficient to interrupt the decision process, and decline the request. Alternatively, you could have all business rules being evaluated to list all the red flags. You could obviously proceed either way.
The heatmap on each activity indicates how the test cases flow through the various branches. Apparently, I created 2 test cases that end up being declined, and 2 that are actually approved.
The first business rule states that the new borrowing cannot exceed 30% of the total assets. Since we have a calculation for the ratio, I just need to check that the ratio is below 30. The mitigation rule might override this rule if there is an executive committee flag, provided that the ratio remains below the set exposure override.
In this snapshot, we have overlaid the core business rule on top of the data to help us understand how it works. It says that if the ratio is greater than 30, which is not correct since it is only 7.5, then we should fail the request. Since the request is not flagged, the default decision is to PASS, which takes us to the next test on 1-4 Threshold.
For this other test case, you can see that the core business rule is triggered, which is indicated by the green ball. Indeed, the new borrowings exceed the 1-4 threshold. The mitigation rule applies though, since it is still below the non-repo collateral. The final decision is to accept this request.
By drag-and-dropping the field of interest in the dashboard, you can see the distribution of decision for the 4 test cases I created: 2 have been approved, and 2 have been declined. Any input field, output field, or calculation can be added in the dashboard for an aggregate view of the data.
Feel free to contact us if you would like to a demonstration of this project.