Open access peer-reviewed chapter

Payments Systems Determination by Universal Financial Industry Message Scheme According to Single Euro Payments Area

Written By

Slobodan Nikola Babić

Submitted: April 17th, 2016 Reviewed: October 10th, 2016 Published: January 18th, 2017

DOI: 10.5772/66250

Chapter metrics overview

1,581 Chapter Downloads

View Full Metrics


This research was initiated by phenomenological events which were recognized in Single Euro Payments Area payment systems, based on the universal financial industry message scheme standard. This paper shows the determination of payment systems based on their structure (all the way from retail users up to the Central bank) and on the subject they are dealing with (payments, forex notifications, securities, trade services) by universal financial industry message scheme standard. The paper provides description of an adequate way of payment system elements creation with potential automation of industry payment systems creation that are of great importance for the society they are serving. It also demystifies these mission critical systems creations and makes it more comprehensible for experts in various fields who have never before had a chance to deal with the financial industry systems, and who could, thanks to their various expertizes, contribute to the development of these systems.


  • design
  • standardization
  • management
  • single euro payments area
  • universal financial industry message
  • scheme
  • standard
  • payment
  • system

1. Introduction

Payment system consists of payment instruments, bank procedures and system for assets transfer between financial institutions so that money assets can be provided [1]. Central bank, standing at the top of the banking system, defines, regulates and directs money flows within its basic role as financial flows regulator and controls payments systems including the most important real-time gross settlement system (RTGS). Real-time gross settlement (RTGS) is a gross calculation system (gross—all ordered funds are directed to the receiver by the payment system) in real time where all individual payments are calculated and performed momentarily through calculation accounts of bank sender and bank receiver at the Central bank, as defined by the Bank for International Settlement (BIS) [2]. All payments through the limit given by the Central bank must be performed via this system. Therefore, the Central bank can control the money funds it needs so that the monetary system remains stable. RTGS is mainly, due to the listed reasons, controlled by the Central banks. RTGS system is connected to the payment systems of banks and other financial institutions, including clearing houses [3], agents, processing houses and other institutions set by the law. Clearing house (Clearing House, Automated Clearing House – ACH) is a central location or central processor mechanism that financial institutions agree with regarding exchange of payment instructions or other financial liabilities as defined by BIS. Agent is an entity that holds the owner’s right (acting for and on behalf of). In case of payment operations agent holds rights over owner’s transaction account (acting for and on behalf of) as defined by BIS. Processing house is the provider or operator and organizes hardware and software environment for operation execution of electronic transactions with no financial institutional attributes. These institutions perform execution, processing, acquisition and distribution of information regarding financial transactions. Figure 1 depicts the RTGS payment system of the Central bank and financial institutions along with their users.

Figure 1.

RTGS system of central institution with defined topology of the subordinated ones.

Described RTGS system in every country belongs to the group of “mission critical” systems. These systems must fulfil very high criteria regarding realization, and at the same time, they must provide maximal working comfort, reliability, high availability, scalability, modularity and portability (Table 1).

All elements that must be satisfied by such a system are defined within the Core Principles for Systematically Important Payment Systems by Bank for International Settlement [4].

Starting with the Central bank’s premise, it is defined in accordance with legal regulations set by the Parliament,

Law on National Bank of Serbia.

by laws which are mainly within the Central bank’s jurisdiction

Example: decision on payment operations performance based on direct debit.

and deeds of Central bank payment operations unit which determine documents—message system for financial information exchange and business processes [5], which must be conducted in financial message exchange.

Manual on format and message purpose in payment system operations.

So far, in RTGS systems defining and implementation, there were attempts to have these system problems systematized, as Denmark National bank in book Payment Systems in Denmark [6], by all elements.

Feature Description
Reliability Every system transaction must be performed according to the defined specification. All functionalities which are not described in the specification are not allowed to occur, i.e. it is not allowed to perform any transaction in a way which is not described by defined specification. That is why the system must be designed so that none of the system message is lost.
High availability System, regardless the environmental circumstances (e.g. natural catastrophes or several messages in a time unit) must be available enough, usually 99.997%, meaning that 100% of system must be functional 99.997% of working hours (e.g. in 10,000 working hours, i.e. 417 days, system can be unavailable for 3 h).
Scalability Depending on the needs, system capacity can be multiplied by simple component multiplication.
Modularity New system functionalities are achieved adding new module functionalities not affecting the existing ones.
Portability System components are in such correlation that one or more components can be exchanged not affecting other components, or system, as a component, can be implemented in into another system with no changes in the existing components.

