I would like to start a discussion about Business Rules. I hope you will join in. Over a series of posts I plan to explore questions like:
- Why are Business Rules necessary?
- What exactly is a Business Rule?
- What should happen if the data fails a Business Rule?
- What controls should you have in place to manage Business Rules?
- Where should you look for Business Rules (if your Enterprise has no Master Business Rules Repository)
I will use a case study from an Anti Money Laundering (AML) programme.
In this AML programme, the client selected a “Best in breed AML vendor solution”. The vendor specified the data required, and the client was responsible for locating the data to populate the new AML repository, and for the quality of the data entered in the repository.
Why are Business Rules necessary?
A standard AML business requirement is the requirement to monitor “Minor Accounts” (accounts held by customers under 18 years of age) for ‘unusual transaction activity’. This high level requirement would result in a number of more specific business requirements, such as:
“Generate an AML alert when the total value of Cash lodged in a month, to an account held by a minor, exceeds a predefined amount, say EUR5000”
Having agreed the above business requirement, the vendor asked the client to provide the Business Rule for identifying a ‘Minor Account’.
So:
1. Why are Business Rules necessary?
Business rules are required to distinguish between product types, customer types, car parts etc. etc. AML systems require business rules in order to apply different alert rules to different account holder types.
AML business staff are AML experts, not business rules experts. It was unclear who owned the data and it took a long time for the IT department to research the business rule(s) for the vendor. Q: How do business users in your enterprise get details of Business Rules? Do your business users find it difficult to access the data they require?
Let us suppose the Business Rule supplied to the vendor was:
A minor account may be identified as follows:
1. Account Type: Personal
2. Account SubType: Minor
3. Customer Age: Less than 18
The age check was required to manage the risk that an account opened when a customer was a Minor was not converted to a Standard Personal account when the customer reached his/her 18th birthday.
So:
2. What exactly is a Business Rule?
A Business rule provides critical details about data, including the ‘business’ name of the field, the business purpose of the field, the values it may hold, the business meaning of each value, and interdependencies with other data. Let’s explore this a little further:
- Business name of the data field(s):
In the above example, three data fields are used in the Business Rule:
‘Account Type’, ‘Account Subtype,’ and ‘Age’ (probably determined from Date of Birth).’
- Business purpose of the data field:
e.g. ‘Account SubType’ is used to identify different account types, such as ‘Minor’, ‘Mature years’ etc.
- Permitted values (also known as enumerations):
e.g. Permitted values for Account Subtype are 101 to 199.
- Business meaning of each permitted value:
e.g. ‘Account SubType’ value 101 means Minor Account
- Interdependencies with other data:
e.g. ‘Account SubType’ depends on ‘Account Type’
‘Account SubType’ value 101 means Minor Account, when Account Type is ‘Personal’
- Field precedence:
This defines the order in which the fields should be interrogated
e.g. First check Account Type, then Account Sub Type
The AML vendor configured the AML tool to apply the “MINOR” rule when Account Type was personal, Account SubType =101 (Minor), and Customer Age less than 18.
During testing, few alerts were generated on Minor accounts. From an AML business perspective, the less alerts generated the better, since the workload for the AML staff is dictated by the number of alerts generated.
The AML business area was pleased with the low number of alerts, and the vendor was pleased that the alert worked ‘as specified’.
However, it was common knowledge that Date of Birth was not populated 100% of the time, so what was happening when there was no Date of Birth present? There was no culture of data quality measurement in the Enterprise, and no facilities for data profiling. Custom built SQL queries against the new AML repository identified multiple instances in which the actual data failed to conform to the Business Rules.
So:
3. What should happen if the data fails a Business Rule?
In our AML example, what do you think should happen when:
a) Account Subtype is ‘101’ indicating a MINOR account, but the customer is aged over 18?
b) Account Subtype is ‘101’ indicating a MINOR account, but date of birth is not populated for this customer?
Business Rules define what data fields “should” contain. On this AML programme, as in all real world data programmes, the actual data content did not always match what was expected.
This only became apparent as a result of custom built data profiling. Based on the actual content of the data, the AML business area had to ask the vendor to implement Exception Rules to handle the non-conforming data. In an ideal world, the data would have been corrected. In the real world of “achieve compliance by a given date, or face a regulatory fine”, workarounds are quite normal.
So – what are Exception Rules?
Exception rules define what must happen when an account contains data that fails to comply with a business rule.
This post is already far longer than I had planned – I hope it hasn’t bored you to tears.
In my next post, I will explore:
Please share your experience by posting a comment – Thank you.
Like this:
Like Loading...