FraTAct for Transforming A Nescient Process Activity Into an Intelligent Process Activity

Existing business process technologies support defining only nescient activities. Currently there is no solution that underpins transforming a nescient activity into intelligent activity. In this paper, we address this shortcoming of the state of the art. We offer a framework ‘FraTAct’ for transforming regulation intensive nescient activities of a financial service business process into intelligent activities. Financial service industries has been experiencing enormous challenges since the last decade. A recent financial crisis has unearthed various weaknesses in terms of administering the financial service industries. In order to prevent the future crisis, the regulators are constantly formulating new rules and also forcing the financial service industry to enact financial regulations in their financial service based application which automates financial operations. A financial service application underpins the financial service business process that contains activities. A nescient activity within a financial service process is prone to the risk of producing an inconsistent outcome that results in severe legal consequences for a financial institute e.g., a bank. In order to avoid these legal consequences, a financial institute should develop their financial service processes by composing activities that should be intelligent to understand and comply with financial regulations. Intelligent activities will produce outcomes that are consistent to financial regulations. It will reduce the possibility of financial regulation noncompliance in financial service process based application. Received on 02 March 2013; accepted on 07 November 2013; published on 04 March 2014


Introduction
A process simply put, is a set of ordered activities [15].Activities carry out operations while a process is running and producing outcomes.The notion of process is used in different domains such as software process, chemical process and so forth.In this paper, process refers to financial service process and activities are financial service activities.In a financial service process (FSP), the operations must be performed in compliance with financial regulations that are essentially financial rules.An operation produces an inconsistent outcome if it does not comply with the relevant regulations.Inconsistent compliance outcomes result in severe consequences for an organization regardless of whether it is a financial or business organization.The Enron-Scandal [12] is a practical example.Therefore, compliance is a highly significant issue in FSP.
Activities within FSPs are regulation-intensive which means that they are based upon financial regulations (e.g., Basel III accords [3]).However, some activities within an FSP may not be regulation-intensive.A regulation-intensive activity within an FSP is called nescient if it lacks explicit knowledge about the underlying regulations, it lacks correlation with financial regulations, and the activity cannot produce consistent outcomes.A nescient activity is not able to perform operations that comply with financial regulations.This promotes the need for activities that are able to perform operations in compliance with regulations.
Existing business process technologies (e.g., BPEL [21]) lack the constructs for defining (modeling) intelligent activities in a financial service process.Some approaches (e.g., Business Process Model and Notation (BPMN) [22])facilitate annotating meta-data of a process activity to give the semantics of that activity.However, these approaches cannot be used for FSPs due to the complexity and ambiguity in financial regulations.More specifically, an FSP is slightly different from the classical business process activity as it must be aware of one or more financial regulations which can be a conjunctive statements.It may not be easy to annotate an FSP with a conjunctive statement which expresses explicitly the semantics of different parts of it.In addition, transforming annotated financial regulations into machine readable ones by preserving their semantics is still an unsolved issue.A solution that supports the straightforward transformation of a nescient activity into an intelligent one is strongly required for smart financial service processes.
In this research, we offer a framework named FraTAct that underpins transforming nescient activities into intelligent activities within the FSP space.It is important to mention that the transformation happens indirectly i.e., the framework supports the nescient activities by providing the exact meaning of regulations and also assists in performing operations complying with financial regulation.In order to do so, the FraTAct framework uses the notion of the knowledge base.The knowledge base is developed using an ontology approach.
The remainder of this paper is organized as follows.A motivating example is presented in section 2. The preliminaries are described in section 3.In section 4, we describe the knowledge base for financial services.Section 5 presents the FraTAct framework.We discuss implementation of the proposed solution in section 6.The related works is discussed in the subsequent section.Finally, section 8 outlines the conclusion and future work.

Motivating Example
This sections sets out the Common Equity Tier 1 Capital Ratio Calculation Process model.The process model is developed based on the description provided in [3].In order to make the example simple, a limited number of activities have been incorporated in the process.Fig. 1 shows the process model.
The process starts with performing the 'List Common Equity Tier 1 Financial Instruments' activity that The 'Common Equity Tier 1 Capital Ratio Calculation' process is driven by regulations particularly, the Basel Capital Accords.The activities contained in this process are regulation-intensive.The operations performed by these activities must comply with the Basel accords.These accords are ambiguous.Therefore, understanding the semantics of these accords is a critical importance for the activities.
Activities contained within 'Common Equity Tier 1 Capital Ratio Calculation' are nescient as these activities lack the support of an approach that enables performing operations intelligently.The FraTAct framework supports transforming these activities into intelligent activities that carry out operations by realizing the semantics of the financial regulations derived from the Basel accords.The framework leads financial service process execution in compliance with the corresponding regulations and prevents unwanted consequences for financial institutes.