Table 1.

Characteristics which the system must satisfy.


2. Management and payment systems organization

2.1. Management

Systems are managed by feedback information, which enables the system to transfer into another with better condition. Feedback is based on self-regulation, i.e., on the system’s ability to maintain value of certain parameters within the approved limits.

System is managed so that it is driven closer to its optimal condition that its dynamic balance is kept and that it is guided towards the desired results. Figure 2 depicts the way system is managed. Driving force makes system processes produce adequate functioning resulting in the regulator to operate with, intervene appropriately and correct the driving force.

The same regulation manner applies for payments systems and payment subsystems. Taking the Central bank as an example we could see that the system functioning is determined by law regulations, that driving force is money flow power and that system functioning results in stable monetary zone. The regulator is composite and multidisciplinary. Regarding payment system, the most important regulators are those which apply to them only, and one of those is provided in payment system functioning rules: maximal amount of payment operations order which can be realized in the system other than the RTGS system.

The Central bank has prescribed that orders which exceed RSD 200,000.00 must be performed in RTGS. Statistically, there are about 5% of all orders that exceed this value, but it includes about 97% of total money that is daily exchanged among payment system participants. If this amount was lower, RTGS system would be processing much more orders, but the total amount of exchanged money would be slightly changed. In the beginning of 2003 the amount was RSD 60,000.00 so that the quantity of payment orders for RTGS system was critical both for the system and for monetary stability in our country. First, the amount was changed to RSD 120,000 and afterwards to RSD 200,000, which led to the optimal parameter value providing stable functioning results.

Figure 2.

System regulation—management.

Systems subordinated to the central bank system, could also serve as an example of system regulator and they are shown in Figure 1 as a wholesale system. Their subordinate systems are retail

Retail—legal entities and private individuals with their individual payment orders.

systems, which also contain adequate regulators. When payment systems are designed, special attention should be given to natural regulators which belong to the system so that the system could be managed and function keeping its dynamic balance.

The example describes management at the administration level. However, payment systems are managed at various levels, i.e., at adequate subsystems. Subsystems can also be defined by their classification and by their nature. One of the author’s classifications was used for planning and realization of several payments systems and it is shown in Table 2.

Every system element will be consistent, if it has the three following characteristics: qualification, authorization and responsibility. System must be qualified, i.e., it must be able to perform assigned functions. In order that the Central bank system could function consistently, it must be authorized by the state parliament. Several systems can be authorized to perform the same operations, but responsibility for the appropriate results must be assigned in a correct manner so that each system regulator could make the correction.

Figure 1 hierarchically depicts payment system participants, from retail participants in their payment systems, through wholesale participants who have their own payment systems, up to the Central bank payment system. It is a complex system that can be seen from the numerous participants using the system on daily basis, like Serbian described in red book “Payment systems in Serbia” [7].

Classification Description
Hardware All material resources which do not belong to information
technologies, computer structures, active network components,
passive network components, devices that provide needed
environment conditions, required material
Software System software, application software
Personnel Bank technology staff and IT technologists enabling
technical system functioning
Organization Organization of unit performing payment operations and
organization of payment operations unit within the subject responsible
for payment system operations
Data Data on system elements, data on processing, data for processing
Standards Standards determining hardware, software, staff, organization and
data, standards which interrelate system elements

Table 2.

Element classification example of managing system.

2.2. Organization

Regarding system ownership, legal authorities or a certain body in hierarchy organization entitled to prescribe sublegal deeds, acts and regulations, clearly defines ownership hierarchy based on various issues and system elements. The most important is system data ownership and it affects many other system functioning aspects. The leading role in the payment operations ownership hierarchy is played by the Central bank. One of the data ownership chains is represented in Table 3.

