Page 1

PROCESS COMPLIANCE IN PUBLIC INFORMATION CHAINS

Welmoed Fokkema, Joris Hulstijn

Thauris Den Haag, Delft University of Technology

w.fokkema@thauris.nl, j.hulstijn@tudelft.nl

Abstract. Public services are increasingly being delivered through information

systems and the processes in government agencies are being standardized.

Traditional government tasks may be delegated to independent government

agencies and private parties. This produces a complex information processing

chain. How can we make sure that an information processing chain performing a

public service, is compliant to relevant legal rules and regulations? In this paper

we study process compliance: the extent to which process elements are in

accordance with legal rules and regulations. We provide a method to review

compliance of processes, based on a detailed process analysis. The method is

illustrated and evaluated by a case study about archiving and message

confirmation requirements in the financial reporting domain.

1 Introduction

More and more activities of government are supported by information systems. We observe a

number of developments. First, the role of information systems in public processes is

increasing [16]. Information systems are no longer only used to support public services, but

are now an integrated part of governing. Second, public processes are redesigned and

rationalized [15], often with a focus on effectiveness and efficiency. This means that public

services are increasingly being delivered by standardized workflows and business processes.

Third, responsibilities are redistributed in information processing chains and networks [5].

Government tasks are delegated to independent government agencies or to businesses, for

instance as a result of self-regulation [2], or as part of public-private partnerships [13, 17].

The question is how compliance to legal rules and regulations of processes can be ensured,

when processes are largely automated and distributed over different parts of an information

processing chain. Moreover, legal experts often do not have the expertise to judge processes

and technical capabilities. In this paper we study process compliance. We define process

compliance here as the extent to which the various elements of a business process (actors,

activities, input, output, decision rules, conditions, temporal order, message exchanges) are in

accordance with laws and regulations. This leads to the following research questions:

Q1. Is there a systematic method to review process compliance?

Q2. How can we use this method to understand compliance of public processes?

This paper focuses specifically on process compliance in the public domain. The government

is not only the source of regulation, but is also an actor whose activities are regulated. After

all, (outcomes of) processes which turn out to be non-compliant, may be deemed illegitimate,

and can be challenged in court or parliament. Legally responsible actors are starting to realize

that information and communication technology creates a new compliance situation [19].

Page 2 Process Compliance in Public Information Chains

Compliance depends on the way a process is set-up. Legal requirements should be

incorporated in the specification. This may be called compliance by design [7]. Especially

when processes are executed on computer systems, built-in application controls provide

reasonable assurance that the outcomes of the process will be compliant too [8]. Therefore

legal experts must participate during the requirements specification and design of a system.

There has been a lot of work on automated verification of compliance of business process

models (conformance testing), for instance [9, 10, 14]. However, these formal approaches

require as a preceding step the interpretation and translation of laws or legal rules into process

requirements. We provide a method to assist legal experts with the analysis of legal

requirements, translating them into process-aware constraints for newly developed systems

and mapping these onto a specific process. This interpretation has to be done with close

regard to context, and can therefore not be performed in an automated manner.

In order to illustrate and evaluate our approach, we have conducted a case study in the

financial reporting domain. Using a shared data representation format businesses can file

financial reports (e.g. tax reports, annual financial statement) to a shared government

infrastructure. This infrastructure has taken over some of the traditional tasks of government

agencies. We look at two particular cases where legal requirements meet electronic

developments: archiving and message confirmation. We analyze the electronic processes

within the shared infrastructure, discuss how to interpret the law and provide suggestions on

the application of the law in the process.

The remainder of paper is structured as follows. In Section 2 we give a characterization of our

approach to process compliance. In Section 3 we present the case studies. The paper ends

with recommendations and lessons learned.

2 Process Compliance

The term ‗process compliance‘ is used here to indicate the extent to which business processes

and elements of processes are in accordance with laws and regulations. A key aspect which

distinguishes process compliance from other types of legal characterizations is the process

