Stefanie Peitzker describes the use of rules technology in compliance solutions for finance. Within the wider field of risk management, it focuses on combating terrorism and maintaining the reputation of financial institutions. Stefanie explains why the graphical approach of "visual rules“ is best suited to this business case. -- John Hall.
 

Rule Technology in Finance

Agile Compliance Solutions for Combating Terrorism
 

by Stefanie Peitzker
 

How to ensure Compliance efficiently
 

In recent years, combating terrorism has not only become a government task but also a task of financial institutions. Their goal is mainly to minimize financial risks of customers efficiently and maintain their good reputation. Just one customer involved in terrorist financing, corruption, money laundering or financial crime can ruin a bank’s business. However, not all of the “suspect customers” are well known and can be excluded from business in the first place. Financial institutions today are almost impelled to match customer data with given blacklists like World-Check and classify customers and transactions by risk. The example below illustrates how this is best done on a rule base.
 

If found, unusual, exposed or criminal, transactions and customers have to be identified and clarified. In order to minimize the effort for clarification, different workflows are triggered and controlled, based on Innovations´ visual rules business rules system (BRS). Actions initiated for clarification depend on the risk level of the operation or customer, ranging from mere observation, informal short clarification and specification checklist up to the non-booking of an entry.
 

Rules for Compliance
 

Rules are used to ensure compliance: for analysis and matching of customer and transaction data (single transactions as well as patterns), for risk classification, triggering of actions, controlling of clarification processes and also for defining user-oriented monitoring filters.
 

Innovations´ compliance system comprises hundreds of rules specified to prevent banks from risks originating from customers that are assessed as exposed or criminal by black lists. Those rules are constantly changing, triggered by official and internal regulations, by the know-how of the bank´s compliance officers and by alerts given. Often fast reaction is essential in order to preserve the reputation of the bank.
 

BRS are best qualified for this kind of application, enabling the experts of the risk/compliance department to adapt the rules of their management system fast and easily. Therefore, the rule system has to be usable by non-programmers as well.
 

Visual Rules for implementing the Compliance Strategy
 

Visual rules is a BRS with a special graphical approach. The business logic is modelled graphically and becomes traceable. Transparency is important when business experts are given the real power to control the rules. It is provided for visual rules by 3 facts:

• The models – “rule trees” – are a precise map of the business logic.
• Where other rule engines have to define and execute several rules, visual rules offers special elements like loops and other decisions with more than 2 exits (switch-case in contrast to just if-then-else). Therefore, rule models remain as clear maps.
• Symbols for elements of rule trees are easy-to-memorize, supporting fast comprehension of the models.

All of the rules, for risk classification of customers and transactions as well as the clarification of unusual business operations, are well known by the compliance experts. With visual rules, they model this knowledge directly for generating code of it. No rule engine is needed to interpret inferences out of the rules. So there is no black box when it comes to compliance logic. Results of passed through logic are always complete and unambiguous. This is important for all applications in finance. And: processing of rules is fast.
 

Change of compliance logic can also be done by the business experts. They adapt rule models in their customized view of the BRS. This is the same IDE that the IT uses for developing applications (e.g. Eclipse). The compliance expert then simulates the new models, and statistics of simulation are shown at each node of the rule tree. By matching the results of simulation with the expected ones, the expert ensures that the models represent compliance reality. The models are then handed over to the programmer who generates the rule code of them and integrates it in the risk management systems. This process is fast and efficient.
 

Name Matching as part of Risk Management
 

The graphical approach and its benefits are demonstrated with Innovations´ Name Matching System (nms) for matching customer data with blacklists used by major Swiss private banks, such as LGT Bank in Liechtenstein and Bank Vontobel. World-Check is the most extensive blacklist data source, containing about 200.000 persons. It is used by more than 80% of the world´s top banks for matching with their customer data base.
 

nms presents the results of matching as a list of politically or otherwise exposed persons or those with high risk. Relatives and business partners of those persons are considered as well for high-quality risk prevention. The matching results have to be identified and clarified by the responsible person, or taken over into a white list if the person has been identified before as being no risk. This prevents the bank´s consultants from doing business with high-risk persons and still limits those results to be clarified.
 

Efficient matching is achieved on a rule base. Also explanations of the results are presented for evaluation in the name matching system. They include:

• Quality of matching (e.g. name and alias are identical but date of birth are not available OR all words are matching in any order, including date of birth)
• Categories of World-Check (Political Individuals, Financial, Narcotic or Organized Criminals, Fraud, Arm Dealers, Terrorists, etc.)
• Attributes of World-Check and customer data (like their position or information about their criminal involvement)..

Rule models for Name Matching
 

Kind and degree of matching criteria can exactly be specified with the rule system. Lets read the rules of the given example (figure 1).
 

Figure 1: matching last name

click image for full screen version
 

