Compliance in Finance – An Interview with Jan Purchase – Part 2

Welcome to Part Two  of my interview with Jan Purchase, Director and Co-Founder of LuxMagi (Part One of the interview is here). Lux Magi are experts in helping their clients automate complex, legal and regulatory compliance processes using business rules technology and decision management.  Jan and I gave a webinar on Agile and Cost Effective Financial Compliance: Going Beyond Business Rules with Decision Management that is available as a recording.

How does Decision Management address compliance challenges beyond what business rules technology offers?

The operational checks and actions required when processing trades, positions and instruments mandated by regulatory strictures, are: moderately complex, highly repeatable, have measurable business impact and need, because of their volume and processing deadlines, to be automated. These requirements match the strengths of decision management very well. Even when you put aside the considerable benefits of a decision management technology stack, decision management still provides techniques to discover, mine, rigorously analyze, precisely represent, determine the mutual consistency of and  manage business logic needed to validate data, assess and triage risk, maximize use of resources (collateral being a prominent example) and calculate complex metrics.
Let’s consider how decision management addresses the challenges we’ve already enumerated:

Scale and Complexity

Most compliance business logic is not inherently sophisticated. In the main, there is little demand to perform single complex tasks like option pricing, Bayesian analysis or probabilistic modelling. With a few exceptions (e.g., apportionment of exposures between legal entities), the complexity of regulatory logic arises from the sheer number of special cases (e.g., arising from product specifics, tax legislation and client protection law), the many sources of input data and the vast multiplicity of different trading scenarios and jurisdictional variations.  Special cases (e.g., the government bond ‘uplift’ exception in 5G liquidity reporting and the enhanced eligibility for government guaranteed corporate instruments, even if they are not DTC eligible—to name but two) abound and are frequently changing. The problem is compounded by the large ‘fan-in’ of regulatory checks. There are a huge number of external authorities, all providing impactful information, some of which is conflicting: counterparty, book, instrument, currency and calendar reference data; credit risk ratings; asset and product classifications; trading events and many others.

As a consequence of this emergent complexity, rule based implementations of regulatory compliance systems tend to have hundreds, if not thousands, of interrelated rules and very convoluted business processes. Often the interdependencies of the rules are implicit. This highlights two limitations with an exclusively rule based approach:

• the lack of a higher, overarching principle to impose some business oriented structure on this complexity; and
• the need to separate a declarative definition of these rules from the sequence-oriented business process – to the betterment of both.

This higher level concept is the decision. Decision management gives us the power to start our regularity analysis from a business, rather than an implementation or a data perspective. What operational business decisions need to be made to comply with a regulation? The declarative definition of the decision, free of implementation or process detail, comes first. Once defined, decisions can be specified in detail using rules and, potentially, analytics. Implementations of these decisions are then made available, within an architecture, via decision services.

Decisions coordinate rules into cohesive collaborations with explicitly defined inter-dependencies that can be analyzed. This allows conflicts, redundancies and inconsistencies to be detected between them. Such wide scope checks are vital to support logical integrity which becomes a critical issue with scale.

A decision oriented approach also facilitates the separation of complex business logic from business process by defining an interface between them: the decision process. This is a process that encapsulates and invokes a business decision and then allows the result to influence the business process without coupling the two. This allows them to evolve independently (frequently at vastly different rates); the process determining when and what is done and by whom and the decision determining how important decisions are made and the declarative logic of these.

The net effect of adopting decisions is scalability (the ability to cope with ever more complex rule sets through abstraction and hierarchy) and the separation of different concerns (process and logic).

Offering true transparency of business logic to SMEs

Effective management of any automated business logic requires transparency: subject matter experts must have a deep understanding of the rules and direct sight (and even control) of their evolution. Control, via an IT intermediary, is not sufficient: it is slow and promotes error. It is business SMEs who must mine the logic from the bowels of legacy systems or compliance documents, wherein it lurks typically expressed in code, technically oriented configuration data or ambiguous and inconsistent English (in a specification document). It is they who must identify all the external authorities and knowledge sources that are required to support it. It is they who must define a lexicon of business terms using which the rules can be unambiguously expressed. Decision management offers techniques to achieve all of these aims. Furthermore, it supports the identification of implicit (hidden) or even missing business decisions.

