1 Introduction

Organizations are operating in an increasingly complex and dynamic business environment. Globalization, new economic challenges, rapid advancements in information technologies, and the requirements of inter-organizational cooperations are only some of the challenges that organizations are facing today (Mohamed and Lashine 2003). Moreover, with possibly conflicting interests and values, organizations are under the pressure to comply with an increasing number of external regulations imposed by various governmental authorities (zur Muehlen et al. 2007). In this context, organizations need to design and adjust their business processes accordingly, ensuring that their organizations operate properly within the boundaries delineated by the governmental regulations. Otherwise, undesired consequences might occur such as financial losses, unhealthy goods being released into free circulation, and environmental damages (Binder Dijker Otte Co 2011).

To achieve regulatory compliance, organizations first need to understand the design purposes of business processes and governmental regulations as well as their relations. Business processes are designed and implemented by the organizations to guide and to regulate business operations, aiming at improving work efficiency by normalizing the actors’ behavior. On the other hand, governmental regulations are formulated and imposed by legal authorities to ensure social welfare, protect local interests, and regulate business activities. Compared to business processes, governmental regulations concentrate on the effects (what should (not) be done) often without providing the implementation details (how it should be done). Table 1 gives a comparison of the two concepts.

Table 1 Governmental regulations and business processes
Full size table

With different concerns, business processes are likely to deviate from what are desired by governmental regulations. Moreover, with the rapid development of new technologies, existing regulations might be changed, and new regulations might be imposed. To these ends, it is necessary to verify, on the one hand, whether business process designs are in accordance with the imposed regulations before they are implemented, and on the other hand, whether the implemented business processes are still compliant with respect to the changes of the regulations. In this sense, regulatory compliance is a lasting process rather than a once and for all step. Furthermore, regulations can be fairly complex in terms of the conditions, targets, and scopes they refer to. When considering a set of regulations, the possibility of interrelationships between them brings added complexity to compliance checking. As such, the following requirements are identified for verifying regulatory compliance of business processes:

  • a separate representation of the imposed regulations and their compliance relations,

  • a separate representation of the business processes,

  • automatic checking and analysis of compliance properties of the business processes with respect to the imposed regulations.

Given these requirements, in this paper, we propose a consistency and compliance checker framework (CCCF) which aims at providing automated supports for organizations to analyze and verify their regulatory compliance. CCCF is based on the theories of normative multi-agent systems where norms like obligations, permissions, and prohibitions have been proposed to deal with coordination and security issues of multi-agent systems (Andrighetto et al. 2012). Normative multi-agent systems provide potential approaches for modeling regulated business environments where organizational actors can be described as autonomous agents, and regulations can be captured by the normative constraints directing the behavior of the agents.

In a nutshell, CCCF captures organizational actors by the notion of agents and captures regulations by the notion of norms (obligations and prohibitions). Moreover, CCCF not only provides the components for representing single normative constraints but also their compliance relations. To indicate organizational interactions, CCCF uses the concept of event sequence to represent the possible behavioral traces that can be abstracted from a business process. With these formalisms, a consistency and compliance checker toolbox (CCCT) is implemented based on the formal semantics of colored Petri nets (CPNs) (Jensen 1997). Using the available techniques and tools of CPNs, CCCT is able to provide information about whether the set of imposed regulations are self-consistent, whether the business process is compliant with the imposed regulations, and which business operations need to be adjusted in case of non-compliance.

The remainder of the paper is organized as follows. In the next section, we present the outline of the CCCF. In Sect. 3, we give an introduction of the case study used in this paper to illustrate our approach. In Sect. 4, we introduce the formalisms that we use to represent legal regulations and business processes. In Sect. 5, we show the working mechanism of the consistency and compliance checker toolbox. In Sect. 6, we evaluate our approach by applying it to the case study. In Sect. 7, we discuss the applicability as well as the limitations of our approach. Related work is discussed in Sect. 8. Finally, we conclude the paper and identify directions for future work in Sect. 9.

2 Consistency and compliance checker framework (CCCF)

CCCF is a framework for modeling regulations with the purpose of verifying regulatory compliance of business processes. It provides an integrated view of the interplay between legal regulations and business processes by introducing a suite of models and methods.

