Appendix 6-H: Use of <SettlInstructions> Component Block

Introduction

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

This component block can be used either to contain full settlement instruction details (i.e. settlement agent identities and account numbers) or a reference to a standing instruction database.

• When used to refer to instructions held on a standing instructions database, the StandInstDbType, StandInstDbName and 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 database. The NoDlvyInst repeating group 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 SettlDeliveryType field is used to identify the type of settlement being represented by these settlement instructions, i.e. DVP (delivery vs payment), FOP (free of payment), hold in custody etc.

Where the component block is used to describe specific settlement instructions (i.e. using the NoDlvyInst repeating group), the number of entries in the NoDlvyInst repeating group is determined by the contents of the SettlDeliveryType field and 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 have their settlement instructions specified. The matrix of usage of the NoDlvyInst repeating group is therefore as follows:

Allocation Instruction, Allocation Report or Settlement Instruction

Confirmation

The actual instructions themselves are held within the SettlParties component block inside the NoDlvyInst repeating group. This contains a repeating group of party identifiers and sub ids which 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.

Delivery Instruction Formatting & Structure

Parties & Party Sub-IDs

FIX supports the concept of a "SettlParty", this being an organisation or individual connected in some way to the settlement of a financial transaction. Every SettlParty has a role (defining what the SettlParty is doing), an identifier, SettlPartyID (with a SettlPartyIDSource to identify the type of SettlPartyID) and any number of sub-identifiers (SettlPartySubID), each with a SettlPartySubIDType to define the type of sub-identifier.

For the purposes of settlement instruction definition, the party sub-identifiers can be taken to represent one of three things:

• An alternative identifier for the SettlParty. For example, if the SettlParty's primary identifier is its BIC (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.
• 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, rather than under the SettlParty on whose behalf the account is held. For example, the account number of a custodian at an agent is held as a SettlPartySubID under the SettlParty representing the agent, not the custodian.
• 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 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.

Mapping FIX to ISO15022

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
• Q = Name and address
• S = Alternate ID

In the interests of assuring STP, FIX fields and messages only map to ISO15022 options C, P or R (with a strong preference for P - BIC wherever possible). 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. For example, a PSET BIC should be represented in FIX using these tags:

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

Notes on CSD 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
• 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.

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.

Settlement instructions for German domestic settlement with Citibank Frankfurt as local agent, into account 11921500:

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

Registration Details & Investor IDs

Where registration details (e.g. a broker or agent's registration number or name) needs to be specified as part of a settlement instruction, this can be done as a SettlPartySubID with SettlPartySubIDType of 11 (registration number) or 14 (registration name) as appropriate. Investor IDs are represented by a completely separate SettlParty with a SettlPartyRole of 5 (investor id).

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.

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

However, this equally contrived combination would not be allowed because the values in SettlPartyRole are identical (784= 4 and 784=4) even though the BICs are different.