File Transfer Rule Book - SWIFT by pengxiang

VIEWS: 1 PAGES: 32

									              Giovannini Protocol – File Transfer Rulebook – Final




Giovannini Protocol:
File Transfer Rulebook




May 2007




1                            GiovanniniProtocol_FTRulebook.doc
                                                              Giovannini Protocol – File Transfer Rulebook – Final




                                                           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

2                                                                                      GiovanniniProtocol_FTRulebook.doc
                                                             Giovannini Protocol – File Transfer Rulebook – Final




        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




3                                                                                     GiovanniniProtocol_FTRulebook.doc
                                          Giovannini Protocol – File Transfer Rulebook – Final




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...).


4                                                          GiovanniniProtocol_FTRulebook.doc
                                            Giovannini Protocol – File Transfer Rulebook – Final




       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

5                                                             GiovanniniProtocol_FTRulebook.doc
                                         Giovannini Protocol – File Transfer Rulebook – Final




    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.




6                                                        GiovanniniProtocol_FTRulebook.doc
                                             Giovannini Protocol – File Transfer Rulebook – Final




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:




               Business Layer          Business          Business Protocol          Business
                                      Application                                  Application




                                  Standard Exchange                            Standard Exchange
              Standard Exchange                         Interchange Protocol
                                      Application                                  Application
                    Layer




                                  Data Exchange (File                          Data Exchange (File
                                       Transfer /         Communication             Transfer /
               Transport Layer                              protocols
                                      Messaging)                                   Messaging)




                                                           Information flow




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.



7                                                                   GiovanniniProtocol_FTRulebook.doc
                                          Giovannini Protocol – File Transfer Rulebook – Final




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.




8                                                             GiovanniniProtocol_FTRulebook.doc
                                         Giovannini Protocol – File Transfer Rulebook – Final




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.




9                                                         GiovanniniProtocol_FTRulebook.doc
                                                   Giovannini Protocol – File Transfer Rulebook – Final




The following packaging possibilities are possible through single or repetitive usage of the
Exchange Header:


     1. Header + Document
                       Exchange
                                                 Header
                        Header




                      Exchange
                                                          Document
                       Payload




     2. Header + DocumentSet

                  Exchange
                                                           Header
                   Header




                                                                     Document




                  Exchange
                                  Document Set                       Document
                   Payload




                                                                     Document




     3. Header + Header + Document

                  Exchange
                                                    Header
                   Header


                                  Exchange
                                                                 Header
                                   Header




                                  Exchange
                                   Payload                                Document



                  Exchange
                   Payload
                                  Exchange
                                                                 Header
                                   Header




                                  Exchange
                                   Payload                                Document




10                                                                               GiovanniniProtocol_FTRulebook.doc
                                          Giovannini Protocol – File Transfer Rulebook – Final




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.




11                                                        GiovanniniProtocol_FTRulebook.doc
                                        Giovannini Protocol – File Transfer Rulebook – Final




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:




12                                                      GiovanniniProtocol_FTRulebook.doc
                                        Giovannini Protocol – File Transfer Rulebook – Final




The next section defines each component of this logical model and the metadata format
requirements of each item according to the following table:


 Reference   Header Component item         Mandatory/   Item Description
 Number      name                           Optional
                                            Indicator



     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.




13                                                      GiovanniniProtocol_FTRulebook.doc
                                             Giovannini Protocol – File Transfer Rulebook – Final




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).


14                                                           GiovanniniProtocol_FTRulebook.doc
                                              Giovannini Protocol – File Transfer Rulebook – Final




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”

15                                                             GiovanniniProtocol_FTRulebook.doc
                                            Giovannini Protocol – File Transfer Rulebook – Final




        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.




16                                                           GiovanniniProtocol_FTRulebook.doc
                                            Giovannini Protocol – File Transfer Rulebook – Final




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)




17                                                           GiovanniniProtocol_FTRulebook.doc
                                           Giovannini Protocol – File Transfer Rulebook – Final




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   M*    Flag indicating if the file exchanged between the two
           indicator                        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:


18                                                         GiovanniniProtocol_FTRulebook.doc
                                            Giovannini Protocol – File Transfer Rulebook – Final




 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...).

19                                                           GiovanniniProtocol_FTRulebook.doc
                                            Giovannini Protocol – File Transfer Rulebook – Final




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:




20                                                           GiovanniniProtocol_FTRulebook.doc
                                          Giovannini Protocol – File Transfer Rulebook – Final




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.




21                                                       GiovanniniProtocol_FTRulebook.doc
                                          Giovannini Protocol – File Transfer Rulebook – Final




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.




22                                                       GiovanniniProtocol_FTRulebook.doc
                                       Giovannini Protocol – File Transfer Rulebook – Final




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




23                                                     GiovanniniProtocol_FTRulebook.doc
                                           Giovannini Protocol – File Transfer Rulebook – Final




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:


24                                                          GiovanniniProtocol_FTRulebook.doc
                                            Giovannini Protocol – File Transfer Rulebook – Final




        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.


25                                                           GiovanniniProtocol_FTRulebook.doc
                                            Giovannini Protocol – File Transfer Rulebook – Final




        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.




26                                                           GiovanniniProtocol_FTRulebook.doc
                                           Giovannini Protocol – File Transfer Rulebook – Final




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


27                                                          GiovanniniProtocol_FTRulebook.doc
                            Giovannini Protocol – File Transfer Rulebook – Final




6 - Examples

6.1. Exchange containing a set of 15022 messages




28                                         GiovanniniProtocol_FTRulebook.doc
                                    Giovannini Protocol – File Transfer Rulebook – Final




6.2. Alternative Exchange with Message Headers
In the following example, each 15022 message is preceded by a Header:




29                                                 GiovanniniProtocol_FTRulebook.doc
     Giovannini Protocol – File Transfer Rulebook – Final




30                  GiovanniniProtocol_FTRulebook.doc
                                       Giovannini Protocol – File Transfer Rulebook – Final




7. References
The Giovannini Protocol Recommendation and its related documentation can be found at:

www.swift.com/index.cfm?item_id=43429




31                                                    GiovanniniProtocol_FTRulebook.doc
                                    Giovannini Protocol – File Transfer Rulebook – Final




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


End of document

32                                                   GiovanniniProtocol_FTRulebook.doc

								
To top