Interesting report by Henry Peyret of Forrester on A Business Rules Engine Decreases The Cost Of Fraud Detection. The system he describes is a classic use of a non-inferencing rules engine but I want to make a couple of points of clarification:
- Most business rules leaders, including Fair Isaac, allow for both inferencing and sequential execution. Depending on the rule scenario one or the other runs faster. There is some discussion of when you need inferencing here and here (as well as Wikipedia) and a description of what the newest versions of Rete (Rete III) can do here.
- Sequential execution is always going to be faster in terms of rules evaluated. It spends no time figuring out which rules to fire and so fires more. This works great unless you need to find a small number of rules to execute amongst a very large number of potential rules in which case inferencing will be better. This is why good rules products allow for both.
-
We have clocked Blaze Advisor, using a real case study from a Fortune 100 company, at 3,543,424 rules per second per CPU or over 6.5M predicate evaluations per CPU per second. Per second. 10M exchanges per hour would be easy. If we assume 30 rule execution per transaction (implied in the paper) then this is 300M rules per hour
or 5M rules per minute or less than 100,000 rules per second.
And remember that Blaze Advisor does its code generation under the covers so you could change the rules in the production system using a web-based rule maintenance application and not have to do any kind of re-generation/re-compile step. This avoids the problem Henry notes of making it hard to re-deploy changes. - As Henry also notes not all rules lend themselves to trees (or tables for that matter). That's why good products like Blaze Advisor and JRules allow for multiple representations.
AML and other kinds of simple fraud detection are great for rules. Even if you have more complex fraud, requiring analytics, rules are still a crucial component in a solution.
