TomDebevoise.com

Answer: when it is a function (Code Sample Included (See Link at End))

Many credit risk (and security) applications use a ’scoring’ approach to modeling risk. For instance in a Basel II Advanced IRB approach, the probability of default can be computed using a weight-adjusted set of objective and subjective factors. For real estate financing, objective factors may for example include the debt service coverage ratio (DSCR) and the loan-to-value. Subjective factors in the set might include the quality and experience of management. These factors are combined in a ’scorecard’ to estimate the probability of default (PD). We often see these scorecards in the form of Excel spread sheets. If you are experienced in business rules, you might assume that a scorecard like this would merely translate into a series of decision tables. The Innovations approach to modeling these is more nuanced.

In our modeling experiences with security, financial or credit risk rating, we use often use decision tables. For instance, we use a decision table to assign the standard BASEL-II risk weight-categories. In the business rules approach, a decision table is a concise way to decide a proposition. Decision tables assign one or more values to parameters based on conditions in the table. Some business rules engines, such as OpenRules or Corticon, drive the majority of their logic from decision tables. I maintain that over-use of decision tables complicates your model. Also, overreliance on the decision tables might result in an incorrect solution.

For instance, a decision table might group a range of numeric values into different groups Consider the FICO  estimates for credit card charge-off from this recent Fair Isaac Publication on page 3*. A range selection decision table might look like:

Yet, unless your application needs crude estimates of the charge-off rate, this approach might not be very good. Another approach would be to develop a ’strait-line’ interpolation of the values.  You can do this by creating an expression in the decision table. A portion of this table might look something like this:

To me, this looks pretty complicated. If you change the FICO scores, you will need a lot of testing to make certain the intervals are properly computed.

Either decision table approach has significant errors. If your application is used by credit or loan underwriters, then one of the simple tables above will suffice. If your application is computing the financial risk for a large portfolio, you will want to avoid the errors inherent in the decision tables. You might consider using a more interpolation accurate method such as Newton’s divided difference. The divided difference approach is basically an extension of the ’strait-line’ interpolation. In strait line interpolation, we use the first derivative (the rise over run) to compute the value. In divided difference we compute the higher derivatives and apply them to the computation. The following graph summarizes the differences:

The simple decision table will yield a single value with a range of errors. The strait line decision table improves the estimated value. The divided difference approach offers the least error for this.

Here are a few sample values as computed by the three approaches: 

FICO	Range Table	Strait Line	Divided Difference
612	3.100	3.484	3.098
635	2.200	1.968	2.350
655	1.500	1.232	1.160

 The errors with the decision approach can be very significant, depending on your application’s needs. The divided difference offers more accuracy and simplicity.

In Visual Rules it is a relatively simple matter to build a divided algorithm. You can build dynamically allocated arrays and manipulate them with visual shapes for looping interators and expressions. A fragment of the visual solution is viewable by clicking on the thumbnail below:

The other choice is to code this into java. There is a pretty good solution here; however, a visual solution to this simple algorithm offers obvious benefits:

• You do not need to declare variables and functional structures, the solution is more direct
• You do not need to know Java or C++ to solve, test and debug your algorithm
• The solution is more compact and it is simpler for others to maintain the visual solutionq

Certainly, decision tables are a simple way to develop and model decisions. Yet, they should be used appropriately. For example, consider the following decision table:

A risk rating evaluation of credit would allocate a portion of the ‘management experience’, a subjective factor to the overall risk. Certainally, most decision tables have more than one parameter; however the decision table is properly used in this contect. 

I have included an export of this visual rules project divideddifferance. (Right click on the link and save the project archive on your hard drive) You will need the most current version (4.4) of Visual Rules. You can download this here. As always, if you need help with this please drop me a line.

*These values were ‘guestimated’ from the FI report and should not be used in any application.

Thanks to Christopher Hansert of Innovations Software Technology, for help with this post!