HELSINKI UNIVERSITY OF TECHNOLOGY Department of Electrical and Communications Engineering Laboratory of Telecommunications Software and Multimedia

Eeva-Liisa Vuolle

File Transfer Services for Corporate Banking Customers

Thesis submitted in partial fulfillment of the requirements for the degree of Master of Science in Technology Espoo, April 5th 2004

Supervisor:

Professor Teemupekka Virtanen

Instructor:

M. Sc. Tuomas Kivinen

HELSINKI UNIVERSITY OF TECHNOLOGY Author:

ABSTRACT OF THE MASTER’S THESIS

Eeva-Liisa Vuolle

Title of the thesis: File Transfer Services for Corporate Banking Customers Date:

April 5th 2004

Number of pages: 68+12

Department:

Professorship:

Department of Electrical and Communications Engineering

T-110 Telecommunications Software

Supervisor: Professor Teemupekka Virtanen Instructor: M. Sc. Tuomas Kivinen Medium sized and large companies often have hundreds of bank accounts. They may perform great number of transaction to and from these accounts on a daily basis as a part of their banking activities. File transfer services offer a meaningful way to deliver a large amount of payment instructions and other financial commissions to the bank in a file format. File transfer system consist of components and subsystems that together receive incoming files, perform authentication, integrity checks, decryption and possibly other tasks on the files before the files are forwarded to payment applications in the bank’s production environment. Nordea Bank has gone through many mergers and acquisitions in the past. This has resulted in large variety and complexity in technologies and platforms on which the file transfer services are run. Furthermore there is a growing need for integration and consolidation of systems and services. This thesis makes a survey to the versatile set of file transfer services, which the Nordea Bank offers today to its corporate customers. We concentrate on describing the technical architectures of these systems and the major differences and similarities between the many solutions. The study conducted in this thesis shows that although the file transfer services and their technical implementations vary largely, some common denominators, such as use of symmetric cryptography, exist. We also surveyed future development trends. XML and Web Services technologies could be utilized to automate for example management of cryptographic keys and to help standardize the diverse customers’ computer environments. Keywords:

Corporate banking customers, file transfer, data communication

i

TEKNILLINEN KORKEAKOULU

DIPLOMITYÖN TIIVISTELMÄ

Tekijä:

Eeva-Liisa Vuolle

Työn nimi:

Pankin yritysasiakkaiden eräsiirtopalvelut

Päivämäärä:

5. huhtikuuta 2004

Sivumäärä: 68+12

Osasto:

Professuuri:

Sähkö- ja tietoliikennetekniikan osasto

T-110 Tietoliikenneohjelmistot

Työn valvoja: Professori Teemupekka Virtanen Työn ohjaaja: DI Tuomas Kivinen Pankin suurikokoisilla yritysasiakkailla on usein satoja pankkitilejä ja monimutkaisia konsernitilirakenteita. Nämä asiakkaat saattavat tehdä satoja maksuja, tilisiirtoja ja muita toimeksiantoja päivittäin. Eräsiirtopalvelut tarjoavat mahdollisuuden lähettää pankkiin useita toimeksiantoja kerrallaan tiedostomuodossa. Eräsiirtojärjestelmä koostuu niistä osista ja alijärjestelmistä, jotka yhdessä vastaanottavat asiakkaan tiedostot ja suorittavat niille tarpeelliset tarkistukset ennen kuin tiedostot siirtyvän edelleen ajatettaviksi maksuliikesovelluksissa. Nordea Pankki on läpikäynyt historiansa aikana useita fuusioita ja yritysostoja. Tästä johtuen pankin eräsiirtojärjestelmät ovat monimutkaisia ja suuria. Tämä diplomityö keskittyy olemassa olevia eräsiirtojärjestelmiä tietoliikenteen näkökulmasta ja löytämään järjestelmien väliltä merkittävimpiä samankaltaisuuksia ja eroja. Tehty tutkimus osoittaa, että vaikka nykyiset eräsiirtojärjestelmät ovat hyvin kirjavia, niiden väliltä voidaan löytää tiettyjä yhtäläisyyksiä. Esimerkkinä mainittakoon symmetristen salaustekniikoiden käyttö asiakkaan tunnistamisessa ja tiedostojen eheyden varmistamisessa. Työssä tutkittiin myös tulevaisuuden kehityssuuntauksia. XML teknologioita voitaisiin hyödyntää tarvittavan avaintenhallinnan automatisoinnissa ja asiakkaiden tietokoneympäristöjen yhdenmukaistamisessa. Avainsanat:

Eräsiirto, tietoliikenne, yritysasiakkaat

ii

Foreword This thesis has been done for Nordea Bank Finland Plc. I am grateful for that they gave me this opportunity and especially for the support they showed so that I could finish my work in spite of all. I want to thank my supervisor Professor Teemupekka Virtanen for his feedback and flexibility. My instructor Tuomas Kivinen deserves a lapful of thanks for his support and for his comments regarding the contents as well as the structure of the thesis. I also want to thank my colleagues Merja Otamo and Tomi Suomela. Merja gave me so many valuable comments and answered my questions patiently. Tomi assisted me with myriad of practical and technical issues. Everybody at Nordea Bank who helped me with this work, although not mentioned here, deserves my thanks as well. I address my last thanks to my manager Auli Salmi. She gave me the chance and time to write this thesis and believed in me from the very beginning to the end.

In Espoo, April 5th 2004

Eeva-Liisa Vuolle

iii

Table of Contents

FOREWORD ....................................................................................................................... III TABLE OF CONTENTS .................................................................................................... IV LIST OF FIGURES ............................................................................................................. VI LIST OF TABLES ..............................................................................................................VII ABBREVIATIONS ........................................................................................................... VIII 1

INTRODUCTION.........................................................................................................1 1.1 1.2 1.3

2

REQUIREMENTS FOR DATA COMMUNICATION IN BANKING ..................4 2.1 2.2 2.2.1 2.2.2 2.2.3 2.2.4 2.3 2.3.1 2.3.2 2.4 2.4.1 2.4.2 2.4.3 2.5 2.5.1 2.5.2

3

SCOPE AND OBJECTIVES .........................................................................................1 RESEARCH METHOD ...............................................................................................2 STRUCTURE OF THE THESIS ....................................................................................2

INTRODUCTION.......................................................................................................4 REQUIREMENTS FOR THE BANK .............................................................................5 Audit Trail.........................................................................................................5 Authentication...................................................................................................5 Customer Authorization ...................................................................................6 Event Logging...................................................................................................7 REQUIREMENTS FOR THE CUSTOMER’S ENVIRONMENT ........................................8 Physical Security ..............................................................................................8 Standard File and Message Formats ...............................................................8 DATA COMMUNICATION REQUIREMENTS ...............................................................9 Confidentiality ..................................................................................................9 Information Integrity ......................................................................................10 Availability...................................................................................................... 11 REFERENCE MODEL .............................................................................................12 Considerations................................................................................................12 System Evaluation Criteria ............................................................................14

PAYMENT SYSTEMS ...............................................................................................16 3.1 DENMARK ............................................................................................................16 3.1.1 Danish Electronic Banking Systems ..............................................................16 3.1.2 File Transfer Communications.......................................................................18 3.1.3 File Transfer Architecture ..............................................................................18 3.2 FINLAND ...............................................................................................................19 3.2.1 Finnish Electronic Banking Systems..............................................................20 3.2.2 File Transfer Communications.......................................................................21 3.2.3 WWW file transfer ..........................................................................................21 3.2.4 File Transfer Architecture ..............................................................................22 3.3 NORWAY ...............................................................................................................24 3.3.1 Norwegian Electronic Banking Systems ........................................................24 3.3.2 File Transfer Communications.......................................................................25 3.3.3 File Transfer Architecture ..............................................................................25

iv

3.4 SWEDEN ...............................................................................................................27 3.4.1 Swedish Electronic Payment Systems ............................................................28 3.4.2 File Transfer Communications.......................................................................28 3.4.3 File Transfer Architecture ..............................................................................29 4

FILE FORMATS AND SECURITY IMPLEMENTATIONS................................32 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.9.1 4.9.2 4.9.3 4.9.4

5

INTRODUCTION.....................................................................................................32 EDIFACT FORMAT...............................................................................................32 BILL PAYMENT FILES............................................................................................33 RECURRING PAYMENTS FILES ..............................................................................34 PAYMENT TERMINAL TRANSACTIONS ..................................................................35 TELEPAY ...............................................................................................................36 IN-PAYMENT FILES ...............................................................................................37 INVOICE PAYMENT FILES......................................................................................38 SECURITY .............................................................................................................39 Denmark .........................................................................................................39 Finland............................................................................................................40 Norway............................................................................................................43 Sweden ............................................................................................................43

ANALYSIS OF THE FILE TRANSFER SYSTEMS..............................................44 5.1 BANK’S SYSTEMS.................................................................................................44 5.1.1 Denmark .........................................................................................................44 5.1.2 Finland............................................................................................................45 5.1.3 Norway............................................................................................................46 5.1.4 Sweden ............................................................................................................46 5.1.5 Summary .........................................................................................................46 5.2 DATA COMMUNICATION .......................................................................................49 5.2.1 Denmark .........................................................................................................49 5.2.2 Finland............................................................................................................50 5.2.3 Norway............................................................................................................50 5.2.4 Sweden ............................................................................................................50 5.2.5 Summary .........................................................................................................51 5.3 CUSTOMER’S ENVIRONMENT ...............................................................................53

6

FUTURE TRENDS .....................................................................................................54 6.1 INTRODUCTION.....................................................................................................54 6.2 TECHNOLOGIES ....................................................................................................55 6.2.1 XML ................................................................................................................55 6.2.2 Web Services ...................................................................................................56 6.2.3 Applications ....................................................................................................56 6.3 INTEGRATION VERSUS CONSOLIDATION ...............................................................57

7

CONCLUSIONS .........................................................................................................58

REFERENCES......................................................................................................................60 APPENDIX A ........................................................................................................................65

v

List of Figures Figure 1: Requirements model................................................................................... 4 Figure 2: ISO general model for authentication mechanisms............................... 6 Figure 3: Symmetric cryptography. ......................................................................... 10 Figure 4: Public key cryptography. .......................................................................... 10 Figure 5: Electronic banking systems offered by Nordea Bank Denmark. ...... 17 Figure 6: Danish file transfer system architecture. ............................................... 19 Figure 7: Finnish file transfer architecture............................................................. 22 Figure 8: Norwegian file transfer system architecture.......................................... 27 Figure 9: Swedish file transfer system (Fantom) architecture. ............................ 30 Figure 10: One pass unilateral authentication using symmetric techniques...... 65 Figure 11: Two pass mutual authentication using symmetric techniques.......... 66 Figure 12: One pass unilateral authentication using asymmetric techniques.... 67 Figure 13: Two pass mutual authentication using asymmetric techniques........ 67

vi

List of Tables Table 1: Considerations for future improvements................................................ 14 Table 2: Summary of evaluation criteria for data communication..................... 15 Table 3: Summary of evaluation criteria for the bank’s systems ........................ 15 Table 4: Main components of the Finnish file transfer system.......................... 24 Table 5: Summary of authentication components. .............................................. 47 Table 6: Summary of customer authorization. ..................................................... 48 Table 7: Summary of audit trail............................................................................... 48 Table 8: Summary of event logging components................................................. 49 Table 9: Summary of availability components. ..................................................... 51 Table 10: Summary of confidentiality components. ............................................ 51 Table 11: Summary of information integrity components. ................................ 52

vii

Abbreviations AUTACK

Secure Authentication & Acknowledgement Message. A message for authentication and acknowledgement of an EDIFACT interchange, specified by United Nations Finance Group.

BBS

Bankenes BetalningsSenter. A Norwegian national clearinghouse between the Bank of Norway and the operating banks.

BS 7799

A standard for Information Security Management Systems.

BSI

British Standards Institute. An organization promoting national standardization and global management systems located in Great Britain.

BSK

Bankenes Standardiserings Kontor. A Norwegian inter-bank standardization body.

Corporate EDI GW

Corporate EDI Gateway. A host-to-host program for file transfer using EDIFACT interchanges.

DES

Data Encryption Standard. A symmetric-key encryption algorithm standardized by ANSI.

Digipass

A physical token used for user authentication in Nordea Bank Norway.

EBS

Electronic Banking System. A file transfer program that allows modification of single payments inside a file.

ECM

Electronic Cash Management System. A part of the production environment in Nordea Denmark consisting of numerous subsystems.

EDI

Electronic Data Interchange. A standard format for business data exchange developed by ANSI.

EDIFACT

Electronic Data Interchange For Administration, Commerce and Transport.

viii

ERP

Enterprise Resource Planning. A system for managing tasks such as accounting and purchasing in enterprises.

Fantom

The production environment of the file transfer system in Nordea Bank Sweden.

Giroprotector

An implementation of ISO 8730-2 message authentication code algorithm by Nordea Bank Sweden.

HTTP

HyperText Transfer Protocol. An application protocol that constitutes the set of rules for transferring text, graphics, sound and other multimedia over the internet.

HTTPS

Hypertext Transfer Protocol over Secure Sockets Layer. Usage of Secure Sockets Layer protocol as a sub-layer under HTTP.

Interpay

A part of the production environment of the file transfer system in Nordea Bank Norway.

ISO

International Organization for Standardization. A worldwide federation of national standardization bodies.

K-Link

Client program for file transfer offered by Nordea Bank Norway.

LAN

Local Area Network. A set of computers and possibly other devices that share common communications link.

LM02

Finnish standard for payment file format.

MAC

Message Authentication Code. A key-dependent one-way hash function.

MD5

Message Digest 5. An algorithm for hash value calculation.

NIST

National Institute of Standards and Technology. A non-regulatory federal agency of United States Department of Commerce.

ix

OTC

One Time Code. A single-time identification number.

PATU

Finnish standard for authentication, integrity protection and key management procedures between customer and bank.

PAYMUL

Multiple Payment Order. An EDIFACT message format for multiple payment orders.

PIN

Personal Identification Number. An identification number, which is often used with a physical token.

PKI

Public Key Infrastructure. A framework for managing keys needed in public key cryptography.

RSA

Rivest-Shamir-Adleman. A public-key encryption and authentica1tion algorithm developed by Ron Rivest, Adi Shamir and Leonard Adleman.

SäkData

A proprietary MAC implementation used in Nordea Bank Sweden.

SGML

Standard Generalized Markup Language. language for defining markup languages.

SHA-1.

Revision of the Secure Hash Algorithm. A cryptographic message digest algorithm developed by NIST.

SOAP

Simple Object Access Protocol. A protocol based on XML for exchanging information in distributed environment.

SSL

Secure Sockets Layer. A protocol for encrypting and authenticating connections over the internet.

SWEDIFinans

Co-operation organization for financial EDI of established banks in Sweden.

SWIFT

Society for Worldwide Interbank Financial Telecommunication. A global organization promoting standardization and interoperability

TCP/IP

Transmission Control Protocol / Internet Protocol. A protocol suite on which the internet is based on.

x

A

TTP

Trusted Third Party. A trustworthy organization on which other parties decide to trust in security services, such as in authentication.

UDDI

Universal Description, Discovery and Integration of Web Services. Directory service for Web Services.

Unitel EDI