Preliminary
In this section, we provide a brief description of intelligent activity.In addition, this section explains ontologies and description graph.

Intelligent Activity
Intelligent activity is defined in [10]  (ii) it relies on regulations which are encoded as axioms in a decidable description logic [13], (iii) it cannot produce outcomes that are non-compliant to regulations, (iv) Any activity that does not satisfy (i), (ii) and (iii) conditions will not be considered as intelligent activity within FSP.
For example, list common equity Tier 1 capital ratio calculation is a intelligent activity if it is able to interpret the semantics of the corresponding regulations (derived from the Basel Accords), complies with those regulation while executing the activities, and the activity produces the list that was desired by the users.

Ontologies and Description Graph
The Ontology Web Language (OWL2) [4] is used for modeling ontologies.The SROI Q DL [13] provides reasoning services for ontologies based on the tableau algorithm.The basic OWL2 concepts are classes, object properties, data-type properties, and individuals.Additionally, an ontology contains class axioms, and property assertions as well as individual assertions.Semantic Web Rule Language (SWRL) [14] is used to model rules in an ontology.
A Description Graph (DG) [18] is a directed labeled graph that contains a set of vertices, edges and a labeling function that assigns each node to an atomic concept, and each vertex to an atomic role.According to [18], a graph-extended knowledge base is a 4-tuple K = (T ; P ; G; A) where T is a TBox, P is a program, G is a GBox, and A is an ABox.The P consists of a finite number of connected rules.The G contains graphs roles i.e. roles one can use in a DG [17].Reasoning with ontology is, mostly, based on tableau [13] and hypertableau [18] algorithms.

Knowledge Base for Financial Services-A Graph-Extended Approach
As already mentioned, financial service components are built on a knowledge base (Fig. 2 shows the knowledge oriented service components).In this section, the core mechanism of knowledge base for financial services is described.Financial regulations are basic building blocks for financial services.Therefore, our aim is to develop knowledge bases for financial regulations.In this section, we explain how to encode regulation corresponding to common equity Tier 1 capital ratio calculation process (shown in Fig. 1) into a graphextended knowledge base [18] and check satisfiability of the knowledge base using a hyper-tableau algorithm [17].Modeling FSPs using graphs is not a new idea [28].However, a problem arises when one needs to apply automated reasoning on the processes which must satisfy certain regulations.The execution of each activity in the common equity Tier 1 capital ratio calculation process relies on regulations derived from e.g.Basel III accords.
Reasoning with the process (shown in Fig. 2) is provided indirectly over reasoning with regulations encoded as a graph-extended knowledge base.We do not specify regulations in the process itself.The reasoning with the given process is important to check whether the activity of financial service processes is compliant with the Basel regulations upon execution.It means that the activity has been executed successfully and is consistent with regulations from where it is taken [3].To consume regulations encoded as graph-extended knowledge base, the reasoner must check satisfiability (see Fig. 2).

Figure 2. Encoding FSP to graph-extended knowledge base
To encode financial regulations underlying the activities within an FSP space, we use the graphextended knowledge base, as follows: We encode the regulations into a graph-extended knowledge base for the following reasons: (i) OWL2 is not expressive enough to encode financial regulations as non-tree structures [17], (ii) Hyper-tableau algorithm is practically efficient in reasoning with more than one DG.Also it is possible to encode process regulations into more than one DG.

Execution of the List of Financial Instruments of Core Capital and the List of Financial Instruments of Additional
Capital (see Fig. 1) must comply with the following regulations, taken from [3]: (R1) If a financial institute has a financial instrument as common stock and the common stock can be converted to a currency, then the given currency is a principal amount for the financial institute.(R2) If a financial institute has a currency as a principal amount and the currency is represented by a common stock, then the financial institute has a financial instrument as given by common stock.
The regulations (R1), (R2) are encoded into the following first order logic formulas: Formula (1) encodes regulation (R1) while formula (2) encodes regulation (R2).The formula (3) specifies the relationship between common stock and currency.Formulas (1), (2) can be expressed as property chains that are not allowed in OWL2.Instead, we use formalism based on DGs.Fig. (3) shows the DG which corresponds to regulations (R1) and (R2).The formal definition of the DG shown in Fig. 3 Concept names are represented as nodes in the graph (see Fig. 3) as shown in formulation (4) [18]: The concept FinancialInstitute is the main concept.Each node in the graph (see Fig. 3) is related to a concept name.The graph roles are defined as follows: The extended signature of the graph (see Fig. 3) is: The set of Tbox roles is empty and all roles are graph roles [18].The formula G(BankOf Ireland, stock1, euro) represents an instantiation of the graph.

