Keywords

1 Introduction

Organizations have to comply with several regulations that are subject to change, such as laws (e.g. Sarbanes-Oxley ActFootnote 1, Basel IIIFootnote 2) and standards (e.g. ISO 9000Footnote 3). These regulations are documents written in natural language, containing a set of guidelines specifying constraints and preferences pertaining to the desired structure and behavior of an enterprise. Non-compliance with regulations can lead to serious consequences, including loss of business reputation and penalties levied against the organization. Regulatory compliance management (RCM) is the problem of ensuring that enterprises are in accordance with laws and domain-specific regulations [1]. In the field of RCM, regulations are usually decomposed in compliance requirements, which are pieces of text extracted from a regulation, specifying expected behavior as well as tolerated and non-tolerated deviations. The extraction of compliance requirements requires the intervention of regulatory (e.g. juridical) and enterprise experts (e.g. business analysts).

All value-adding activities inside organizations are realized and supported by business processes. Hence, compliance to regulations must be ensured at the level of business processes in particular [2]. In order to analyze, simulate, execute, monitor, and optimize their business processes, more and more organizations use business process management (BPM) [3], where the concept of a process model is fundamental. Process models may be used to configure information systems and serve as a means to analyze, understand, and improve the processes they describe [3].

RCM of process models has been identified as one of the core challenges in the discipline of BPM [4], and a variety of proposals have been made to facilitate it. Existing approaches to ensure compliance at design time, i.e. before the processes are executed, suggest automating compliance validation of process models in order to avoid manual auditing procedures (e.g. [5–9]). The models are checked using predefined compliance rules, which are semi-formal representations of compliance requirements. However, the specification of compliance rules shifts the problem of ensuring compliance from the process models to the rules. It remains unclear how regulatory compliance of derived rules is guaranteed, e.g. in the case that regulations are changed. It can be a complex and error-prone task to identify manually all rules that need to be updated.

In this paper, we present an approach to extend existing RCM solutions with the concept of traceability between regulations and compliance rules. Based on the principle of establishing links between rules and the corresponding text of regulations, we describe the architecture and adaptations of the RCM life-cycle in order to realize traceability. Among other advantages, this enables us to integrate tool support for regulation change detection which helps providing the assurance of up-to-date and better maintainable compliance rules. The remainder of this paper is structured as follows: Sect. 2 outlines a motivating scenario and contains a short introduction to the state-of-the-art of business process RCM solutions. In Sect. 3, we present our approach to improving the maintainability of compliance rules in business process RCM solutions. Some details of a proof-of-concept prototype and evaluation results are provided in Sect. 4. We finish with a conclusion and outlook in Sect. 5.

2 Motivation and the State-of-the-Art

It is the task of RCM to ensure compliance of business processes and regulations which, in the context of BPM, can be realized in three main ways. The first way is to ensure compliance of the process models before the execution of the processes (static verification at design time). At run time, compliance can be checked monitoring the running process instances. Finally there is a way of backward compliance checking by analyzing the traces of completed process executions [2]. In this paper, we focus only on the design time aspects of RCM, which we prefer due to their preventative focus. In this section, we will introduce the state-of-the-art of business process RCM using an example which is taken from a case study we conducted in cooperation with an insurance company (cf. Sect. 4.2).

2.1 Motivating Scenario

In Germany, a series of typical contractual rights and obligations of insurer and policyholder is regulated by different laws - particularly by the German Insurance Contract Act (IC Act)Footnote 4. This is done in order to ensure a fair balance between the interests of the insurer and the policyholder [10]. An excerpt from the IC Act is shown in the following snippet. The text regulates documentation requirements of the insurer and its duty to advise the policyholder before the time of the conclusion of the contract. In the excerpt, activities are highlighted in bold, conditions are italicized, and temporal indications are underlined.

figure a

