FORMALISATION OF A FUNCTIONAL RISK MANAGEMENT

SYSTEM

V´ıctor M. Gul´ıas, Carlos Abalde, Laura M. Castro and Carlos Varela

MADS Group. Computer Science Department

University of A Coru˜na (Spain)

Keywords: Risk management, functional programming, business process modelling.

Abstract: This article shows a ﬁrst approximation to the formalisation of a risk management information system. It is

based on our experience in the development of a large, scalable and reliable client/server risk management

information system.

1 INTRODUCTION

In this paper, we present our ﬁrst attempt to formalise

the model of a large, scalable and reliable client/ser-

ver risk management application called ARMISTICE

(Advanced Risk Management Information System:

Tracking Insurances, Claims and Exposures (Gul´ıas

et al., 2005) http://mads.lfcia.org/armistice).

The main novelty of this system, in the ﬁeld of

risk management informationsystems (RMISs), is the

new approach used to manage the different kind of

heterogeneous business objects. ARMISTICE pro-

vides an abstract frameworkthat can be easily adapted

to any organisation. It represents a step forward

compared with other popular RMIS products like

(STARS, 2005) or (AON, 2005).

The paper is structured as follows. First, a few ba-

sic knowledge about the whole system architecture is

presented. Then, section 3 provides the non-technical

formalisation of the system internals. Finally, section

4 shows some conclusions.

2 SYSTEM ARCHITECTURE

ARMISTICE has a client/server architecture, struc-

tured in layers using two well-known architectural

patterns: Layers and Model-View-Controller (Mari-

nescu, 2002). Figure 1 provides an overview. The

user side is a lightweight Swing/Java client which

performs remote procedure calls to the server (XML-

RPC) and has no associated logic. The server side,

completely developed in the distributed functional

declarative language Erlang (Wadler, 1998; Arm-

strong et al., 1996), supports the model and all the

business logic. In (Cabrero et al., 2003), some addi-

tional technical information can be found.

Figure 1: ARMISTICE three tier architecture.

3 INSURANCE POLICY MODEL

Our system is split into three large subsystems: risks,

policies and claims.

3.1 Risks Subsystem

3.1.1 Risks Situations and Their Attributes

The key concept in this subsystem is the risk situation

(RS). A RS models the state of any element that can

be included on the coverage of a policy (e.g. a shop

or a vehicle). Every RS is an instance of a risks group

516

M. Gulías V., Abalde C., M. Castro L. and Varela C. (2006).

FORMALISATION OF A FUNCTIONAL RISK MANAGEMENT SYSTEM.

In Proceedings of the Eighth International Conference on Enterprise Information Systems - ISAS, pages 516-519

DOI: 10.5220/0002496205160519

 SciTePress

(RG). A RG is a template, that is, a meta-description

of all the important attributes (e.g. address, vehicle

registration number, warehouse area or cubic capac-

ity) which describe the state of any element that can

be insured (e.g. commercial locals or vehicles).

We denote the set of attributes as A, each of them

deﬁned as Attribute =(name, type) where

name ∈ String

type ∈ Types = {String,Boolean,...}

Over these elements, the set of RGs RG is de-

ﬁned. Each member RG

∈RGis a set like RG

,...a

n−1

}∀x ∈ [0,n− 1] a

∈A.

Therefore a RG is a set of attributes which provides

a meta-description of any property that can be impor-

tant from the insurance’s point of view.

Finally, using the RG set, the set of RSs (that is,

insurable elements) RS is deﬁned. A RS RS

is an

instance of a RG RG

(RS

: RG

−→ ∪ Types).

Every attribute in the RG has a concrete value

assigned in the RS.

= {p

,...p

n−1

}∀x ∈ [0,n− 1] p

≡ (a, v)

∧ a ∈RG

∧ v ∈ Type(a)

Then, a RS represents the state of any element that

can be insured. For short, we will use RS

.a to de-

note the value of attribute a of the RS RS

3.1.2 Versions and Revisions of RSs

Using the previous abstraction, it is possible to

model the state of every insurable element (i.e. RSs).

However, business requirements demand a temporal

representation of the RSs. Based on Fowler’s pat-

terns (Fowler, 2005), a temporal tracking of the RS

set is performed. The evolution of a RS is modelled

since its creation as a set of versions and revisions

(two-dimensional temporal modelling). A version

represents a new state of a RS as a result of a business

event. However, a revision represents a new state of

a RS as a result of a mistake or any other business

external event. This behaviour is provided modifying

the original deﬁnition of a RS as follows:

= {RS

,...RS

α−1

}

∀x ∈ [0,α− 1] v

∈ Timestamp∧

x+1

∧

= {RS

,...RS

β−1

}∧

∀y ∈ [0,β− 1] r

∈ Timestamp∧

= v

≤ r

y+1

∧

= {p

,...p

n−1

}∧

∀z ∈ [0,n− 1] p

≡ (a, v)∧

a ∈RG

∧

v ∈ Type(a)

Figure 2: Versions and revisions of a RS.