Reasoning with Financial Regulations
Reasoning with financial regulations involved with common equity Tier 1 capital ratio calculation process (see Fig. 1) includes: • Preprocessing the DG which implements regulations consumed by common equity Tier 1 adequacy calculation process, • Application of derivation rules to the graphextended knowledge base.
Applying derivation rules, the hyper-tableau algorithm checks the satisfiability of (R, A) where R = [∼ ](G) ∪ P , and where A is defined Abox [17].To prove satisfiability of given graph-extended knowledge base, the hyper-tableau algorithm tries to construct a model of a (R, A) by applying different derivation rules to R, A. Before applying the rules, it is important to define at least one Abox A. If ⊥ ∈ A then there is a clash and the algorithm will detect inconsistency in the knowledge base.

FraTAct -Activity Transformation Framework
FraTAct (Framework for Transforming Activity) supports the transformation of a nescient activity of a financial service process into an intelligent activity.This framework combines two different but complementary technologies which include ontology based technologies and service oriented technologies.In this section, an overview of the framework is presented and the underlying technique of the framework is described.
The FraTAct framework is developed relying on Service Oriented Architecture (SOA) [27].It adopts two characteristics of SOA including loose coupling and ubiquity.The FraTAct framework consists of a process design interface, a process engine, service component repository, and management components.FraTAct is a multi-layer framework depicted in Fig. 4. (ii) Process Engine: Process engine is a back-end component which resides at the process layer.
A process after designed is deployed in the process engine that executes the process.The process engine executes processes by means of invoking the components for process activities (aka services).In other words, the process engine orchestrates the financial services business process activities.
(iii) Component Repository: Component repository resides at the component layer.It contains knowledge oriented financial service components that 'actualizes' the process activities.The term 'actualization' refers to performing operations.Precisely, the components perform operations of corresponding process activities.The process engine invokes one or more of these financial service components for performing a process activity.
Financial service components are the key constituents in a financial service system.These components perform operations of a corresponding process activity by relying on the financial regulation knowledge base.In effect, a process activity which used to be a simple abstraction that is not aware of financial regulations, turns into an intelligent one.It is worth noting that the intelligence of a financial service process activity is its ability to realize the exact semantics of financial regulations and carry out operations by complying them.
(iv) Process Manager: Process manager resides at management layer.It is responsible for performing management tasks such as substituting activities contained in business processes for adapting a change.In addition, it supports modification of business processes.
(v) Message Broker: It is a message management component residing at management layer.This component acts to manage messages exchanged between the components, components and process engine, and also between the components.The message broker is connected with the process manager.Any changes occur in processes may promote adjusting the messaging sequences, aggregating messages in message broker.

Implementation of FSBA using FraTAct Framework
Throughout this section, we will describe how we have implemented an FSBA using FraTAct framework.According to our understanding, an implementation of a Financial Service based Application(FSBA) will suffice in demonstrating how FraTAct assist in transforming a nescient activity into intelligent activity.Notably, we have implemented common Equity 'Tier 1 Capital Ratio Calculation Process' shown in Fig. 1.Sections include 6.2, 6.3, 6.4 will describe our implementation.In any case, we will provide an overview of the technological aspect of the framework in section 6.1.