Regulations such as the IC Act impact on the business processes of an enterprise. Besides their use in BPM, process models help share the understanding of a process with other people. Thus, in order to show business experts how a compliant business process for advising policyholders would look like, juridical experts could develop a process model based on the IC Act excerpt - a proposal is shown in Fig. 1. BPMN 2.0 [11] was chosen as modeling language because it is an important industry standard which is supported by most BPM solutions. From a business standpoint, however, this legally sound model is not practicable. For example, it lacks the case that no contract is concluded after the advising of the policyholder. Business experts could, however, use this model as a reference process model and adapt it according to the specific requirements of the insurer. Modifications in turn can lead to breaches of compliance and call for checking compliance of process models each time they are changed. This could be done manually by juridical experts, but manual checking activities are time expensive and error-prone - especially when there are lots of compliance requirements that should be applied to many process models [9]. This issue is addressed by current business process RCM solutions as shown in Sect. 2.2.

Fig. 1.
figure 1

Business process model derived from the German Insurance Contract Act

Full size image
Fig. 2.
figure 2

BPMN-G-CTL rule as a formal representation of a compliance requirement

Full size image

2.2 Compliance Rules for Checking Process Models

Compliance requirements often originate in legal texts and have informal and abstract character. For example, the following (simplified) compliance requirement in natural language is derived from subsection (2) in the IC Act snippet: Whenever the advice had been provided verbally and the contract has been concluded, the information shall be provided in writing to the policyholder without undue delay. This requirement applies to the business process and its model shown in Fig. 1. In order to avoid manual auditing procedures of process models with respect to informal requirements, current RCM solutions suggest to represent compliance requirements in a formal and structured notation. These formal compliance rules enable tool support for automatic compliance checking of process models. E.g., the Business Application Modeler [5] allows for the specification of graphical rules in Computational Tree Logic, called G-CTL. It provides the ability to define rules on basis of process elements using a rule model editor and to verify process models against these rules through model checking. In case of a violated rule the model checker delivers the error trace of a counter example, which is visualized directly in the process model.

The compliance requirement example represented as BPMN-G-CTL [12] rule model is shown in Fig. 2. Besides the use of logic operators, the figure demonstrates how process elements can be placed inside of containers in order to formulate atomic expressions. With the aid of the Business Application Modeler, the rule shown in Fig. 2 can be used for automated compliance checking of the process model in Fig. 1. The validation will show that the process model is correct with respect to the rule.

This way of formalizing compliance requirements is an effective way of verifying the compliance of process models according to compliance rules. Furthermore, it enables the separation of specifying compliance requirements and business processes as advised in [13]. However, the feasibility of maintaining large sets of compliance rules is still limited regarding updates of rules and regulations. Imagine the case that a regulation is changed: manually identifying all rules that are related to the updated parts of the regulation can be challenging and time expensive. And the fact that regulations regularly change means that compliance rules have to be updated frequently. Empirical research proves that updates of existing compliance frameworks to comply with new obligations are seen as a key problem by industry compliance experts [14]. Thus, we believe that existing RCM solutions have to be extended in order to improve the overall maintainability of compliance rules.

2.3 Related Work

An overview on the state-of-the-art of business process compliance approaches based on a literature review is provided in [15]. As in [5], where a graphical notation for temporal logic (CTL) used for modeling compliance requirements is introduced (cf. Sect. 2.2), a large part of these approaches focuses on the design time aspects of RCM and on verification and validation techniques. In [7], the authors propose using predefined rule patterns (BPMN-Q queries) which are translated into temporal logic (PLTL) for compliance checking. The approach in [6] advocates using a visual pattern-based language grounded on temporal logic (LTL) that enables using compliance patterns, which are high-level abstractions of frequently used compliance requirements. Another approach that enables to model graphical compliance requirements introduces compliance rule graphs (CRG) used for compliance verification as presented in [9]. Deontic logic is used in [4, 8], where process models are enriched by control tags to visually annotate and analyse the models. Although these approaches help to ensure compliance of business processes with respect to (semi-formal) compliance requirements derived from regulations, they do not take into account the aspect of assuring that compliance requirements stay in line with the regulations. Thus, in this paper we will show how such approaches can be extended accordingly, especially in order to address the issue of the regulation’s changing nature.