A host-to-host file transfer program for mainframe computers offered by Nordea Bank Denmark.

Unitel PC

A PC-based file transfer client program offered by Nordea Bank Denmark.

VAN

Value Added Network. A network where pricing is based on the amount of transferred data.

VPN

Virtual Private Network. A private network over public internet, which maintains privacy by the use of tunneling protocols.

W3C

World Wide Web Consortium An industry consortium promoting standardization and evolution of the World Wide Web.

Web Services

A set of standards based on XML for web based application-to-application communication.

WSDL

Web Services Description Language. A standard based on XML describing how to connect to a Web Service and how to use the offered services.

X.25

Packet switched data network protocol for exchange of data and control information standardized by International Telecommunication Union.

X.400

Standard for sending reliable mail messages and binary attachments.

XML

eXtensible Markup Language. A text format language based on SGML

xi

1

Introduction

Nordea Bank is formed of four former Nordic banks: the Danish Unitel, Finnish Merita Bank, the Norwegian Kristiania Bank and the Swedish Nordbanken. These companies have had different background and culture as well as technologies, ground systems and platforms on which the varying banking services were, and still are, implemented. In the ongoing integration processes the services provided in different countries will be unified and the underlying technologies and platforms will be integrated to some extent in the near future. Corporate customers can deliver and retrieve for example payment information encompassed in files into the bank via file transfer systems. The customers create the file material in their local systems and then transfer it to the bank either directly or via centralised clearing houses. Bank’s file transfer systems then receive the transfer requests and physical files from the customer side, check integrity and validity of the received material and then forward them to the actual payment service applications that process the files. This thesis investigates the file transfer services provided by Nordea Bank in the four Nordic countries: Finland, Sweden, Denmark and Norway. Describing and understanding the existing solutions is essential before they can be integrated meaningfully and efficiently.

1.1 Scope and objectives The objectives of this thesis are to describe the existing file transfer services together with their technical implementations and to find out the main differences and similarities between the country specific solutions. Beside the analysis of the present situation the thesis makes a survey to the future trends. In this part we will concentrate on the opportunities of XML and Web Services technologies and especially evaluate the support they offer for the automation of customers’ processes. The integration of the current netbank file transfer functionality to the next generation, shared Nordic file transfer solution will also be dealt with. The objectives are listed as follows. • Map out the existing file transfer services within Nordea Bank in Finland, Denmark, Norway and Sweden. • Describe the technical implementation of these file transfer architectures. • Find and analyse the main similarities and differences of the country specific file transfer solutions.

1

• Survey the future technologies that could be used in file transfer services and address the question of integration of the current file transfer solutions. There are over 1500 different file formats within Nordea. This thesis covers only a certain sample of file formats. We have taken examples of those file types having largest volumes measured in transaction amounts and/or cash flow from each country. Generally the interfaces of file transfer services are the same for all the customers but there exists a few customer specific adjustments for the largest companies. These special cases are not included in the scope of this thesis, because they are not significant in contrast to the Nordic general view. To keep the scope reasonable in size, technical study and analysis are limited to the traffic from customer side to the bank. The traffic from the bank to the customer is omitted except when necessary for understanding and clarity.

1.2 Research method The research presented in this thesis is based on throughout literature study and an analysis conducted from the study results. The existing file transfer systems within Nordea Bank are highly versatile when compared to each other. Moreover, even individual solutions are composed of numerous components and subsystems. The written technical documentation has scattered over the years and forming a holistic view of the current situation is found difficult. At first stage, the thesis collects information from many sources both inside and outside the bank’s organisation. Then based on the collected material, the thesis describes the system architectures and forms a general overview of file transfer systems in each of the four countries. The theory part of the thesis presents legislative imperatives to which banks’ services must conform to. We walk through the technical and security standards which can be implemented to achieve the legislative and regulatory conformance. In the end of the theory part we formulate a criterion to compare the systems from communications point of view. Once the criteria have been created then the systems are evaluated against it. This way we are able to find the major differences and similarities between the systems under investigation.

1.3 Structure of the thesis In chapter 2 we present a model for requirements of a file transfer system. Chapter 2 also brings up some considerations that should be taken into account when planning improvements to a file transfer system.

2

Chapter 3 depicts the file transfer architectures country by country and introduces briefly the prevalent file transfer products Nordea Bank offers to its customers. Chapter 4 describes in detail a sample of file formats. At least one sample for each country is included. In the end of chapter the authentication, integrity protection and confidentiality solutions of ach file transfer architecture are discussed. Chapter 5 provides an analysis of the file transfer systems studied in chapters 3 and 4. It evaluates the systems against the criteria presented in the end of chapter 2. Chapter 6 makes a survey to future technologies and short-term trends. Web Services and XML technologies are covered. The question of integration and consolidation of file transfer services is discussed here. In chapter 7 we draw conclusions about the research and about how well the research goals were achieved.

3

2

Requirements for Data Communication in Banking

2.1 Introduction The file transfer can be seen as a process that involves three components. Two of them, the customer and the bank, exchange information with the help of the third one, communications. Usually neither the bank nor the customer has necessary facilities or infrastructure to establish the connection between each other, the communications component includes for example network operators and Internet Service Providers (ISPs). These so called their parties might also be service centres, if the customer has outsourced its financial operations. The data communications is thought to take place between a client and server, between the customer and the bank. The analysis of data communications is performed independent of the network operator. In other words, the thesis does not deal with services offered by network operators, but with services offered by the bank or by the customer.

Network operators Service centres

Customer’s environment

Communications Bank’s Systems

•Physical security

•Availability

•Audit trail

•Standard file and message formats

•Confidentiality

•Authentication

•Information integrity

•Customer authorization

•Access control •Event logging

Figure 1: Requirements model.

4

2.2 Requirements for the Bank The banks must conform to numerous regulations originating from legislation, other national governance or simply enforced by customers’ needs. The following requirements of audit trail, customer authorization and event logging are the most important ones that the banks must satisfy in order to be able to perform its tasks in the information society and electronic financial environment. 2.2.1 Audit Trail The chain of transaction inputs, outputs and receipts must be unbreakable. It must be possible to reconstruct afterwards all processing stages and states of a single transaction. According to Finnish and Swedish Accounting Acts, the bank must take care of maintaining this chain of activities, i.e. audit trail, in order to provide necessary information in case of error or failure recovery, customer request or an account audit (Syrjänen 2001). The International Organization for Standardization (ISO) defines audit trail as records of activities that offer means to restructure events and establish accountability (ISO/TR 13569 1997). Whenever a network service is accessed, sensitive information is disclosured or special authorization is used, an entry to the audit trail should be made. The audit trail records should cover the issues stated in the list below (ISO/TR 13569 1997). • User identification information • Date and time stamp • Executed transaction • Placement of workstations and network connectivity path • Functions, system resources and information accessed. 2.2.2 Authentication The bank must assure that the transaction requests it accepts come from a valid source, i.e. from a customer. Moreover, also the customer has to be sure that it is communicating with the bank and not with someone else. Authentication is a process of determining whether someone or something is who or what it claimed to be. In comparison to authentication, identification is the mere claim of identity whereas in authentication the claimer provides some evidence of one’s identity. Successful authentication is a pre-condition for authorization and access control, which are discussed in chapter 2.2.3. ISO presents a general model for authentication mechanisms in (ISO/IEC DIS 9798-1 1996). The model consists of three interacting parties: the claimant, the verifier and a trusted third party (TTP). The verifier is the one requiring

5

authentication and claimant has the burden of proving authenticated identity. Trusted third party is an authority on which the verifier and the claimant trust for authentication purposes (ISO/IEC DIS 9798-1 1996). The claimant and verifier may communicate directly with each other, or indirectly via the TTP. Moreover, they can also communicate only with the TTP and use information given by TTP to authenticate each other, without the need for direct communication (ISO/IEC DIS 9798-1 1996). The model including the possible information flows is presented in figure 2. In the scope of this study, we omit the role of the TTP and examine only the direct information exchange between the claimant and the verifier. Trusted third party

Verifier

Claimant

Figure 2: ISO general model for authentication mechanisms. Authentication can be either unilateral or mutual. In unilateral authentication, only one of the involved parties authenticates the other, i.e. the authentication is one-way procedure. Correspondingly, in mutual authentication, the authentication is performed in both directions. Both of the authenticating parties take the roles of the claimer and the verifier in their turns and the exchange of the roles takes place in the middle of the procedure. Both mutual and unilateral authentication schemes are presented in appendix A. 2.2.3 Customer Authorization According to the law, the bank has to maintain the privacy of its customers’ financial information. For example, both the Swedish Financial Supervising Authority (known as ‘Finansinspektionen’) and the Finnish Financial Supervision (known as ‘Rahoitustarkastus’) dictate that banks must protect from unauthorized disclosure their sites, which contain confidential financial information of any customer (Syrjänen 2001).

6

Authorization is the process of giving permission to know something or do something. The permission should only be granted on a need-to-know basis, allowing the minimum rights with which the task can be carried out successfully. As stated in (BS7799 1995), the implementation of the need-toknow principle requires: • Identification of the authorizations assigned to each product • Establishing of an authorization process and • Privilege segregation. In privilege segregation, users have separate identities for task requiring high privileges and for those requiring ordinary access rights. The access rights should not be valid until the authorization process is completed (BS7799 1995). 2.2.4 Event Logging Event logging is the process of recording system activities. These activities might be triggered by the user of the system or automated system processes. In practice, event logging is fully automated process and the logging information is saved in electronic format (BS7799 1995). The purpose of event logging is mainly to support integrity (chapter 2.4.2) and availability (chapter 2.4.3) of services and in addition to these, system access control (chapter 2.2.3) (BS7799 1995; ISO/TR13569 1997). The system start and finish time, system errors and corrective operations as well as data file processing outputs should be logged. In error and conflict situations these logs can be revisited in order to solve the problem at hand (BS7799 1995). Enforcing system access monitoring will assist to detect unauthorized access to system and the assets included in the system. Successful as well as denied logon attempts, use of specially privileged user accounts and access to sensitive assets should be recorded (BS7799 1995; ISO/TR13569 1997). According to the banking security guidelines of ISO (ISO/TR13569 1997) the records should include: • User ids • Assets that have been accessed or modified • Date, time and • Network connectivity path. In the banking industry some logging is legislatively regulated. For example in Finland the national Accounting Act dictates storing of payment transaction information for six years after the financial year in which the transaction was made (Finlex 2003).

7

2.3 Requirements for the Customer’s Environment The customer is permitted use services or programs provided by the bank only if the customer’s system does not interfere or prevent the use of the services offered by the bank (Nordea 2003). Therefore the customer must take care of that (1)

Its system follow the hardware and software standards the bank recommends

(2)

The communications and computers are properly secured and protected against unauthorized access.

2.3.1 Physical Security To prevent and restrain loss and damage of computer assets or hinder unauthorized access of its computer systems the customer must protect the computer facilities physically. An appropriate physical security includes consideration of computer equipment placement, protection from hazards like fire, water damage or power supply failure and equipment environment monitoring (BS7799 1995). The computer equipment should be placed in a way which minimizes unnecessary trespassing in equipment areas. The computers should be kept away from fire, heat, dust or chemicals and other substances that may harm electronic devices. Reserve power system is recommended for equipment that runs business critical operations. The electrical supply should conform to computer manufacturers’ requirements. Neither software and nor hardware maintenance may compromise the integrity of the computer systems. In accordance to that, equipment repairing should be handled only by authorized service personnel and according to manufacturer’s instructions. The customer should also keep a record of faults (BS7799 1995; ISO/TR13569 1997). To support computer systems’ access control, all working areas should be physically limited perimeters and monitoring of exit doors should be considered (ISO/TR 13569 1997). Moreover, authentication information, for example sign-on codes, should be securely stored independent of the physical format (BS7799). 2.3.2 Standard File and Message Formats The customer is responsible for the correctness of the information it sends to the bank. The bank performs all orders with the information the customer provided and has no obligation to perform any checks on the data it receives from the customer. (Nordea 2003). In practice, the bank states the desired data

8

format in its service descriptions. In order to get the transactions processed, the customer must ensure that their computer systems produce messages in the standard format.

2.4 Data Communication Requirements The communication provides means to offer bank’s services to its customer. These services should be available for authorised users at their request. The information that is needed to execute financial transactions should be protected against unintended and unauthorised changes and disclosure. These matters bring up the need for availability, authentication, information integrity and confidentiality. 2.4.1 Confidentiality Confidentiality is the protection of information from unauthorized disclosure (Kaufman, Perlman and Speciner 2002). In broader sense, confidentiality may mean hiding of the existence of the information (Schneier 1996). Confidentiality can be achieved via encryption (ISO TR/13569 1997). Encryption means the transformation of a message into an unintelligible form so that its contents cannot be read (Schneier 1996; Kaufman, Perlman and Speciner 2002). The original message is called plaintext and the transformed message is called cipher text. The process of transformation is called encryption and the recovering of the original text from the cipher text form is called decryption correspondingly (Schneier 1996). One should notice that the methods and algorithms that are utilized to provide confidentiality, should be publicly recognized as secure choices and moreover, they should be widely adopted (Valtiovarainministeriö 2001). The mathematical function that is used to perform encryption (and decryption) is a cryptographic algorithm. Beside the message input of the algorithm, a parameter called a key is used to hinder to reveal the plaintext from the cipher text (Kaufman, Perlman and Speciner 2002; Schneier 1996). Key-based cryptographic algorithms are usually divided in two basic categories: symmetric algorithms and public-key algorithms. The symmetric algorithms have the property that the encryption key and decryption key are mathematically dependent. It means that the encryption key can be derived from the decryption key and vice versa. Often the encryption and decryption key are the same and those algorithms are called secret-key algorithms (Schneier 1996).

9

Key

Key

Plaintext

Ciphertext

Plaintext Decryption

Encryption

Figure 3: Symmetric cryptography. As opposed to symmetric algorithms, public-key algorithms have separate keys for encryption and decryption. This design even assures that the keys cannot be derived from each other in a computationally feasible time (Schneier 1996). The public-key algorithms have got their name from the fact that one can publish the whole encryption procedure in use, including the encryption key. However, the decryption key i.e. the private key should be kept carefully secret. In this way, anyone possessing the encryption key is able to encrypt messages but only a recipient the corresponding private key can reveal the plaintext (Kaufman, Perlman and Speciner 2002; Schneier 1996).

Plaintext

Ciphertext Encryption

Public key Private key

Ciphertext

Plaintext Decryption

Figure 4: Public key cryptography.

2.4.2 Information Integrity In data communications and especially in the case of electronic financial transactions, it is essentially important that the bank receives the messages as the customer meant to them to be sent (United Nations 1999; Valtiovarainministeriö 2001). The property of information to remain unchanged during transmission is called integrity.

10

ISO defines integrity to be the property that data has not been modified or destroyed in unauthorized way, neither intentionally nor by accident (ISO/IEC FDIS 9797-1 1999). On the other hand, the British Standards Institution (BSI) takes wider perspective on integrity. BSI defines integrity as protection of accuracy and completeness of information or software (BS 7799 1995). Numerous means to ensure integrity exist. ISO recommends in its security guidelines for banking and related financial services (ISO/TR 13569 1997) that message integrity should be verified by a Message Authentication Code (MAC) of a hash value calculation. Beside confirmation of integrity, messages can be also authenticated, which covers both message integrity and origin of message verification. According to ISO, authenticity check should be carried out with the help of digital signatures or MACs. Message authentication and integrity verification are measures to prevent alteration of messages. However, if message integrity has not retained, it is still possible to detect the modification. Unique time stamps, transaction session numbers and electronic signature are techniques to detect integrity failures (ISO/TR 13569 1997). The ISO recommendations for integrity protection and detection of alteration techniques are listed below. (1)

