Eurogiro Envelope Format Specification · • Updated reference to SWIFT Standards • Added detailed description of field ... (MT category 1 to 9) which are used for financial transactions

Eurogiro Confidential

Eurogiro Envelope Format Specification

Version 2.4

26 August 2010



Eurogiro Envelope Format Specification Author: Uwe Holmsgaard This document is part of the Eurogiro System Documentation. Possession, use or copying of this publication is authorised only to members of the Eurogiro environment. Document history:

1.0 04 March 1994 New document extracted from Eurogiro Implementation Guide. • 2.0 18 November 1996

Editorial changes • List of Headers for various Message

Types • List of Trailers for various Message

Types • Fields to exclude from MAC calculation • Character set for MAC calculation • System Message Types

2.1 01 October 1998 Editorial changes.

• BEN /OUR definition for field 904 • Character set for MAC calculation

2.2 20 April 2002 Editorial changes.

• Examples updated with new dates and currencies

• Handling of date fields • Multiple hosts • SHA fee • New message types • SRC field in trailer block

2.3 15 February 2008 Editorial changes.

• Removed references to MT100 • Updated reference to SWIFT Standards • Added detailed description of field

format in the text block • Added description of SEPA XML

2.4 this release Editorial changes (marked).

• Updated supported character sets • Designation of test BIC • Clarified the usage of “:” • Clarified the conversion between 2

digit year and 4 digit year • Root tag in XML messages

Eurogiro Confidential i

Table of contents

1 Introduction 1

1.1 About this Handbook 1 1.1.1 Conventions Used in This Handbook 2

1.2 More information 3

2 Overview 4

2.1 System Concept 4 2.2 SWIFT Compatibility 4

3 Envelope 6

3.1 Message Types 6 3.2 Notation 6 3.3 Character Set 6 3.4 Block Format 7 3.5 Amount Field Format 7

3.5.1 Format and Usage Guidelines 7 3.6 Date field format 8 3.7 Post/Giro/Bank Identification Code 8 3.8 Envelope Components 10

3.8.1 Basic Header Block 11 3.8.2 Application Header Block 12 3.8.3 User Header Block 14 3.8.4 Text Block 16 3.8.5 Envelope Trailer Block 17 3.8.6 Example Envelopes 20

4 System Message Types 22

4.1 MT011, Delivery Notification 22 4.2 MT199-99, Statistics 23

5 MAC Calculation 24

5.1 MAC Structure 24 5.2 Character Set 24 5.3 Field Inclusion 27

6 XML formatting for SEPA 31

6.1 Bulking of transactions 31 6.2 Protection of XML file 31 6.3 Root tag 31 6.4 Example of SEPA XML message: 31

Eurogiro Envelope Format Specification, version 2.4

Eurogiro Confidential 1

1 Introduction

This Eurogiro Envelope Format Specification describes the format of the data, which are exchanged between the data processing systems of the Post/Giro/Banks via the Eurogiro Network. A main principle in the Eurogiro Network is the concept of transaction Envelopes. An Envelope contains a header and a trailer with control fields and common information about the messages of the Envelope. The document is not designed to cover the following topics in detail: • Host application functionality • Description of fields in the User-to-User message types • Operation of the Eurogiro System • Handling of payments

1.1 About this Handbook

This handbook is divided into chapters designed to cover a single topic or group of related topics. The following list summarises the contents of each chapter: • Overview - Provides an overview of the Envelope concept. • Envelope - Describes the format of Envelope headers and trailers.

For each message type is listed the fields that must be present in the headers and trailers.

• System Messages - Describes the messages generated by the Eurogiro System.

• MAC Calculation - Describes the fields to be included in the MAC calculation as well as the character set conversion.

• XML Formatting for SEPA – Describes the Eurogiro implementation of the SEPA XML messages.



1.1.1 Conventions Used in This Handbook

Convention Meaning

examples Examples and commands appear in this font. . In examples, a vertical ellipsis indicates that not all of . the lines of the example are shown. . ... An ellipses means "through" (used to define set ranges) ! Indicates comments to a command in an example variable In descriptions, this indicates items that are variable. = An equal sign means "is defined as" or "is composed of" () Parentheses mean "select one of the enclosed items". | A bar separates the items to select [ ] Square brackets mean "optional" (if more than one item is within the brackets, the set is optional) ' ' Single quotation marks are used to enclose a literal

Symbol Values Meaning

n ('0'|'1'|...|'9') any integer digit

no ('0'|'1'|...|',') amount field (digits and ‘,’) see 3.5

a ('a'|'A'|...|'Z') any alphabetical character

A (a|n) any alphanumerical character

h ('0'|...|'F') any hexadecimal character

x any character in the SWIFT character set



Notation Meaning

n<symbol> A number before a symbol means "an iteration of" or occurrences of the item(s)" enclosed. For example: 6n denotes a data element is composed of up to six integer digits 16a denotes an alphabetical data element composed of up to 16 alphabetical characters '' Exact values are enclosed in quotation marks. Example: Application identifier of format 1A with the value 'F' {} Curly brackets are used to enclose blocks and sub- blocks of a message. Example: {PDF:0} __ Underline is used to denote fields of fixed length. For example: 6n denotes a data element is composed of exactly six integer digits : Colon is used to separate block identifiers from block contents. Example: {2:O1000900910703...55559107030900U} :: Pair of colons is used to enclose field identifiers in text fields. Example: :32A:910103BEF1000000, CrLf The character Carriage Return followed by the character Line Feed.

1.2 More information

More information can be found in the following documentation: Ref. [1] Eurogiro Information Handbook [2] Eurogiro Implementation Guide [3] ISO 7746, Banking - Telex formats for inter-bank messages [4] ISO 8731-2, Banking - Approved algorithm for message

