How an Electronic Payment System is Modeled for Future Banking Purposes?

## **Short Answer**

Could you imagine a situation when we are trying to shop online and the only way to pay is by sending a check in the mail? And how about we are not able to use a credit or debit card when you went out to shopping or to eat or have gas for your car? The way of transferring money has advanced tremendously over the last few years. PayPal, online bill pays, and mobile payments are all examples of recent advancements. These changes are led to electronic fund transfer system (EFTs) or electronic transfer of money from one account to another.

### **Electronic Fund Transfer(EFT)**

Basically electronic fund transfer is about moving funds through computer systems without the need of paper documents. Technically Electronic Fund Transfer is the electronic transfer of funds from one bank account to another, the transfer can be either within a single financial institution or across multiple institutions, through computer-based systems and without the direct intervention of bank staff. EFTs include direct-debit transactions, wire transfers, direct deposits, ATM withdrawals and online bill pay services.

EPS(electronic payment system) is an important application area for both the theory and practice of system specification. In theory they demonstrate abilities of a specification method. In practice they are safety critical systems. We study in detail how to build a formal specification for the electronic payment system ep2, a new international standard developed by a consortium of leading Swiss finance institutes. It is built using abstract data types and process algebra. The description of the system is an actual industrial standard used to develop the next generation of automatic banking machines. The language used for specification is Csp-Casl.

### **ep2 System**

The system consists of seven autonomous entities centered around the ep2 Terminal:

Cardholder (customer), Point of Service (cash register), Attendant, POS Management System, Acquirer, Service Center and Card.

The entities communicate with the Terminal and to an extent with one another via XML messages. These messages contain information about authorisation, financial transactions, as well as initialisation and status data. The state of each component depends on the content of the exchanged data. Each component is a reactive system defined by a number of use cases. Thus, there are both reactive parts and data parts which need to be modelled, and these parts are heavily intertwined.  The specification consists of roughly 600 pages of text. Csp-Casl uses Csp for the modelling of reactive behavior, whereas the properties of the communications are specified in Casl.

### **CSP-CASL**

Communicating sequential process(CSP) is a formal language for describing patterns of interaction in concurrent systems. It is process algebra or process calculi which is one of the mathematical theories of concurrency known as process algebra which is based on message passing via channels. The Common Algebraic Specification Language (CASL) is a general-purpose specification languagefirst-order logicinduction

Csp-Casl is a comprehensive language which is a combination of both CSP and CASL which combines the processes written in CSP and data types in CASL. The general  idea of this language combination is to describe reactive systems in the form of processes based on Csp operators, but where the communications between these processes are the values of data types, which are loosely specified in Casl. The CSP conditional construct uses CASL to obtain the general syntax of CSP-CASL as follows.

***ccspec N = data Sp Channel Ch Process P end***

This is the general synatx for a Csp-Casl specification. So, syntactically, a Csp-Casl specification with name N consists of a data part Sp, which is a structured Casl specification, an (optional) channel part Ch to declare channels, which are typed according to the data specification, and a process part P written in Csp, within which Casl terms are used. For the purpose of specifying ep2 in Csp-Casl, we mainly use the Csp denotational stable-failures model. This model is able to distinguish between the different choice operators, and allows for infinite non-determinism as well as for infinite communication alphabets: features which naturally appear in abstract system descriptions involving loosely specified data.

According to the general paradigm of Csp-Casl there are two main aspects: the reactive behavior of ep2 components and data structures which are involved. In reactive behaviour of a system there are three levels of Csp process which interchange data over communication channels typed by Casl sorts. They are, *Architectural level* which contains the terminal process. *Abstract component description level*which is used to refine the processes of RUN(A). The *Concrete component description level,*we model which specific values the terminal is going to send.

Speaking about the data on differents levels of abstraction, in *Architectural level*it is sufficient to speak merely about the existence of values which are communicated over channels. In component specification level if it is abstract it is sufficient to introduce suitable subsorts. If it is concrete it is necessary to specify the data types up to representation.

## **Long Answer**

### **The ep2 System**

ep2 stands for ‘EFT/POS 2000’. This is short for ‘Electronic Fund Transfer/Point Of Service 2000’. It is a joint project established by a number of financial institutes in order to define EFT/POS infrastructure for credit, debit, and electronic purse terminals in Switzerland.

