In this paper we report on the development and evaluation of a business process compliance checker, based on the compliance-by-design methodology proposed by Governatori and Sadiq [9]. For a screencast see http://www.youtube.com/watch?v=gFmDQJNai_4
Regulatory compliance is the set of activities an enterprise does to ensure that its core business does not violate relevant regulations, in the jurisdictions in which the business is situated, governing the (industry) sectors where the enterprise operates.
The activities an organisation does to achieve its business objectives can be
understood as business processes, and consequently they can be represented by business
process models. On the other hand a normative document (e.g., a code, a bill, an act) can
be understood as a set of clauses, and these clauses can be represented in an
appropriate formal language. Based on this [
To gain compliance different strategies can be devised. [
Detective measures are intended to identify “after-the-fact” un-compliant situations. There are two main approaches: (a) retrospective reporting through manual audits by consultants or through IT forensics and Business Intelligence tools; (b) automated detections generating audit reports against hard-coded checks performed on the requisite system. Unlike the first approach, automated detection reduces the assessment time and consequently also the time of un-compliance remediation/mitigation.
Corrective measures are intended to limit the extent of any consequence caused by un-compliant situations. For example, situations that can arise from the introduction of a new norm impacting upon the business, to the organisation coming under surveillance and scrutiny by a control authority or to an enforceable undertaking.
The two approaches above suffer from lack of sustainability, caused by the extreme
interest of companies in continuous improvements of the quality of services, and for
changing legislations and compliance requirements. Indeed, even with automated
detection means, the hard coded checking of repositories can quickly grow to a very large
scale making it extremely difficult to evolve and maintain. To obviate these problem
[
The key aspect of the compliance-by-design methodology is to supplement business process models with additional information to ensure that a business process is compliant with relevant normative frameworks before the deployment of the process itself.
In this section we first introduce the architecture of BPCC, a business process
compliance checker based on the business process compliance methodology proposed by
Governatori and Sadiq [
As we have already discussed to check whether a business process is compliant with a relevant regulation, we need an annotated business process model and the formal representation of the regulation. The annotations are attached to the tasks of the process, and it can be used to record the data, resources and other information related to the single tasks in a process.
For the formal representation of the regulation we use FCL [
1, … , ⇒
Where 1, … , are the conditions of applicability of the norm/rule and is the
normative effect of the norm/rule. FCL distinguishes two normative effects: the first is that
of introducing a definition for a new term. For example the rule
(), () > 1000 ⇒
_()
specifies that, typically, a premium customer is a customer who has spent over 1000
dollars. The second normative effect is that of triggering obligations and other deontic
notions. The deontic notions covered by FCL are obligations1, permissions, and reparation
chains. For obligations FCL supports both maintenance obligations and achievement
obligations, and for achievement obligations both pre-emptive and non-pre-emptive
obligations (see [
It is worth noticing that FCL allows deontic expression (but not reparation chains) to appear in the body of rules, thus we can have rules like: , [P] _ℎ ⇒ [OM]ℎ _ ⊗ [OAPNP] _.
The rule above means that if a restaurant has a license to sell alcohol (i.e, it is permitted
to sell it, [P] _ℎ ), then it has a maintenance obligation to expose the license
([OM]ℎ _ ), if it does not then it has to pay the fine ([OAPNP] _ ). The
obligation to pay the fine is non-pre-emptive (this means it cannot be paid before the
violation). For full description of FCL and its feature see [
base & checker Legalese Formalisation Rule1
...
Input
Obligations tr o p e r s u tt a
S
Finally, FCL is agnostic about the nature of the literals it uses. They can represent tasks (activities executed in a process) or propositions representing state variables.
Compliance is not just about the tasks to be executed in a process but also on what the
tasks do, the way they change the data and the state of artifacts related to the process, and
the resources linked to the process. Accordingly, process models must be enriched with
such information. [
Recommendations
Figure 1 depicts the architecture of BPCC. Given an annotated process and the
formalisation of the relevant regulation, we can use the algorithm propose in [
representation Annotated process model s i s y l a n a ifta h W
I*(e1) I*(e2) I*(e3) I*(e4) ...
• determine which obligations have been fulfilled, violated, or are pending; and if there are violated obligation check whether they have been compensated. – repeat for all traces.
A process is compliant if and only if all traces are compliant (all obligations have been
fulfilled or if violated they have been compensated). A process is weakly compliant if
there is at least one trace that is compliant.
BPCC is implemented on top of Eclipse. For the representation of process models, it
uses the Eclipse Activiti BPMN 2.0 plugin, extended with features to allow users to add
semantic annotations to the tasks in the process model. BPCC is process model agnostic,
this means that while the current implementation is based on BPMN all BPCC needs is
to have a description of the process and the annotations for each task. A module of BPCC
take the description of the process and generates the execution traces corresponding to
the process. After the traces are generated, it implements the algorithm outlined in the
previous section, where it uses the SPINdle rule engine [
BPCC was tested against an 2012 Australian Telecommunications Customers Protection Code (C628-2012). The code is effective from September 1st 2012. The code requires telecommunication operators to provide annual attestation of compliance with the code staring from April 1st 2013. The evaluation was carried out in May-June 2012. Specifically, the section of the code on complaint handling has been manually mapped to FCL. The section of the code contains approximately 100 commas, in addition to approximately 120 terms given in the Definitions and Interpretation section of the code. The mapping resulted in 176 FCL rules, containing 223 FCL (atomic) propositions, and 7 instances of the superiority relation. Of the 176 rules 33 were used to capture definitions of terms used in the remaining rules. Mapping the section of the code required all features of FCL: all types of obligations apart punctual obligations were used, reparation chains, permissions, defeasibility to easily capture exceptions, and obligations and permissions in the body of rules.
The evaluation was carried over in cooperation with an industry partner subject to the code. The industry partner did not have formalised business processes. Thus, we worked with domain experts from the industry partner (who had not been previously exposed to BPM technology, but who were familiar with the industry code) to draw process models for the activities covered by the code. The evaluation was carried out in two steps. In the first part we modelled the processes they were. BPCC was able to identify several areas where the existing processes were not compliant with the new code. In some cases the industry partner was already aware of some of the areas requiring modifications of the existing processes. However, some of the compliance issues discovered by the tools were novel to the business analysts and were identified as genuine non-compliance issues that need to be resolved. In the second part of the experiment, the existing processes were modified to comply with the code based on the issues identified in the first phase. In addition a few new business process models required by the new code were designed. As result we generated and annotated 6 process models. 5 of the 6 models are limited in size and they can be checked for compliance in seconds. The largest process contains 41 tasks, 12 decision points, xor splits, (11 binary, 1 ternary). The shortest path in the model has 6 tasks, while the longest path consists of 33 tasks (with 2 loops), and the
Fig. 4. BPCC report of traces, rules, and tasks responsible for non-compliance longest path without loop is 22 task long. The time taken to verify compliance for this process amounts approximately to 40 seconds on a MacBook Pro 2.2Ghz Intel Core i7 processor with 8GB of RAM (limited to 4GB in Eclipse). 4
We reported on the development of a tool, BPCC, for checking the compliance of
business processes with relevant regulations. The BPCC was successfully tested for real
industry scale compliance problems. In the recent years, a few other compliance
prototypes have been proposed: MoBuCom [
NICTA is funded by the Australian Government as represented by the Department of Broadband, Communications and the Digital Economy and the Australian Research Council through the ICT Centre of Excellence program.