The design of CCCF is shown in Fig. 1, which is guided by the three requirements specified in Sect. 1. At the top level, on the one hand, we assume a set of legal regulations, which can usually be obtained from the legislation, and describe the (un)desired behaviors for the actors in the form of a natural language. On the other hand, we assume a business process that presents how business operations are ordered and can be described using any process modeling language such as BPMN (Allweyer 2010), YAWL (van der Aalst and ter Hostede 2004), EPC (Keller et al. 1992), etc. For the formalization of legal regulations, we adopt a normative structure Norm Nets (NNs) to model the regulations and their compliance relations. The translation from the natural language regulations to a formal model is itself a separate research domain (e.g., Lau 2004), which is out of the scope of this paper. Therefore, the transformation from the legal regulations into an NN is based on a manual interpretation in this paper. For business processes, we use the model of event sequence to represent all the possible behavioral traces that can be abstracted from the business process. Similarly, the transformation from a business process into a set of event sequences is manually done in this paper.

Fig. 1
figure 1

Consistency and compliance checker framework

Full size image

Using NNs, the set of regulations can be formalized into a normative specification. With respect to the business process, we can abstract all the possible behavioral traces and represent them by a set of event sequences. Compliance checking is then to check whether there are any non-compliances in each event sequence according to the normative specification. If there are non-compliances, it means that the business process is not correctly designed. However, it is also possible that the normative specification itself is not consistent. That is, some actions are obliged and forbidden simultaneously. If this is the case, no matter how the business process is designed, it will violate the normative specification. Therefore, a prerequisite for compliance checking is that the set of regulations should be self-consistent. As such, we implement a toolbox CCCT which on the one hand will take the set of imposed regulations as inputs and verify whether there are any inconsistencies, and on the other hand will take both the regulations and the business process as inputs and verify whether there are any non-compliances.

The results obtained from CCCT will be transferred back to the initial inputs: the legal regulations and the business process. The information on inconsistencies can provide evidences for the re-formulation of the regulations. The information on non-compliances can help process designers to adjust their designs in order to achieve regulatory compliance. The whole process is following a feedback loop such that whenever there is anything changed in the regulations or the business process, compliance checking has to be performed accordingly.

3 Case study

Customs declaration (European Commission 2013c) is one of the crucial steps in international trade. Any organization whose business involves import and export activities needs a clear understanding of the imposed regulations, as they may affect the performance of the trading process in terms of lead time, cost, and reliability. Typical activities involved in customs declarations are related to the registration, checking, and control of movements of goods. Customs authorities and declarants are the two main parties involved in the customs declaration processes. The customs authorities have the responsibility of monitoring and controlling goods importation and exportation. Their main interest is to make sure that the import and export processes are in accordance with the legal regulations. On the other hand, the declarants have a strong demand of a fast and smooth customs declaration process since it can shorten the delivery time and improve the cost efficiency and reliability of their supply chains.

During the declaration process, changes may occur due to any differences between the declaration statement and the corresponding requirements. For example, the customs may find that the declaration is incorrect based on the inspection results, which may result in a correction of the declaration by the customs (and potentially will lead to a fine). To ensure customs compliance, a large number of regulations is imposed to restrict the behavior of both declarants and customs authorities. In this case study, we consider a summary of regulations, reflecting a subset of the European Customs Community Code and the Implementing Provisions (European Commission 2013b), in which there are about 350 articles. For some types of declarations, more than 50 activities can be identified. To illustrate our approach, we take a part of the regulations as a case study, described as follows.

  • R1. If the customs informs the declarant that the goods need to be physically controlled, the declarant must not make changes to the declaration.

  • R2. If the customs finds out any errors in the declaration, the declarant must not make changes to the declaration.

  • R3. After the customs releases the goods, changes to the declaration are not allowed.

  • R4. If customs debt is incurred and there is no temporary admission for the goods, the customs is forbidden to release the goods before the amount of the customs debt has been paid or the whole amount has been secured by the declarant.

  • R5. If the declarant submits an incomplete declaration, the declarant must include in the declaration data for the identification of the goods and the amount of the goods, otherwise the customs should not accept the declaration.

  • R6. If the declarant submits an incomplete declaration and the customs releases the goods, the declarant should submit the supplementary documents within one month at most after the acceptance of the declaration.