In order to be able to manage compliance business rules effectively, subject matter experts need to comprehend both the existing decisions and rules and their potential. In other words: what they do and what they could do. One of the central challenges of transparency is how to represent business decisions and rules. There is a tension between precision, flexibility and comprehension. Hitherto it’s usually been the case that you could only achieve precision or flexibility at the expense of comprehension. Usually this is achieved by resorting to a programming paradigm to eliminate ambiguity and proffer a powerful and flexible environment to express rules. Following this approach, business SMEs express their rules in a business domain specific language which inexorably decays into an obscure programming language as more concepts are added over time. This compromises rule comprehension in the long term because it requires training and a programmers’ mindset to use effectively. Usually, over time, this causes the business to relinquish control of such rules to an IT-led maintenance team, which is rarely satisfactory. Oddly the less frequently rules are changed the faster this fallback occurs.

In the other extreme (sometimes referred to as a ‘fill in the blanks’ rule interface), rule flexibility is severely restricted in the name of easy rule comprehension and safe changes. This strategy retains business SME control of rules and allows them to make minor alterations directly (usually the ones IT imagine they might need), but they must still consult IT for any significant changes. Ultimately, unless more significant changes are very rare, this modus operandi is hardly better than the first.

Decision modelling supports transparency by giving business analysts a shared means to represent precise business semantics.  This is a representation, capable of concisely expressing business decision logic, that does not require resorting to code: the decision model and notation (DMN). DMN, formally adopted by the Object Management Group, allows business analysts to create and share precise specifications of business logic which are devoid of implementation details.

Over time the semantics of some rules can be obscured by cumulative accumulation of content, especially if this is done by lots of different people. The rule becomes a ‘dumping ground’ for additional logic because time does not allow changes to be properly reflected by refactoring rules and decisions. The growth of rule sets over time can compromise their comprehension by business SMEs. But the more rigorous approach of decision modelling (and DMN) prevents this by imposing atomicity, normalisation and other constraints which prevent rule bloat and needless repetition. This formality also helps to identify redundancy and maintain simplicity of rules by refactoring.

Decisions are, as we’ve seen, well integrated to, but not mixed with, the business process. This integration, coupled with the precision of DMN, supports a very important aspect of decision management: traceability. Traceability gives us the ability to:

• link a given outcome to all the data, rules and decisions which caused it
• link a decision to the authorities (e.g., compliance legislation, typically down to a paragraph in a document)  that mandated it

In short, users of a decision oriented system are sure that regulations have been followed and are seen to have been followed. This supports non-repudiation of decision results and their design, a vital win when your client’s regulatory systems are audited. It also supports effective impact assessment when an authority notifies a client of an update (e.g., the issue of a variation in a compliance policy).

Effective Ongoing Measurement of Effectiveness

As I’ve mentioned, decision modelling lends a powerful structuring mechanism to business decisions and rules, permitting collections of collaborating rules to be associated with non-technical artefacts (e.g., business processes, business motivations, knowledge sources and authorities). This association publicly defines the decision’s place in providing business benefit and facilitates the monitoring of benefit metrics. By measuring the ongoing effectiveness of business decisions we can achieve timely warning of underlying changes that might be undermining our decisions and take steps to improve them. We can also experiment with alternative decision definitions to see which yield better results. This autonomous approach to decision quality is essential to any continuous improvement initiative.

An example of how this can be applied is the association of compliance decisions with business goals defined in a business motivation model (using ArchiMate’s business motivation extension or the business motivation model – BMM). One benefit of modelling business goals in compliance is that you can detect contradictory goals (e.g., optimization of collateral versus capital adequacy) and resolve them. Typical compliance decision metrics include: data quality faults; capital adequacy breach frequencies/magnitudes and the failure count of classification schemes (e.g., credit rating or asset classification). Many decision stacks can support this type of associations and some even allow decisions to be linked to departments or teams so that any dysfunction can be addressed directly to those best placed to resolve it. An added benefit of this technique is that the associations can be used to assess the decision impact of changing business goals.

Decision management is pivotal here because it is often very hard to associate an individual business rule with a measurable business goal; especially if the same rule is used in many decisions. What is the business goal of a currency default risk mapping rule, or a credit rating classification rule, for example?

