Model to Program and Blockchain Approaches for Business Processes and Workflows in Finance

Abstract

Business process modeling and verification have become an essential way to control and assure organizational evolution. We overview the opportunities for the application of blockchain in Business Process Management and Modeling in Finance and we focus on in-depth analysis of claim process in insurance as a use case. We investigate the utilization of blockchain technology for model checking of Workflow, Business Processes to ensure consistency, integrity, and security in a dynamically changing business environment. We create a UML profile for the blockchain, then we combine it with a UML activity diagram followed by a verification using Petri nets to guarantee a distributed computing system and scalable with mutable data. Our paper creates a unified picture of the approaches towards business processes modeling used in the financial industry organized around the set of premises intending to develop a future research agenda for blockchain business process modeling, specifically for the financial industry domain.

1. Introduction

Business process modeling aims to describe the organization and operational processes of an enterprise. Modeling uses many different methods that can help understand and summarize how models work. Modeling allows the simulation of business processes for comparison of different scenarios, allows the analysis and restructuring of the enterprise to improve performance, and to get a correct generated program from our model. Different approaches and techniques are used for modeling business processes.

Previous research [1] analyzes how the processing flows are checked for correctness in syntax and simulates how they should be executed to achieve better results. Therefore, some organizations and standards standardize some aspects of workflows and provide different design notations. But UML and SysML [2] activity diagrams (AD) and Business Process Modeling Notation (BPMN) are mostly used to provide an easily readable graphical notation for workflow processes [3]. In this study, the UML activity diagram is used because it is easy to read and can be easily extended and adapted with UML profiles to use Blockchain.

A blockchain is a system for recording information in a way that makes it difficult or impossible to alter, hack, or defraud the system. Blockchain has only recently been used in insurance companies [4,5]. It is used to automate insurance claims by tracking compromises made between different parties without paperwork. It will facilitate quick approval of claims and renewals. It will also be used to automate payments for claims, thereby reducing administrative costs.

Model to Program (M2P) approach is the technique or method of transforming a model into a final product (program) [6]. It uses various transformation techniques between different types of business process workflow modeling methods of business systems, especially those with complex and concurrent workflow processes. Model transformation is considered the fundamental method in Model Driven Architecture (MDA).

In the seminal work of the author of [7], the basic principles of modeling and its relationship to program generation are stated. This approach introduced a new line of thought in the field. Since the model transformation helps to minimize the development time of the system, thereby reducing the “time-to-market” factor of the final product [8], we transform the model into Petri nets after creating a complete diagram (UML AD and blockchain) into the same extended diagram using the UML profile.

Petri nets are one of the most powerful formal models for representing work, control, and information flows [9]. It helps in the formal description, modeling, and formal analysis of information systems and business process modeling. Its techniques, features, and concepts follow a balanced combination of powerful, easy-to-use, and natural approaches to describe and analyze the flow of information and control processes throughout the system structure.

The motivation behind our work is to take advantage of UML AD in modeling business processes and applying blockchain technologies to maintain integrity in the insurance industry. In our work, we combined UML-AD and blockchain in one model before transforming them into formal Petri nets. In Section 2, we mention related work on Blockchain, modeling with UML-AD, model transformation, and modeling with Petri nets. In Section 3, we discuss research issues in the context of information systems and case studies. Then we show the combination of blockchain with UML-AD and the transformation to Petri nets, followed by a discussion. Finally, a conclusion with possible future work.

2. Literature Review

At a high level, UML and BPMN are designed for participants and other stakeholders of the business processes to gain easy understanding through a visual representation [10] and provide enough detail to enable accurate execution. Business process modeling has many benefits, such as improving efficiency and saving time, as well as ensuring consistency and standardization across the organization. [11] provides an overview of business process modeling (BPMN) tools. Another work [3] shows a comparison of the UML activity diagram and BPMN in business process modeling. The authors in [12] propose an extension of UML activity diagrams to obtain a specification of the business process model and requirements using the UML profile. We choose to extend UML-AD using the UML profile as well. Modeling with UML [13] is effective and easy to use, but needs more formal verification.