### **ep2 Document Structure**

The ep2 specification consists of twelve documents. The Terminal, Acquirer and the other components have specification documents which show the ‘general’, ‘functional’, and ‘supplementary’ requirements. The functional requirements carry the most detail. They consist mainly of use cases discussing how that particular component behaves in various situations. One characteristic of this specification document is that in order to gather information about one aspect, the information required to understand that aspect is contained in several different documents.

For example, in order to gather all information about the SI-Init interface between Terminal and Acquirer, one has to examine the Terminal Specification, the Acquirer Specification, the Interface Specification, and the Data Dictionary.

### **ep2 Specification style**

The ep2 documents have a number of different specification notations: plain English; UML-like graphics, file descriptions, pictures, encoding rules.

*Tables:*

For the SI init connection we focus on the connection between the Terminal and Acquirer.

The aquirer can be defined in a table of roles as a "Card Processor, which runs a system for processing of electronic payment transactions. Acquirer is in contact with the merchant."

In another table it also describes the main system features and its functionality is classified into four subsystems:

              Acquirer Initialisation System: Exchanges Terminal configuration data with the Service Center.

              Authorisation System: Processes Terminal on-line authorisation requests, as well as transaction                 reversal requests. Forwards issuer scripts to the terminal.

              Submission System: Processes transactions.

              Reconciliation System: Provides reconciliation data to the merchant.

In the Acquirer general requirements document, a fifth subsystem is identified:

              COI 2 server: Used for data exchange with the Service Center.

*Use Cases:*

In system specification this communication is depicted in a use case

Figure 3 shows that the “Get Initialization Function” can be called by the service man either directly at the Terminal, or via an “Initiate Terminal Setup” at the Point of Service. The function can also be called by a timer process, or by an authentication server process.

### **Formalizing ep2 in CSP-CASL**

As we discussed earlier about the general paradigm of Csp-Casl.

#### **Reactive Behaviour**

Consider the given below example in figure 4

##### ***Architectural level***

Here, we use the Csp alphabetized parallel operator, example [ C COI-Config || C COI-Config, C MI Subm or Rec ] (line 28), which synchronizes in the intersection of the two alphabets, i.e. in this example in C COI-Config. On the architectural level, we leave the behaviour of the different processes completely unspecified, i.e. they are modelled by the Csp process RUN(A), which is the deadlock-free, non-terminating process.

##### ***Abstract component description level***

This example stems from the Terminal specification, showing the Terminal’s reactions to the Acquirer’s requests on initialization data.In a first step, we specify only that the Terminal produces answers of the right kind, e.g. on a D\_SI\_ConfigDataRequest a D\_SI\_Init\_ConfigDataResponse is sent.

**Example**

**TConfigManagement = C\_SI\_Init ? x ->**

**if x in D\_SI\_ConfigDataRequest**

**then !y:C\_SI\_Init.D\_SI\_Init\_ConfigDataRespons -> TConfigManagement**

**else if x in D\_SI\_ConfigDataNotification**

**then !y:C\_SI\_Init.D\_SI\_Init\_ConfigDataAcknowledge -> TConfigManagement**

**else** ....

Here, !y:A -> P denotes the process which first communicates a value y out of the set A and then behaves like P; i.e. the ! operator is similar to the Csp prefix choice, but for the former the choice is internal, while for the latter the choice is external.

##### ***Concrete component description level***

At this level the process becomes stateful i.e., it depends on a parameter p:Pair[TState][Trigger].

Consider the below example, it shows the interaction between the specification of reactive behaviour and the modelling of data types when studying the control flow within a component.A message x is received from the Acquirer over the channel C\_SI\_Init. Depending on the type of x, different answers are sent back to the Acquirer, e.g. information configDataResponse(x,state(p)) on the current configuration of the Terminal or a message configDataAcknowledge. Then the configuration management is continued, either without a state change or with a state change to pair(activateData(x,state(p)),trigger(p)).

 **Example:**