On the other hand, research exists on establishing a connection between process models and regulations. The authors in [16] propose to bookmark structural parts in regulation documents and to annotate process models with references to these bookmarks. Work in [17] proposes to translate laws into process models using the Semantic Process Language (SPL) and to establish traceability through the documentation of compliance requirements within the process model itself. In [18] an approach is presented to increase the traceability between law and processes using the Visual Law and Process Modeller (VLPM). The tool supports translating laws into process models and linking laws and models. These approaches help to understand the impact of regulation or process changes to their counterparts. In comparison with previously mentioned RCM solutions, however, they lack the possibility for the (semi-formal) specification of compliance requirements and the (automated) verification of process models, thus requiring manual compliance checking activities inducing the aforementioned drawbacks.

3 Improving the Maintainability of Compliance Rules

Traceability between business processes and regulations and a change detection mechanism for regulations have been identified as important means to facilitate up-to-date business process compliance to regulations [16]. However, in the design of rule based RCM solutions these aspects have been neglected so far. In order to improve the maintainability of compliance rules, we advocate to integrate these aspects into existing RCM solutions by expanding them with tool support that helps to perform related activities.

3.1 Conceptualization

With traceability in the context of RCM solutions we mean the bi-directional ability to interrelate regulations and compliance rules: It should be possible to easily trace back compliance rules to the parts of regulations where the rules are derived from. On the other hand, it should be easily possible to spot all compliance rules that are derived from a particular part of a regulation. As a mechanism to realize traceability, we propose the establishment of links between compliance rules and regulations, i.e. human and machine interpretable relations where rules or even elements in these rules refer to the respective parts of regulations. For example, the task “Provide advice verbally” is an element of the compliance rule shown in Fig. 2. It is derived from the text “information may be provided verbally” in the IC Act snippet in Sect. 2.1. Thus, we would link the task in the rule with the part “Sect. 6, subsection (2)” of the IC Act. We will build on this simple principle when we realize further tool support.

3.2 Architecture

We propose the integration of four specific components into existing RCM solutions. These components are (1) a version control system for storing regulation documents and modeled compliance rules, (2) a tool for modeling compliance rules with the ability to establish links to structural parts in the regulation documents, (3) a component for identifying compliance rules linked with selected structural parts in regulation documents, which we will call link tracer, and (4) a change detection tool that identifies changes in regulation documents as well as the compliance rules affected by these changes. Within existing RCM solutions, components specific for our approach will be integrated with the other components of the RCM solution, such as a process model editor, a compliance checking infrastructure utilizing generic techniques like model checking for ensuring that process models are in accordance with compliance rules, a business process management system for coordinating the enactment and execution of the process models, etc. A high-level view on these components integrated in a RCM solution and the relations between the components are shown in Fig. 3. In the following, approach-specific components are described in further detail.

Fig. 3.
figure 3

High-level view on the components used in the approach

Full size image

Version Control System. Multiple versions of various files can be stored in a version control system. This allows for tracing the changes between different versions of files. We will use a version control system for storing regulation documents, compliance rules and process models.

Rule Model Editor with Regulation Linking Extension. Compliance requirements are represented as formal compliance rules that can be used for checking process models, e.g. using BPMN-G-CTL [12] as shown in Sect. 2.2. As a specific functionality in the presented approach, the compliance rule editor should allow establishing links between elements of the rule models and the text of regulation documents. This requires for the provision of the documents in a way that the regulations can be referenced by the rule model editor. The link should be stored together with the rule model in the version control system.