One common compliance rule quality metric that can be associated with individual rules is execution frequency. If a rule’s execution frequency drops to zero over several months, this might be an indication that it needs to be recertified, or at the very least the cause investigated. Compliance decisions are complex enough without redundant logic.

Safe Agility

Decision management empowers safe agility in a number of ways. The rigor with which decision management can mine, analyze and represent business logic, under the direct auspices of a business SME team, reduces redundancy and inconsistency in decisions, making them simpler and revealing many inherent flaws long before release. Because some decision stacks support entry and simulation of decisions directly by the business, without need for the IT infrastructure, decisions can be tested far earlier than usual, yielding greater parallelism in the development. Some tools that support this also allow ‘deployment’ to a BRMS (or Java, database mapping tables or whatever execution technology is selected), once the business simulation passes the defined tests. All of this significantly reduces time to market.

Once rules are in production, managing change becomes the predominant issue. As already discussed, decision orientation makes the dependencies between rules (and between rules and other artefacts) explicit and this helps functional impact analysis and prevents collateral damage when rule changes are made. This, in conjunction with a robust regression testing facility, can substantially improve the agility of systems already ‘live’. The aid to comprehension arising from using standards like DMN is also a boon in this respect.

Cross Enterprise Consistency

Regulatory standards impose a huge impact on our clients most significantly because they apply simultaneously to a large number of, independently evolved, production systems—adding to the cost of their development. When operational, some demand a quasi-real time response (e.g., 5G which requires daily reporting of every corporate entity’s liquidity profile—consolidations of all callable assets, liabilities and FX positions, bucketed by maturity period—with a latency of no more than 48 hours). This imposes demands on source systems that many organizations have never encountered before. The demands are exacerbated by the fact that, often, there are specific data exclusions (e.g., inter-company transfers) and adjustments have to be made to the raw data (e.g., apportionment of cross LE liabilities, calculation of required reserves and marketable value of assets). These must be applied consistently across all systems.

To apply these changes individually to each source system would be ruinously expensive and invite a patchwork of inconsistencies into the financial architecture. Decision Management enables a smarter solution in which the existing business processes of all these systems is integrated with a single set of decision services that support the core regulatory business logic, for example: data validation; asset, liability and collateral classification; reserve, uplift and asset weighting calculations and exclusions. Sounds straightforward? Actually it isn’t. You still need to separate this logic (and any pre-existing legacy logic that it replaces) from your existing business processes and systems. You still need to mine, analyse and capture the logic these decisions services need to support in order to satisfy the regulations on the part of all stakeholders and cope with any business specific variations. You still need to protect the regulatory process from the poor data quality and other vagaries of your source systems and cope with the exceptions these create. You still need to define the decisions services well enough that new systems can integrate effectively with them. Decision management offers processes, techniques and best practices for all of these.

Compliance initiatives frequently require the collaboration of large teams of analysts: one team to develop the compliance components and other, frequently embedded teams, to integrate them with existing source systems. A common format for expressing the business logic of compliance is vital to effective collaboration. The Decision Model and Notation (DMN), a global standard ratified by the Object Management Group, addresses this need by providing a representation of business logic that can be shared between teams, removing the need for their own ad-hoc (and often highly individualistic) standards and ensuring a concise record of business semantics that conforms to best practices. Decision management also provides the means by which teams can build and agree a common business vocabulary to ensure complete consistency between them.

Can you share a success story that illustrates the power of Decision Management?

Recently we were asked by a client to assist with multiple compliance initiatives arising from a single, broad spectrum, Federal Financial Supervisory Authority edict. These initiatives each had a distinct focus, but affected an overlapping group of legacy systems. There was already a strong conviction that a business rule approach should be adopted (because of the need for agility and transparency), but the client had little experience of rule architecture, building and maintaining large rule sets or mining rules from legacy systems. Because of the correlated goals of the projects, the fact that they intended to share many data sources and the need for consistency, transparency and agility, we elected to use decision management techniques to mine and model the decisions and decision services to deploy them for use in existing applications. This was very successful for several reasons:

