FIX SO mapping FIX Protocol

Document Sample
FIX SO mapping FIX Protocol Powered By Docstoc
					         A NEW APPROACH TO STP:MAPPING FIX 4.4 –
                      ISO15022
1.  Introduction and Executive Summary .................................................................. 32
  1.1    Achieving the reality – STP Lite .................................................................... 32                    Formatted
  1.2    Suggested method ........................................................................................ 43                Formatted
2. FIX Component Blocks ......................................................................................... 73
  2.1    Parties ........................................................................................................... 73
  2.2    NestedParties ................................................................................................ 73
  2.3    SettlInstructions and SettlParties .................................................................. 74
3. Location and Content of Component Blocks........................................................ 84
  3.1    FIX Message - Allocation Instruction ............................................................ 84
  3.2    FIX Message - Confirmation ......................................................................... 84
4. Which Party and Where? ..................................................................................... 95
5. Party ...................................................................................................................... 95
  5.1    PartyRoles ..................................................................................................... 95
  5.2    PartyIDSource ............................................................................................. 107
    5.2.1 PartyIDSource for Firms ............................................................................ 117
    5.2.2 PartyIDSource for Broker of Credit: .......................................................... 117
    5.2.3 PartyIDSource for Settlement Location..................................................... 117
    5.2.4 PartyIDSource for Buyer/Seller, Custodian, Intermediary or Agent ......... 128
  5.3    PartySubID .................................................................................................. 128
6. Settlement Instructions ....................................................................................... 139
  6.1    Use of <SettlInstructions> Component Block ............................................. 139
  6.2    SettlParties Component Block .................................................................. 1611
    6.2.1 SettlParty ................................................................................................. 1611
    6.2.2 SettlPartySubID ....................................................................................... 1612
7. Mapping FIX to ISO15022 ................................................................................ 1612
  7.1    Towards the Rosetta Stone ...................................................................... 1612
8. Settlement Party Mapping ................................................................................ 1812
  8.1    Introduction ................................................................................................ 1812
  8.2    Method ....................................................................................................... 1813
  8.3    Mapping Conventions ............................................................................... 1813
    8.3.1 Place of Settlement (PSET) Sequence ................................................... 1913
    8.3.2 Executing Broker Sequence (BUYR/SELL) ............................................ 2014
    8.3.3 Executing Broker – Safekeeping Account .............................................. 2116
  8.4    Receiving/Delivering Agent Sequence (REAG/DEAG) ............................ 2217
    8.4.1 REAG/DEAG Party Identifier................................................................... 2217
    8.4.2 REAG/DEAG Safekeeping Account........................................................ 2419
  8.5    Clearing Broker Sequence (DECU/RECU)............................................... 2520
    8.5.1 Clearing Broker – Party Identifier ............................................................ 2520
  8.6    Example Messages ................................................................................... 2620
9. Settlement Instructions Message ..................................................................... 3022
  9.1    Settlement Instructions.............................................................................. 3023
10.    Custodian – Institution SSI Updates ............................................................. 3224
  10.1      Security type .......................................................................................... 3224
  10.2      Product................................................................................................... 3225
  10.3      SecurityType .......................................................................................... 3325
  10.4      Classification of Financial Instrument (CFI) Code ................................ 3528
11.    SSI Update Messages .................................................................................. 3629
  11.1      Buyside Entity and Fund Identifiers....................................................... 3629
12.    Appendix 1 – Relational Integrity .................................................................. 3831
13.    Appendix 2 – MT54x Sequence E ................................................................ 5032


                                                                1
1.  INTRODUCTION AND EXECUTIVE SUMMARY ................................................. 2
2.  PROPOSED POST-EXECUTION FLOW .............................................................. 3
  2.1    Overview......................................................................................................... 3
  2.2    Implementation .............................................................................................. 3
3. FIX SETTLEMENT AND PARTIES INFORMATION ............................................ 5
4. Component Blocks ............................................................................................... 5
  4.1    Parties ............................................................................................................. 5
  4.2    NestedParties ................................................................................................ 5
  4.3    SettlInstructions and SettlParties ............................................................... 5
5. Location and Content of Component Blocks.................................................... 6
  5.1    Allocation Instruction ................................................................................... 6
  5.2    Confirmation .................................................................................................. 6
6. Which Party and Where? ..................................................................................... 7
7. PARTY .................................................................................................................... 7
  7.1    PartyRoles ...................................................................................................... 7
  7.2    PartyIDSource................................................................................................ 8
    7.2.1    PartyIDSource for Firms ....................................................................... 8
    7.2.2    PartyIDSource for Broker of Credit: .................................................... 9
    7.2.3    PartyIDSource for Settlement Location .............................................. 9
    7.2.4    PartyIdSource for Buyer/Seller, Custodian, Intermediary or Agent 9
  7.3    PartySubID ..................................................................................................... 9
8. SETTLEMENT INSTRUCTIONS ......................................................................... 10
  8.1    Use of <SettlInstructions> Component Block ......................................... 10
    8.1.1    Allocation Instruction, Allocation Report or Settlement Instruction
             11
    8.1.2    Confirmation ......................................................................................... 12
  8.2    SettlParty ...................................................................................................... 12
    8.2.1    SettlPartySubID .................................................................................... 12
9. MAPPING FIX to ISO15022 ................................................................................ 13
  9.1    Towards the Rosetta Stone........................................................................ 13
  9.2    Some Worked Examples ............................................................................ 13
    9.2.1    PSET ...................................................................................................... 13
    9.2.2    CSD Identifiers ..................................................................................... 13
    9.2.3    Putting it all together ........................................................................... 14
10.    SSI Enrichment ............................................................................................... 15
11.    SETTLEMENT INSTRUCTIONS MESSAGE .................................................. 16
  11.1     Settlement Instructions .......................................................................... 16
12.    APPENDIX 1 – RELATIONAL INTEGRITY .................................................... 18
13.    APPENDIX 2 – IDENTIFYING FUNDS AND LEGAL ENTITIES .................... 19
  13.1     Statement of Problem ............................................................................. 19
  13.2     Assumptions ............................................................................................ 19
    13.2.1 Example Data Structure ...................................................................... 20
  13.3     Scope ........................................................................................................ 20
  13.4     Suggested Implementation .................................................................... 20
    13.4.1 Ideal Structure ...................................................................................... 20
  13.5     Just-in-Time SDI Enrichment ................................................................. 23
  13.6     Regulatory Considerations .................................................................... 24
  13.7     Administration and Control .................................................................... 24
  13.8     Risk ........................................................................................................... 24
    13.8.1 Project Risk .......................................................................................... 24
    13.8.2 Operational Risk Reduction ............................................................... 24




                                                               2
Version     Author                    Date          Notes
0.1         Simon Leighton-Porter     22 May 03     First draft
0.2         Simon Leighton-Porter     26 May 03     Addition of parties information
0.3         Simon Leighton-Porter     27 May 03     Minor
0.4         Simon Leighton-Porter     28 May 03     Minor
0.5         Simon Leighton-Porter     1 Aug 03      Re-write of mapping information
0.6         Simon Leighton-Porter     6 Aug 03      Re-formatted
0.61        Simon Leighton-Porter     4 Sep 03      Amendments as suggested by
                                                    Alvin Mullan

Acknowledgements: much of the text of this document has been taken directly or
paraphrased from the FIX 4.4 specification published by FPL. ISO15022 settlement
parties section contributed by Sean O’Farrell (Gartmore). SMPG summary for MT54x
messages contributed by Activest.

1. Introduction aAnd Executive Summary
This paper shows how FIX 4.4 could be used for all post-execution messaging up to,
but not including, settlement messages. It suggests a method for real-time message
enrichment with SSIs and net moneyThis paper and sets out proposed data formats
for the new flow with the aims of standardising tag usage and achieving ISO15022
compliance.

Main aimsaddresses a number of fundamental aims affecting the global securities
industry:
 1. Achieving efficient cross-border STP at minimum cost to all industry participants.
 2. Making best use of the new post-execution functionality within FIX 4.4
 3. Defining and agreeing the data standards to be used in the new environment so
    that FIX can be mapped unambiguously to SWIFT in ISO15022 format.

The method proposed relies on the use of FIX for all post-execution messaging up to,
but not including, settlement messages. It provides for real-time message enrichment
with SDIs and net money. In addition, it proposes a method for identifying legal
counterparties and their funds without the use of proprietary databases. These
capabilities give the industry a viable, low-cost STP model.

The paper is broken into 34 main sections:
1. A high-level description of the proposed flow.
2. Overview of FIX component blocks and their uses.
3. FIX to SWIFT mapping
4.Legal entity and fund identifiers                                                        Formatted: Bullets and Numbering
                                                                                           Formatted
1.1
                                                                                           Formatted
1.21.1 Achieving the reality – STP Lite
If participants to a trade can agree basic trade details, net money, and settlement
instructions, there is a high probability that the trade will settle on time. This paper
assumes that the basic trade details such as buy/sell, security, quantity, price can be
stated in FIX and translated into an MT54x message without undue difficulty.
Therefore, the most pressing remaining task is to define how FIX settlement                Formatted
information should could be used for each combination of market, instrument and
settlement location.




                                           3
The STP Lite flow proposes a solution similar to that suggested by the GSTPA
initiative, with the aim of achieving real-time message enrichment and trade-date
matching and affirmation. The problem with such a flow is how to get the buy-side’s
settlement instructions (and net money) to the broker. STP Lite proposes that
investment managers create a database within their IT infrastructure that will be
populated with Standing Settlement Instructions (SSIs) which will be automatically
appended to the FIX Allocation Instruction. This database will be populated and
maintained directly by the investment manager’s custodians who will use the 4.4
Settlement Instruction message to do so. Although it is out of the direct scope of FIX
4.4, it is recommended that investment managers calculate net monies earlier in the
allocation process and append them to the Allocation Instruction Message – this is
not common practice outside the US market. On receipt of the Allocation Message
the broker will match the trade details, net money and settlement channel
compatibility (defined as PSETs being the same or ‘bridgeable’) and, assuming
everything matches, respond with a Confirmation enriched with the broker’s
settlement instructions and echoing back the investment manager’s allocation details.
Once affirmation is complete, both parties to the trade will have all the information
they need and in such a format that it can be parsed unambiguously into an MT 54x
message.

                                                                                         Formatted: Bullets and Numbering
1.2   Suggested method
The keys to the successful translation between FIX and SWIFT are: adherence to the
ISO15022 standard and achieving common tag usage. The proposed method for
achieving these aims is follows:
                                                                                         Formatted
1. Start with the ideal MT54x for each combination (market, instrument, PSET).
2. From the MT54x, define the FIX message content and format.
3. From 1 and 2 above, define the format and content of the FIX Settlement
   Instruction message to support the proposed flow.

These steps will form the basis of a project to define data standards.




                                           4
                                                                                                Formatted
        PROPOSED POST-EXECUTION FLOW
                                                                                                Formatted: Bullets and Numbering
        2.1Overview
        1.Order and NOE/final execution report can take place via FIX or any other method.
        2.Custodian sends periodic SDI update file to buy-side OMS database.                    Formatted: Bullets and Numbering
        3.Buy-side sends Allocation Instruction. Allocation includes total allocated quantity
            plus individual allocation quantities thus acting as both “block” and allocation.
            Allocations are enriched with SDIs from OMS database. Allocations may also
            contain net money calculations.
        4.Sell-side matches SDIs for settlement channel compatibility and net money (if
            applicable).
        5.Sell-side sends confirms enriched with both parties’ SDIs and net money.
        6.Buy-side matches complete trade and if match successful, instructs custodian and
            sends affirmation to sell-side (Confirmation ACK: type “accepted”). On receipt of
            affirmation, sell-side instructs its clearing agent.


            Buy-side                                    Sell-side


                 1               New Order

                              NOE/Final exe                 1

                 3
                              Alloc Inst (SSDIs)            4


                 6          Confirm & SDIsSSIs              5




SDSI file
        Custodian



             2




                                                                                                Formatted: Bullets and Numbering
        2.2Implementation
        1.The proposed flow is NOT dependent on FIX being used for order routing and the
            transmission of the NOE/final execution report.
        2.OMS vendors will need to create a new database within their systems to hold SDI       Formatted: Bullets and Numbering
            hold SDI information. This data will be maintained by the custodian and
            periodically updated. It must (Will need to be)be available to the OMS in real      Formatted
            time and will be used to enrich allocation instruction messages. Custodians,
                                                                                                Formatted
            OMS vendors and buy-sides must agree a common format and transmission



                                                   5
    transmission method for the periodic SDI update file: the FIX 4.4 Settlement
    Instruction message appears to be a good candidate but rigorous adoption of the
    ISO15022 format is essential. The additional cost and effort of maintaining and
    handling this data will be more than offset by the reduction in manual
    investigation and repair work in sell-side, buy-side and custodians’ operations
    operations departments.
3.The existence of an SDI database linked to the buy-side OMS will allow real-time
    real-time enrichment of allocations. If a buy-side firm does not wish to use Alert
    wish to use Alert or SID to identify its funds to the broker, a low-cost option is
                                                                                            Formatted
    option is to use the Legal Entity Identifier (LEI) and Fund LEI as outlined in
    appendix 1 (Legal Entity and Fund Data) below. Buy-side firms can choose one            Formatted
    can choose one of the following options:

           a.No SDIs on Allocation Instruction Message: sell-side to use internal
               database or Alert/SID to look up SDIs.
           b.PSET only: sell-side will use PSET to find SDI in internal database and
               to perform settlement channel matching.
           c.Full SDI enrichment from the OMS SDI database.                                 Formatted
    Use of PSET or full SDI enrichment will allow sell-side firms to do settlement
    channel matching and thus avoid rejected confirmations and associated
    settlement issues. Ideally, net money calculations should also be included on the
    allocation. By providing both net money and PSET information on the allocation,
    potential mis-matches will be caught and repaired earlier. This step will probably
    be phased in at a later date.
    The sell-side in turn will populate their Confirmations with SDIs and net money.
    Buy-side OMS vendors will be required to provide the capability to match this
    information against the data sent on the Allocation Instruction.
    The use of the ISO15022 standard for settlement instructions will allow users to
    populate their SWIFT messages more easily, and the provision of just-in-time
    enrichment will allow both parties to the trade to do away with having to maintain
    a database of each-other’s SDIs: the only SDIs they will have to maintain are
    their own. In order to achieve high levels of matching and automation, it is vital
    that when settlement instructions are transmitted via FIX that they can be
    unambiguously translated into ISO15022 format for inclusion in MT54x
    messages.