MAC of the message hash value

(2)

Digital signature

(3)

Transaction sequence numbers

(4)

Time stamps.

Naturally, the recipient has to calculate check values and verify that they correspond with the sender’s one, independent of the applied technique. 2.4.3 Availability Banking is an essential part of the society’s everyday infrastructure. Enforced by law regulations, financial services should run reliably in emergency situation as well as in normal circumstances (ISO TR/13569 1997; Finlex 2003). Additionally, the United States National Institute of Standards and Technology (NIST) states that electronic trading systems must meet the customer and regulatory expectations in reliability and trustworthiness (NIST SP 800-9 1993). Availability is a property of a system which ensures that services produced by the system and information stored in the system are accessible to its authorized users by request (BS7799 1997). The concept of availability varies to some extent from source to source. According to ISO, availability is achieved through contingency planning, i.e. by preparing and planning major failure recovery (ISO TR/13569 1997). On the other hand, BSI separates service and system availability. The service

11

availability procedures include data back-upping, computer system logging and monitoring of the computer environment whereas system availability consists of disaster recovery planning, anticipating growth of system capacity needs and well-organized system change control (BS7799 1995). However, certain actions are common to availability preservation, independent of the definition of availability (BS799 1995; ISO TR:/13569 1997; NIST SP 800-34 2002). • Regular back-ups of business critical information¨ • Definition of disaster recovery resources (Hardware, software, power supply, personnel and premises) • Planning of disaster recovery processes and assignment of duties • Testing of the recovery plan and processes in arranged exercises.

2.5 Reference Model The requirements model in chapter 2 depicts the legislative and customer driven requirements imposed on banking systems. These requirements have to be considered in file transfer services. The model also presents formal standards and practices that are taken into account when fulfilling the requirements. The current file transfer system designs are not based on any formal system or process model or not even on a consistent series of international standards. Therefore, it is not feasible to try to develop a completely new system design or a system framework in the scope of this study. Instead, we raise some considerations that the current file transfer systems omit. In the second subchapter, the current requirements based on the model are summarized in table format, to benefit the analysis performed in chapter 5. 2.5.1 Considerations The bank obligates the customer to follow the hardware and software standards the bank recommends. In addition to that, the customer should implement access control in it’s own systems on an appropriate level (Nordea 2003) and store the authentication information, that is needed in communication between the bank and the customer, securely (BS7799 1995). The physical security of the customer’s environment is not under the bank’s control. However, the bank could provide more specific instructions on access control implementations and physical protection measures. The files that the customer sends to the bank should be in standard formats. Therefore, the bank should have test environments available for customers, so that they could test the compliance of their file material properly. This should be done before moving into the production stage.

12

The communications requirements are divided in three categories: availability, confidentiality and information integrity. Confidentiality means protection of information from unauthorized disclosure and it can be achieved with encryption. However, encryption is often an optional service (United Nations 1.4.1999; Finnish Bankers’ Association 9.5.2001) and not used in file transfer. In times when more emphasis is laid on comprehensive information security, the customers should have a possibility to use encryption when they feel they need to. To achieve this, the bank should define methods that could be utilized in encryption and develop its systems in way that enables encryption and decryption. Nowadays the file transfer systems lack support for confidentiality. Authorization should be performed on need-to-know basis (BS7799 1995). From this follows that privilege segregation should be extended to the user level, authorizing customer’s users to accounts and services instead of only authorizing customer companies to services. If the authorization is made on the company-level, the customer's have responsibility over authentication of the real users. Naturally, this implies that also authentication must be done on the customer level. Authentication, encryption and integrity protection mechanism rely on cryptographic keys. As stated previously in this chapter, these keys can bet shared secrets or public keys. Independent of the key type, usage of cryptographic keys always requires key management. The keys should be exchanged reliably and stored securely so that the secrecy of the keys is not compromised at any circumstances. This requires effective key management. Secret key cryptographic mechanisms are more widely adopted than those based on public key cryptography are (see 2.4.1). Therefore, the banks should define adequate public key management procedures to cover the key management in contemporary and future PKI applications. In addition to that, the bank could for example offer its customers secure random number and time stamp generators. To clarify the presented suggestions, they are presented in table form below. They are arranged in similar manner as the components of the requirements model.

13

Requirement Physical security Standard message formats Confidentiality

Integrity protection Authorization Authentication

Suggestions Develop instructions how to implement adequate physical security Test environments for file format compliance testing Define acceptable methods for encryption. Implementation of file encryption and decryption methods in the bank’s systems PKI key management Random number and time stamp generators Random number and time stamp generators Authorization on user level Authentication on user level PKI key management

Table 1: Considerations for future improvements 2.5.2 System Evaluation Criteria This chapter illustrates the requirement for a file transfer system on a detailed level. The division of requirement issues follows the model defined. The bank has no direct control over the customer’s computer environment, but the bank can gives instructions and recommendations on the configuration of computer environment. Because of this impreciseness, the customer’s computer environment is left out of the final evaluation. In the chapter 5, where the analysis and its results are presented each listed item is evaluated with a simple implemented/not implemented scale. The comparison between countries can be conducted, when each component (i.e. availability, confidentiality, integrity etcetera) is listed country by country. The conclusion can be drawn when assessing how many of these issues are addressed in each file transfer system.

14

Availability Confidentiality

Information Integrity

Data Communication Data back-ups Algorithm publicity Algorithm category (symmetric/public key) Key management Algorithm publicity Algorithm category (symmetric/public key) Key management MACs and/or digital signatures Time stamps Digital signatures

Table 2: Summary of evaluation criteria for data communication

Audit trail

Authentication

Customer Authorization Event Logging

Bank’s Systems User identification information Date and time stamp Executed transaction Accessed resources Algorithm publicity Algorithm category (symmetric/public key) Key management Mutual/Unilateral Authorization level (customer/user) Privilege segregation Identification of authorizations System start and finish times Error logging Data processing output logging Log contents

Table 3: Summary of evaluation criteria for the bank’s systems

15

3

Payment Systems

3.1 Denmark Danish banks are members of Danish Bankers’ Association, Finansraadet. The purpose of the association is to protect its members’ interests in Danish governance as well as European banking industry. The Danish Bankers’ Association also promotes development of Danish payment transfer infrastructure (Danish Bankers’ Association, 2003). However, payment transfer or payment formats standardization does not belong to associations’ duties. Therefore every bank in the Danish banking industry has own local formats for different payments (Borkenfelt 3.11.2003). The Danish banks have joined a common network, which is used to exchange domestic payment information in certain local format called UDUS. For currency payments between Danish banks, the international SWIFT banking network is utilized. In both cases above, no money is actually transferred directly between Danish banks. All banks have an account in the Danish central bank and he the money is transferred between these accounts. The total payments sum is cleared by the central bank and only the net sum of payments transfers of a clearing period moves from an account to another (Borkenfelt 3.11.2003). 3.1.1 Danish Electronic Banking Systems The Danish electronic banking system present file transfer functionality of two kinds: the actual file transfer functionality and a so called import/export functionality. The former, i.e. file transfer, means that a customer transfers a file from one point to another, from its ledger system to the bank or vice versa. The integrity of the file is protected before the transfer begins, and the file travels untouched from the source point to the destination. The customer cannot view, change or delete the payment file in transition. On the other hand, import/export functionality offers a way to modify the payment files. The customer imports a file from its ledger system to an Electronic Banking System (EBS) program and can change or delete single payments contained in the payment file. After the modifications, the customer signs the file and exports it, i.e. transfers the modified file from the EBS program to the bank’s host system (Borkenfelt 3.11.2003). Nordea Bank Denmark offers customers three file transfer products: Unitel for PC is an EBS program designed especially for small corporate customers, Unitel EDI is a file transfer product for small and medium sized Danish customers and Nordea Corporate EDI Gateway is a file transfer program for large Nordic corporate customers (Borkenfelt 27.10.2003).

16

The Unitel for PC provides the customers a way to transfer payments to the bank via an electronic mailbox. The payments can be entered three months before the due date and the Unitel for PC launches the transaction in time. Available payment types are listed below. • Account transfers within Nordea • Account transfers to other Danish Banks • Request for Transfer • Giro account transfers*) • Payment of giro transfer forms • Payments of domestic and international cheques ) Requires an agreement with BG Bank made before 1.11.1996.

*

With Unitel EDI the customers are able to deliver their international and domestic payments to the bank in EDI-4 (Danish supplement to EDIFACT version 4) or in the United Nations EDIFACT format. The Unitel EDI employs file transfer functionality instead of the import/export functionality of the Unitel for PC. Nordea Corporate EDI gateway allows the customers send both domestic and international payment through one single payment format; Nordea’s EDI centre will take care of separating cross-border payments to be transmitted via the international SWIFT network and domestic payments.

Nordea EDI centre

Corporate EDI GW

Customer ERP system

Unitel Host system Unitel PC

Unitel EDI (centre)

Unitel EDI

Figure 5: Electronic banking systems offered by Nordea Bank Denmark.

17

3.1.2 File Transfer Communications The available communication alternatives depend on the customer’s choice of file transfer product (chapter 3.1.1). The users of Unitel for PC connect to the bank’s system over TCP/IP networks. They may have either modem line or a Local Area Network (LAN) connection. The modem connection can be established over standard phone lines or the customers may acquire a direct leased line to the bank’s end. However, in any case, the customer makes a contract with his Internet service provider, independent of the bank. AS/400 environment’s connection alternatives are either dial-up or direct line. In case of dial-up connection, the protocol for file transfer is the DMM of the OS/400 operating system. The direct line may be connected directly to the bank or to a switching centre approved by the bank. In both occasions, RJE and IND$FILE are applicable file transfer protocols. To the UNIX and mainframe platforms same rules apply concerning direct lines, but UNIX dial-up over TCP/IP network utilizes Xmodem file transfer protocol instead. Ordinary PC users connect to the Unitel Edi with dial-up over TCP/IP networks. If customer connects to the bank via a Value Added Network (VAN) all connection types are available. The value added network means that the service provider charges the customer by each byte transferred over the connection. Corporate EDI Gateway is reachable only via X400 network. 3.1.3 File Transfer Architecture All files that the customer sends are processed in the Nordea Denmark’s ground system, i.e. Unitel Host system independent of the way they are sent to the bank. The bank processes files in its UTF and EDI-4 in-house formats. All files in other formats than these are converted to EDI-4 format at arrival in the receiving front-end (Borkenfelt 11.12.2003). Customers using Corporate EDI Gateway send their files to Nordea’s EDI-Centre in EDIFACT format. Customers that have chosen Unitel for PC program, send their files directly to the Unitel host system in UTF format. Unitel EDI has a dual meaning: it can mean either the file transfer program in the customer’s computer system or the mailbox functionality inside the bank’s system. Customers using Unitel PC retrieve their feedback files from Unitel EDI system and customers using Unitel EDI file transfer program both send and retrieve their files from Unitel EDI center (Borkenfelt 27.10.2003). Figure 5 illustrates the differences described above. The Unitel host system is interconnected with Unitel user administration (QPRI). Incoming files are validated against the QPRI, which executes file syntax check, integrity checksum calculation and data decryption if the files are encrypted. Finally, customer’s authorizations for upload are checked and file contents are validated. Unitel user administration fetches users’ authorization

18

information from Unitel Admin database, which contains customer numbers, customers’ service authorizations and payment agreements. After necessary validation, Unitel host system stores payment information to Unitel Payments database that includes information of all payments that are handled by Unitel host system. Payments are executed on their due date when the payment instructions are handed to the payment applications like Unipay that processes international payments and Request for Transfers. Unitel host system is also connected to the bank’s account system, Unibog. The Mailing data component retrieves account information and payment instruction feedback files from account system and KUD (KUD stands for Customer and Data) application and places them to Unitel Information database. The files are available for customers via Unitel EDI Mailbox where the files can be retrieved (Borkenfelt 27.10.2003). Figure 6 depicts the Unitel system architecture.

QPRI

Unitel Admin

Unitel Payments

Client Client Ledger System

BGS

Unitel Host System

Unitel PC

UniPay

Clearing

Internet connection

Mailing data UniBog

Local file system

Unitel DB

Unitel EDI

Unitel Info

Customer site

KUD

Bank site

Figure 6: Danish file transfer system architecture.

3.2 Finland Finland has one common payment system, which all deposit banks represented in the country have joined (Häkkinen 2002). All these banks are members of Finnish Banker’s Association, the organization promoting banking operation and standardization in Finnish banking industry as well as international cooperation between banks.

19

Finnish banks are connected to each other via private networks and payments are transferred directly between parties. There exists two separate systems for transaction transmission named PMJ and POPS, the former standing for “Payment Transfer System between Banks “ and the latter standing for “Online Express Giro System between Banks” . The POPS system is designed for express- and check transactions whereas PMJ is used for other types of transactions. Every bank operating in Finland has a check account in Bank of Finland and the balance transfers are executed between these accounts. The transaction information is delivered directly between sending and receiving bank. The transactions included in POPS system are delivered in closed packet network between banks and PMJ transactions are delivered via closed TCP/IP network to which all banks are connected as well (Finnish Banker’s Association 1999; Finnish Banker’s Association 2001). 3.2.1 Finnish Electronic Banking Systems Corporate customers have varying needs for electronic banking. Small companies may only have a couple of accounts and make monthly salary payments for their employees. On the other hand, large companies often own hundreds of accounts, have complex cash pool structures and handle large amounts of international and domestic payments daily. The main tool for small corporate customers for regular banking activities is the netbank, which is accessible via internet, ordinary phone and Wireless Application Protocol. Customers can enter Solo Internet via World Wide Web in public TCP/IP networks. In Solo Internet’s browser-based user interface the customers may, for example, retrieve real-time account balance information, make single payments, pay salaries and handle company’s invoicing. Medium sized and large companies have considerably bigger banking transaction volumes compared to small ones and making payments one by one becomes ineffective. File transfer technology provides a solution for this particular problem. Finnish Banker’s Association has developed common standards for payment and account information file formats. In addition to that, the authentication procedure, data integrity protection and necessary key management required for implementation of authentication and integrity control are also standardized. This security standard called PATU is followed in data transfer between banks and their customer throughout the whole country. Finnish Banker’s association is the originator of the PATU security standard. Nordea Bank Finland offers two products that exploit file transfer technology: Multibank and Banking Program. Customers generate transaction files in their own ledger systems and import them to Banking Program or Multibank program. After that, the necessary integrity checksums are calculated from the transaction files within the programs and security messages needed in data transfer are generated.

20

