Collection and Elicitation of Business Process Compliance Patterns with Focus on Data Aspects

Figure 1 shows the six phases of a BPC life cycle based on the phases of compliance as set out in Awad (2010). It starts with the Regulation identification as first phase where regulations, laws, standards, and guidelines are scanned to spot the ones relevant for the respective purpose. In the second phase Constraint elicitation, constraints are extracted from the relevant regulatory documents. Not knowing which constraints an organization has to comply with, might lead to violations of those constraints. Consequences can be fines, economic disadvantages, and reputation damage. Risk & formalization assessment represents the third phase in which the determined constraints are evaluated in accordance with their impact on an organization in case of violation. Furthermore, the possibility of formalization is analyzed for each constraint and a decision is made which constraints are formalized. In the fourth phase of Constraint formalization the selected constraints are formalized using different formal approaches [e.g., Linear temporal logic (LTL), Event calculus (EC), Complex event processing (CEP)]. The fifth phase is Constraint verification which checks if the regulatory constraints imposed on business processes are fulfilled. Many approaches exist for compliance verification (e.g., Awad et al. 2015; Elgammal et al. 2010; Hashmi et al. 2012; Ly 2016; Ly et al. 2015; Turetken et al. 2011), and can be categorized into design-time, runtime, and ex-post checking of BPC according to Fellmann and Zasada (2014). In the sixth phase of Constraint redesign, existing regulatory constraints have to be adapted due to new or changed laws, standards, or guidelines. For this, regulatory constraints must be continually reviewed and updated. This paper focuses on the phases of constraint elicitation and constraint formalization, which are highlighted in Fig. 1. Constraint elicitation builds the basis for constraint formalization and identifies relevant constraints within regulatory documents. Constraint formalization also means to specify identified constraints in a suitable way that many people in an organization will understand. For this purpose, various approaches propose patterns in general and Compliance patterns (CPs) in particular. For instance, Dwyer et al. (1998) and Turetken et al. (2011) advocate CPs, because complex logic and formal specifications are hidden from business users. Thus, business users become able to understand the meaning behind and make use of the CPs. This property of CPs also fosters the common understanding of a certain, recurring problem/issue between different departments within an organization, for instance between the legal unit and IT which has to implement the defined compliance measures. CPs are independent of approach and language which means that they are universally applicable to and (re)usable for various regulatory constraints. So no extra effort is necessary when changing between different languages and approaches. They also facilitate a solid basis for the analysis of root-causes in case of compliance violations.

CPs offer the right level of abstraction. For furthering BPC support in practice a comprehensive collection of CPs that is based on real-world needs would be crucial. Comprehensive in this context refers to the coverage of typical business process perspectives that CPs might relate to, i.e., control flow (including order and occurrence), data, resources, and time (Ly et al. 2015). Most approaches suggest and use control flow related CPs. Becker et al. (2012) compare different approaches by positioning compliance approaches into the support of CPs of simple, medium, and high complexity where only 2 approaches support highly complex CPs referring to data or time. For instance, precedence and consequence patterns for activities in a business process are used several times as examples (e.g., Awad et al. 2015; Barnawi et al. 2016; Chesani et al. 2008; El Gammal 2012; Yu et al. 2006). The focus of BPC publications on the order and occurrence perspective is also highlighted by Fellmann and Zasada (2014). Some papers also include a small collection of up to 15 CPs (Awad 2010; De Masellis et al. 2014; Namiri and Stojanovic 2007). However, a broader collection and a deeper analysis of existing CPs like done by Caron et al. (2013a) and Ramezani (2017) are rare, although they support the assumption that also process perspectives beyond control flow are crucial for CPs. In addition, only few approaches deal with CPs in the context of more than one domain (Awad 2010; Bernardi et al. 2014; El Gammal 2012; Elgammal et al. 2016; Gong et al. 2016; Ly 2016; Ly et al. 2015; Ramezani 2017), but often lack the elicitation of CPs from those domains. Thus, an investigation of a broad range of regulatory documents is missing.

Overall, this discussion emphasizes the need for a systematic and comprehensive CP collection. This paper takes up this challenge by addressing the following research questions (Qs):Q1 aims to assess the comprehensiveness of existing CP collections. Q2 relates to gaps in the data perspective of business processes regarding coverage of regulatory constraints. In case that CPs which are required from real-world applications are missing in current collections, Q3 aims at filling this gap.