Technological Overview of FraTAct Framework
FraTAct framework shown in Fig. 4 relies on OpenESB [26] that is a middleware comprises a list of components.We will not describe all of these components in this section rather we will briefly introduce the components that are used in FraTAct framework.
FraTAct is built by integrating a process design component.The component provides an interface for designing financial service business process.It offers elements used in designing financial service business processes.The framework integrates a scalable BPEL [21] service engine for executing financial service business processes.
Java Enterprise Edition (Java EE)is integrated into FraTAct.FraTAct Java EE facilitates building ontology oriented financial service components.Since FraTAct is built on the service oriented architecture paradigm, the components are offered as services using Web Service Description Language (WSDL) [34] which describes the service components specifically, the operations, and inbound and outbound messages.FraTAct relies on XML schemas for specifying inputs for the components that perform operations based on the given inputs.
FracTAct was deployed into Glassfish container [9] which is an application server.Furthermore, FraT-Act utilizes Composite Application Service Assembly (CASA) to facilitate the users to assemble the financial service components in an FSBA.FraTAct relies on Java Business Integration module (JBI) that offers the binding components used to bind the components, messages, processes, and container.For exchanging messages, FraTAct depends on Simple Object Access Protocol (SOAP) [32].
FraTAct framework utilizes Glassfish administration module as a process manager (shown in Fig. 4) for managing the changes while financial service business processes are running.The module offers a user friendly interface for managing business processes.Moreover, FraTAct integrates the Hermes Java Messaging Service (Hermes JMS) [11] that is a message broker used in publishing and editing messages between service components that hosted at distributed locations.

Implementation of Service Component
At the first phase of our implementation, we develop service components.The development of service components rely on the mechanism described in section 4. We develop two components bsOntology.java and OntoConsistency.javathat perform the List Common Equity Tier 1 Financial Instruments and Verify the List activities (see Fig. 1 ).These activities are regulation intensive, should be performed intelligently.Therefore, the components developed in this paper are ontology based.We describe the development of our ontology based service components in this section.
We implement the following financial instruments: Common shares, Stock surplus, Retained earnings, Comprehensive incomes, Other disclosed reserves, Subsidiaries common shares.Minority interests financial instrument is not part of the current implementation.The Implementation consists of three parts (see Fig. 5): • Implementation financial regulations as local ontologies.For each financial instrument we have one local ontology.For example, common share local ontology.
• Implementation financial regulations as description graphs.
• Integration ontologies and description graphs.
We use OWL2 language to implement local ontologies.To check consistency of the ontologies we use Pellet reasoner [20].When OWL2 is not expressive enough for implementing financial regulations, then we  To create graph concepts and roles we use AtomicConcept and AtomicRole classes respectively imported from Hermit API [31].For the creation of graph roles we allocate memory using the AtomicRole class.To check satisfiability of the graph-extended knowledge base, the Hermit reasoner takes ontology and DG as input.In order to do that, we use the Reasoner class imported from the Hermit API.For more details, how to implement some financial regulations using description graphs, please see [23].Imported ontology can not contain built-in predicates because HermiT reasoner does not support reasoning with built-in predicates.For example, the HermiT reasoner is not useful in case of testing consistency of ontology during calculation equity capital in a balance sheet.For such cases, we use Pellet reasoner.
To implement regulations for all financial instruments, integration of ontologies and description graphs is employed.We use a hybrid approach (see Fig. 5) because of the following reasons: • Local ontologies and graphs are easy to modify.
The reason is that some regulations can be changed in the future and it requires modification of local ontologies.
• Integration module connects local ontologies and graphs.It will allow different type of reasoners to check consistency of different ontologies extended with description graphs or just checks the consistency of ontologies without extensions with description graphs.
• Local ontologies and description graphs can be interconnected independently of integration module.For example, one local ontology can be imported into another local ontology.

Implementation of Financial Service Process
The previous section describes the implementation of service components bsOntology.java and OntoConsistency.java.We wrapped these components using WSDL [34] as services bsOntologyService.wsdl and bsOntoConsistencyService.wsdl and published on Glassfish container.In addition, we developed a client side web service bsOntologyCChkWSDL.wsdlthat provides interface for accepting the requests from the client.
Next, we implemented the Common Equity Tier 1 Capital Ratio process shown in Fig 1 .In order to implement the process, we used BPEL (version 2.0) -an eXtensible Markup Language (XML) based de facto language for developing business processes.First, we defined a Process Scope that contains the process activities.The scope contains StartOntologyProcess activity that receives requests from client service bsOn-tologyCChkWSDL.wsdl.Fig. 6 shows the connection between StartOntologyProcess activity and bsOn-tologyCChkWSDL.wsdl service.The next activity contained in the scope AssignInput copies the input to the subsequent activity ProvideOntology within the scope.It is a regulation intensive activity and upon triggering this activity the process engine invokes the ontology oriented service component GetOntologyService.WSDL that actualizes List Common Equity Tier 1 Financial Instruments (see Fig. 1).As this component is an ontology based component, it performs activity by realizing the semantics of financial regulations and in effect, the activity List Common Equity Tier 1 Financial Instruments turns into an intelligent activity.A BPEL script bsOntologyProcess.bpel is generated automatically which is then deployed on the processes engine.The BPEL script is added in Appendix.