For the verification of models and more formality, Petri nets describe and analyze the information flow of information and control processes throughout the whole system structure. Petri nets are used to determine if the model is working correctly and to determine as well if the Petri net is correctly modeling the actual system. It is used by many researchers, Ref. [14] presents a guide to modeling, verification, and application of Petri nets for systems engineering. Ref. [15] integrates UML and widely used CASE tools with Petri nets in software engineering. Refs. [16,17] proposes a mapping from a core set of BPMN to labeled Petri nets. Another work [18], proposes to ensure equivalence between a set of modeling elements in activity diagrams and their corresponding Petri nets. A transformation from SysML AD to Petri nets has been presented that allows behavioral modelers to reduce verification costs by identifying potential design flaws in behavioral models specified as activity diagrams before implementation. Some other work shows the comparison of Petri nets and activity diagrams for workflow modeling [19], which helps us before performing the transformation.

In our work, we combined blockchain and activity diagrams. Blockchain is known as the core technology behind cryptocurrencies and bitcoin [20]. The blockchain technology major component is a ledger for transactions with unique characteristics that assist to support maintaining integrity, consistency, data protection and security in systems and business processes [21]. It offers easier traceability, increased security, and greater transparency. Reference [22] gives a comprehensive overview of blockchain technology and highlights challenges, opportunities, and future directions of blockchain technologies. Nowadays, blockchain is used in numerous fields [23] such as cryptocurrency, finance, advertising, medicine, healthcare, and insurance [24,25]. References [26,27,28] show using blockchain technologies in finance. Ref. [5] presents the case study of an Italian insurance company, the goal was to improve the company’s day-to-day operations by introducing innovative digital solutions, a platform that connects the company with its customers, and an analysis of cyber insurance policies to be included in the company’s portfolio. Ref. [4] designed an efficient distributed enameled blockchain platform as a system service to support transaction execution in insurance processes. There are also opportunities for using blockchain technology in medicine, references [29,30] explore blockchain research for healthcare, and present a roadmap for the future. Not only that, but many proposals use blockchain technologies to improve scientific processes [31]. We didn’t work on the blockchain directly, but we created a UML profile to represent it, and after that, we transformed the whole model.

Model transformations [32] or Model to Program (M2P) approach can handle many problems and complete many source models. In our previous paper [33] we presented the theoretical background and an overview of Model to Program in the case of workflow systems. We have discussed various semi-formal transformations from semi-formal models such as UML and BPMN to other formal models such as YAWL and Petri nets or executable programs. The need to obtain validated and well-analyzed programs led many researchers to look into using M2P and other methods. The book [6] contains many papers specialized in M2P. One of them is formal model checking and transformations of models represented in UML using Alloy [34], where we transformed our UML activity diagram model into an Alloy program to benefit from the Alloy analyzer. Another transformation of UML data using Model Driven Architecture [35]. Ref. [36] automatically generates integrated formal models that correspond to UML system models. Also, ref. [37] presented a transformation methodology for UML 2.0 activity diagrams into colored Petri nets. Reference [38] shows a graph transformation of activity diagrams into $\pi$- calculus for Verification Purpose. Many other transformations are performed from UML to YAWL, which is considered an extended version of Petri nets and is also considered an alternative to BPEL and has strong verification tools. In our previous work, we transformed the UML state machine to YAWL to enable better verification and analysis of our models [39]. Ref. [40] also transformed the UML activity diagram into YAWL models for Business Processes Analysis.

3. Research Questions in the Context of Information Systems