Figure 2 depicts the overall research method employed in this paper including the artifacts created throughout the applied method. Starting point is the goal definition based on the research questions. The literature review performed in the second step identifies existing CPs in research and the current status of research concerning the topic of CPs in general (\(\mapsto\)Artifact 1). All identified CPs are extracted into a uniformed collection of CPs (\(\mapsto\)Artifact 2) as proposed by Caron et al. (2013a). The same procedure is applied to compliance anti-patterns (CAPs) (\(\mapsto\)Artifact 3), which are in most cases the negation of CPs and can be seen as a subset of CPs. In addition, if possible the relation between CP and CAP is established. The legal constraints elicitation step identifies compliance constraints stated in various regulatory documents (\(\mapsto\)Artifact 4). Those legal and regulatory documents are selected due to their generality of application area, their different domains, and their up-to-dateness. The compliance constraints serve as basis to state atomic data-oriented constraints (\(\mapsto\)Artifact 5). The fifth step compares existing CPs to elicited atomic constraints previously identified in Step 3. If constraints cannot be mapped to CPs, they are collected in a separate list of gaps (\(\mapsto\)Artifact 6). The atomic constraints are then further used to derive data-related CPs (\(\mapsto\)Artifact 7). Special focus is on data-related CPs to emphasize the increased importance of data for economic, competitive, and legal reasons. Furthermore, the support of CPs in different domains is analyzed (\(\mapsto\)Artifact 8).

The provided results are supposed to support business users in selecting the CP of interest and need. The results additionally enable users to view the entire set of CPs from various perspectives. The intention is to further the research concerning the root-cause analysis of compliance violations in business processes.

The paper is structured as follows. In Sect. 2 the criteria for and the results of the performed literature review are listed. Section 3 analyzes different legal and regulatory documents that require compliance for data. In Sect. 4 a comparison between current constraint needs and existing CPs as well as the design of new data-related CPs is conducted. The advantages and disadvantages of the applied method and the results of the paper are discussed in Sect. 5. The paper concludes with a summary and an outlook in Sect. 6.

The search process starts with the definition of inclusion and exclusion criteria for literature. Then search strategy and data extraction are determined. Afterwards the literature is synthesized and prepared for reporting.

The inclusion criteria for literature selection are:The exclusion criteria negate the inclusion criteria, but are extended with further criteria:The search strategy is split into three stages with combined usage of inclusion/exclusion criteria (cf. Fig. 3). In the first stage the K.O. criteria Accessibility, Language, and Title of paper exclude non-relevant literature. Those criteria are the entrance criteria for further investigation of the papers. In the next stage the filtered literature is further analyzed based on first content-related criteria to refine the search results. In the selection stage a detailed review of the remaining literature is performed to get the final literature list.

The search strategy makes use of a search engine and applies a horizontal as well as a vertical search. In this context the horizontal search tries to retrieve as many search hits as possible for the given search strings, whereas the vertical search exploits the search hits’ references of the horizontal search as well as experts’ advices to retrieve specific details. The search engine must be online and freely accessible with any device, and must allow as well to search for terms in the title of literature. In addition, the search engine must allow to concatenate search terms with Boolean operators and to search for literature in English only.

The search strategy uses concatenations of search terms to search strings. Search strings allow to narrow the search space, but are also able to cover various variants of search terms (e.g., singular and plural of terms). Kitchenham and Charters (2007) suggest to divide the research questions into separate parts and list “synonyms, abbreviations, and alternative spellings” to find search terms. The following terms are determined according to research questions Q1 and Q2: business, process, compliance, constraint/(anti-)pattern/rule, validation/verification, framework, monitoring, violation, runtime/design-time, mining, rule-based, model-based, and data. Based on them 18 different search strings are composed for the horizontal search. These include the terms listed in Table 1 in various combinations.

In addition to the CPs their description and categorizations/classifications as well as the year of publication are extracted. The latter facilitates the analysis of the domain and publication of literature, and crucial events of recent times (e.g., the financial crisis of 2008).