So the elements belonging to the RS set can be

deﬁned as a collection of items representing different

states from different RSs:

RS ≡ {RS

,...,RS

,...}

∀j ∈ [0, |RS|−1]∧

x ∈ [0,α

− 1]∧

y ∈ [0,β

j,x

− 1]

where |RS| are the actual different modelled RSs.

Therefore, the expression RS

.a must be changed

by RS

.a[vDate][rDate]. With this new model

questions like “At the moment in time rDate ∈

Timestamp, what was the value we thought attribute

a (of RS RS

) had at date vDate ∈ Timestamp,

and which one we do know it is now?” can be an-

swered. Figure 2 shows a schematic view of the

evolution of the versions and revisions of a RS RS

through time.

3.1.3 Hazards that Affect RSs

The risks subsystem is not only a tool for modelling

the state on any insurable element. There is an ad-

ditional and very important concept: the hazards.A

hazard can act over a RS causing a damage or ac-

cident. The system has to manage a set of hazards

H (e.g. ﬁre, explosion or terrorism). Each business

model must state a standard list of hazards adapting it

to its domain, to ease policy modelling.

Thus, ARMISTICE allows the user to handle the

sets A, GR, RS and H. By doing so, our application

can be adapted to a broad variety of business models:

the ﬁrst step would be the deﬁnition of attributes and

RGs. Then, not only the RSs would be created over

these abstractions, but any relevant change in their

states, too. These modelling and tracking activities

are the fundamental working basis for the rest of the

system.

FORMALISATION OF A FUNCTIONAL RISK MANAGEMENT SYSTEM

517

3.2 Policies Subsystem

Policies are the most complex element in the sys-

tem. They group and link every business object.

ARMISTICE works over a set of policies P, where

each policy P

is modelled as a set of renewals P

A renewal represents a new policy created to provide

coverage to a new set of RSs in a new temporal

interval. At the same time, a renewal is composed by

a set of supplements P

.Asupplement represents

a revision of the policy to change its coverage, to

change its contractual clauses, to change its relevant

dates, etc. A supplement represents the minimal

element that can be used to give coverage to a claim.

Here, a temporal modelling is applied, like in section

3.1.2, but with three dimensions or temporal axis:

each supplement P

is parametrised by starting

and ending validity dates, an activation date and a

timestamp.

≡ (Number,{P

,...P

α−1

})

≡ (Receipts, {P

,...P

β−1

})

≡ (Start, End, Activation, T imestamp,

Coverage, Conditional) ∧ Coverage ⊆RS

where Start, End, Activation, T imestamp ∈

Timestamp are the dates used to determine the lo-

cation of the validity period of the policy in the axis

of the three dimensions temporal modelling. As far

as the Coverage is concerned, it represents the col-

lection of RSs states building the insurance of the

policy. Of course, this means that every RS

inside the Coverage set is different, Coverage ⊆

RS ∀RS

, RS

= j

Each policy renewal P

is related to an element

we have called Receipts. This component is in fact

a receipt model (ReceiptModel), and a set of re-

ceipts that appear as a result of some hazard affecting

one or more of our RSs ({ R

,...R

}), Receipts ≡

(ReceiptModel, {R

,...R

}).

When an accident happens to a RS (e.g. a shop),

and we have a particular policy P

to cover all the

arrangements and repairs to be done, all those pay-

ments can be broken down into several items. That

is what the ReceiptModel is intended for: using

formulas-based models (see 3.2.2), it is possible to

express the calculation for each item, and so it is pos-

sible to foresee the amount of all the receipts, even