Link Tracer. A regulation link tracer tool helps identifying all rule models that contain links referencing to the particular part of a regulation. In order to identify these rules, all rule models stored in the version control system can systematically be parsed for links that point to the respective part of the regulation document (or more fine-grained parts that are comprised by the respective part, e.g. subsections of a regulation when a particular section is of interest). We do not postulate a separate tool for tracing links from a rule model to the linked regulation part, as the links are already integrated in the models and can be examined in the rule model editor.

Change Detector. The change detection component is used to detect changes in the text of regulations. This can be done by a comparison of the actual regulation documents stored in the version control system and newer versions of these documents, e.g. new versions of law that have been published on the web page of a governmental organization. For each change that has been detected, affected rule models are identified in the version control system based on the established links pointing to that regulation document.

3.3 Life Cycle Integration

Both RCM and BPM can be supposed to follow a life cycle of phases [13]. Each life cycle consists of the phases elicitation, modeling (design and formalization), enactment and controlling (optimization) of compliance rules and business processes, respectively. The design phases of both life cycles are required to be synchronized to create consistent process models and compliance rules [13] - remember, rules can be designed on the basis of process model elements. Compliance checking of process models using compliance rules is the way back from RCM to BPM, it initiates the process elicitation phase in case of a process model violating a rule. In our approach, we extend the RCM life cycle with a change detection and synchronization phase. This is the phase where new regulation documents are provided and existing documents are updated in the version control system, which will subsequently initiate the rule elicitation phase. The integrated and extended life cycles are shown in Fig. 4. In the following, we outline the specific steps covered by our approach that will be enabled through the components described in Sect. 3.2, and allocate the steps to the phases of the extended RCM life cycle as shown in Fig. 4.

Fig. 4.
figure 4

Managing maintainable compliance rules in a BPM environment

Full size image

Linking Regulations and Process Constraints. The first step is to select relevant regulation documents. They are stored and provided in the version control system. Then, compliance rules are derived from the text of the regulation. The rules are modeled using the rule model editor and linked with the corresponding regulation text using the editor’s linking functionality. The rules are stored in the version control system. These steps can be allocated to the phases Regulation Synchronization, Rule Elicitation and Rule Modeling.

Change Detection. The change detection component is used to detect external changes in the regulations that have been stored in the version control system. If changes were detected, these changes and affected compliance rules are shown to the modeler. The modeler has to decide on necessary adjustments and should implement them if necessary. The final step is to transfer the new versions of compliance rules into the version control system and update the regulation documents in the version control system. These steps can be allocated to the phases Regulation Change Detection, Regulation Synchronization, Rule Elicitation and Rule Modeling.

Link Tracing Between Regulations and Process Constraints. The compliance rule model editor is used for the optimization of rules or their adaptation to changes in process models. Due to the existing links, the text representation of the regulation is recognizable directly in the editor and consequently can be taken into account when applying changes to the rules. In order to analyze regulations on the other hand, e.g. performing completeness checks with regard to the existing rules, the appropriate regulatory document in the version control system is opened with the link tracer tool. Any granular text part in the document can be selected to serve as a basis for performing link tracing where all referencing rules are identified. These steps can be allocated to the phases Rule Controlling and Rule Elicitation.

4 Evaluation

4.1 Proof-of-Concept Prototype

The described approach has been implemented as an extension of the Business Application Modeler, which is realized as a plug-in for the Eclipse platformFootnote 5. The regulation documents need to be provided as structured XML files. The governments of several countries have already adopted XML-based structures for publishing legislative documents, as is the case with the United States CodeFootnote 6 and the German lawsFootnote 7, for example. In order to support different regulations with different structures, we decided to design the prototype extensible and user-configurable. For each type of regulation (e.g. “German law”), an XML configuration file has to be provided. These configuration files determine structural parts in the regulations that should be linkable (e.g., “Sections” and “Subsections” in “German laws”), and how these parts can be extracted from the XML regulation documents. The extraction of parts is configured using XML Path Language (XPath) which is a query language for selecting nodes from an XML document. Regulation documents and configuration XML files are matched via the regulation’s document type definition (DTD).

