Table of contents for Meet our Partners
- Lux Magi and Decision Management: An interview with Jan Purchase (Part 1)
- Compliance in Finance – An Interview with Jan Purchase – Part 2
- Legacy Modernization and Decision Management: An Interview with Claye Greene
- BPM and Decision Management: An Interview with Juergen Pitschke
We have been expanding recently, adding partners to help us deliver decision management to customers around the world. You can see the current list of partners here on Decision Management Solution’s website. To introduce these partners to you I am going to be conducting a series of interviews in the coming weeks. I am going to begin with a partner of ours based in the UK that focuses on investment banking – LuxMagi.
Please describe your current role and title and tell us a little about your company
I’m Jan Purchase, the director and co-founder of Lux Magi Ltd. We enable financial institutions to manage and automate fast-evolving, complex business logic that’s crucial to the survival of their companies. Our clients need to make lots of complex decisions to optimize or verify their business transactions and these decisions are subject to continuous assessment and improvement. Our consultants lead client teams in the development of systems that allow their business SMEs to directly articulate, simulate, test and execute the operational decisions that determine the enterprise’s profitability or regulatory compliance.
We’ve amassed decades of experience in capital markets with a mastery of the tools and processes that are needed to make active management of operational decisions a reality. Much of our work involves automation of complex, legal and regulatory compliance processes with a high penalty for error and aggressive delivery deadlines.
How did you come to get involved with Decision Management?
We started as a Business Rule consultancy because we had all, individually — on separate projects for different organizations, shared the frustrations of business SMEs in developing transaction processing systems: Why does it take so long to effect the simplest of changes? Why do the business behaviours I specify need to be translated (and often mistranslated) to SQL or Java implementations which I can’t comprehend or validate? Why do businesses yield the control and deep understanding of their operational decisions to their IT departments? Why can’t systems justify unexpected behaviours, post-hoc, in a manner I can understand? Why can’t the system monitor the effectiveness of the decisions it makes? The potential of separating business logic from technical infrastructure, explicitly managing it as an asset and making it transparent to experts on their terms excited us.
Following a number of successful business rule projects, in 2007-2011, our focus evolved into an interest and then advocacy of business decisions. Over the course of six enterprise projects (and excellent publications by von Halle and Goldberg, Taylor and Ross), we realized that business rules alone are not enough: they are only part of an effective solution. Many of the problems we encountered with application of business rules in large projects were well articulated and addressed by the decision management approach. (We’ll discuss a few of these in the next post in the series)
What are some of the key business challenges facing your clients?
Our clients typically need: to check their transactions are compliant against an ever-changing, often poorly-integrated, patchwork of regulatory standards; quickly detect and remediate violations and know how to strategically eliminate or reduce the number of violations in future. They also need to demonstrate that they have done all of this to the satisfaction of regulators. All of this needs to be done under considerable time pressure. The main challenges are:
- Time to Market: the rate of evolution of compliance standards is increasing as is their proliferation. Some regulatory frameworks only allow three months consultation periods and nine months from notification to ‘go–live’. Given the scope of these frameworks, this leaves very little time for organizations to understand the entire impact to their business and implement the changes effectively. More than ever, clients need to save time by prototyping early and eliminating redundancy (and risk) by pooling common requirements (e.g., asset classifications, product and other reference data, risk metrics) between programs.
- Data Quality: a common hurdle is acquiring data of a sufficiently high internal consistency on which to base reliable compliance checks. The most effective operational checks can be undermined by poor data quality. Within data management the handling of enumerated data and coping with evolution of permitted values over time is also a significant obstacle. This can be combated by publisher side data standards, but this does not remove the need for our solutions to be data resilient.
- Change and Audit Management: many compliance standards are subject to frequent amendments (e.g. FRB 5G liquidity data collection) and consultation periods during which further change can emerge. Therefore businesses need an agile approach to compliance checks that is tolerant of and manages constant evolution. A strong governance process and auditing of all changes is a vital part of ensuring that not only are the necessary checks up to date and correctly executed, but seen to be so.
- Effective Traceability: often the combined behaviors of large numbers of interacting rules can surprise business SMEs, even if the rules have been individually reviewed and tested. The job of testing all possible interactions is intractable, so instead we need to test what we can and ensure that the compliance process can always justify its behaviour after the fact by explaining what decisions were made at each stage in the process. This serves to explain counterintuitive behaviour and pinpoint flawed rules in the event that the counterintuitive behaviour turns out to be wrong. This is complicated by the temporality of both compliance regulations and the data they act on — compounding the challenges of version control. The need to retain this information over long periods, to facilitate post-hoc inspection by auditors, further complicates this challenge.
- Precision and Transparency: the complexity of financial rules and the fact that many regulatory documents are written in vague, self-contradictory documents makes precision of our operational compliance rules very important. In some cases regulatory standards are so ambiguous that many consultancies exist to provide ‘certified interpretations’. It’s crucial therefore that our client’s interpretations of the regulations, whether they are sourced from an external consultancy or developed internally, be very clear so that they can be reviewed by a wide panel of experts or regulators. The problem is: how do you represent this logic precisely in a format that everyone understands?
- Rapid and Insightful Response to Issues: clients need to measure the effectiveness of their systems in near real time in order that they can avoid costly errors or be informed of hazardous developments. In addition they need to monitor the effectiveness of their compliance process over time. But, utilization aside (a rule that is never used is certainly worthy of attention and review), how does one set meaningful effectiveness metrics for a compliance rule, many of which are not individually meaningful to the business?
In your experience what are some of the top challenges for those working with business rules in terms of maximizing the business impact of what they do?
- Offering true transparency of business logic to SMEs: this is the holy grail of business rule management – the ability for a business analyst or SME to be able to understand, review and even amend a rule solely from a business glossary and the rule itself (and perhaps a sandbox environment in which to experiment with the rule’s impact on production and synthetic data). Very often this is complicated by the fact that some management systems engender rules which have a strong IT flavor which obfuscate their meaning. Sometimes it’s hampered by analysts that don’t want the responsibility of authoring rules that might turn out to be flawed – they’d rather hide behind the ambiguity of a specification in Excel instead and blame IT for an imperfect implementation. But for the best analysts and SMEs visibility gives them the ability to not only directly achieve the effects they require, but to experiment with event better ways of doing it and truly own a rule set’s evolution. BRMS sales teams have claimed their tools support this nirvana, but practical, enterprise-scale examples are very rare.
- Safe Agility: the need to change operational logic within days or hours with a very high degree of confidence that there will be no collateral damage due to unintended consequences. The difficulties here are that the penalty for making a mistake is high, but often the window in which the change needs to be made is rather small (before a competitor capitalizes on the same change or a regulatory deadline expires or an event occurs that attracts a fine). The ability to turn-around surgical amendments to compliance rules within days with a very low rate of incidents has pivotal value to clients.
- Scale: frequently we are consulting simultaneously to 4-8 related compliance projects within a client program. These often create rulesets with thousands or tens of thousands of rules. Managing the interdependencies and complexities of these rules, and therefore their ease of comprehension and change, is a major hurdle for most clients. Understanding the impact of a proposed change can be undermined by this complexity and a strong organizing principle is needed that makes these interdependencies explicit. This is further complicated if the knowledge sources on which these rules are based is also evolving (e.g. reference data systems).
- Effective Ongoing Measurement of Effectiveness: it can be very tempting, in the bustle of implementing business rules that are not a focus of change, to simply replicate the function mined from existing systems. Teams assure themselves they will revisit the logic when time allows, but frequently this isn’t done and outmoded business logic is merely ‘facelifted’ into a BRMS. Other rules may be changed only in response to an external change stimulus, rather than an internal review. Although rules are tested to ensure they achieve the right ends, their true business effectiveness is not measured or monitored and there is no autonomous drive for improvement. Frequently, individual rules don’t have any explicit connection to business goals which means their effectiveness is difficult to measure and larger rulesets may have nebulous, ambiguous or contradictory goals. Often, rules are not associated with specific SMEs or sources of knowledge so questions that arise about their improvement are hard to target, particularly if the rule is old.
- Cross Enterprise Consistency: as clients develop multi-site, multi-disciplinary teams as a means of meeting the tight deadlines imposed on regulatory projects, they seek to reuse rather than redevelop assets. The need to share resources—decision services, a common business vocabulary and a framework for expressing business logic—becomes more important. The days when business analysts could express a requirement using an ad-hoc spreadsheet are waning. Specifications need to adhere to standards if teams are to stand any chance of leveraging each other’s assets.
- Process Support for Governance and Agility: many clients are motivated to use rules by the promise of agility. However more than technology is needed to achieve this and some businesses miss out on the benefits because they perceive it as exclusively a technology issue and don’t adopt an efficient governance process.
More from Jan in the next blog post. Jan and I are gave a webinar on Agile and Cost Effective Financial Compliance: Going Beyond Business Rules with Decision Management.