perspective. We use the following description, taken from Davenport [3] p5: ―a process is

simply a structured, measured set of activities designed to produce a specific output for a

particular customer or market‖. The following elements or parts of processes are potentially

covered or touched by regulation: activities, actors, input, output (products / documents), the

process flow and constraints covering the process as a whole. For example, a law can govern

the temporal order in which activities have to be executed (process flow), like the

requirement for the government to archive received files in the original state when they come

in (see below); or it can demand a specific format to be used (input), like a mandatory

predefined tax form that companies have to use for their tax report.

2.1 Information Processing Chains

Process compliance in the public domain is not just affected by ICT developments; it is also

shaped by the fact that information technology enables the integration of systems and

organizations in networks or chains [16]. Mentzer et al [12] define a supply chain as a set of

three or more entities (organizations or individuals) directly involved in the upstream and

downstream (supply and distribution) flows of products, services, finances, and/or

information from a source to a customer. This definition is also suitable for chains in the

public domain, with the customer being a company or citizen and the source the government.

Welmoed Fokkema, Joris Hulstijn Seite 3

Specialization and outsourcing often lead to activities being performed by one dedicated actor

for all the others (shared processes). As a consequence, special regulations for a single

government agency or process (for example the tax office or tax filing) do no longer just

apply to the internal processes of this agency, but the whole chain has to comply. The party

which demands compliance might not have the formal responsibility over the processing steps

which most influence it.

2.2 BPMN Modeling

To make detailed models of both the existing situation (as is, ‗Ist‘) and the envisioned new

situation (to be, ‗Soll‘), we make use of modeling tools, in particular Business Process

Modeling Notation (BPMN) [18]. Using business processes and workflow descriptions is

especially crucial when dealing with information requirements. BPMN is a useful instrument

in developing so called process aware information systems [11]. In addition, graphical models

like BPMN models have been shown to facilitate knowledge sharing among stakeholders [4].

2.3 Compliance Aspects

By looking at legislation from a process perspective, it is possible to confront the rules with

the elements of the process, and to determine which legal rule affects which part of the

process. Process aspects that are likely to have legal impact are:

a. Terms (timeframes). Technical, organizational and legal terms are important in processes.

A set of activities has to be performed within a certain timeframe. That in turn makes the

passage of time between process milestones (entry; decision; feedback; completion)

relevant.

b. Transfers. Transfer of information and/or data and the shift of the process flow between

actors indicate a shift in responsibilities and may have to be accompanied by monitoring

and confirmation of the transfer.

c. Messages. Messages like reports, notifications and decisions represent the

communication between actors (e.g. citizen/company, government agencies).

d. Responsibilities. A process is owned by one or several actors, this can be indicated in law.

Other people or departments (front office – back office) may execute steps of the process.

Yet other actors may have to supervise or audit compliance of the process. In general, the

process owner formulates requirements for process execution, based on preferences and

specific or general regulations.

e. Other process requirements. Other process requirements may also be demanded by law.

Consider for example the order of activities, efficiency, actors involved, and specific

product characteristics such as requirements on messages, recording and reporting of

management information, specific input formats and models, etc.

2.4 Review Method

We will now present a review method for assessing process compliance. A process

compliance review proceeds in four steps:

1. Analyze the process and its context. The assessment starts with analyzing a process and its

context. The context is determined by all relevant regulations, and the relevant aspects

(a—e). For example, applying for a subsidy, where the specific law and the term for

application determine the context. Also, the type of process determines the context.

According to Alpar and Olbrich [1] one can distinguish three different levels of e-

Page 4 Process Compliance in Public Information Chains

government: information, communication, and transaction. A transaction for example is

characterized by the fact that rights and obligations of both or more parties are affected.

2. Determine the relevant legislation. This depends on the context and the chain perspective.

Process compliance in the public domain is twofold. On the one hand, the government has

to abide by its own procedures laid down in law, for example the laws on making