Based on the criteria for literature selection and search engines a horizontal literature search is performed. For this the search terms must be included in the title of the documents and only documents in English are searched as described in the literature search’s inclusion criteria Language and Title of paper. “Appendix A” lists the detailed results of the horizontal literature search including a list of the selected literature. The three columns correspond to the three search stages. If documents are retrieved multiple times, the first occurrence of a document is listed. Each search term combination is stated in the first column grouped by the date when the search was performed. The second column represents the number of papers retrieved using the corresponding search terms. Out of 798 distinct hits in total, 111 hits are investigated in detail and 34 are finally selected based on the previously defined inclusion and exclusion criteria.

In addition, a vertical search is performed and additional literature is identified by experts (see “Appendix B”) resulting in 17 additional documents in total, out of which 13 documents are finally selected. Altogether, \(34+13=47\) papers form the literature list for further consideration.

The majority of existing approaches includes CPs. Only seven papers explicitly deal with CAPs (Awad 2010; Awad and Weske 2010; Awad et al. 2011, 2015; Barnawi et al. 2016; Montali et al. 2014; Trčka et al. 2009). Lu et al. (2009) use CPs and Bernardi et al. (2014) use CAPs but they do not name them as such. The compliance monitoring/management approaches are applied to or created from different domains such as electronic business (Elgammal et al. 2010, 2016; Papazoglou 2011; Turetken et al. 2011; Yu et al. 2006) or higher education (Lam 2017; Ly 2016; Ly et al. 2015).

Around one third of the papers proposes their own compliance monitoring or compliance management framework (Awad et al. 2015; Barnawi et al. 2016; El Gammal 2012; Elgammal et al. 2016; Giblin et al. 2006; Gong et al. 2016; Ly 2016; Ly et al. 2011, 2015; Maggi et al. 2011; Montali et al. 2014; Papazoglou 2011; Schumm et al. 2010; Thullner et al. 2011; Turetken et al. 2012). Those frameworks mainly try to comprehensively address the topic of compliance verification by checking compliance at design-time (Awad 2010; Awad and Weske 2010; Awad et al. 2009, 2011; Becker et al. 2010; Bernardi et al. 2014; Cheikhrouhou et al. 2014; El Gammal 2012; Elgammal et al. 2010, 2016; Gomez-Lopez et al. 2013; Ly 2016; Ly et al. 2011; Schumm et al. 2010; Stuht et al. 2012; Turetken et al. 2012) or checking compliance based on execution traces at the runtime of a business process (Awad et al. 2015; Barnawi et al. 2016; Chesani et al. 2008, 2009; De Masellis et al. 2014; El Gammal 2012; Lam 2017; Ly 2016; Ly et al. 2015; Maggi et al. 2011; Montali et al. 2014; Ramezani 2017; Santos et al. 2012).

In order to identify compliance violations multiple formalisms are used. LTL is a very commonly used one (Bernardi et al. 2014; Caron et al. 2013a, b; De Masellis et al. 2014; Dwyer et al. 1998; El Gammal 2012; Elgammal et al. 2010, 2016; Gong et al. 2016; Lam 2017; Maggi et al. 2011; Schumm et al. 2010; Stuht et al. 2012; Turetken et al. 2012). Other formalisms in literature are (colored) automata (Cheikhrouhou et al. 2014; De Masellis et al. 2014; Gruhn and Laue 2005; Maggi et al. 2011; Santos et al. 2012; Gruhn and Laue 2006), Computational tree logic (CTL) (Awad and Weske 2010; Awad et al. 2011; Dwyer et al. 1998; Stuht et al. 2012), First order logic (FOL) (Caron et al. 2013a, b; Ly et al. 2010), CEP (Awad et al. 2015; Thullner et al. 2011), Logic programming (Chesani et al. 2008, 2009), (Mixed) Integer programming (IP) (Kumar and Barton 2017; Kumar et al. 2010, 2015), EC (Montali et al. 2014), Declare (van der Aalst et al. 2017), and Business process constraint network (BPCN) (Lu et al. 2009).

Some papers focus on the graphical representation of compliance constraints, CPs and violations using Compliance rule graphs (CRGs) (Gomez-Lopez et al. 2013; Knuplesch and Reichert 2017; Ly 2016; Ly et al. 2010, 2011). The graphical presentation eases the interaction with and use of CPs and the results of compliance monitoring for business users.

