In complex problem-solving environments such as loan origination, tax compliance, portfolio balancing or insurance underwriting, the interaction logic frequently cannot be predefined in advance and is dynamic by its nature. Below we will describe several real-world interaction scenarios: 

       Scenario 1: Loan Approval Decisions

       Scenario 2: Tax Return Compliance for Partnerships

       Scenario 3: Maintenance of User Profiles for Portfolio Balancing

       Scenario 4: Identifying Suspicious Groups of Airplane Passengers

While new facts in these scenarios can come from different sources, an effective interactive system should be able to request new information based in part on the new facts and in part on already known related facts. But what does it mean “related facts”? Where are they defined and how can we initiate a new information request?
 
Why Dynamic Interaction Processes?

If your applications are highly interactive, you may wonder:

• How will a business rules approach help me to define intelligent dialogs with complex web-based forms?

• Will a new system be able to construct dynamic interaction processes on the fly using interaction history and information already available from an existing system?

You want your business specialists to be able to easily modify different web forms without learning multiple GUI development techniques usually oriented to experienced software developers. And most importantly, you need reliable proven tools and methodology to redefine and maintain the frequently changing business and presentation logic of your complex interaction processes. Take a look how OpenRules addresses these problems.

 Example "Loan Dynamics"                                                                                            (Presentation)          (Solution)

Scenario 1: Loan Approval Decisions
This is a real-world business scenario where a bank manager has to make a loan approval decision by analyzing different securities related to the initial loan request:
 

Events and Facts	Loan Application Decision	Comments
Peter Johnson applied for $50K loan	Rejected	Insufficient Income. But a loan officer noticed that they have a valuable client with the same address
Joe & Dawn Johnson agreed to be Peter's guarantors. They have a Housing Loan with Available Equity of $300K and Remaining Debt of $150K	Accepted	$100K surplus is a sound proposition. But conducting more detailed analysis, the officer noticed a joint borrowing on Mt. Johnson's file which is not with his wife
Joe Johnson and his partner Bill Smith (50/50) have a Business Loan for $200K with Available equity of $52K	Accepted	The remaining $26K surplus still meets requirements. But Bill and Susan Smith have other facilities outstanding against their property as well as the business loan
Bill & Susan Smith have a Housing Loan with Available Equity of $240K and Remaining Debt of $150K	Accepted	Still a surplus. But a lending clerk noticed a secured personal loan in the name of Tommy Smith for $50K secured by his parents
Their son Tommy Smith has $50K loan secured by his parents	Rejected	Accumulated remaining equity is less than the requested loan amount. The initial debt to Peter Johnson would be $8.8K short on cover

This scenario was initially proposed by Cameron Powell. The first rules-based solution was presented by Jacob Feldman at BRForum's in 2003. To solve business problems like this, humans and machines should make an accept/reject decision based on the joint performance of tasks. New facts about the loan related securities can come from a human or a 3rd party system. An effective interactive system should be able to play a devil advocate requesting new information trying to scrutinize already made accept/reject decisions.  

See this presentation that demonstrates how this scenario can be implemented using OpenRules state machines within a pub/sub architecture.

Click "Solution" to see how this scenario can be implemented using OpenRules business rules and OpenRules forms facilities.

More Examples of Dynamic Interactive Processes

Scenario 2: Tax Return Compliance for Partnerships

• Tax compliance becomes extremely complicated when it has to consider a possible revenue and expenses distribution among multiple related corporations (partnerships including foreign ones) 
• The main problem here is how to generate the proper data requests, receive the related data, and then validate the accumulated information to be compliant with the current regulations 
• Again we deal with a question of how to define and maintain the “related data”, which is dynamic in nature and can not be saved in a database

Scenario 3: Maintenance of User Profiles for Portfolio Balancing

• While a customer may define preferences related to his/her investment strategy (conservative or moderate risk level, industry sectors, security type distributions, etc.) the dynamic nature of the constantly changing financial market requires permanent automatic and interactive adjustments to each customer’s profile  
• The system should be able to generate questions like: ”Your positions are overly concentrated in a single security. Are you willing to relax position constraints?” and make an automatic decision in each case based on a customer’s preferences and the company’s current strategy

Scenario 4: Identifying Suspicious Groups of Airplane Passengers

• A system validates a list of all passengers when they book tickets for air travel. Along with simple criteria such as:

  • age range, gender, country of origin, legal status, etc.

• The system may include dynamic characteristics such as:

  • acquired certain chemical products in certain quantities
  • took certain classes at a certain educational institutions in a certain time period
  • visited certain countries during the last 2 years, etc.
• Dynamic attributes need to be validated not just for one passenger but also for all possible combinations of currently known passengers. The very fact that a passenger satisfies a certain criterion, may initiate a new request about other passengers, that can in turn initiate additional new requests or can reconsider already known facts

 What do all these scenarios have in common?

• They all deal with the joint performance of tasks by humans and machines:  

  • with the dynamic structure of these communications
  • when the interaction logic can not be predefined and depends on the interaction history and the related available information about involved objects
  • with the necessity to support multiple data information requests, algorithms and programming interfaces  

• We have to deal with situations when not all concepts/relationships are known in advance and new concepts/ relationships could be added as we go.

To address these problems, OpenRules goes beyond traditional BRMS covering not only business logic but also the presentation logic. OpenRules proposes a generic methodology and supporting software tools for the design and maintenance of dynamic Web applications. These tools are based on commonly used Excel and Eclipse allowing non-technical analysts to become active participants of the Web development and support processes.