Institution Data
Central bank RTGS centre data
Data on processing in banks
Bank Bank payment system data
Data on retail user message processing
Retail users Legal entities: data on payment orders processing
Private individuals: data on payment orders processing

Table 3.

Ownership of one country payment system data.

Listed data groups make a unique whole and they must be kept for a long time (e.g. 10 years), and in case that some data are missing, at any level, or some data (or data set) of the RTGS system elements are seriously damaged, and it is corrected by legal and penalty regulations. Lack of data or its damage can be considered as a serious criminal act of the data owner.


3. Technical standards

3.1. Standard ISO20022

ISO is national standardization institutions network. International standard ISO 20022 was initially created by Technical Committee ISO TC68.

Standard ISO 20022—Universal Financial Industry Message scheme (UNIFI) is an international standard defining the ISO platform for financial standards development. Access, present in the schemes of business modelling, enables users and development team to present financial business models and related transactions formally independent of the regarding syntax. These business transaction models are real business standards. They can be translated into physical message of the desired syntax. At the time when UNIFI started with development, XML (eXtensible Mark-up Language) had already been the leading syntax for e-communication.

Focus UNIFI is the international (cross-border) financial communication language among financial institutions, their clients and domestic or international infrastructure included in financial transactions processing.

That is why a repository was developed, as well as a set of standardized message schemes is located at the ISO site, Standard ISO20022 repository consists of two major parts: data vocabulary and business processes catalogue. Data vocabulary contains business concepts, message concepts and data types. Business process catalogue was organized by business fields. Communication and interaction requirements are in various business areas and they are supported by business transactions.

Standard also include development methodology, registration process and central financial repository organization containing UNIFI messages and their components. UNIFI standard consists of five parts.


If there are no UNIFI messages covering special transactions, new model can be defined along with messages that shall be approved by UNIFI registration body. If there is such a message in the repository, but it does not satisfy all the requirements, new message version can be created by initiative which will adjust them to the requirements, and if it is not possible, new messages shall be created for these requirements.

3.2. Catalogue of UNIFI messages

In order that ISO defined messages become public, all UNIFI messages were published along with all the elements describing them in detail:

  • Document in pdf format describing messages completely;

  • XML scheme of all messages;

  • Business examples, i.e. XML instances of every message;

  • Zip file containing HTML version of UML message model;

  • Zip file containing UML message model which is completely open and can be used with IBM Rational Rose 8.5.0506.2811; and

  • Zip file containing activity diagram (for business flows), diagram sequences (for scenario creation) and class diagrams (for messages); diagrams are available in several formats.

UNIFI message list related to the application domain are Payments, FX, Securities and Trading messages.

3.3. Messages defined by the Europe Payments Council (EPC)

Relying on ISO20022 message standard, in accordance with their needs, the EPC defined appropriate message set and that way the modification for payment systems was created. National Bank of Serbia [8], for example, defined their message set in 2003 based on SWIFT messages reducing usage range, i.e. defining its sub-standard. Sub-standard is defined so that usage of given message set could be limited regarding implementation and easier message flow control. Given set of basic EPC messages is regularly updated. There are also basic messages given containing additional optional services. Additional optional services are the financial organization services which are not mandatory, and can bring profit or attract clients, and financial institutions are obliged, if they introduced them for certain clients, to perform them to their other clients too. This access of system usage determination is enabled due to the advantages provided by modern ICT

ICT—information and communications technology.

technologies. Namely, if IT

IT—information technology.

service was introduced for certain subject, e.g. only administrative bans (but not expenses), usage of the same services can be disabled for other clients, too.


4. Complexity management through recursion

Recursion is already a well-known conception in mathematics and computer science field. ‘In business environment it is rarely used explicitly’, said Bernard Schiemenz [9]. However, recursion can be applied in complex systems: using cases where inner part of the system is hierarchically recursive (special case appearing very often in practice and especially in payments systems domain), using cases where system objects are recursive and using cases where there is a recursive problem which needs to be solved. We have been meeting recursive Russian figures called ‘babushka dolls’, and Figure 3 represents additional examples. ‘Object is called recursive if it contains itself as a part, and if it is defined by some of its parts’, as described by Bernard Schiemenz.