5.The adoption of LEIs (see appendix 1) will allow the use of post-execution FIX            Formatted: Bullets and Numbering
    messaging by firms who do not currently subscribe to Alert or SID.

Notes on use of Settlement Location (PSET) and Trade Matching
One of the strengths of the FIX 4.4 post-execution process is the ability to enrich
messages with PSET or full settlement details. This will allow brokers to match the
buy-side’s PSET for “settlement channel compatibility” prior to the confirmation
process. Brokers will compare the PSET on the buy-side’s Allocation Instruction with
their default PSET for the security in question and, if the match is not exact, they will
use their own proprietary logic to determine whether or not to support a “bridge”
between the 2 PSETs. All participants are strongly encouraged to use the BIC for
sending PSET information. This matching logic closely mimics that proposed by the
GSTPA model and has the advantage of alerting parties to potential settlement
issues well before instructions are sent to the market. For similar reasons, buy-side
firms are encouraged to include net money calculations on their allocations.




                                            6
                                                                                             Formatted: Bullets and Numbering
3.2. FixIX Settlement And Parties InformationComponent
    Blocks
This section covers the usage of the following component blocks within the Allocation
Instruction and Confirmation messages in FIX version 4.4.
Component Blocks
The use of Component Blocks is a flexible mechanism that allows new "roles" or
types of firm identification to be specified without a corresponding increase in the
number of FIX fields.

This section covers the usage of the following component blocks within the Allocation
Instruction and Confirmation messages in FIX version 4.4:

   Parties                                                                                  Formatted: Bullets and Numbering
   Nested Parties
   Settlement Instructions
   Settlement Parties

                                                                                             Formatted: Bullets and Numbering
4.12.1 Parties
In simple terms, the Parties block is used to describe those parties which are
common to the entire message (in the case of the Allocation Instruction) or for those        Formatted
messages where there is no requirement to nest party information such as the
Confirmation message. In addition, the PartyRole field allows users to specify “what”
is being described or the role it the party plays in the process. Similarly, the format or
“source” of the identifier is shown via the PartyIDSource field. The PartySubID may
be optionally used to provide an further level of subdivision
                                                                                             Formatted: Bullets and Numbering
4.22.2 NestedParties
The Allocation Instruction can be considered as analogous to the buy-side’s “block”
ETC message and Tthe NestedParties block is used to describe parties that are
relevant to discrete items on a message, - such as individual allocations, - where this
information may differ from that of the “block” or where it varies from item to item.

To illustrate its use, consider the difference between an Allocation Message and a
Confirmation. On the former, certain parties are common to all the individual
allocations whereas it is likely that each allocation will have certain party information
that is unique to it alone. Conversely, aTo illustrate its use, consider the
Confirmation message which has no need for a NestedParties group because each
Confirmation messageit is a unique message in itself and not one of many nested
items such as the individual allocations within an Allocation Instruction message.
                                                                                             Formatted: Bullets and Numbering
4.32.3 SettlInstructions and SettlParties
The role of the SettlInstructions component block is self-explanatory. Itand it can
contain any number of SettlPartyIDds that provide the details (DECU, REAG etc) on
a settlement instruction. Its presence on an Allocation Instruction Message is
optional. A confirmation can contain both sell-side and buy-side settlement parties
and can be used for DVP/RVP, free and tri-party settlement. This block will be the
main focus of the FIX-SWIFT mapping effort.




                                            7
                                                                                                             Formatted: Bullets and Numbering
5.3. Location and Content of Component Blocks

5.13.1 FIX Message - Allocation Instruction
This shows an Allocation Instruction message from which most of the fields have
been removed for clarity. It shows the Parties block which holds information relevant
to the entire message; the NestedParties block which holds information relevant to                           Formatted
each individual allocation, and the SettlInstructions block, again holding information                       Formatted
on an individual allocation level. Repeating within the SettlInstructions block is the
SettlParties block. The component blocks are shown in bold.


Tag   Field Name                    Req'd     Comments
      Standard Header                Y        MsgType = J
 70   AllocID                        Y        Unique identifier for this allocation instruction message
Component block <Instrument>         Y        Included for completeness only
component block <Parties>            N        The parties in this block must be common to the entire         Formatted
                                              allocation
component block <YieldData>           N       Included for completeness only
 78   NoAllocs                       Y**
       79    AllocAccount           Y**
     component block                 N       This block is used for party information that is specific to
      <NestedParties>                         the individual allocation.
     component block                N        Included for completeness only
      <CommissionData>
      780    AllocSettlInstType     N        Used to indicate whether settlement instructions are provided on
                                              this message, and if not, how they are to be derived.
                                              Absence of this field implies use of default instructions.
      component block               N        This block contains settlement instructions for this individual
       <SettlInstructions>                    allocation only
       Standard Trailer              Y

                                                                                                             Formatted: Bullets and Numbering
5.23.2 FIX Message - Confirmation
As shown stated above, the Confirmation message has no need of a NestedParties
block. As with the Allocation Instruction, the Confirmation has a SettlInstructions
block which can contain any number of SettlParties blocks.

Tag    Field Name                  Req'd    Comments
       Standard Header              Y       MsgType = AK
664    ConfirmID                    Y       Unique ID for this message
650    LegalConfirm                 N       Denotes whether this message represents the legally binding
                                            confirmation
                                            Required for ConfirmType = Confirmation
 665  ConfirmStatus                 Y
component block <Parties>           N       Note that there is no need for a <NestedParties> block on the
                                            confirmation because the sell-side sends an individual
                                            confirmation message in response to each allocation
                                            repeating withinin the Allocation Instruction message
component block                     Y
<Instrument>
component block <YieldData>         N
component block                     N
<SettlInstructions>
component block                     N
<CommissionData>
        Standard Trailer            Y




                                             8
                                                                                                                    Formatted: Bullets and Numbering
       6.4. Which Party and Where?
       From a first reading of the FIX 4.4 specification, the 3 parties groups seem to overlap
       and there is a degree of flexibility over where such an attribute such as Place of
       Settlement (PSET) should be stated. To make this decision easier, all 3 groups share
       the same set of possible values and the correspondence between each of the groups
       is shown in the table below. (See volumes 1 and 6 of the FIX 4.4 specification for
       clarification if unclear)

Tag Party Field Name            Tag   Nested Party Field Name               Tag Settlement Party Field Name
 453 NoPartyIDs                 539   NoNestedPartyIDds                    781 NoSettlPartyIDs
 448 PartyID                       524 NestedPartyIdD                        782 SettlPartyID
 447 PartyIDSource                 525 NestedPartyIDdSource                  783 SettlPartyIDdSource
 452 PartyRole                     538 NestedPartyRole                       784 SettlPartyRole
 802 NoPartySubIDs                 804 NoNestedPartySubIdDs                  801 NoSettlPartySubIDs
 523 PartySubIDd                      545 NestedPartySubIdD                    785    SettlPartySubID
 803 PartySubIDType                   805 NestedPartySubIdDType                786    SettlPartySubIDType


                                                                                                                    Formatted: Bullets and Numbering
       7.5. PARTYParty
       This section will refer to “Party” but as the grid above shows, Roles, Sources, Sub ids
       etc apply equally to NestedParties and SettlementParties.

       Parties are identified by a PartyID which in turn is “described” by the PartyRole,
       PartyIDSource and, optionally, by the PartySubID.
                                                                                                                    Formatted: Bullets and Numbering
       7.15.1 PartyRoles
       The PartyRole tells us “what” role the the PartyID being described isthe party is                            Formatted
       playing – a clearing firm, a custodian, an executing firm etc

       The next table shows the PartyRole values that can be used in these 3 party blocks.
       The list is taken from the 4.4 spec, Volume 6 – Appendix 6-G. However, it should be
       noted that the meaning of some of these PartyRoles are ambiguous and do not map
       easily to ISO15022 standards.


          Party Role                               Common Identification and Considerations Reference
       1 Executing Firm                            See “Common PartyRole Identification for Firms”
       2 Broker of Credit                          See “Common PartyRole Identification for Firms”
       3 Client ID                                 See “Common PartyRole Identification for Firms”
       4 Clearing Firm                             See “Common PartyRole Identification for Firms”
       5 Investor ID                               See “PartyRole Identification for Investor ID”Can be             Formatted
                                                   used to specify the ultimate client/fund on Settlement
                                                   Instruction message                                              Formatted
       6 Introducing Firm                          See “Common PartyRole Identification for Firms”                  Formatted
       7 Entering Firm                             See “Common PartyRole Identification for Firms”
       8 Locate/Lending Firm (for short-sales)     See “Common PartyRole Identification for Firms”
       9 Fund manager Client ID (for CIV)          See “Common PartyRole Identification for Firms”
       10 Settlement Location                      See “PartyRole Identification for Settlement Location”
       11 Order Origination Trader (associated with See “Common PartyRole Identification for Traders”
          Order Origination Firm – e.g. trader who
          initiates/submits the order)




                                                         9
   Party Role                                Common Identification and Considerations Reference
12 Executing Trader (associated          with See “Common PartyRole Identification for Traders”
   Executing Firm - actually executes)
13 Order Origination Firm (e.g. buyside firm) See “Common PartyRole Identification for Firms”Can               Formatted
                                              be used to specify the buyside firm on Settlement
                                              Instruction message                                              Formatted
14 Giveup Clearing Firm (firm to which trade See “Common PartyRole Identification for Firms”
   is given up)
15 Correspondent Clearing Firm               See “Common PartyRole Identification for Firms”
16 Executing System                          See “PartyRole Identification for Execution System”
17 Contra Firm                               See “Common PartyRole Identification for Firms”
18 Contra Clearing Firm                      See “Common PartyRole Identification for Firms”
19 Sponsoring Firm                           See “Common PartyRole Identification for Firms”
20 Underlying Contra Firm                    See “Common PartyRole Identification for Firms”
21 Clearing Organization                     See “Common PartyRole Identification for Firms”
22 Exchange                                  See “Common PartyRole Identification for Firms”
24 Customer Account
25 Correspondent Clearing Organization       See “Common PartyRole Identification for Firms”
26 Correspondent Broker                      See “Common PartyRole Identification for Firms”
27 Buyer/Seller (Receiver/Deliverer)         Value intended to be used in SettlParties component block
                                             (note these values correspond to ISO15022 settlement
                                             party categories)

28 Custodian                                 Value intended to be used in SettlParties component block
                                             (note these values correspond to ISO15022 settlement
                                             party categories)

29 Intermediary                              Value intended to be used in SettlParties component block
                                             (note these values correspond to ISO15022 settlement
                                             party categories)
                                             Note: it is possible to have multiple parties with this role in
                                             a SettlParties component block (intermediary 1,
                                             intermediary 2 etc.) in which case the PartySubID is used
                                             to distinguish between them.
30 Agent                                     Value intended to be used in SettlParties component block
                                             (note these values correspond to ISO15022 settlement
                                             party categories)

31 Sub custodian                             Value intended to be used in SettlParties component block
                                             (note these values correspond to ISO15022 settlement
                                             party categories)

32 Beneficiary                               Value intended to be used in SettlParties component block
                                             (note these values correspond to ISO15022 settlement
                                             party categories)
33 Interested Party                          See “Common PartyRole Identification for Firms”

34 Regulatory body                           See “Common PartyRole Identification for Firms”
35 Liquidity provider                        See “Common PartyRole Identification for Firms”


                                                                                                               Formatted: Bullets and Numbering
7.25.2 PartyIDSource
The PartyIDSource tells us the format of the information provided in the PartyIDRole.                          Formatted
Teg he options include: BIC, generally accepted market participant identifier, ISO
country code etc.




                                                  10
                                                                                              Formatted: Bullets and Numbering
7.2.15.2.1 PartyIDSource for Firms

 PartyIDSource (447/525/783)         PartyID (448/524/782)         PartySubID (523/545/785)
 B    BIC (Bank Identification       <<BIC Code Value>>            (optional)
      Code)
 C    Generally accepted market      (various)                     (optional)
      participant identifier
 D    Proprietary/Custom code        (various)                     (optional)


                                                                                              Formatted: Bullets and Numbering
7.2.25.2.2 PartyIDSource for Broker of Credit:

 PartyIDSource                       PartyID                       PartySubID
 (447/525/783)PartyIDSource          (448/524/782)PartyID (448)    (523/545/785)PartySubID
 (447)                                                             (523)
 B     BIC (Bank Identification      <<BIC Code Value>>            (optional)
       Code)
 I     ISITC code for identifying    <<ISITC-defined 3             (optional)
       directed brokers as per       character code>>
       ETC Best Practices
       document (for use with
       PartyRole = Broker of
       Credit only)
 D     Proprietary/Custom code       (various)                     (optional)

                                                                                              Formatted: Bullets and Numbering
7.2.35.2.3 PartyIDSource for Settlement Location