authentication - Part 2: Message authenticator algorithms [5] ISO 8732, Banking - Key management (wholesale) [6] SWIFT Standards MT, October 2007. Standards Release Guide



Int. HOSTInt. HOST

EurogiroNetwork

Transactions

Envelope

2 Overview

This chapter is an introduction to the Eurogiro Network and Systems.

2.1 System Concept

The Eurogiro Network act as a transparent means for connecting the international Host systems at the various Post/Giro/Bank Institutions.

A main principle in the Eurogiro Network is the concept of transaction Envelopes. Transactions are generated in SWIFT compliant message format and sent to the destination packed into Envelopes. An Envelope contains multiple transactions with the same message type, value date, currency, fees and destination.

Figure 1 Envelope Transfer

An Envelope contains a header and a trailer with control fields and common information about the messages of the Envelope. The Envelopes are transferred in the network based on Bank Identification Codes (BIC address) (See section 3.7 Post/Giro/Bank Identification Code). The destination and source BIC address of the Host systems are in the Envelope header.

2.2 SWIFT Compatibility

An important issue is the compatibility with SWIFT. Many of the involved Post/Giro/Banks are using applications developed for handling SWIFT messages.



Normally when transmitting SWIFT-messages, the sender's address and receiver's address located respectively in the Basic Header Input and the Application Header Input, are switched by the SWIFT data processing centre when appearing in the Basic Header Output and Application Header Output.

This switching is not

done by the Eurogiro System. The Eurogiro System is passing the Envelopes from one Host system to the other without any other alteration than the Eurogiro System inserting an Envelope Output Sequence Number (OSN) before sending an Envelope to the Host and possibly adding a indications for possible duplicate or urgent message priority. Therefore the SWIFT II output header format is used as standard format for Envelope headers. This means that the contents of the Envelope header can be used as transaction header at the unpacking at the receiver. This will make the further processing of the received transactions easier for software systems normally processing SWIFT-formatted data.

The Eurogiro messages, when unpacked from Envelopes, have the same format as SWIFT user-to-user messages and they can then be forwarded directly to these applications. However the debiting of all transactions in an Envelope cannot comply to the SWIFT standard as these are debited in one single transaction with the reference number from the Envelope User Header Block used as reference for this particular transaction.



3 Envelope

The Eurogiro System supports Envelopes containing up to 10000 transactions. Currently the recommended Envelope size is 500 transactions. A larger Envelope size can be agreed bilaterally. The optimum Envelope size depends on the quality of the telecommunication lines. If the quality is poor, large Envelopes may cause a high number of re-transmissions with resulting low performance. However, if the quality is good, a better performance may be achieved by increasing the Envelope size. The description of the Envelope format is based on the specifications in ref. [6]. In this section the format of the Envelope header and trailer is described.

3.1 Message Types

In the Eurogiro Network there are 3 types of messages: • System Messages - (MT category 0) which relates to receiving of

messages (Delivery Notification). • User - to - User Messages - (MT category 1 to 9) which are used for

financial transactions. • SEPA messages in XML format

The system messages are described in section 4 and the User - to - User message types and the SEPA messages are all described in ref. [1].

3.2 Notation

The notation used is adopted from ref. [6]. The notations and symbols used in the following data format definitions is shown in section 1.1.1 Conventions Used in This Handbook. Envelopes generated on the sending Host are called export Envelopes. Envelopes received from a remote system are called import Envelopes.

3.3 Character Set

The allowed character set in MT transaction Envelopes is limited to the X SWIFT character set, which is specified below:

X SWIFT Character Set

Alphabetical Characters A to Z (upper case) a to z (lower case)

Numeric Characters 0 to 9 Special Characters /-?:().,'+Space CrLf

It follows that it is not

allowed to include any special national characters in the transaction Envelopes like e.g. æøåäöüéë, as this will cause problems when converting Envelopes between ASCII and EBCDIC during the transmission or when transactions are forwarded on other networks.



XML formatted messages will be validated against the UTF-8 characters set. However the sending party must check that the receiving institution is capable of processing such files or only files limited to the X SWIFT character set.

3.4 Block Format

The general format of a block according to the SWIFT standard is:

<block> = {<block id>:<block contents>}

where <block id> is a string of 1 to 3 characters and <block contents> is dependent of the block type.

3.5 Amount Field Format

The general format of amount fields is described below (ref. [7]):

3.5.1 Format and Usage Guidelines

nn......nn,nn....n (integer part),(fractional part - optional) Whenever they represent a numeric value, numbers always take the same form:

• The integer part must contain at least one digit. • Decimal points are not permitted. A comma "," shall precede the frac-

tional part. • The maximum length includes the decimal comma • The fractional part may be missing, but the decimal comma must

always be present. • Neither blank spaces, nor any symbols other than the decimal comma

are permitted. • Numbers must not begin with zeros, except the integer zero before

the decimal comma. • Normally when a number represents an amount of money, the

number of places following the decimal comma is dependent on the currency, i.e., it may not exceed the number of decimal digits valid for the specified currency. The specifications for the individual message types will indicate the fields where this is not the case. Details regarding the allowable fractional parts for each currency code may be found following the list of currency codes in the green section of the International Bank Identifier Code Directory.



Examples:

Valid Not Valid

0, 0 0,67 .67 0,25 ,25 0,2 ,20 100000, 100.000 25768, 25-768 99999999, 999.999.999 100, 100 10500, 10500 5,25 5 1/4

3.6 Date field format

Please notice that the year is often only presented by 2 digits in the Envelopes. The fields for the Value Date, Input Date, Output Date and other fields with dates will not be expanded to hold a 4 digit presentation of the year. It is recommended that the 2 digit year is converted internally to 4 digit representation by using the year 79 as crossover. Algorithm: If YY > 79 then YYYY=19YY ELSE YYYY=20YY