This set of regulations set strict rules for both declarants and customs authorities. From the perspective of the customs authorities, it is their responsibility to ensure that the submitted declarations cannot be changed and the goods cannot be released before the customs debt has been paid or secured. From the perspective of the declarants, they have to make sure that the submitted declarations contain the required information and that the supplementary documents are submitted on time in case of incomplete declarations.

In this scenario, the customs always needs to react to different conditions. High ratio of mistakes and delays of customs operations may lead to financial losses for business companies and decrease the economic competitiveness of the country. To this end, customs authorities have a strong need for a declaration management system to handle all the processes from receiving the declaration, validating the declaration, performing risk assessment to clearing the declaration. As an example, Fig. 2 shows a piece of business process for managing customs declaration modeling in BPMN. This piece of process is to determine whether a received declaration complies with the set of validation rules which are applicable for accepting a declaration. The process starts when a declaration has been received and continues with a sub process of “validate declaration”. Based on the validation results, the declaration will be processed differently.

Fig. 2
figure 2

A piece of business process for managing customs declaration

Full size image

4 Formalization: norm nets and event sequences

4.1 Representation of legal regulations

Legal regulations usually describe what should (not) achieve rather than how to achieve it. In normative multi-agent systems, norms are used to specify the (un)desired behavior for agents in terms of obligations, prohibitions, and permissions. Both regulations and norms have a declarative nature, and applying normative structures to the modeling of regulations has been explored by a number of researchers (D’prile et al. 2010; Governatori and Rotolo 2010). In this section, we briefly introduce the normative language NNs proposed in (Jiang et al. 2013a, b), which is adopted in CCCF to formalize legal regulations.

The basic components in NNs are role-action pairs which describe the actions available to the roles specified in an organization. For example, we can express the statement “declarant submits a declaration” by defining a role-action pair (declarant, submit_declaration). Moreover, to capture the possible relations between role-action pairs, the role-action pair language L RAP is defined by introducing the operators and (∧), or (∨), before (< ). Based on the role-action pair language, NNs provide a formalism of representing regulations by two types of instances.

The first type is called singular norm net or norm, which consists of four components, i.e., deontic type, target, deadline, and precondition. Deontic type can be either obligation or prohibition, respectively denoted by O and F. The target is represented by a role-action pair, indicating that an action is obliged or forbidden for a role by the norm. Both the deadline and the precondition are built over the role-action pair language, in which the precondition determines when the target is activated and the deadline determines until when the target of an obligation has to be ensured or when the target of a prohibition ceases to be forbidden. Given that the precondition is activated, if the obliged target is not ensured at the moment that the deadline occurs, a violation will be caused. As for a forbidden target, a violation is caused as soon as the target is brought about before the deadline occurs. If a norm does not specify a particular precondition, the interpretation is that it always holds. Without a particular deadline, the value is the whole life cycle of a system, since without a deadline one can never determine whether an obligation is violated.

The second type is called composite norm net, which recursively combines two norms or NNs into a new norm net according to their compliance relations, i.e., AND (conjunction), OR (disjunction), and OE (reparation/sanction). AND(NN, NN) indicates that both component NNs should be complied with and the violation of either NN will result in a violation to the system. OR(NN, NN) indicates a choice between the component NNs and only when both NNs are violated, the system is considered as violated. OE(NN, NN) indicates that the component NNs are conditional and exclusive, i.e., (1) only when the first NN is violated can the second NN be triggered, and (2) the violation of the first NN can be repaired by the fulfillment of the second NN or the second NN is a sanction of the violation of the first NN.

For example, given the regulations R1 and R2 described in Sect. 3, we know that if the customs informs about the physical control on the goods (inform_control), the declarant is not allowed to change the declaration (change_declaration), and if the customs finds any errors in the declaration, the declarant is not allowed to change the declaration as well. Accordingly, we can construct a norm net NN 1 = AND(n 1, n 2) where

  • n 1 = (F, (Declarant, change_declaration), (Customs, clear_declaration), (Customs, inform_control)),

  • n 2 = (F, (Declarant, change_declaration), (Customs, clear_declaration), (Customs, find_errors)).