PartyIDSource                       PartyID                       PartySubID
(447/525/783)PartyIDSource          (448/524/782)PartyID (448)    (523/545/785)PartySubID
(447)                                                             (523)
B     BIC (Bank Identification      <<BIC Code Value>>            (optional)
      Code)
C     Generally accepted market     CED = CEDEL                   (optional)
      participant identifier        DTC = Depository Trust
                                    Company
                                    EUR = Euroclear
                                    FED = Federal Book Entry
                                    HIC = Held In Custody
                                    ICSD = International
                                    Central Securities
                                    Depository
                                    NCSD = National Central
                                    Securities Depository
                                    PNY= Physical
                                    PTC= Participant Trust
                                    Company
E    ISO Country Code               << ISO Country Code           (optional)
     [for Local Market              Value >>
     Settlement]




                                                 11
                                                                                          Formatted: Bullets and Numbering
7.2.45.2.4 PartyIdDSource for Buyer/Seller, Custodian, Intermediary
      or Agent

PartyIDSource                      PartyID                      PartySubID
(447/525/783)PartyIDSource         (448/524/782)PartyID (448)   (523/545/785)PartySubID
(447)                                                           (523)
B     BIC (Bank Identification     <<BIC Code Value>>           (optional)
      Code)
H     CSD participant/member       <<CSD participant or         (optional)
      code (e.g. Euroclear, DTC,   member code>>
      CREST or Kassenverein
      number)

                                                                                          Formatted: Bullets and Numbering
