How to Introduce The Decision Model Using a Real-World Compliance Example

(Practical Advice from a Certified Decision Modeler)

Adoption of The Decision Model (TDM) is growing and includes major corporations, such as those in the financial industry. As a result, decision models based on TDM are operating in production worldwide on behalf of critical business transactions and some with huge transaction volumes.

This means there are organizations and people with several years of TDM experience. However, there are also people and organizations interested in TDM and contemplating how to get started. This article provides insights by which business analysts can plant the seed for TDM.

As business analysts, you are the “people in the middle.” You sit between business experts and technology experts. You fill the gap for both sides, understanding business concerns and technology solutions. This puts you in a unique position from which to introduce TDM and its benefits to different audiences.

A previous article [1] described a presentation for introducing The Decision Model to a management audience. It recommends that your presentation be a visual TDM story targeted at your organization’s specific needs, rather than describing general examples. Since TDM is new to the audience, they will see the benefits much quicker if explained using a familiar business problem, requirement, or challenge. That article then uses a general fictitious case study as an example.

Below Rupak Rajaram (Certified Decision Modeler) takes the ideas in that article further in five ways.

1. Rather than a fictitious case study, he walks through a specific real-world regulatory compliance requirement: Know Your Customer (KYC).
2. He includes a Rule Family to illustrate use of TDM for data quality [2].
3. He introduces a decision model for computing risk score.
4. He gives an example of the notion of Decision Model Views which may be extremely useful to some audiences.
5. He provides advice for doing so when you have a limited amount of time to prepare and present (such as a 1-hour presentation), which is often the case.

Rupak’s step-by-step procedure for “rapid TDM introduction” has 6 steps. When introducing TDM, you can produce the TDM deliverables in MS/Visio and MS/Excel templates [3].

Step 1: Know Your Audience

Start by identifying the target audience and how they benefit from TDM. Expect the audience to know nothing about TDM and that your objective is to spark short-term willingness to try it.

There are likely different audiences and they fall roughly into three categories: (1) pure business, (2) business analysts and requirements analysts, and (3) enterprise architects and developers.

Example: KYC Audience

For KYC, let’s assume your primary audience is mostly on the business side. So the focus is on the benefits of TDM without software concerns, such as:

• Simplified process model
• Visual organized diagram of business logic
• Simple Rule Family tables, easy to validate
• Business, not technical, vocabulary
• Natural fit with agile principles and
• Well-suited for complexity and changing compliance mandates.

However, your audience may also include the technical side. When this is so, you can add TDM benefits that would be of interest to them even in the absence of TDM software. These benefits are that TDM is:

• Amenable to prototyping (e.g., visualization using iRise, etc.)
• Sufficiently structured to serve code generation or creation
• Easily mapped to data sources
• Easily automated in various target technologies, especially BRMS.

Step 2: Know Your Business

Even in a short presentation, aim to create immediate visual awe, something they can relate to and get excited about.

For this, an ideal business example may be an internal project having difficulties with business logic in a specific area. Another impactful example may be a regulatory compliance requirement whose source is publically available and therefore is somewhat familiar to the audience. This is especially meaningful if it is complex, changes often, ambiguous, expensive to automate, and if efforts-to-date have missed the mark.

Example: KYC Business Case

The KYC due diligence framework in the investment banking space has a wide audience: Wealth Management, Sales and Trading, and Anti Money Laundering. KYC is an interesting example for four reasons:

1. KYC requirements are provided in documentation publically available, a primary source being the USA Patriot Act [4].
2. KYC documentation can be ambiguous. Financial institutions interpret and tailor the KYC requirements, producing a policy guide and KYC remediation checklist. These documents plus SME support provide insight into the logic needed to build KYC decision models.
3. Financial institutions spend tremendous amounts of money developing their AML programs which include KYC. “Citigroup Inc., the third-biggest U.S. bank, said the finance industry could spend as much as $10 billion annually in coming years to combat money laundering” [5].
4. Despite these efforts, AML regulatory enforcement actions have levied billions of fines for financial institutions, much for KYC. Some of these approach or exceed $2.0 billion dollars for a single Financial Institution. [6]

Figure 1 illustrates the progression from business source documents, such as regulation, to the creation of TDM and related models. So, the next step is to create an appropriate process model.