Notice that we construct two norms with an AND relation for R1 and R2 to prohibit the declarant from making changes to the declaration.

4.2 Representation of business processes

A business process is a collection of related, structured activities or tasks that realize a specific objective (Weske 2007). Following such business processes, actors in the organizations take specific roles and perform process-related actions. A business process usually consists of several alternative sequences of activities according to different conditions. In our approach, we use the concept of event sequence to capture all these alternatives.

An event sequence ES is defined as a sequence of events, each of which is captured by a role-action pair describing a fact that an action is available to a role. The sequence of events is an abstraction of the actors’ behavior and presents a temporal order of who does what with respect to a business process. As an example, given the business process shown in Fig. 2, we can abstract the following event sequences:

  • \(ES_1 = \langle(customs, validate\_declaration), (customs, accept\_declaration), (customs, notify\_acceptance)\rangle\),

  • \(ES_2 = \langle(customs, validate\_declaration), (customs, report\_errors), (customs, reject\_declaration), (customs, notify\_rejection)\rangle\),

Notice that there is only one role in this event sequence, i.e., customs. The reason is that the corresponding piece of business process is designed from the perspective of a customs agency to process the declarations submitted by declarants. In this sense, the actions are mostly performed by the actors in the customs agency.

5 Operationalization: consistency and compliance checker toolbox (CCCT)

In the previous section, we have shown the formalizations for legal regulations as well as business processes adopted in CCCF. It can be seen that the link between the two formalisms is events describing the actions available to roles. Operationally, if an actor is assigned a role, from the perspective of the business process, the actor is permitted to perform the actions that are available to the role. However, from the perspective of the legal regulations, some of the actions might not be granted to the actor under specific conditions. Compliance checking is then to determine whether the behavior of the organizational actors enacting specific roles are in accordance with what are desired by the regulations. Moreover, to make sure that non-compliances in business processes are avoidable, we need to verify whether the set of regulations itself is consistent.

Following the approach in (Jiang et al. 2013a, b), we implement the consistency and compliance checker toolbox in CCCF based on the operational semantics of CPNs (Jensen 1997). To do this, on the one hand, we build a CPN model for a given set of regulations according to its formalization in NNs and the mapping rules from NNs to CPNs. On the other hand, we abstract the set of all possible event sequences from a given business process. Thereafter, we can verify the compliance of the business process against the set of regulations as follows:

  1. 1.

    given an event from an event sequence, fire all the enabled transitions in the CPN model corresponding to the event and update the marking of the CPN model,

  2. 2.

    if the new marking of the output place labeled v in the CPN model (indicating the overall violated state of the corresponding NN) is not empty, then the corresponding NN is evaluated to be violated,

  3. 3.

    otherwise, if there exists a place in the CPN model whose label starts with vr (indicating the repairable violation state of the corresponding NN) and whose new marking is not empty, then the corresponding NN is evaluated to be sub-ideally complied,

  4. 4.

    otherwise, the corresponding NN is evaluated to be complied.

Given an event sequence, the marked CPN model of the NN is able to run accordingly. Each event in the event sequence might cause a change to the marking of the CPN model and thus the compliance state of the NN. From the resulting markings, we know the influence of the event sequence on the compliance state of the NN. That is, we can determine whether a specific business process is complying with a set of regulations. If and only if the compliance evaluation is complied at all steps, the given event sequence is considered as fully compliant with respect to the NN. Full compliance is important for regulated business environments because the reparation of a violation may still cause a heavy loss to the actors. Therefore, from the perspective of business process designers, it is necessary to verify whether a business process can achieve a full compliance against all the relevant regulations.

