Post by Sapphire Capital on Jul 28, 2008 21:28:26 GMT 4
Giovannini Protocol:
File Transfer Rulebook
May 2007
Table of contents
1 – Introduction 4
1.1 - Background and justification 4
1.2 - Terminology 4
1.3 - Scope 5
1.4 - Concepts 5
1.5 - Usage of the Exchange Header and Exchange Payload 6
2 – Guiding principles for the Exchange Header structure 7
2.1 Assumptions 7
2.2 High Level requirements 8
2.3 High Level requirements analysis 9
2.3.1. Routing the object exchanged to a destination 9
2.3.2. Identifying the object exchanged 9
2.3.3. Describing the type of the object exchanged 9
2.3.4. Giving processing information to the receiving party 11
2.3.5. File Naming Conventions 11
3 – Exchange Header logical model 12
3.1 - Content description 12
3.2 Exchange 13
3.3 Header 13
3.4 Party.Details 13
3.4.1 - ExchangeHeader.Sender 14
3.4.2 - ExchangeHeader.OriginalSender 14
3.4.3 - ExchangeHeader.Receiver 14
3.4.4 - ExchangeHeader.FinalReceiver 15
3.4.5 - Party.Details.Identifier 15
3.4.6 - Party.Details.Authority 15
3.5 Payload Description– 16
3.5.1 PayloadDetails 16
3.5.1.1 - PayloadDetails.PayloadIdentifier 17
3.5.1.2 - PayloadDetails.CreationDateAndTime 17
3.5.1.3 - PayloadDetails.PossibleDuplicateFlag 18
3.5.1.4 - PayloadDetails.PayloadStatus 18
3.5.1.5 - PayloadDetails.RelatedReference 18
3.5.1.6 - PayloadDetails.Priority 18
3.5.1.7 - PayloadDetails.TestIndicator 19
3.6 - PayloadTypeDetails 19
3.6.1 - PayloadTypeDetails.Type 19
3.6.2 - PayloadType.StandardFamily 19
3.6.3 - PayloadType.StandardVersion 20
3.6.4 – PayloadType.ProfileIdentification 20
3.7 - ManifestDetails 20
3.7.1 - ManifestDetails.DocumentType 20
3.7.2 - ManifestDetails.NumberOfDocuments 21
3.8 – ApplicationSpecificInformation 21
3.9 - Business Routing 22
3.10 – Technical Info 22
4 – File Transfer Rules 24
4.1 – File Construction 24
4.1.1 – Restrictions on content 24
4.1.2 – Restrictions on content mixture 24
4.2 – File Transfer Operations 24
4.2.1 – Authentication 24
4.2.2 – Non-Repudiation 25
5 – Rulebook Maintenance 27
6 - Examples 28
6.1. Exchange containing a set of 15022 messages 28
6.2. Alternative Exchange with Message Headers 29
7. References 31
8. Glossary: 32
End of document 32
1 – Introduction
1.1 - Background and justification
Following the publication of the final Giovannini Protocol in March 2006, representatives of the Independent Advisory Group (which approved the Protocol) identified the need for specific implementation guidance at the transfer layer, and for generic header properties and operational guidelines for file transfer implementations. This rulebook is the response to that need.
The ultimate goal of this rulebook is to improve interoperability between financial institutions, by removing several design tasks which have to be performed every time two institutions wish of exchange data with each other by file transfer. The target of this document is to identify generic header, content and operational requirements, organise them in a logical way, propose a structure to specify exchange business content declaration and structure and provide further guidance as to the actual implementation on transport layers, without prescribing specific implementations (nor proscribing others).
This document describes tools and methods to address some of the issues faced by parties exchanging files:
- description of the high level business content of the exchange. This description allows various processing steps, ranging from routing to the appropriate application, authorisation routines (e.g. if a copy function is used over the transport network), pre processing upon receipt of exchanges, etc...
- description of the organisation/layout of the exchange payload, i.e. the possibility to declare the number and types of instances concatenated in the exchange payload, as relevant and further processing instructions (compression, encryption, expected behaviours, etc...).
To date, there is no or little generic guidance for users as regards the above mentioned descriptions. Needs have been expressed and replied to in specific projects and implementations across different markets (e.g. securities and payments) and market segments (payment initiation, payments clearing and settlement...). This obviously increases interpretation risks, duplication of methods and does not provide any interoperability of implemented solutions from an end user perspective.
1.2 - Terminology
This document retains the following terminology:
• An exchanged object is named an Exchange. This distinction allows certain elements of this rulebook to be reused in direct messaging as well as in file transfer operations.
• An Exchange is made of an ExchangeHeader and an ExchangePayload.
• An ExchangeHeader is a set of data elements which describe the Exchange Payload and the rules under which it is constructed.
• An ExchangePayload can contain a Document, a DocumentSet or again a combination of Exchange Header and Exchange Payload (this construction allows to have several nested of exchange headers, if needed).
• A Document is an atomic dataset defined by a Standard setter to support a business function (eg. MT541, MT103, ISO 20022 pain.001.001.01, etc...).
• A DocumentSet is a group of homogeneous Documents
1.3 - Scope
This document provides a generic solution and messaging layer-independent way of declaring the content of an exchange between parties and the structure of the exchange payload.
As requested by representatives of the Independent Advisory Group (IAG) on the Giovannini Protocol, the business usage scope of this rulebook is intended to cover not just those exchanges governed by the Giovannini Protocol, but any payload which might need to be carried between two or more financial institutions.
Finally, the document includes specific rules concerning packaging of content for file transfer, and minimum standards of compliance for technical and security characteristics such as authentication and integrity.
As for the scope of the solution to which this rulebook relates, there is no constraint on exchange payload content.
The format of the headers defined in this rulebook will be XML. This implies that the rulebook is likely to be used to define file transfer interfaces which are built, re-architected or refreshed from the date of publication, where XML is in any case likely to be the format of choice. As exchange models are gradually migrated towards ISO20022, the legacy of non-XML header formats will reduce over time, thereby improving interoperability at a pace that is justified in individual business cases.
1.4 - Concepts
The concept developed revolves around the following steps:
1 - Business and technical requirements relating to exchanges are identified and translated into data requirements. These data requirements are classified function of their underlying purpose (business content declaration, technical coding of the file itself, structure declaration of the exchange payload, peripheral requirements (e.g. related to workflow) and organised into a logical structure;
2 - Definition of a service profile for the file transfer solution: this definition selects from the above set of requirements the relevant elements to be implemented as regards the type of business covered by the file transfer service (e.g. SEPA instruments, securities clearing and settlement). Each service profile will require some features and a given granularity derived from the business area addressed and the service described.
These first two steps are agnostic as to the underlying messaging solution and layer to be used for the actual transfer of the files.
3 – Implementation guideline of the service profile elements taking into account the messaging solution capabilities. This last layer will guide implementers in associating the service profile requirements with the messaging layer/product capabilities and selecting relevant elements from the generic logical structure in order to fulfil all service profile selected features. Some elements from the service profile may already be taken care of by the messaging solution selected (e.g. PKI signatures embedded), if this is not the case, the implementation should address the specific requirements in another way, using the capabilities of the exchange header.
1.5 - Usage of the Exchange Header and Exchange Payload
The Exchange Header is defined once but provides for:
- multiple usages at different levels (e.g. a first occurrence of the exchange header can be used for the high level business content declaration of the file content, and a second occurrence can be used for the structure declaration of the exchange payload).
- multiple packaging possibilities for the Exchange Payload (see 2.3.3 below)
The above possibilities are integrated in the exchange header and accommodate various exchange payload content from a very simple and homogeneous file payload to a rather complex scenario where a set of heterogeneous documents, each flagged by a specific exchange header, are compiled in a single exchange payload.
2 – Guiding principles for the Exchange Header structure
2.1 Assumptions
The Exchange header makes the following assumptions.
The functionality required for interoperability between Business Processes can be grouped into 3 layers:
The Business Layer implements the Business applications.
The Business Protocol determines the respective behaviour of Business Partners and the business information to be exchanged. Business Applications have to comply with rules defined by Standards setters and Regulatory Authorities but they are likely to have their own representation of the business information and their own way of processing the information.
Example: The SEPA Direct Debit and Credit Transfer Scheme Rulebooks define the datasets to be exchanged between Partners, the roles of the Partners and the business rules to follow. They do not provide any information about how to exchange the information.
The Standard Exchange Layer implements a set of services to allow for interoperability between business applications.
This layer corresponds to the Data Layer of the Giovannini Protocol.
To interoperate, business applications need to exchange information they all understand. The role of the Standards is to precisely define the information to exchange and in what sequence. The role of the rulebook is to specify additional rules and constraints that cannot be specified in the Standards.
The services provided by the Standard Exchange Layer are (non exhaustive list):
- the transformation of the business information into standard information (e.g. ISO 15022 or ISO 20022);
- the management of the information flow (e.g. determine the exact destination, determine the type of standard document to exchange...);
- the grouping of documents in an exchange.
Examples: ISO 15022, ISO 20022 or Edifact are examples of specifications to be supported by the Standard Exchange Layer. The EBA Step2 specification is another example: it describes the standards of the messages to be exchanged, how the information is packaged (files), who are the Senders and Receivers, etc.
The Transport Layer handles the actual exchange of information between the Business Partners. The functionality of the Transport layer may vary, depending on the product and the service provider; examples of transport-layer services include:
• Guaranteed Delivery
• Non repudiation of emission / reception
• Authentication of sender
• Data Integrity
• Encryption
• Compression
2.2 High Level requirements
The functions of a header are to:
• route the object exchanged to a destination;
• identify the object exchanged;
• describe the type of the object exchanged;
• give processing information to the receiving party.
2.3 High Level requirements analysis
2.3.1. Routing the object exchanged to a destination
Two types of routing requirements have been identified:
• Routing to a business entity: business entities are generally identified in a given community by the use of a single identifier. In the Financial community, for example, a BIC usually identifies a business entity.
• Routing to a business application: if this level of routing is required, there must be an agreement between the business entities to define routing criteria. It can be as simple as a string of characters or a more complex structure (e.g. BusinessRouting.ServiceIdentifier) .
2.3.2. Identifying the object exchanged
The Sender needs to assign a unique identification (PayloadDetails.PayloadIdentifier) to the object sent. In case the object is sent several times, the same identification must be used and additional information is needed to indicate why the same identification is sent again (PayloadDetails.PossibleDuplicateFlag).
Two cases can be envisaged:
• Possible Duplicate: the Sender’s Standard Exchange application does not know if the object has been received by the Receiver’s Standard Exchange application. Note that this is different from a Possible Duplicate at Transport Layer level.
• Duplicate: the Sender’s Standard Exchange application sends an object that has already been sent to the same Receiver.
The CreationDateAndTime is also added for traceability (creation of the object exchanged).
2.3.3. Describing the type of the object exchanged
If the exchanged object is in XML, it is self describing as an XML instance contains a schema declaration identifying the structure of the instance.
If the exchanged object is not in XML (e.g. an ISO 15022 message), it is not self describing. Its type needs to be declared by means of additional information (PayloadTypeDetails.StandardFamily).
The Sender can also assemble a set of objects and request the Transport Layer to transfer the set. The Receiver must be able to de-assemble the set and retrieve each individual document.
The following packaging possibilities are possible through single or repetitive usage of the Exchange Header:
1. Header + Document
2. Header + DocumentSet
3. Header + Header + Document
Although the latest possibility would be the recommendation for a long term point of convergence it is recognised that this may necessitate further integration work and would conflict with current implementations. Therefore care has been taken to leave some flexibility for an incremental implementation over time.
2.3.4. Giving processing information to the receiving party
The sender might need to provide additional information to support additional validation or specific processing to be performed by the receiver or any value added service provider.
The nature and the structure of this information need to be determined by the community defining the service. This is done through the definition of a service profile.
The header is designed in such a way that it can be easily extended.
2.3.5. File Naming Conventions
File naming conventions or requirements are not in the scope of this rulebook; business partners are expected to determine how much use to make of filenaming on a bilateral basis.
3 – Exchange Header logical model
3.1 - Content description
The entire block of information is called an “Exchange” and consists of “ExchangeHeader”, “PayloadDescription” and a placeholder for one or more instances of “Payload”.
Note that the “ExchangeHeader” can be used at various levels; indeed, an “Exchange” may start with the “PayloadDescription”. In this case, the “Payload” would contain an Exchange, made of an “ExchangeHeader”, “PayloadDescription” and “Payload”.
This structure is highly flexible, as the ExchangeHeader can be ignored at the Document Set level and appear at the Document level, as illustrated below:
The next section defines each component of this logical model and the metadata format requirements of each item according to the following table:
Reference Number Header Component item name Mandatory/Optional
Indicator Item Description
3.2 Exchange
An Exchange is composed of a Header, a PayloadDescription and a Payload.
3.3 Header
The ExchangeHeader component groups the information required to identify the sending and the receiving parties.
3.4 Party.Details
The component Party.Details is used to implement the Sender, OriginalSender, Receiver and FinalReceiver.
3.4.1 - ExchangeHeader.Sender
Definition: Identifies the party that transmits the exchange to the next party in the chain.
Additional Information: This structure identifies the effective business sender of the document, which might be different from the sending address potentially contained in the transmission header (as defined in the transport layer).
Requirements:
REQ.01 Sender M Identifies the party that transmits the exchange to the next party in the chain.
3.4.2 - ExchangeHeader.OriginalSender
Definition: Identifies the party that has delivered the file to the Sender for forward transmission.
Additional Information: In case the Sender is acting on behalf of another party, the same structure can be used to identify the primary sender of the document/document set.
Requirements:
REQ.02 OriginalSender O Identifies the party that has delivered the file to the Sender for forward transmission.
3.4.3 - ExchangeHeader.Receiver
Definition: Party that is instructed by a preceding party in the chain to carry out the processing of a file.
Additional Information: This structure identifies the effective business receiver of the document, which might be different from the receiving address potentially contained in the transmission header (as defined in the transport layer).
Requirements:
REQ.03 Receiver M Party that is instructed by a preceding party in the chain to carry out the processing of a file.
3.4.4 - ExchangeHeader.FinalReceiver
Definition: Party that should receive the document.
Additional Information: In case the Receiver is acting on behalf of another party, the same structure can be used to identify the final recipient of the document/document set.
Requirements:
REQ.04 FinalRecipient O Party that should ultimately receive the document.
3.4.5 - Party.Details.Identifier
Definition: Identifies a Party.
Additional Information: Any identifier can be used (BIC, UCC-EAN, Proprietary,...). The type of identifier to be used must be defined by the service provider (the organisation defining the standard exchange layer service) or when proprietary by the Business Partners performing the exchange.
Requirements:
REQ.05 Party.Details.Identifier O Unique Identifier of a Party.
3.4.6 - Party.Details.Authority
Definition: Qualifies the identifier of the Party.
Additional Information: This element identifies the type of Party.Details.Identifier. This element can be defined by the service provider but, ideally, this element should be standardised – for example:. ISO-6523 is a standard dealing with the identification of organisations defining coded information and identification schemes.
ISO-6523 defines two main concepts:
• the International Code Designator (ICD): “the identifier allocated to a particular identification scheme”
• the Issuing Organisation (IO): “a body that assumes responsibility for the administration of a specific identification scheme” (“Registration Authority” can be considered as equivalent to “Issuing Organisation”)
Example: ICD for DUNS is 0060, ICD for BIC is 0021.
Note: the British Standards Institute (BSI) is the Registration Authority for ICD’s.
Requirements:
REQ.06 Party.Details.Authority O The Type of PartyDetailsIdentifier used in REQ05.
3.5 Payload Description–
Definition: information about the payload
3.5.1 PayloadDetails
This component is used to identify the instance of the document exchanged.
3.5.1.1 - PayloadDetails.PayloadIdentifier
Definition: Point to point identification assigned by the instructing party and sent to the next party in the chain to unambiguously identify the file.
Additional Information: The sender has to make sure that 'Payload Identification' is unique per Sender for a pre-agreed period of time.
Requirements:
REQ.07 Payload Identifier M Point to point identification assigned by the instructing party and sent to the next party in the chain to unambiguously identify the payload.
3.5.1.2 - PayloadDetails.CreationDateAndTime
Definition: The date and time at which the file has been constructed (not sent).
Additional Information: This date and time corresponds to the time the payload has been created (from an application perspective).
Requirements:
REQ.08 File Creation Date M The date and time at which the file has been constructed (not sent)
3.5.1.3 - PayloadDetails.PossibleDuplicateFlag
Definition: Flag indicating if the payload exchanged between the two business applications is possibly a duplicate. If the receiving business application did not receive the original, then this message should be processed as if it was the original.
Note: if this element is set to TRUE, the receiver needs to check if he has already received this payload and perform the necessary actions to avoid processing this payload more than once. The default value of this field (if mandatory) should be FALSE. Requirements:
REQ.09 Possible duplicate indicator M* Flag indicating if the file exchanged between the two business applications is possibly a duplicate. If the receiving business application did not receive the original, then this message should be processed as if it was the original.
M* - this field is mandatory if the duplicate condition applies.
3.5.1.4 - PayloadDetails.PayloadStatus
Definition: Identifies the status of the exchanged payload: Original, Copy (copy of a payload to another destination), Duplicate (duplicate of a payload already sent to this destination).
Requirements:
REQ.10 PayloadStatus O Status (ie Original, Copy or Duplicate) of the Payload.
3.5.1.5 - PayloadDetails.RelatedReference
Definition: Reference to a linked payload that was previously exchanged.
Requirements:
REQ.11 RelatedReference O PayloadIdentifier of a related (and previous) exchange.
3.5.1.6 - PayloadDetails.Priority
Definition: Relative indication of the processing precedence of the payload over a set of files with assigned priorities.
Additional information: some systems are sorting out the payloads according to relative priorities assigned (for example when there is a shortage of available liquidity, some payloads may be flagged more critical then others – e.g. salary/pension payments versus commercial payments or the reverse).
Requirements:
REQ.12 Priority O Relative indication of the processing precedence of the file over a set of files with assigned priorities.
3.5.1.7 - PayloadDetails.TestIndicator
Definition: Indicates the file is sent in test mode or production (live) mode.
Default is 0 (Production mode).
Requirements:
REQ.13 Test Indicator O Indicates the file is sent in test mode or production (live) mode
3.6 - PayloadTypeDetails
Definition: Identification of the type of payload.
3.6.1 - PayloadTypeDetails.Type
Definition: Declaration of the payload content. Describes the type of business document being exchanged.
Additional information: when sending a copy or a duplicate of a previous document set, the document set identification must remain identical.
Requirements:
REQ.14 File Type M Declaration of the file content. Describes the type of business document being exchanged
3.6.2 - PayloadType.StandardFamily
Definition: Indicates the standard type the instance belongs to (ISO 15022, ISO 20022, EDIFACT, proprietary...).
Requirements:
REQ.15 Standard Family O Indicates the standard family and/or type the instance belongs to (ISO 15022, 20022, EDIFACT, proprietary...)
3.6.3 - PayloadType.StandardVersion
Definition: Indicates the version of the standards (e.g. D96.A for EDIFACT instances) or the message identifier (e.g. pacs.003.02.01).
Requirements:
REQ.16 Standard Version O Indicates the version of the standards (e.g. D96.A for EDIFACT instances) or the message identifier (e.g. pacs.003.02.01)
3.6.4 – PayloadType.ProfileIdentification
Definition: Indicates the specific rulebook profile used: SEPA, SEPANetting, Giovannini, Target2, or other bilaterally agreed values.
Requirements:
REQ.17 ProfileIdentification O Indicates the rulebook profile of the payload
3.7 - ManifestDetails
Definition: Manifest that describes the related items or attachments.
Additional information: this block is repeated for each different type of item.
3.7.1 - ManifestDetails.DocumentType
Definition: The type of items contained in the document set. An initial list of values can be found in the ISO20022 message type catalogue:
Business Document Type Short Code (from ISO20022 XML Schema name)
Administration admi
Cash Management camt
Payments Clearing and Settlement pacs
Payments Initiation pain
Reference Data reda
Securities Management semt
Securities Settlement sese
Securities Trade setr
Treasury trea
Requirements:
REQ.18 Message type O Indicates the instance business document type .
3.7.2 - ManifestDetails.NumberOfDocuments
Definition: The count of numbers of items in the document set.
Requirements:
REQ.19 Number of messages O Gives the number of instances (messages) for each declared type.
3.8 – ApplicationSpecificInformation
This block should contain business information that is considered as necessary by the service provider. The service provider should publish a specific schema for each set of business information.
This type of information depends on application specific services to be implemented on top of the exchange services.
Requirements (example business application: SEPA Netting):
REQ.20 FileCycleNumber O The target cycle for the clearing of the file.
REQ.21 TotalInterbankSettlementAmount O Total amount of money transferred between instructing agent and instructed agent.
REQ.22 TotalNumberOfTransactions M Total number of individual transactions contained in the file.
REQ.23 CreditDebitCode O Specifies if an operation is an increase (credit) or a decrease (debit).
REQ.24 InterbankSettlementDate O Date on which the amount of money ceases to be available to the agent that owes it and when the amount of money becomes available to the agent to which it is due.
3.9 - Business Routing
This block should contain information to route payload to route the documents to the application able to process it.
Requirements:
REQ.25 ServiceIdentifier M Name or code of a specific business process known to all parties (Senders and Receivers) that is used to process the instructions. The Service Identifier may be used as a pointer to a Rulebook.
3.10 – Technical Info
This block should contain information about the packaging information for the payload.
Requirements:
REQ.26 BatchingRule M Indicates whether the file contents are of a single version of a single standards family or not
REQ.27 DocumentDelimiterValue M Defines the character or sequence of characters which denotes the end of a document in an exchange
REQ.28 FileInfo O General information about the exchange payload
REQ.29 SWCompression O Information about the compression software and/or algorithm used to compress the exchange payload
REQ.30 CharSet O Definition of the character set of the payload (this should no be used if the character set is already implied by the standards family, e.g. ISO15022, ISO20022, Edifact etc)
REQ.31 Encryption O Information about any encryption software or algorithm used to protect the payload
4 – File Transfer Rules
4.1 – File Construction
This section defines the rules specific to the construction of files described by the header information above, to reduce the burden of bilateral negotiation between parties and thereby improve interoperability.
Error and exception handling procedures are out of scope of this rulebook.
4.1.1 – Restrictions on content
Provided that the rules specified in section 5.1.2 below are applied, there is no restriction on the nature or type of content allowed in an exchange.
4.1.2 – Restrictions on content mixture
Unless bilaterally agreed between a given sender/receiver pair, all documents in an Exchange will be of the same nature; specifically:
- an exchange consisting of binary images, .pdf files or similar will not be mixed with structured messages
- all structured messages in an exchange will be of the same Standards Family (for example, ISO15022 messages will not be mixed with ISO20022 message types)
- all structured messages in an exchange will be of the same Version (for example, messages of the standard camt.008.001.01 will not be mixed with camt.008.001.02) in a single exchange
- all content of a given exchange will be of the same mode (meaning that test messages cannot be sent alongside live messages in the same file, and further that test messages destined for one particular test environment may not be mixed with messages intended for a different test environment).
4.2 – File Transfer Operations
This section defines the generic requirements for file transfer operations. Note that there are no specific implementations described here; some file transfer systems embed their own private key systems, their own Non-Repudiation support and other characteristics, and it is not the intention of this rulebook to specify how any file transfer system should operate. Rather, this rulebook specifies the requirements for compliance, and it is expected that the operators of file transfer systems will construct their own detailed implementation guides – or rulebooks – which show how the requirements of this rulebook have been met.
4.2.1 – Authentication
It is a requirement that file transfers include a mechanism to prove the identity of the sender, and the integrity of the file. This will be implemented using Public Key Infrastructure, or PKI. The key characteristics of an appropriate implementation of PKI, to which all file transfers should comply, are:
• Integrity
When the Sender “signs” an Exchange with its digital signature provided by its PKI solution, the receiver of the exchange can confirm that the message content has not been changed during transmission by verifying the signature.
• Confidentiality
Document-level and/or exchange-level encryption guarantees that only the intended recipient can read and interpret the data, as it can be proved that the originator is the sole owner of a unique decryption key.
• Access control
Password-protected access for an individual or organisation to his, her or its private key stored in a secure and digital device.
Certain providers of file transfer services go further than this, provided value-added services designed to reduce the burden of implementation, operation and integration.
4.2.2 – Non-Repudiation
The precise wording in the Final Protocol Recommendation document itself specifies that Non-Repudiation (as well as the other security measures) are to be applied to “all machine-to-machine transfers” – and the Consultation document which preceded the Protocol specifically identified the scope of non-repudiation thus: ”Non repudiation (sender & receiver): Participants should not be able to deny that a message or file was exchanged as well as being able to guarantee the integrity of the content.”
Therefore, this Rulebook specifies that all exchanges under the Giovannini Protocol are to be protected by Non-Repudiation, of both Dispatch and Receipt, in addition to be able to guarantee content integrity.
That said, there are several different sets of standard requirements of non-repudiation set by individual countries and national jurisdictions, and this rulebook does not seek to superimpose additional requirements on any of these. Rather, the generic characteristics of non-repudiation are listed here to serve as a guideline, so that individual senders and receivers can check that their proposed file transfer service provider is compliant with local national rules as well as with the Giovannini Protocol.
The key characteristics of Non-Repudiation, to which all file transfers should comply, are:
• Transmission Logging
A mechanism to capture, record and archive the transmission log files of both sender and receiver, including the security context of the file (ie its signatures and certificates), and the transport-level timestamps
• Delivery Notification
A delivery notification mechanism, by which the receiver of a file is required to acknowledge receipt of the file (by explicitly acknowledging that the responsibility for processing the file contents is now firmly that of the receiver, and therefore that the header and its contents are readable – or by returning a negative acknowledgement with an error code if the content is not readable).
Note that there may be many forms of acceptable delivery notification, as defined and/or required by the specific non-repudiation context in which exchanges take place. This rulebook does not attempt to define or to harmonise these requirements – rather, the rulebook stipulates that since non-repudiation is a requirement of the Giovannini Protocol, some acceptable form of Delivery Notification needs to be part of any compliant file transfer solution. Within this constraint, business partners and their suppliers are free to determine their optimum implementation.
• Secure Archive
A secure archive facility that can be relied upon to store, and report, the transmission log files and delivery notification for any file in the previous 5 years, or the duration required by legal jurisdictions for sender or receiver, whichever is the higher.
5 – Rulebook Maintenance
This rulebook is maintained by:
SWIFT
Securities Market Reform Team
7th Floor, The Corn Exchange
55 Mark Lane
London EC3R 7NE
Telephone: +44 207 762 2030
Email: Andrew.muir@swift.com
The individual contributors to this rulebook, and the organisations they represent, are gratefully acknowledged below:
Name Organisation/s
John Booth Northern Trust, ISITC-IOA
Maurice Carn LCH.ClearNet
Luc Castan Euroclear
Gaël David BNP Securities Services
Genevy Dimitrion State Street, ISITC-IOA
Steve Feldstein Morgan Stanley
Steve Goswell Barclays Global Investors, ISITC-IOA
Andreas Hoefler Deutsche Bank
Alexandre Kech Securities Market Practice Group (SMPG)
Serge Logelain Clearstream
Patrick Poncelet FBE (European Banking Federation)
Benjamin Reches Morgan Stanley
Isaac Sazadaly LCH.ClearNet
Dharmesh Sethi Citigroup
Martin Stolz UBS, ISSA
Aki Tarri NCSD
Marc Winkler LCH.ClearNet
6 - Examples
6.1. Exchange containing a set of 15022 messages
6.2. Alternative Exchange with Message Headers
In the following example, each 15022 message is preceded by a Header:
7. References
The Giovannini Protocol Recommendation and its related documentation can be found at:
www.swift.com/index.cfm?item_id=43429
8. Glossary:
BIC Bank Identification Code
EBA Euro Bankers Association
FIX Financial Information eXchange
FOA Futures and Options Association
FPL FIX Protocol Ltd
FpML Financial Products Mark-up Language
G30 Group of Thirty
GUI Graphical User Interface
IBAN International Bank Account Number
IOSCO International Organisation of Securities Commissions
ISIN International Securities Identification Number
ISO International Organisation for Standardisation
ISO 15022 The ISO-Standard Data Field Dictionary and Message Catalogue for Securities Transactions
ISO 20022 The ISO-Standard methodology and design rules for developing XML messages and schemae from UML transaction models
ISSA International Securities Services Association
OTC Over The Counter
PKI Public Key Infrastructure
SEPA Single Euro Payment Area
SIS SegaInterSettle
SMPG Securities Market Practice Group
TARGET Trans-European Automated Real-time Gross settlement Express Transfer
UML Universal Modelling Language
XML Extensible Mark-up Language
File Transfer Rulebook
May 2007
Table of contents
1 – Introduction 4
1.1 - Background and justification 4
1.2 - Terminology 4
1.3 - Scope 5
1.4 - Concepts 5
1.5 - Usage of the Exchange Header and Exchange Payload 6
2 – Guiding principles for the Exchange Header structure 7
2.1 Assumptions 7
2.2 High Level requirements 8
2.3 High Level requirements analysis 9
2.3.1. Routing the object exchanged to a destination 9
2.3.2. Identifying the object exchanged 9
2.3.3. Describing the type of the object exchanged 9
2.3.4. Giving processing information to the receiving party 11
2.3.5. File Naming Conventions 11
3 – Exchange Header logical model 12
3.1 - Content description 12
3.2 Exchange 13
3.3 Header 13
3.4 Party.Details 13
3.4.1 - ExchangeHeader.Sender 14
3.4.2 - ExchangeHeader.OriginalSender 14
3.4.3 - ExchangeHeader.Receiver 14
3.4.4 - ExchangeHeader.FinalReceiver 15
3.4.5 - Party.Details.Identifier 15
3.4.6 - Party.Details.Authority 15
3.5 Payload Description– 16
3.5.1 PayloadDetails 16
3.5.1.1 - PayloadDetails.PayloadIdentifier 17
3.5.1.2 - PayloadDetails.CreationDateAndTime 17
3.5.1.3 - PayloadDetails.PossibleDuplicateFlag 18
3.5.1.4 - PayloadDetails.PayloadStatus 18
3.5.1.5 - PayloadDetails.RelatedReference 18
3.5.1.6 - PayloadDetails.Priority 18
3.5.1.7 - PayloadDetails.TestIndicator 19
3.6 - PayloadTypeDetails 19
3.6.1 - PayloadTypeDetails.Type 19
3.6.2 - PayloadType.StandardFamily 19
3.6.3 - PayloadType.StandardVersion 20
3.6.4 – PayloadType.ProfileIdentification 20
3.7 - ManifestDetails 20
3.7.1 - ManifestDetails.DocumentType 20
3.7.2 - ManifestDetails.NumberOfDocuments 21
3.8 – ApplicationSpecificInformation 21
3.9 - Business Routing 22
3.10 – Technical Info 22
4 – File Transfer Rules 24
4.1 – File Construction 24
4.1.1 – Restrictions on content 24
4.1.2 – Restrictions on content mixture 24
4.2 – File Transfer Operations 24
4.2.1 – Authentication 24
4.2.2 – Non-Repudiation 25
5 – Rulebook Maintenance 27
6 - Examples 28
6.1. Exchange containing a set of 15022 messages 28
6.2. Alternative Exchange with Message Headers 29
7. References 31
8. Glossary: 32
End of document 32
1 – Introduction
1.1 - Background and justification
Following the publication of the final Giovannini Protocol in March 2006, representatives of the Independent Advisory Group (which approved the Protocol) identified the need for specific implementation guidance at the transfer layer, and for generic header properties and operational guidelines for file transfer implementations. This rulebook is the response to that need.
The ultimate goal of this rulebook is to improve interoperability between financial institutions, by removing several design tasks which have to be performed every time two institutions wish of exchange data with each other by file transfer. The target of this document is to identify generic header, content and operational requirements, organise them in a logical way, propose a structure to specify exchange business content declaration and structure and provide further guidance as to the actual implementation on transport layers, without prescribing specific implementations (nor proscribing others).
This document describes tools and methods to address some of the issues faced by parties exchanging files:
- description of the high level business content of the exchange. This description allows various processing steps, ranging from routing to the appropriate application, authorisation routines (e.g. if a copy function is used over the transport network), pre processing upon receipt of exchanges, etc...
- description of the organisation/layout of the exchange payload, i.e. the possibility to declare the number and types of instances concatenated in the exchange payload, as relevant and further processing instructions (compression, encryption, expected behaviours, etc...).
To date, there is no or little generic guidance for users as regards the above mentioned descriptions. Needs have been expressed and replied to in specific projects and implementations across different markets (e.g. securities and payments) and market segments (payment initiation, payments clearing and settlement...). This obviously increases interpretation risks, duplication of methods and does not provide any interoperability of implemented solutions from an end user perspective.
1.2 - Terminology
This document retains the following terminology:
• An exchanged object is named an Exchange. This distinction allows certain elements of this rulebook to be reused in direct messaging as well as in file transfer operations.
• An Exchange is made of an ExchangeHeader and an ExchangePayload.
• An ExchangeHeader is a set of data elements which describe the Exchange Payload and the rules under which it is constructed.
• An ExchangePayload can contain a Document, a DocumentSet or again a combination of Exchange Header and Exchange Payload (this construction allows to have several nested of exchange headers, if needed).
• A Document is an atomic dataset defined by a Standard setter to support a business function (eg. MT541, MT103, ISO 20022 pain.001.001.01, etc...).
• A DocumentSet is a group of homogeneous Documents
1.3 - Scope
This document provides a generic solution and messaging layer-independent way of declaring the content of an exchange between parties and the structure of the exchange payload.
As requested by representatives of the Independent Advisory Group (IAG) on the Giovannini Protocol, the business usage scope of this rulebook is intended to cover not just those exchanges governed by the Giovannini Protocol, but any payload which might need to be carried between two or more financial institutions.
Finally, the document includes specific rules concerning packaging of content for file transfer, and minimum standards of compliance for technical and security characteristics such as authentication and integrity.
As for the scope of the solution to which this rulebook relates, there is no constraint on exchange payload content.
The format of the headers defined in this rulebook will be XML. This implies that the rulebook is likely to be used to define file transfer interfaces which are built, re-architected or refreshed from the date of publication, where XML is in any case likely to be the format of choice. As exchange models are gradually migrated towards ISO20022, the legacy of non-XML header formats will reduce over time, thereby improving interoperability at a pace that is justified in individual business cases.
1.4 - Concepts
The concept developed revolves around the following steps:
1 - Business and technical requirements relating to exchanges are identified and translated into data requirements. These data requirements are classified function of their underlying purpose (business content declaration, technical coding of the file itself, structure declaration of the exchange payload, peripheral requirements (e.g. related to workflow) and organised into a logical structure;
2 - Definition of a service profile for the file transfer solution: this definition selects from the above set of requirements the relevant elements to be implemented as regards the type of business covered by the file transfer service (e.g. SEPA instruments, securities clearing and settlement). Each service profile will require some features and a given granularity derived from the business area addressed and the service described.
These first two steps are agnostic as to the underlying messaging solution and layer to be used for the actual transfer of the files.
3 – Implementation guideline of the service profile elements taking into account the messaging solution capabilities. This last layer will guide implementers in associating the service profile requirements with the messaging layer/product capabilities and selecting relevant elements from the generic logical structure in order to fulfil all service profile selected features. Some elements from the service profile may already be taken care of by the messaging solution selected (e.g. PKI signatures embedded), if this is not the case, the implementation should address the specific requirements in another way, using the capabilities of the exchange header.
1.5 - Usage of the Exchange Header and Exchange Payload
The Exchange Header is defined once but provides for:
- multiple usages at different levels (e.g. a first occurrence of the exchange header can be used for the high level business content declaration of the file content, and a second occurrence can be used for the structure declaration of the exchange payload).
- multiple packaging possibilities for the Exchange Payload (see 2.3.3 below)
The above possibilities are integrated in the exchange header and accommodate various exchange payload content from a very simple and homogeneous file payload to a rather complex scenario where a set of heterogeneous documents, each flagged by a specific exchange header, are compiled in a single exchange payload.
2 – Guiding principles for the Exchange Header structure
2.1 Assumptions
The Exchange header makes the following assumptions.
The functionality required for interoperability between Business Processes can be grouped into 3 layers:
The Business Layer implements the Business applications.
The Business Protocol determines the respective behaviour of Business Partners and the business information to be exchanged. Business Applications have to comply with rules defined by Standards setters and Regulatory Authorities but they are likely to have their own representation of the business information and their own way of processing the information.
Example: The SEPA Direct Debit and Credit Transfer Scheme Rulebooks define the datasets to be exchanged between Partners, the roles of the Partners and the business rules to follow. They do not provide any information about how to exchange the information.
The Standard Exchange Layer implements a set of services to allow for interoperability between business applications.
This layer corresponds to the Data Layer of the Giovannini Protocol.
To interoperate, business applications need to exchange information they all understand. The role of the Standards is to precisely define the information to exchange and in what sequence. The role of the rulebook is to specify additional rules and constraints that cannot be specified in the Standards.
The services provided by the Standard Exchange Layer are (non exhaustive list):
- the transformation of the business information into standard information (e.g. ISO 15022 or ISO 20022);
- the management of the information flow (e.g. determine the exact destination, determine the type of standard document to exchange...);
- the grouping of documents in an exchange.
Examples: ISO 15022, ISO 20022 or Edifact are examples of specifications to be supported by the Standard Exchange Layer. The EBA Step2 specification is another example: it describes the standards of the messages to be exchanged, how the information is packaged (files), who are the Senders and Receivers, etc.
The Transport Layer handles the actual exchange of information between the Business Partners. The functionality of the Transport layer may vary, depending on the product and the service provider; examples of transport-layer services include:
• Guaranteed Delivery
• Non repudiation of emission / reception
• Authentication of sender
• Data Integrity
• Encryption
• Compression
2.2 High Level requirements
The functions of a header are to:
• route the object exchanged to a destination;
• identify the object exchanged;
• describe the type of the object exchanged;
• give processing information to the receiving party.
2.3 High Level requirements analysis
2.3.1. Routing the object exchanged to a destination
Two types of routing requirements have been identified:
• Routing to a business entity: business entities are generally identified in a given community by the use of a single identifier. In the Financial community, for example, a BIC usually identifies a business entity.
• Routing to a business application: if this level of routing is required, there must be an agreement between the business entities to define routing criteria. It can be as simple as a string of characters or a more complex structure (e.g. BusinessRouting.ServiceIdentifier) .
2.3.2. Identifying the object exchanged
The Sender needs to assign a unique identification (PayloadDetails.PayloadIdentifier) to the object sent. In case the object is sent several times, the same identification must be used and additional information is needed to indicate why the same identification is sent again (PayloadDetails.PossibleDuplicateFlag).
Two cases can be envisaged:
• Possible Duplicate: the Sender’s Standard Exchange application does not know if the object has been received by the Receiver’s Standard Exchange application. Note that this is different from a Possible Duplicate at Transport Layer level.
• Duplicate: the Sender’s Standard Exchange application sends an object that has already been sent to the same Receiver.
The CreationDateAndTime is also added for traceability (creation of the object exchanged).
2.3.3. Describing the type of the object exchanged
If the exchanged object is in XML, it is self describing as an XML instance contains a schema declaration identifying the structure of the instance.
If the exchanged object is not in XML (e.g. an ISO 15022 message), it is not self describing. Its type needs to be declared by means of additional information (PayloadTypeDetails.StandardFamily).
The Sender can also assemble a set of objects and request the Transport Layer to transfer the set. The Receiver must be able to de-assemble the set and retrieve each individual document.
The following packaging possibilities are possible through single or repetitive usage of the Exchange Header:
1. Header + Document
2. Header + DocumentSet
3. Header + Header + Document
Although the latest possibility would be the recommendation for a long term point of convergence it is recognised that this may necessitate further integration work and would conflict with current implementations. Therefore care has been taken to leave some flexibility for an incremental implementation over time.
2.3.4. Giving processing information to the receiving party
The sender might need to provide additional information to support additional validation or specific processing to be performed by the receiver or any value added service provider.
The nature and the structure of this information need to be determined by the community defining the service. This is done through the definition of a service profile.
The header is designed in such a way that it can be easily extended.
2.3.5. File Naming Conventions
File naming conventions or requirements are not in the scope of this rulebook; business partners are expected to determine how much use to make of filenaming on a bilateral basis.
3 – Exchange Header logical model
3.1 - Content description
The entire block of information is called an “Exchange” and consists of “ExchangeHeader”, “PayloadDescription” and a placeholder for one or more instances of “Payload”.
Note that the “ExchangeHeader” can be used at various levels; indeed, an “Exchange” may start with the “PayloadDescription”. In this case, the “Payload” would contain an Exchange, made of an “ExchangeHeader”, “PayloadDescription” and “Payload”.
This structure is highly flexible, as the ExchangeHeader can be ignored at the Document Set level and appear at the Document level, as illustrated below:
The next section defines each component of this logical model and the metadata format requirements of each item according to the following table:
Reference Number Header Component item name Mandatory/Optional
Indicator Item Description
3.2 Exchange
An Exchange is composed of a Header, a PayloadDescription and a Payload.
3.3 Header
The ExchangeHeader component groups the information required to identify the sending and the receiving parties.
3.4 Party.Details
The component Party.Details is used to implement the Sender, OriginalSender, Receiver and FinalReceiver.
3.4.1 - ExchangeHeader.Sender
Definition: Identifies the party that transmits the exchange to the next party in the chain.
Additional Information: This structure identifies the effective business sender of the document, which might be different from the sending address potentially contained in the transmission header (as defined in the transport layer).
Requirements:
REQ.01 Sender M Identifies the party that transmits the exchange to the next party in the chain.
3.4.2 - ExchangeHeader.OriginalSender
Definition: Identifies the party that has delivered the file to the Sender for forward transmission.
Additional Information: In case the Sender is acting on behalf of another party, the same structure can be used to identify the primary sender of the document/document set.
Requirements:
REQ.02 OriginalSender O Identifies the party that has delivered the file to the Sender for forward transmission.
3.4.3 - ExchangeHeader.Receiver
Definition: Party that is instructed by a preceding party in the chain to carry out the processing of a file.
Additional Information: This structure identifies the effective business receiver of the document, which might be different from the receiving address potentially contained in the transmission header (as defined in the transport layer).
Requirements:
REQ.03 Receiver M Party that is instructed by a preceding party in the chain to carry out the processing of a file.
3.4.4 - ExchangeHeader.FinalReceiver
Definition: Party that should receive the document.
Additional Information: In case the Receiver is acting on behalf of another party, the same structure can be used to identify the final recipient of the document/document set.
Requirements:
REQ.04 FinalRecipient O Party that should ultimately receive the document.
3.4.5 - Party.Details.Identifier
Definition: Identifies a Party.
Additional Information: Any identifier can be used (BIC, UCC-EAN, Proprietary,...). The type of identifier to be used must be defined by the service provider (the organisation defining the standard exchange layer service) or when proprietary by the Business Partners performing the exchange.
Requirements:
REQ.05 Party.Details.Identifier O Unique Identifier of a Party.
3.4.6 - Party.Details.Authority
Definition: Qualifies the identifier of the Party.
Additional Information: This element identifies the type of Party.Details.Identifier. This element can be defined by the service provider but, ideally, this element should be standardised – for example:. ISO-6523 is a standard dealing with the identification of organisations defining coded information and identification schemes.
ISO-6523 defines two main concepts:
• the International Code Designator (ICD): “the identifier allocated to a particular identification scheme”
• the Issuing Organisation (IO): “a body that assumes responsibility for the administration of a specific identification scheme” (“Registration Authority” can be considered as equivalent to “Issuing Organisation”)
Example: ICD for DUNS is 0060, ICD for BIC is 0021.
Note: the British Standards Institute (BSI) is the Registration Authority for ICD’s.
Requirements:
REQ.06 Party.Details.Authority O The Type of PartyDetailsIdentifier used in REQ05.
3.5 Payload Description–
Definition: information about the payload
3.5.1 PayloadDetails
This component is used to identify the instance of the document exchanged.
3.5.1.1 - PayloadDetails.PayloadIdentifier
Definition: Point to point identification assigned by the instructing party and sent to the next party in the chain to unambiguously identify the file.
Additional Information: The sender has to make sure that 'Payload Identification' is unique per Sender for a pre-agreed period of time.
Requirements:
REQ.07 Payload Identifier M Point to point identification assigned by the instructing party and sent to the next party in the chain to unambiguously identify the payload.
3.5.1.2 - PayloadDetails.CreationDateAndTime
Definition: The date and time at which the file has been constructed (not sent).
Additional Information: This date and time corresponds to the time the payload has been created (from an application perspective).
Requirements:
REQ.08 File Creation Date M The date and time at which the file has been constructed (not sent)
3.5.1.3 - PayloadDetails.PossibleDuplicateFlag
Definition: Flag indicating if the payload exchanged between the two business applications is possibly a duplicate. If the receiving business application did not receive the original, then this message should be processed as if it was the original.
Note: if this element is set to TRUE, the receiver needs to check if he has already received this payload and perform the necessary actions to avoid processing this payload more than once. The default value of this field (if mandatory) should be FALSE. Requirements:
REQ.09 Possible duplicate indicator M* Flag indicating if the file exchanged between the two business applications is possibly a duplicate. If the receiving business application did not receive the original, then this message should be processed as if it was the original.
M* - this field is mandatory if the duplicate condition applies.
3.5.1.4 - PayloadDetails.PayloadStatus
Definition: Identifies the status of the exchanged payload: Original, Copy (copy of a payload to another destination), Duplicate (duplicate of a payload already sent to this destination).
Requirements:
REQ.10 PayloadStatus O Status (ie Original, Copy or Duplicate) of the Payload.
3.5.1.5 - PayloadDetails.RelatedReference
Definition: Reference to a linked payload that was previously exchanged.
Requirements:
REQ.11 RelatedReference O PayloadIdentifier of a related (and previous) exchange.
3.5.1.6 - PayloadDetails.Priority
Definition: Relative indication of the processing precedence of the payload over a set of files with assigned priorities.
Additional information: some systems are sorting out the payloads according to relative priorities assigned (for example when there is a shortage of available liquidity, some payloads may be flagged more critical then others – e.g. salary/pension payments versus commercial payments or the reverse).
Requirements:
REQ.12 Priority O Relative indication of the processing precedence of the file over a set of files with assigned priorities.
3.5.1.7 - PayloadDetails.TestIndicator
Definition: Indicates the file is sent in test mode or production (live) mode.
Default is 0 (Production mode).
Requirements:
REQ.13 Test Indicator O Indicates the file is sent in test mode or production (live) mode
3.6 - PayloadTypeDetails
Definition: Identification of the type of payload.
3.6.1 - PayloadTypeDetails.Type
Definition: Declaration of the payload content. Describes the type of business document being exchanged.
Additional information: when sending a copy or a duplicate of a previous document set, the document set identification must remain identical.
Requirements:
REQ.14 File Type M Declaration of the file content. Describes the type of business document being exchanged
3.6.2 - PayloadType.StandardFamily
Definition: Indicates the standard type the instance belongs to (ISO 15022, ISO 20022, EDIFACT, proprietary...).
Requirements:
REQ.15 Standard Family O Indicates the standard family and/or type the instance belongs to (ISO 15022, 20022, EDIFACT, proprietary...)
3.6.3 - PayloadType.StandardVersion
Definition: Indicates the version of the standards (e.g. D96.A for EDIFACT instances) or the message identifier (e.g. pacs.003.02.01).
Requirements:
REQ.16 Standard Version O Indicates the version of the standards (e.g. D96.A for EDIFACT instances) or the message identifier (e.g. pacs.003.02.01)
3.6.4 – PayloadType.ProfileIdentification
Definition: Indicates the specific rulebook profile used: SEPA, SEPANetting, Giovannini, Target2, or other bilaterally agreed values.
Requirements:
REQ.17 ProfileIdentification O Indicates the rulebook profile of the payload
3.7 - ManifestDetails
Definition: Manifest that describes the related items or attachments.
Additional information: this block is repeated for each different type of item.
3.7.1 - ManifestDetails.DocumentType
Definition: The type of items contained in the document set. An initial list of values can be found in the ISO20022 message type catalogue:
Business Document Type Short Code (from ISO20022 XML Schema name)
Administration admi
Cash Management camt
Payments Clearing and Settlement pacs
Payments Initiation pain
Reference Data reda
Securities Management semt
Securities Settlement sese
Securities Trade setr
Treasury trea
Requirements:
REQ.18 Message type O Indicates the instance business document type .
3.7.2 - ManifestDetails.NumberOfDocuments
Definition: The count of numbers of items in the document set.
Requirements:
REQ.19 Number of messages O Gives the number of instances (messages) for each declared type.
3.8 – ApplicationSpecificInformation
This block should contain business information that is considered as necessary by the service provider. The service provider should publish a specific schema for each set of business information.
This type of information depends on application specific services to be implemented on top of the exchange services.
Requirements (example business application: SEPA Netting):
REQ.20 FileCycleNumber O The target cycle for the clearing of the file.
REQ.21 TotalInterbankSettlementAmount O Total amount of money transferred between instructing agent and instructed agent.
REQ.22 TotalNumberOfTransactions M Total number of individual transactions contained in the file.
REQ.23 CreditDebitCode O Specifies if an operation is an increase (credit) or a decrease (debit).
REQ.24 InterbankSettlementDate O Date on which the amount of money ceases to be available to the agent that owes it and when the amount of money becomes available to the agent to which it is due.
3.9 - Business Routing
This block should contain information to route payload to route the documents to the application able to process it.
Requirements:
REQ.25 ServiceIdentifier M Name or code of a specific business process known to all parties (Senders and Receivers) that is used to process the instructions. The Service Identifier may be used as a pointer to a Rulebook.
3.10 – Technical Info
This block should contain information about the packaging information for the payload.
Requirements:
REQ.26 BatchingRule M Indicates whether the file contents are of a single version of a single standards family or not
REQ.27 DocumentDelimiterValue M Defines the character or sequence of characters which denotes the end of a document in an exchange
REQ.28 FileInfo O General information about the exchange payload
REQ.29 SWCompression O Information about the compression software and/or algorithm used to compress the exchange payload
REQ.30 CharSet O Definition of the character set of the payload (this should no be used if the character set is already implied by the standards family, e.g. ISO15022, ISO20022, Edifact etc)
REQ.31 Encryption O Information about any encryption software or algorithm used to protect the payload
4 – File Transfer Rules
4.1 – File Construction
This section defines the rules specific to the construction of files described by the header information above, to reduce the burden of bilateral negotiation between parties and thereby improve interoperability.
Error and exception handling procedures are out of scope of this rulebook.
4.1.1 – Restrictions on content
Provided that the rules specified in section 5.1.2 below are applied, there is no restriction on the nature or type of content allowed in an exchange.
4.1.2 – Restrictions on content mixture
Unless bilaterally agreed between a given sender/receiver pair, all documents in an Exchange will be of the same nature; specifically:
- an exchange consisting of binary images, .pdf files or similar will not be mixed with structured messages
- all structured messages in an exchange will be of the same Standards Family (for example, ISO15022 messages will not be mixed with ISO20022 message types)
- all structured messages in an exchange will be of the same Version (for example, messages of the standard camt.008.001.01 will not be mixed with camt.008.001.02) in a single exchange
- all content of a given exchange will be of the same mode (meaning that test messages cannot be sent alongside live messages in the same file, and further that test messages destined for one particular test environment may not be mixed with messages intended for a different test environment).
4.2 – File Transfer Operations
This section defines the generic requirements for file transfer operations. Note that there are no specific implementations described here; some file transfer systems embed their own private key systems, their own Non-Repudiation support and other characteristics, and it is not the intention of this rulebook to specify how any file transfer system should operate. Rather, this rulebook specifies the requirements for compliance, and it is expected that the operators of file transfer systems will construct their own detailed implementation guides – or rulebooks – which show how the requirements of this rulebook have been met.
4.2.1 – Authentication
It is a requirement that file transfers include a mechanism to prove the identity of the sender, and the integrity of the file. This will be implemented using Public Key Infrastructure, or PKI. The key characteristics of an appropriate implementation of PKI, to which all file transfers should comply, are:
• Integrity
When the Sender “signs” an Exchange with its digital signature provided by its PKI solution, the receiver of the exchange can confirm that the message content has not been changed during transmission by verifying the signature.
• Confidentiality
Document-level and/or exchange-level encryption guarantees that only the intended recipient can read and interpret the data, as it can be proved that the originator is the sole owner of a unique decryption key.
• Access control
Password-protected access for an individual or organisation to his, her or its private key stored in a secure and digital device.
Certain providers of file transfer services go further than this, provided value-added services designed to reduce the burden of implementation, operation and integration.
4.2.2 – Non-Repudiation
The precise wording in the Final Protocol Recommendation document itself specifies that Non-Repudiation (as well as the other security measures) are to be applied to “all machine-to-machine transfers” – and the Consultation document which preceded the Protocol specifically identified the scope of non-repudiation thus: ”Non repudiation (sender & receiver): Participants should not be able to deny that a message or file was exchanged as well as being able to guarantee the integrity of the content.”
Therefore, this Rulebook specifies that all exchanges under the Giovannini Protocol are to be protected by Non-Repudiation, of both Dispatch and Receipt, in addition to be able to guarantee content integrity.
That said, there are several different sets of standard requirements of non-repudiation set by individual countries and national jurisdictions, and this rulebook does not seek to superimpose additional requirements on any of these. Rather, the generic characteristics of non-repudiation are listed here to serve as a guideline, so that individual senders and receivers can check that their proposed file transfer service provider is compliant with local national rules as well as with the Giovannini Protocol.
The key characteristics of Non-Repudiation, to which all file transfers should comply, are:
• Transmission Logging
A mechanism to capture, record and archive the transmission log files of both sender and receiver, including the security context of the file (ie its signatures and certificates), and the transport-level timestamps
• Delivery Notification
A delivery notification mechanism, by which the receiver of a file is required to acknowledge receipt of the file (by explicitly acknowledging that the responsibility for processing the file contents is now firmly that of the receiver, and therefore that the header and its contents are readable – or by returning a negative acknowledgement with an error code if the content is not readable).
Note that there may be many forms of acceptable delivery notification, as defined and/or required by the specific non-repudiation context in which exchanges take place. This rulebook does not attempt to define or to harmonise these requirements – rather, the rulebook stipulates that since non-repudiation is a requirement of the Giovannini Protocol, some acceptable form of Delivery Notification needs to be part of any compliant file transfer solution. Within this constraint, business partners and their suppliers are free to determine their optimum implementation.
• Secure Archive
A secure archive facility that can be relied upon to store, and report, the transmission log files and delivery notification for any file in the previous 5 years, or the duration required by legal jurisdictions for sender or receiver, whichever is the higher.
5 – Rulebook Maintenance
This rulebook is maintained by:
SWIFT
Securities Market Reform Team
7th Floor, The Corn Exchange
55 Mark Lane
London EC3R 7NE
Telephone: +44 207 762 2030
Email: Andrew.muir@swift.com
The individual contributors to this rulebook, and the organisations they represent, are gratefully acknowledged below:
Name Organisation/s
John Booth Northern Trust, ISITC-IOA
Maurice Carn LCH.ClearNet
Luc Castan Euroclear
Gaël David BNP Securities Services
Genevy Dimitrion State Street, ISITC-IOA
Steve Feldstein Morgan Stanley
Steve Goswell Barclays Global Investors, ISITC-IOA
Andreas Hoefler Deutsche Bank
Alexandre Kech Securities Market Practice Group (SMPG)
Serge Logelain Clearstream
Patrick Poncelet FBE (European Banking Federation)
Benjamin Reches Morgan Stanley
Isaac Sazadaly LCH.ClearNet
Dharmesh Sethi Citigroup
Martin Stolz UBS, ISSA
Aki Tarri NCSD
Marc Winkler LCH.ClearNet
6 - Examples
6.1. Exchange containing a set of 15022 messages
6.2. Alternative Exchange with Message Headers
In the following example, each 15022 message is preceded by a Header:
7. References
The Giovannini Protocol Recommendation and its related documentation can be found at:
www.swift.com/index.cfm?item_id=43429
8. Glossary:
BIC Bank Identification Code
EBA Euro Bankers Association
FIX Financial Information eXchange
FOA Futures and Options Association
FPL FIX Protocol Ltd
FpML Financial Products Mark-up Language
G30 Group of Thirty
GUI Graphical User Interface
IBAN International Bank Account Number
IOSCO International Organisation of Securities Commissions
ISIN International Securities Identification Number
ISO International Organisation for Standardisation
ISO 15022 The ISO-Standard Data Field Dictionary and Message Catalogue for Securities Transactions
ISO 20022 The ISO-Standard methodology and design rules for developing XML messages and schemae from UML transaction models
ISSA International Securities Services Association
OTC Over The Counter
PKI Public Key Infrastructure
SEPA Single Euro Payment Area
SIS SegaInterSettle
SMPG Securities Market Practice Group
TARGET Trans-European Automated Real-time Gross settlement Express Transfer
UML Universal Modelling Language
XML Extensible Mark-up Language