3.7 Post/Giro/Bank Identification Code

The Bank Identification Code (BIC address) is used for addressing in the Eurogiro Network. The BIC is an ISO standard managed by SWIFT. The 12 characters BIC address is formatted as follows: Bank Code 4a Country Code 2a Location Code 2a Logical Terminal Code 1a Branch Code 3a The last 4 characters (Logical Terminal and Branch Code) are in the Eurogiro Network: XTIC Designating the general Host as source or destination.

Envelopes must always be addressed to the XTIC address. XTIn Designating the Host “n” as source.

Envelopes must always be addressed to the XTIC address. XELS or XESM

Designating a Eurogiro System as source. The Envelope has been generated using the Data Entry facility or automatically by the ELS / ESM (i.e. MT011 or MT202).

All financial institutions can apply for a BIC address by SWIFT.



When the Test and Production system are located on the same site a naming convention has been adopted to distinguish the two systems. To designate the Test system the last character in the Location Code is normally substituted with a "T" ("T" for test). As an example the BIC addresses of Postbank in Germany are: Production: PBNKDEFF Test: PBNKDEFT

Note

Please observe that some members may use test systems NOT ending on a “T”. Also some members may have a 3rd

system ending on “TT”.

Note

Also please note that some member banks may be using a “0” instead of the “T” to indicate the test BIC.



3.8 Envelope Components

A SWIFT II User-to-User message is build up by the following components:

{1: BASIC HEADER BLOCK} {2: APPLICATION HEADER BLOCK} {3: USER HEADER BLOCK} {4: TEXT BLOCK} {5: TRAILERS BLOCK}

Each block contains data of a particular type and is used for a particular purpose. The Text Block is containing the actual transaction message fields depending on the message type. The structure of a Eurogiro Envelope is in essence a SWIFT II message with several occurrences of Text Block and with modifications and additions to the header- and trailer blocks.

{1: BASIC HEADER BLOCK} {2: APPLICATION HEADER BLOCK} {3: USER HEADER BLOCK} {4: TEXT BLOCK 1} {4: TEXT BLOCK 2} {4: TEXT BLOCK 3} • • {4: TEXT BLOCK n} {5: TRAILERS BLOCK}

Blocks 3 and 5 may contain sub-blocks (i. e. blocks within blocks).

Because of varying lengths of records and blocks in the Host and Eurogiro Systems involved in the transmission of an Envelope, there may appear a block of insignificant bytes after the last valid character of the Envelope (the last "}" of block 5}. These characters will usually be spaces or binary zeros and there should never be made any assumptions on the value of these bytes and they should never be interpreted in any way. This implies that an Envelope should always be parsed from the beginning and never backwards from the end of the file containing the Envelope.



3.8.1 Basic Header Block

The Basic Header Block of an Envelope has the same format and use as in SWIFT II.

The following is an example of a Basic Header Block, as it might appear at the beginning of a Eurogiro Envelope:

{1:F01PSTBNL2AXTIC0000000000}

For clarity the components are shown separated below:

{1: F 01 PSTBNL2AXTIC 0000 000000} a b c d e f

(a) Block Identifier

The block identifier for a Basic Header Block is always '1:'.

(b) Application Identifier

The application identifier will in Eurogiro always have the value 'F', which means Financial application.

(c) Application Protocol Data Unit Identifier

In Eurogiro this field will always have the value '01', which means a user-to-user message.

(d) Address of Recipient

This field contains the 12-character BIC address identifying the recipient of the Envelope.

(e) Output Session Number

This field is not used in Eurogiro, but should always be set to '0000'.

(f) Output Sequence Number

The Output Sequence Number (OSN) will always consist of 6 digits. The sending Host shall always put the value '000000' in this field, and the receiving Eurogiro System will insert a sequence number in this field before transmitting the Envelope to Host, to enable the receiving host to determine if it receives all Envelopes sent from the Eurogiro System.



The scheme below gives an overview of the basic header block:

Tag Field name Format 1 Application Identifier,

Data Unit, Receiver's Address, output session number (dummy) output sequence number

F 2n 4a2a2A1A3A 4n 6n

3.8.2 Application Header Block

The Application Header Block of an Envelope has the same format as a SWIFT II Application Header - Output. The following is an example of a Application Header Block, as it might appear at the beginning of a Eurogiro Envelope:

{2:O1000900020115PTCHBEBBXTIC00005555550201150902N}

For clarity the components are shown separated below:

{2: O 100 0900 020115P...0555555 020115 0902 N} a b c d e f g h

(a) Block Identifier

The block identifier for a application header block is always '2:'.

(b) Input/Output Identifier

The input/output identifier is in Eurogiro always given the value 'O' meaning Output.

(c) Message Type

This field will contain the message type (MT) number of the mess-ages in the Envelope. The message types used in Eurogiro are described in ref. [1].

(d) Input Time

The time the Envelope was sent in sender's local time. The format of the time is HHMM.

(e) Message Input Reference (MIR)

The Message Input Reference contains data about the sender of the Envelope. In the example above the MIR looks like this:

020115PTCHBEBBXTIC0000555555



For clarity the MIR can be separated into its components:

020115 PTCHBEBBXTIC 0000 555555 I II III IV

(I) Input Date

The date the Envelope was sent in sender's local time. The format of the date is YYMMDD.

(II) Address of sender

This field contains the 12-character BIC address identifying the sender of the Envelope.

(III) Session Number

This field is not used in Eurogiro, but should always be set to '0000'.

(IV) Input Sequence Number

