.png)
Commissions play a pivotal role in various industries, especially in the financial sector. In this article, we dive into the practical implementation of commission management and calculation using DecisionRules.io. In the first part, we'll explore the layers of the commission calculation model, rule variables, activation management, and input/output models. In the second one, we will look into examples of concrete rules, integration of DecisionRules with external systems, and Reporting of Commissions.
.png)
Commissions are typically recalculated once a month as a basis for employee payouts. But with DecisionRules, you can do these calculations at any time during the month at the team or individual broker level to increase their motivation.
The solution must be able to calculate three different commission models. To define this complex behavior on one hand and simplify the integration on the other, we have implemented hierarchical rule structure.
.png)
Rule Calculate Commissions is designed to evaluate all the applicable rules for a bulk input, meaning the input contains all of the accounts and/or deals of a broker. However, it is always possible to evaluate any rule in isolation if it is required or easier for implementation.
The rule has an input property commissionType which determines the type of commission that will be calculated, so for any subset of these commissions the input can remain the same.
This rule is not intended to be changed, unless the model is changed significantly, such as when another type of commission would be added. If the structure of commissions stays the same and rules are only removed or added, then only the input schema would change to reflect the structure of your input data.
This layer organizes the rules into individual commission models. There are three tables, each for one commission model. Each table contains a list of all active commission rule ids. Only the current rules in these tables will be evaluated.
The table for Merit commissions also contains a column, where an exclusivity group can be set. This feature enables more of the rules to be defined for one case. All of the rules of this exclusivity group are evaluated at the same time and only the highest commissioned one will be awarded. This creates an option to design multiple tiers of Merit commissions.
The last layer contains the actual logic for evaluating the commissions. These rules are called from the orchestrating script Calculate Commissions. But there is also the possibility of evaluating all of them separately should the need arise.
All of the commissions have a separate rule where their logic is stored, therefore any rule can be modified independently.
We expect that the number of rules will increase. IT might be beneficial for a business user that can see the opportunity to unleash his/her creativity. For an application administrator this could quickly become a headache. That is why we have introduced some techniques for keeping the number of rules at a manageable level.
For each rule, we can define a rule variable that proves useful when a single value is utilized in multiple sections of an algorithm, or when there's a need to easily modify significant attributes like the commission amount.
A good example can be a commission percentage used as part of a condition in rule Sales commission - Loan Sale as described above. Using a variable, we can change it at the same time reducing the chance of a potential error.
The rule variables can also be used in the same way as if they were a part of the input.
As described above ( Model structure - 2nd layer ), only the rules present in the List tables are evaluated. That provides the possibility of easily managing active commissions; all the admin has to do to deactivate a commission rule is to switch its record off in this table.
It is also possible to set an activation time for a particular rule, which gives an option to create time limited promotions or vary the commission settings based on season.
Input data is structured around the broker. All information for the commission processing is sent in a single batch and also the commissions for individual brokers are evaluated in one go. The data structure is created as an array so it is possible to process different types of commissions for a single broker, one type of commission for multiple brokers or any other combination.
The input structure is set in the I/O Model of the main rule - Calculate Commissions. The input is divided into three parts:
The CommissionType property is mandatory in the commission processing. The content of the Deals and Consultant properties is variable and depends on the rule and parameters significant for the business logic of the commission. |
|
While the input structure has some mandatory components and many optional parameters that vary by the commission model, the output structure will be always the same:
|
|
Each rule may have a different set of inputs to evaluate, and so the input structure is variable. If we take a look at an example of the sales commission SC_LOAN, it’s input model looks like the one in image no.1
The output of every commission rule has the same structure to make the final output uniform and simple to integrate. You can see the output model in image no.2
Let’s have a look at rules in the 3rd layer which defines the business logic of individual commissions. Every commission model has its specifics just as every product class has the same.
For each example we will describe the input data needed, the logic and parameters set and also output of the rule.
While input structures will often vary depending on the type of commission model, the output will be essentially the same. All of the rules we have intended to present can be easily set in a simple form of tree structure so there is no need for programming skills. This might be useful for organizations where the IT resources are very sparse. Please bear in mind that as for any other IT tool it is strongly recommended to involve an application administrator in the process of new rule development.
Sale commission of a loan in our case is calculated from three basic inputs:
There might be several other parameters to calculate the commission, but we have decided to use a simple rule.
For the ease of maintainability there are also two rule variables defined. One defines the percentage values for the commission rate, which is used to calculate the payout of the commission, and the other, specifies the minimum ratio of the disbursed amount.
This rule is constructed in the form of a decision tree and its implementation takes the following form:
There is only one condition which checks whether or not the number of clients exceeds the predefined threshold.
We use the ARRAY_FILTER function to filter out any account where the newClient property is not true, then we COUNT these entries and we check if the count is greater than or equal to the threshold value defined in the rule variables as ACC_COUNT_THRESHOLD.
If the condition has been met, then the commission value is set to a predefined value (in our case 30.000) and the awarded property is set to true.
If the condition is not met, then the value of the commission is set to 0, the awarded property is set to false and there is a message generated under the reasoning that says “Not enough new clients” with the number of new clients that the broker has achieved.
DecisionRules integrates through Restful API (documentation). For the purposes of our case study, we would leverage the bulk processing of larger data sets. On top of that, there is also the possibility to call a single rule for one deal only. That could come in handy in situations where a broker needs to validate the amount of commission for a deal he/she intends to make.
Communication with the DecisionRules dealing with larger data volumes invokes leveraging a middleware solution to facilitate seamless communication between the DecisionRules and the data source. This intermediary tool will manage data transmission, ensuring a secure and efficient exchange of information and maintaining data integrity.
The response from the API call contains a predefined output structure described above in detail. After processing in the middleware component, it can be used as a source for further business processes to approve the commissions and payment.
In order to test the solution, we can use the tool https://www.postman.com/ to mimic the middleware, visualize the response received and prove working logic inside the DecisionRules.io.
A call from a postman application can look like this.
… and the response from Sales commission rule:
Business owners will need a set of reports that will provide information about the sum of the commission to be paid and also detailed information about a single case to be able to decide possible complaints.
Power BI will be our weapon of choice.
DecisionRules.io is able to store detailed information about every single rule processing including the input data and the calculated output. This kind of data will be stored in the form of Audit logs. These logs can be then retrieved through the API and processed for reporting in Power BI. Find out more about the Audit logs from our documentation: link
In our example, the rule logs some basic information about the broker along with all the data used in rule evaluation, commission amount, name and type of the commission, the date when the commission was awarded and basic anonymous information about the account or client.
In this article, we have described how the commission models are implemented in the DecisionRules and we have described broadly how the model functions and the way to evaluate it. We have also tackled the reporting of commission results.
We mentioned that DecisionRules.io is not a single tool that will solve every aspect of the commission process, but could be the critical one that will contain and manage the precious knowhow.
In the next and last part of this series we will go into deeper detail for the implementation in DecisionRules.io so you can try if for yourself and experiment with various commission models.