Figure 3.

Recursive structure based on Bernard Schiemenz’s descriptions.

Therefore, system consists not only of elements with attributes and relations among them, but of the fact that it belongs to some other superior system consisting of subordinate systems, too, i.e. for each system some belonging structure can be found. Figure 3 depicts a payment system with recursive structure. System consists not only of elements with attributes and relations connecting them, but it is also the fact that it belongs to a superior system, and that it contains subordinate systems, i.e. that for every system there can be found a belonging structure. Figure 3 depicts a payment system with recursive structure. Recursive structure can be, apart from set relations, represented in several other ways. One of the ways is with inner brackets, so that the structure from Figure 3 can be represented in the following way, too: (G(D, E(A, B, C), F)). It is quite clear that a recursive object can be represented by a recursive structure, too. It can also be reviewed in a table, with columns representing a hierarchy level within the recursive object, and rows representing recursive element names, as shown in Figure 4.

Figure 4.

Table form of recursive structure for financial market in Serbia.

Based on the previous considerations, the following mathematical model of recursive structure was created: payment system of Serbia consists of payment systems at multiple levels. The lowest level is the level on which acquisition and final distribution of information on payment transactions is performed. It is the retail level. The upper level is the bank level, i.e. the wholesale level. Above the bank level is the RTGS National Bank of Serbia level. Above the level of RTGS National bank of Serbia, there are various levels of global payment transactions information exchange.

Payment systems of the same purpose at various levels are equivalent by their functionality. Therefore, we can depict the basic system module in the following way:


Let Fl(k) is a system model at k level. Let the function fl(X) represent a transformation function of several system union which equals X. System transformation reflects an authorization over the data, responsibility and assigned required qualifications conducted through prescription of legal regulations, norms and application of other prescribed standards.

Legal regulation, norms and other legal and technical cathegories treated as standards.

Reflection of fl is such that at higher level differences Rn−1 reflect into a point (reflection neglects Rn−1 at higher level), since these are system functions which are not subject of higher level system.

Let RX represent a system part of higher level than that of system union X, which does not belong to the system union X.

Let us assume that the system can be realized at its lowest level using basic model as shown in Figure 5:

Figure 5.

Graphic description of the lowest level system model.


Based on the previous considerations, level n of the system can be presented in the following way:


Model described by formula (3) can be graphically shown in Figure 6:

Figure 6.

Graphical review of system model at n level.

Example: Let F1(n−1), F2(n−1) and F3(n−1) be three different payment systems of different banks, i.e. systems for credit transfers, direct debit and cheque clearing, respectively. In this case, system Fl(n) shall be a processing house for credit transfers, direct debit and cheque clearing. It shall not have, for example, the liabilities prescribed by the legal regulations Rn−1 in which function fl reflects into a point (i.e. neglects) but it shall have its functions reflected in the difference Rn. When systems F1(n−1), F2(n−1) and F3(n−1) are of the same kind, let us say direct debit, than the formula (3) gets simplified and there is no need for the union since the systems at n − 1 level are equivalent so that it is sufficient to apply the transformation function to any system and add difference Rn so that the system of n level could be made. In this case, the system of n level is equal with any of the systems of n − 1 level.


5. Brief review of most important payment systems factors

Safe and efficient payments systems are the most critical segment in undisturbed financial system functioning. Payments systems, in interbanking funds transfer sense, are the most important payments systems and they are considered to be important payment systems. They are basic, and often the only channel that can transfer faults in domestic and foreign systems and markets. Robust payments systems are essential for keeping and improvement of financial stability. In the last few years, consensus was made among main financial institutions and a set of requirements was developed which payments systems must satisfy, promoting internationally recognized standards and best practice regarding their design, development and production.

There are 50 trillion retail transactions processed today in the Euro zone, which is two to four times more than in cash. This transaction volume is realized by 315 million retail users, 16–18 million small, medium and large companies, 6000–7000 banks and other financial organizations, at 4.6 million POS

POS—point of sale.

terminals and 240,000 ATMs.

ATM—automated teller machine.