Implementation of Common Equity Tier 1 FSBA
We describe how the financial service based application was developed.The application was developed by binding service components with 'Common Equity Tier 1 Capital Ratio Calculation' process that we implemented(described in the previous section).The 'Composite Application Service Assembly (CASA)' facilitates developing the common equity tier 1 capital ratio calculation service based application.We will describe how we assembled the service components into an application.
We generated the Jar files from process bsOntol-ogyProcess.bpeland service components bsOntology.java and OntoConsistency.java.The jar files bsOntologyProcess.jar,bsOntology.jar, and Onto-Consistency.jar are then imported on Java Business Integration module that binds the service components using SOAP protocol.The application was then built and deployed in the Glassfish application server.Fig. 7 depicts the development of common equity tier 1 FSBA.
The financial service based application of common equity calculation process is now ready to automate the common equity tier 1 capital ratio calculation process.The application performs the regulation intensive process activities intelligently.
Scalability and performance of the approach on a large scale of DGs depends on the HermiT reasoner performances discussed in [19].The reasoner shows significant advantages in reasoning with a large scale ontologies [19] comparing to other standard reasoners such as the Pellet [20].The open issue is how to query financial ontologies extended with description graphs by using SPARQL.

Related Works
In this section, we discuss the related solutions revolving around the financial regulation knowledge base, reasoning, and process.To the best of our knowledge, financial regulation has been scoped in a very small amount of research.Thus, the actual need (e.g., machine readable definition of Basel-based regulations) of the financial service industry has been addressed very briefly in current solutions.Some very recent research including [29], [30], and [1] focus on investigating the issues and challenges, and defining a roadmap for governance, risk and compliance within business processes.Nonetheless, no concrete solution has been discussed in these works.Additionally, a language to capture the compliance requirements of business processes is proposed in [33] and [6].The language is promising, but offers a very limited number of constructs that do not facilitate defining financial regulations in FSB.Solutions including [7] and [16] are offered to perform reasoning on business processes to verify the correctness of business processes.However, these solutions do not address the problem of this research.

Conclusion
In this paper, we have shown how to transform a nescient activity within an FSP into an intelligent activity.In order to support the transformation, we have EAI European Alliance for Innovation shown how to encode financial regulations into a graphextended knowledge base that assists process activities to perform operations intelligently.Additionally, we have shown how to perform reasoning with financial regulations.We have also described the current state of implementation.
We plan to extend the solution in order to enable a system to decide actions for the conditions that are evolved at runtime.In the future, we plan to cover more complex financial regulations.In addition, our intention is to cover financial regulations from various bodies.We also plan to enable these systems to support fuzzy reasoning.Keeping completeness for an incomplete ontology reasoner is a challenge [8] which we have experienced in this research.We will try to tackle this challenge in its future extension.
Currently, FraTAct is a specific framework which serves only financial domain but we plan to add more features that can cover other domains such as business to business(B2B).In B2B, businesses are governed by service-level agreement (SLA).The business processes activities must be accomplished by satisfying SLAs.We plan to develop knowledge-oriented component which provides explicit semantics of SLA clauses for corresponding process activities.We are considering to integrate technologies such as Semantic Markup for Web Services(OWL-S) [24].

Figure 1 .
Figure 1.Common Equity Tier 1 Capital Ratio Calculation Process (i) Entities related to each activity are encoded as nodes in DG, (ii) The interconnection between elements is represented by graph roles, (iii) DG rules and SWRL implement regulations related to an activity, (iv) Restrictions on the graphs implements control flows between elements.

Figure 3 .
Figure 3. DGs for Common Equity Tier 1 Capital Ratio Calculation Process shown on Fig. 1 ) N Rg = {hasFinancialInstrument, convertT o, represnetedBy, hasP rincipalAmount}, N I = {bankOf Irelan, stock1, euro} N C represents the set of graph concepts, N Rg is the set of graph roles, and N I represents the set of individuals.

Figure 5 .
Figure 5. Federation of ontologies in graphs extended knowledge base

Figure 6 .
Figure 6.Implementation of Common Equity Tier 1 Capital Ratio Process

Figure 7 .
Figure 7. Graphical View of of Financial Service Application