Figure 1: From Business Documentation to Corresponding Models

Step 3: Design a Decision-Aware Process Model

A decision-aware process model is the business doorway to TDM. It simply is a process model “that is designed to distinguish between tasks that perform work (i.e., process tasks) and tasks that come to conclusions based on business logic (i.e., decision tasks). This separation enables the details behind a decision task (i.e., business logic) to be represented in a different kind of model, specific to business logic” [7].

Example: KYC Decision-Aware Process Model Example

Figure 2 is a sample decision-aware process model for KYC. It has three decision tasks indicated by the presence of octagons on the task shape. One decision task determines client type [8], another determines client acceptability, and another determines whether a client is eligible for simplified due diligence evaluation. Behind each decision task is a decision model for that decision. Let’s look closer at the decisions.

Figure 2: Decision-Aware Partial Process Model for KYC

Step 4: Identify Decisions

A decision (aka business decision) is a conclusion of interest to the business arrived at through business logic (i.e., set of conditions leading to a conclusion). Decisions are discovered in Step 3 during the creation of the process model. In Step 4, more information is gathered and presented about each decision in preparation for selecting one of them for a decision model.

Example: KYC Decision Example

While Figure 2 exposed three decisions, more detailed process models and communications with SMEs uncovered five as listed in below:.

• Core Data Acceptability: Do we have the minimum client data required to begin analysis? (Completeness, etc.)
• Client Acceptability: Is our client acceptable, or are there glaring red flags immediately?
• Simplified Due Diligence Eligibility: Due to the presence of verified characteristics, is our client eligible for a basic/cursory due diligence check?
• Enhanced Due Diligence Data Acceptability: If simplified due diligence is not appropriate, do we have all the information necessary for a more in-depth analysis? (Completeness, Domain Validity)
• Composite Risk Score: What is my client’s overall weighted risk rating?

Step 5: Design a Rule Family

In this step, the goal is to explain the parts of a Rule Family, using business logic of the business example. A Rule Family is a two-dimensional representation of business logic conforming to TDM normal form: columns, rows, each row representing one business logic statement, all such statements in a Rule Family reach a conclusion about a common piece of information (called a fact type).

Example: KYC Rule Families

One common use of TDM is to validate acceptable quality of input data. Quality of data is measured in various dimensions, including completeness (i.e., is all required information available) and domain validity (i.e., are values provided within the allowable value set) [9].
Figure 3 is a Rule Family that does so. In particular, based on the widely-used KYC “questionnaire” construct in Wealth Management, this Rule Family contains logic to determine if the personal information of declared principals or others is sufficiently complete to be used to reach a TDM conclusion, specifically are all required fields populated?

Figure 3: Rule Family Concluding Quality of Input Data

Such a simple, but relevant Rule Family is an excellent basis for explaining to the audience the properties of Rule Families in TDM, with emphasis on TDM’s Principles. In Figure, because non-empty columns in a Rule Family are connected with ANDs, row 1 indicates that if all four named fields are populated, the data is deemed to be sufficiently complete. Rows 2 through 5 conclude that if one of those fields is not populated, the data is incomplete

Figure 4 is an example of another Rule Family. This one is not for testing quality of input data, but for assigning a risk rating based on product. For example, row 1 concludes that, if Product Citation Type is either Criminal Subpoena or Enforcement Action then the Product Regulatory Risk Rating is assigned a value of 3.

Figure 4: Rule Family for Business Logic for Risk Rating Based on Product

Step 6: Design a Decision Model Diagram

Once the audience understands Rule Family basics, they are ready to learn about the resulting decision model diagram that pulls them all together into a holistic and manageable deliverable.

A decision model diagram “depicts only TDM’s structure and not the detailed content of its Rule Families. It begins with an octagon shape that represents the entire business decision. The other shapes in the Decision Model Diagram represent Rule Families and their connections” [10]. Rule Family connections emerge naturally wherever a conclusion of one Rule Family is a condition in another.

Example: KYC Decision Model Diagram

KYC risk rating is based on 8 criteria. In a full decision model effort, each may best be its own decision model. For a demonstration, it is sufficient to collapse them into one decision.

From your own list of possible decision model diagrams, (1) identify a calculation-based, complex conclusion within KYC (or your target compliance requirement) (2) determine the most salient categories which determine its conclusion and (3) build a decision model diagram from it in a top-down modeling manner.