The market and processing expenses in banks and other financial organizations are such that there is interest for creation of a new competitive market different from the present one, which is a kind of monopoly. In the European Union (EU) there are tendencies of introducing unique payment zone where legal entities and private individuals could perform their transactions equally as in their present national zones, and therefore under the same conditions, with the same rights and liabilities. European Union now consists of 27 member countries and four joined countries: Ireland, Norway, Lichtenstein and Switzerland, but the priority is introducing into 13 present EU countries. This represents chance for participation in technical and technological resources in development of unique European payment zone.

Great global institutions for message standardization accepted XML standard as a base for further standard development. Standard XML enables them to present their standards in an acceptable way and make them available to a wide range of experts of adequate message processing fields. Standard XML represents a basis for development of convergent tables for various standards and therefore to make messages of one standard available to the systems functioning in accordance with other standards. Convergent tables contain elements which are mutual and those that are different in both standards in relation with another one. UNIFI (ISO20022) message standard contains elements of all relevant standards and therefore plays a key role in conversion of other standards towards a unique, generally acceptable one.

Standard XML and appropriate tools nowadays represent powerful tools in every software life cycle, from the payment systems analysis up to their production. Tools, based on XML ‘materials’, included in standards (XML structures can be taken over from every considerably important institution for standardization site), can also produce appropriate basic system elements. XML structures made the implementation of payment systems more reliable, easy to monitor and control, which can be reflected in the final function reliability and efficiency of payment systems.


6. Solution solving methodology

In early chapters, description method was used to determine different types of payments systems, considering the payment instrument upon which the payment system is based. Using deduction method over economical-financial systems, theories and reckonings which apply to payment systems (starting with the payment and payment system definition) as well as theories dealing with research task solving applying researching techniques, a conclusion was made that starting from general theoretical model individual payment system solutions could be produced, such as credit transfer or direct debit. The same deductive method led us to the conclusion that every individual system, regardless of its level, can be solved in the same way.

The developed models represent verification of the predictions that were reached using comparative methods when analysing structural and functional characteristics of various phenomena, processes and payment system structures. Facts collected this way represent basis for new theory set up in the field of economic financial sphere applying to payment system problems, and even more important, the collected facts become subject of system management theories and sciences dealing with theoretical aspects of information technology application.

6.1. Analysis of credit transfers systems

The aim of this analysis is to describe a business model of one payment system type over which a generalization could be performed and to notice business processes or payment system functions which according to their nature differ one from another payment system type. The noticed differences among the payment systems can be grouped in a module so that general purpose structure is created or individually defined if special purpose payment system is to be composed.

6.1.1. Decomposition of credit transfers systems

Credit transfers system is distributed at three levels, as it has already been emphasized in the analysis of the EPC model for credit transfer shown in Figure 7. First level is retail user level, process 1.1 in Figure 7, and it is connected with initiation processes of credit transfer, and with banks where a system in charge of processes related with retail users is located. The second part of the process is located in Chapter 2, labelled as 2.1, and it deals with processes oriented towards superior institutions for processing. Now the gap between the two systems located in the bank is visible: the part oriented towards subordinated retail part of the system and the part towards superior part of the payment system, i.e. superior institutions. Gap is reflected in the fact that the system part towards subordinated institutions is obliged to perform as many as possible transactions, to be user friendly, to be helpful to users in disputable situations and to be user oriented concerning marketing so that as many as possible transactions that can be collected by the bank are performed. While the system oriented towards superior institution is in such a situation that it only performs the most necessary part of transactions, finds disputable transactions and returns them for additional auditing due to the expense risk which could result from wrong transaction, to be pessimistically oriented towards superior institution calculating every transaction, and to tries to optimize transactions grouping them, waiting and collecting as many as possible transactions before the realization. Part of the system in the bank oriented towards superior institution even tries to postpone the realization, to perform it in the last minute, since that way minimal funds are placed out from the bank, which means more funds remain in the bank. The same paradigm can be applied for processes 2.3 and 3.1 in a processing house, e.g. Automated Clearing House. The above-mentioned processes and their basic position in payments system are shown in Figure 8. Reporting processes are connected with legally regulated reports as well as the view the system owner finds necessary when the system is used.

Figure 7.

Credit transfers context diagram (CTCD), top two levels.

