Achieving Regulatory Compliance – the devil is in the data

I will be sharing my experience and ideas on “Achieving Regulatory Compliance – the devil is in the data” at an IDQ Seminar Series event in Dublin next month.  I would like you to help me prepare.

I would like you to share your past experience with me, your ideas on the current situation, and most important, your view of the future.

Is Regulatory Compliance a mere box ticking execise?

What industry do you work in?

Is regulation increasing in your industry?

Is regulation merely a box ticking exercise?  Does the regulator simply accept what you say.

What role does data quality play?

What role does data governance play?

My initial thoughts are as follows:

  • Regulation is increasing across all industries
    e.g. Within Financial Services, the list includes:

    • SOLVENCY II
    • BASEL II
    • Anti Money Laundering AML
    • Anti Terrorist Financing AFT
    • Sarbanes Oxley SOX
    • MFID
  • Regulatory compliance is often seen as a box ticking exercise, since it is physically impossible for the regulator to check all the information provided.
  • Regulators will increasingly seek to challenge, audit and query the Data Governance processes used to gather the information, and critically the controls applied within those processes.  (I have written a series of posts on common Data Governance Issues – see Data Governance Issue Assessment Process)

I hope to write a number of posts expanding on the above ideas.  My argument is that “To achieve Regulatory Compliance, the devil is very definitely in the data, but the evidence is in the Data Governance process”.

Whether you agree, or disagree, I would like to hear from you.

Business Rules Case Study Part I

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:

  1. Why are Business Rules necessary?
  2. What exactly is a Business Rule?
  3. What should happen if the data fails a Business Rule?
  4. What controls should you have in place to manage Business Rules?
  5. 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:

  1. 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).’
  2. Business purpose of the data field:
    e.g. ‘Account SubType’ is used to identify different account types, such as ‘Minor’, ‘Mature years’ etc.
  3. Permitted values (also known as enumerations):
    e.g. Permitted values for Account Subtype are 101 to 199.
  4. Business meaning of each permitted value:
    e.g. ‘Account SubType’ value 101 means Minor Account
  5. Interdependencies with other data:
    e.g. ‘Account SubType’ depends on ‘Account Type’
    ‘Account SubType’ value 101 means Minor Account, when Account Type is ‘Personal’
  6. 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.

Business is all about data

Technologies may come and go.  At the end of the day, business is all about data.

Take the banking industry:
Hundreds of years ago, banks had Customers, with Accounts, on which Transactions were recorded. Bankers knew their customers personally, and all details were recorded by hand in ledgers, using quills made from feathers. Over time, quills were replaced by fountain pens, and later by biros, to record customer, account and transaction details.

Fast forward to today:
Banks still have Customers, with Accounts, on which Transactions are recorded, only many, many more of them.   Financial Regulators require banks to “know your customer”, but it is physically impossibe for bankers to know their customers personally. Customers can now perform transactions via multiple channels, at the bank branch counter, over the internet, over the phone, using mobile devices.

Customer Relationship Management (CRM):
To provide their customers with the best service, banks have implemented “Customer Relationship Management” or CRM systems. CRM systems analyse data to identify situations when the bank may wish to contact the customer to offer additional services, or otherwise improve the service the bank provides to the customer.

Money Laundering, Fraud, Terrorist Financing:
Banks today face ever increasing risks of Money Laundering, Terrorist Financing and Fraud.  Regulators require banks to implement best practice Anti Money Laundering (AML) and Anti Terrorist Financing solutions.

Best practice solutions:
What is the common thread amongst the best practice AML solutions?  How do Anti Money Laundering solutions enable a bank to “Know your customer”?  How do Anti Money Laundering solutions identify Accounts that require investigation? How do Anti Money Laundering solutions identify “Suspicious Transactions” amongst the millions of transactions the bank processes daily?

The answer:
By analysing the data.  However, the data analysis must be targetted.  The analysis must seek out defined activity patterns, and then alert trained staff to the possibility of wrongdoing.   More sophisticed AML systems can identify transaction activity that is unusual for a given customer type, by performing “Peer Group Analysis”.   For “Peer Group Analysis” to work, a bank must be able to reliably distinguish between different customer types.   Distinguishing between different customer types is often more challenging than one would think…