Figure 5 is a decision model diagram for a set of categories. Because a client’s composite risk score is a weighted average of risk groups, the conclusion of the Decision Rule Family (i.e., the top Rule Family) is an unconditional formula, therefore always calculated in the same manner. As such, this Rule Family has no conditions and its conclusion is simply the calculation formula. The formula uses the results of each of the 8 logic branches under the Decision Rule Family. [11]

Your diagram will be deliberately incomplete. Specifically, this one has “stubs” which are the three left-most branches with no supporting Rule Families. The stubs serve as placeholders for the remainder of the logic. An incomplete decision model diagram is sufficient for a high level, intuitive explanation while also exhibiting support for agile development approaches.

For the technical audience, it is often valuable to refer to an entire decision model structure, such as the one in Figure 5 as a holistic “callable decision asset”.

Figure 5: Decision Model (Structural) Diagram for Client Risk Score

Advanced TDM Topic

A sophisticated aspect of TDM, not covered in the book [12], is the use of views which may be extremely valuable to your audience.

Essentially, views are decision models for the same named conclusion but with different underlying logic. An example in KYC is Client Risk Score if there is one set of logic (i.e., calculation) for determining Client Risk Score for a person and another for doing so for a business entity. Both decision models have the same conclusion fact type of Client Risk Score, but each specifies different logic and calculation. Figure 6 ontains two views for Composite Risk Score, one for a business entity and one for individual along with the ability to visually compare them.

Figure 6: Decision Model Structures for Two Different Views

The view capability is useful in many other situations, such as different views of a decision model by state, for example.

Due to time limitations in preparation and presentation, there are inherent challenges to be aware of with a “rapid” TDM presentation:

• The deliverables are not intended to show a complete decision model or process models, but merely illustrate the relationships.
• The process models are deliberately high level and devoid of technical considerations (such as data structures, etc.).
• The next step after your introduction presentation is to seek a pilot project for TDM.

Business analysts can play an important part in leading the way to TDM. The steps and advice in this article are a good and proven way to get started.

Authors:

Rupak Rajaram is a Senior Analyst with Sapiens DECISION. He has been involved in multiple Decision modeling client engagements and is a Certified DECISION Model Practitioner. Prior to Sapiens, Mr. Rajaram’s was an AVP at Merrill Lynch. He holds a Bachelor of Science in Engineering from the University of Michigan. He can be reached at [email protected].

References:

1. http://www.modernanalyst.com/Resources/Articles/tabid/115/articleType/ArticleView/articleId/2516/How-to-Introduce-The-Decision-Model-Successfully.aspx

2. Some people use the phrase “data acceptance” rather than “data quality” when referencing decision models that determine whether input data is of sufficient quality. The distinction is that a “data acceptance” decision model measures the quality of input data as to whether it is acceptable for subsequent decision model usage; not whether it is acceptable for all uses across an enterprise.

3. This article illustrates deliverables using the Sapiens DECISION product, but MS/Excel and MS/Office TDM templates are downloadable for free at http://www.kpiusa.com/index.php/category/2-templates.html

4. http://www.gpo.gov/fdsys/pkg/PLAW-107publ56/pdf/PLAW-107publ56.pdf

5. http://canadianinstitute.com/blog/index.php/tag/citigroup/

6. http://www.bankersonline.com/security/bsapenaltylist.html

7. von Halle and Goldberg, The Decision Model: A Business Logic Framework Linking Business and Technology, © 2009 Auerbach Publications/Taylor & Francis, LLC.

8. This article uses the words “client” and “customer” interchangeably.

9. A previous article addressed some ideas on data quality dimensions (http://www.modernanalyst.com/Resources/Articles/tabid/115/articleType/ArticleView/articleId/1761/Better-Faster-Cheaper-Part-II-The-Decision-Model-Meets-Data-Quality-Head-On.aspx)

10. The Decision Model book uses the phrase “Decision Model Diagram” to mean the structural representation compliant with TDM principles. Sapiens’ DECISION uses the phrase “Decision Model View” to mean Decision Model Diagram.

11. In software, portions of the model can be linked to the policy document for traceability.

12. Von Halle, Barbara and Larry Goldberg, Ibid.