7.35.3 PartySubID
The PartySubID is used to provide more detail about the PartyID. The PartyID field
itself contains the actual value, and a repeating group of PartySubID and
PartySubIDType fields may be optionally used to provide additional detail about the
party. For example, the PartySubIDType field can be used to identify the type of
PartySubID value (i.e. "Firm", "Phone number", "Contact name", "Full legal name of
firm", etc.)

Note that although there is a PartySubIDType, there is no “Role” field for a SubID
which limits the use of SubIDs in certain circumstances.

Example values are shown below:

        Value PartySubIDType ( tags 803/805/786)
        1      Firm
        2      Person
        3      System
        4      Application
        5      Full legal name of firm
        6      Postal address (inclusive of street
              address, location, and postal code)
        7      Phone number
        8      Email address
        9      Contact name
        10     Securities account number (for
              settlement instructions)
        11     Registration number (for settlement
              instructions and confirmations)
        12     Registered address (for confirmation
              purposes)
        13     Regulatory status (for confirmation
              purposes)
        14     Registration name (for settlement
              instructions)
        15     Cash account number (for settlement
              instructions)
        16     BIC code
        17     CSD participant/member code (e.g.


                                                12
       Value PartySubIDType ( tags 803/805/786)
             Euroclear, DTC, CREST or
             Kassenverein number)
       18    Registered address
       19    Fund/account name
       20    Telex number
       21    Fax number
       22    Securities account name
       23    Cash account name
       24    Department
       25    Location / Desk
       26    Position Account Type




                                                                                       Formatted: Bullets and Numbering
8.6. Settlement Instructions
In practice, the options for SSI population on post-execution FIX messages are:

1. No SSIs – parties to refer to internal or external databases. Tags 169<             Formatted: Bullets and Numbering
   StandInstDbType>, 170<StandInstDbName> and 171<StandInstDbId> are used
   to drive the look-up process.
2. PSET only
3. Full enrichment

For option 3, some or all of the following fields (depending on market) can be
considered as the minimum for full enrichment for DVP/RVP and free settlement:

   PSET                                                                               Formatted: Bullets and Numbering
   Agent BIC
   CSD identifier (DTC 418, Crest 636, Euroclear 90895 etc)
   Securities account
   Cash account

This section covers the practicalities of how some of these elements should be used
within the message structure.
                                                                                       Formatted: Bullets and Numbering
8.16.1 Use of <SettlInstructions> Component Block
The SettlInstructions component block is used to transmit settlement instruction
details on an Allocation Instruction, Allocation Report, Confirmation or Settlement
Instruction message.
 When used on an Allocation Instruction, Allocation Report or Confirmation
     message, this represents the settlement instructions that apply to a particular
     trade or order.




                                           13
        When used on a Settlement Instruction message, this represents either standing
         instructions (to be used on future trades) or the instructions for a specific order
         (this usage is intended for the retail CIV market).

SettlInstructions Component Block

                                              <SettlInstructions>
Tag        Field Name                 Req'd     Comments
172                                    N        Required if AllocSettlInstType = 1 (derive from parameters provided)
           SettlDeliveryType                    or 2 (full details provided)
169                                     N       Required if AllocSettlInstType = 3 (SSI db IDs provided) - should not
           StandInstDbType                      be populated otherwise
170                                     N       Required if AllocSettlInstType = 3 (should not be populated
           StandInstDbName                      otherwise)
171                                     N       Identifier used within the StandInstDbType
           StandInstDbID                        Required if AllocSettlInstType = 3 (should not be populated
                                                otherwise)
    85                                  N       Required (and must be > 0) if AllocSettlInstType = 2 (should not be
           NoDlvyInst                           populated otherwise)
                                       N       Used to identify whether these delivery instructions are for the
           165   SettlInstSource
                                                buyside or the sellside. Required if NoDlvyInst > 0.
                                       N       S – securities, C – cash, mandatory for each occurrence of this
           787   DlvyInstType                   repeating group Required if NoDlvyInst > 0.
          Component Block              N       Required if NoDlvyInst > 0.
           <SettlParties>
                                              </SettlInstructions>


This SettlInstructions component block can be used in one of two ways:

1. either tTo contain transmit full settlement instruction details (i.e. settlement agent                       Formatted: Bullets and Numbering
   identities and account numbers). or a
2. As a reference to a standing instruction database. In this case, tags 169<
   StandInstDbType>, 170<StandInstDbName> and 171<StandInstDbId> are used.

        When used to specify settlement instruction details (case 1 above), tag                                Formatted: Bullets and Numbering
         85<NoDlvyInst> is used. Each member of the tag 85 group holds one party's
         settlement instructions. Tag 165<SettlInstSource> identifies to whom the
         instructions belong, and tag 787<DlvyInstType> identifies whether the
         instructions are for securities or for cash.

        When used to refer to instructions held on a standing instructions database (case
         2), the tags 169<StandInstDbType>, 170<StandInstDbName> and
         171<StandInstDbID> fields are used to specify the identify and name of the
         standing instructions database, and the identifier of the standing instruction
         record within that databaseit. The NoDlvyInst repeating group (tag 85) should not
         be populated when using these fields.

When used to specify settlement instruction details, the NoDlvyInst repeating group
   is used. Each member of that group holds one party's instructions for cash or
   securities settlement (or both in the case of DVP). The SettlInstSource field
   identifies to whom the instructions belong, and the DlvyInstType field identifies
   whether the instructions are for securities or for cash.
 In both of these cases, the tag 172<SettlDeliveryType> field is used to identify
   the type of settlement LEbeIing represented by these settlement instructions, i.e.
   DVP (delivery vs payment), FOP (free of payment), hold in custody etc.



                                                14
Where the SettlInstructions component block is used to describe specific settlement
instructions (i.e. using the NoDlvyInst [tag 85] repeating group), the number of entries
in tthe 85<he NoDlvyInst> repeating group is determined by the contents of the tag
172<SettlDeliveryType> field and by the context of the message block (i.e. which
message it is in). When used in an Allocation Instruction, Allocation Report or
Settlement Instruction message, only the settlement instructions for the party
generating the message need be specified. On a Confirmation message, both parties
to the trade will can have their settlement instructions specified.

The matrix of usage of the tag 85<NoDlvyInst> repeating group is therefore as
follows:




8.1.11. Allocation Instruction, Allocation Report or Settlement Instruction                       Formatted

172<SettlDeliveryType> 85<NoDlvyInst> 165<SettlInstSource>                  787<DlvyInstType> Formatted: Bullets and Numbering
0 – Versus Payment     1              1 (broker's), 2                       S – securities
                                      (institution's) or 3
                                      (investor's), depending
                                      on the identity of the
                                      originator of the
                                      message
1 – Free               2              1 (broker's), 2                       S – securities
                                      (institution's) or 3                  C – cash
                                      (investor's), depending
                                      on the identity of the
                                      originator of the
                                      message


OR                                                                                                Formatted


8.1.22. Confirmation                                                                              Formatted: Bullets and Numbering
                                                                                                  Formatted
172<SettlDeliveryType> 85<NoDlvyInst> 165<SettlInstSource>                  787<DlvyInstType>
0 – Versus Payment     2              1 (broker's)                          S – securities
                                      2 (institution's)
1 – Free               4              1 (broker's)                          S – securities
                                      1 (broker's)                          C – cash
                                      2 (institution's)                     S – securities
                                      2 (institution's)                     C – cash


The actual instructions themselves are held within the SettlParties component block               Formatted
inside the tag 85<NoDlvyInst> repeating group. This group contains a repeating
group of party identifiers and sub ids and is used to hold the identifiers of all parties
involved in settlement (e.g. agent, custodian, depository) together with any required
account numbers, registration details or similar.



                                            15
                                                                                               Formatted: Bullets and Numbering
6.2     SettlParties Component Block
The SettlParties component block is a repeating block held within the
SettlInstructions block.                                                                       Formatted
                                                                                               Formatted
8.26.2.1 SettlParty                                                                            Formatted: Bullets and Numbering
FIX supports the concept of a “SettlParty”, this beingwhich is defined as an
organisation or individual connected in some way to the settlement of a financial
transaction. Every SettlParty has 3 attributes:

1.    Aa role (defining “what” the SettlParty is or what role it’s playing in the settlement   Formatted: Bullets and Numbering
      process).,

2.    Aan identifier, the SettlPartyID                                                         Formatted: Bullets and Numbering


3.    (with aA SettlPartyIDSource to identify the type of SettlPartyID)                        Formatted: Bullets and Numbering


In addition, in common with the party logic outlined above, it may have and any
number of sub-identifiers (SettlPartySubID), each with a SettlPartySubIDType to
define the type of sub-identifier.
                                                                                               Formatted: Bullets and Numbering
8.2.16.2.2 SettlPartySubID
For the purposes of settlement instruction definition, the settlement party sub-
identifiers can be taken to represent one of three things:
    1. An alternative identifier for the SettlParty. For example, if the SettlParty’s
         primary identifier is its BIC code (expressed through its SettlPartyID with
         SettlPartyIDSource = B for BIC) then any other identifiers for the SettlParty
         (e.g. CSD participant number) can be expressed using a SettlPartySubID.
         For every SettlPartyIDSource that is commonly used to identify a SettlParty
         for settlement purposes, there is an equivalent SettlPartySubIDType.
    2. An identifier of an account held at the SettlParty. Note that the convention is
         to hold the account details under the SettlParty at which the account is held,        Formatted
         rather than under the SettlParty on whose behalf the account is held. For             Formatted
         example, the account number of a custodian at an agent is held as a
         SettlPartySubID under the SettlParty representing the agent, not the                  Formatted
         custodian.                                                                            Formatted
    3. Additional information relating to the SettlParty, e.g. its full name, address,
         contact name, phone number etc.
When using the FIX SettlInstructions component block, it may be appropriate to
provide a number of identifiers for the same SettlParty (e.g. both the BIC code and
CREST id for a CREST member agent bank). Only one of these can be held as a
SettlPartyID – the other(s) must be held as SettlPartySubID(s). It does not matter
which is held where.

                                                                                               Formatted: Bullets and Numbering
9.7. MAPPING Mapping FIX tTo ISO15022

9.17.1 Towards the Rosetta Stone
It is important to note that the ISO15022 standard has a consistent set of codes for
what in FIX terms would be called the SettlPartyIDSource (or SettlPartySubIDType
for sub-identifiers). Examples include:
      C – Country code
      P – Qualifier (BIC/BEI)
      R – Data Source Scheme/Proprietary Code


                                             16
     Q – Name and address
     S – Alternate ID
In the interests of assuring STP, we are proposing that FIX fields and messages only
map to ISO15022 options C, P, R or S (with a strong preference for P - BIC wherever
possible) and that SMPG guidelines will be followed throughout. There is no
equivalent of ‘Q’ in FIX at the SettlParty level, though this is supported at
SettlPartySubID level.
The ISO 15022 standard uses a similar methodology to the component blocks in FIX.
This means that the same ISO tag can be used many times in the same message but
its meaning depends on which message ‘sequence’ it is in. This is equivalent to the
FIX concept of SettlPartyRole.


                                                                                       Formatted: Bullets and Numbering
9.2Some Worked Examples

9.2.1PSET
For example, a PSET BIC should be represented in FIX using these tags:

FIX Tag                    Value
782 SettlPartyID           CEDELULL
783 SettlPartyIDSource     B
784 SettlPartyIDRole       10

The mapping to a SWIFT tag would work here as follows:
1.FIX tag 782 is a SettlPartyID and therefore maps to SWIFT tag 95 (Party)             Formatted: Bullets and Numbering
2.FIX tag 783 shows that the SettlPartyIDSource is a BIC and therefore maps to
    SWIFT option P.

We can now derive the correct SWIFT tag as 95P, which takes the format

:Tag::Qualifier//BIC, or in SWIFT shorthand ::4!c//4!a2!a2!c[3!c] (where [3!c]
represents the optional XXX characters at the end of an 8-character BIC).

So, concatenating the values within, or implied by, the FIX tags the mapping is:

782 & 783::& 784 & //& 782, or in the final message, :95P::PSET//CEDELULL

                                                                                       Formatted: Bullets and Numbering
9.2.2CSD Identifiers
ISO15022 allows a CSD identifier to be specified along with the type of identifier
being used. For example:

       :95R::DEAG/CRST/636 - Tag(Option):: (Qualifier)/(Data Source
       Scheme)/(Proprietary Code)
Here, the various tags have the following meanings:
   95 (Tag) = PARTY                                                                   Formatted: Bullets and Numbering
   R (Option) = The party will be identified by a data source scheme/ proprietary
       code
   DEAG (Qualifier) = Deliverer’s agent
   CRST (Data Source Scheme) = Crest
   636 (Proprietary Code) = participant ID at Crest.




                                          17
In order to avoid having the full set of CSD identifier types listed as separate
enumerations of PartyIDSource/PartySubIDType, FIX treats all such identifiers simply
as CSD participant/member codes (PartyIDSource = H, PartySubIDType = 17). The
type of participant/member code (e.g. Euroclear vs. DTC vs. CREST etc.) can be
derived simply by looking at the instruction’s settlement location (PartyRole = 10 –
equivalent to ISO15022 PSET).. This is illustrated in the example below.

                                                                                         Formatted: Bullets and Numbering
8. Settlement Party Mapping
See appendix 2 for more details on the MT54x fields
                                                                                         Formatted: Bullets and Numbering
8.1   Introduction
The aim of this section is to specify the settlement party contents of FIX allocations
and confirmations so that the FIX message recipient (the broker in the case of
allocations, and the investment manager in the case of confirmations) can extract the
sender’s settlement details for population into an MT54x message. Clearly, there is
more to an MT54x message than the settlement parties, but this paper concentrates
on that information which needs to be sent via an Allocation Instruction or a
Confirmation in order for the recipient to be able to populate their settlement
instructions. For example, such details as price, trade date and settlement date
should already be known or are easily mapped from FIX.

                                                                                         Formatted: Bullets and Numbering
8.2   Method
The method adopted will be to take the ISO MT54x structure and define the format
for FIX messages that is best adapted to being parsed into the SWIFT format. The
aim is not to force users to populate every single item of the ISO15022 standard into
their FIX messages and then parse them on a 1 to 1 basis into SWIFT messages.
For example, the FIX PartyRole enumerators do not contain discrete identifiers for       Formatted
Delivering Agent (DEAG) or Receiving Agent (REAG): FIX uses 452/538/784 = 30 for
both DEAG and REAG, the context of the allocation or confirmation message
showing which is meant:

      For example, if the investment manager is buying from the broker, then the         Formatted
      investment manager will identify its REAG on its FIX allocation, and the broker
      will respond with its DEAG on its confirm. Continuing this example, when the
      broker subsequently sends its MT543 (Deliver Against Payment) message to
      its settlement agent it will populate the E1 subsequence with the REAG
      information it received from the investment manager’s FIX allocation.              Formatted


                                                                                         Formatted: Bullets and Numbering
8.3   Mapping Conventions
The repetitive E1 subsequence in the MT54x message is used to describe various
Settlement Parties and the aim is to structure the FIX message so that it can be
easily and unambiguously parsed in.

In any single MT54x message, SMPG practice is always to populate 3 Settlement
Party sequences. These are

   Place of Settlement (PSET)                                                           Formatted: Bullets and Numbering
   Executing Broker (BUYR/SELL)
   Receiving / Delivering Agent (REAG/DEAG)




                                         18
Occasionally, a fourth Settlement Party sequence is required

     Clearing Broker (DECU/RECU)                                                  Formatted: Bullets and Numbering


The Executing Broker, Receiving / Delivering Agent and Clearing Broker sequences
may also have an Account Number tag populated (SAFE).

The rules for populating and formatting these sequences are described below.

                                                                                   Formatted: Bullets and Numbering
8.3.1 Place of Settlement (PSET) Sequence
Applicable to message types 540, 541, 542, 543.

Qualifier: PSET

Allowable tag formats: 95C, 95P

Where physical settlement is to take place, tag 95C will be used.

The format of this tag is

:4!c//2!a
(Qualifier)
(Country Code)

The Country Code element is equivalent to the Market of Settlement of the trade.

Example
:95C::PSET//GB

PSET - FIX Representation (95C)

Tag   Field Name                      Value       Comments
781   NoSettlPartyIDs                   1
     782   SettlPartyID               GB         PSET id
     783   SettlPartyIDSource          E         ISO country code
     784   SettlPartyRole              10        Settlement location (PSET)
                                                                                   Formatted


For all other places of settlement, tag 95P will be used.

The format of this tag is

:4!c//4!a2!a2!c[3!c]
(Qualifier)
(BIC)

The BIC element identifies the CSD where the trade is to be settled.

Example
:95P::PSET//CEDELULLXXX

PSET - FIX Representation (95P)


                                             19
Tag   Field Name                      Value      Comments
781   NoSettlPartyIDs                   1
     782   SettlPartyID          CEDELULLXXX    PSET id
     783   SettlPartyIDSource         B         BIC
     784   SettlPartyRole             10        Settlement location (PSET)



                                                                                         Formatted: Bullets and Numbering
8.3.2 Executing Broker Sequence (BUYR/SELL)

8.3.2.1 Executing Broker – Party Identifier
Applicable to message types 540, 541, 542, 543.

Qualifier: SELL (540, 541), BUYR (542, 543)

Allowable tag formats: 95R, 95P

The tag format will be dictated by the Place of Settlement.

If the Place of Settlement is either DTCYUS33XXX or FRNYUS33XXX (i.e. US
market, settlement via DTC or Fedwire), tag 95R will be used.

The format of this tag is

:4!c/8c/34x
(Qualifier)
(Data Source Scheme)
(Proprietary Code)

Data Source Scheme is always set to DTCYID for the US market.
Proprietary Code will be the broker’s DTC participant code.

Example
:95R::BUYR/DTCYID/161

BUYR/SELL - FIX Representation (95R) Option 1 (ambiguous)
When option R is used, the executing broker should ideally be identified by the use of
a SettlPartySubID. However, the FIX 4.4 spec does not contain an enumeration for
SettlPartySubIDType corresponding to ‘executing broker.’ Therefore, there is nothing
in the SettlParties fragment below to tell us what role is being played by the firm      Formatted
identified by DTC161.

                                    <SettlParties>
Tag   Field Name                        Value        Comments
781   NoSettlPartyIDs                       1
     782   SettlPartyID           DTCYUS33XXX       PSET id
     783   SettlPartyIDSource              B        BIC
     784   SettlPartyRole                  10       Settlement location (PSET)
     801   NoSettlPartySubIDs              1




                                            20
          785    SettlPartySubID            161           CSD identifier
          786    SettlPartySubIDType            17        CSD participant/member code
                                                                                          Formatted


BUYR/SELL - FIX Representation (95R) Option 2 (unambiguous)
Until an enumeration for ISO15022 BUYR/SELL is added, we suggest the use of a
SettlPartyID (as opposed to a SettlPartySubID) to identify the executing broker.
                                                                                          Formatted
Tag   Field Name                            Value       Comments
453   NoSettlPartyIDs                         1
     782   SettlPartyID                     161        BUYR/SELL Identifier
     783   SettlPartyIDSource               H          CSD participant/member code
     784   SettlPartyRole                    1         Executing firm


Note1. The identity of the CSD is not stated. This should be derived from the PSET.
Note 2. BUYR/SELL is not stated. This will be derived from tag 54(Side) in the FIX
allocation or confirmation. The rules for SWIFT message population are: for MT540
and MT541, the party is SELL: for MT542 and MT543, the party is BUYR.

For all other places of settlement, tag 95P will be used.

The format of this tag is

:4!c//4!a2!a2!c[3!c]
(Qualifier)
(BIC)

The BIC identifies the executing broker.

Example
:95P::SELL//GRTFGB21XXX

BUYR/SELL - FIX Representation (95P)

Tag   Field Name                            Value         Comments
453   NoSettlPartyIDs                         1
     782   SettlPartyID                 GRTFGB21XXX      BUYR/SELL Identifier
     783   SettlPartyIDSource               B            BIC
     784   SettlPartyRole                    1           Executing firm



Note. BUYR/SELL is not stated. This will be derived from tag 54(Side) in the FIX          Formatted
allocation or confirmation. The rules for SWIFT message population are: for MT540
and MT541, the party is SELL: for MT542 and MT543, the party is BUYR.
                                                                                          Formatted: Bullets and Numbering
8.3.3 Executing Broker – Safekeeping Account
Applicable to message types 540, 541, 542, 543.

Qualifier: SAFE




                                                   21
Allowable tag formats: 97A

This optional tag notifies the Executing Broker’s account with the Receiving /
Delivering Agent.

The format of this tag is

:4!c//35x
(Qualifier)
(Account Number)

Example
:97A::SAFE//987654

SAFE - FIX Representation (97A)
The safekeeping account will be shown as a SettlPartySubID. For completeness, the
account is shown as belonging to the previous executing broker example                Formatted


                                         <SettlParties>
Tag   Field Name                            Value         Comments
781   NoSettlPartyIDs                         1
     782   SettlPartyID                 GRTFGB21XXX      BUYR/SELL Identifier
     783   SettlPartyIDSource                B           BIC
     784   SettlPartyRole                    1           Executing firm
     801   NoSettlPartySubIDs                1
          785    SettlPartySubID         987654         Safekeeping acct #
          786    SettlPartySubIDType       10           Securities account number



                                                                                      Formatted: Bullets and Numbering
8.4   Receiving/Delivering Agent Sequence (REAG/DEAG)

8.4.1 REAG/DEAG Party Identifier
Applicable to message types 540, 541, 542, 543.

Qualifier: DEAG (540, 541), REAG (542, 543)

Allowable tag formats: 95R, 95P

The tag format will be dictated by the Place of Settlement.

For the following Places of Settlement, tag 95R must be used.                         Formatted


       CRSTGB22XXX               Crest, UK                      CRST
       CEDELULLXXX               Clearstream                    CEDE
       MGTCBEBEXXX               Euroclear                      ECLR
       DTCYUS33XXX               DTC, US                        DTCYID
       FRNYUS33XXX               Fedwire, US                    USFW
       SICVFRPPXXX               Sicovam, France                SICV
       INSECHZZXXX               SEGA Inter Settle,             SCOM
                                 Switzerland


                                              22
       VPDKDKKKXXX               Vaerdipapircentralen,            VPDK
                                 Denmark

These markets insist that the 95R format be used. Some markets such as Germany
allow use of either the 95R (participant code) or the 95P (BIC) format. The PSET or              Formatted
other party should always be represented by the BIC format where this is allowed.                Formatted

The format of the tag is

:4!c/8c/34x
(Qualifier)
(Data Source Scheme)
(Proprietary Code)

Data Source Scheme will be the appropriate entry from the table above.
Proprietary Code will be the broker’s participant code at the CSD.

Examples
:95R::DEAG/CRST/686
:95R::DEAG/CEDE/52686
:95R::DEAG/ECLR/93812
:95R::DEAG/USFW/021000021
:95R::REAG/DTCYID/161
:95R::REAG/SICV/530
:95R::REAG/SCOM/100370
:95R::REAG/VPDK/161
:95R::BUYR/DTCYID/161

DEAG/REAG - FIX Representation (95R) Option 1 (ambiguous)

Where the CSD participant id is available, FIX 4.4 allows it to appear as a
SettlPartySubID to the PSET. However, as with the other identifiers (BUYR/SELL,
RECU/DECU etc) the lack of a SettlPartySubIDRole tag means that there is no way                  Formatted
of telling what role is being played by Crest 686 in this example.                               Formatted
                                                                                                 Formatted
                                         <SettlParties>
Tag   Field Name                            Value         Comments
781   NoSettlPartyIDs                         1
     782   SettlPartyID                 CRSTGB22XXX      Crest
     783   SettlPartyIDSource                B           BIC is used as the identifier in 782
     784   SettlPartyRole                    10          Settlement location (PSET)
     801   NoSettlPartySubIDs                1
          785    SettlPartySubID           686          DEAG/REAG identifier
          786    SettlPartySubIDType        17          CSD participant/member code



DEAG/REAG - FIX Representation (95R) Option 2 (unambiguous)
To avoid the confusion inherent in REAG/DEAG option 1 above, we suggest the
following FIX format                                                                             Formatted


Tag   Field Name                           Value    Comments




                                               23
453   NoSettlPartyIDs                   1
     782   SettlPartyID               686        DEAG/REAG Identifier
     783   SettlPartyIDSource          H         CSD participant/member code
     784   SettlPartyRole              30        Agent


Note. DEAG/REAG is not explicitly stated. This will be derived from tag 54(Side) in
the FIX allocation or confirmation. The rules for SWIFT message population are: for
MT540 and MT541, the party is DEAG: for MT542 and MT543, the party is REAG.
                                                                                      Formatted


For all other places of settlement, tag 95P will be used.

The format of this tag is

:4!c//4!a2!a2!c[3!c]
(Qualifier)
(BIC)

The BIC identifies the delivering or receiving agent.

Example
:95P::REAG//GRTFGB21XXX

DEAG/REAG - FIX Representation (95P)                                                  Formatted


Tag   Field Name                      Value       Comments
453   NoSettlPartyIDs                   1
     782   SettlPartyID            GRTFGB21      DEAG/REAG Identifier
     783   SettlPartyIDSource          B         BIC
     784   SettlPartyRole              30        Agent


Note. DEAG/REAG is not stated. This will be derived from tag 54(Side) in the FIX      Formatted
allocation or confirmation. The rules for SWIFT message population are: for MT540
and MT541, the party is DEAG: for MT542 and MT543, the party is REAG.
                                                                                      Formatted: Bullets and Numbering
8.4.2 REAG/DEAG Safekeeping Account
Applicable to message types 540, 541, 542, 543.

Qualifier: SAFE

Allowable tag formats: 97A

This optional tag is only applicable when the Place of Settlement is FRNYUS33XXX
(Fedwire) and notifies the Broker’s Fedwire Mnemonic.

The format of this tag is

:4!c//35x
(Qualifier)
(Account Number)




                                             24
Example
:97A::SAFE//CHASE NYC MERRILL

REAG/DEAG Safekeeping Account - FIX Representation (97A)
The safekeeping account will be shown as a SettlPartySubID. In this case, the
securities account name is used.                                                                       Formatted


                                         <SettlParties>
Tag   Field Name                                   Value                 Comments
781   NoSettlPartyIDs                                  1
     782   SettlPartyID                           161                   Identifier
     783   SettlPartyIDSource                         H                 CSD participant/member code
     784   SettlPartyRole                             30                Agent
     801   NoSettlPartySubIDs                         1
          785    SettlPartySubID       CHASE NYC MERRILL               Safekeeping acct #
          786    SettlPartySubIDType                 22                Securities account name


                                                                                                       Formatted: Bullets and Numbering
8.5   Clearing Broker Sequence (DECU/RECU)

8.5.1 Clearing Broker – Party Identifier
Applicable to message types 540, 541, 542, 543.

Qualifier: DECU (540, 541), RECU (542, 543)

Allowable tag formats: 95R, 95P

This tag is used occasionally when it is necessary to specify the clearing broker of
the trade. The rules for formatting of the tag are exactly the same as for Executing
Broker, except for the change of qualifier to DECU / RECU in place of SELL / BUYR.

Examples
:95R::RECU/DTCYID/161
:95P::DECU//GRTFGB21XXX

DECU/RECU - FIX Representation (95R)
As before, to resolve the ambiguity caused by the lack of a SettlPartySubIDRole tag,                   Formatted
the use of SettlPartySubID will not be used. Instead, the DECU/RECU participant
code will appear in a discrete SettlPartyID block.                                                     Formatted


Tag   Field Name                           Value            Comments
453   NoSettlPartyIDs                        1
     782   SettlPartyID                    161             Identifier
     783   SettlPartyIDSource               H              CSD participant/member code
     784   SettlPartyRole                   28             Custodian (DECU/RECU)
                                                                                                       Formatted
DECU/RECU - FIX Representation (95P)

Tag   Field Name                           Value            Comments




                                                  25
453   NoSettlPartyIDs                         1
     782     SettlPartyID                GRTFGB21      Identifier
     783     SettlPartyIDSource              B         BIC
     784     SettlPartyRole                 28         Custodian (DECU/RECU)


Note. The direction, DECU/RECU, is not stated. This will be derived from tag
54(Side) in the FIX allocation or confirmation. The rules for SWIFT message
population are: for MT540 and MT541, the party is DECU: for MT542 and MT543, the
party is RECU.
                                                                                                                 Formatted: Bullets and Numbering
8.6   Example Messages
These examples show the relevant fragment of the FIX allocation and confirmation
messages required for populating repeating sub-sequence E1 in the MT54x.

Gartmore buys UK equities from Citigroup for Crest settlement                                                    Formatted



                                     Gartmore’s FIX Allocation                                                   Formatted
                                                                                                                 Formatted
       780     AllocSettlInstType                2           Used to indicate whether settlement instructions are
                                                                                                                  Formatted
                                                              provide on this message. Null implies use default
                                             <SettlInstructions>
Tag    Field Name                             Value           Comments
172                                             0             Versus payment
       SettlDeliveryType
 85                                               1           Required (and must be > 0) if AllocSettlInstType = 2
       NoDlvyInst                                             (should not be populated otherwise)
                                                 2           Used to identify whether these delivery instructions are
                                                                                                                   Formatted
       165      SettlInstSource                               for the buyside or the sellside. Required if NoDlvyInst
                                                              > 0. (2= Institution’s)
                                                 S           S – securities, C – cash, mandatory for each         Formatted
       787      DlvyInstType                                  occurrence of this repeating group Required if
                                                              NoDlvyInst > 0.
                                                  <SettlParties>
781    NoSettlPartyIDs                          3             1. PSET/REAG, 2. BUYR
      782    SettlPartyID                CRSTGB22XXX         Crest
      783    SettlPartyIDSource               B              BIC is used as the identifier in 782
      784    SettlPartyRole                   10             Settlement location (PSET)
      782    SettlPartyID                   BT01C            Crest ID
      783    SettlPartyIDSource               H              CSD participant/member code
      784    SettlPartyRole                   30             Agent (REAG in this case)
      801    NoSettlPartySubIDs                1
            785 SettlPartySubID             6333            Acct # at agent                                    Formatted
                     SettlPartySubID                                                                             Formatted
            786                                 10          Securities account number
                     Type
      782    SettlPartyID                  GRTFGB21          Executing broker (BUYR)                            Formatted
      783    SettlPartyIDSource               B              BIC                                                Formatted
      784    SettlPartyRole                   1              Executing firm
                                                                                                                 Formatted
                                               </SettlParties>
                                                                                                                 Formatted
                                             </SettlInstructions>
                                                                                                                 Formatted
                                                                                                                 Formatted
                               Citigroup’s FIX Confirmation                                                      Formatted
For completeness, in this example the confirmation contains both the broker’s and                                Formatted
the institution’s delivery instructions as shown by 85<NoDlvyInst>=2. This allows the                            Formatted
institution to re-check that the broker has processed the allocation message
                                                                                                                 Formatted



                                                  26
correctly. However, it is not mandatory for the broker to ‘echo’ back the institution’s
instructions in this manner. As we saw above, in order to avoid ambiguity over party
roles, limited use has been made of SettlPartySubID tags.
                                                                                                            Formatted


                                            <SettlInstructions>
Tag   Field Name                             Value      Comments
172                                            0        Versus payment
      SettlDeliveryType
 85                                            2        Required (and must be > 0) if AllocSettlInstType = 2
      NoDlvyInst                                        (should not be populated otherwise)
                                              1        Used to identify whether these delivery instructions are
      165    SettlInstSource                            for the buyside or the sellside. Required if NoDlvyInst
                                                        > 0. (1= broker’s)
                                             S         S – securities, C – cash, mandatory for each
      787    DlvyInstType                               occurrence of this repeating group Required if
                                                        NoDlvyInst > 0.
                                        <SettlParties> (Broker’s)                                           Formatted
781   NoSettlPartyIDs                         3          1. PSET 2. DEAG 3. SELL
     782    SettlPartyID               CRSTGB22XXX      Crest
     783    SettlPartyIDSource              B           BIC is used as the identifier in 782
     784    SettlPartyRole                  10          Settlement location (PSET)
     782    SettlPartyID                   636          Crest ID
     783    SettlPartyIDSource              H           CSD participant/member code
     784    SettlPartyRole                  30          Agent (DEAG in this case)
     782    SettlPartyID                SBUKGB21        Executing broker (SELL)
     783    SettlPartyIDSource              B           BIC
     784    SettlPartyRole                   1          Executing firm
                                              </SettlParties>
      165   SettlInstSource                   2         (2= Institution’s)                                 Formatted
      787   DlvyInstType                      S         S – securities
                                                                                                            Formatted
                                       <SettlParties> (Institution’s)
781    NoSettlPartyIDs                        3          1. PSET 2. REAG 3. BUYR                            Formatted
      782 SettlPartyID                 CRSTGB22XXX      Crest                                              Formatted
      783 SettlPartyIDSource                B           BIC is used as the identifier in 782
                                                                                                            Formatted
      784 SettlPartyRole                    10          Settlement location (PSET)
      782 SettlPartyID                    BT01C         Crest ID                                           Formatted
      783 SettlPartyIDSource                H           CSD participant/member code
      784 SettlPartyRole                    30          Agent (REAG in this case)
      801 NoSettlPartySubIDs                 1                                                             Formatted
           785 SettlPartySubID            6333         Acct # at agent
                                                                                                            Formatted
                     SettlPartySubID
           786                              10         Securities account number                          Formatted
                     Type
      782 SettlPartyID                   GRTFGB21       Executing broker (BUYR)                            Formatted
      783 SettlPartyIDSource                B           BIC
                                                                                                            Formatted
      784 SettlPartyRole                    1           Executing firm
                                              </SettlParties>                                               Formatted

                                            </SettlInstructions>


                          Gartmore’s SWIFT Message fragment

Sequence E - Settlement Details
  :16R:SETDET
  :22F::SETR//TRAD
   Sub-sequence E1 - Settlement Parties
    :16R:SETPRTY
    :95R::DEAG/CRST/636



                                               27
    :16S:SETPRTY
    :16R:SETPRTY
    :95P::SELL//SBUKGB21
    :16S:SETPRTY
    :16R:SETPRTY
    :95P::PSET//CRSTGB22XXX
    :16S:SETPRTY
                                                                                              Formatted


                                                                                              Formatted: Bullets and Numbering
9.2.3Putting it all together
Settlement instructions for German domestic settlement with Citibank
Frankfurt as local agent, into account 11921500:
                                              <SettlParties>
      Tag         Field Name                                             Value              Comments
      781         NoSettlPartyIDs                                         3
                                                                                            PSET for
                 782           SettlPartyID                           DAKVDEFF   German domestic
                                                                                  settlement
                                                                                            BIC is used as
                 783           SettlPartyIDSource                        B
                                                                                  the identifier in 782
                                                                                            Settlement
                 784           SettlPartyRole                            10
                                                                                  location (PSET)
                                                                                            Broker’s agent’s
                 782           SettlPartyID                             7671
                                                                                  Kassenverein number
                                                                                            CSD
                                                                                  participant/member code
                                                                                  (e.g. Euroclear, DTC,
                                                                                  CREST or Kassenverein
                                                                                  number)
                 783           SettlPartyIDSource                        H
                                                                                            As the settlement
                                                                                  location here is ‘German
                                                                                  domestic’, this identifier is
                                                                                  therefore a Kassenverein
                                                                                  number
                                                                                            Agent – maps to
                 784           SettlPartyRole                            30      SWIFT DEAG or REAG
                                                                                  (depending on Side)
                 801           NoSettlPartySubIDs                        1
                                                                                           This agent’s BIC
                                                                                  code
                                                                                           This is held here
                                                                                  as a PartySubID, though
                              785              SettlPartySubID       CITIDEFF   could also have been held
                                                                                  as the PartyID with the
                                                                                  Kassenverein number
                                                                                  held as PartySubID
                                                                                  instead
                              786              SettlPartySubIDType      16               BIC code
                                                                                           Broker or
                 782           SettlPartyID                             9427     broker's custodian’s
                                                                                  Kassenverein number




                                          28
                                                                                                       CSD
                                                                                             participant/member code
                                                                                             (e.g. Euroclear, DTC,
                                                                                             CREST or Kassenverein
                                                                                             number) (KV no. in this
                 783         SettlPartyIDSource                                   H         case)
                                                                                                       As the settlement
                                                                                             location here is ‘German
                                                                                             domestic’, this identifier is
                                                                                             therefore a Kassenverein
                                                                                             number
                                                                                                       Deliverer/receiver
                                                                                             of securities (or custodian)
                                                                               27 (client)
                 784         SettlPartyRole                                                 – maps to SWIFT DECU
                                                                       or 28 (custodian)
                                                                                             or RECU (depending on
                                                                                             Side)
                 801         NoSettlPartySubIDs                                    1
                                                                                                     Securities
                            785              SettlPartySubID                 11921500
                                                                                             account number
                                                                                                     Securities
                                                                                             Account – maps to
                            786              SettlPartySubIDType                 10
                                                                                             ISO15022 Tag 97 SAFE
                                                                                             (Safekeeping account)
                                                     </SettlParties>

SWIFT settlement instruction for an example trade, using settlement
instructions derived from the above FIX data:

:16R:GENL

:20C::SEME//011204000064001
  :23G:NEWM
:16S:GENL
:16R:TRADDET
  :94B::TRAD//EXCH/XETR
  :98A::SETT//20011206
  :98A::TRAD//20011204
  :35B:ISIN DE0005557508
:16S:TRADDET
:16R:FIAC
  :36B::SETT//UNIT/3000,
  :97A::SAFE//11921500          Securities account number (taken from third
:16S:FIAC                       SettlParty in the table above).
:16R:SETDET
  :22F::SETR//TRAD
  :16R:SETPRTY                  Agent – the second SettlParty in the table above.
    :95R::DEAG/DAKV/7671        The DAKV identifies the number 7671 as being a
  :16S:SETPRTY                  Kassenverein number and is derived from a
                                combination of this party’s SettlPartyIDSource (H -
                                CSD code) and the SettlPartyID of the settlement
                                agent.
 :16R:SETPRTY
   :95P:PSET//DAKVDEFF          Settlement location – the first SettlParty in the
 :16S:SETPRTY                   table above.
 :16R:SETPRTY
   :95R::SELL/DAKV/9427         Custodian/client – the third SettlParty in the table
 :16S:SETPRTY                   above.
 :16R:AMT


                                        29
    :19A::SETT//EUR50700,
  :16S:AMT
:16S:SETDET

                                                                                              Formatted: Bullets and Numbering
10.SSI Enrichment
The options for SSI population are:
1.No SSIs – parties to refer to internal or external databases
2.PSET only                                                                                   Formatted: Bullets and Numbering
3.Full enrichment

For option 3, some or all of the following fields (depending on market) can be
considered as the minimum for full enrichment for DVP/RVP and free settlement:

PSET                                                                                         Formatted: Bullets and Numbering
Agent BIC
CSD identifier (DTC 418, Crest 636, Euroclear 90895 etc)
Securities account
Cash account
Investor id
Registration number

                                                                                              Formatted: Bullets and Numbering
11.9. Settlement Instructions Message
It may seem paradoxical to consider this message after the settlement-related
contents of the various parties Component Blocks, but it is the contents and format of
these blocks that determines the content and format of the settlement instruction
message and the format of the SSI data stores to be held on the buy-side firms’
OMSsinfrastructure. The urgent task facing the industry is to tighten up the rules for
transmitting and storing commonly-used settlement-related data fields before the
message enters service and bad practice becomes common practice.

                                                                                              Formatted: Bullets and Numbering
11.19.1        Settlement Instructions
The Settlement Instructions message provides the broker’ssell-side’s, the
institution’sbuy-side’s, or the intermediary’s instructions for trade settlement. The
SettlInstSource field indicates if the settlement instructions are the broker’ssell-side’s,
the institution’sbuy-side’s, or the intermediary’s. This message has been designed
so that it can be sent from the broker sell-side to the institutionbuy-side, from the
institution buy-side to the brokersell-side, or from either to an independent “standing
instructions” database or matching system or, for CIV, from an intermediary to a fund
manager.

The Settlement Instructions message can be used in one of 3 modes
(SettlInstMode):

1. To provide “standing instructions” for the settlement of trades occurring in the           Formatted: Bullets and Numbering
   future. The message could either be sent in an 'unsolicited' fashion (i.e. a 'push'-
   style update from one firm to that firm's counterparties) or in response to a
   Settlement Instruction Request message. In either of these scenarios, this
   message can provide multiple settlement instructions. The Settlement Instruction
   detail can be either explicitly specified (via the SettlInstructions component block)
   or can exist within an independent standing instructions database and can be


                                            30
      referenced via the StandInstDbType, StandInstDbName, and StandInstDbID
      fields. See Volume 6 – Appendix 6-H for further details regarding the
      construction and formatting of Settlement Instruction Messages.
1.
1.2.     To reject a Settlement Instruction Request message (e.g. unable to process
    request, no matching settlement instructions found).
2.3.     To provide settlement instructions for a specific Order with a single account
    either as overriding or standing instructions to support matching. The ClOrdID
    field should be used to link the settlement instructions to the corresponding
    Order message.

The Settlement Instruction detail can be either explicitly specified (via the
SettlInstructions component block) or can exist within an independent standing
instructions database and can be referenced via the StandInstDbType,
StandInstDbName, and StandInstDbID fields. See Volume 6 – Appendix 6-H for
further details regarding the construction and formatting of settlement instruction
details.
                              Settlement Instruction Messages
Tag     Field Name                   Req'd   Comments
        Standard Header               Y      MsgType = T
777     SettlInstMsgID                Y      Unique identifier for this message
791     SettlInstReqID                N      Only used when this message is used to respond to a settlement
                                             instruction request (to which this ID refers)
160     SettlInstMode                 Y      1=Standing Instructions, 2=Specific Allocation Account
                                             Overriding, 3=Specific Allocation Account Standing , 4=Specific
                                             Order, 5=Reject SSI request
792     SettlInstReqRejCode           N      Required for SettlInstMode = 5. Used to provide reason for
                                             rejecting a Settlement Instruction Request message.
 58     Text                          N      Can be used to provide any additional rejection text where
                                             rejecting a Settlement Instruction Request message.
354     EncodedTextLen                N
355     EncodedText                   N
165     SettlInstSource               N      1=Broker’s Settlement Instructions, 2=Institution’s Settlement
                                             Instructions , 3=Investor
                                             Required except where SettlInstMode is 5=Reject SSI request
 11     ClOrdID                       N      Required for SettlInstMode=4.
 60     TransactTime                  Y      Date/time this message was generated
778     NoSettlInst                   N      Required except where SettlInstMode is 5=Reject SSI request
        162    SettlInstID           N      Unique ID for this settlement instruction.
                                             Required except where SettlInstMode is 5=Reject SSI request
        163   SettlInstTransType     N      New, Replace, Cancel or Restate
                                             Required except where SettlInstMode is 5=Reject SSI request
        214   SettlInstRefID         N      Required where SettlInstTransType is Cancel or Replace
       component block               N      Insert here the set of "Parties" (firm identification) fields defined
        <Parties>                            in "COMMON COMPONENTS OF APPLICATION MESSAGES"
                                             Used here for settlement location.
                                             Also used for executing broker for CIV settlement instructions
        54    Side                   N      Can be used for SettleInstModeSettlInstMode 1 if SSIs are being
                                             provided for a particular side.
        460   Product                N      Can be used for SettleInstModeSettlInstMode 1 if SSIs are being
                                             provided for a particular product.
        167   SecurityType           N      Can be used for SettleInstModeSettlInstMode 1 if SSIs are being
                                             provided for a particular security type (as alternative to CFICode).
        461   CFICode                N      Can be used for SettleInstModeSettlInstMode 1 if SSIs are being
                                             provided for a particular security type (as identified by CFI code).
        168   EffectiveTime          N      Effective (start) date/time for this settlement instruction.
                                             Required except where SettlInstMode is 5=Reject SSI request
        126   ExpireTime             N      Termination date/time for this settlement instruction.
        779   LastUpdateTime         N      Date/time this settlement instruction was last updated (or created if
                                             not updated since creation).
                                             Required except where SettlInstMode is 5=Reject SSI request



                                              31
      Component block                N     Insert here the set of "SettlInstructions" fields defined in
       <SettlInstructions>                  "COMMON COMPONENTS OF APPLICATION MESSAGES"
       492                           N     For use with CIV settlement instructions
               PaymentMethod
       476    PaymentRef             N     For use with CIV settlement instructions
       488    CardHolderName         N     For use with CIV settlement instructions
       489    CardNumber             N     For use with CIV settlement instructions
       503    CardStartDate          N     For use with CIV settlement instructions
       490    CardExpDate            N     For use with CIV settlement instructions
       491    CardIssNum             N     For use with CIV settlement instructions
       504    PaymentDate            N     For use with CIV settlement instructions
       505    PaymentRemitterID      N     For use with CIV settlement instructions
       Standard Trailer               Y



                                                                                                           Formatted: Bullets and Numbering
10. Custodian – Institution SSI Updates
The STP Lite model proposes the use of the Settlement Instruction Message by
custodians to update an SSI database in the investment manager’s environment. The
key to the success of this process is adherence to the FIX tag usage set out in
section 9.

The minimum field requirements for an SSI Database are:
 PSET – where the trade will settle                                                                       Formatted: Bullets and Numbering
 Security Type (see section 10.1 onwards) – what security type this SSI is for
 Fund identifier
 REAG/DEAG
 REAG/DEAG’s account at the CSD
 DECU/RECU
 DECU/RECU account
 Time in force – important for SSI updates which may not be effective until a future
   date
 Additional fields
       o Investor id
       o Registration id
       o Contact details
       o etc

10.1 Security type
Three tags can be used to identify security type:

460<Product>
167<SecurityType>
461<CFICode> Classification of Financial Instrument

For Fixed income instruments, 167<SecurityType should by used.
                                                                                                           Formatted: Bullets and Numbering
10.2 Product
Tag 460
Indicates the type of product the security is associated with. See also the CFICode (461) and
SecurityType (167) fields.

Tag 460<Product> Values                                                                                    Formatted
1 = AGENCY
2 = COMMODITY



                                             32
Tag 460<Product> Values                                                                  Formatted
3 = CORPORATE
4 = CURRENCY
5 = EQUITY
6 = GOVERNMENT
7 = INDEX
8 = LOAN
9 = MONEYMARKET
10 = MORTGAGE
11 = MUNICIPAL
12 = OTHER
13 = FINANCING


                                                                                         Formatted: Bullets and Numbering
10.3 SecurityType
Tag 167

                         Tag 167<SecurityType> Values                                    Formatted
Indicates type of security. See also the Product (460) and CFICode (461) fields. It is
recommended that CFICode be used instead of SecurityType for non-Fixed Income
instruments.
Example values (grouped by Product field value) (Note: additional values may be used
by mutual agreement of the counterparties):

460 = AGENCY                                                                             Formatted
EUSUPRA = Euro Supranational Coupons *
FAC = Federal Agency Coupon
FADN = Federal Agency Discount Note
PEF = Private Export Funding *
SUPRA = USD Supranational Coupons *
* Identify the Issuer in the "Issuer" field(106)
460 = CORPORATE                                                                          Formatted
CORP = Corporate Bond
CPP = Corporate Private Placement
CB = Convertible Bond
DUAL = Dual Currency
EUCORP = Euro Corporate Bond
XLINKD = Indexed Linked
STRUCT = Structured Notes
YANK = Yankee Corporate Bond
460 = CURRENCY                                                                           Formatted
FOR = Foreign Exchange Contract
460 = EQUITY                                                                             Formatted
CS = Common Stock
PS = Preferred Stock
460 = WAR - Warrant now is listed under Municipals for consistency with Bloomberg        Formatted
fixed income product types. For equity warrants - use the CFICode (461) instead.




                                             33
                         Tag 167<SecurityType> Values                            Formatted
460 = GOVERNMENT                                                                 Formatted
BRADY = Brady Bond
EUSOV = Euro Sovereigns *
TBOND = US Treasury Bond
TINT = Interest strip from any bond or note
TIPS = Treasury Inflation Protected Securities
TCAL = Principal strip of a callable bond or note
TPRN = Principal strip from a non-callable bond or note
TNOTE = US Treasury Note
TBILL = US Treasury Bill
* Identify the Issuer Name in Issuer (106)
460 = FINANCING                                                                  Formatted
REPO = Repurchase
FORWARD = Forward
BUYSELL = Buy Sellback
SECLOAN = Securities Loan
SECPLEDGE = Securities Pledge
460 = INDEX                                                                      Formatted

Note: "Indices" includes: Stock, Index Spot Options, Commodity, Physical Index
Options, Share/Ratio, and Spreads. For index types use the CFICode (461).
460 = LOAN                                                                       Formatted
TERM = Term Loan
RVLV = Revolver Loan
RVLVTRM = Revolver/Term Loan
BRIDGE = Bridge Loan
LOFC = Letter of Credit
SWING = Swing Line Facility
DINP = Debtor in Possession
DEFLTED = Defaulted
WITHDRN = Withdrawn
REPLACD = Replaced
MATURED = Matured
AMENDED = Amended & Restated
RETIRED = Retired
460 = MONEYMARKET                                                                Formatted
BA = Bankers Acceptance
BN = Bank Notes
BOX = Bill of Exchanges
CD = Certificate of Deposit
CL = Call Loans
CP = Commercial Paper
DN = Deposit Notes
EUCD = Euro Certificate of Deposit
EUCP = Euro Commercial Paper
LQN = Liquidity Note
MTN = Medium Term Notes
ONITE = Overnight
PN = Promissory Note
PZFJ = Plazos Fijos
STN = Short Term Loan Note
TD = Time Deposit
XCN = Extended Comm Note
YCD = Yankee Certificate of Deposit




                                             34
                         Tag 167<SecurityType> Values                                 Formatted
460 = MORTGAGE                                                                        Formatted
ABS = Asset-backed Securities
CMBS = Corp. Mortgage-backed Securities
CMO = Collateralized Mortgage Obligation
IET = IOETTE Mortgage
MBS = Mortgage-backed Securities
MIO = Mortgage Interest Only
MPO = Mortgage Principal Only
MPP = Mortgage Private Placement
MPT = Miscellaneous Pass-through
PFAND = Pfandbriefe *
TBA = To be Announced
* Identify the Issuer Name in Issuer (106)
460 = MUNICIPAL                                                                       Formatted
AN = Other Anticipation Notes BAN, GAN, etc.
COFO = Certificate of Obligation
COFP = Certificate of Participation
GO = General Obligation Bonds
MT = Mandatory Tender
RAN = Revenue Anticipation Note
REV = Revenue Bonds
SPCLA = Special Assessment
SPCLO = Special Obligation
SPCLT = Special Tax
TAN = Tax Anticipation Note
TAXA = Tax Allocation
TECP = Tax Exempt Commercial Paper
TRAN = Tax & Revenue Anticipation Note
VRDN = Variable Rate Demand Note
WAR = Warrant
460 = OTHER                                                                           Formatted
MF = Mutual Fund (i.e. any kind of open-ended “Collective Investment Vehicle”)
MLEG = Multi-leg instrument (e.g. options strategy or futures spread. CFICode (461)
can be used to identify if options-based, futures-based, etc.)
NONE = No Security Type
? = “Wildcard” entry (used on Security Definition Request message)


                                                                                      Formatted: Bullets and Numbering
10.4 Classification of Financial Instrument (CFI) Code

For non-fixed income instruments, 461<CFICode> is to be used:

CFI code structure (ISO 10962):
 The CFI reflects characteristics that are defined when a financial instrument is    Formatted: Bullets and Numbering
   issued and remain unchanged during its entire lifetime.
 The CFI consists of six alphabetical characters:
 The first character indicates the highest level of classification (categories).


Equities (E)
Debt instruments (D)
Entitlements (Rights) (R)
Options (O)
Futures (F)
Others/Miscellaneous (M)


                                            35
The second character indicates specific groups within each category                        Formatted


Groups e.g. for equities:
Shares
Preferred shares
Convertible preferred shares
Units, i.e. unit trusts/mutual funds etc.
Others

The third to sixth character indicate the most important attributes of each group:         Formatted


Attributes e.g. for equities:
Voting right
Ownership/transfer restrictions
Payment status
Form

                                                                                           Formatted: Bullets and Numbering
10.4.1.1 High-level subset of possible values applicable to FIX usage:
Note: Corresponding FIX 4.2 SecurityType field value is identified within [ ]
ESXXXX = Equity Common Shares [CS]
EMXXXX = Equity Miscellaneous or Other (e.g. Exchange Traded Funds (ETFs),
etc.) [n/a]
EPXXXX = Equity Preferred Shares [PS]
EUXXXX = Equity Units (unit trusts/mutual funds/OPCVM/OICVM) [MF]
DXXXXX = Debt (Fixed Income) [various]
DCXXXX = Debt Convertible Bond [CB]
FXXXXX = Future [FUT]
MRCXXX = Misc, Referential Instrument, Currency [FOR]
MRIXXX = Misc, Referential Instrument, Index [n/a]
MRRXXX = Misc, Referential Instrument, Interest Rate [n/a]
OCXXXX = Option - Call [OPT]
OPXXXX = Option - Put [OPT]
RWXXXX = Right Warrant [WAR]
RWXCXX = Covered Warrant [n/a]
XXXXXX = [NONE and ?]
Note that "X" represents an unspecified or unknown attribute and many of the values
above containing "X" can be further subdefined according to the CFI standard (e.g.
Voting rights are the third character of Equity Common Shares).

                                                                                           Formatted: Bullets and Numbering
11. SSI Update Messages
This is an example of a periodic update message sent from a custodian to the fund
manager for an equity SSI. The entire message structure is shown and those fields
that are not used are marked accordingly.

                                                                                           Formatted: Bullets and Numbering
11.1 Buyside Entity and Fund Identifiers
Where the buyside is using proprietary identifiers to identify itself and its funds, the
FIX tag usage is fairly unambiguous: tags 169<StandInstDbType>, 170
<StandInstDbName> and 171<StandInstDbID> are used to specify the identify and
name of the standing instructions database, and the identifier of the standing
instruction record within it. However, when a proprietary database is not used FIX is


                                            36
a little vague regarding the identification of buy-side sub-accounts so we have
suggested what seems to be a sensible compromise. The suggested format allows
for multiple funds’ SSIs or multiple SSIs for the same fund to be transmitted in one
message.

Tag   Field Name                    Req'd    Comments
      Standard Header                Y       MsgType = T
777   SettlInstMsgID                 Y       Unique identifier for this message
791   SettlInstReqID                 N       Not used
160   SettlInstMode                  Y       1=Standing Instructions                                    Formatted
792   SettlInstReqRejCode            N       Not used
 58   Text                           N       Not used
354   EncodedTextLen                 N
355   EncodedText                    N
165   SettlInstSource                N       2=Institution’s Settlement Instructions                      Formatted
 11   ClOrdID                        N       Not used
 60   TransactTime                   Y       Date/time this message was generated
778   NoSettlInst                    N       Number of SSIs in this message
      162     SettlInstID           N       Unique ID for this settlement instruction.
                                             Required except where SettlInstMode is 5=Reject SSI
                                             request
      163   SettlInstTransType      N       New, Replace, Cancel or Restate
                                             Required except where SettlInstMode is 5=Reject SSI
                                             request
      214 SettlInstRefID            N       Required where SettlInstTransType is Cancel or Replace
     component block <Parties>      N       Identity of sending custodian.                               Formatted
                                             Custodian should identify funds to which SSIs apply
      54    Side                    N       Can be used for SettlInstMode 1 if SSIs are being provided
                                             for a particular side.
      460   Product                 N       460/167/461 S/B Mandatory for SSI updates.                   Formatted
      167   SecurityType            N       460/167/461 S/B Mandatory for SSI updates.
      461   CFICode                 N       460/167/461 S/B Mandatory for SSI updates.
      168   EffectiveTime           N       Effective (start) date/time for this settlement instruction.
                                             Required except where SettlInstMode is 5=Reject SSI request
      126   ExpireTime              N       Termination date/time for this settlement instruction.
      779   LastUpdateTime          N       Date/time this settlement instruction was last updated (or
                                             created if not updated since creation).
                                             Required except where SettlInstMode is 5=Reject SSI request
     Component block                N       Should follow format shown in the FIX-SWIFT mapping Formatted
      <SettlInstructions>                    section above
      492                           N       For use with CIV settlement instructions
              PaymentMethod
      476    PaymentRef             N       For use with CIV settlement instructions
      488    CardHolderName         N       For use with CIV settlement instructions
      489    CardNumber             N       For use with CIV settlement instructions
      503    CardStartDate          N       For use with CIV settlement instructions
      490    CardExpDate            N       For use with CIV settlement instructions
      491    CardIssNum             N       For use with CIV settlement instructions
      504    PaymentDate            N       For use with CIV settlement instructions
      505    PaymentRemitterID      N       For use with CIV settlement instructions
      Standard Trailer               Y

The key to using this message effectively is the way in which the SettlInstructions
component block is populated. Precise population rules will be defined by the FIX
allocations working group but the general rules for each PSET are shown in appendix
2.




                                            37
10.12.         Appendix 1 – Relational Integrity
Notes on Relational Integrity and Compatibility with ISO15022
The FIX 4.4 post-execution messages have been designed to be compatible with the
ISO15022 standard. To ensure that all parties can translate a FIX message into a
SWIFT message without ambiguity, it is essential that the information on Allocation
Instructions and Confirmations conforms to certain relational integrity rules. This is
particularly applicable to the data within the component blocks. The ability to use
these blocks to define any number of parties gives considerable flexibility, but there
are certain pitfalls. The same SettlPartyIDRole should never repeat within the same
<SettlParties> block. For example, this slightly contrived combination would be
allowed because even though the values in SettlPartyID and SettlPartyIDSource are
identical, the values of tag 784 (784=30 and 783=27) are unique.

                                         <SettlParties>
Tag   Field Name                      Value          Comments
781   NoSettlPartyIDs                   2
     782   SettlPartyID           CITIGB21XXX
     783   SettlPartyIDSource          B            BIC
     784   SettlPartyRole              30           Agent
     782   SettlPartyID           CITIGB21XXX
     783   SettlPartyIDSource          B            BIC
     784   SettlPartyRole              27           Buyer/Seller (receiver/deliverer)
                                             </SettlParties>

However, this equally contrived combination would not be allowed because the             Formatted
values in SettlPartyRole are identical (784= 4 and 784=4) even though the BICs are
different.
                                          <SettlParties>
Tag   Field Name                       Value           Comments
781   NoSettlPartyIDs                    2
     782   SettlPartyID             DAKV1234
     783   SettlPartyIDSource           C             Generally accepted market code
     784   SettlPartyRole               4             Clearing firm
     782   SettlPartyID           DEUTFF2LXXX
     783   SettlPartyIDSource           B             BIC
     784   SettlPartyRole               4             Clearing firm
                                             </SettlParties>
                                                                                         Formatted: Bullets and Numbering
11.




                                            38
                                                              Formatted: Bullets and Numbering
13.APPENDIX 2 – IDENTIFYING FUNDS AND LEGAL ENTITIES

12.

13.1Statement of Problem

14. Main areas of concern

1.Legal and compliance

2.Processing

3.Risk

18.

19. In summary:

 No commonly agreed identifier for regulated entities.

 Difficult for counterparties to identify the other side’s
  contracting entity.

 No commonly agreed identifier for funds managed by these
  entities.

 No existing method (outside VMUs) for real-time enrichment
  of SDIs                                              on
  confirmation messages.

 Increased operational and credit risk.

 Difficult to group entities together for firm-wide risk
  exposure purposes.

 Failure to meet G30 requirements.

27.

13.2Assumptions

29. It is assumed that:




                               39
1.A new identifier, to be called the Legal Entity Identifier (LEI)
   and based on the existing 8-character BIC code structure,
   created.

2.The LEI will not be the same as any existing BIC. It is simply
   logic of the BIC and is an ISO15022-standard identifier.

3.The LEI will not be used for SWIFT messaging.

4.The LEI will be used to identify a unique regulated entity, or
   in the case of unregulated entities, the fund or
   organisation to which an order (or part of an order) is
   allocated.

5.An issuing authority for new identifiers will be appointed.

6.Agreement of all parties to the proposed structure will be
   obtained.

7.Data providers and regulators will agree to carry the new
   data fields.

8.The proposed hierarchy is designed to meet compliance
   (EDD, KYC, AML etc) and processing requirements only.

38.

13.2.1Example Data Structure




                                40
                               Client and Counter Party Data - illustrative
                                                                                    Parent
                              XYZ Holdings




                                                                                                      Legal Entity Information
                                  (UK)


                  XYZ                                   XYZ                         Subsidiaries
                Trading                                 N.V.



                                                                                    Business/
      XYZ Management          XYZ International           XYZ International         legal
        & Research                 U.K.                     Luxembourg
                                                                                    Entity

                                                                                    Fund Level




                                                                                                      Standing Settlement Inst.
           Fund A                   Fund A                      Fund B              Information

           Fund B                   Fund B                      Fund E


           Fund C                   Fund C                         H.K.Equities
                                                                                    Settlement
           Fund D                   Fund F
                                                                                    Instructions
                                                                 U.S. Governments
                                                                                    - by market
                                                                                    - by instrument
            German Equities           French Equities
                                                                     U.K.Gilts


             U.K. Equities             U.K. Options
                                                                  Cert of deposit

40.
41.

13.3Scope

43. While all elements of the structure are in scope, the most
    pressing need is to create those relationships which most
    directly affect STP:

44.

1.Legal/business entity

2.Fund

3.SDI.

48.

49. The relationship between those entities above the
    Legal/business Entity in the data structure shown in
    section 3.2.1 will be mainly used for risk calculations and
    are thus out of scope for security processing. Individual
    firms’ risk management departments can use existing data
    sources such as D&B, Bankers’ Almanac etc to link their
    risk groupings to the Business Entity structure proposed
    by this paper. We have not attempted to impose a formal

                                                                    41
      structure for those entities above the business/legal
      entities in the hierarchy because individual departments
      (risk, CRM, financial, compliance etc) will want to create
      their own groupings for this hierarchy.

13.4Suggested Implementation

13.4.1Ideal Structure

52. The basic problem to be solved is to create this relational
    structure:

                 Parent                 Subsidiary




      SSI                   Fund                     Business/legal entity




53.
54.

55. As explained earlier, the hierarchy above the
    legal/business entity level (Parent and Subsidiary) is more
    relevant to risk considerations and is therefore out of
    scope for trade processing and STP.

13.4.1.1 Legal Entities

57. National regulators and exchanges hold data on their
    members and legal entities which they regulate, but each
    of these organisations present their data in different forms
    and it is therefore difficult to consolidate the available
    information.

58.

59. The proposed solution is to work with SWIFT (possibly
    acting as issuing authority), national regulators and
    exchanges to ensure that each regulated business entity
    and exchange member firm is assigned a unique 8-


                                   42
      character LEI (based on the BIC code) and that the LEI is
      published on the exchanges’ and regulators’ databases as
      a mandatory field. For example:

60.

      Trading entity
      LEI: CITIGB2L


61.
62.

63. This will make it far easier to carry out know-your-client
    (KYC), Patriot Act and anti-money laundering (AML)
    compliance procedures. The LEI could also be used for
    regulatory reporting.

13.4.1.2 Funds

65. One of the most difficult problems faced by the industry is
    that there is no globally agreed fund identifier. Part of this
    gap is filled by OMGEO’s Alert product, but usage is far
    from universal.

66.

67. Again, the structure of the BIC code supplies a possible
    solution for creating a LEI hierarchy that uniquely
    identifies funds.

68.

69. The last 3 characters of the 11 character BIC code are
    intended to be used to identify branches of the parent
    institution represented by the 8-character BIC. However,
    given that these 3 characters can be arranged in a very
    large number of unique permutations they could also be
    used to identify individual funds without conflicting with
    their intended use as branch identifiers.

70.




                                43
71. The number (P) of 3-letter groups (r) that can be created
    from 26 letters (n) can be calculated using the following
    formula:

72.

                  n!
73. P(n,r) =
               (n  r )!

                                      26!
74. or in this example P(n,r) =              = 15,600 3-letter groups.
                                  ( 26  3)!

75. (If, in addition to using the letters A to Z, the numbers 0 to
    9 are included, the available number of unique groups
    goes up to 42,840). If characters are allowed to repeat
    within the groups, AAA, AAB, for example, the number of
    groups is even higher (363 =46,656)

76.

77. Therefore, we can create a unique LEI composed of the
    first 8 characters of the BIC to represent the legal entity
    plus a 3-letter group to give a possibility of at least 15600
    (42,840) fund ids. We can call this the Fund LEI.

78.

79. The next part of the relational structure is thus created:

80.

81.




                                  44
                               LEI

                         CITIGB2L




      FUND AAA                       FUND AAB
      LEI:CITIGB2L                   LEI: CITIGB2L
      FUND_LEI: CITIGB2LAAA          FUND_LEI: CITIGB2LAAB



                              FUNDS
82.
83.

84.

85.

86. There is no conflict between this new field and existing
    identifiers such as the Alert acronym/access code pairing.
    For example, an existing Alert fund under Omgeo Acronym
    BIGBANK1 with Omgeo Access Code 123 might have a
    Fund LEI of BIGBNY21XYZ, and Alert would show both
    values.

87.

88. It is also important to note that there would be no attempt
    to standardise fund identifiers across different fund
    managers. For example, if the Teacher’s Pension Fund of
    Texas was managed by 2 fund managers, each would
    create their own distinct 3-character Fund LEI. Similarly,
    when a fund’s trustees remove the mandate from one
    fund-manager and give it to another, the receiving
    manager will assign the fund an new Fund LEI.

13.4.1.3 Standing Delivery Instructions (SDIs)

90. Assuming that:

1.Creation of a globally-accepted, industry-wide SDI database
   not feasible.

                                            45
2.all organisations which publish data about funds or broker
    entities use the Fund LEI as the unique identifier.

3.all data vendors agree to take this additional field.

4.SSIs will conform to the ISO 15022 standard

95.

96. then the available solutions for transmitting this data are:

97.

1.Where there is no data vendor, brokers and buy-side firms
   can exchange this information bilaterally and save it in
   their own databases.

2.Participants can use “just-in-time” enrichment of allocation
   confirmation messages with SDI information.

100.

101.

                           LEGAL/BUSINESS ENTITY

                                   CITIGB2L




                FUND AAA                           FUND AAB
                LEI:CITIGB2L                       LEI: CITIGB2L
                FUND_LEI: CITIGB2LAAA              FUND_LEI: CITIGB2LAAB



                                        FUNDS


       SSI CITIGB2LAAA         SSI CITIGB2LAAA
       SSI_Equity              SSI_Fixed




                           SSIs
102.


                                              46
103.

13.5Just-in-Time SDI Enrichment

105. If all parties to a trade can agree on how to identify
   themselves to each other and the buy-side use the
   proposed Fund LEI model to identify their funds, there is
   no longer any need for the industry to use and maintain
   costly shared account and SDI databases. Instead,
   custodians would send fund managers a periodic update
   file (in ISO15022-compliant format) of basic SDI details
   which would be captured in a database within the buy-
   side’s OMS. This would have the advantage of keeping the
   responsibility for SDI maintenance with the custodians but
   allow fund managers to enrich their allocation messages
   with up-to-date SDIs. With their smaller number of SSIs,
   broker-dealers would maintain their own SDI data with
   which they would enrich their confirmations. Both sides
   would match the other’s SDIs for settlement channel
   compatibility, and if the match is successful, would then
   instruct for settlement. There would also be a major gain
   for sell-side firms who would no longer have the
   maintenance overhead of maintaining multiple SDIs for
   each client fund. The key to the success of this flow will be
   strict adherence to agreed data standards.

13.6Regulatory Considerations

107. One of the keys to the success of this approach is its
   acceptance by regulators and exchanges. It is likely that
   these bodies will welcome a global standard for identifying
   their member entities that does not conflict with existing
   identifiers, although there may be a reluctance to make the
   technology investment required to prepare their databases
   for the use of LEIs. Also, the adoption of the LEI structure
   directly addresses and number of the issues and action
   plans raised by the recently published G30 report, ‘Global
   Clearing and Settlement, a Plan of Action.’

108.

13.7Administration and Control



                               47
110. The issue of new LEIs and Fund LEIs will need to be
   controlled centrally by a single registration and issuing
   agency such as SWIFT. The service will need to be
   available H24, and the buy-side must be able to request
   and receive new Fund LEIs within 30 minutes. All requests
   for new LEIs at the entity level will be subject to
   compliance and legal checking in accordance with the
   governing law of their regulator. Although the creation of
   new entities will be a relatively rare event, there will be an
   administrative overhead involved: one option would be for
   the new entity firstly to request registration with a national
   regulator and for the regulator to make the request to the
   issuing agency for a new LEI. It is assumed that buy-side
   firms would not be willing to pay the full initial set-up costs
   involved in the creation of LEIs and Fund LEIs and that
   sell-side firms would be expected to foot some of the bill.
   This issue will affect any new identifiers that the industry
   chooses to adopt.

13.8Risk

13.8.1Project Risk

113. A number of issues and risks face this proposal:

  ROI proves insufficiently compelling to persuade all parties
   to adopt the solution.

  Buy-side OMS vendors unwilling to invest in the necessary
   changes to their systems.

  Regulators do not adopt the new identifiers.

  Control and admin overheads prove too high.

  Adherence to industry data standards is poor.

  Industry participants unwilling to face the start-up and
    maintenance costs.

13.8.2Operational Risk Reduction
One of the major potential advantages of the approach outlined in this paper is the
reduction of operational risk. All participants’ cost per transaction will reduce as will
the number of unmatched and failed trades. With the advent of Basel 2, any


                                            48
decrease in operational risk should be seen as a strong selling point for the LEI
model.




                                          49
                                                                                                                                                       Formatted: Bullets and Numbering
          13. Appendix 2 – MT54x Sequence E
          This section shows a summary of the best practice guidelines for populating the settlement details sequence of an ISO15022 message:

                 SubSeq. E1              SubSeq. E1                       SubSeq. E1                    SubSeq. E1       SubSeq. E3       SubSeq. E3
                                               Account of                            Account of the Alternate         Settlement
               Place of        Delivering or   Delivering or Client of Delivering    Client of       identification   Amount (including
                                                                                                                                        Deal Amount
               settlement      Receiving agent Receiving     or Receiving agent      Delivering or   (charity, tax    currency) for
                                               agent at CSD.                         Receiving agent id…)             against payment
               95P::PSET//4!a2 95P::DEAG or                   95P::SELL or
GLOBAL                                                                                                                19A::SETT//3!a15d
               !a2!c           REAG//4!a2!a2!c                BUYR//4!a2!a2!c
               95P::PSET//4!a2 95P::DEAG or                   95P::SELL or
Australia                                                                                                             19A::SETT//3!a15d
               !a2!c           REAG//4!a2!a2!c                BUYR//4!a2!a2!c
               95P::PSET//4!a2 95P::DEAG or                   95P::SELL or
Austria                                                                                                               19A::SETT//3!a15d
               !a2!c           REAG//4!a2!a2!c                BUYR//4!a2!a2!c
               95P::PSET//4!a2 95P::DEAG or                   95P::SELL or
Belgium                                                                                                               19A::SETT//3!a15d
               !a2!c           REAG//4!a2!a2!c                BUYR//4!a2!a2!c
               95P::PSET//4!a2 95P::DEAG or                   95P::SELL or
Canada                                                                               97A::SAFE//35x                   19A::SETT//3!a15d
               !a2!c           REAG//4!a2!a2!c                BUYR//4!a2!a2!c
                               95R::DEAG or
Canada
                               REAG/CUID/4!a
               95P::PSET//4!a2 95R::DEAG or                   95P::SELL or
Denmark                                                                                                               19A::SETT//3!a15d
               !a2!c           REAG/VPDK/5!n                  BUYR//4!a2!a2!c
                                                              95Q::SELL or
Denmark                                                                              97A::SAFE//35x
                                                              BUYR//4*35x
               95P::PSET//CED 95R::DEAG or                    95P::SELL or
ICSDs EOC                                                                                                             19A::SETT//3!a15d
               ELULL          REAG/CEDE/5!n                   BUYR//4!a2!a2!c
               95P::PSET//MG 95R::DEAG or                     95P::SELL or
ICSDs CLR                                                                                                             19A::SETT//3!a15d
               TCBEBE         REAG/ECLR/5!n                   BUYR//4!a2!a2!c




                                                                                50
               SubSeq. E1              SubSeq. E1                        SubSeq. E1                    SubSeq. E1       SubSeq. E3       SubSeq. E3
                                            Account of                              Account of the Alternate         Settlement
             Place of       Delivering or   Delivering or Client of Delivering      Client of       identification   Amount (including
                                                                                                                                       Deal Amount
             settlement     Receiving agent Receiving     or Receiving agent        Delivering or   (charity, tax    currency) for
                                            agent at CSD.                           Receiving agent id…)             against payment
             95P::PSET//4!a2 95P::DEAG or                    95P::SELL or
Finland                                                                                                              19A::SETT//3!a15d
             !a2!c           REAG//4!a2!a2!c                 BUYR//4!a2!a2!c
             95P::PSET//4!a2 95R::DEAG or                    95P::SELL or
France                                                                                                               19A::SETT//3!a15d
             !a2!c           REAG/SICV/5to8!n                BUYR//4!a2!a2!c
             95P::PSET//4!a2 95P::DEAG or                    95P::SELL or
Germany                                       97A::SAFE//7!n                                                         19A::SETT//3!a15d
             !a2!c           REAG//4!a2!a2!c                 BUYR//4!a2!a2!c
                             95R::DEAG or
Germany
                             REAG/DAKV/7!n
             95P::PSET//4!a2 95P::DEAG or                    95P::SELL or
Greece                                                                                                               19A::SETT//3!a15d
             !a2!c           REAG//4!a2!a2!c                 BUYR//4!a2!a2!c
             95P::PSET//4!a2 95P::DEAG or                    95P::SELL or
Hong Kong                                                                                                            19A::SETT//3!a15d
             !a2!c           REAG//4!a2!a2!c                 BUYR//4!a2!a2!c
             95P::PSET//4!a2 95P::DEAG or                    95P::SELL or
India                                                                                                                19A::SETT//3!a15d
             !a2!c           REAG//4!a2!a2!c                 BUYR//4!a2!a2!c
             95P::PSET//4!a2 95P::DEAG or                    95P::SELL or
Israel                                                                                                               19A::SETT//3!a15d
             !a2!c           REAG//4!a2!a2!c                 BUYR//4!a2!a2!c
                             95R::DEAG or
Israel
                             REAG/XTAE/4!n
             95P::PSET//4!a2 95P::DEAG or                    95P::SELL or                            95P::BUYR or
Italy                                                                                                                19A::SETT//3!a15d
             !a2!c           REAG//4!a2!a2!c                 BUYR//4!a2!a2!c                         SELL//4!a2!a2!c
                                                                                                     95S::ALTE//TXID
Italy
                                                                                                     /IT/30x
             95P::PSET//4!a2 95P::DEAG or                   95P::SELL or
Japan                                                                               97A::SAFE//35x                   19A::SETT//3!a15d
             !a2!c           REAG//4!a2!a2!c                BUYR//4!a2!a2!c
             95P::PSET//4!a2 95R::DEAG or                   95P::SELL or
Luxembourg                                                                                                           19A::SETT//3!a15d
             !a2!c           REAG/CEDE/5!n                  BUYR//4!a2!a2!c




                                                                               51
                 SubSeq. E1             SubSeq. E1                         SubSeq. E1                    SubSeq. E1       SubSeq. E3       SubSeq. E3
                                              Account of                              Account of the Alternate         Settlement
               Place of       Delivering or   Delivering or Client of Delivering      Client of       identification   Amount (including
                                                                                                                                         Deal Amount
               settlement     Receiving agent Receiving     or Receiving agent        Delivering or   (charity, tax    currency) for
                                              agent at CSD.                           Receiving agent id…)             against payment
               95P::PSET//4!a2 95P::DEAG or                    95P::SELL or
Norway                                                                                                                 19A::SETT//3!a15d
               !a2!c           REAG//4!a2!a2!c                 BUYR//4!a2!a2!c
               95P::PSET//4!a2 95P::DEAG or                    95P::SELL or
Portugal                                                                                                               19A::SETT//3!a15d
               !a2!c           REAG//4!a2!a2!c                 BUYR//4!a2!a2!c
               95P::PSET//4!a2 95P::DEAG or                    95P::SELL or
South Africa                                                                                                           19A::SETT//3!a15d
               !a2!c           REAG//4!a2!a2!c                 BUYR//4!a2!a2!c
               95P::PSET//4!a2 95P::DEAG or                    95P::SELL or
Spain                                                                                                                  19A::SETT//3!a15d
               !a2!c           REAG//4!a2!a2!c                 BUYR//4!a2!a2!c
               95P::PSET//4!a2 95P::DEAG or                    95P::SELL or
Sweden                                                                                                                 19A::SETT//3!a15d
               !a2!c           REAG//4!a2!a2!c                 BUYR//4!a2!a2!c
                               95R::DEAG or
               95P::PSET//4!a2                                 95P::SELL or
Switzerland                    REAG/SCOM/2!a6                                                                          19A::SETT//3!a15d
               !a2!c                                           BUYR//4!a2!a2!c
                               !n
                               95P::DEAG or
Switzerland
                               REAG//4!a2!a2!c
The            95P::PSET//4!a2 95P::DEAG or    97A::SAFE//35   95P::SELL or
                                                                                      97A::SAFE//35x                   19A::SETT//3!a15d
Netherlands    !a2!c           REAG//4!a2!a2!c x               BUYR//4!a2!a2!c
               95P::PSET//4!a2 95P::DEAG or                    95P::SELL or
Turkey                                                                                                                 19A::SETT//3!a15d
               !a2!c           REAG//4!a2!a2!c                 BUYR//4!a2!a2!c
               95P::PSET//4!a2 95R::DEAG or                    95P::SELL or                          95P::BUYR or                      19A::DEAL//3!a1
UK and IE                                                                                                            19A::SETT//3!a15d
               !a2!c           REAG/CRST/5x                    BUYR//4!a2!a2!c                       SELL//4!a2!a2!c                   5d
                                                                                                     95S::ALTE//CHT
UK and IE
                                                                                                     Y/2!a/30x
               95P::PSET//DTC 95R::DEAG or                     95R::SELL or                                                            19A::DEAL//3!a1
US                                                                                    97A::SAFE//35x                 19A::SETT//3!a15d
               YUS33          REAG/DTCYID/4!n                  BUYR/DTCYID/8!n                                                         5d
                                                               95P::SELL or
US
                                                               BUYR//4!a2!a2!c




                                                                                 52
            SubSeq. E1             SubSeq. E1                       SubSeq. E1                   SubSeq. E1       SubSeq. E3         SubSeq. E3
                                         Account of                           Account of the Alternate         Settlement
          Place of       Delivering or   Delivering or Client of Delivering   Client of       identification   Amount (including
                                                                                                                                 Deal Amount
          settlement     Receiving agent Receiving     or Receiving agent     Delivering or   (charity, tax    currency) for
                                         agent at CSD.                        Receiving agent id…)             against payment
          95P::PSET//FRN 95R::DEAG or  97A::SAFE//35 95R::SELL or                                                                  19A::DEAL//3!a1
US                                                                                                             19A::SETT//3!a15d
          YUS33          REAG/USFW/9!n x             BUYR/DTCYID/8!n                                                               5d
                                                     95P::SELL or
US
                                                     BUYR//4!a2!a2!c

     Source: Activest/SMPG




                                                                        53

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:21
posted:10/3/2012
language:Unknown
pages:53