Few approaches go beyond the “simple” identification of compliance violations and try to offer fixing actions (Awad et al. 2009; El Gammal 2012; Elgammal et al. 2010; Maggi et al. 2011; Ramezani 2017; Lu et al. 2009). Such remedy strategies include, for instance, change of the process model structure (Awad et al. 2009), ignorance or reset of violations, change of business process execution (Maggi et al. 2011), and analysis of violation context (Ramezani 2017).

Schumm et al. (2010) address compliance from another direction by trying to ensure compliance by design. For this they propose to use predefined and already compliance ensured process pieces to integrate compliance constraints into a business process.

Lu et al. (2009) use CPs to apply constraints to process variants which are used in their framework to adapt process instances by domain experts if needed. For this they define selection and scheduling constraints which represent occurrence and order CPs.

Cabanillas et al. (2010) describe what data-related compliance problems exist and how they can be grouped. Some of the mentioned problems can be represented as CPs.

Typical business process and compliance perspectives are control flow, resources, time, and data (Ly et al. 2015). Additional properties found in literature are atomic and composite CPs and CAPs. The atomic property relates to individual CPs, whereas CPs assigned to the composite property are two or more CPs combined with Boolean operators. Figure 4 shows how these perspectives and properties are addressed in compliance literature and a full matrix of the used literature and perspectives and properties is provided in “Appendix C”. The number of documents using a perspective or a property are represented as the bars. Three different categories of usage exist. If perspectives or properties are used by literature this is indicated by Explicitly mentioned. If literature does not mention any perspective or property, we assume one or more perspectives and properties based on the given CPs, which is then listed as Implicitly mentioned. Not mentioned is taken if the respective perspective or property are not included in literature in any way.

The three perspectives occurrence, order, and control flow basically represent the same overall category of control flow, but sometimes occurrence and order are listed as distinct perspectives (e.g., Awad 2010; Awad et al. 2011, 2015; Caron et al. 2013a), whereas both of them are sometimes combined under control flow (e.g., Becker et al. 2010). The control flow perspective is the most frequently mentioned perspective (30 papers). Second is the time perspective (18 papers) and third the resource perspective (13 papers). Far off from the other three business process perspectives is the data perspective. It is only mentioned by 7 papers, which is roughly half of the number for resource, roughly three times less than for time, and more than four times less than for the control flow perspective. Also if the numbers of papers which just implicitly mention a perspective are viewed, the data perspective has the lowest number. Thus, the data perspective shows the highest number in regards of unmentioned counts within the investigated documents, too. This finding does not reflect that Data quality (DQ) is one of the leading challenges for todays organizations (Paulson 2000), since data becomes more and more a crucial commodity like water, oil, and steel and represents an existential cornerstone of today’s and future (fully) automated industry as well as the foundation for every fact-based board decision (Marín-Ortega et al. 2014). Also in the research area DQ has to be ensured in order to obtain reliable results. Therefore different approaches are used to achieve this goal (Khan et al. 2012; Stausberg et al. 2011). If available, data-related CPs can be even integrated into organizations’ DQ management frameworks to support overall DQ.

Less frequently, existing approaches utilize the properties atomic, composite, and anti-pattern where atomic is explicitly mentioned eight times, composite ten times, and anti-pattern seven times.

Finally, we take a look at the number of real-world domains a single document applies its approach to. Typically the research is only applied to one domain like maritime safety, online product selling application, or supply chain management (e.g., Awad and Weske 2010; Cheikhrouhou et al. 2014; Chesani et al. 2008; Elgammal et al. 2010; Ly et al. 2011; Santos et al. 2012; Yu et al. 2006). Nevertheless, about one fourth of the papers deal with two or more domains like banking and e-business, health care, manufacturing, higher education, maritime safety, and IT projects, or Internet reseller and loan origination and approval (cf. Awad 2010; Bernardi et al. 2014; El Gammal 2012; Elgammal et al. 2016; Gong et al. 2016; Ly 2016; Ly et al. 2015; Ramezani 2017; Turetken et al. 2012). Also three documents do not state any application domain at all (cf. Caron et al. 2013b; Gruhn and Laue 2005, 2006).