After the steps described above are performed, the customer opens a connection to the bank and to its file transfer system. After a successful authentication and transfer request, the customer may send files to the bank and receive files from the bank. The main difference between Banking Program and Multibank functionality is that the customer can send files to other Finnish banks with Multibank but with Banking program the customer can contact only Nordea Finland’s’ own file transfer system. The file transfer system, its architecture and functionality are discussed in more detail in chapter 3.2.4. 3.2.2 File Transfer Communications The customers can connect to the Nordea’s file transfer system either via X.25 or TCP/IP networks. For communication over TCP/IP network, currently two commercial solutions are available for customers: LanLink network service or Datanet network service. LanLink network is owned by local Finnish phone companies whereas Datanet is offered by nationwide internet service provider Sonera. The customer makes a contract independently with its internet service provider and no permission from the bank is needed. If the customers connect to the file transfer system via public internet, the bank advises them to use a Virtual Private Network (VPN) connection. Basically, the VPN simply tunnels the traffic between two endpoints and the connection appears to be point-to-point. The customers are able to connect from a private network, but then the traffic is directed via one of the alternatives stated above. Public packet networks are another communication channel from the customer side to the Nordea’s file transfer service. Finnish internet service providers Sonera and Elisacom offer either leased line from customer site to the bank or a dial-up connection via their packet network to the bank. Connection from abroad to Nordea’s file transfer service can be established via international public packet network service. The service provider is international teleoperator Sprint and the customer makes an agreement with the Sprint’s Finnish representative. Kermit telnet protocol is used in packet switched communications and transfer rate up to 64 kilobytes per second is possible. In case of traffic over TCP/IP, the protocols used are Kermit and ftp and transfer rate is 155 megabytes per second maximum. 3.2.3 WWW file transfer The transfer via WWW is done file by file. Therefore it is suitable companies, who have small file transfer volumes. We introduce the WWW channel briefly below, but leave it out from the further because the files arriving via WWW interface constitute only a minor portion of the total volumes.

21

The connection to netbank is established through Nordea’s web service and the customer carries out its operations with the help of an internet browser program. In Finland, the product is called Solo Internet. The connection made over TCP/IP network is controlled over secured Hypertext Transmission Protocol (HTTPS) and encrypted with Secure Sockets layer (SSL) protocol. Both HTTPS and SSL protocols are designed for web browser environment. In WWW file transfer, the authentication of the customer is carried out with a customer number and a changing password or One Time Code (OTC). The usage of PATU authentication is not mandatory but up to the customer. Whenever a customer decides to take PATU keys in to use, the PATU authentication and integrity protection are used beside OTC authentication. After the customer has chosen to utilize PATU keys, their usage becomes mandatory and the bank performs necessary checks upon that (Merita 2001). Customers pick up the files they want to send to the bank from their local machines and send the files out in netbank’s user interface. Once the files reach the bank’s site, the same file transfer system receives and forwards the files. 3.2.4 File Transfer Architecture Nordea’s file transfer service provides a transmission channel for payment transaction materials between customer and the bank. In addition to mere transmission between these two endpoints, the file transfer also monitors the traffic and stores the material received from the customers. The general file transfer architecture is illustrated in Figure 7.

Session management (ftp, kermit)

PATU authentication telecon nection DB

PATU security calculation logging file material receipt

Help file

intermediaries

File receival feedback

file material

File submission upload download

customer files

Figure 7: Finnish file transfer architecture.

22

File transfer performs a validity check at reception to ensure that a message group is structured as stated in the corresponding service description. (Merita 2001; Nordea 2003). If the material passes the test, file transfer forwards it to the payment application responsible for the file material in question to be further processed. Various payment applications produce information that customers are able to retrieve from the bank via file transfer. When the payment applications have finished processing and the material is ready to be retrieved, they send it internally to the file transfer system where the material is kept for a certain time period, available for customers to be retrieved. Neither the file transfer system nor payment applications notify the customers in any way; the retrieval is always initiated by the customers (Merita 2001). Before any files can be sent, the customer and the bank must authenticate themselves. The authentication procedure is described in chapter 4.9.2. After a successful introduction, the customer sends a transfer request to the bank. A transfer request tells the type of the files the customer wishes to send and according to that information, the file transfer system delivers the file material arriving from the customer to the correct reception program. The PATU keys needed during authentication and integrity checksum calculation are stored in Teleconnection database and the file transfer system retrieves the keys by customer number from there. The connection opening, authentication and transfer request details are written into a log file, which can be used in problem solving and error detection. The reception program pre-checks the files while they are received in the bank. The purpose of this check is to ensure that the customer is authorized to send files of the type in question and that the customer has the same service id as that included in the batch file. The authorization information is retrieved from intermediaries database. Unauthorized or erroneous transfer is rejected. The batch file is saved to a customer-specific file and the file name is generated from file transfer help file. The batch file summary and status information are written down to the File transfer surveillance log. The customer receives a receipt of transactions accepted for further processing and can then retrieve a feedback on discarded transactions. If the entire batch file is rejected, the customer receives an acknowledgement that contains a reason for the error. (Merita 2001) The most important interfaces that file transfer has to Nordea’s other system are listed in Table 4. The received files are processed further as payment application batch jobs, i.e. downloads, on banking days. The download procedure updates the files’ status information located in payment surveillance log as well as the download time. The payment applications generate a feedback message for most files. For certain file types, the feedback is generated immediately and is available to be retrieved right after the transfer is completed. Feedback messages of this kind are in plain text format. Other kind feedback messages are generated according

23

to service-specific schedule and can be retrieved from file transfer system like ordinary retrievable files. The connection must be closed with an end command depending on whether Kermit of ftp protocol is used. If the customer terminates the connection without a proper closing command, the connection is closed after one minute of elapsed time since the last transfer request. Component Name Teleconnection database Intermediaries database Log file

Help file File Transfer Surveillance file

Description Stores PATU keys and other customer information needed for authentication and integrity protection. Stores customers’ authorisation information for different services. Recorded information about connection opening, authentication, transfer requests, payment application-specific error and information messages, connection closing Customer-specific file names for incoming file are generated from help file. Stores status information of received files and monthly total transaction amount statistics.

Table 4: Main components of the Finnish file transfer system.

3.3 Norway The Norwegian banks are interacting via a central clearing house Bankenes BetalningsSentral (BBS). The banks send their transactions from a clearing period to the BBS, which in turn performs the clearing and sends the cleared totals of the transactions to the Bank of Norway (Norges Bank). Then the central bank transfers the cleared totals between banks’ accounts located in the central bank. There also exists a national interbank standardisation body named Bankenes Standardiseringskontor (BSK) and its tasks are to promote and develop Norwegian banking standards (Knudsen 2003). 3.3.1 Norwegian Electronic Banking Systems The main file transfer solution for Norwegian customers is called K-link. The customers may choose between PC-client based program K-link for Windows, Klink Online and K-Link Integrated. K-Link Online enables among others on-line payment file deletion and dual confirmation of payments. K-link Online is

24

available for customers that have main frame emulation functionality in their computer systems (Knudsen 2003). K-link Windows and K-link Online are connected to the customer’s accounting system, where the files aimed to the bank are retrieved and thus sent via K-link program(s). Moreover, the customers can send files of certain types to the bank directly from their ledger systems if they have decided to use K-Link Integrated. K-Link Integrated enables direct connection from customer‘s ERP system to the bank’s site. (Knudsen 2003). However, all arriving files will first be run through a common front system K-front after which they arrive at Electronic Cash Management (ECM) system. Files originating from K-link Windows remain in ECM system for further processing but files that have arrived directly from ledger system are forwarded to Interpay system (Knudsen 2003; Nordea March 2003). The file transfer system architecture is depicted in more in detail in chapter 3.3.3. 3.3.2 File Transfer Communications K-Link customers connect to the bank’s file transfer system via TCP/IP networks. However, the choice of the type of the communication line depends on the product used. Users with K-Link Windows program can choose between a modem connection and internet connection from inside a Local Area Network (LAN). Those customers in favor of the modem connection purchase their lines from a service provider Annex. The LAN connection might be for example corporate network or an individual corporate customer that has acquired the connection from its internet service provider (Nordea 4.12.2003). In addition, K-Link Online users need a communication line over TCP/IP network. Annex modem connection is not available for mainframe environment customers, so internet service providers offer connections to these customers too (Nordea 4.12.2003) In contrast to K-Link Windows or K-Link Online users, customers with K-Link Integrated have direct leased lines from their computer systems to the bank (Knudsen 2003). 3.3.3 File Transfer Architecture Files from customer sites arrive first at K-Link front system. There details (size, name, arrival time, etc.) of all arriving files are written down to log file and the files are back-upped. If the files are sent along an internet connection, they are encrypted in transit. Thus, K-Link front is also responsible for (SSL) data decryption/ encryption procedures. If the owner of the files is using K-Link Integrated and has decided to use seal to protect the integrity of the data, the checksum is calculated in the K-Link front system (Nordea 4.12.2003; Knudsen 2003).

25

Next, the files move to ECM host system, which is not constructed of a single component but a number of internal systems. There the data embedded in the files is stored in a database prior to the file validation. ECM Admin system contains K-Link User Administration database with user numbers, users’ authorizations and K-link payment agreements. The steps the of payment instruction validation processes runs in following sequential order (Nordea 10.3.2003): (1)

Syntax check

(2)

Security check

(3)

Authorization for upload

(4)

Validation and authorization.

Security check includes customer number control and authentication with Authentication Control Functionality (ACF2) mechanism, which is based on user Ids (customer numbers) and passwords (Nordea 10.3.2003; Nordea 4.12.2003; Hinsch 2003). Customers are authorized to upload files with the help of a Digipass product. Digipass is a small token device, with which the customer can calculate responses to upload authorization challenges if she/he possesses a secret Personal Identification Number (PIN) code (Nordea 9.1.2003). Eventually, if all preceded steps completed successfully, the customer’s authorizations to services, i.e., the contents of payment agreements, are retrieved from K-Link User Administration database and if the match with the customer’s upload request, the validation is completed. Validated payments are executed on their due dates. System named 521 is responsible for international payments, Interpay handles information of all KLink payments and SWIFT takes care of RfTs. Moreover, Norwegian clearing system, the bank’s account system and cover control systems are involved. When payment instructions are completely processed, the feedback is put in ECM so that customers can retrieve it (Nordea 10.3.2003).

26

Ecm admin Interpay

Client

K-Link PC

Local file system

Modem or Internet connection

K-Link front system

Online

Client Ledger System

Cover control

ECM Host

Clearing

SWIFT

Account system

K-Link DB ”521”

Customer site

Bank site

Figure 8: Norwegian file transfer system architecture.

3.4 Sweden The Swedish banks as well as the foreign banks which have branch offices in Sweden are members of the Swedish Bankers’ Association (Swedish Bankers’ Assiociation1 21.11.2003). The main tasks of the Association are to promote national and international co-operation and be the representative of its members. The Association participates in the development of the international financial EDIFACT (Swedish Bankers’ Association2 20.11.2003). The Swedish banks have a common closed network (Rydholm 17.11.2003). The payments clearing system called Data Clearing system (DCL) is owned by the Swedish bankers’ Association. However, the clearing runs in Bankgiro Centre (BGC). However, the clearing is based on the accounts located in the Bank of Sweden. After the Bank of Sweden has moved the cleared net sum totals between the banks’ account, BGC sends corresponding transaction information to the banks. Then the banks execute the transactions from and to the accounts in question. All banks participating in the clearing have agreed on certain payment formats they accept. The standardization was lead by BGC.

27

3.4.1 Swedish Electronic Payment Systems The existing Swedish file transfer services originate from two former Swedish Banks, Nordbanken and Postgirot, who both are now a part of Nordea Group. They both had their own ground systems and moreover, the services and products offered to customers too. The Postgirot solution consist of a file transmission front-end system called Fantom and customer programs. The customer programs can be Windows or DOS clients, browser-based applications or applications utilizing mail box-functionality (Frank 20.10.2003). The GiroLink via Internet is a browser-based application with which the customer can transfer files from its own personal computer to the bank. The customer may choose to create the payment material withPostgirot’s GiroVision Internet product or import the payment files from its own ERP system (Postgirot 21.11.2003) GiroLink file transfer service is also available as client software for various operating systems and platforms: Windows, Macintosh, UNIX and mainframe computers (Postgirot 2002). All file transfer services described above (GiroVision and GiroLink) exploit the Postgirot’s file transfer system called Frank 20.10.2003). The Fantom architecture consists of three basic concepts: node, file type and transport. A node can be an application or a customer client, or even a special internal node. File type holds the information of the type of the data (payments, salaries etc.) and transport is the combination of source, destination and type of the file (Postgirot 26.4.2002). The Fantom architecture is discussed in detail in chapter 3.4.3. 3.4.2 File Transfer Communications In Sweden separate communication alternatives exist for mainframe and PC customers. The PC users have modem connections for asynchronous transfer and the connection speed can be raised up to 33,6 kbits per second. If the PC customer favours synchronous transfer instead, a DATEL link with maximum speed of 28,8 kbits per second full duplex is available. In synchronous transfer the 3780 main frame emulation protocol is used (Frank 20.10.2003; Postgirot 2002). The customers having mainframe environment may choose either TCP/IP connection or a Subscriber Network Interface (SNI) connection. The latter can be established via: • Customer’s own communication link • Leased communication link • Re-direction via a service centre • Tele2 operator’s snix-network

28

The link layer protocol is either X.25 or Synchronous Data Link Controller (SDLC). The terminal protocol is IBM/ Netview File Transfer Protocol (NFTP) or ConnectDirect. The SNI line can even reach a speed of two megabytes per second maximum. The mainframe customer has also a possibility to use packet or TCP/IP networks. The X.25 connection may be created over a ´service provider’s packet network or a direct line. Those customers fond of TCP/IP connection are free to choose among an Integrated Services Digital Network (ISDN) connection and IP-network (for example LAN or corporate network). The application protocols for mainframe’s TCP/IP connections are FTP and DirectConnect (Frank 20.10.2003; Postgirot 2002). 3.4.3 File Transfer Architecture A system called Fantom is the core of the Nordea Sweden file transfer solution. The Fantom system receives files both from customer side and from nodes inside Nordea’s ground systems. The Fantom system also stores the files and they are accessible by various payment applications. Moreover, after processing the files, the payment applications return the feedback information to Fantom so that customers may retrieve the feedback to their own ledger systems. Also account statements and retrievable files other than those containing processing feedback are accessible to customers via the Fantom system. The Fantom system consists of two main components, the batch program and the online interface. The batch program executes the actual file transmission tasks whereas the online interface monitors the transmission activities and maintains information of the system parts included in the batch program. (Postgirot 26.4.2002). The core of the Fantom is constructed from nodes. A node is a logical presentation of a customer or a bank’s application. Transportation consists of a source node, a destination node and a file type. The file type defines what sort of information is encapsulated in the file. Moreover, the nodes can be special Fantom nodes, which are used in case of varying error and conflict situations (Postgirot 26.4.2002).

29

File type register

File type informatíon

Composite files

file transfer info +data sets

CTY-node’s transportation register Nodes and transfers

Communic ation files Split up composite files

Composite files

SEAL-key register

SEAL-keys

Communic ation files

Active transfers Put-inFantom

file transfer info

Retrivefrom-Fantom

file transfer info

Composite files Create Composite files

file transfer info +data sets

Completed transfers

Log file

Read in file-inFantom

Application

Application

Write out filein-Fantom

Files-inFantom

Data sets