legislation, applicable in the process of lawmaking. On the other hand, public processes in

which private parties are involved, will contain legal elements to protect citizens, for

example the duty for the government to respond to each request by citizens.

3. Determine legal process requirements. Legal process requirements may refer to aspects

such as terms, responsibilities, and the nature of message transfers, as well as product

characteristics, skills required of staff, and any other qualities mentioned or prescribed in

the law. In this step the legislation is interpreted and applied to the specific situation.

4. Confront these requirements with the process. Processes as implemented can be tested

against the requirements from legislation. Lawyers representing the actors involved in the

process share the task of determining the compliance and the necessary actions in case of

non-compliance. Ideally, in the design of new processes or changes of processes, lawyers

are consulted by architects in order to ensure that the designed processes are compliant

(compliance by design).

Important to note is that in the third and fourth step, the lawyers involved make an

interpretation. They interpret both the laws and the processes, both of which are in principle

‗abstract‘ conceptual information which requires interpretation in order for it to be used for

comparison and analysis. The outcome of the confrontation may be:

Insight into the relation between process and rules (laws and regulation) both on the level

of the whole process and on the level of the process activities;

Insight into which parts of the process will be affected by amendments in legislation;

Identification of gaps between the legal requirements and the current process.

On the basis of such a review, the responsible process owner may then decide to redesign the

process, or else decide to leave the gap as it is and accept the political risk.

3. Case Studies

We start with a general description of the domain of the two case studies. Using a shared data

representation language called XBRL (eXtensible Business Reporting Language, a variant of

XML), developed by an international platform of institutions in the financial industry, it is

now possible to re-use existing financial data definitions, and re-use existing technical

infrastructures across several financial reporting streams [6]. Here we focus on the business

processes and communication protocols, which need to be aligned to reap the benefits of

standardization and integration. Several reporting processes are executed via a shared

governmental portal (gateway), which provides a reliable technological infrastructure. The

case study focuses on compliance of processes executed by the gateway, in several reporting

streams between citizens or companies and various government or semi-government agencies

which demand reporting (e.g. tax office, environmental inspectorate, social security agency,

etc.). Figure 2 gives an overview of the required communication processes. First, the

company or financial intermediary (accountant, bookkeeper, tax consultant) sends a report.

This message is processed by the gateway. Part of the process is a validation: does the

message represent a valid report? If this is indeed the case, the message is delivered. When

the agency has received the message in good order, the gateway automatically generates a

Welmoed Fokkema, Joris Hulstijn Seite 5

Ag

en

cy

Ga

tew

ay

Co

mp

an

y /

Inte

rme

dia

ry

Provide

Message

Delivery

Receive

Message

Validation

Process

Decision

Provide

Response

Internal

Processing

Provide

Decision

confirmation

decision

Receive

Response

confirmation

report

report

Receive

Message

Time at which

received

Copy for

Archiving

confirmation, and subsequently passes it on to the company. The actual decision is send

directly to the company by the agency, after internal processing.

The confirmation message may entail certain legal consequences (see below). The

government agency carries on by processing the report, after some internal processing it

reaches a formal decision: e.g. an established entitlement to a subsidy.

Figure 1: Control flow with typical message exchange for financial reporting

Regarding the definition, the financial reporting domain can indeed be interpreted as a chain:

a set of organizations involved in the flows of products, services and information from a

source to a customer [12]. One can see the company submitting a financial report as the

source of information, and the back-office of the governmental agency as the customer. In

between there are the gateway, the information systems of the target agency (e.g. tax office)

and the information systems of the source, which is either the company itself or a financial

intermediary. In the description of the cases below, reference is made to the process aspects

often related to legal rules (as mentioned in 2.3), by an indication in [brackets].

3.1 Case 1: Archiving

The shared gateway performs government services. Regarding its specific tasks and activities,

it therefore has to adhere to the specific requirements that the law states for each

governmental agency with regard to these or comparable tasks.