CPs are extracted from the final literature list to create a CP collection. The extracted CPs are then integrated into the existing CP taxonomy as proposed in Caron et al. (2013a). They propose a comprehensive rule-based compliance checking approach. This approach rests on three main architectural components: Business provenance records the actual and past business events. Legislation, policies, and other directives deal with various kinds of constraints. Techniques consist of rule patterns (i.e., CPs) and rule-based controls. A so called business rule taxonomy includes all CPs structured in accordance with the two main perspectives Process mining perspective (PMP) and Rule restriction focus (RRF) perspective. The PMP covers three out of four business process perspectives (control flow, resource, and data) and the RRF perspective includes the forth business process perspective of time.

This taxonomy is by far the largest one we found and supports the main business process perspectives control flow, resources, time, and data. Thus, a substantial foundation for the collection of CPs exists and allows to categorize CPs more easily accordingly to the given taxonomy.

The collection process is detailed for CPs (Artifact 2) and CAPs (Artifact 3): First CPs are identified in literature. For this we look for CPs enumerations, their formal representation, and the various substitutes, e.g., semantic rules and compliance requirements. If a CP is identified, an investigation of its meaning is performed. Often only the name and a textual description are available, sometimes a formalism to get the intention behind the CP. After a clear understanding of the CP goal, a search in the existing CP collection is performed. If a corresponding CP matches, the CP source is added as reference to the collection. Otherwise, the CP is transformed to the structure of the CP collection (cf. Caron et al. 2013a). For instance the identified CP Exists in Turetken et al. (2011) describes a condition that necessities the existence of P is mapped to An activity of type a\(_{1}\)must be performed at least once which represents the structure of CPs in Caron et al. (2013a). Afterwards the transformed CP and the CP source are added to the CP collection. This process is conducted for every CP as well as every CAP in the investigated literature.

In total, 215 CPs/CAPs are identified from the 47 papers of the final literature list. They include the 64 CPs already contained in the CP collection offered by Caron et al. (2013a), but extend this collection into the – to the best of our knowledge – most comprehensive CP collection (Artifact 2, Artifact 3) based on existing literature.¹ Moreover, the CP collection builds the basis for matching elicited compliance constraints, i.e., based on the collection it can be decided whether a compliance constraint can be assigned to an existing CP in the collection or potentially a new CP has to be defined.

The analysis of the investigated literature shows that all business process and compliance perspectives are covered (i.e., mentioned in at least one paper) by literature. Some perspectives are obviously highly preferred above others.

Another finding is that the data perspective falls short in explicit coverage and awareness when compared to the other perspectives. This perspective will need further attention in future, so all compliance constraints concerning data can be sufficiently fulfilled. Examples for regulations containing data-oriented constraints are the Guidelines on anti-money laundering & counter-financing as referred to in Awad (2010) and Awad et al. (2011). Ramezani (2017) uses an internal policy from the Dutch national Employee Insurance Agency. These examples will be augmented with a detailed analysis of further regulatory documents with respect to the need for supporting data-oriented constraints in the following Sect. 3.

The selected documents cover the domains of financial industry (i.e., AnaCredit; Bank for International Settlements 2013), health care (i.e., ELGA-VO 2015; GTelG 2012), IT security (BSI Act 2009), energy sector (IMA-VO 2011; Oesterreichs Energie 2015, 2018), data protection (i.e., DPA 2000) and e-government (i.e., E-GovG). All of them include constraints that affect the processing of data. DPA (2000); E-GovG; GTelG (2012), IMA-VO (2011), Oesterreichs Energie (2015, 2018) and ELGA-VO (2015) are already implemented regulations in Austria. The BSI Act (2009) is effective in Germany. The other two regulations AnaCredit and Bank for International Settlements (2013) must be implemented and complied to in the next one to two years by organizations in Austria (cf. “Appendix D”). Those domains are selected due to their broadness and versatility, their use in other papers, and thus their well-known level of awareness. The selection criterion RegC3 is split into two separate columns in “Appendix D” to better differentiate between the effective dates of the regulations. All selected regulatory documents fulfil all three criteria and the details are listed in “Appendix D” where a \(\checkmark\) shows the fulfilment of a criterion. The Bank for International Settlements (2013) developed 14 “Principles for effective risk data aggregation and risk reporting” – also known as BCBS 239 – which require banks to aggregate and report risk data in a complete, accurate, and timely way by using as well data taxonomies including metadata and naming conventions.