The blockchain technology and architecture promise that each participant in the transaction has her copy of the ledger to safeguard the consistency and integrity of the logs of transactions through synchronization. Thereby, communicating partners participating in transactions can avoid the utilization of intermediary parties. Business use cases in finance involve back-end processing of transactions and provenance tracing through the whole process chain [41,42]. In an enterprise environment, the tracking, recording, and retention of data representing information flow, actions, activities are very important and legally required, especially in the field of finance. The tracing of activities within workflows is very important from the viewpoint of accounting and the auditing of Information Systems. The application of blockchain technology within workflows raises questions whether how the internal audit function and external auditing acts will change [43,44]. The auditing of Information Systems concentrates not only on financial accounting but all electronic transactions that involve data, electronic documents, and processing steps. The digital transformation of enterprises implies that the major part of each business process is electronic; at certain points, human interactions are involved. In the case of digitally transformed enterprises, especially those that exploit Financial Services Technologies the supply chain management means the flow of electronic documents that contain various information about the transactions. The decisive assets of digitally transformed enterprises are data, information stored in electronic documents, structured, semi-structured, and unstructured formats [45,46]. Blockchain technology makes it possible that the state, the originality, and tracking data of pieces of information can be retrieved that were collected throughout the whole life cycle of the given item. From a document-centric view, the descriptions of Business Processes, Workflows either in XML or JSON can be considered as semi-structured data/document besides the information resources that are utilized during the execution of tasks included in Workflow and Business Processes [47,48]. One of the research questions is how the information flow should be managed as the Supply Chain of electronic pieces of information; how the Information Architecture and Enterprise architecture should look like. What kind of design methods should be applied? [49,50]. In an enterprise that is digitally transformed, Information Systems are core constituents. Blockchain technology is devoted to those applications that share information. The research question is how blockchain technology could be used; what use cases would be appropriate to exploit blockchain technology for efficient and effective application. The Workflows manage the transactions and information resources that are an integral part of Information Systems [51,52]. To define design principles that could be used to describe Workflow, Business Processes, and their tasks to make use of blockchain technology for provenance, security, control, monitor, data protection, and supervising is a research area that can be ordered under the subject of Design Science Research. The Design Science Research paradigm gives a research methodology that can be applied to conceptualize the results of experimental design and development [53]. To elaborate design principles, case studies, models, and patterns of Workflow can be used to start building up initial design guidelines [54]. The next question is if there are design guidelines on how to specify Workflows and Business Processes that are integrated with blockchain technology to provide provenance about the instances of executed tasks of Processes and consumed information items. Furthermore, how we can create executable programs from models that were built in a visual language. The available opportunity is to employ the toolset of Model-to-Program (M-2-P). Besides the operationalization of the specified workflow, the M-2-P techniques offer model checking, maintaining consistency, integrity—coupled with blockchain—security, and trustiness.

Definition 1.

Blockchain is an electronic, decentralized, distributed account book (ledger) that stores all activities promptly to establish an enduring and immutable registry.

Blockchain technology can be used to trace financial transactions (internal and external) to enterprises, tracking the electronic document, data, more generally, assets during workflows and after finishing and closing down the specific issue. The blockchain makes it possible to assure the quality of processes, to support internal and external auditing, management control, and checking. Since the electronic document handling belongs to the information logistics of companies.

The MIT Business Process Handbook contains a comprehensive collection of Business Process patterns that could be customized for purpose [55]. The domain of Finance needs some tailoring of the original patterns, especially in the insurance industry. In the tables (

Table 1. Business Process Pattern: Claim.

Request/Claim Pattern
Description	The process pattern represents the tasks from the initiation of the claim until the fulfillment or rejection. Verification sub-task begins after the request, an insurance claim has been received, and then accepted by the administrator. The claim, the request is forwarded to the responsible person this task can be described by ‘Connection Pattern’. The verification stage includes authentication, identification, and validation of all data that are supplied by the consumer. The outcome of the verification stage could be approval, rejection, withdrawal of the claim, or refreshing the information.
Goal	To describe a series of tasks in a model that depicts the approval or rejection of the claim.
Problem	This pattern obligates that verification and validation should be carried out at the starting of the process and during the execution when various confidential and personal information is utilized thereby appropriate security mechanisms should be applied (e.g., blockchain).

and

Table 2. Business Process Pattern: Contacting patterns.

Contacting Partners Pattern
Description	To contact corresponding partners, this pattern represents the chain of tasks whereby more data could be asked for; or inquires can be initiated about the status of the whole process and belonging documents that are addressed to the responsible role. The contacting process can commence with a direct request for information (e.g., claim acceptance, the satisfaction of demand/request, reimbursement) or an offer. The Contacting Partners pattern describes a two-way interaction between the interested parties. The pattern usually starts with the verification of supplied data and requests. The Informing Pattern responds to the request with appropriate messages.
Goal	To model the chain of activities of the Contacting Partners’ pattern.
Problem	Contacting Partners’pattern assumes an external stimulus to launch a chain of tasks of the business process. The pre-condition for executing activities within the pattern is to validate the input data and information before starting the whole process. Each task in each process may require identification, authentication, authorization, verification, and validation of information.

), the core patterns are outlined that make it obligatory in a digitally transformed enterprise to be complemented by the modern security mechanisms that can safeguard the integrity, consistency, and trustfulness of the business processes. The components of blockchain technology can be inserted into patterns then the patterns can be used during business process realization and finally the executable programs as instances of the business process realization can be generated through the exploitation of the Model-2-Program approach.