Figure 8.

CTCD—retail system.

Retail system 1.1 is depicted in Figure 8. Process 1.1.1 payment preparation can also be performed manually, which is usually done for private individuals and smaller legal entities, while for other legal entities it is not performed manually, and the processes can be supported by many equivalent products available in the market. They are equivalent since in relation with the given transaction set, the result must be the same payment messages set. Process 1.1.2 payment realization consists of standard procedural processes, such as verification of payment information, payment message preparation, interaction with payment system, message comparing with its response and payment verification which are also equivalent in relation with message system because their input and output must be equal. Process input must be the same since the final result is a standard message containing correctly determined information, and output is the same message which regardless of the type of its components must be the same. The phenomenology, in the Mihajlo Petrovic’s work [10] sense, of process 1.1.1 is interesting because it has analogue object with the RTGS system as well as later in processes 1.2.2, 2.2.3, and 3.1.3, which can be the subject of a later research.

Process 1.2 bank’s retail credit transfer system starts with control of initial system parameters set by superior institution which can consist of variable system parameters in relation with the current situation in the whole system. This way the desired feedback is achieved within the system, i.e. management function of the superior institution as described in chapter 1.1.1. If there was not this automated process, a subordinate institution would not be able to avoid their liabilities regulated by legal or sublegal deeds and it could jeopardize its existence. By comparing Figures 9 and 10, we can see that certain processes are repeated and that they are completely the same in their functionality.

Figure 9.

CTCD—bank’s retail credit transfer system.

Figure 10.

CTCD—bank’s processor credit transfer system.

By comparing Figures 1013, we can also notice that some processes are repeated and that they are completely the same in their functionality.

Figure 11.

CTCD—processor’s net system.

Figure 12.

CTCD—processor’s gross system.

Figure 13.

Generalization of the first two levels.

6.1.2. Generalization of first two levels

Based on analyses described in the previous chapter and considering the fact that for every transaction, regardless of its type, there is initiation, clearing and settlement, so that a generalization can be made by the type of transactions that are processed, i.e. by payment instrument which is being used, as it is shown in Figure 13. Therefore, regardless of the payment instrument that is used (credit transfer, direct debit, cards) process steps and their relation would be the same. In the following analyses of diagram showing data flow there is generalization by process depth that can be noticed.


7. Usage of software tools in application of standards

Global institutions for standardization set standards and make them available to the whole community, Figure 14. Lately, we can notice other organizations’ initiative to adjust their products and to enable the usage of material which standardization institutions made available and free of charge.

Figure 14.

camt.008.002.01.xsd scheme on ISO20022 site with instance.

The following text provides description of one of the ways for using standardization elements in system element creation using tools that are available in the market or as open source. This shall be shown on a general example containing all necessary elements so that we can make the conclusion that it is also possible for other cases.

Let us start from the basic material—XSD scheme which is on ISO20022 site [11]. In this example we shall use the scheme RequestToCancelPayment (camt.008.002.01.xsd) with its appropriate instance, as it is shown in Figure 14. The structure of the scheme is shown in tool Altova XMLSpy in Figure 15.

Figure 15.

Structure of payment cancellation request XSD scheme.

Alexis Smirnov showed how objects and data relation structure can be unified using the XDS scheme as a basis for object relation mapping [12], i.e. a way to create data base structure using XSD file. Figure 16 depicts the tool XSD2DB used by Alexis Smirnov and author group (the object as well as the source code could be found on the Internet) applied to the RequestToCancelPayment scheme.

Figure 16.

Database model creation using tool with XSD scheme.

Schemes are taken over from ISO20022 organization normalized XML documents, as described in Lazarevic’s book [13], so that there are two solutions in tool usage: (1) to normalize XML documents and then create conceptual database model or (2) to create database from the existing XSD scheme and afterwards normalize the database scheme. Figure 16 shows where the tools can be taken over, tool abilities, the structure material of database and the way database structure was created.

Database model, shown in Figure 17, is not normalized and corrections and normalization are necessary so that model of satisfactory characteristics could be obtained. By comparing the XSD scheme structure in Figure 15 and the database model in Figure 17, we can also compare the structures.