before they arrive (R

...R

3.2.1 Conditional Clauses

A conditional is the key object to implement the

ARMISTICE help decision support system. It is

used when a user is looking for coverage to any

claim. The supplement conditional is a model of

the contractual clauses of a speciﬁc policy. Thus,

it is linked to a supplement P

. In particular,

the system is only interested in the model of the

policy coverage, that is to say, in the model of the

policy warranties (e.g. the warranty against natu-

ral risks, its application preconditions, its franchise

and its limits). Then, a conditional C

can be repre-

sented as, C

= {g

,...g

}, ∀x ∈ [0,n − 1], each

≡ (Res,Fra,GrlL,PSinL,PSitL,AgrL)

containing an applicability precondition Res ∈Res

(see section 3.2.3), and several formulas Fra, GrlL,

PSinL, PSitL, AgrL ∈For (see section 3.2.2),

used to calculate the franchise and limits (general, per

sinister, per RS and aggregated). These expressions

can access to the context where they are evaluated and

they can use temporal informationabout RSs, policies

and other claims.

3.2.2 Formulas

The set of formulas, together with the RSs meta-

description (i.e. RGs) and the set of hazards H, are

key elements to build a ﬂexible and adaptable RMIS

framework.

Each element For

∈For is a formula which has

been built using an ad-hoc language (which is not

within the scope of this paper) and models a receipt,

franchise or limits calculation.

For

: {RS

/RS

∈RS}×

Puser ×Psys −→ ∪ Types

where Puser and Psys are sets of pairs label/value

which can be accessed using speciﬁc constructors of

the modelling language. The Puser set, also known

as user parameters set, are input values provided by

the user in the process of evaluation of a formula. The

Psys set, also known as system parameters, are val-

ues calculated by the system, whether it be calculated

when the formula is evaluated or through time as in-

ternal counters.

3.2.3 Restrictions

Restrictions are the conditions to be hold by a war-

ranty in order to be activated. Every warranty (i.e.

contractual clause) inside a conditional of a policy

has an applicability restriction which models its be-

haviour.

Each element Res

∈Res is a restriction

which has been build using a language that is a

super-set of the formulas language, where logical

operators and the concept of nuance have been added.

Res

: {RS

/RS

∈RS}×

Puser ×Psys ×{H

∈H}−→

(Integer, Boolean ∪ String)

Once a restriction is evaluated, it can be true or

false (i.e. the associated warranty can be applied

or not). However, sometimes it is not possible to

ICEIS 2006 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

518

Figure 3: Restriction tree.

state directly whether the restriction is true or not.

In this case, the truthfulness of a restriction may de-

pend on the answer of the user to a question expressed

in natural language (i.e. a combination of nuances,

String ∈ Types). Therefore, it could only be eval-

uated to a boolean value by means of human user in-

tervention.

The evaluation process of a restriction can be seen,

then, as a simpliﬁcation of the tree which represents

the contractual clause: the system, using the context

information, removes as many nuances as possible.

The result is a tree with a logical combination of nu-

ances that must be evaluated by a human user.

Figure 3 illustrates the appearance of the internal

structure of a restriction Res

. This could be the ap-

plicability precondition of a contractual clause.

3.3 Claims Subsystem

The risks and policies subsystems provide us with a

full set of tools to model the business framework. The

claims subsystem takes that modelling as a basis to

carry on its own task: performingregistrations of each

day’s incidents, checking their coverage and tracking

their whole life cycle, from opening to closing, man-

aging related tasks depending on the kind of claiming,

receipts and relevant documentation, and, of course,

remarkable calculations to be done.

Thus, in a formal way, we can describe the set of

claims in the system, CM, as a set of elements,

≡ (HDate,{H

,...H

AffectedRSs,P

)

HDate ∈ Timestamp∧

AffectedRSs ⊆RS

∀RS

,RS

= j

∧

∈ (Conditional ∈ P

)

that represent the relationship between the RSs

affected by one or more hazards on date HDate.

HDate is also the one used to ﬁnd the most suit-

able warranty to cover a claim, that is to say, the one

that will be used to locate a supplement with a ear-

lier effective date and a later expiration date. Once

the appropriate-by-date P

supplements are iden-

tiﬁed, their warranties must be examined, and the

most accurate one (g

) is chosen by the user to be

charged with all the expenses.

As can be seen in this deﬁnition, the same com-

ment we made when talking about the policies cov-

erage is applicable here: each RS

inside the

AffectedRSs set must be different. As both sets

will be checked for total/partial matches, this makes

all sense.

4 CONCLUSIONS AND FUTURE

WORK

In this paper we have presented a formalisation of

the ARMISTICE kernel, pointing out the extensibil-

ity and adaptability properties that the model has. We

have left out both technical information and low-level

details.

Nowadays, ARMISTICE is being successfully de-

ployed in the risk management department of a large

holding enterprise for about a year. Its adaptability

has been proved as it has been possible to model eas-

ily all the insurable elements, policies and hazards.

Moreover, the formalism introduced by the need of

that modelling has made possible to detect small mis-

takes in theoriginal composition ofthe policy clauses.

To sum up, the ARMISTICE adaptability and mod-

elling tasks are a differential factor regarding other

RMIS systems.

REFERENCES

AON (2005). Aon. http://www.aon.com.

Armstrong, J., Virding, R., Wikstr¨om, C., and Williams, M.

(1996). Concurrent Programming in Erlang, Second

Edition. Prentice-Hall.

Cabrero, D., Abalde, C., Varela, C., and Castro, L. (2003).

Armistice: An experience developing management

software with erlang. PLI’03. 2nd ACM SIGPLAN Er-

lang Workshop, pages 23–28.

Fowler, M. (2005). Design patterns.

http://www.martinfowler.com.

Gul´ıas, V. M., Abalde, C., Castro, L., and Varela, C.

(2005). A new risk management approach deployed

over a client/server distributed functional architecture.

18th International Conference on Systems Engineer-

ing (ICSEng’05).

Marinescu, F. (2002). EJB Design Patterns. Advanced Pat-

terns, Processes, and Idioms. John Wiley & Sons, Inc.

STARS (2005). Stars. http://www.starsinfo.com.

Wadler, P. (1998). Functional programming: An angry half

dozen. SIGPLAN Notices, 33(2):25–30.

FORMALISATION OF A FUNCTIONAL RISK MANAGEMENT SYSTEM

519