Regulation (EU) 2016/867 of the European Central Bank (ECB) on the collection of granular credit and credit risk data (ECB/2016/13) also known as AnaCredit controls the reporting of credit data to the national central banks and the ECB, respectively. The reported credit data must, for instance, follow dedicated rules concerning accuracy, and data format and type (AnaCredit).

The Data Protection Act 2000 (DPA 2000) is more general in regards to data-related compliance. It deals with the trustworthy and correct processing and storage of personal and sensitive data (i.e., data that identifies or makes data subjects identifiable and data concerning racial or ethnic origin, political opinion, and religious beliefs). All data processing has to ensure that used data are factually correct by means of reasons of application.

The ELGA-Verordnung 2015 (ELGA-VO 2015) deals with the implementation and improvement of the Electronic health record (EHR) and includes data-oriented constraints. The main data focus is on the completeness of data and the correct data delivery according to specific conformity criteria.

Another health industry-related Austrian law is the Federal Act on Data Security Measures when using personal electronic Health Data (GTelG 2012). It deals with the handling and usage of personal electronic health data to ensure a minimum set of standards for data security, extend the information basis on e-health and define rules for undirected communication of electronic health data.

The Federal Act on Provisions Facilitating Electronic Communications with Public Bodies (E-GovG) promotes the electronic legally relevant communication with public bodies. Crucial cornerstone of this law is the unique electronic identification of legal persons. Thus, it defines electronic identity, how to get an electronic identity and how it shall be used for the communication with public offices.

The Act on the Federal Office of Information Security (BSI Act – BSIG) (BSI Act 2009) describes the tasks, responsibilities, and authorization of the federal office. It “shall promote the security of information technology” through, for instance, analyzing security risks, testing and evaluating security of IT and servicing other federal bodies with security products. The office shall further protect communications technology of the German Federation and serves as central contact point for critical infrastructure operators in regards to IT security.

The Intelligente Messgeräte-AnforderungsVO (IMA-VO 2011) defines the requirements for smart metering utilities. It describes the application area and technical as well as process-related requirements (e.g., bi-directional communication possibility, storage capacity, timing requirements).

The Requirements Catalog End-to-End Security for Smart Metering (Oesterreichs Energie 2018) “describes the minimum requirements for end-to-end secured Smart Metering for electricity in Austria. These requirements apply to manufacturers during tender processes for the Smart Meter, Gateway, Central System, and their communication links.”

The Smart Metering Use-Cases (Oesterreichs Energie 2015) give an overview of uses cases that shall be supported in a smart metering system in Austria (e.g., data read out, deactivation of smart meter, prepayment). The document uses different regulatory documents as basis (e.g., IMA-VO 2011).

We go through each of the regulatory documents and identify and extract atomic data-oriented constraints in a manual way. Only those constraints are considered that impose restrictions on data read, written, and transformed in business processes, i.e., constraints that are checked and enforced in the context of a business process and not elsewhere (e.g., in a database). For instance, Article 5 (1) of AnaCredit states Credit data shall be reported (...) where the debtor’s commitment amount is equal to or larger than EUR 25, 000 on any reporting reference date within the reference period.. Here, several atomic data-oriented constraints (e.g., amount has to be equal to or larger than 25,000, amount has to be in Euro, amount has to be from respective reporting period) can be defined to ensure a correct credit data reporting to the supervisors (in the associated business process). Table 2 contains the extracted atomic data-oriented constraints on the left hand side (Artifact 5), e.g., 7 Data must be in domain. Altogether 19 constraints are identified and extracted. The total number of occurrences of an atomic data-oriented constraint per regulatory document is listed in the respective columns of Table 2 to the right.