Problem. The Dutch Law on Archiving (Archiefwet) requires governmental organizations to

archive received and created documents that are deemed to be kept long term. The term

‗document‘ is used, regardless whether it is in electronic format or paper-based. Specific

regulations based on the Archiefwet require the agency to ensure that the contents, structure

and form of a document at the moment of creation or reception (original and authentic) can

always be established.1 However, the law is based on a paper reality, and assumes a non-chain

1 See article 17 of the Archiefregeling( Context and authenticity).

Page 6 Process Compliance in Public Information Chains

situation. Paper documents keep their original contents and form, while electronic data can be

altered more easily by processing. When the agency itself performs all the tasks, it can ensure

that the document is recorded in accordance with the requirements of the Archiefwet and

related regulations, and the organization controls all processing activities from the moment of

creation or reception. But now (chain situation) some of the processing tasks have been

delegated to the gateway. Should the same be done for (some of) the archiving demands?

Findings. In the electronic processing of reports to government agencies, part of the main

process (the reception, identification, transformation, validation and routing of messages

containing reports) is now performed by the gateway, controlled by another party. See Figure

1 for a BPMN analysis of the various processing steps. The law requires that all messages, all

data used in decisions and outcome data be recorded/registered in such a way that the process

can be traced back to the original incoming message. Since the agency no longer controls the

execution of activities in the beginning of the process, at the point where the original form of

the data can be established and recorded, the agency is no longer able to comply with the law

by itself. The gateway has to perform part of the required archiving activities. The agency, the

responsible party addressed by the law, has to formally order and instruct the (party

responsible for the) gateway to perform this task [responsibilities]. Since the rules on

archiving focus on long term saving of data, the agency remains the most important actor in

the execution of archiving activities. In addition however, the gateway should make a copy of

the original document at the moment of reception [message/transfer], before it performs any

other processing activities on the instance and the data it contains. All the metadata created by

the gateway in the process should be recorded as well. It should then forward the recorded

information and the original instance to the responsible agency for the purpose of long term

archiving [transfer].

Recommendations regarding process compliance. In order to implement the process in a

manner compliant with the Archiefwet and accompanying regulations it is essential to address

the chain as a whole, from company to gateway to agency. The actors have to cooperate in

order to be compliant. By looking at the process in BPMN (Figure 1), the exact moment

where the law requires the recording activities can be identified (―copy for archiving‖). The

transfer of information between actors, entailing a transfer of operational responsibility, has

become visible. Another aspect made explicit by the process perspective, is that the archiving

activities should make up a separate, parallel process. Archiving can be triggered by a certain

event or change of status in the main process: a document has been identified which needs to

archived.2 In addition, since archiving is not a goal in itself [process requirement], the parallel

execution prevents errors from blocking the flow of the main process.

3.2 Case 2: Send and receive

In the domain described above, there is another important compliance aspect. The gateway

executes services such as authentication, validation and delivery to the portal of the addressed

agency [transfer]. Before that, the portal to the gateway filters out messages that are too big or

that may contain viruses. The authentication and validation services can lead to a positive or

2 See article 1c of the Archiefwet.

Welmoed Fokkema, Joris Hulstijn Seite 7

negative outcome. In case of a negative outcome, the system will decline the message.3

[product characteristics, requirements on messages]

Problem. This case describes two issues, which are related to each other. (i) The Dutch law on

Electronic Communication with the Government4 states that the time (moment) at which an

electronic message is received by a government agency (hereafter: time at which received) is

the moment that the message reaches the ‗system for data processing‘ of the agency.5

Companies and citizens who send a message through a governmental shared gateway wonder

at which point in time the government has received their message, and when they are

dismissed from fulfilling their obligation. There are several ways of interpreting the time at

which received: (1) the moment of passing the portal to the gateway, (2) the moment of

passing all services and delivery to the agency system, or (3) the moment of reaching the

back-office of the agency. It appears that the legal definition of time at which received is,

