Achieving Regulatory Compliance with Decision Management

The 2008 financial crisis affected each of us in some manner. In particular, financial institutions and banks felt most of the heat. There were several repercussions of this crisis in the form of increased regulations and various legislation in an effort to curtail such an occurrence in the future. The aim of such regulations is to maintain confidence in the financial system, to increase financial stability, to protect consumers at some level and to reduce financial irregularities.

Since financial institutions now live in a climate of increased compliance and regulation, there has been an increase of consulting firms – both technical and advisory – in providing specialized services to help these institutions implement regulatory compliance so that these institutions can focus on their business while complying with these ever changing regulations.

It would be futile to jump into a solution of how this can be achieved without understanding what regulatory compliance means. Compliance means conforming to a rule which can be a policy, standard or law. Regulatory Compliance describes the goal that companies aspire to achieve in order to comply with relevant laws and regulations.

Where do business rules fit in the picture?
Business rules are by definition a statement that describes the policies or constraints of an organization. Since compliance requires conforming to a policy in general, business rules fit the perfect picture as a placeholder of such policies. This is for various reasons. First, rules are repeatable and tractable to automation. Second, rules are transparent and easily traceable. This makes for increased visibility of the policies which are to be complied with. Business rules implemented with IBM’s Operational Decision Management software can be exported to a word or excel document, and even be emailed to an organization’s legal department in the format they are written. Third, rules can be changed easily with zero down time to make the change to production. This helps organizations cope with an ever-changing regulatory environment and allow them to focus on its business rather than inviting preseason resources keeping up with a changing regulatory environment.

How can regulatory compliance be achieved by Operational Decision Management (ODM)?
The best way to describe ODM’s capabilities for regulatory compliance would be to take existing compliance policies that firms have to constantly deal with, and propose an implementation using ODM. We take one of the most challenging regulations that was recently (2010) enacted by the 111th US Congress – it is the Foreign Account Tax Compliance Act or more popularly known as FATCA. The act aims to tackle tax evasion by US Citizens to tax havens or strong data protection countries like Switzerland. Foreign financial institutions like banks, insurance firms and fund houses are affected by FATCA and need to comply with FATCA regulations. Individuals with US nationality, US address or phone number and corporations with substantial US ownership are affected by this legislation. Complying with FATCA became so complex and necessary at the same time that IBM has offered a specialized FATCA solution in their offerings.

One of the challenges FATCA brings is the amount of information it requires an organization to process which especially creates a hassle to the organization’s technology platform. There are three different impacts to the technology platform with FATCA – customer classification, transaction monitoring and finally IRS reporting.

In our business case example, let us study customer classification. In order to comply with FATCA, financial organizations have to collect a W-9 form from all account holders who are US Persons. This is clearly business logic which can take an ugly and complex turn when implemented in application code. The solution: WebSphere Operational Decision Management (ODM). The above business logic can be copied word to word and represented in the form of a business rule. It can be created in what is called a rule designer. This is how the same business logic looks like when written in ODM as a business rule:

The above business rule can be exported as-is to what is called the decision center which is the special portal that business users have access to with the ODM suite of products. Decision Center gives immense visibility to the rules across an organization. Major stakeholders can log in to this portal and view the contents of critical decision tables or business rules. Returning to our scenario above, the same FATCA rule when deployed to the decision center, can be edited by business users by click of a button. Clicking on the “Edit” link below, the rule can be easily modified by a non-technical user:

Any changes to these business rules in general can be directly deployed to production environment, through the decision center portal. Obviously, there are various recommended governance strategies that provide checks and balances along with regression testing, so that incorrect information is not pushed to production servers. Nevertheless, the capability to change an existing policy (or a decision table) is available with ODM.

Conclusion

Regulations are here to stay and the sooner organizations adapt to implement compliance with these regulations, the better they will become for their competition. In our example for FATCA we just saw how ODM can be leveraged to implement changes at a lightning pace. There is much more that can be achieved with ODM, this just gives a small glimpse of what your organization can look forward to when selecting ODM as a solution to meet your organization’s compliance.