Case Studies

This part of the research has been designed as an exploratory multiple case study [56,57]. The empirical inquiry that investigates a contemporary phenomenon in real-life context building should start with little or no theory under consideration and no hypothesis to test as preordained theoretical propositions may limit or bias future research [56,57], therefore this part aimed to act as a starting point to draw up sufficiently broad research questions and future data gathering process.

It has been long argued that blockchain can “democratize” the economy by creating a technological commanding opportunity that favors, open, distributed, decentralized systems, platforms, and markets based on blockchains. When representation of companies’ activities are put on the blockchain, the company enables open and decentralized access to the information flows to managers and allows for centralized control that for sure improves companies operations [58,59,60].

Insurers are at the early stages of discovering the potential of new technologies to improve their operations, so naturally, many insurance companies are studying how they can benefit from the use of blockchain and this is the central goal of many applied and research projects. A few potential domains for the use of blockchain in insurance include:

• Smart contracts, or better computer protocols, embedding the contractual obligations into a source code that is compiled and executed per terms and conditions specified in the contract. It relies on the distributed ledger architecture of a blockchain to create the smart contract. Therefore the smart contract can control its states and assets, and it can respond to the input of external information. Smart contracts can be fully self-enforcing [61].
• Customer loss history, estimating the insurance policy quote is based on a complex risk assessment process, in which companies must analyze customer’s loss history, a process that allows the insurance companies to correlate past behavior to risk [62]. This process can be long and painful for all parties involved. Therefore, some first claims sharing platforms, based on blockchain, can provide any company with the opportunity to keep records of claims/losses in one place, in which the credibility of claims is validated by a blockchain technology [63].
• Regulatory compliance Financial institutions are highly regulated and hierarchical organizations, where multi-stakeholders views usually are required to implement such systems. Regulatory compliance projects can be another example for cases where the application of blockchain may significantly improve operations, and such implementation can lead to big operation improvements in terms of audit issues or possible risks coming from failing to comply with regulation [64].
• Claims processes A typical claim process starts with an insurer asking to assess the loss or the damage of the insured person or company. Different solutions have been devised already in this respect, in terms of automated claims setting, where already based on past data, the company can fully automatize claim report and their response to them. Insurance companies, therefore, execute and automate decisions to the greatest extent possible, such as whether the insurance company should pay the claim, which is approved by a staff member is later only without the manager’s meddling [65].

Other use can be for the aim of offering digital identities related services for financial companies [66], as well as for improved security as solutions based on blockchain bring transparency [67].

To understand the relevance of use cases from an insurance perspective, we can distinguish three cases categories in respect to the potential they hold from a business point of view to the company [68]:

• Evolutionary, cases where there already exist solutions, without blockchain, and the stakeholders and markets have solutions, and thus blockchains only optimize existing offer, support, and operations.
• Transformative, insurance users are served in a new way, in new context, the business operations models are created, and thus this means that insurers add new innovative offerings to their pallet of products and services.
• Disruptive, cases that lead to the creation of new users and new ways of doing business for the insurers (thus also new business models for insurers and new ways of doing business).

The biggest challenges for implementation relate to the effect on the social and business network. The issue is what is required to make the distributed ledger technology work in the different scenarios. For the specific solutions to work, there needs to be adherence to several institutional regulations. The second challenge is that the literature doesn’t discuss yet is how value creation and value capturing will be realized through these solutions for the companies, this will be, according to many scholars, the next obstacle to solving indeed.

4. Overview of the Insurance Claim Processing

Each claim involves a business process that is to be performed. The process consists of a sequence of tasks that must be performed, and conditions that must be verified to execute the task. An example of a process is the way insurance companies handle claims. Figure 1 shows the activity diagram of the claims handling process. As shown in Figure 1, the added value of the modeling perspective in Activity Diagrams is based on the ability to model and integrate the different components’ view in the claims process, and how to provide a systematic integration of automation, and explains how the systems support the employees in the different phases of the claims process.

These types of views make it possible to:

• Identify and model claims processes at single organizational layers (transversal and information flow to all managers).
• Improve the business process by identifying tasks that can be performed in parallel.
• Model different criteria on organization level of claims accepting/rejection.

4.1. Modeling the Insurance Claim with Activity Diagram