although designed for electronic communication, a mere translation of time at which received

in the paper reality. For paper, reliable postal services and standardized mail handling are

assumed . In electronic communication, timeframes have changed radically. Moreover, the

legal definition is based on a non-chain reality where the message goes directly from sender

to the system of the agency (for example e-mail).

A related issue (ii) is automatic confirmation. The law recommends that the agency sends an

automatic confirmation for every received message.6 The law intends for it to confirm to the

sender that the chosen means of electronic communication function properly, therefore, it

should be sent immediately after reception (automatic). This means that confirmation does not

entail the acceptance of the contents of the message.7 A complicating factor in the case is that

the gateway system may send a confirmation, as well as the system or the back office of the

receiving agency. The sender does not know what legal position he may claim based on which

confirmation.

Findings. (i) From the perspective of the sender, as well as from the perspective of the law,

the gateway is an extension of the addressed agency. The gateway does not have any legal

authority on its own. The agency uses the gateway to execute its legal power.

[responsibilities] Consequently, the moment of passing the gateway to the shared system is

the time at which received (see arrow in Figure 2). This is where the earliest registration of

the message can take place, before that, firewalls etcetera may block communications without

registering them. From this moment the message can be qualified as having reached the

system, as the law defines it.

(ii) The legal requirement of sending a confirmation is based on a paper reality, in which days

may pass before a message is processed, and assurance of the fact that it is being processed is

3 See article 2:15 (3) of the Algemene wet bestuursrecht for the authority to decline a message that does not

comply with certain requirements. 4 Wet elektronisch bestuurlijk verkeer. Incorportated in the Algemene wet bestuursrecht. 5 See article 2:17 (2) of the Algemene wet bestuursrecht. 6 See article 4:3 a of the Algemene wet bestuursrecht. 7 See Memorie van toelichting Wet elektronisch bestuurlijk verkeer, Kamerstukken II 2001-2002, 28 483, nr. 3,

p. 44 (Explanatory memorandum attached to the Law on electronic communication with the government).

Page 8 Process Compliance in Public Information Chains

needed in the light of legal terms. [terms] This is also advisable in an electronic situation, but

there the message goes through different technical checks and assessment, each of which may

trigger a confirmation. If the first confirmation sent out to the sender confirms only the

technical functioning of the gateway, the parties involved (especially the agency) have to

ensure that the sender understands this meaning (to minimize uncertainty). In addition, they

will have to do their utmost to make sure that after that first confirmation, if the message

satisfies the basic technical requirements, it does indeed reach the back office [transfer]. And

that when, in spite of the confirmation, the message has to be declined for technical reasons,

this is communicated effectively and immediately to the sender.8 [message]

Recommendations regarding process compliance. In order to assess the compliance of the

situation, and to be able to indicate to users how the legal obligations are met and what their

legal position is, the parties involved have to analyze the complete process of handling the

message, from the sender to the back office. This leads to an indication of the time at which

received, which can be communicated to users (i.).

In the creation of a shared gateway, the parties involved should decide on when a technical

confirmation (ii.) should be sent and what its meaning in legal terms is: what does it confirm

and what not. This mode of electronic communication entails the need to monitor whether all

confirmed messages did indeed reach the back office.

4. Conclusions

Due to the increased role of information systems, standardization of public processes and the

redistribution of government tasks in a network or chain, elements which contribute to

compliance are distributed over different actors. However, in the end, compliance is a

property of the whole information processing chain. In a chain, who is legally responsible and

who is in fact executing a certain task, are two different questions.

In this paper we have addressed process compliance, the extent to which elements of business

processes adhere to (legal) rules and regulations. The following aspects of processes are

crucial in assessing compliance: (a) terms and timeframes, (b) transfer of information,

dossiers and responsibility, (c) message exchange, (d) actors and responsibilities, and (e)

other operational process requirements. We have developed a review method for assessing

process compliance, consisting of the following steps: 1. Analyze the process and its context,