If there is a XSD scheme, and an appropriate database structure, it is possible, using the tools, to achieve the application structure for input, editing and deletion in the appropriate instance database. For that purpose tools Altova MapForce can be used where XSD structures are mapped into the database structure, Figure 18.

Figure 17.

Database model created with XSD2DB tools.

Figure 18.

Mapping of the XSD scheme and database scheme.

Mapping of camt.008.002.01.xsd structure into the database structure from Figure 19 is shown in Figure 20. The mapped structures can be used for the generation of appropriate application structure in several program languages, as shown in Figure 21, for generation of source code in C# program language. When generation take place the information on instance from ISO20022 site, camt.008.002.01.xml, containing test data, was used.

Figure 19.

Selection of program language for database access code generation.

Figure 20.

Successfully generated application structure.

Figure 21.

Successful updating of database by camt.008.002.01.xml instance.

Starting console application databases are updated and Figure 21 shows successful input of camt.008.002.01.xml instance into the database structure.

Source code of a test console application generated with tools Altova MapForce is as follows:

using System;

using System.Collections;

using System.Data;

using Altova.Types;

using Altova.Functions;

namespace Mapping


public class MappingConsole


public static void Main(string[] args)


Console.Out.WriteLine(“Mapping Application”);



TraceTargetConsole ttc = new TraceTargetConsole();

MappingMapToUniversalDB MappingMapToUniversalDBObject = new MappingMapToUniversalDB();



“C:/Documents and Settings/Slobodan/Desktop/xsd2db/xsd2db/bin/Release/camt.008.002.01.xml”,

“Provider=SQLOLEDB.1; Data Source=SOLARIS; Initial Catalog=UniversalDB;Integrated Security=SSPI;Persist Security Info=False;”);



catch (Altova.UserException ue)


Console.Out.Write(“USER EXCEPTION: “);

Console.Out.WriteLine( ue.Message );



catch (Exception e)


Console.Out.Write(“ERROR: “);

Console.Out.WriteLine( e.Message );

Console.Out.WriteLine( e.StackTrace );