An insurance claim is a formal request from a customer to an insurance company for coverage or indemnification. First, the customer applies for the claim. The insurance company receives the claim after entering the data into the system and reviewing the claim; they decide the policy and claim type if it is premium or economic. The investigation begins after the manager-level responsibility and the clerk-level responsibility. The insurance organization will assess the claim and may request additional data to confirm the case. After that, a conclusion of investigation and analysis which help to determine the value of insurance claims for a d refuted by the customer, settlement through agreement or direct acceptance. After the Acceptance, the insurance organization will calculate the payment transfer and notify the customer by email, SMS, or postal mail. Figure 1 shows in detail the insurance claim/Activity diagram.

4.2. UML Activity Diagram and Petri Nets Meta Models

UML Activity diagram and Petri nets metamodels are needed to define the element-to-element transformation. From the activity diagram meta-model, we use activities, edges, and control nodes to acquire the transformation rules and transform them into Petri nets as shown in the figure below The Figure 2.

We used in our work Petri nets because they are considered to be one of the powerful formal models for work, control and information-flow representation [69]. It helps to make a formal description, modeling, as well as a formal analysis of information systems and business process modeling. Its techniques, properties, and concepts follow a well-balanced combination of powerful, easy-to-use, and self-evident methods to describe and analyze the flow of information and control processes throughout the whole system structure. To transform our model to Petri nets, we need the Petri nets meta-model presented in Figure 3.

4.3. Extending the Activity Diagram including Blockchain UML Profile

We propose to create a structured UML profile, a new meta-model, to lightweight extend the UML meta-model by adding the blockchain part to the Activity diagram. Profiles allow adaptation of the UML meta-model for platforms like Java platform, .NET Framework, etc... or domains such as our case business process modeling, insurance, medical applications, service-oriented architecture, etc.

Figure 4 shows in detail our profile for blockchain. It is composed of:

• Node—In blockchain architecture, a node can be any user or computer (every node has an independent copy of the blockchain).
• Block—Ia data structure used for keeping a set of transactions that is distributed to all nodes in the network.
• Chain—Ia sequence of blocks in a specific order.
• Transaction—Contained in the block and contains information, records, etc...
• Miners—specific nodes which perform the block verification process before adding anything to the blockchain structure.

4.4. Transforming the Extended UML with Blockchain to Petri Nets

In the upcoming subsections, we will present the transformation rules element to element from UML AD and the extended part that represents the blockchain to Petri nets and the algorithm of transformation.

4.4.1. Transformation Rules

The transformation rules presented in

Table 3. Transformations rules from UML AD to Petri nets.

Transformation Rules from UML AD to Petri Nets
Rule 1	The initial node from UML AD is transformed into a place in Petri nets and the name of the place is the same as the initial node.
Rule 2	The final node from UML AD is transformed into a place in Petri nets and the name of the place is the same as the final node.
Rule 3	Every action node from the UML activity diagram is transformed to a new place in Petri nets.
Rule 4	Every decision node from the UML activity diagram is transformed to a new place in Petri nets, and the name of the place has the same name as the decision.
Rule 5	Edges in the UML activity diagram are transformed into new transitions in Petri nets.
Rule 6	Join (And Join workflow) in UML activity diagram is transformed to a non-real transition with incoming arcs from the joined places in Petri nets.
Rule 7	Fork(And Fork workflow) in the UML activity diagram is transformed to a non-real transition with outgoing arcs from the places split.
Rule 8	Every block added by the UML profile is transformed into a place in Petri nets.
Rule 9	Data contained in blocks added by the UML profile is transformed into tokens/resources in Petri nets.

to be used in our transformation algorithm were extracted from comparing the UML activity diagram meta-model (see Figure 2) + the created profile (see Figure 4) with the Petri nets meta-model (see Figure 3). The transformation is done from element to element only when it comes to the workflow: join in the UML activity diagram is transformed into a non-real transition with incoming arcs from the joined places in Petri nets, and fork in the UML activity diagram is transformed into a non-real transition with outgoing arcs from the split transitions.

4.4.2. Transformation Algorithm

For our Algorithm 1, we define first the set of components from both the extended UML-AD and Petri nets.

Definition 2.

The input model of Extended UML-AD

• $Node$ is for initial, Final or decision node.
• $Action$ is for action.
• $Edge$ is for edge.
• $Workflow$ is for join or fork.
• $Block$ is for added block.
• $Data$ is for added data.