Figure 9: Swedish file transfer system (Fantom) architecture. The Fantom system handles the file transmission information and the data separately. The transmission information forms an address label, which contains information of the file origin, destination and type. The transaction information forms a data set. Files that arrive in Fantom and contain both the address label and the data set are called composite files. The files are saved in the composite file database. A system program separate composite files distinguishes the address label and the data portion of the composite file. The program checks from file type register how the separation should be done. The data sets become so called files-inFantom and they are moved to a corresponding database. Every data set will be named by a Fantom naming program and the given names follow a certain naming standard (Postgirot 26.4.2002). The batch program puts the address labels to the communication file database and then shifts the control to the put-in-Fantom program. The program retrieves then customer’s signature keys from the Seal keys database and calculates the seal value to ascertain the integrity of the information. The put-in-Fantom program fetches the value of the next node i.e. to-node from the CTY-nodes transports database and appends the to-node information to the communication file. Then put-in-Fantom program adds an entry to Active transports database table and writes a track of performed operation to the log file. Active transports are actually file transmissions that have not yet reached their destination nodes.

30

When a payment application is ready to process the transactions further, it creates an order file telling the to-node (the application itself) file type, source and destination of the desired data. Moreover, in certain cases, the application may also create a parameter file or a list file to provide specific search criteria for the datasets it requests for. The retrieve-from-Fantom program then processes the order file, extracts active transports matching the request from the database table and writes the gathered information to a new communication file. The active transport in question is deleted from the database and instead, adds it the log file as a completed transport. In the end, a program called create-composite-file reads the communication file, retrieves the data set on which the communication file points, and combines the communication file and the data into a composite file and sends it to the application. If, on the other hand, the application is able to co-operate directly with the file transfer system, the composite file is not needed. The applications read and write files directly from/to files-in-Fantom via calling the read/write-file-inFantom program (Postgirot 26.4.2002).

31

4

File Formats and Security Implementations

4.1 Introduction There are over 1500 different file formats in Nordea Bank. This chapter aims to provide a small sample them. We have chosen representative(s) from each country, among those file types that have largest yearly volumes measured in transactions and/or cash flow. From Denmark we picked up the EDIFACT format. Bill payment files, recurring payment file and terminal card transactions are from Finland. Telepay comes from Norway and the two last ones, In-payment file and Invoice payment file, represent Sweden. Security functions often utilize pieces of information that are embedded in the files. For example, sequence numbers used in integrity checks are embedded in the files in many cases. Therefore we discuss security in the subchapter 4.9.

4.2 EDIFACT format The Danish Unitel EDI and Corporate EDI Gateway both use EDIFACT Directory 96 A format to exchange payment transaction information between the customer and the bank or vice versa (Borkenfelt 3.11.2003). The information is encapsulated in messages of different types. The message flow and the message contents depend on which file transfer program the customer uses; both Unitel EDI and Corporate EDI Gateway have their own implementations. Basically, the structure of the messages remains unchanged but the optional segments included in the messages vary (Borkenfelt 3.11.2003). In principle, all data in EDIFACT messages are organised in segments. A segment is a collection of related data and each segment has a segment tag so that it can be identified. Moreover, segments may be further collected into segment groups that together contain related data, which could not fit within one single segment. Each segment contains single and/or composite data elements. One data element contains one piece of data whereas composite element contains many data elements, each of which contains one piece of data correspondingly. Data elements are marked with four-digit numbers and composite elements are marked with strings of alphabet C and three-digit numerical value (Nordea 07.07.2003). Since the EDIFACT message implementations are program-specific, we present as an example only the logical structure of a multiple payment order (PAYMUL) EDIFACT message. The customers transfer payment instructions to the bank with PAYMUL messages.

32

A PAYMUL message may contain one or more debit orders and one or more credit orders attached to each debit order. Reference information tells the reason for the payment and it could be linked with the corresponding credit order. The debit order contains details from the ordering customer, payer, and payer account (debit account) and debit transaction information such as payment date, total amount and payment currency. The credit order includes information about beneficiary, payee (credit account owner), credit account and credit transaction information: payment amount and currency. In addition to debit orders, credit orders and reference information, the PAYMUL message contains a payment order group. The group holds information about the payment order: the date on which the message was created i.e. the payment order date, its unique verifier, the payment order number and its predecessor’s date and reference number, labelled as previous payment order. The previous payment order element is filled only in the event of duplicates or re-transmissions. The payment order group might contain also payment order sender and payment order recipient elements but only with the permission of the receiving bank (Swedifinans 15.4.2003).

4.3 Bill Payment Files A bill payment file is composed of three or four different records: a batch record, one or more transaction records, an optional message record and a sum record. A batch file can consist of one or more payments, but one batch file can only contain transactions: • with the same due date • with the same payer’s account number • bills and/or payments or express payments There exist two separate record standards, LM02 and LM03. The newer LM03 is recommended. The LM03 standard differs from LM02 in following points: transaction records may only include payments and the bank does not combine transactions. LM03 does not include discount or default interest calculation, because these are nowadays carried out in customers’ ledger systems. In LM03, the payer can give details of the bills to the payee by using itemisation records (Nordea June 2003). Rest of this chapter gives an overall syntax of records following LM03 standard. For more details, please see (Nordea June 2003). The first record of a payment file is a batch record. A new batch record (and a new payment file) is created if any of the following information changes: service code, payer’s account number, due date, payer’s name qualifier, batch identifier and file content type. Note that this is consistent with the batch file content rules . The record fields are listed in the table below.

33

The payment file records are separated with certain record separators. Each record ends with a carriage return and a line feed characters. A record called transaction records follows the batch record in a payment file. As implied in the name, transaction record holds the information of a single debit transaction, including transaction type (payment), payee qualifying information, sum of transaction and message. The message can be reference number, freeform message (up to 70 characters), long message (up to 420 characters), tax message, or bill details. An itemisation follows a payment transaction or payment transaction messages. Itemisation record cannot be used if the transaction message is tax message or reference number. The itemisation record must have same payee account number as the corresponding transaction record, otherwise the itemisation record is rejected. A message record is an option record, which is used if transaction message is long message or a tax message. The message record is adjacent to the transaction or transaction itemisation record it belongs to. The sum record is the last record of a bill payment batch file. It holds the number and sum of the payments together with payer’s information included in the batch file in question. If the total sum and number of payments are not equal to those calculated from the transaction records, bank rejects the batch file as a whole.

4.4 Recurring Payments files A recurring payments batch file consists of transaction records and a sum record. One payment file may be composed of several batches and one batch may contain one or more payment transactions. A single batch file may only contain transactions: • With the same due date • With the same payment subject • Of the same payer Records are separated with record separator. Every record ends with a carriage return and a line feed character. Transaction record contains information of payment date, payee’s account number and personal identity number, payment subject and name and payer identifier. The one or more transaction records are followed with sum record placed at the end of a batch file. The sum record must be created every time when payment date, payer code, payment subject or monetary unit changes. The reason for payment could be for example salary, pension, interest income or other recurring payment.

34

4.5 Payment Terminal Transactions A payment terminal, or in other words, point of sale system is a device that processes debit or credit card transactions. The payment terminal reads the debit or credit cards, performs required checks and authorizations and records the purchase transaction electronically (Finnish Bankers’ Association, 2002). The merchants act as payees and they forward the recorded card transactions to their own banks. If the payee’s bank is the same as payer’s bank, then the payment is executed, but otherwise the payment is forwarded again to the payer’s bank for execution in order to deliver the money to the payee’s account. In the rest of this chapter we refer to payees as customers. The customers deliver the payment terminal transactions to the bank via file transfer system. As well as bill payments and recurring payments, Finnish Bankers’ Association has created a national standard for payment terminal transaction file formats. The files transmitted between the customer and the bank are transaction file from customer to bank and from bank to customer feedback file, warning file and warning file updates. The batch file consists of transmission batch record, one or more batches and a transmission sum record. The batches have also an internal structure, which is divided in to account batch record, one or more transaction and message records and account sum record. The transactions are grouped into batches by payee identifier and payment card type. The transactions made with debit cards or credit cards issued by bank belong to a same batch whereas transactions made with other issuers’ cards form a batch of their own. Transactions within same batch are sorted in ascending by card number Account batch record contains the number of transactions and the total net amount of these transactions. The account sum record is used to define the sign (+/-) of the transactions included in account batch record. The number of transactions and the net amount of transactions are repeated in account sum record. A transaction record identifies one single transaction made on payee’s payment terminal. It can be a debit or a credit transaction. Correspondingly, a message record consists of one single transaction that triggered a warning on the payment terminal. These kinds of transactions could be attempted use of card listed in the bank’s warning file or attempted payment authorization with incorrect PIN. After the bank‘s file transfer system has received the whole batch file and forwarded it to the responsible payment application, bank forms a feedback file. This feedback tells which of the transactions included in the batch file are accepted for further processing and which of them were rejected. The feedback is formed once a day (Nordea, August 2003).

35

4.6 Telepay The BSK has developed a payment file format Telepay. Although the standard is national, following it is not obligatory for the Norwegian banks. However, Nordea has adopted the Telepay standard and it is the most common type of incoming files when measured in yearly transaction volume (Knudsen 2003). The Telepay files are divided into batches, which consist of records. Each batch is separated from the others with a starting identification transaction record and an end-of batch transaction record. Moreover, same physical file may contain both domestic and cross-border payment instructions if only they are divided into separate batches with their own start and end records (BSK 28.10.2003). Cross-border payment instructions are categorised according to one payment instruction per beneficiary, in the same currency, with the same value date, payment date and regulatory report code (BSK 28.10.2003). To enable this division, cross-border payment instructions have four different records beside identification transaction and end-of batch transaction records: • Transfer transaction record • Beneficiary bank record • Beneficiary record • Invoice record The records follow each other in the batch in the above-listed order. Transfer transaction record contains information that is common for all the payment instructions inside the same batch like due date, value date and exchange rate. As its name suggests, beneficiary bank record embeds those details that identify the beneficiary’s bank unambiguously: bank name, addresses, swift address and country code. Accordingly, beneficiary record contains beneficiary identification information. Invoice records wrap up the actual payment details including payment reference number and amount. One should note that an invoice record contains one single payment, and multiple payments within a payment instruction are constructed with adjacent invoice records. One transfer transaction record can hold up to 999 invoice records linked to it (BSK 28.10.2003). The records related to a domestic payment batch are quite similar to the cross-border payment instructions. The batch starts with an identification transaction record and terminates with an end-of batch record. In between are transfer transaction records, invoice records and mass payment records. The consequent invoice records and mass payment records are separated with a transfer transaction record. Mass payments are payments like salaries or pensions and only one reference number is used through the whole set of payments compared to invoice payments where every payment may have its own reference. Domestic payment instructions also allow cash transfers between the company’s own accounts.

36

In domestic payments, the beneficiaries are identified with their names and account numbers included in the corresponding fields of invoice and mass payment records. One should note that even if the meaning of different records may be the same in cross-border and domestic payment records, they differ in the actual contents and syntax. Certain properties are common to all files obeying the Telepay format. An application header precedes every record so that the bank’s system is able to determine the type of the payment instructions (cross-border or domestic) and process the data in the incoming files. Records are always 320 characters long, from which the application header fills the first characters. The files contain two sequence numbers in order to prevent unauthorized changes or duplicate transmissions of payment instructions. First of these sequence numbers is placed in each application header. The number counts from 1 to 100 000 and is readjusted to 000 001 every day. The sequence numbers should form an unbroken chain throughout the entire day. In addition to that, each record type holds a position of four-number control number that starts from one and is incremented with one position up to 1000 whenever a new record is created. The sequence formed by these control numbers should be continuous between files. When the counter reaches 1000 it simply starts over from 0001 again. The identification transaction records and end-of batch records include the fields needed for seal calculation. Their types and lengths are the same for cross-border and domestic payments (BSK 28.10.2003).

4.7 In-Payment Files In-Payment service is targeted for customers who receive large amounts of incoming reference payments such as rents or membership fees. Basically, InPayment transactions are reference payments that are processed in Postgirot’s system (Postgirot 2000). In the rest of this chapter, the word sender refers to the customer of Postgirot, who has agreed on using In-payment service. The customer of the sender, i.e. the payer of the reference payment is referred as the customer. The In-Payment file contains records of seven types: a Header record, Customer records, Account records, Date of posting records, In-Payment records, Summary records and a Summary/End of file record. A summary record is formed per customer account and per date of posting, which means that In-Payments of the same customer with same posting date are grouped together. The header record includes information of service bureau, accounting unit, type of data medium and serial number in order to deliver the payment forms information to a service house. These service houses print out in the inpayment forms on paper, after which the forms can be delivered to the customer. An accounting unit is a group of customer accounts that are reported on the same data medium to the service bureau. The serial number

37

identifies the multiple entities of the same physical media. In addition to information meant for service bureau, the header record carries information of file layout code (Unicode), production date at Postgirot and a tag for whether the customer has agreed on registration of payment rejects. The Customer record contains customer reference number (allocated by Postgirot), name of the customer and spare position for future use which is left blank. The Account record contains the same customer reference number as the customer record and the Postgirot account number. The Date of posting record, following Customer and Account records, contains customer reference number and Postgirot account number plus date of posting and spare positions. The In-Payment record contains again, the same customer reference number. Then follows the payment total amount, given in Swedish currency. Also sender information is filled in the In-Payment record. The sender is identified with sender’s Postgirot account number. The film number and spare positions are located in the end of the In-payment record. The Summary record carries the number of in-payments and the total amount of the in-payments, calculated from individual account with same posting dates. The customer reference number, Postgirot account number and date of posting are naturally included in the beginning of the record. The record ends with spare positions. The End of file record is the last record of an In-payment file. Service bureau information and production date precede the total number of inpayment and total sum of these in-payments. As earlier, the file ends with spare positions allocated for future need. In addition to the information described in above paragraphs, each and every one of the In-payment file records begins with a record type code. Moreover, all records of Postgirot files of al types are framed with file management records that for example contain the result of the seal (integrity checksum) calculation, source and destination identifier information, customer number (of the sender, in this case) the number of records, filet type and production date.

4.8 Invoice Payment Files Invoice payment service provides customers a way to pay bills. An invoice payment file always begins with a header record and terminates with a sum record. One such file forms a so called production unit and the production unit may consist of one or more production blocks. A production block always has same customer, same sender account, account-pocket and payment currency. One file may contain several customer numbers and production numbers. The header record contains the customer number, which is allocated to the customer by Postgirot., production date, which is date when the sender created the file. In the end stands production number, the meaning of which is

38

to individualize several production units sent within same day. If the production number is not unique within the day, the bank considers the file to be received already and the file is discarded. In the end of a header record are spare positions reserved for future use. A sender record follows the header record in an invoice payment file. It contains the customer number, payer account, payer code and payer descriptions. After these fields follows the currency pocket used and the currency of the payment. The return account is given if the customer wants that undelivered (redeemed) payments will be returned to another account instead of the payer’s account.