Compliance checking of event sequences can tell whether a business process is compliant with a set of regulations. However, when non-compliances are identified, it is not always the case that the business process is not correctly designed since the set of regulations itself might be inconsistent. Thus, we also need to check whether the latter case is true. To do this, we make use of the CPN model of an NN and check in its state space whether there is a full-compliant event sequence by the following steps.

  1. 1.

    given the CPN model with the initial marking, find all the enabled transitions in the CPN model and group them by their labels (those transitions indicating the same actions are grouped together),

  2. 2.

    if there is no enabled transition, then the corresponding NN is consistent; otherwise, it is consistent if and only if there exists a group of transitions obtained from step 1 such that,

    1. (a)

      after firing all the transitions in the group, the new markings of the output place labeled v and all the places whose labels start with vr in the CPN model are empty and,

    2. (b)

      with respect to the CPN model with the new marking, the corresponding NN is consistent.

When an NN is evaluated to be consistent, the corresponding set of regulations is consistent. Moreover, such a process of determining consistency can also be used to find full-compliant event sequences, which might be useful to provide prior knowledge for process designers.

6 Evaluation

In this section, we will illustrate how our approach is used by applying it to the case study described in Sect. 3.

6.1 Modeling legal regulations

In Sect. 3, we have chosen a set of six regulations from the legislation. Each article in these regulations can be represented by an NN. The process of modeling a single article with NNs is actually the process of defining the deontic types, targets, deadlines, preconditions, and logical connections between norms according to the semantics of the regulations. Such an interpretation process in this work is realized manually, and its correctness is highly dependent on the interpreter’s knowledge of the legislation as well as the construction of NNs. To this end, we consulted domain experts to confirm our interpretation which is formalized as a norm net denoted by NN case . As an illustration, here we show the modeling of a regulation which features a sanction relation between two norms.

According to R5, there is a special type of declaration submissions, i.e., the declarant is allowed to submit an incomplete declaration (submit_incompDeclaration). If this is the case, the declarant should include the identification information of the goods, otherwise the customs should not accept the declaration, as specified by R5 and represented by NN 2 = OE(n 3, n 4) where

  • n 3 = (O, (Declarant, add_identification), (Customs, accept_declaration), (Declarant, submit_incompDeclaration)),

  • n 4 = (F, (Customs, accept_declaration), (Customs, clear_declaration), ∅),

This piece of norm net model indicates two norms with an OE relation, in which norm n 4 is the sanction of the violation of n 3. The ∅ symbol in n 4 represents that the precondition component of n 4 is null.

6.2 Modeling business process

The whole declaration management process consists of a large number of decision points, activities, and sub-processes. Our task in this step is to abstract all the events that are relevant to the control of the considered regulations and find their corresponding positions in the declaration management process. Once we know all the possible positions of the events in the process, we can organize them into event sequences according to the order of their appearances in the process. Later on we use these event sequences as inputs to the CPN model of NN case to indicate the firing order of the transitions such that we can determine the compliance of the business process.

After discussing with the process designer, we abstract seven event sequences from a part of the declaration management process, which indicate different solutions for managing declarations according to different conditions. As an illustration, here we give one example that is of interest for the compliance checking results.

  • \(ES_3 = \langle(customs, receive\_declaration), (customs, validate\_declaration), (customs, accept\_declaration), (customs, notify\_acceptance), (customs, asses\_risk), (customs, inform\_control), (customs, perform\_control), (customs, report\_minorDiscrepancy), (customs, accept\_changes), (customs, clear\_declaration)\rangle\).

It can be seen that in this case, some of the events in the business process are named differently from that in the regulations. Therefore, we have to find the correspondences between the events specified in the business process and the events specified in the regulations. To do this, we first abstract all the events (role-actions pairs) specified in the regulations, as shown by the second column in Table 2. Thereafter, we associate these events with their corresponding events in the business process, as shown by the third column in Table 2.

Table 2 Events in the regulations and their counterparts in the business process
Full size table

Notice that in the event sequence ES 3, there are ten events, while only five of these events have their counterparts in the regulations. The reason in this case is that we only take a part of all the relevant regulations. But in other cases, it could also be that not all the events specified in a business process are covered by the regulations.

6.3 Applying CCCT