class TraceTargetConsole: Altova.TraceTarget {

public void WriteTrace(string info) {





In generated testing console application there is a code which can be used in any application system for work with database over which it was constructed. The same can be applied for all other schemes given on ISO20022 site as well as for other XSD structures.

This example shows that the elements with satisfactory characteristics can be obtained if XSD structures are used with given standards applied. All received payments systems elements described exist in many versions, with special market characteristics. Obtained elements represent good foundation for project development but also for development of new characteristic tools which could even more automate the development of payments systems application elements.


8. Realization

A short description of possible payment system realization is provided in the task defined in Section 8.1 and in the task solution in Section 8.2.

8.1. Task

Basic task can be formulated as follows:

Specify and develop a payment system for X at level Y.

8.2. Solution

The standard system for message transfer can solve the problem of distributed systems concatenation. The problem that should be solved for implementing the system is shown in Figure 22. Therefore, there is a system class isolated which needs a solution.

Figure 22.

Successfully isolated problem class which should be realized.

8.2.1. System specification for X

(a) Separator

Its function is to separate the messages observing whether the message is allowed, to which processing it is directed, to what kind of system, etc., Figure 23.

Figure 23.

General specification of system subunits.

(b) Loader

Its function is to connect system subunits considering the subunit’s place within the system, structure of the required input-output data and their necessary adaptation, Figure 23.

(c) Processor

Performs basic system processing, in addition, up to the extractor specification, the separated processes are listed at their Y levels, Figure 23:

  1. Retail level

    1. 1.1. User’s level

    2. 1.2. Bank’s level

  2. Net level

    1. 2.1. Bank level

    2. 2.2. Processing house level

  3. Gross level

(d) Extractor

Its function is to connect system subunits regarding the subunit’s place within the system, structure of required input-output data and their necessary adaptation. The difference between extractor and loader is the subunit adaptation direction. At this abstraction level they cannot be exchanged with adapters since the adapters would be more complex than the whole system due to the solving of potential danger caused by semantic connection of input and output and perpetual mobile paradigm (therefore, if such an adapter was to be connected with itself it would have to perform the adaptation of itself to itself), Figure 23.

(e) Integrator

Its function is to unify, in a given manner, set of messages for transport level, Figure 23.


9. Conclusion

The described methodology for payment and other system determination and development was realized like pilot project in the National Bank of Serbia and Association of Serbian Banks [14]. In domain of payment messages generation, transport and receipt, as well as of processing of consisting financial transactions, system was prepared for development or test environment.

In this paper, there are also information technologies for which it is expected to improve their development processes in payments systems domains as follows: (a) uniformed application in domain model for distributed functionalities, (b) domain of the state-of-the-art analytical payment systems application, (c) state-of-the-art technologies implementation, (d) implementation of financial industry IT standards, (e) in financial message transport processes and (f) in IT improvement of financial messages processing.

The paper is dedicated, before all, to the professionals in the field of systems, especially systems based on standard messages, system optimization, modern financial systems and innovations in financial field, then to the financial institutions management, management of ICT companies, business analysts in financial institutions, system analysts and project leaders, as well as all others who think about the paradigm called systems based on business messages.


  1. 1. National Bank of Serbia, Elements on the payment transactions instruments contents and filling, 2002, Available from: http://www.nbs.yu/export/internet/english/20/plp/form_contents_instruments_elements.pdf [Accessed: 2016.10.06].
  2. 2. Committee on Payment and Settlement Systems, A glossary of terms used in payments and settlement systems, Bank for International Settlements, 2003, ISBN 92-9197-133-2.
  3. 3. Babić S., Anđelković Z., Lekić N., The Clearinghouse—A Pattern for Supply Chain Information Exchange. Actual Problems of Economics, 2013. 6(C), pp. 171–181, ISSN 1993-6788.
  4. 4. Committee on Payment and Settlement Systems, Core Principles for Systematically Important Payment Systems, Bank for International Settlements, 2001, ISBN 92-9131-610-5.
  5. 5. Babić S., Anđelković Z., Barać D., Bogdanović Z., Despotović-Zrakić M., Model of Interoperable e-Business of Payment Systems Based on Ontologies. Metalurgia International, 2013.2, pp. 150–155, ISSN: 1582-2214.
  6. 6. Denmark National Bank, Payment Systems in Denmark, 2005, ISBN 87-87251-50-7, ISBN 87-87251-51-5.
  7. 7. Committee on Payment and Settlement Systems, Payment systems in Serbia, Bank for International Settlements, 2007, ISBN 92-9197-742-X.
  8. 8. National Assembly of the Republic of Serbia, Law on National Bank of Serbia, [Internet], 2003, Available from: [Accessed: 2016.10.06].
  9. 9. Management and Organizational Change, A Symposium at the European Meeting on Cybernetics and Systems Research, [Internet], 2002, Available from: [Accessed: 2016.10.06].
  10. 10. Petrović M., Mathematical Phenomenology, Collection, Book 6, BIGZ, 1998, ISBN 86-17-06414-5.
  11. 11. Babić S., Payment system developing based on ISO20022 XML standard according Single Euro Payment Area, Magister Thesis, The Technical Faculty in Bor, University of Belgrade, Serbia, 2008.
  12. 12. Alexis Smirnov, XSD2DB [Internet], 2005, Available from: [Accessed: 2016.10.06].
  13. 13. Lazarević B. and a group authors, Data bases, Belgrade University, Faculty of Organizational Sciences, Belgrade, 2003, ISBN 86-80239-96-8.
  14. 14. National Bank of Serbia, Decision on payment operations performing based on direct debit, 2007, "Official Gazette RS," No 31/2007.


  • Law on National Bank of Serbia.
  • Example: decision on payment operations performance based on direct debit.
  • Manual on format and message purpose in payment system operations.
  • Retail—legal entities and private individuals with their individual payment orders.
  • See
  • ICT—information and communications technology.
  • IT—information technology.
  • Legal regulation, norms and other legal and technical cathegories treated as standards.
  • POS—point of sale.
  • ATM—automated teller machine.

Written By

Slobodan Nikola Babić

Submitted: April 17th, 2016 Reviewed: October 10th, 2016 Published: January 18th, 2017