4.9 Security 4.9.1 Denmark The Danish implementation of the authentication and integrity protection security functions depend on the customer’s choice of the file transfer product (chapter 3.1.1). The Unitel EDI and Corporate EDI Gateway programs, which employ file transfer functionality, follow more or less the United Nations’ solution for financial EDIFACT file protection with the help of AUTACK messages (United Nations 1.4.1999). However, the security solution of the Unitel PC program relies on a simple MAC computation scheme (Borkenfelt 27.10.2003; Frank 19.2.2003). According to Borkenfelt, the Corporate EDI Gateway program implements AUTACK messages as defined by SWEDI Finans in (SWEDI Finans 1999) Moreover, the hash value of the EDIFACT interchange is computed with SHA-1 hash algorithm, which is defined in ISO standard 10118-3. As opposed to the contents of the above standard, the Nordea implementation does not pad empty interchange message fields. The hash result is then feed as an input to the RSA algorithm to produce the customer’s digital signature. The RSA is a public key algorithm and the customer uses its private key to derive to the signature. The binary result is converted into ASCII code before substituting the value into the corresponding AUTACK message field. The AUTACK message is sent along with the protected interchange to the bank (Nordea 19.5.2003). The hashing with SHA-1 algorithm requires a shared secret. On the other hand, RSA utilizes a private key-public key pair. The customer produces the signature with his private key and the bank verifies the signature with the customer’s public key. Together these two provide both integrity control and authentication. The customer itself is responsible for the production and storage of the public-private key pair. The key length is defined to be 1024 bits. The public key will be delivered by email to the bank and the private key is to be stored securely in the customer’s computer system. The secrecy of the private key is

39

essential, so the customer must take appropriate measures to prevent unauthorized access to the key storage (Nordea 19.5.2003). As mentioned earlier, the Unitel EDI uses AUTACK messages to protect interchanges. However, DES algorithm with symmetric keys is used to calculate hash values and MAC values from corresponding hashes. The software that performs the calculations is called EDI security and transportation module and the bank delivers it on CD-ROM media to the customer. The necessary secret key is sent via mail in two parts. The key exchange period is one year (Nordea March 2003). Unitel PC utilizes MAC computation with DES algorithm in authentication and integrity protection (Borkenfelt 27.10.2003). 4.9.2 Finland The banks operating in Finnish banking industry share a common security framework for data transfer between the customer and the bank. This standard covers the procedures for authentication, integrity control and key management. The standard has been developed by the Finnish Bankers’ Association and is referred after its name as PATU security standard (Finnish Bankers’ Association 9.5.2001). In the rest of this chapter, we briefly explain the basic idea of PATU and describe the key management as defined in the standard. Then we discuss authentication and integrity protection functions in corresponding subchapters in more detail. The security functions are based on a cryptographic algorithm defined in the ISO 8731-1 standard, namely the Data Encryption Standard (DES) algorithm. The current PATU version uses MAC values computed by DES algorithm and symmetric secret keys. The principal property of a MAC is that a message cannot be altered without affecting its MAC value. It is also impossible to calculate correct MAC value if one does not know the secret key used in the computation. In PATU standard, the MAC value is computed twice and the result of the first computation is called a hash value and the second result is called an authentication value, correspondingly. These hash values and authentication values are placed in special security messages. There are four different types of these messages: identification message (ESI), security header (SUO), security trailer (VAR) and response message (PTE). All messages have a fixed structure, which consist of a common initial part and a message specific extension part. The acronyms of the message names are listed inside brackets after each name. The PATU security standard utilizes keys of three types: Key Exchange Key (KEK), Authentication key (AUK) and Hashing Key (HSK). All the keys are shared secrets in nature, but they are used for different purposes. The KEK key is used to encrypt the two other keys, the authentication and hashing key, during data transfer. The Bank delivers the KEK key to the customer in two distinct pieces, on two different days via ordinary mail. From these two pieces

40

the customer computes the actual KEK via XOR operation and bit parity control. The authentication key is needed when calculating the authentication values of the security messages. The customer derives the first AUK key in his own software by encrypting a 16-bit binary zero with the DES algorithm. The parity of the result of the encryption operation is set to odd and so the customer’s first AUK key is ready to use. The bank issues the following generations (i.e. subsequent versions of the AUK key) and delivers them inside the security messages. The AUK key exchange may take place either from the bank’s or the customer’s initiative. Naturally, the new AUK key is encrypted with the current KEK in use to protect it during transfer. The hashing key is used in hash value computation. The hashing key is unique for every computation and always random in content. A new HSK key is used every time an entity is to be protected. The only key customer handles manually is the KEK key. Hashing keys are generated by the customer’s banking program (which has to be PATU compliant). Neither the PATU standard nor Nordea policies state how the customer generates the key that is needed in the HSK key value computation.

Authentication The customer and the bank must mutually authenticate themselves before any files can be sent or received. The identification and authentication are implemented with ESI identification messages. ESI messages may be sent individually before actual file material or they are added to the batch file and feedback messages exchanged between bank and the customer (Finnish Bankers’ Association 9.5.2001). The followed procedure depends on whether connected or connectionless data transfer is used. The customer first computes an ESI message in its computer system. Then the customer establishes a data connection to the bank and sends the ESIc (c standing for customer) message to the bank. The ESIc message is checked and verified in the bank, after which the bank replies with its own ESIb (b standing for bank) message. The ESI message contains information that identifies both the sender and the receiver of the message, key generation information and a unique time stamp. It also contains an authentication value, which is computed as follows: all fields of the ESI message preceding the authentication value field are DES encrypted with the AUK key. The resulting cipher text is the authentication value. The customer should verify the bank’s reply in its computer system immediately, but the customer can also store the ESIc message and check it later. If the customer and the bank have exchanged ESI messages and verified their contents successfully, the customer may start to send and retrieve files (Nordea August 2003).

41

A virtual private network connection is recommended if the customer wants to initialise an ftp-connection to the bank over a public TCP/IP network. The VPN encrypts and tunnels the traffic between the customer and the bank, but the VPN-solution agreed between the members of the Finnish Bankers’ Association does not provide reliable mutual authentication between the customer and the bank. Therefore, the ESI handshake procedure is still needed although the customer connects over a VPN (Nordea August 2003).

Integrity Protection The PATU security standard (Finnish Bankers’ Association 9.5.2001) offers integrity control over the file transfer between the customer and the bank. Integrity means, that a message cannot be altered, either intentionally by malicious users or because of a bit error during transfer, without the change to be noticed. The PATU security standard enables integrity protection both when sending and receiving files, but in Nordea, integrity protection is utilized only when customer sends material to bank. Moreover, the protection is not compulsory, and the customer and bank agree on which file types are to be protected. After the contract is signed, protection becomes mandatory from that date on, and bank rejects at arrival those file types not protected although agreed so. The message types used in integrity control are security header (SUO), security trailer (VAR) and response message (PTE) (Finnish Bankers’ Association 9.5.2001). The concept of security message is introduced in the previous chapter. The batch file sent to the bank may be protected as an entity or each message group separately. In connected data transfer, the batch is always protected as a whole whereas in connectionless transfer both ways mentioned above are possible. A protected entity is placed between SUO security header and VAR security trailer. The bank sends a receipt of reception to the customer from each protected entity in a PTE message. However, the customer does not acknowledge the files it receives from the bank. During a single integrity calculation procedure, the customer generates a unique HSK encrypted with the KEK and places it into the SUO message body. Then the customer sends the SUO message to the bank. Next the customer computes a hash value from the whole batch file using a DES encryption algorithm for Message Authentication Code method (MAC) calculation. After that, the actual batch file is sent unencrypted to the bank and the VAR security message is formed. The VAR message contains a reserved field for the hash value. After the hash value is placed to the VAR message, an authentication value is calculated. The authentication value computation goes as follows: Data Encryption Standard (DES) algorithm is used to calculate a Message Authentication Code (MAC) over the characters of the VAR message that precede the

42

authentication value field. The MAC calculation key is the shared secret AUK. Note that the customer handles manually only the KEK key. To sum up, the hashing key HSK encrypted with KEK, hash value, and authentication value encrypted with AUK are transmitted together with message sender, message receiver and software information. 4.9.3 Norway The Norwegian customers select between host-to-host communication with the bank’s Interpay system and K-link client program. The security implementations of these alternatives differ from each other. Interpay utilizes file sealing functionality, which in practice means MAC value calculation with SHA-1 hashing algorithm and MD5 MAC algorithm from the files. This provides authentication and integrity protection. The K-Link users are authenticated with digital one-time codes. The customers are given a physical token, Digipass and it is used in a challengeresponse scheme. Only the SSL connection is authenticated with challengeresponse, not individual files (Knudsen 18.12.2003). 4.9.4 Sweden Several solutions for authentication and integrity control exist in Sweden. Basically, all of them are called file sealing, and they are based on checksum computation or digital signatures with the help of some secret or token. Next, the alternative techniques are introduced briefly. Giroprotector and SäkData utilize symmetric techniques similar to PATU security standard described in chapter 4.9.2. The bank delivers symmetric keys to the customer via mail. The keys are changed every 30th day by default. The computation takes place in the client application in both Giroprotector and SäkData cases. The Giroprotector is a Nordea implementation and is based on an algorithm defined in ISO 8731-2 standard. The SäkData is a third-party implementation and comprises a proprietary algorithm. The message seal, i.e. the checksum is sent along the file, of which the seal is supposed to protect. These two solutions are utilized when a hostto-.host and modem connections are used in data transfer, because web browser interface is not supported. In addition, smart card and PKI based sealing solutions are available. Smart sec is a Java application running on a web browser session. Nordea delivers the customer a smart card. Then, the MD5 hash algorithm is used to calculate a 128-bit seal of the target file, while the smart card holds the key needed in the computation. The seal value is transmitted together with the file. In the PKI solution, a MD5 hash is calculated from the file first. Then the hash value is signed with the customer’s private key. This result is sent along the original file (Schwab 17.12.2003).

43

5

Analysis of the File Transfer Systems

This chapter presents an analysis of the file transfer systems of Nordea bank depicted in this study. These systems are composed of three parts: the customer’s computer environment, data communications and the bank’s systems. Because the bank cannot control the operations of its customers’ systems, the analysis of customer computing environment, its physical security and the correctness of the produced file material, are left out of this analysis. The analysis of the file transfer systems is difficult to conduct, because neither any complete system designs nor evaluation methods or evaluation criteria for file transfer system exists in the literature. Therefore, the analysis concentrates on the properties of the individual parts of the systems separately more than on all of them as a whole. The analysis is based on the requirements model presented in chapter 2 and the properties listed in the subchapter 2.5.2. This chapter is divided into three main sections. First, we analyze the bank’s systems. This covers authentication, audit trail, customer authorization and event logging functions. Next, we will analyze the communications requirements including availability, encryption and information integrity. Key management is also considered whenever suitable, because key management is necessarily needed when implementing authentication, encryption and integrity protection functions. In the corresponding subchapters, each of the four countries is evaluated as an entity. We discuss how the country-specific file transfer architectures fulfill the requirements described. At the end of each part, a short summary is provided to help comparison between countries. The summary is presented in a table form to make its presentation as clear and formal as possible.

5.1 Bank’s Systems The bank site is responsible for authentication and authorization of a customer, establishing an audit trail and logging system events. The following subchapters present how these aspects are handled in each country. 5.1.1 Denmark All Danish customers are authenticated by the bank. However, the ways in which the authentication is performed and the authentication methods used vary. The authentication of the customers using Corporate EDI Gateway or Unitel EDI is based on AUTACK messages. The syntax of these AUTACK messages is similar to that of the EDIFACT AUTACK, but with some modifications. Customers with Unitel PC program are authenticated with the

44

help of a MAC value and this MAC is produced as an output of DES algorithm. Same AUTACK messages and DES-MAC are used in integrity protection. The more detailed description of these methods can be found from chapter 5.2.1. The authentication is unilateral, meaning that only bank authenticates the customer but not vice versa. All algorithms used are well known and have existed a good while. The bank delivers the necessary keys to the customer via mail in two pieces. The keys are changed to new ones in the same way. What comes to the management of public keys, in practice the customers are responsible for key management related activities. These activities cover creation of keys, storing the private key and the delivery of the customer’s public key to the bank. The bank gives each customer a unique customer number. The authorization of customers is based on this number and it is included in a corresponding field in all types of files and messages. The customer number is assigned to a company, not to an individual employee of the company. The authorization procedure does not provide any privilege segregation. However, the authorizations are identified with the help of payment agreement databases. This means that once customer has only access to services of which it has agreed with bank. The collection of event log and audit trail information is throughout and thereby satisfies the requirements. 5.1.2 Finland The authentication relies on the implementation of PATU security standard, which is described in chapter 4.9.2. The standard provides a mutual authentication between the bank and the customer. The authentication is performed by exchanging ESI security messages that contain specific authentication values. These values are obtained by DES computation. The DES algorithm is well known and it utilizes symmetric keys. The standard provides also unambiguously defined key management procedures. The customer authorization is carried out in similar manner as in Denmark. The unique customer numbers are included in each file type. The file transfer system performs a mapping between the customer numbers and payment agreements to find out the corresponding authorizations. The customer number-payment agreement linkage does not provide authorization on user lever. Privilege segregation is not implemented. The log files and file transfer surveillance files establish audit trail and event logging in certain scale. The connection opening and closing times, of, error situations and executed commands together with related time stamps recorded on the log file. Complementarily, file transfer surveillance saves status of the processed data. The studied documentation does not tell whether the accessed resources are written on the log file. However, all but one item of the ISO recommended event log and audit trail information is considered and recorded.

45

5.1.3 Norway Authentication is mandatory for all customers in Norway. The authentication method depends on product the customer has chosen. K-Link user’s connection over SSL is authenticated with challenge-response method. The bank delivers customers physical tokens, which are then used to calculate the response. In the Interpay system the customer’s and bank’s mainframe hosts communicate over a modem connection. The authentication s performed with secret keys, which the bank has delivered to the customer via mail. The key is entered into the customer host and the used in a challenge-response type handshake. The K-Link SSL session authentication is mutual, because both ends of the connection are authenticated. In the case of Interpay, only the bank authenticates the customer and thus the authentication is unilateral. Wellknown algorithms SHA-1 and MD5 are used. The key management is handled manually via mail. The Digipass tokens are third party products, which are delivered to the customer via bank. The authorization is based on customer numbers and similarly as in Denmark and Finland, the authorization is performed on customer level. Privilege segregation is not in place, but identification of authorizations is implemented via payment agreement database. The bank provides a feedback of the file transmission. All required details of transactions are logged, which makes the audit trail concise. 5.1.4 Sweden In Sweden the authentication is carried out with MAC values of the files. It provides unilateral authentication, where the bank authenticates the customer. Because same MACs are utilized in integrity protection, the details of algorithm properties are identical to those described in chapter 4.9.2. The bank is responsible for delivering symmetric keys to the customer via mail. Customer authorization is identical to the cases of Denmark, Finland and Norway above. Authorization is based on customer numbers and identification of authorizations is implemented with payment agreements. Executed transactions and error situations are logged with relevant time stamps together with corresponding system start and finish times. Also the output of data processing is recorded on the log. The audit trail chain is complete. 5.1.5 Summary Authentication is implemented each of the four countries and it is mandatory for all customers. Symmetric and well-known algorithms are used in all countries. However, there are two exceptions from this rule of thumb. Danish

46