Up to now, we have constructed the norm net model for the regulations and abstracted the event sequences from the business process. The task then is to converge these two information flows into CCCT such that we can verify whether the business process is complying with the regulations (consistency can be derived from the compliance results by checking whether any of the abstracted event sequences is full compliant in this case study). To do this, we firstly build the CPN model of NN case following (Jiang et al. 2013a, b) using CPN tools (Jensen et al. 2007). Secondly, we input each event sequence into the CPN model (which stands for regulation information) such that the transitions corresponding to the events in the event sequences will be fired in the order of their appearances (which stands for process information). Notice that in this step, we have to map the events specified in the business process to the events specified in the regulations according to their connections identified in Table 2. After the firing of each event, we can check whether there are tokens in the featured places of the CPN model to determine whether the business process is compliant with the regulations following the steps described in Sect. 5.

After running the checking procedure against all the event sequences, we found one token in the output place labeled V in the CPN model of NN case , which means that there is a non-compliance between the declaration management process and the regulations. This non-compliance is caused by the event (Declarant, change_declaration) from the perspective of the regulations. Going back to the event sequences, we found an event (Customs, accept_changes) in ES 3 which is a corresponding event from the perspective of the business process. Accordingly, in the document of the business process, we found a description “The customs will hand over the control result to a specialist who will take a customs position by determining whether the control resulted in [\(\ldots\)] a minor discrepancy, in which case he will ask an assistant to correct the declaration or instruct the declarant to do so.”

Further investigation on the CPN model shows that this non-compliance is caused by the violation of norm n 2 relating to regulation R2. The reason is that the regulation says if the customs finds out any errors in the declaration, then the declarant is forbidden to change the declaration. However, in the business process, it is possible for the customs or the declarant to make changes to the declaration when there are only minor discrepancies. From the compliance checking results, we know that only one of the abstracted event sequences is not compliant, while the others are fully compliant. Therefore, we can conclude that the set of regulations is consistent.

6.4 Reflection

From the case study, we can see that compliance checking is necessary yet complicated. There are several issues that have to be considered in applying compliance checking approaches.

  • It is a large amount of work to interpret legal texts even with domain knowledge, especially when we are not only considering the contents of single regulations but also their interrelations. In this case, it would be desirable if we can establish standard management systems for the regulations such that compliance checking processes can be facilitated.

  • One needs to have a sufficient understanding of the design objectives of a business process when abstracting event sequences from the business process. It is not the case that the process is just a simple set of activities. Instead, there might be a lot of decision points and sub-processes. As such, we need to cross over different parts of the process to determine the right alternative paths.

  • Regulations usually cover organizational behavior from a broader sense, while a business process is often designed from the perspective of a specific organization and thus might have a single view of the interactions with other organizations. This often leads to a need for concept alignments between the specification of the regulations and that of the business process.

With automated support for regulatory compliance, it is convincing that the workload of compliance departments can be reduced. Their work will change from multiple tasks related to compliance checking procedures to the focus on maintenance of regulation management systems and analysis of optimizing process designs. Moreover, organizations can make their business processes more reliable in terms of regulatory compliance. On the other hand, the control and maintenance cost of governmental authorities can also be reduced, with the possibility of providing integrated services (e.g., regulation interpretation, consultation, risk management, etc.).

7 Discussion

With automated support for regulatory compliance, organizational efficiency can be improved and social welfare can be facilitated. CCCF is designed to achieve such automated support in a sustainable way. On the one hand, the consistency management of regulations can provide a reliable basis for compliance checking. On the other hand, the compliance management of business processes can assist organizations to adjust their business operations, and in some cases can be used as evidences to show their compliance capabilities, e.g., the authorized economic operator (AEOFootnote 1) program (European Commission 2013a).