Definition 3.

The output model Petri nets

• $Place$ is for Place.
• $Transition$ is for Transition.
• $Arc$ is for Arc.
• $Token$ is for Token.

We initialize the unprocessed elements to all the elements in the input model and then process them one by one through specifying the type of the workflow, whether it is a join or a fork; and even the type of the activity node is defined, whether it is an initial, final, or decision node, and then we pursue the created transformation rules (Table 3) until we complete all elements in the set.

Algorithm 1 Extended UML AD to Petri net Transformation algorithm

Input: an extended UML model $(Node,Action,Workflow,Edge,Block,Data)$ Output: a Petri net $(Place,Transition,Arc,Token)$ Initiation: $proc\_elements:=⌀,non\_proc\_elements=\{i\mid i\in Input\}$; $node\_type\in \{Initial,Final,Decision\}$ $workflow\_type\in \{Join,Fork\}$ while$\mid non\_proc\_elements\mid \ne 0$do     if $i=Node$ then         if $node\_type=Initial$ or $node\_type=Final$ or $node\_type=Decision$ then            $addPlace\to Output;$            $addi\to proc\_elements;$         end if     end if     if $i=Action$ then         $addPlace\to Output;$         $addi\to proc\_elements$     end if     if $i=Edge$ then         $addTransition\to Output;$         $addi\to proc\_elements$     end if     if $i=Workflow$ then         if $workflow\_type=Join$ then            $addNon\_Realtransition\to Output;$            $addIncoming\_Arcs\_from\_joined\_Places\to Output;$            $addi\to proc\_elements$         else            if $workflow\_type=Fork$ then                $addNon\_Realtransition\to Output;$                $addOutgoing\_Arcs\_from\_forked\_Places\to Output;$                $addi\to proc\_elements$            end if         end if     end if     if $i=Edge$ then         $addtransition\to Output;$         $addi\to proc\_elements$     end if     if $i=Block$ then         $addPlace\to Output;$         $addi\to proc\_elements$     end if     if $i=Data$ then         $addtoken\to Output;$         $addi\to proc\_elements$     end if end while

5. Discussion

There is a proposal for theoretical frameworks considering blockchain applications in supply chain and logistics. These proposals raise the question of how to structure and design an architecture for processes of supply chain and logistics [49,70]. The proposed theoretical frameworks concentrate on the Business Model component of the Enterprise Architecture [71,72,73]. There is an attempt to provide design guidelines in the context of the supply chain to achieve provenance. The proposed approach is grounded in an ontology-oriented method [74]. Application of blockchain technologies in Business Processes within an untrusted environment is analyzed in a paper [75]. The application of State Machines to discover process patterns is investigated in ref. [76].

The document handling within Financial Services can be considered as the Information Logistics function of enterprises. Thus, the supply chain and logistics application has relevance for idea generation and thereby tailoring the appropriate sector.

We used two-pronged approaches in our research, namely, real-life case studies and experimental design and development. Based on case studies, Business Process Models are described in UML Activity Diagrams, in which the Business Process representation is grounded in patterns. The patterns are extended by hooks that will use blockchain technologies for two purposes. One is to track the specific instance of the Business Process. The other one is to trace the documents, evidence, and input/output data during processing. The reason that we applied Activity Diagrams in UML and SysML is that their application is widespread and easy to understand and explain in contrast to BPMN 2.0 [3,77]. The configuration of possible components and patterns provides an approach that is feasible to support Business Process Management and Modeling in the Finance domain. The constrained experiment showed that it is viable to elaborate the Business Processes and blockchain patterns in a systematic way for the Finance domain. The pairing of business processes and blockchain models through a pattern-based approach is a fruitful solution in the cases when financial companies in their digital transformation, intensively use blockchain-related technologies in various fields of business activities. The initial models rely on the Business Processes that were explored in the case studies. This model contains starting patterns that will be extended by empirical studies and software experiments [54]. The empirical observation of case studies served as the basis for conceptualizing the patterns from which the Business Process Representation in UML Activity Diagrams were created. During the modeling, the BPMN principles are followed in a disciplined way that relies on existing patterns. The patterns are extended by such links to blockchain services that enable program generation from the individual models. The M-2-P approach gives a solid base for program generation from Business Process Models. The algorithms that were developed up to now need enhancement using graph-theoretical foundations to be prepared for the complex situation and model configurations. We attempted to apply the M-2-P methodology in the field of Financial Services and workflows. Other authors aimed at distinct fields for the application of M-2-P and they did not consider involving the blockchain technology into M-2-P methodology [7]. The M-2-P, BPMN, Activity Diagram representation in graph format, and the transformation based on graph theory are justified modeling approaches in the problem domain. The combination of proposed models is useful to support financial companies to react to stimuli and events that arrive from the turbulent environment, market. We used experimental design, development, and implementation to investigate the results of model building and program generation. The qualitative case studies gave enough information to investigate phenomena in the problem area. The M-2-P method made it possible to observe and investigate the designed model in an operational environment. The experimental design and development along with the usage of empirical data have proved a beneficial methodology to study and to create proposals for solutions in the problem area. Our design is based on real-life case studies that yielded foundations to study the proposed approach. The pattern library that is already existing and will be developed can support the digitalization of Financial Companies and the dynamic process changes in an Agile and Lean governance environment.