2. Determine the relevant legislation, 3. Determine the legal process requirements specific to

this situation, 4. Confront the process requirements with the actual process. We have

illustrated and evaluated the approach by a case study in the financial reporting domain,

where a shared governmental gateway has taken over some of the tasks of government

agencies. In particular, we looked at archiving requirements and message confirmation. The

process compliance aspects (a) – (e) listed above, can indeed be identified in the compliance

analysis of the cases. Terms and timeframes turn out to be important aspects, as well as

transfers and responsibilities. The case studies demonstrate the necessity of taking a process

8 In line with the requirement of communicating the declination of a message, see article 2:15 of the Algemene

wet bestuursrecht.

Welmoed Fokkema, Joris Hulstijn Seite 9

perspective when analyzing the effects of relevant laws and when assessing compliance.

Process analysis leads actors towards a compliant and practical solution, because the solution

can be implemented into the process directly.

References

1. Alpar, P. and S. Olbrich, Legal Requirements and Modelling of Processes in e-Government. The Electronic

Journal of e-Government, 2005. 3(3): p. 107-116.

2. Bartle, I. and P. Vass, Self-Regulation and the Regulatory State: A Survey Of Policy and Practice. 2005,

CRI, University of Bath.

3. Davenport, T.H., Process innovation: reengineering work through information technology. 1993: Harvard

Business School Press.

4. Davies, I., et al., How do practitioners use conceptual modeling in practice? Data and Knowledge

Engineering, 2006. 58(3): p. 358-380.

5. de Bruijn, J.A. and E.F. ten Heuvelhof, Network and Decision Making. 2000: Lemma, Utrecht, Netherlands.

6. Debreceny, R., et al., XBRL for Interactive Data: Engineering the Information Value Chain. 2009, Berlin:

Springer.

7. Governatori, G. and S. Sadiq, The journey to business process compliance, in Handbook of Research on

Business Process Management. 2009, IGI Global. p. 426-445.

8. Knechel, W., S. Salterio, and B. Ballou, Auditing: Assurance and Risk. 3 ed. 2007: Thomson Learning,

Cincinatti.

9. L.T. Ly, et al., On Enabling Integrated Process Compliance with Semantic Constraints in Process

Management Systems. Information Systems Frontiers, 2010. DOI 10.1007/s10796-009-9185-9.

10. Lu, R., S. Sadiq, and G. Governatori, Measurement of Compliance Distance in Business Work Practice.

Information Systems Management, 2009. 25(4): p. 344-355.

11. Marlon Dumas, W.M. van der Aalst, and A.H. ter Hofstede, Process-Aware Information Systems: Bridging

People and Software Through Process Technology. 2005: Wiley Academic Publishers.

12. Mentzer, J.T., et al., Defining Supply Chain Management. Journal of Business Logistics, 2001. 22(2): p. 1-

25.

13. Rosenau, P.V., ed. Public–Private Policy Partnerships. 2000, MIT Press, London.

14. Rozinat, A. and W.M.P. van der Aalst, Conformance checking of processes based on monitoring real

behavior. Information Systems, 2008. 33(1): p. 64-95.

15. Scholl, H.J., Current practices in e-government-induced business process change (BPC), in Proceedings of

the 2004 annual national conference on Digital government research. 2004, Digital Government Research

Center. p. 1-10.

16. Scholl, H.J. and R. Klischewski, E-Government Integration and Interoperability: Framing the Research

Agenda. International Journal of Public Administration, 2007. 30(8-9): p. 889-920.

17. Spackman, M., Public–private partnerships: lessons from the British approach Economic Systems 2002.

26(3): p. 281 -- 301.

18. White, S.A. and D. Miers, BPMN Modeling and Reference Guide: Understanding and Using BPMN. 2008:

Future Strategies Inc., Lighthouse Pt, FL.

19. WRR, iOverheid. 2011, Wetenschappelijke Raad voor het Regeringsbeleid (WRR).