Regulations can come from different sources, many of which are updated constantly (Boella et al. 2013), and it is very difficult for organizations to keep track of relevant legislations. This makes it difficult in realizing compliance checking approaches and obtaining satisfactory results. Even if we have the knowledge of all the regulations that are relevant for the control of the business processes of an organization, we are still confronted with the task of interpreting legal text. As for our approach, there are several limitations:

  1. 1.

    The transformation from natural language regulations to NNs is done manually and highly dependent on people’s domain expertise. For example, the deontic types and the vocabularies used in regulations are not a strictly one-to-one mapping. Words like “must,” “ought,” “allow” can have a variety of meanings, and their appearances in legislative text are not themselves a sufficient reason to determine the deontic type of a norm. To this end, we have to rely on domain experts for accurate interpretation.

  2. 2.

    Not all regulations have clear normative components. For example, sometimes deadlines are not explicit. Without deadlines, it is impossible to determine whether an obligation is violated. For this problem, our current solution is: if there is no explicit deadline in the regulation, we will set the deadline to be the last event that occurs in the process. However, this varies from case to case, mistakes and misunderstanding could happen if we do not interpret the regulation or the process correctly.

  3. 3.

    Our operational model is based on CPNs, and the compliance checking results are shown in the form of the markings of CPN models. Such compliance information is not general enough to be communicated in the organizations across disciplines. For this, we still need to adapt our approach such that business analysts can easily get started and make use of it.

Admittedly, compliance checking approaches are important for organizations to achieve regulatory compliance. However, compliance-related decisions can be influenced by organizational strategies with consideration of potential costs. Occasionally, organizations may decide it is not worth conforming to certain regulations when the cost of implementation is greater compared with the fine or loss of reputation they would face in case of non-compliance.

8 Related work

Organization are required to take measures for ensuring regulatory compliance (EI Kharbili et al. 2008), which poses new requirements for business process management. To this end, many efforts have been taken in the research of business process compliance checking.

Lohmann (2013) presented an approach to automatically construct business process models that are compliant by design based on an existing artifact-centric framework. This approach uses Petri nets to model artifact life cycles, inter-artifact dependencies, compliance rules, and a role-based access control. Awad et al. (2012) introduced an approach to synthesize business process templates out of a set of compliance rules expressed in linear temporal logic. The approach also shows how analysis is conducted if the compliance rules are inconsistent. Sadiq et al. (2007) proposed to use the formal contract language (FCL) proposed in Governatori and Milosevic (2006) to express normative specifications and introduce the notion of compliance distance to measure how much a particular instance deviates from the expected behavior.

Process mining techniques are widely used for compliance checking to find commonalities and discrepancies between the modeled behavior and the observed behavior (van der Aalst 2011). For example, van der Aalst et al. 2012 and Ramezani et al. 2012 proposed to check compliance by aligning the observed behavior described in event logs with the corresponding Petri-net patterns of compliance rules concerning control-flow, data-flow, and organizational aspects. (van der Aalst et al. (2011) presented an architecture of an online auditing tool in which business rules are translated in a straightforward way into queries that can be executed against the database consisting of three types of data (run time data, de jure models, and de facto models).

Our work is based on the formal theories of normative systems (Andrighetto et al. 2012; Meyer and Wieringa 1993), which provide a precise and unambiguous specification of regulations in terms of normative constraints. More importantly, we take an integrated view on regulatory compliance of business processes by (1) providing a unified framework to capture both regulations and business processes, (2) formalizing and analyzing the impact of the compliance relations between regulations on business processes, and (3) employing an operationalization that realizes both consistency checking and compliance checking.

9 Summary and future work

In this paper, we propose CCCF for verifying regulatory compliance of business processes. CCCF provides formalisms for representing both regulations and business processes, which are integrated in a structured way. Additionally, a toolbox is developed based on the mapping from the two formalisms NNs and event sequences to CPNs. The toolbox is not only able to verify whether business processes are in accordance with a set of interrelated regulations, but also verify whether the set of regulations itself is consistent.

CCCF aims at providing automated support for analyzing and verifying compliance properties of business processes. It can be used by people such as business analysts, process designers, and compliance officers in assisting their decision making. Moreover, CCCF provides a general solution for the problem of regulatory compliance in the sense that we can replace NNs with some other formal models to represent regulations, and similarly for the representation of business processes and the operationalization of compliance checking.

In future work, there are a number of issues to be studied. Firstly, we are trying to enrich the expressiveness of NNs by considering more relations such as priorities over different regulations. Secondly, we intend to apply more advanced CPN models for the operationalization of NNs, such as using timed CPNs to capture time elements and using hierarchical CPNs to capture regulations with different abstraction levels. Thirdly, we will make use of the available methods to fill the gap of interpreting natural language regulations into NNs. Fourthly, we are exploring a general way of transforming business processes into event sequences.