Practitioners can benefit from this study too. First on a more general level, to our knowledge we are the first to apply the M-2-P methodology in the financial domain and workflows and involved blockchain technology into M-2-P methodology. This generic setting can: (i) help in developing activities for such technology setting and, (ii) decrease the transparency problems in the insurance claim process.

6. Conclusions

The business activities and document processing of the insurance field can be regarded as a specialization of more generic business and document-related processes within Finance and Financial Services. The sector-specific business processes can be abstracted away and formulated as generic processes that can be considered as a valid generalization for the whole Finance sector. The disciplined case study methodology makes it possible to observe the phenomena in a specific case and then generalize it. In Financial Services, the initiation of an issue, inputting documents, creating new documents, processing them are typical components of a workflow. During the document processing, the document flow starts with documents that are full of free, unbounded variables and placeholders. During the processing, the variables will be bound and valuated until they reach a finalized state. However, the finalized state is not the end-state, since the business processes may require further modifications to reach the end-state in the form of a ground document [78]. The recent and hot issue of transparency in every field of business transactions requires that during the entire processing, all activities could be explainable and understandable. The valuation of variables in the documents happens through the execution of algorithms including Data Science, and in a broad sense AI. The newer versions of the specific algorithms in AI and Data Science attempt to give cues about the proposed decision. However, these cues and final results should be integrated into the activities of business processes. Defining the adequate patterns that incorporate the appropriate services that manage both the blockchain technology for immutability and the explanation of the actual results of the valuated variables that will be expounded as a decision or outcome is the crucial question. The case study assisted to pinpoint the issue and the proposed approach, and thereby it makes it possible to conclude general statements exploiting the underlying generic enterprise architecture that are similar or quasi-isomorphic concerning the graph representation to other typical workflows and business processes in Financial Services. For this reason, the generalization and unification based on one specific sector of Finance can be performed to achieve a valid conclusion. This paper discusses the power of modeling business processes using UML activity diagrams and other languages presented in the literature, and model transformation M2P benefits from the strength of blockchain and UML profiles to facilitate insurance claims. A UML profile was created to extend the UML activity diagram by adding a part that represents the blockchain. Then we Transformed the whole extended diagram to Petri nets by respecting the generated rules of transformation.

Implications of our paper suggest that blockchain integration in the insurance field can be a promising multi-actor research area. To our knowledge, it is the first paper to discuss the modeling of the blockchain-based insurance claim process.

In the future, the model that was presented in this article is a starting point for research in which we systematically seek and collect patterns of Business Processes that are specific to Finance and especially to Financial Services Technologies. The referred sources that contain generic descriptions and patterns of Business Processes are not tailored to the domain of Finance. The application of blockchain technology can be perceived as web services or micro-services that are called by tasks of specific Business Processes [55]. These web service patterns should be explored and defined, then patterns should be collected into the library. The patterns of Business Processes and web services initiate the review of workflow patterns [54]. The workflow patterns are elementary building blocks that can be either extended or expanded by necessary constituents to take into account the specialty of Business Processes in Financial Services Technologies and the application of blockchain technologies. This collection of patterns – Business Processes and workflows – can be used to develop a set of adaptive algorithms that make it possible to use the Model-2-Program paradigm in a complex and rapidly changing enterprise environment to react to stimuli from outside.