In summary, the analysis of regulatory documents shows the relevance of compliance constraints in general (Artifact 4): in each of the documents at least 4 different atomic data-oriented constraints were identified and extracted. AnaCredit includes 12 different atomic data-oriented constraints which is the highest number. Table 2 shows in detail which regulatory document uses which atomic data-oriented constraints. It further can be deduced that the extracted constraints refer to one or several of the four business process perspectives control flow, data, time, and resources. The scan of the regulatory documents strengthens the presumption that constraints referring to other business process perspectives than data might be covered by already existing CPs. For instance, Principle 1 of BCBS 239 requires the active participation of the board and senior management of a bank which can be covered by CP performed by (cf. Barnawi et al. 2016; El Gammal 2012; Ly et al. 2015). Another example are paragraphs 4 and 6 of Article 13 stated in AnaCredit where national central banks have to transfer monthly credit data until a defined deadline being covered by CPs P LeadsTo Q ExactlyAfter k (El Gammal 2012) or An activity of type\(a_{1}\)must be started/completed before/after/on t time units (relative to\(t_{0}\)) (Caron et al. 2013a).

Before the mapping of atomic data-oriented constraints to existing data-related CPs, constraints with the same semantics get deleted. Accordingly, constraint 13 Data must be unique over time just extends the existing uniqueness CPs by including a time component, which in turn is superfluous because uniqueness has to be given at any point in time. Over time means in the context of this paper a given time span. Therefore, we subsume this atomic data-oriented constraint under the constraint 11 Data must be unique. Also the constraints 18 Data origin must be known and 19 Data purpose must be known are subcategories of the constraint 3 Data must be available/complete, because both, origin and purpose of data can be specified as an own CP, but can be simply seen as existence of data representing either the purpose or the origin which have to be available. Nevertheless, we do not merge those 3 atomic data-oriented constraints due to simplicity of applicability by business users. They do not need to know what constraints have to be merged and have the same semantics–that is done by the CPs. In the end, 19 atomic data-oriented constraints are extracted.

The mapping between the atomic data-oriented constraints from Table 2 found in various regulatory documents (e.g., AnaCredit, BCBS 239, GTelG) and the existing CPs from literature is based on the associated CP descriptions. Table 3 summarizes the results where for 14 out of 19 data-oriented constraints a mapping can be found. The remaining 5 data-oriented constraints form the list of CP gaps (Artifact 6), i.e., 2, 6, 10, 11, and 17.

Based on the mapping between atomic data-oriented constraints to existing CPs, research question Q1: Is there a gap between coverage of business process perspectives in literature and demands from regulatory documents? Particularly for data-oriented compliance demands? can be answered with yes. There are gaps for the data perspective of business processes. The other business process perspectives seem to be covered.

For research question Q2: Which data-oriented compliance constraints in regulatory documents are not covered by existing CPs? the answer is: there are 5 data-oriented constraints identified as gaps and put on the gap list (Artifact 6). Those are not covered by existing CPs for the data perspective of business processes.

The next question is which of the remaining 5 constraints result in the creation of a data-related CP. Therefore all of them are investigated in detail by applying the following CP design criteria.If an atomic data-oriented constraint fulfils all three criteria, it is designed as CP. Constraints not fulfilling all criteria are not further considered and could be subject for future research. However, all identified atomic data-oriented constraints fulfil all three criteria and are designed as CPs in the next Sect. 4.2.

For each CP its name, description, and related CPs are described (\(\mapsto\)Artifact 7). The newly designed CPs are formalized using EC – a well-known logical language. We decided to use EC based on the findings of Fdhila et al. (2016) which show the suitability of EC to specify (instance-spanning) constraints referring to data.

Table 4 shows the design of two new CPs for constraint 2 that is split into two CPs, i.e., Data must be available at a certain time and Data must be available for a certain time, where the latter one can be substituted by a sequence of the first one. For atomic data-oriented constraint 2 we check if an activity to read data resulting in an event ReadData can be successfully executed at time point \({t}_{\text {R}}\) and for the second type of constraint 2 the read event has to occur in a given time span ts starting at \(ts_{start}\) and ending at \({ts_{end}}\), respectively.

“Appendix G” lists the CP designs of the other atomic data-oriented constraints 6, 10, 11 and 17. It includes also the different characteristics of a CP as shown in Table 4. The answer to research question Q3: How can missing CPs be defined for uncovered data-oriented compliance constraints? is: like for all other business process perspectives through application of a uniformed elicitation method and use of a suitable specification formalism.