Corporate EDI Gateway customers are authenticated with a method based on PKI. The Swedish SäkData authentication method contains a proprietary algorithm. Any details of this algorithm are not available. Key management is handled more or less manually via ordinary mail in all of the four countries. Only Finland has standardized and uniform key management procedure that covers all customers. Authentication related differences and similarities are illustrated in Table 5 below. Denmark Service availability Algorithm publicity

Algorithm category

Authentication Finland

Norway

Mandatory

Mandatory Mandatory

Mandatory

Yes

Yes

Yes/ Giroprotector

Public-key/ Corporate EDI GW

Symmetric

Yes

Symmetric

Symmetric/ Unitel PC Yes/Corporate EDI GW

No/ SäkData Symmetric/ Giroprotector Unknown/ Säkdata

Symmetric/ Unitel EDI

Key management

Sweden

Yes

Yes

Yes

Mutual

Mutual/ K-Link

Unilateral

Yes/Unitel EDI Mutual/ Unilateral

Yes/Unitel PC Unilateral

Unilateral/ Interpay Table 5: Summary of authentication components. Customer authorization is performed identically in all the four countries. Customers are assigned wit a customer number and the authorizations are kept in payment agreements. Authorizations map with customer numbers. Customer authorization constitutes a mandatory part of the file transfer procedures (see Table 6).

47

Service implmented Authorization level Privilege segregation Identification of authorizations

Customer Authorization Denmark Finland Norway Mandatory Mandatory Mandatory

Sweden Mandatory

Customer

Customer

Customer

Customer

No

No

No

No

Yes

Yes

Yes

Yes

Table 6: Summary of customer authorization. The audit trail and event logging procedures are well in place in all of the four countries. All main details according to ISO’s recommendations are recorded. Major differences could not be found in the comparison and the level of details in logging seems to be very similar in all countries. We could explain this with the strict legislation that dictates the importance of audit trail in banking.

Service implemented Date/time stamp Executed transaction Accessed resources

Denmark Yes

Audit Trail Finland Yes

Norway Yes

Sweden Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

No

Table 7: Summary of audit trail.

48

Denmark Yes

Service implemented System start and finish times Error logging Data processing output logging

Event Logging Finland Norway Yes Yes

Sweden Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Table 8: Summary of event logging components.

5.2 Data Communication The communication requirements consist of availability, confidentiality and information integrity. Availability means that services are available for authorized users at their will. The availability includes disaster recovery planning, assignment of duties and definition of recovery processes. The analysis, however, examines the service availability in terms of system backupping and leaves the organizational side of the disaster recovery out of scope. 5.2.1 Denmark The Danish architecture does not concern availability issues. The validated transactions are stored in Unitel payments database, but documentation does not reveal any database for customer files as such. Integrity protection mechanisms depend on the product the customer uses. Those who send files in EDIFACT format, produce certain authentication messages to be sent along the file. The structure and contents of these AUTACK messages is defined by United Nations in (United Nations 1.4.1999). The Danish implementation follows the SWEDI Finans’ specification, where hash value is computed with SHA-1 algorithm and then signed with RSA digital signature. The customer itself has to take care of the creation of the private-public key pair. The public key is delivered to the bank via email. Unitel EDI and Unitel PC customers need secret keys for integrity protection. Unitel EDI customers send AUTACK messages along the files, but authentication is handled with a MAC value. Users of Unitel PC calculate MAC value from certain fields of the transmitted files. Both Unitel EDI and

49

Unitel PC MAC values are computed with DES algorithm and the keys needed are delivered and exchanged via ordinary mail. 5.2.2 Finland As stated in chapter 3.2.4, the batch files the customer sends are saved in a customer-specific file into a database. In addition to that, the files are given unique names and their status is written on a log file first time at reception. This procedure enables back upping of customer’s transaction data and promotes availability. The Finnish banks share a common security standard, PATU, which defines procedures for authentication and integrity control. The PATU standard specification (Finnish Bankers’ Association 9.5.2001) states that the part concerning encryption function is not in use. The bank recommends that ftp-connections established over open TCP/IP networks should be protected by tunneling the traffic over a virtual private network connection. The usage of a VPN enables encryption with IPSec/IKE protocol. However, usage of VPN is up to the customer and requires an investment into commercial VPN client software. The bank’s systems do not support encryption in other ways. Information integrity is implemented with security messages defined in PATU standard. Integrity protection is not mandatory and the customer agrees on integrity control per file type with the bank. The integrity protection is based on hash and MAC values that are calculated with DES algorithm defined in ISO 8371-1. The integrity protection procedure is well defined and standard for all customer and file types. The keys are shared secrets (64-bit DES keys with parity set to odd) of three types. Customers have to handle only key exchange keys. The hashing key is produced in customer’s software and bank issues the third keys that are used for authentication of the PATU messages. Time stamps are used to hinder replay attacks. The bank does not offer or recommend any time stamping services, although they are produced in the customer’s software. 5.2.3 Norway The Norwegian systems consider confidentiality and integrity protection. The integrity protection is implemented with MAC calculation, which is called SIGILL in Norway. However, the customer is free to choose not to use MACs. In that case, the bank takes no liability on the integrity of the delivered files. 5.2.4 Sweden The studied Swedish documentation does not discuss availability issues at all. There are several communication and banking program alternatives. Only the browser-based GiroLink via Internet application addresses confidentiality

50

needs: the data is protected with SSL protocol during its transfer over the internet. Several integrity protection mechanisms are available: Giroprotector and SäkData products. They are based on MAC calculation with symmetric keys. Giroprotector is based on ISO 8731-2 algorithm but SäkData contains a proprietary algorithm. The keys are delivered to the customers from the bank to the customer via mail every 30 days by default. In the Smart Sec smart card solution, the bank delivers the customer a smart card token, which is used in MD5 hash value calculation. There exists also a PKI mechanism for integrity checksum computation. Again, MD5 is the computation algorithm, but we are not able to say anything about the key management. The reliability of the PKI solution rests on the secrecy of the customer’s private key. It is on customer’s responsibility to conserve the secrecy. 5.2.5 Summary

Data back-ups

Denmark Yes

Availability Finland Yes

Norway Yes

Sweden Yes

Table 9: Summary of availability components.

Service availability Algorithm publicity Algorithm category Key management

Denmark Optional

Confidentiality Finland Norway No Mandatory

Sweden Mandatory

Yes

N/A

Yes

Yes

Symmetric

N/A

Symmetric

Symmetric

Yes

N/A

No

No

Table 10: Summary of confidentiality components.

51

Service availability Algorithm publicity Algorithm category

Information Integrity Denmark Finland Norway Mandatory Optional Optional

Sweden Mandatory

Yes

Yes

Yes

Public-key/ Corporate EDI GW

Symmetric

Symmetric

Yes/Giroprotector No/SäkData Symmetric

Yes

Yes

Yes

Yes

No

No

No

Yes

No

Yes

Yes

Yes

No

Symmetric/ Unitel EDI

Key management

MAC

Symmetric/ Unitel PC Yes/Corpor Yes ate EDI GW Yes/Unitel EDI Yes/Unitel PC No/Corpora Yes te EDI GW Yes/ Unitel EDI

Digital signature Time stamps

Sequence numbers

Yes/Unitel PC Yes/ Unitel EDI GW Yes/Unitel EDI GW No/ Unitel EDI No/ Unitel PC Yes

Table 11: Summary of information integrity components.

52

5.3 Customer’s Environment The customer’s computing environments vary in size, in their purpose and configuration. This makes them a complex factor that has an impact on the file transfer services. The bank can, and will, give instructions and recommendations on the configuration of the customer’s environment. For example, (Nordea 2003) states that the customer’s system must not interfere with or prevent the usage of the bank’s services. In practice, the customer is obliged to follow the standards recommended by the bank in order to be able to use file transfer services. However, because the bank has no direct control over any customer systems, we leave it out of the rest of this study.

53

6

Future Trends

This chapter discusses development trend lines of the file transfer services. First, the lately emerged needs and the motivation for changes are presented. Then some related technologies, namely XML and Web Services, are introduced shortly. The latter subchapter 6.3 concentrates on the current important topic at Nordea Bank, the integration and consolidation of services.

6.1 Introduction The study conducted in the preceding chapters implies, file formats, communication protocols and authentication methods might be interdependent. To illustrate the existence of this dependency, we give some examples: The algorithms used in the authentication of Danish customers depend on their choice of the banking program. The program used dictates also the file formats available. On the other hand, the Norwegian Interpay and K-link customers have different data communications to the bank, as well as separate authentication procedures. The consequence from these dependencies is that the number of combinations of formats, protocols and authentication methods is very large. In practise this means that the bank must maintain numerous systems, processes and data storages. Moreover, as services and technologies evolve, the bank should be able to add new services on the top of its current systems. One major part of this thesis’ problem statement has been the complexity of Nordea Bank’s file transfer system. The complexity cannot grow without it affecting to cost-efficiency and system maintainability. Therefore, in the future development of file transfer services, attention should be carefully paid on to keep • File formats • Protocols and • Authentication independent of each other. The customers’ computer environment brings a second factor to the complexity issue. The environments have various operating systems, mass memories (i.e. hard disks, zip drives etcetera), processing capabilities and communication links. Basically, the customer is responsible for that its systems are compatible with the bank’s site. However, the need for support of different computer environments has lead to the development of many different client programs, of which the bank or third party producers then offer to the customers. The question of complexity and cost-efficiency arises again,

54

because these clients have to be configured to fit into a certain environment with unique parameters. They are also likely to be updated along the time. Therefore, the customer clients should be easily configurable and standard in a certain sense. Nowadays the customers also handle key information manually. Most of the studied authentication and integrity protection methods utilise symmetric cryptography where the secret keys are delivered via mail to the customer. The key management activities should be further automated and brought the minimum, because this can simplify their implementation in the bank’s system. To sum up the considerations presented above, we can list the desirable properties of the client programs in the following manner: • Configurable • Standard • Automated key management procedures.

6.2 Technologies The wed-based applications and services together with web-browser user interfaces have become more and more widely used in recent years. Also in the banking services, the trend is toward more and more versatile netbank services. The following subchapters introduce two concepts, XML and Web Services, which could be used when striving for simplicity and cost-efficiency in upcoming file transfer services. 6.2.1 XML XML stands for eXtensible Markup Language and it has been developed to enforce creation, transformation, validation, storing and processing of data in internet environment (Ahokas 2003). Actually, XML is an application of Standard Generalized Markup Language (SGML), which in turn is a language for defining other markup languages (W3C1) The World Wide Web Consortium (W3C) designed XML to be as usable and straightforward as possible, although XML can support a wide variety of applications. As another advantage, its syntax is formal and human-intelligible (W3C2). The primitive concept in XML is a tag. XML is a combination of tags and content, and the tags give meaning to the content. In other words, XML is a description of data and its meaning. XML does not have any pre-defined set of tags, and therefore it can be thought as a language used to define other languages (Ahokas 2003). One creates its own language, when one defines the set of tags to be used. One should notice that XML forms a standard for the presentation of data. EDIFACT, on the other hand defines a standard for both the

55

presentation of the data and the content of the data. This is the primary reason which makes XML potentially useful in file transfer services. With XML the data contents of the files can be kept independent of the file format. Transferring XML messages does not dictate any particular communication protocol to be used (Ahokas 2003). Thus we are able to reduce the number of file formats and moreover, separate protocols and formats. This will lead to reduced complexity. 6.2.2 Web Services The phrase web services has multiple interpretations. It can mean services built on XML based standards (Ahokas 2003; W3C3) or it can be associated with host-to-host communication in web environment, where human interaction is not needed (Ahokas 2003). Independent of the interpretation the term web services, a couple of XML based standards strongly related to it. These standards are Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL) and Universal Description, Discovery and Integration of Web Services (UDDI) (W3C3). SOAP is a platform independent communication protocol used by web applications to exchange information. (Ahokas 2003). It is developed by W3C and aimed to be the standard for accessing web-based services (W3C3). WSDL is basically an XML document, which declares the location and operations of a web service. In other words, it describes where a web service is located, how it can be accessed and what functionality the web service is able to provide (Ahokas 2003). UDDI is framework for registering web services, finding registered services and publishing information on the internet. UDDI constitutes a directory, which stores WSDL documents and uses SOAP to respond to external application’s document request. In practice, UDDI provides a way to register public information about organizations and the services the provided by the organizations (Ahokas 2003). 6.2.3 Applications Next we give an example on how web services could be utilized in file transfer services. As discussed earlier, configuration of the clients and partially manual key management are current problems. An application running on a customer client could first use WSL to locate Nordea’s file transfer web services. At the bank’s end, configuration or client update script files are stored in an UDDI directory. Communicating with SOAP, the client can automatically retrieve a suitable configuration script and run it locally and thus automatically achieve proper configuration. XML offers also digital signatures and encryption of XML documents (W3C4; W3C5). If signatures are used for authentication and integrity control, same kind of scenario as above could be used to deliver customer’s public keys

56

to the bank in PKI based security functions. If we add encryption to this, also secret keys could be transmitted in XML format.

6.3 Integration versus Consolidation The Oxford English Dictionary (OED) defines integration to be: 1) “composition of a whole by adding together or combining the separate parts or elements –“or “the combining of diverse parts into a complex whole”. On the contrary, the dictionary gives the following explanation for the word consolidation: “The merging of two or more actions in order to avoid the expense and delay arising from the trial of a multiplicity of actions upon the same question”. So far, the bank has mainly combined its services and the technologies, platforms and processes constituting these services. This system integration increases complexity, makes maintenance more difficult and thus increases costs. According to (Kanerva 2003) the bank strives for a structure, where it has only one handling process, one agreement system and one point of management per business process. In this context, the business process means one type of service. For example payments, e-invoicing and payment terminal transactions are separate business processes each. Correspondingly, single point of management should cover management of customer support, managerial actions and system development and maintenance. To achieve this goal, the bank must consolidate its services. Practically consolidation means merging of systems, technologies and platforms. This can be done through discarding some current solutions and replacing them with some other existing ones or by replacing a set of current solution with a common new one. Some of the currently used systems and technologies are almost thirty years old. They store or run business-critical information and they cannot be easily replaced. This means that systems cannot be consolidated at once, but in smaller steps. In practice, one would construct some kind of common file transfer front-end based on existing file transfer architecture. This would tie the current file transfer system together in way that seems to be uniform from the customers’ perspective. The final joint file transfer system might be either a wholly new architectural solution or a one of the current ones. However, that is not a matter of this study, but a subject for further research.

57

7

Conclusions