Akshat Srivastava is a Senior ODM Consultant at Prolifics with about 7 years of experience in the IT industry having worked in insurance, banking, retail and public sector companies. He is experienced in all aspects of the development life cycle, including bottom-up estimates, analysis, design, development, testing, release management, and bug-fixing. He has created rule based solutions at various clients, authored rule repositories and best practice documents while focusing on WebSphere Operational Decision Management as the implementation environment. He has also created BPM applications for client onboarding for leading financial institutions. Akshat holds a bachelor’s degree in computer science from California State University.

Testing Philosophy in ODM: Feasibility of Complete Rule Testing in Decision Validation Services (DVS)

Software testing is an important step in the software development life cycle. IBM Operational decision Management (ODM) is not an exception. Testing in ODM is done through Decision Validation Services (DVS). It automatically generates an excel sheet with specified input fields from the Execution Object Model (XOM).  To run a test you need to fill out the excel sheet with test cases and expected outputs. Each row would represent a test case. In this article I would like to discuss the feasibility of running a complete (or close to complete) test in DVS based on the number of fields and the complexity of the decision (rules).

Let us first consider the feasibility of complete test regardless of the technology/software choice. For simplicity let us consider rules around only three fields (Field1, Field2, Field3), which carry binary values. The maximum number of test cases needed to run a complete test for the ruleset is 2^3=8.

#	Field1	Field2	Field3	Ruleset Output
1	T	T	T
2	T	T	F
3	T	F	T
4	T	F	F
5	F	T	T
6	F	T	F
7	F	F	T
8	F	F	F

This is a simple example (n=3), but it can help us visualize and understand how to handle the test cases with a lot more fields/elements. Note:  2^3=8 is also the maximum number of unambiguous rules that can be implemented with 3 fields. This can also be visualized as a binary tree. The height represents the number of fields and the leaves of the tree represent the rules. E.g. the left most leaf R1 corresponds to the rule#1 in the above table (F1=true and F2=true and F3=true).

In general for N fields, each of which can take K values (group of values), there can be at most K^N unambiguous rules implemented. In the above example N=3 and K=2 (binary fields). We can generalize it even further. There can be fields with different number of accepted values (group of values).  If there are n fields, each of which can take k values and there are m fields each of which can take p values, there can be at most k^n* p^m unambiguous rules implemented. 

Another philosophical question we should ask is how much testing is sufficient. E.g. if we have implemented R1,R2,R3, do we have to implement test cases for the tracks R4, R5, R6, R7,R8 , i.e. do we have to prove that unimplemented rules did not fire(unintentionally)?!?!  The answer is - it depends!! We may have to do 1 or 2 test cases for unimplemented rules, depending on the complexity of the rules. Example: loan approval application that has a rule: “if the age of the applicant is greater than 40 and the credit score is “good” then approve”. If we were to write test cases for that single rule, we might have to do the following:

#	Age is greater than 40	Credit score is “good”	Expected output
1	T	T	Approve
2	T	F	The default approval status

Theoretically we did not “have to” do the second test case, but it is good to make sure the approval is set by the implemented rules and not by some bug that sets it to  “approve”  regardless of rule conditions. 

What if there were 100 fields instead and let us keep them binary for simplicity (would not change the problem if they could accept 3, 4, 5 ... n values). The max number of rules constructed and the max number of test cases need to do a complete case is 2^100. 

#	Field1	Field2	…	Field100	Ruleset Output
1	T	T		T
2	T	T		F
…	…	…		…
	F	F		F

Often times we implement rules with more than 100 XOM elements and to run a complete test we would need 2^100~1.27*〖10〗^30test cases. Theoretically this is an unfeasible problem if we consider the worst case scenario. 

The number of fields is relevant only in theoretical discussion, considering the worst cases (2^n  , where n is the number of fields). In practice though the number of test cases is needed for DVS is equal or comparable to the number of rules.  That means that if it was feasible to create N number of rules, then it would be feasible to implement sufficient test cases for complete testing in DVS. 

To learn more about Prolifics' ODM solutions, visit our website or contact solutions@prolifics.com.

Artur Sahakyan is an Associate Consultant at Prolifics specializing in IBM WebSphere Operational Decision Management (v5.xx - v8.xx). Artur has a strong background in mathematics and probability/statistics. He also has profound knowledge of IBM Business Process Manager, IBM Integration Bus (IIB v9), IBM WebSphere MQ (v7), IBM SPSS Modeler, IBM SPSS Statistics, Java, C++, C.