SWIFT ISO 15022 Frequently Asked Questions

SWIFT Working Groups / Best Market Practices

Message Features and Functions

SWIFT Working Groups / Best Market Practices

Are you a participant of any group defining Best Market Practices and/or STP guidelines for your local market? The Securities Services network participates in many of the local Best Market Practice groups and in other industry standards groups. Further, Citi has offered to assist SWIFT by hosting meetings and identifying major players and counterparties in those local markets where no group has been formed to date.

Do you find the ISO 15022 Standard and the Best Market Practices sufficient to achieve SWIFT STP? If not, do you have additional requirements for your SWIFT processing? If you do, what are they? Securities Services has implemented ISO 15022 messages for the overall global template and those unambiguous Best Market Practices published prior to January 2001. Where possible, we have also incorporated Best Market Practices published after that date. We will continue to incorporate unambiguous, published Best Market Practices in subsequent releases. We have been working with each local Best Market Practice group if established to identify additional STP requirements. It is our goal to be in agreement with those Best Market Practice recommendations. If, however, the existing Best Market Practices are unable to achieve STP, we will make recommendations accordingly. Following this effort we have identified a list of country conditional requirements for several countries and they are detailed in "Citibank ISO 15022 Country Conditions List for Instructions", which can be found in the Message Format Matrices section. Where SWIFT Standard or SMPG have not published appropriate codewords, Citibank maintains 70E codewords necessary for processing of special value-added services, which are detailed in "Citibank ISO 15022 Field 70E Codewords Mapping for Settlement Instruction and Confirmation Messages" also found in the Message Format Matrices. We continue to promote these improvements to the SMPG's and SWIFT standard to ensure they are encapsulated in the correct fields rather than narrative field.

Will you adhere to the SMPG recommendations, what will you do if there is none for a market? We are adhering to most of the SMPG recommendations. Others require continued industry discussion. Work groups in each country continuously define and redefine their market requirements. The process is lengthy and requires validation by various business communities. Once the requirements are officially validated and published, we will make the necessary updates. If there are no SMPG recommendations specific for a market yet, Citibank will follow the SMPG common elements until SMPG recommendations are accepted by the industry.

What are the 10 common elements recommended by SMPG?

  • Sender's Message Reference
  • Settlement Date
  • Trade Date
  • Identification of Financial Instrument
  • Quantity of Financial Instrument to be settled
  • Safekeeping account to be credited or debited
  • Delivering of Receiving Agent
  • Client of Delivering or Receiving Agent
  • Place of Settlement
  • Settlement Amount

Message Features and Functions

The new standards support several new features and functions, for example, linked transactions and back-to-back transactions. Please list the new functions that your organization is planning to use in the new standards.

  • Linking of settlements for turnarounds and block trades
  • Pairoffs
  • Allegement notices and statements
  • Linking of all messages associated with a specified Corporate Action event
  • Intra-position advices, instructions and statements

Beyond the recommendation of the ISO 15022 SWIFT Standard, do you plan to use any proprietary data scheme codes? We anticipate that a number of unique keywords may have to be developed to address certain specific processing requirements in particular market defined processing systems.

Given that the ISO 7775 Tag 72 appears to have been reborn as Tag 70E in ISO 15022, do you plan to use Tag 70E? We strongly discourage the use of Tag 70E for other than ancillary information. We are continuing our participation in industry groups to ensure that it does not become necessary to define process-specific keywords or data tags. To the extent that this becomes true, we would like to limit the use of Tag 70E to a single occurrence, as part of the Additional Information Block.

Do you expect settlement messages to be linked? Only if they pertain to turnarounds or block trade allocations.

Do you plan to always adhere to the ISIN standard for security ID? We strongly encourage the use of ISIN as the security identifier. Where ISIN may not be available, we will support an alternate identifier scheme, such as SEDOL, CUSIP or local country identifier along with the proper Issuer Code in field 35B.