The Input Sequence Number (ISN) will always consist of 6 digits. The sending host shall insert a sequence number in this field enabling the receiving Eurogiro System to determine if it receives all Envelopes sent from the Host.

(f) Output Date

The output date (YYMMDD) is the date of receipt local to the receiver. The field should be filled with the current date by the receiving Host. The sending Host shall initialise the field with the value '000000'. The Eurogiro System set this value when an import Envelope is received from a remote system.

(g) Output Time

The output time (HHMM) is the time of receipt local to the receiver. The field should be filled with the current date by the receiving Host. The sending Host shall initialise the field with the value '0000'. The Eurogiro System set this value when an import Envelope is received from a remote system.

(h) Message Priority

The priority field may in Eurogiro have the value 'N' (Normal) or 'U' (Urgent) set by the sending host. The Eurogiro System application on both the sending and receiving Eurogiro System will forward Envelopes with 'U' as message priority immediately. Immediate and scheduled transfers of Envelopes can also be controlled at the Eurogiro System through the Eurogiro System control table on the product code level.



The scheme below gives an overview of the application header block:

Tag Field name Format 2 Output Identifier,

Message Type, Input time (sender's local), Message input reference (input date, sender's address, input session number (dummy), input sequence number) Output date (receiver's local), Output time (receiver's local) Message priority

'O' 3n 4n 28A (6n, 4a2a2A1A3A, 4n, 6n) 6n 4n ('N'|'U')

3.8.3 User Header Block

The User Header Block of an Envelope has the same format as a SWIFT II user header block with some additional non-SWIFT fields. The User Header Block is available for User-to-User messages only.

The following example shows the format of a User Header Block as part of an Envelope: {3:{108:ENVREF-001}{901:EUR}{902:020117}{903:20}{904:OUR}} The following blocks are defined:

Tag Block name Identifier Format 3 Reference Number

Currency Code Value Date Product Code BEN / OUR/SHA Specification

108: 901: 902: 903: 904:

16x 3a 6n 2n 3a

Block Identifier

The block identifier (tag) for the User Header Block is always '3:'.

108: Reference number

This field is a common reference for all messages contained in the Envelope consisting of up to 16 characters. This reference number will be used for any reference from the receiver to the sender to this Envelope, including debit transaction for the Envelope on subsequent statements. In SWIFT II this field is called Message User Reference (MUR). Please note that the Reference number must be unique within a year for a specific message type!



Also please note that the first 3 characters must only hold the value “TMO” for the MT103 and MT198 message types related to the Eurogiro Cash International® product.

901: Currency code

This field contains the common currency code for the transactions contained in the Envelope. The field tag '901:' has been invented by Eurogiro and is not part of the SWIFT standard. The currency code is the two letter ISO country code followed by a third letter denoting the particular currency.

902: Value Date

This field contains the common Value Date on the form YYMMDD for the transactions contained in the Envelope. The field tag '902:' has been invented by Eurogiro and is not part of the SWIFT standard.

903: Product code

This field contains the common product code for the transactions contained in the Envelope. The field tag '903:' has been invented by Eurogiro and is not part of the SWIFT standard. This tag is mandatory, and '00' must be specified for messages that do not have a product code!

904: BEN/OUR/SHA specification

This field contains the fee information for the transactions contained in the Envelope. The field tag '904:' has been invented by Eurogiro and is not part of the SWIFT standard. The presence of the BEN/OUR/SHA specification in the user header block makes it possible to handle the BEN-, OUR- and SHA category messages at the Envelope level. The BEN/OUR/SHA specification may also be present in each message in field 71A (mandatory for MT103).

Note that the fields should be expected to appear in any order in the User Header Block. The fact that the fields appear as sub-blocks makes it possible to decode the User Header Block uniquely. It is however recommended letting the fields appear in the order shown above.

In Table 1 below is an overview of which fields must be present for the various message types.



Mesage Type 108 901 902 903 904 011 na na na na na 102 - 103 X X X X X 191 X X X n92 - n96 - n98 X X 198-93 X X X X n99 X X 200 X X X X 202 X X X X 900 - 910 X X 940 - 950 X X

Table 1 Sub-blocks in User Header Block

3.8.4 Text Block

Eurogiro messages will appear in the Envelope as a series of SWIFT II Text Blocks.

All message text within the Text Block (block 4) begins with Carriage Return and Line Feed <CrLf> and ends with <CrLf> followed by a hyphen.

Below is an example of two Eurogiro messages. Please note that the example is for information only and may not show a valid transaction. Please see in ref. [1] for a detailed list of mandatory and optional text field for the specific Message Types.

{4:<CrLf> :20:PAYREF-AA00001<CrLf> :32A:020117EUR50000,<CrLf> :50:CUSTOMER NAME<CrLf> AND ADDRESS<CrLf> :59:/111-222-333<CrLf> BENEFICIARY NAME<CrLf> AND ADDRESS<CrLf> -} {4:<CrLf> :20:PAYREF-AA00002<CrLf> :32A:020117EUR750000,<CrLf> :50:CUSTOMER NAME<CrLf> AND ADDRESS<CrLf> :59:/444-555-666<CrLf> BENEFICIARY NAME<CrLf> AND ADDRESS<CrLf> -}

Block Identifier

The block identifier for each message is '4:'.



Text Fields

The message text is always beginning with CrLf and ends with CrLf followed by a hyphen (-). The lines within the message text are separated by CrLf.

A field is always prefaced by a field tag which consists of two digits followed, in certain cases, by an alphabetic character followed by a colon (:). The alphabetic character is referred to as an option. A field is always ended by a field separator which consists of ’CrLf:’ for all the fields included in the text of a message, and ’CrLf-’ for the last field of the text. The following character restrictions are applied to field content:

• first line: o it must not start with ’CrLf’ o it must not be entirely composed of blank characters

• second and subsequent lines (a new line must start with ’CrLf’) o within the field content, a colon ’:’ must never be used as

the first character of a line (the combination ’CrLf:’ always indicates a new field tag). An exception is the situations where a copy of the original message is applied!

o within the field content, a hyphen ’-’ must never be used as the first character of a line. (the combination ’CrLf-’ always indicates the end of text)

• meaningless components are not allowed: components containing only blank(s) or only ’CrLf’ are not allowed!

Trailing blanks are allowed as long as the length of the field is not exceeded. In those cases where character type 'a' or 'a' is used in the field format description (see ref. [1]), the alphabetic characters must be uppercase.

3.8.5 Envelope Trailer Block

Envelope Trailer Block is added for control purposes. The Envelope Trailer Block has the same format as a SWIFT II Trailer Block.

Each trailer appears as a separate sub-block and is bounded by block delimiters. Each trailer begins with a three letter code, followed by a colon, followed by the trailer information itself.

Below is an example of a Envelope Trailer Block. Note that the Envelope trailer will be transmitted as a continuous string of characters without CrLf or blank characters inserted. In the below example the sub-blocks have been shown on separate lines and with spaces for purpose of clarity. {5:{NOM:00001}{TOT:532000,}{PDF:0}{MAC:3A62DC8B}}



The following sub-blocks in the trailer are defined:

Tag Block name Identifier Format 5 Number of Messages

Total of Amounts Total amounts of fees Message Authentication Code Possible Duplicate File Possible Duplicate Emission System Message

NOM: TOT: SRC: MAC: PDF: PDE: SYS:

5n 18no 18no 8h ('0'|'1') 6n

NOM Trailer

(Number Of Messages) This trailer is a non-SWIFT trailer and it is used by Eurogiro to indicate the number of messages contained in an Envelope.

TOT Trailer

(Tot

al of amounts) This Trailer is a non-SWIFT trailer and it is used by Eurogiro to contain the amounts from the messages of the Envelope added together (Σ 32A). The format of the value-part (See section 3.5) of this field is the same as the value-part of field no. 32A in the specific messages of the text block (block no. 4) with the only difference that a sufficient number of digits should be allowed.

SRC Trailer

(Total of fees) This Trailer is a non-SWIFT trailer and it is used by Eurogiro to contain the amounts of fees from the messages of the Envelope added together (BEN or SHA: Σ 71F, OUR: Σ 71G). The format of the value-part (See section 3.5) of this field is the same as the value-part of field no. 71F (field 71A = BEN / SHA) or 71G (field 71A = OUR) in the specific MT103 messages of the text block (block no. 4) with the only difference that a sufficient number of digits should be allowed. For OUR payments this field is used to indicate the charges included in the settled amount (TOT). The charges the sending party pays to the receiving party. For BEN / SHA charges the field is forwarded for information purposes only.

MAC Trailer

(Message Authentication Code) This trailer is a standard SWIFT II trailer. It is used to supply the ISO 8731-2 generated MAC of the Envelope for authentication verification.



PDF Trailer

(Possible Duplicate File) This field is a non-SWIFT field it is used in Eurogiro by the Eurogiro System application to indicate that the Envelope might be a duplicate of an already transmitted Envelope. The field shall always be inserted by the sending host with the value 0 ({PDF:0}), indicating no possible duplicate file. In case a transaction file is re-transmitted between Eurogiro System's or it is re-transmitted from the Eurogiro System to the Host, the sending Eurogiro System will change the value to 1 ({PDF:1}).

PDE Trailer

This field is used like in SWIFT II to indicate possible duplicate emission with supplied information. This field is used by Eurogiro when an Envelope is transmitted from the Host to the Eurogiro System, and there is reason to believe that the Envelope has already been transmitted. The field is set by the sending Host when an Envelope is re-transmitted and contains the Input Sequence Number of the Envelope, when it was originally send from the Host. This is a simplification of the SWIFT II format. The field is only present if the Envelope is an actual duplicate emission.

SYS Trailer

A SYS Trailer is added to messages generated by the Eurogiro System for example Delivery Notification.

Note that the trailers may appear in any order in the Envelope Trailer Block. The fact that the fields appear as sub-blocks makes it possible to decode the Envelope Trailer Block uniquely. It is however recommended to let the fields appear in the order shown above.

In Table 2 below is an overview of which sub-blocks for the various message types (‘M’ means mandatory and ‘O’ means optional):



MT NOM TOT SRC PDF PDE MAC SYS 011 M M O M 102 M M M O M na 103 M M O M O M na 191 M M M O M na n92 – n96 M M O na n98 M M O O na n98-93 M M M O M na n99-00 M O O na 199-99 M M O O M 200 M M M O M na 202 M M M O M *1

900 - 910

M M O M na 940 - 950 M M O O na

Table 2 Sub-blocks in Trailer Block

Note

Please observe that the MAC must always be verified if it is supplied!

3.8.6 Example Envelopes

Below are three examples of Envelopes sent from The Netherlands to Belgium. The first example shows an export Envelope. The second example shows this Envelope received on the destination Host (OSN, Output Date and Time set). The third example shows a re-transmission of this Envelope from the Host (New ISN, Input Date and Time, PDE trailer and new MAC). Note that <CrLf> is inserted where this is actually used as a delimiter as opposed to the use of several lines to fit the example into a normal page of this document.

1 When the MT202 is generated automatically by the Eurogiro System the {SYS:} block is present, in all other circumstances the block must be omitted.



Export Envelope:

{1:F01PSTBNL2AXTIC0000000000} {2:O1000911020115PTCHBEBBXTIC00005555440000000000N} {3:{108:ENVREF-AA001}{901:EUR}{902:020117}{903:20}{904:OUR}} {4:<CrLf> :20:PAYREF-AA00001<CrLf> :32A:020117EUR50000,<CrLf> :50:CUSTOMER NAME<CrLf> AND ADDRESS<CrLf> :59:/111-222-333<CrLf> BENEFICIARY NAME<CrLf> AND ADDRESS<CrLf> -} {4:<CrLf> :20:PAYREF-AA00002<CrLf> :32A:020117EUR750000,<CrLf> :50:CUSTOMER NAME<CrLf> AND ADDRESS<CrLf> :59:/444-555-666<CrLf> BENEFICIARY NAME<CrLf> AND ADDRESS<CrLf> -} {5:{NOM:00002}{TOT:800000,}{MAC:1D34A6CD}{PDF:0}}

Import Envelope:

{1:F01PSTBNL2AXTIC0000000753} {2:O1000911020115PTCHBEBBXTIC00005555440201151653N} {3:{108:ENVREF-AA001}{901:EUR}{902:020117}{903:20}{904:OUR}} {4:<CrLf> :20:PAYREF-AA00001<CrLf> . . BENEFICIARY NAME<CrLf> AND ADDRESS<CrLf> -} {5:{NOM:00002}{TOT:800000,}{MAC:1D34A6CD}{PDF:0}}

Export Envelope (re-transmit):

{1:F01PSTBNL2AXTIC0000000000} {2:O1000852020116PTCHBEBBXTIC00005555660000000000N} {3:{108:ENVREF-AA001}{901:EUR}{902:020117}{903:20}{904:OUR}} {4:<CrLf> :20:PAYREF-AA00001<CrLf> . . . BENEFICIARY NAME<CrLf> AND ADDRESS<CrLf> -} {5:{NOM:00002}{TOT:800000,}{MAC:F5D72C38}{PDF:0}{PDE:555544}}



4 System Message Types

This section describes the System Message Types used in the Eurogiro Network.

4.1 MT011, Delivery Notification

The ELS and ESM versions of the Eurogiro System returns a MT011 upon successful reception of a transaction. SECUG members are also obliged to generate the MT011. The MT011 Delivery Notification includes the following from the original message:

• Input time of delivered message (when message was sent) • Message Input Reference (MIR), from the Application Header: • Message User Reference (MUR), field 108: in the User Header • Output time of delivered message (when message was received) • Message Output Reference (MOR)

{1:<basic-header>}{2:<application-header>} {4: {175:<input time>} 4n {106:<MIR>} 6n12[{108:<MUR>}] 16x

x4n6n

{175:<output time>} 4n {107:<MOR>} 6n12x4n6n -}{5:{SYS:}{NOM:00001}{PDF:0}}

Message Output Reference (MOR)

A MOR is assigned by the Eurogiro System to a message when it is received. The MOR is formatted: • Receiver’s local Output date, BIC address, '0000', Output

Sequence Number



4.2 MT199-99, Statistics