• Once we had established the integration of our BRMS with the data integration architecture, by defining our service interfaces, there was a high degree of parallelism between infrastructure development and decision mining, analysis and development. This considerably decreased our time to market which would not have been the case had we taken a business rule oriented approach.
• The multiple teams of analysts working on the project all have different means of representing their business logic, each one unique to the team (and sometimes the member) involved! Adopting a unified approach to decision modelling helped to eliminate all of these troublesome difficulties.
• Involving business SMEs in defining decisions from the start not only secured their valuable expertise, but helped them to appreciate what the new system could do. It was an excellent way to capture their suggestions and prepare them to take ownership of those decisions (in terms of both taking responsibility and operational know-how to amend and test decisions) post ‘go-live’.
• The mining techniques and use of a normalised decision representation allowed us to identify and remove many flaws and inconsistencies in the original rules long before development. In one case this led to the identification of flaws in the original regulatory documentation. Ultimately, the number of rule flaws found in the first round of system testing that were not solely due to data quality was less than 5%.
• We were able to derive a first decision service prototype (with a rule coverage of about 70%) in just six man weeks.
• Expressing the rules within a decision framework allowed us to clarify their interdependencies and we discovered a number of dependencies that were hitherto not appreciated. This informed the technical architecture of the project and avoided potential incidents in production.
• The decoupling of decision services from the rest of the architecture made it possible for other projects to share our decision infrastructure for their own services.

How did decision modeling play a role in these successes?

Decision modelling was central to our success because it:

• Facilitated cooperation of business analysts of different backgrounds. We instigated the training of the multi-site, business SME team in decision modelling and this allowed them to work very effectively together. Decision models allowed each to see how their work related to that of others and the complete consistency of modelling notation and business vocabulary provided a lingua franca, enabling sharing of rule definitions with less need for explanation. Workshops between analysts became focused on the semantics of decisions and their business benefit, rather than implementation details. It also facilitated the effective review of compliance logic by third parties.
• Increased the effectiveness of individual business SMEs. It enabled SMEs to share business logic with developers and to increase the rigor of this representation so that any flaws, gaps, redundancies and inconsistencies were readily apparent very early in the mining process. It assisted analysts in rigorous and critical thinking too.
• Reduced the resulting size of the rule set. In two cases the application of decision modelling reduced the original size of the rule set by a factor of more than eight times.
• Increased the reusability of the rule set. Decision modelling helped the analysts to separate logically orthogonal issues that had historically been entwined (e.g., the distinction and separation of industry class and issuer class in asset classification) which, in turn, allowed both to be simplified and made independently reusable.
• Informed governance processes. Decision modelling served as an early warning of the high number of enumerated attributes the domain required and the need to manage the governance of these.

The faster time to market, the radically improved quality of the business logic and the transparency of the resulting rules, even prior to implementation, were the most marked advantages we achieved with decision modelling. We believe that with the right training and consultancy partner, any financial organization could replicate these results.

Lux Magi recently became a Decision Management Solutions partner. What are you looking forward to working on with us in 2014?

We are very proud to be partners of Decision Management Solutions and we are looking forward to a very busy year together. We hope to bring the manifest benefits of Decision Management and Modelling to more clients in 2014, specifically in the financial compliance arena which is growing strongly. In particular, we like to get more working experience with DMN and Decisions First Modeler, Decision Management Solutions’ collaborative decision modelling environment. We also aspire to be among the first DMN certified practitioners in Europe and, working with Decision Management Solutions, continue building commoditized, exemplars of regulatory decision sets (e.g., 5G, FATCA).

Last question – what advice would you give those working with business rules to help them maximize the value they create for their organization?

Our advice would be:

• Investigate and get training in Decision Management as soon as you can. You will find that it addresses many of the familiar problems associated with using business rules alone (especially coping with scale, improving precision and providing transparency).
• Learn DMN, it will make you a more effective rule author.
• Consider your decision governance strategy as early as you can in the project lifecycle and ensure business SMEs are involved from the start. It is much harder and less efficient to apply governance processes once a system is going live.

To learn more, check out the webinar Jan and I gave on Agile and Cost Effective Financial Compliance: Going Beyond Business Rules with Decision Management. The webinar recording includes illustrations of how the decision management approach has been applied in compliance projects and a walkthrough of real decision model from one of these. It will conclude with an interactive Q&A session.