Although ISO 15022 allows for numerous types of parties to a transaction, which party fields do you require? For trading broker? For clearing broker? For example, in the case where the original trading broker was in one market, but an intermediary trading broker was used in another market, do you require the intermediary party? For Receive transactions, we require the DEAG (Delivering Agent) or DECU (Deliverer's Custodian) parties; we also would need the BUYR (Buyer) party identified, where identification of the ultimate beneficiary is necessary.

For Deliver transactions, we require the REAG (Receiving Agent) or RECU (Receiver's Custodian) parties; we also would need the BUYR (Buyer) party identified, where identification of the ultimate beneficiary is necessary.

A Receiver's or Deliverer's Intermediary (REI1, DEI1) is necessary only to the extent that it corresponds to one of the parties identified above.

Will you always use the BIC standard for a party ID? In order to ensure optimal STP rates, we strongly recommend the use of BIC Codes as party identifiers. However, it is understood that a number of other identifiers may be appropriate on certain occasions. Typically, these include participant numbers at depositories (DTC, CREST, SICOVAM, etc.), Fed numbers, ABA numbers, etc. These may be used, in conjunction with the appropriate Proprietary Code.

Funds clearing system participant numbers and separate cash accounts will be specified to the extent that in a particular transaction funds settle separately from securities.

Do you require place of settlement? If yes, regarding book entry security, do you always plan to use BICs for clearinghouses and depositories? Regarding physical security, place of settlement do you plan to use ISO country codes? Place of Settlement is the 10th common element recommended by SMPG. Please refer the list of PSET published by SWIFT on behalf of SMPG. BICs for clearinghouses and depositories are used in most cases. Place of Settlement (PSET) will be mandatory for Citibank in markets where there is more than one place of settlement, except US market. PSET is also supported if the settlement condition (STCO) is physical.

Where can the clients find the latest version of List of Places of Settlement? Securities Market Practice Group maintains the current List of Places of Settlement. Please go to http://www.smpg.info/, enter the site, click on Documents, select FINAL folder and select Settlement and Reconciliation sub folder. Scroll down and find the List of Places of Settlement.

Whereas the MT 534 only allowed one occurrence of change of status / fail code, the MT 548 allows multiple occurrences of change of status / fail codes. Using one transaction per MT 548, how many change of status / fail codes per MT 548 do you plan to use? Is the increased number of different change of status / fail code values sufficient for your needs? If not, will you use Tag 70E to further specify the change of status / fail code?

We plan to use a single status/fail code per MT 548 message (itself pertaining to a single transaction). We have identified and submitted to SWIFT for incorporation into the MT 548 definition a number of additional status/fail codes. We feel that these, along with the initially defined ones are presently adequate to address status indication requirements, without resorting to the use of Tag 70E.

Have you considered the case of a complicated corporate action with numerous action options for numerous accounts? If that corporate action has more data than would fit in one MT 564 (up to 10K in length), how would you handle that? We would use the MT 568 as a continuation message to the MT 564.

Will you continue to use ISO 7775 MT 560s and MT 561s for proxy information and instruction, as they have no equivalent, ISO 15022 message types? SWIFT guidelines for the Corporate Action MEET event are to use a combination of the MT 564 and MT 568, as is valid in the 2001 release. The 2002 release has provided the following event types: MEET, OMET and XMET. Citibank will support OMET and XMET in a future phase. In the interim, Securities Services will use a MEET event with a combination of the MT 564 and MT 568 to convey proxy information.

Securities Services will follow the SWFT guideline to accept proxy instructions via MT 565.

Will you support CANC and REMO for MT 578? Citi will follow the SWIFT standard definition about CANC and REMO as below:

  • CANC: Cancellation — This is to cancel a previously sent allegement.
  • NEWM: New — This is a new allegement.
  • REMO: Removal — This is to acknowledge that a previously sent allegement is no longer outstanding.
Citi will not support CANC.

For ISO 7775, Citi uses MT 534 to advise clients of missing instruction. Citi will notify customers of missing settlement instructions in cases where Citi has received copies of the broker confirmations or is notified of pending trades by counterparties (including depositories) attempting to pre-match, yet no instructions from customers have been received.

For ISO 15022, Citi will continue this process using MT 578 to advise clients of missing instructions. Responses from customers to these MT 578s should be MT 540-3 settlement instructions with 23G NEWM for valid transactions and should contain the Citibank transaction reference number of the MT 578 sent to the customer using 20C RELA in A1 Linkages. When REMO process is defined by SMPG, Citi will follow the recommendation.

What is the minimum information required on a cancel message? The minimum information required for cancellation is to change the function of the message to CANC. To provide the subsequence A1 linkages, referencing the original instruction being cancelled using PREV. Then provide any mandatory sequences in the message and within the mandatory sequence provide the mandatory fields at a minimum.

Will you support consolidated statements? Citi will support consolidated MT 535 and MT 536 statements. In consolidated statements, the main (parent) account is identified in Sequence A and each sub-safekeeping account in Sequence B. If a client elects to receive statements on individual safekeeping accounts, a separate statement message will be sent for each sub-safekeeping account and identify the sub-safekeeping account in Sequence A.

Will you support GENR code and narrative field for MT 564? Citi will support GENR in MT 564, Subsequence B2 Account Information, Tag 97a. In all countries, event notification will be sent at the safekeeping account level unless GENR is selected by clients via Standing Instruction. Citi will support narrative field using ADTX in Sequence F only.