The Eurogiro systems collect statistics of outgoing transactions. Each month these statistics are sent to Eurogiro and used for billing purposes. On ELS systems the monthly statistics are also sent to the local country in a MT199-99 message. {1:<basic-header>}{2:<application-header>} {3:{108:02-PTCHBEBB-01-0}{903:99} {4: :20:<Reference> 2n-8a-2n :79:<Statistics> 8a,3n,2n,3a,7n,18n <Statistics> 8a,3n,2n,3a,7n,18n . . <Statistics> 8a,3n,2n,3a,7n,18n -}{5:{SYS:}{NOM:00001}{PDF:0}}

Reference

The reference is formatted:

• Year, BIC address, month

Statistics

The statistics are formatted “comma separated” in tag 79 and sorted by BIC address, message type and product code:

• BIC address, MT, Prod. Code, Currency, Number of

transactions, Total amount

Note

Please note that the normal limitations (characters per line and number of lines) for tag 79 will be exceeded!



5 MAC Calculation

For each Envelope to be sent from one Host system to the Eurogiro System, a Message Authentication Code (MAC) should be generated based on a Message Authentication Algorithm (MAA) complying with the ISO 8731-2 standard. The MAC is generated by the sending Host system and inserted in the MAC-trailer. The connected Eurogiro System will re-calculate the MAC and verify it against the MAC received with the Envelope. The ISO 8731-2 standard is available from the respective national standards institutes. An MAA implementation complying with the ISO 8731-2 standard is available from Eurogiro in the C programming language, Java and .NET. This can be used either for direct porting or as pseudo-code for implementation in another language or tool. Also a COBOL/Assembler implementation on the IBM system 370 platform is available.

5.1 MAC Structure

The MAC result is a 32 bit binary value. In the Envelope it is inserted after the MAC-keyword in the Envelope trailer and is represented in by 8 hexadecimal characters (i.e. {MAC:1234ABCD}).

5.2 Character Set

Since the authentication process handles the message as a consecutive string of 32-bits unsigned integers, it is very important that the messages are represented by the same string of integers when being authenticated in different installations. Therefore, all the characters in the message will be converted to a character set defined by Eurogiro Networks. This is mainly the printable characters in the ASCII alphabet. Any not printable, national or character that is not represented in all common character sets, must be masked out and replaced by space.

Note

Please observe that the MAC character set is extended to support EDIFACT and general text messages. Transaction messages should be limited to only use the SWIFT character set (section 3.3 Character Set).

The Table 3 below describes the conversion rules for the EBCDIC characters. Please note that all lowercase ASCII characters are converted into uppercase in the calculation. Please note that the left and right curly brackets must be converted into spaces before the calculation.



Character name Character symbol

EBCDIC hex-code

ASCII hex-code

space 40 20 period . 4B 2E less than < 4C 3C left parenthesis ( 4D 28 plus + 4E 2B exclamation point ! 4F 21 ampersand & 50 26 asterisk * 5C 2A right parenthesis ) 5D 29 semicolon ; 5E 3B dash/hyphen - 60 2D slash / 61 2F comma , 6B 2C percent % 6C 25 underscore _ 6D 5F greater than > 6E 3E query/question mark

? 6F 3F

colon : 7A 3A apostrophe/quote ‘ 7D 27 equal sign = 7E 3D double quote “ 7F 22 right curly bracket { C0 7B left curly bracket } D0 7D lowercase a a 81 41 lowercase b b 82 42 lowercase c c 83 43 lowercase d d 84 44 lowercase e e 85 45 lowercase f f 86 46 lowercase g g 87 47 lowercase h h 88 48 lowercase i i 89 49 lowercase j j 91 4A lowercase k k 92 4B lowercase l l 93 4C lowercase m m 94 4D lowercase n n 95 4E lowercase o 0 96 4F lowercase p p 97 50 lowercase q q 98 51 lowercase r r 99 52 lowercase s s A2 53 lowercase t t A3 54 lowercase u u A4 55 lowercase v v A5 56 lowercase w w A6 57

Continued on next page



Continued from previous page

Character name Character symbol

EBCDIC hex-code

ASCII hex-code

lowercase x x A7 58 lowercase y y A8 59 lowercase z z A9 5A uppercase a A Cl 41 uppercase b B C2 42 uppercase c C C3 43 uppercase d D C4 44 uppercase e E C5 45 uppercase f F C6 46 uppercase g G C7 47 uppercase h H C8 48 uppercase i I C9 49 uppercase j J Dl 4A uppercase k K D2 4B uppercase l L D3 4C uppercase m M D4 4D uppercase n N D5 4E uppercase o O D6 4F uppercase p P D7 50 uppercase q Q D8 51 uppercase r R D9 52 uppercase s S E2 53 uppercase t T E3 54 uppercase u U E4 55 uppercase v V E5 56 uppercase w W E6 57 uppercase x X E7 58 uppercase y Y E8 59 uppercase z Z E9 5A zero 0 F0 30 one 1 Fl 31 two 2 F2 32 three 3 F3 33 four 4 F4 34 five 5 F5 35 six 6 F6 36 seven 7 F7 37 eight 8 F8 38 nine 9 F9 39 all other characters 20

Table 3 MAC character set and conversion table

Note

Please note that the left and right curly brackets must be converted into spaces before the calculation.



5.3 Field Inclusion

This is a specification of which fields of an Envelope to include in the MAC calculation. Basically as many fields as possible should be included, to get the most information as possible subject to authentication. The only fields to be excluded are the fields which can be changed after the MAC calculation. Fields can be changed either by the sending Host or by the Eurogiro Systems when the Envelope is being transferred. The MAC calculation must take place as early in the processing of export Envelopes as possible. Therefore the following fields (Table 4) shall not

be included in the MAC and the value part of the fields must be swapped with spaces before the calculation:

Note

Please note that the Input Date must not be changed after the MAC has been calculated as this field is used by the receiver to select the MAA keys for the verification.



Block Field Description Basic Header Block

Output Sequence Number

Set by the Eurogiro System before transmitting the Envelope to the Host system.

Application Header Block

Input Time

Set by the sending Host to the time of sending.

Input Date

Set by the sending Host to the date of sending.

Input Sequence Number

Set by the sending Host before transmitting the Envelope to the Eurogiro System.

Output Date

Set by the Eurogiro System to the date of receipt before transmitting the Envelope to the Host.

Output Time

Set by the Eurogiro System to the time of receipt before transmitting the Envelope to the Host.

Message Priority

The message priority field may be changed by the Eurogiro System from "N" to "U", in case a transmission is delayed due to network failures or a re-transmit has been issued.

Trailer Block

MAC

The value part of the Message Authentication Code must itself be excluded from the calculation.

PDF

Set by the Eurogiro System in case of re-transmission.

PDE

The value part of the PDE must be excluded from the calculation.

Table 4 Fields to be excluded in MAC calculation

In Table 5 is an example of an export Envelope where the characters to be excluded from the MAC calculation is shown respectively as bold and padded out with spaces.

Apart from the fields listed in Table 5, all other characters of an Envelope should be included in the MAC-calculation, from and including the opening curly bracket ({) of block 1 to and including the last closing curly bracket (}) of block 5. Generally the space-character is used for padding an Envelope for several purposes: • The way to exclude fields from MAC calculation shall be done by

padding these fields with spaces (also called blanks) before the calculation of the MAC. This retains the size and structure of the envelope and means that no shuffling of data is needed as would be the case if fields were removed. See figure 2 below, which shows the characters to be included in the MAC calculation. After generation the MAC shall be inserted at the proper place in the trailer.



• To avoid problems with different representation of national and other special characters, those characters shall be translated to space in the translation tables used by the MAA. This is already done in the tables ASCII.TBL and EBCDIC.TBL.

• In the MAA implementation spaces shall be used to pad out the

envelope so that the MAC is generated on a multiple of 4 bytes.



Table 5 Envelope for MAC Calculation

{1:F01PSTBNL2AXTIC0000000000}{2:O1000900020115PTCHBEBBXTIC00005555550000000000N}{3:{108:ENVREFAA00001}{901:EUR}{902:020117}{903:20}}{4:<CrLf> :20:PAYREF-AA00001<CrLf> :32A:9020117EUR50000,<CrLf> :50:CUSTOMER NAME<CrLf> AND ADDRESS<CrLf> :59:/111-222-333<CrLf> BENEFICIARY NAME<CrLf> AND ADDRESS<CrLf> -}{4:<CrLf> :20:PAYREF-AA00002<CrLf> :32A:020117EUR750000,<CrLf> :50:CUSTOMER NAME<CrLf> AND ADDRESS<CrLf> :59:/444-555-666<CrLf> BENEFICIARY NAME<CrLf> AND ADDRESS<CrLf> -}{5:{NOM:00002}{TOT:800000,}{MAC:1234ABCD}{PDF:0}{PDE:555544}} {1:F01PSTBNL2AXTIC0000 }{2:O100 PTCHBEBBXTIC0000 }{3:{108:ENVREFAA00001}{901:EUR}{902:020117}{903:20}}{4:<CrLf> :20:PAYREF-AA00001<CrLf> :32A:020117EUR50000,<CrLf> :50:CUSTOMER NAME<CrLf> AND ADDRESS<CrLf> :59:/111-222-333<CrLf> BENEFICIARY NAME<CrLf> AND ADDRESS<CrLf> -}{4:<CrLf> :20:PAYREF-AA00002<CrLf> :32A:020117EUR750000,<CrLf> :50:CUSTOMER NAME<CrLf> AND ADDRESS<CrLf> :59:/444-555-666<CrLf> BENEFICIARY NAME<CrLf> AND ADDRESS<CrLf> -}{5:{NOM:00002}{TOT:800000,}{MAC: }{PDF: }{PDE: }}



6 XML formatting for SEPA

The Eurogiro applications are able to handle the XML messages as outlined by EPC for SEPA credit transfers. Please refer to the Eurogiro Message type Specification for more information. Please see the document the document “UNIFI (ISO20022) Message Definition Report – Payments Standard – Initiation” for a detailed description of the XML format.

6.1 Bulking of transactions

The XML format includes bulking, so there is no need for additional Eurogiro bulking or Enveloping. The bulking information is in the <GrpHdr> where the total number of transactions (<<NbOfTxs>), the settled amount and currency (<TtlIntrBkSttlmAmt Ccy >) and Value Date (<IntrBkSttlmDt>) are listed.

6.2 Protection of XML file

The XML file does not hold any elements or tags for MAC information. The file will be protected by other means in the transmission between the Host and the Eurogiro System.

6.3 Root tag

Support of the new versions of pacs and camt messages (released Nov 2010) will use the standard ISO root tags. Previous releases will be supported with the root tags designating the message type (i.e. <pacs.008.001.01>).

6.36.4 Example of SEPA XML message:

The purpose of the below example is to show the overall structure. The example does not include all the required message elements. <?xml version="1.0" encoding="UTF-8"?> <?SWIFTStandards Smart Test Messages for SEPA Credit Transfer Scheme product version 2.0?> <?valid true?> <Document xmlns="urn:iso:std:iso:20022:tech:xsd:pacs.008.001.01" xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance"> <pacs.008.001.01> <GrpHdr> <MsgId>TPACS008001_Normal</MsgId> <CreDtTm>2007-08-15T16:40:00</CreDtTm> <NbOfTxs>3</NbOfTxs> <TtlIntrBkSttlmAmt Ccy="EUR">1000.00</TtlIntrBkSttlmAmt> <IntrBkSttlmDt>2007-08-17</IntrBkSttlmDt> . <InstgAgt> <FinInstnId>



<BIC>EURODK2T</BIC> </FinInstnId> </InstgAgt> <InstdAgt> <FinInstnId> <BIC>POFICHBT</BIC> </FinInstnId> </InstdAgt> </GrpHdr> <CdtTrfTxInf> . !first transaction . </CdtTrfTxInf> <CdtTrfTxInf> . !second transaction . </CdtTrfTxInf> <CdtTrfTxInf> . !third transaction . </CdtTrfTxInf> </pacs.008.001.01> </Document>



Index

A

Application Header Block, 12

B

Bank Code, 8 Bank Identification Code. See BIC

address Basic Header Block, 11 BEN specification, 15 BIC address, 8 Branch Code, 8

C

Character set MAC, 24 SWIFT, 6

Colon, use of, 17 Country Code, 8 Currency code, 15

D

Date field, 8 Delivery Notification, 22

E

Envelope, 4 Envelope reference, 14 Envelope Trailer Block, 17 Example

Envelope Trailer Block, 17 Eurogiro messages, 16 Export Envelope, 21 Import Envelope, 21 Re-transmit Envelope, 21 SEPA-XML, 31

H

Hyphen, use of, 17

I

ISN number, 13

L

Location Code, 8

M

MAC calculation, 24 character set, 24 field exclusion, 27 trailer, 18, 24

Message priority, 13 Message type, 12 MIR, 12 MOR, 22 MT011. See Delivery Notification MUR. See Envelope reference

N

NOM trailer, 18 Normal priority, 13

O

OSN number, 11 OUR specification, 15 Output date, 13 Output time, 13

P

PDE trailer, 19 PDF trailer, 19 Product code, 15 Production system, 9

R

root tag, 31



S

SEPA, 31 SRC trailer, 18 Statistics, 23 sub block, 10 SYS Trailer, 19 System message, 6

T

Test system, 9 Text Block, 10, 16 TOT trailer, 18 Trailing blanks, 17

U

Urgent priority, 13

Use of colon, 17 Use of hyphen, 17 User Header Block, 14 User-to-User message, 6, 10

V

Value date, 15

X

XML, 31 root tag, 31

Y

Year 2000, 8

Documents

Eurogiro Envelope Format Specification · • Updated reference to SWIFT Standards • Added detailed description of field ... (MT category 1 to 9) which are used for financial transactions