The objectives of this Master’s thesis work were to study the various file transfer services within Nordea Bank and describe the underlying architectures from technical perspective. The architectural overviews together with customer telecommunication were studied as detailed as possible. However, at some points the extraction of technical information has shown to be very challenging. The study could have been more in depth without these problems. Because a suitable comparison criterion from literature was not directly applicable to the case at hand, we have created a model of our own for evaluation purposes. The model is based on national legislative regulations and on ISO and BSI standards. The main goal of this thesis was to find and point out the main differences and similarities between the country-specific solutions. The lack of standardization and useful process model in banking industry has brought up many different technical solutions along the years. Therefore, the number of end-user products is large. The systems examined are highly versatile, but certain similarities could still be found. They use Message Authentication Codes to control integrity of files. In Denmark and in Sweden integrity protection is mandatory, in Finland and in Norway the customer can decide whether to use integrity protection mechanisms or not. Customer authorization is one of the primary controls in all of the systems of this study. Authorization is carried out in a similar manner in all of the four countries. Authorization is performed per corporate instead of per individual users. The authorizations are tied to customer numbers, which the bank assigns to the customers. All systems address audit trail and availability issues carefully. Based on the material available in this study, the audit trail and event logging procedures appear to be concise and throughout, satisfying the ISO recommendations. Another common denominator for all countries is the use of symmetric cryptography. Symmetric techniques are utilized in customer authentication as well as in integrity protection. Nordea Bank Denmark forms and exception of this rule as it uses public key cryptography in authentication of Corporate EDI Gateway customers. Key management is essential for the implementation of authentication, integrity protection and confidentiality. In most cases the key management is handled in somewhat manual way as the keys are delivered to the customer on piece of paper via ordinary mail or by email in the case of Danish corporate EDI gateway customers. In Finland, the PATU security standard defines more automated key management procedures, where keys can be exchanged programmatically.

58

It is clear that the file transfer systems must strive for uniformity. The current complexity of systems makes maintenance difficult and increases costs. XML and Web Services are potentially exploitable technologies in the future. Management of cryptographic keys could be automated with these technologies. Moreover, the bank could easily offer configuration services for customers’ client programs, and thus benefit from the more standardized client environment as the complexity reduces.

59

References Ahokas, Timo. 2003. Using XML In Making Legacy Application Data Accessible Through Web Services. Masters’ Thesis, Helsinki University of Technology. Andersson, Dennis B. and Haglund Sven-Olof. 5.12.2003. Interview. Anonymous. 2003 Authorization – a searchSecurity definition. (online). (Referred14.11.2003). http://searchsecurity.techtarget.com/sDefinition/0,,sid14_gci211622,00. html Anonymous2. 2003. SHS Acronym (online). (Referred 24.11.2003). http://www.hiddenlab.com/acronym/acrowebS.htm Bankenes Standardiseringskontor BSK. 28.10.2003. The Telepay Format. Nordea Bank Norway Version 2.0. (on-line). (Referred 28.2.2003). http://www.bsk.no Borkenfelt, Nina. 20.10.2003. Interview. Borkenfelt, Nina. 27.10.2003. Concept for ERP Integration in Nordea DK. Presentation material. Nordea Bank Denmark. Borkenfelt, Nina. 3.11.2003. Interview. Borkenfelt, Nina. 11.12.2003. Interview. BS 7799. 1995. Code of practice for Information security management. London: British Standards Institution. Danish Bankers’ Association 2003. The Danish Banking System 2002/2003 Edition (online). (Referred26.10.2003). http://www.finansraadet.dk/finansraadet/finans.nsf/HTMLdokumenter/index_facts/download.pdf. Finlex 2003. Valtion säädöstietopankki (online). (Referred 22.10.2003). http://www.finlex.fi/lains/index.html. Finnish Banker’s Association. 1.6.1999. POPS-järjestelmän katteiden välitys järjestelmäkuvaus v2.0 Finnish Bankers’ Association 9.2.2001. PMJ-katteensiirto järjestelmäkuvaus v3.1.

60

Finnish Bankers’ Association 9.5.2001. PATU Security Functions for Data Transfer between Customer and Bank. Part 1: Procedures for Authentication, Integrity Control and Key Management (online). (Referred18.12.003). http://www.pankkiyhdistys.fi/sisalto_eng/upload/pdf/patu122e.pdf Finnish Bankers’ Association 13.5.2002. Point of Sale System: A Functional Description. Version 2.2. Frank, Morten. 19.2.2003. Unitel system overview with perspectives. Presentation material. Nordea Bank Denmark. Frank, Morten. 20.10.2003. Nordea File Box Architecture Investigation and Decision Process. Presentation Material. Nordea Bank Demark. Hinsch, Bethany. 2003. ACF2 mainframe security (online). (Referred 17.1.2004). http://www.giac.org/practical/GSEC/Bethany_Hinsch_GSEC.pdf. Häkkinen, H. 25.9.2002. Nordea Finland Offered local solution at the moment. Presentation material. Nordea Bank Finland Plc. ISO IS 8730. 1990. Banking – Requirements for message authentication (wholesale). International Organization for Standardization. ISO/IEC FDIS 9797-1. 1999. Information technology – Security techniques – Message Authentication Codes (MACs) – Part 1: Mechanisms using a block cipher. International Organization for Standardization. ISO/IEC DIS 9798-1. 1996. Information technology – Security techniques – Entity Authentication – Part 1: General. International Organization for Standardization. ISO/IEC DIS 9798-2. 1997. Information technology – Security techniques – Entity Authentication – Part 2: Mechanisms using symmetric encipherment algorithms. International Organization for Standardization. ISO/IEC DIS 9798-3. 1996. Information technology – Security techniques – Entity Authentication – Part 3: Mechanisms using asymmetric signature techniques. International Organization for Standardization. ISO/IEC DIS 9798-4. 1996. Information technology – Security techniques – Entity Authentication – Part 4: Mechanisms using cryptographic check functions. International Organization for Standardization.

61

ISO/TR 13569. 1997. Banking and related financial services – Information and security guidelines. Switzerland: International Organization for Standards. ISO/DIS 15668. 1998. Banking – Financial transaction cards – Secure file transfer (retail). International Organization for Standardization. Kanerva, Pekka. 16.12.2003. Interview. Knudsen, Geir Atle 2003. Interview. Merita Pankki Oyj. 16.5.2001. Solo-eräsiirto. Järjestelmäkuvaus. NIST SP 800-9. 1993. Good Security Practices for Electronic Commerce, Including Electronic Data Interchange. Washington: National Institute of Standards and Technology. (online). (Referred 22.10.2003) http://csrc.nist.gov/publications/nistpubs/800-9/800-9.pdf NIST SP 800-934. 1993. Contingency Planning Guide for Information Technology Systems. June 2002. Washington: National Institute of Standards and Technology. (online). (Referred 22.10.2003) http://csrc.nist.gov/publications/nistpubs/800-34/sp800-34.pdf. Nordea Bank Finland. August 2003. File Transfer service description (online). (Referred29.9.2003). http://www.nordea.fi/fin/yri/tuki/soloerasiirto.asp?navi=kasikirjat&ite m=soloerasiirto Nordea Bank Finland. June 2003. Bill Payment Service Description (online). (Referred6.10.2003) http://www.nordea.fi/liite/e/yritys/pdf/lmp_kasikirja.pdf Nordea. 19.5.2003. Corporate EDI Gateway. Security and Communication description. Version 0.8. Nordea. 22.8.2002. Corporate EDI Gateway. Information and Message Flow. Nordea. 7.7.2003. Corporate EDI Gateway. User guide for EDIFACT implementation guides. Version 1.8. Nordea 9.1.2003. K-Link 7.00 User Manual. (online). (Referred 15.12.2003). http://www.nordea.no/klink. Nordea 4.12.2003. Deposit & Payment Systems – System Overview. Presentation material. Nordea 10.3.2003. K-Link System overview with perspectives. Presentation material.

62

Nordea March 2003. Unitel EDI. EDI sikkerheds- og transportmodul. Service description. Nordea. 2003. Yritysten elektronisten palvelujen yleiset ehdot. Postgirot 21.11.2003. GiroLink via Internet. Presentation material. Postgirot 2002. GiroLink och andra datamedia. Allmän beskrivning. Postgirot2 2002. In-Payment Service Record Description. Postgirot 26.4.2002. Postgirots filförmedling och Fantom. Version 1.1. Postgirot 2000. In-Payment Service General Description. Schwab, Johan. 17.12.2003. Presentation av ny säkerhetslösning för Postgirots eTjänster. Presentation material. Nordea Bank Sweden. Suomen Pankkiyhdistys. 5.10.2001. VPN-ratkaisu pankkien ftpasiakasyhteyksille (online). (Referred 7.10.2003}. http://www.pankkiyhdistys.fi/sisalto/upload/pdf/vpnasia.pdf SWEDI Finans. 1999. Message implementation guideline of the UN/EDIFACT secure authentication & acknowledgement message AUTACK. Draft 0.6m. SWEDI Finans. 15.4.2003. Payment Order. Version 2.0. (online) (Referred 30.10.2003). http://www.swedifinans.com. Syrjänen, Niko. 2001. Verkkopankin säännöt ja valvonta – kansainvälinen vertailu. Rahoitustarkastus. (on-line) (referred 22.10.2003) http://www.rahoitustarkastus.fi/suomi/Julkaisut/data/tyopaperit/TP010 2000LLO.pdf United Nations/EDIFACT Finance Group SWG-F D6, 01.04.1999. Recommended Practice for Message Flow and Security for EDIFACT Payments. Valtiovarainministeriö. 2001. Sähköisen asioinnin tietoturvallisuuden yleisohje (VAHTI 4/2001). World Wide Web Consortium. On SGML and HTML. (online). ( Referred 27.02.2004) http://www.w3.org/TR/REC-html40/intro/sgmltut.html World Wide Web Consortium. Extensible Markup Language (XML) 1.0. (online) (Referred 27.02.2004) http://www.w3.org/TR/2004/REC-xml20040204.

63

World Wide Web Consortium. Web Services Activity. (online) (Referred 28.02.2004). http://www.w3.org/2002/ws/ World Wide Web Consortium. XML Signature Working Group. (online) (Referred 28.02.2004). http://www.w3.org/Signature/2001/ World Wide Web Consortium. XML Encryption Working Group (on-line) (Referred 28.02.2004). http://www.w3.org/Encryption/2001/

64

Appendix A This appendix considers authentication mechanisms offered in the multipart authentication standard of ISO. From the alternatives available, we concentrate on techniques utilising symmetric algorithms (ISOIEC DIS 9798-2 1997), asymmetric digital signature techniques (ISO/IEC DIS 9798-3 1997) and cryptographic check values i.e. MACs (ISO/IEC FDIS .9798-4 1999; ISO/IEC FDIS 9797-1 1999).

Symmetric techniques Utilization of symmetric cryptography requires sharing of a secret key between the authentication parties. The authentication is based on the claimer’s demonstration of its knowledge of the secret key ISO DIS 15668 1997). The standard does not define the way in which the authenticating parties share the knowledge of the secret, i.e. how they distribute the key to each other (ISO DIS 15668 1997; ISO DIS 9798-2 1997). The authentication mechanisms demand the use of time variant parameters such as time stamps, sequence numbers or random numbers to prove the uniqueness of messages and to protect the authentication procedure against replay attacks. Random numbers require one pass, i.e. one message exchange, more to complete authentication when compared to sequence numbers or time stamps (ISO DIS 15668 1997). Unilateral authentication One pass authentication The verifier B authenticates the claimant A. The claimant A initiates the authentication procedure and sends following token to B: Text1 | eKAB|(TA or NA|B|Text2). KAB denotes the secret key shared between A and B, eKAB denotes encipherment of some data X with the secret key, TA and NA stand for time stamp and sequence number and |denotes concatenation of messages. The identifier B of the verifier is optional.

Text1 | eKAB|(TA or NA|B|Text2)

Verifier B

Claimant A

Figure 10: One pass unilateral authentication using symmetric techniques.

65

The description of two pass unilateral authentication can be found from (ISO DIS 15668 1997; ISO DIS 9798-2 1997). Mutual authentication Two pass authentication In mutual authentication as well as in unilateral authentication, uniqueness is covered with the use of time stamps or sequence numbers. The token sent in mutual symmetric key authentication is similar to that one in unilateral authentication, but the authentication includes one pass more to provide authentication of both parties. A sends following token to B: Text1 | eKAB|(TA or NA|B|Text2). After that, B sends Text3 | eKAB|(TA or NA|A|Text4) to A . (ISO DIS 15668 1997).

Text1 | eKAB|(TA or NA|B|Text2) Text3 | eKAB|(TA or NA|A|Text4)

Verifier B

Claimant A

Figure 11: Two pass mutual authentication using symmetric techniques.

Asymmetric techniques Asymmetric authentication mechanisms are based on digital signatures and thus on public-private key pairs. The claimer proves its identity by knowing the private key assigned to it. The claimer signs a message with its private key using a certain signature algorithm and then the verifier verifies the signature by using the same algorithm but the claimer’s public key instead (ISO/IEC DIS 9798-4 1996; ISO DIS 15668 1997). As in symmetric authentication, asymmetric authentication might be unilateral or mutual. Moreover, unilateral authentication requires one pass and mutual authentication requires two passes at minimum. The scenarios including random numbers and having one extra pass compared to the usage of time stamps and sequence are omitted here as well. Unilateral authentication One pass authentication The claimant A initiates the authentication by sending a token to the verifier B. The form of the token is

66

TA or NA|B|Text2|sSA(TA or NA|B|Text1). sSA (X) denotes signing of the message X with A’s private key. As opposed to authentication techniques that exploit symmetric algorithms, the identifier of the verifier is mandatory. That is to ensure that no one but the intended verifier accepts the token the claimant sent (ISO/IEC DIS 9798-4 1996; ISO DIS 15668 1997). (CertA)|TA or NA|B|Text2|sSA(TA or NA|B|Text1)

Verifier B

Claimant A

Figure 12: One pass unilateral authentication using asymmetric techniques. Mutual authentication Two pass authentication The mutual authentication is similar to the unilateral one. After the original verifier has successfully verified it, they exchange roles and the verifier becomes the claimer and vice versa. The form of the token sent from B to A is TB or NB|A|Text4|sSB(TB or NB|A|Text3). The authenticating parties may additionally send their certificate i.e. signed public key information along the token. In the mutual authentication the messages the parties send are not related to each other. This means that by performing the unilateral authentication in both directions, actually the mutual authentication is achieved between the two authenticating parties (ISO/IEC DIS 9798-4 1996).

(CertA)|TA or NA|B|Text2|sSA(TA or NA|B|Text1)

(CertB)|TB or NB|A|Text4|sSB(TB or NB|A|Text3

Verifier B

Claimant A

Figure 13: Two pass mutual authentication using asymmetric techniques.

67

Mechanisms using cryptographic check functions Message Authentication Codes (MACs), which are also called cryptographic check values, can provide authentication of message origin and in addition to that, data integrity. The MAC is delivered along with a message the integrity of which the MAC is supposed to protect. The sender of the message generates the MAC. The MAC calculation can be applied to the whole of the message or only to those parts of the message that need the integrity protection. The principle idea of MACs is to map a message of arbitrary length into a fixed length value. A cryptographic algorithm and a key are needed for the calculation. The algorithm has to have the property that without knowing key, it is impossible to calculate a correct MAC for a message, even if one would know some other original message – check value pairs. MACs offer authentication of origin, because the claimer is able to prove its identity by demonstrating the possession of the secret key (ISO/DIS 15668 1998). Either public key cryptography or symmetric techniques can be utilized; the authentication procedures are similar to those presented in chapter 2.2.2. Only a MAC calculation algorithm fK is used instead of eKAB or sSA. (ISO/IEC DIS 9798-4). Part one of the ISO multipart standard 9797 describes six MAC calculation algorithms using symmetric encipherment techniques. Also ISO standard 8731 specifies a list of algorithms accepted for MAC calculation. For example, one of these algorithms is Data Encryption Standard (DES) (ISO/IEC FDIS9797-1 1999; ISO 8730 1990).

68