The rule editor of the Business Application Modeler has been extended with a corresponding linking functionality. A regulation link can be established for each element in the compliance rules. The user interface of the linking functionality is shown in Fig. 5. The figure shows a link between the rule model element selected in the rule editor (not shown) and Sect. 6, subsection 2 of the IC Act.

Fig. 5.
figure 5

Regulation linking extension of the compliance rule editor

Full size image

The link tracing and change detection component have been realized as one tool on the basis of the Eclipse platform’s compare editor. The tool is configured with the same XML configuration files as the rule editor. It supports exploring regulation documents, identifying referencing compliance rules and synchronizing external regulation documents with those stored in the version control system. The task of adapting compliance rules according to changes in regulations is supported by populating the Eclipse platform’s task list with detected changes. Changes are categorized into new, changed, and deleted parts. The associated tasks can be scheduled, enriched with notes, and finally be marked as completed in the task list. Besides, the change detection component can be used to perform some activities in an automated way, e.g. deleting rules when the corresponding regulation parts have been deleted.

4.2 Case Study

In order to evaluate the approach, we conducted a case study in cooperation with a German insurance company. The prototype implementation has been used to model the complete process of insurance contract conclusion on the basis of respective one year old regulation documents. Figure 1 shows an excerpt from this process. The whole process covers additional aspects like declaration of intent, contractual agreement, periods for acceptance, revocation, etc. It is divided in 5 subprocesses and comprises 72 tasks in total. We then derived 43 compliance requirements pertaining to the process model from mandatory law (ius cogens). We modeled them as compliance rules and linked them with the regulations. Figure 2 shows one of these rules. After this, we adopted the process to the specific requirements and context of the insurer. The compliance rules were used to verify that the process remains compliant despite the adjustments. Finally, we took the current versions of the regulation documents and used the change detection tool to discover relevant changes in the linked laws. Several changes were detected and shown as tasks to the modeler. Most of the changes in law did not affect the compliance rules or the process, anyway, two changes required to change rules, and one change finally required to adapt the process model in order to be compliant with the rule and thus the regulation again.

4.3 Results

The case study has shown that traceability is an important feature in the design of RCM solution which supports us in the following RCM-related activities:

  • Performing reviews of compliance rules and justify the existence of a particular compliance rule by providing a reference to the parts of regulation where the rule is derived from.

  • Performing compliance completeness analysis for a particular regulation by identifying all compliance rules that are derived from this particular regulation.

  • Analyzing the validity of changes in a compliance rule. As the parts of regulation can be traced back, it is easier to check if the rule is still in compliance with the regulation after changes are applied to the rule.

  • Analyzing the impact of a change in the regulation. As all derived compliance rules for that regulation can be identified, it is possible to decide which rules have to be adapted according to the changes in regulation.

The overall maintainability of compliance rules is increased significantly by these aspects. However, the evaluation has also revealed some limitations. A set of restrictions is inherited from existing compliance management solutions. Issues such as the model construction problem when creating formal models or the state explosion problem connected with model checking [12] apply equally to the presented approach. Another substantial aspect is the level of automation. Change detection helps in detecting changes in regulations, but the decision if these changes require the adaptation of compliance rules and the adaptations themselves still remain mainly manual tasks. A higher level of automation is still desirable.

5 Conclusion

Traceability and change management are important requirements on RCM solutions with regard to minimizing the cost of maintenance of compliance requirements. In this paper, we presented an approach to integrate these aspects into existing RCM solutions. The components and steps comprised in the approach were presented, and the feasibility of the approach has been verified in a case study in the context of insurance companies.

All in all, the approach is a feasible way to ensure up-to-date compliance rules. Traceability supports the alignment of regulations and compliance rules, which improves the overall maintainability of compliance requirements. Actually, we are working on increasing the level of automation of the approach.