The first rule is to check the availability of a customer´s last name in the World-Check list. If it is available, the next check concerns the availability of both first names. If the first name is identical as well, the matching of the dates of birth follows as next step. Depending on the matching of dates of birth, the result is presented (in any chosen system) and includes the quality of the matching hits. Quality 2 represents a high matching hit. This model by itself is a pretty easy rule-set. It can be extended as complex as required. In the case that the field of first names is empty, the next step is to check if the last name consists of several words and if first and last names are both found in the data field of the last name. Then again, the dates of birth are matched.
 

There are many other rules passed through for results matching with quality 2. Let´s look at a different example for a lower matching quality that explains some more elements of the rule models (figure 2).
 

Figure 2: matching all words in name
 click image for full screen version

This is a check of all words in both fields of last name and first name. The first rule decides if more than one word is found. Otherwise, the result is ignored as too low quality for this matching rule-set. In the positive case, a loop iterates over all words (defined by separating spaces). Here, the element loop enables processing an array of words. If all words are found, again loops iterate over all matching words in the fields of name and alias while differently spelled words are also considered by integration via fuzzy search.
 

A possible result is that all of the names found are identical, given that any order is tolerated. The quality of the matching hit is then 5. Of course it is lower than the result of the example with quality 2 since there is a greater toleration for matching. At the end of the rule-set, dates of birth are always matched for keeping or reducing quality of the match. There is also a check against the bank´s white list (see the element described as “check matches + statistics”) in order to manage matching results most efficiently. The dates of birth and the white list checks are swapped to other rule trees in order to reuse these parts of the logic and still keep the models clear. They are included in this tree by rule tree calls, which are represented by the green symbols with a tiny rule tree on it.
 

If only a subset of the words are matching, the quality of the hit is lower (here 7), given that the dates of birth of the hit are identical. If the dates of birth do not match or exist, there are no matches to present.
 

Conclusion: The result of the matching process is explicitly traceable. Whenever rules are supposed to be changed – triggered from in-house or by the external list provider – they can easily be adapted by replacing single decision nodes, extending trees with additional rules or attaching another tree for an additional matching process.
 

Rule Technology for other applications of Compliance Management
 

Matching of customer data can be delivered via the online analytical tool of the name matching system for single requests, e.g. when a customer account is opened. Professional compliance systems like Innovations´ mlds (money laundering detection system) also comprise a feature for continuous, periodic matching. The results are then presented to the responsible consultant or compliance expert as soon as he starts his view of the system. Presentation is customizable for flexible controlling of clarification – by quality of matching or by category like political person, narcotic crime, etc.
 

In compliance systems, rules are also used for monitoring of transactions, not only customers. Furthermore, mlds features a proprietary risk classification of customers, realized on the master data enquired with opening a customer account (on business connections, transaction behaviour, etc.). Another example of use of rule technology within an integrated compliance system is the control of clarification workflows: who has to complete a checklist, whether the responsible person is delayed, who has to review the list and possibly turn it back or approve it. The rule based control of clarification workflows simplifies the cooperation of involved persons and guarantees that clarification is done in the defined period of time.
 

One more rule project is to be specified here. We have picked the triggering of clarification actions. Whether a transaction – here: cash – is of high risk and has to be clarified, is defined by the rules shown in figure 3.
 

Figure 3: clarification
 click image for full screen version

Inflow and outflow transactions are regarded differently for clarification. The action that has to be taken by the consultant, highly depends on the risk rating of the concerned customer. The risk of a customer classified with A is lower than one classified with B (defined and executed by another rule-set). Therefore, customer A is tolerated with a greater cash amount. The limit for his transaction is €100.000, being classified as high-risk transaction and as to clarify with a detailed checklist. Compared to a customer rated at risk C, his limit is only €25.000. Therefore, depending on the type of transaction, the risk rating of the customer and the transaction amount, a clarification workflow is triggered automatically by the rule system.
 

Conclusion and Future Prospects
 

Compliance management in finance – like the name matching system and mlds used by many European banks – requires traceability and flexibility of business logic. Traceability is necessary for the business expert in order to define accurate and complete compliance logic models. It is given by the graphical approach of visual rules.
 

Flexible business logic enables compliance experts to react fast to risk alerts, changing regulations or black list data. This agility is given with visual rules, by keeping the business logic apart from the application logic and by generating programming code directly of the rule models.
 

There are many other aspects that make a rules system qualified for risk management systems of a bank: Does it guarantee audit acceptability? Is high-performance of execution of the business rules given? Can the IT department use the established IDE for developing the business logic? Can business experts use the same IDE with customized view for a straight process of developing business logic? Does the BRS support legacy systems as well as Java architectures?
 

The individual demands of the bank decide which of the factors are essential for its risk management strategy – e.g. depending on the fact, if it is using Cobol-based systems and therefore business logic needs to be provided for both Java and Cobol.
 

Some of the product and company names used in this article are trademarks and/or registered trademarks. They are used explicitly for reference purposes and are – independent of marking – property of their respective owners.