**TConfigManagement (p:Pair[TState][Trigger] =   C\_SI\_Init ? x ->**

**if x in D\_SI\_ConfigDataRequest**

**then C\_SI\_Init ! configDataResponse(x,state(p)**

**-> TConfigManagement(p)**

**else if x in D\_SI\_ConfigDataNotification**

**then C\_SI\_or\_FE ! configDataAcknowledge**

**-> TConfigManagement (pair(activateData(x,state(p)),trigger(p)))**

**else....**

#### **Data on different Abstract levels**

##### ***Architectural level:***

From figure 6 let us consider the data sort D\_CAI\_Card is interchanged on a channel C\_CAI\_Card: D\_CAI\_Card between the Card and the Terminal.Or a channel shall be shared by different message types, as channel C\_MI\_Subm or Rec: D\_MI\_Subm\_or\_Rec. Here, the Casl free type construct ensures that the different kinds of data are kept separate.

##### ***Component description level***

Consider the below example  which is used to specify how the Acquirer interchanges initialisation data, it is enough to know the type of the data, i.e. whether it is a <<SessionStart>> Message or a <<ConfigDataRequest>> Message. In Casl, this can be specified by a free type construct.

**Example:**

**free type D-SI\_Init : : = sort D\_SI\_Init\_SessionStart**

*|* **sort****D\_SI\_Init\_ConfigDataRequest**

*|* **sort D\_SI\_Init\_ConfigDataResponse**

**| ......**

where each alternative corresponds to a message type occurring in the activity diagram.

Up to now data modelling involved only sort declaration, sub-sorting and several forms of disjoint union via the free types construct. But on the component description level, also operations on data and axioms describing them comeinto play. Consider the below example from the context of Terminal's initialization. The ep2 documentaion states that: If the configuration download is started by the service man or the ‘Use Case: Initiate Terminal Setup’, the Terminal sets the <Config Download Mode> to ‘1’ indicating ‘Forced download’ otherwise to ‘0’ for ‘Download check’.

**Example**

**axioms sessionStart(serviceMan) = forcedDownload;**

**sessionStart(initialTerminalSetup) = forcedDownload**

**sessionStart(others) = downloadCheck**

Formalising ep2 in Csp-Casl leads to the partial or complete resolution of the problems associated with ep2.

Figure 5 Sequential diagram for requesting configuration data (Left) and activity diagram of ep2 (Right)

Looking on the reactive side, a comparison of  both the diagrams in Figure 5 they show that they specify the order of Requests and Responses differently: Left diagram requires that after one Request exactly one Response has to follow. In spite of this, the right diagram suggests that several Requests and sever

al Responses can be ‘bundled’, and that a session might include different numbers of Requests and Responses. This inconsistency is clearly due to the change between the two formalisms involved (and maybe a weakness of the latter). In Csp-Casl, we can easily specify both variants; in our ep2 formalization.

## **Conclusion**

We have shown how to specify a non-trivial system in the formal specification language Csp-Casl. Since ep2 is a prototypical example, the obtained results also hold for other systems such as web services, communicating financial agents, etc. Reconsidering our original aims, the specification language turned out to be wellsuited to “translate” informal and natural language constructs, and rich enough to cover most important aspects of this particular system. Furthermore, it turned out that it is mostly possible, but not always advisable to follow the original document structure in the formalization. Considering scalability, we found that it is neither much harder nor much simpler to write a formal than an informal specification. In fact, we think that both styles have their own benefits; ideally the formal text should accompany informal descriptions in a ‘literate specification’.

## **References:**

**[1] http://www.investinganswers.com/financial-dictionary/personal-finance/electronic-funds-transfer-eft-2328**

**[2] Gimblett, A., Roggenbach, M., & Schlingloff, B. (2005). Towards a Formal Specification of an Electronic Payment System in CSP-CASL. Recent Trends in Algebraic Development Techniques Lecture Notes in Computer Science, 61-78. doi:10.1007/978-3-540-31959-7\_4**

**[3] Roggenbach, M. (2006). CSP-CASL—A new integration of process algebra and algebraic specification. Theoretical Computer Science, 354(1), 42-71. doi:10.1016/j.tcs.2005.11.007**

**[4] Fiadeiro, J. L. (1999). Recent trends in algebraic development techniques: 13th international workshop, WADT '98, Lisbon, Portugal, April 2-4, 1998: Selected papers. Berlin: Springer.**

**[5] http://www.investinganswers.com/financial-dictionary/personal-finance/electronic-funds-transfer-eft-2328**