Banking Back-Office Processing

Transcription

1 Banking Back-Office Processing Settlements Guide Copyright 2002, Unisys Corporation. All rights reserved Unisys is a trademark of Unisys Corporation Release October 2003 Printed in the UK

2 The names, places, and/or events used in this publication are not intended to correspond to any individual, group, or association existing, living or otherwise. Any similarity or likeness of the names, places and/or events with the names of any individual, living or otherwise, or that of any group or association is purely coincidental and unintentional. NO WARRANTIES OF ANY NATURE ARE EXTENDED BY THIS DOCUMENT. Any product and related material disclosed herein are only furnished pursuant and subject to the terms and conditions of a duly executed Program Product License or Agreement to purchase or lease equipment. The only warranties made by Unisys, if any, with respect to the products described in this document are set forth in such License or Agreement. Unisys cannot accept any financial or other responsibility that may be the result of your use of the information in this document or software material, including direct, indirect, special or consequential damages. You should be very careful to ensure that the use of this information and/or software material complies with the laws, rules, and regulations of the jurisdictions with respect to which it is used. The information contained herein is subject to change without notice. Revisions may be issued to advise of such changes and/or additions. Correspondence regarding this publication should be forwarded to Unisys Corporation, Bakers Court, Bakers Road, Uxbridge, Middlesex, UB8 1RG, United Kingdom. All registered trademarks are acknowledged.

3 About This Guide Purpose This guide provides information for users managing the settlement of contracts entered in to the Unisys Banking Back-Office Processing product. The information contained in this guide is also available as online help. Scope This guide describes the authorisation procedure for settlements, the static data that supports settlements, and the screens used for customer transfers. An example is provided of each of the screens associated with these processes. Audience This guide is intended for the staff responsible for the management and processing of settlements. Prerequisites Anyone using this guide should have a working knowledge of the S.W.I.F.T. network. Users of this guide should have read the Starter s Guide that provides instruction in the use of the screens. How To Use This Guide This guide is a reference document for staff responsible for managing settlement processes, setting up static data that supports settlements and processing settlement messages and customer transfers. Throughout this document the following terms and definitions apply: The acronym S.W.I.F.T. refers to the S.W.I.F.T. II network system Input messages are defined as messages input to the S.W.I.F.T. network via an online interface or a batch file accessible to systems, such as S.W.I.F.T. Alliance iii

4 About This Guide About Urbis The usage of the product name Urbis is due to be phased out as part of the Unisys re-branding exercise. The replacement will be the generic term "Banking Back-Office Processing" solution or "Banking Back-Office" for short. To provide continuity with existing product documentation, the name Urbis is used within this document, but is synonymous with Banking Back-Office Processing. Organisation This guide consists of twelve sections and two appendices: Section 1: Overview of Settlements This section outlines a standard flow of events from contract entry to settlement. Included are the settlement and accounting authorisation queues for cash and paper settlements. Section 2: Static Data This section describes the screens used to maintain the static data that supports settlements processing. Section 3: Contract Auditing/Authorisation This section describes the screens used to control the contract management and contract settlement queues. Section 4: Accounting Authorisation and Paper Settlements This section describes the screens used to manage the accounting authorisation and paper settlement queues. Section 5: Depots This section describes the screens used to define and manage depository information. Also included is information on the inquiry screens used to view information on holdings in depositories. Section 6: Individual Settlement Authorisation This section describes the screens used to authorise the release of messages for printing or sending to S.W.I.F.T. The section also includes descriptions of the screens used to repair messages and add messages. iv

5 About This Guide Section 7. LA Commercial Loans Fee Settlements This section describes the screens used to authorise LA Commercial Loans Fee settlements. Each of the associated screens is illustrated and a short description is given. Section 8. Clean Payments This section describes the screens associated with entering Clean Payment transactions. Each of the associated data entry screens is illustrated and a short description is given. Section 9. Nostro Transfers This section describes the screens used to transfer funds between nostro accounts at different correspondent banks. Each of the associated data entry screens is illustrated and a short description is given. Section 10. Netting of Contracts This section describes the screens used to set-up and maintain netting agreements. This section also describes how netting contracts are selected and authorised. Section 11. Continuous Linked Settlement This section describes the screens used to set-up and maintain continuous linked settlement (CLS). This includes the definition of CLS service providers, the clients and currencies that can access the functionality, and inquiry screens to show the contracts affected. Section 12: Definition of Field Names This section describes all the field names on the screens described in this guide. The fields are listed in alphabetical order. Appendix A: S.W.I.F.T. Messages Generated by Contract Type This appendix contains a table showing the types of S.W.I.F.T. message that the system can generate for a contract type. Appendix B: S.W.I.F.T. Confirmation Message Construction This appendix gives examples of typical S.W.I.F.T. confirmation messages sent by Urbis v

6 About This Guide Related Product Information Product Overview ( ) This document describes the capabilities and benefits of the modules of the Banking Back-Office Processing system. It consists of an overview of the system, and a description of each of the modules and interfaces available. It is intended for use by senior management. Operations Reference Card ( ) This document is a single card that provides a list of screen names and their mnemonics. The list is organised according to the menu structure of the Graphical User Interface. The card also describes how to log on and off the system, enter data, make inquiries and print reports. These instructions are relevant to the Graphical User Interface only. Starter s Guide ( ) This guide describes how to enter data and make online inquiries. It also includes a description and example of commonly used data entry and inquiry screens. This guide is intended for all new and inexperienced personnel who need to enter data and make inquiries. Guide to Setting Up ( ) This guide describes how to set up parameters that govern the operating environment of the system. It describes the procedures for setting up the business and operational tables, and setting up usercodes and access security. The procedures for setting up blueprint parameters are provided with a description of each parameter. It should be used by all persons involved in installation, implementation and maintenance of these system parameters. Core Functions and Inquiries Guide ( ) This guide describes the kernel functions that are used regularly for the maintenance of information utilised by a number of modules. It describes the procedures for setting up and maintaining data, such as market rates and dealers. It also describes inquiries that are common to all contracts. This guide is relevant to all users. Clients and Accounts Administration Guide ( ) This guide describes the data entry and inquiry screens associated with setting up and maintaining client details. This guide also describes the set up and maintenance of client accounts, including automatic payments (standing orders). An appendix covers the calculations used by client accounts. This should be used by personnel preparing information for data entry. General Ledger Administration Guide ( ) This guide describes the data entry screens associated with General Ledger transactions. This should be used by personnel preparing information for data entry. vi

7 About This Guide Risk Management Administration Guide ( ) This guide describes the data entry screens associated with setting up limits and exposures. The guide also describes the screens associated with portfolios. The amounts that represent book and market values are listed by module in an appendix. This guide is intended for personnel preparing information for data entry and those concerned with controlling risk. Commercial Loans Administration Guide ( ) This guide describes the data entry screens associated with Commercial Loan transactions. This includes entry of commitments, various types of drawdown and contract schedules. An appendix gives the calculations used in the processing of Commercial Loan transactions. This guide is intended for personnel preparing information for data entry. Foreign Exchange and Money Market Administration Guide ( ) This guide describes the data entry screens associated with Foreign Exchange and Money Market transactions. An appendix gives the calculations used in the processing of Foreign Exchange and Money Market transactions. This guide is intended for personnel preparing information for data entry. Forward Rate Agreements and Interest Rate Swaps Administration Guide ( ) This guide describes the data entry screens and some related inquiries associated with Forward Rate Agreement and Interest Rate Swaps transactions. An appendix gives the calculations used in the processing of Forward Rate Agreement and Interest Rate Swap transactions. This guide is intended for personnel preparing information for data entry. Futures Administration Guide ( ) This guide describes the data entry screens associated with Futures transactions and some related inquiries. An appendix gives the calculations used in the processing of Futures transactions. This guide is intended for personnel preparing information for data entry. Traded Options Administration Guide ( ) This guide describes the data entry screens associated with Options transactions. An appendix gives the calculations used in the processing of Options transactions. This guide is intended for personnel preparing information for data entry. OTC Options Administration Guide ( ) This guide describes the data entry screens associated with OTC Options transactions. An appendix gives the calculations used in the processing of OTC Options transactions. This guide is intended for personnel preparing information for data entry vii

8 About This Guide Securities Administration Guide ( ) This guide describes the data entry screens associated with Interest Bearing Securities, Discounted Securities and Repurchase Agreements transactions and some related inquiries. An appendix gives the calculations used in the processing of Securities transactions. This guide is intended for personnel preparing information for data entry. Trade Finance Administration Guide ( ) This guide describes the data entry screens used by the Trade Finance department. This guide is intended for personnel preparing information for data entry. Generalised Fees Administration Guide ( ) This guide describes the data entry screens associated with Fee transactions and supporting business table. This guide is intended for personnel preparing information for data entry. Core On-Demand Reports ( ) This guide describes how to run online reports that are provided in the core of the system and which will be relevant to most implementations of the system. Any options available when producing a report are detailed as well as any specific calculations. On-Demand Reports Guide ( ) This guide describes on-demand reports in alphabetical order. Any options available when producing a report are detailed as well as any specific calculations. Note: core reports are described in the Core On-Demand Reports Guide; retail reports are described in the Retail On- Demand Reports Guide. Overnight Reports ( ) This guide describes how to run offline reports. This includes an overview of overnight processing. Instructions on how to initiate reports are given. This guide should be used by all personnel who need to understand the reports and the overnight process. Data Dictionary ( ) This document provides details of data fields within every dataset on your banking systems database. This document should be used by staff preparing the accounting models and writing SQL reports to inquire on the database. Guide to Interfaces with External Systems ( ) This guide describes the running of all the interfaces between your Banking Back Office system and external systems. This guide is intended for personnel involved in setting up and running external interfaces. viii

9 About This Guide Order Transport Management System ( ) This guide describes how to enter stock exchange securities contracts using the Order Transport and Management System. The screens in this guide allow users to add, maintain and inquire on deals, convert deals into stock exchange securities contracts, and liaise with brokers to complete settlement of a deal. This guide is intended for personnel preparing information for data entry. Portfolio Management ( ) This guide describes how to create portfolios for the clients and agents who will be trading stock exchange securities with your institution. A large array of inquiry screens for managing these portfolios is also described. This guide is intended for personnel preparing information for data entry. Stock Exchange and Securities Management ( ) This guide describes how to set up and maintain the securities master file, allowing you to record details of stock exchange securities. This guide also describes how to create, maintain and inquire on contracts based on stock exchange securities, including the necessary static data. Loan Administration System Guide ( ) This guide describes the data entry screens associated with Syndicated Loans. It includes entry of facilities, and contracts such as drawdowns, guarantees and acceptances and their schedules. The screens in this guide allow users to enter data using workflows. This guide is intended for personnel preparing information for data entry. Static Database Transaction Input Guide ( ) This guide, in conjunction with the static database, enables users to evaluate the functions and features of many of the modules. It should be used by persons who are familiarising themselves with the systems functionality ix

10 About This Guide x

11 Contents About This Guide... iii Section 1 Overview of Settlements Introduction Settlement Process Manual Process Flow Contract Entry Stage Contract Auditing/Authorisation Individual Settlement Messages S.W.I.F.T. BIC Codes Messages to TARGET and CHAPS TARGET CHAPS IBAN Numbers Credit and Debit Advices Accounting Authorisation Interest Bearing and Discounted Paper Securities Introduction to Paper Settlement Managing Paper Settlement Depots Setting Up Depots Using Depots Inquiring on Holdings Overview of Clean Payments Inward Clean Payments Automatic Authorisation of Clean Payments Clean Payments Screen Flow Inward Payment Screen Flow Clean Payment and Client Account Management Services Overview of Nostro Transfers Straight Through Processing of Settlements STP Processing Flow STP Settlement Authorisation Netting Establishing Netting Continuous Linked Settlement Setting Up Continuous Linked Settlement Using Continuous Linked Settlement Euro Related Information xi

12 Contents Section 2 Static Data Introduction Agent Details (AGNTM) Agent Inquiry (AGNTI) Agent Settlement Defaults (AGDFM) Agent Default Inquiry (AGDFI) Non Standard Settlement Instructions (NSTDM) Nostro Details (NSTRO) Nostro Settlement Defaults (NSDFM) Nostro Default Inquiry (NSDFI) Client Settlement Instructions for LA (CISIM) LA Client Settlement Instructions Authorisation Queue (CDATI) Payment Instruction Narratives (PCNRM) Security for SWIFT Tag Codes (STAGA) Section 3 Contract Auditing/Authorisation Introduction Screen Flow for Contract Auditing/Authorisation Deals Input Confirmation (AWBOI) Confirming Contract Details Removing a Contract from the Contract Management Queue Settlement Instructions Confirmation (AWSTI) Confirming Contract Settlement Instructions Removing a Contract from the Contract Settlement Queue Section 4 Accounting Authorisation and Paper Settlements Introduction Screen Flow for Accounting Authorisation Accounting Authorisation Queue (ACQUE) Accounting Authorisation (ACATM) Accounting Amount Parameters Allocating Amounts using Accounting Authorisation (ACATM) Screen Flow for Paper Settlement Management Paper Settlement Authorisation Queue (PSQUE) Changing the Status of a Paper Settlement Amount xii

13 Contents Section 5 Depots Introduction Screen Flow for Setting Up Depots Setting Up Depots Screens Depository Maintenance (CSDM) Depot and Account Definition (DEPAM) Depot Defaults (SPSTM) Depot and Account Definition Inquiry (DEPAI) Depot Defaults Inquiry (SPSTI) Depot Holdings Inquiry Screens Depot Account Holdings Position Inquiry (DEPSI) Depot Holdings Transaction Inquiry (DEPCI) Section 6 Individual Settlement Authorisation Introduction Screen Flow for Settlement Message Authorisation Outstanding Settlement Messages (SETCN) Authorise Release of Event Messages (SETTA) Authorise Release of Event Messages for LA Participants (SETTB) Settlement Message Review and Repair (MESSR) Screen Flow for Manual Message Production Settlement Message Add (MESSA) S.W.I.F.T. CASmf Interface Inquiry (CASMI) Section 7 Loans Administration Fee Settlements Introduction Accounting Events for Authorised Fee Settlement Loans Administration Fee Settlements Screens LA Fee Settlement Confirmation (LARSM) LA Fee Settlement Authorisation (LAFAM) Section 8 Clean Payments Introduction to Clean Payments Clean Payments Status Clean Payment Screens Clean Payments Default Maintenance (CPDFM) Clean Payments Addition (CPAYA) MT103 Additional Details Screens MT202 Additional Details Screens Clean Payments Authorisation (CPAUT) Outward Clean Payments Amendment (CPAYC) Outward Clean Payments Inquiry (CPAYI) MT103 and MT202 Inquiry Screens Clean Payments Inquiry by Account (CPACQ) Clean Payments Inquiry by Product (CPPRQ) xiii

14 Contents Inward Clean Payments Screens Outbound S.W.I.F.T. Message Inquiry (MSGSI) Incoming Clean Payments Inquiry (CPINI) Output from Message Inquiry (MSGI) Section 9 Nostro Transfers Introduction Nostro Transfer Screens Nostro Transfer Add (NSXFA) Nostro Transfer Reversal (NSXFR) Section 10 Netting of Contracts Introduction to Netting Setting up Netting Types Netting Type Maintenance (NTTYM) Netting Type to Product Linkage (NTTPM) Netting Type to Accounting Centre Linkage (NTBRM) Entering Netting Agreements Client Netting Agreements (NTAGM) Client Netting Agreement - Currency Cut Off Days (NTACM) Client Netting Agreement - Product (NTAPM) Authorising Netting Settlements Netted Settlements - Lead In (NETCN) Netted Settlements - Authorise (NETTA) Netting Inquiries Overview of Netting Inquiries Netting Agreements Inquiry (NTAGI) Netted Payments Inquiry (NETTI) Section 11 Continuous Linked Settlement Screens Introduction CLS Maintenance Screens CLS Provider Detail Maintenance (CLSDM) CLS Counterparty Maintenance (CLSCM) CLS Currency Maintenance (CLSCY) CLS Inquiry Screens CLS Balance Inquiry (CLSBI) CLS Balance Breakdown Inquiry (CLSCI) Section 12 Definition of Field Names Introduction xiv

15 Contents Appendix A S.W.I.F.T. Messages Generated by Contract Type S.W.I.F.T. Message Types Supported... A 1 Table of S.W.I.F.T. Message Types Generated... A 3 Appendix B S.W.I.F.T. Confirmation Message Construction MT 300 Foreign Exchange Confirmation... B 1 MT 305 Foreign Currency Option Confirmation... B 4 MT 320 Fixed Loan/Deposit Confirmation... B 5 MT 330 Call/Notice Loan/Deposit Confirmation... B 9 MT 340 Forward Rate Agreement Confirmation... B 12 MT 341 Forward Rate Agreement Settlement Confirmation... B 15 MT 360 Single Currency Interest Rate Derivative Confirmation... B 17 MT 361 Cross Currency Interest Rate Swap Confirmation.. B 24 MT 364 Single Currency Interest Rate Derivative Termination/ Recouponing... B 33 MT 365 Cross Currency Interest Rate Swap Termination/Recouponing... B 35 MT 518 Market-Side Securities Trade Confirmation... B 39 Index... Index xv

16 Contents xvi

17 Figures 1 1 Outline of Settlements Process Flow BIC Directory Inquiry window Example of Amount Parameters Example of Allocation of Amounts Screen Flow for Processing Clean Payments Screen Flow for Processing Clean Payments STP Process Flow Establishing Netting Agreements Agent Details screen Agent Inquiry screen Agent Settlement Defaults screen Agent Default Inquiry screen Non Standard Settlement Instructions screen Nostro Details screen Nostro Settlement Defaults screen Nostro Default Inquiry screen Client Settlement Instructions for LA screen LA Client Settlement Instructions Authorisation Queue screen Payment Instruction Narratives screen Security for SWIFT Tag Codes screen Contract Auditing/Authorisation Screens Deals Input Confirmation screen Settlement Instructions Confirmation screen Accounting Authorisation Screens Accounting Authorisation Queue screen Accounting Authorisation screen Paper Settlement Screens Paper Settlement Authorisation Queue screen Depot Definition Screens Depository Maintenance screen Depot and Account Definition screen Depot Defaults screen Depot and Account Definition Inquiry screen Depot Defaults Inquiry screen Depot Account Holdings Position Inquiry screen Depot Account Holdings Contract Inquiry screen Settlement Message Authorisation Screens Outstanding Settlement Messages screen Authorise Release of Event Messages screen Authorise Release of Event Messages for LA Participants screen xvii

18 Figures 6 5 Settlement Message Review and Repair screen Manual Settlement Message Production Settlement Message Add screen S.W.I.F.T. CASmf Interface Inquiry screen LA Fee Settlement Confirmation screen LA Fee Settlement Authorisation screen Clean Payments Default Maintenance screen Clean Payments Addition screen Clean Payment Message Input Screen One 103 screen Clean Payment Message Input Screen Two 103 screen Clean Payment Message Input Screen Three 103 Screen Clean Payment Message Input Screen Four 103 Screen Clean Payments Message Input Screen One 202 screen Clean Payments Message Input Screen Two 202 screen Clean Payments Authorisation screen Outward Clean Payments Amendment screen Outward Clean Payments Inquiry screen Clean Payments Inquiry by Account screen Clean Payments Inquiry by Product screen Outbound S.W.I.F.T. Message Inquiry screen Inward Clean Payments Inquiry screen Output from Message Inquiry screen Nostro Transfer Add screen Nostro Transfer Reversal screen Netting Type Maintenance screen Netting Type to Product Linkage screen Netting Type to Accounting Centre Linkage screen Client Netting Agreements screen Client Netting Agreement - Currency Cut Off Days screen Client Netting Agreement - Product screen Flow Chart for Authorising Netting Settlements Netted Settlements - Lead In screen Netted Settlements - Authorise screen Netting Agreements Inquiry screen Netted Payments Inquiry screen CLS Provider Detail Maintenance screen CLS Counterparty Maintenance screen CLS Currency Maintenance screen CLS Balance Inquiry screen CLS Balance Breakdown Inquiry screen xviii

19 Tables 12 1 Definition of Field Names A 1 S.W.I.F.T. Message Types Supported... A 1 A 2 S.W.I.F.T. Message Types Generated by Contract Type... A xix

20 Tables xx

21 Section 1 Overview of Settlements Introduction The system supports a wide range of electronic that is S.W.I.F.T. messages, and also paper settlements. The majority of settlement messages are generated from underlying contracts. However, the system also provides the ability to raise non-contract based settlements. The release of settlement messages can be achieved either automatically or manually: Manual - The system provides functionality that enables you to manage settlement-related processing from deal entry through to the release of messages for transmission to S.W.I.F.T., or printing. The number of manual stages between deal entry and message production can be tailored to meet the needs of your institution. Automatic The system can manage all the steps from contract input to release of messages automatically. This is called Straight Through Processing (STP) and this document covers the settlement part of the STP process. STP settlements are described later in this section. As well as contract level settlement processing, the system also supports the following settlement methods: Continuous Linked Settlement (CLS) of FX trade and swap contracts. The system can act as a third party bank, sending and receiving messages from a CLS provider. Bilateral Settlement Netting, which provides a number of user benefits, such as reduction of settlement risk and reduction of settlement costs. Netting of Contracts is described in section 10 of this guide

22 Overview of Settlements Settlement Process Manual Process Flow User Enters Contract Details System Produces Diary of Events System Generates Settlement Messages User Authorises Messages for Sending or Printing System Sends or Prints Messages Figure 1 1. Outline of Settlements Process Flow Contract Entry Stage The system provides defaults for the standard settlement instructions. This means that data entry for outline deals can be minimised in the front office environment. Outline deals can then be reviewed in the back office and settlement data added or amended if necessary. Contract entry can also be controlled by Straight Through Processing functionality, making the inputting of contracts an even faster process. See 'Entering and Inquiring on Contracts' in the Core Functions and Inquiries Guide for further information on outline deals and their confirmation. Within the Settlements module you can: Enter details of the agents, who are the third parties responsible for paying or receiving funds on any contract. A client's details can include an intermediary bank through which the agent receives funds. Set up a default pay or receive agent for each combination of counterparty, currency and accounting centre. These defaults appear on the contract screens when a contract is being entered into the system

23 Overview of Settlements Enter details of the nostros that are utilised by your organisation Set up a default pay or receive nostro for each combination of product, settlement currency and accounting centre. You can also set up a default nostro for a combination of client, product, settlement currency and accounting centre. Enter details of the depots accounts used in the settlement of securities. Default depots can be defined if required. As soon as a contract has been entered, the system automatically generates a diary of the events (such as start, interest settlement and maturity) that are due during the life of the contract. These events are then used to trigger the automatic generation of settlement messages at the appropriate time. Contract Auditing/Authorisation When an outline deal has been confirmed and transmitted to the system as a verified contract, the contract is placed on two queues so that it can be confirmed by other staff: Contract management queue: This queue enables contract management staff to verify that the contract details are correct. Contract settlement queue: This queue enables settlements staff to review the contract before it is removed from the queue. In the case of a securities contract, the depot details must also be reviewed before the contract can be removed from the queue. Depending on the needs of your organisation, you can make use of either (or both) of the above queues mandatory using blueprint parameter BP-VIEW-UNAUTH (see Section 6, Individual Settlement Authorisation for details). If you make the use of a queue mandatory, then settlement messages cannot be viewed or released until the contract has been removed from this queue. If you do not make either the contract management queue or the contract settlement queue mandatory, then settlement messages can be viewed and released as soon as the contract has been entered successfully

24 Overview of Settlements Individual Settlement Messages Message Generation When a contract is entered, the contract's diary of events is accessed by the Settlement Message Creation (ONSETT) report that automatically generates settlement messages. Messages are generated in a format that is compliant with S.W.I.F.T. However, this does not mean that they must be sent via S.W.I.F.T. See the Guide to Interfaces with External Systems for more information on S.W.I.F.T. Messages can be: Printed on paper using the ONPAPER - Online Paper Confirmations/Payments report, see the On-Demand Reports Guide for details Sent via the S.W.I.F.T. Alliance interface, using the SWIFTCAS S.W.I.F.T. CASmf Interface report, documented in On-Demand Reports Guide. Whether a system can use the S.W.I.F.T. Alliance interface is set up on the S.W.I.F.T Parameters (SWPTR) screen. Loaded into a flat file that can be read by S.W.I.F.T. Alliance, or any other S.W.I.F.T. compliant system. This is done by the ONSEND - Settlement Message Creation report. Extracted from the Datafile, allowing you to create your own confirmations. Messages are initially generated on the following basis: When the contract is input, payment messages are generated for relevant diary events (see Appendix A, "S.W.I.F.T. Messages Generated by Contract Type") due on and before the contract input date. Payment messages are also generated for those events that occur a set number of days in advance. The number of days is defined for a currency using the 'Payment Days Advance' field of the Countries (CNTRY) screen, see the Guide to Setting Up for details. Confirmations are generated when the contract is input. After the initial message generation, messages will be generated using the following process: During the overnight processing, the relevant contract beginning-of-day reports, such as the MMBOD - Money Market Beginning-of-Day Update report, will identify the contract diary events (and cashflows) that are due within the number of days defined on the Countries (CNTRY) screen. The ONSETT - Settlement Message Creation report generates the settlement messages for the identified diary events

25 Overview of Settlements S.W.I.F.T. Message Security If your institution has multiple S.W.I.F.T. addresses, then you will normally only be able to view and change messages that are sent or received from the S.W.I.F.T. address designated to your accounting centre. You can set up the S.W.I.F.T. address for an accounting centre by using the Accounting Centres Maintenance (ACNTM) screen. You can also designate a user as a privileged user, allowing access to messages for all accounting centres, by using the Setting Up Operations (OPERS) screen. See the Guide to Setting Up for more details. Message Review and Repair Once settlement messages have been generated for a contract, they can be reviewed both in summary and detailed form. If a message is incorrect, then it can be repaired by editing the S.W.I.F.T. details. The repaired messages details overwrite the original message details and are saved, but the contract details are not updated. Therefore, if there is an error in the contract details that caused the repair to be required, the contract will need to be updated to prevent the error from recurring. The editing of messages in this way must be strictly controlled, therefore enhanced security features exist for use with this screen. For further details of these security features, see 'Message Update Protection' later in this section. When you have confirmed that a message is correct, you can authorise it either for: Printing: In this case, the message will be printed using the ONPAPER - Online Paper Confirmations/Payments report, see the On-Demand Reports Guide for details Sending to an online device or loading into a flat file: In this case, the message will be processed by the ONSEND - Settlement Message Extraction report, see the On-Demand Reports Guide for details Sending via the S.W.I.F.T. Alliance interface. The messages will be processed and sent using the SWIFTCAS - S.W.I.F.T. CASmf Interface report, see the On-Demand Reports Guide for details Status of S.W.I.F.T. Messages When you send a S.W.I.F.T. message using the S.W.I.F.T. Alliance CASmf interface, the system expects to receive a message from S.W.I.F.T. acknowledging its receipt and format. Therefore, until the acknowledgement is received from S.W.I.F.T. Alliance, the message status changes to 'Sent but Unacknowledged'. If an acknowledgement is received by the system then the message status is changed to 'Acknowledged'. If S.W.I.F.T. Alliance rejects the message, it will be returned to the settlement queue as 'Unsent', showing that it has been rejected, the details of the rejection and the number of times it has been rejected previously. You can then repair this message using the Settlement Message Review and Repair (MESSR) screen, and resend the message using the S.W.I.F.T. Alliance CASmf interface

26 Overview of Settlements Manual Message Production For those users who are skilled in S.W.I.F.T. messages and their formats, a facility is supplied to enable messages to be entered manually. To do this you must enter the S.W.I.F.T. tag code and message detail for each line of the message. The message will not be validated, its content and validity is the responsibility of the user. For further details see the Settlement Message Add (MESSA) screen in Section 6 of this guide. The entry of messages in this way must be strictly controlled, therefore enhanced security features exist for use with this screen. For further details of these security features, see 'Message Update Protection' later in this section. Message Update Protection To assist in the control of message repair and addition, you can allow: Any users, that can access the repair facilities, to update specific parts of existing messages Specify the users that can repair specific parts of existing messages Specific users to add and/or repair complete messages For details of how to set up message update protection, see the description of the Security for S.W.I.F.T. Tag Codes (STAGA) screen in Section

27 Overview of Settlements S.W.I.F.T. BIC Codes The system uses the standard Bank Identification Codes (BIC codes) to help identify the clients and institutions that S.W.I.F.T. messages are being sent to, and received from. The BIC codes are used on screens such as Settlement Message Review and Repair (MESSR) when constructing a S.W.I.F.T. message. The system contains a directory of BIC codes, loaded in from a file supplied by S.W.I.F.T. There is a facility in the system that allows you to search through the BIC directory after it has been loaded into the system. This is only available on the Graphical User Interface (GUI), and can be opened by selecting View BIC Details from the Common Menu on the Menu Bar, or by pressing the F7 key. This will display the BIC Directory window. Using the BIC Directory window, you can search either by BIC Code or Nickname. The default search is by BIC Code. To search by agent Nickname, click on BIC Code to display the hidden drop down list. Select Nickname from the drop down list. Having selected either BIC Code or Nickname, enter all or part of a BIC code or Nickname in the search field. The system will display the BIC codes or nicknames matching what you have entered. You can then click on the desired entry to obtain more details about the institution related to it. The search can be restricted further by country, or by searching for preferred agents only. For more information on agent data, including nicknames, see Agent Details (AGNTM) in section 2. The system can distinguish between banks and other institutions through the use of a Business Entity Identifier (BEI) indicator. If the BEI indicator is activated, then this identifies the client or agent as being a non-bank. An agent is identified as being a non-bank by setting the BEI-Type field to Yes on the Agent Details (AGNTM) screen. The following figure is an example of the BIC Directory window that allows you to inquire on BIC codes

28 Overview of Settlements Figure 1-2. BIC Directory Inquiry window To load in a new file containing BIC addresses, you should run the report LOADBIC - Load S.W.I.F.T. BIC File. This is described in more detail in the On-Demand Reports Guide

29 Overview of Settlements Messages to TARGET and CHAPS Electronic messages are normally sent from Urbis using the S.W.I.F.T. messaging system. Two other interfaces are available for specific messages. These are: TARGET. This can be used for making payments in euros. CHAPS. This can be used in the United Kingdom for settlement of wholesale transactions. When sending messages to either of the above messaging systems, the S.W.I.F.T. interface must be operational. See "Interface to S.W.I.F.T., TARGET, and CHAPS" in the Guide to Interfaces with External Systems for more information. TARGET TARGET messages are distinguished from S.W.I.F.T. messages by the addition of an //RT codeword in the message. This denotes that it is to be routed using the TARGET messaging system. Apart from this codeword, the TARGET message will be the same as the equivalent S.W.I.F.T. message. TARGET can be used for sending the following types of messages: Payment messages related to clean payments and standing orders. Contract settlement messages. For payment messages related to clean payments and standing orders, the //RT codeword (indicating that this is a TARGET message) is at the user s discretion, although the system will ensure that the //RT codeword is used appropriately and not duplicated within a single message. For contract settlement messages, the system will place the //RT codeword into the relevant messages to be sent to TARGET. Whether a message is to be sent using TARGET or S.W.I.F.T. is decided at contract level. If the following criteria are met, then the message will be sent using TARGET instead of S.W.I.F.T. The "Target Indicator" field on the Non-Standard Settlement Instructions (NSTDM) screen must be switched "On". The settlement currency of the contract is euro. If both of the above criteria are met, then the system will place //RT on the first line of Field 57 Account With Institution, on the MT103 or MT

30 Overview of Settlements CHAPS The CHAPS messaging system can use different routing codes to the S.W.I.F.T. messaging system. A settlement message will be sent using CHAPS instead of S.W.I.F.T. if the following criteria are met: The blueprint parameter BP-NEWCHAPS is set to "Y" (see the Guide to Setting Up for more information) The nostro to be used for settlement has a CHAPS BIC Routing Code defined for it. This routing code contains the destination address for the message. This is entered on the Nostro Details (NSTRO) screen The settlement currency is GBP. Sort Codes can be defined for the relevant agents/intermediaries, and counterparties. This Sort Code can then be used instead of the BIC code in routing a CHAPS message. This field is entered on the Agent Details (AGNTM) and Non-Standard Settlement Instructions (NSTDM) screens

31 Overview of Settlements IBAN Numbers The International Banking Account Number (IBAN) is used by banks to uniquely identify account numbers in an international environment. The constituents of the IBAN account number will vary from country to country as required. The system can recognise incoming IBAN numbers, and construct IBAN numbers for internal accounts. A typical example of an IBAN could be: Country Code where the account is held. The first 4 numbers of the account holder's S.W.I.F.T. address. The sort code of the account holder The account number of the account at the institution where it is held. The outline of an IBAN number is defined on the Accounting Centres Maintenance (ACNTM) screen (described in the Guide to Setting Up). The number can consist of 4 parts of differing size and content. The first 4 numbers must always be the country code, and the last numbers must always be the account number. To ensure that IBAN numbers generated by the system are unique, account numbers must also be unique. If two account numbers are the same, but have different currencies, then the IBAN number for these accounts will be the same

32 Overview of Settlements Credit and Debit Advices If a client requires your institution to provide notice whenever a posting is made to their account, this can be done through S.W.I.F.T., either as an MT900 or an MT910 message, depending on whether the posting is a credit or a debit. To enable the sending of MT900/MT910 messages for postings, you must set the Credit Advices and Debit Advices indicators on the Client Account Static Details (CAHDR) screen. See the Clients and Accounts Administration Guide for more information on this screen. Accounting Authorisation The Accounting Authorisation Queue (ACQUE) lists pay and receive events by value date for contracts using accounting models that are set to manual authorisation only. This screen enables you to record the actual amount paid or received on a diary event date. The system uses accounting models to determine the amounts to post on each diary event date for each type of contract (see Setting Up Accounting Models in the Guide to Setting Up for details). For events to be authorised using these facilities, a record must have been set up on the Accounting and Exposure Amount Parameters (ACEXM) screen for the relevant event/contract type combination. The amount posted on a particular diary event date may be composed of several elements. For example, a Rollover event (RL), could be composed of interest and a principal repayment. These elements must have been set up for each combination of RL diary type and contract type using the Accounting and Exposure Amount Parameters (ACEXM) screen (see the Guide to Setting Up for more information). The following figure shows how the total amount settled at an RL event could be sub-divided. Money Market Loan - RL event Principal Repayment Interest Interest Adjustment Penalty Figure 1 3. Example of Amount Parameters

33 Overview of Settlements After set up has been completed, you can use the Accounting Authorisation (ACATM) screen to allocate portions of an amount paid or received against the elements that comprise it. You access the Accounting Authorisation (ACATM) screen via a link from the Accounting Authorisation Queue (ACQUE). The figure below shows an example of how this may work in practice for an amount received at an RL event on a Money Market Loan: Amount Due: Amount Received: 507,500 GBP 500,000 GBP Amount allocated as follows: 500,000 GBP Principal Repayment Interest Interest Adjustment Penalty 491,750 7, Total = 500,000 Figure 1 4. Example of Allocation of Amounts Notes: No postings can be made for an event that uses an accounting model that is set to manual authorisation until it is confirmed on the Accounting Authorisation (ACATM) screen. The contract details and diary are not updated by changes made on the Accounting Authorisation (ACATM) screen. The settlement messages are not affected either. However, if you update the diary using the relevant schedule change screen, such as the Money Market Loan/Deposit Schedule Change (MMLSC) screen, then the settlement messages are reversed and re-issued. The accounting is also reversed and re-applied and the interest is re-calculated

34 Overview of Settlements Interest Bearing and Discounted Paper Securities Introduction to Paper Settlement The paper settlement queue facilities help you to manage the delivery and receipt of the physical paper associated with interest bearing and discounted paper securities. The physical paper is held in an account at a depository (Depot). When entering a contract, the name of the depot and the account number of the depot are identified for both your institution, and the counterparty. This information is controlled by the 'Depots' functionality. Managing Paper Settlement Depots All deals that require paper settlement appear on the Paper Settlement Authorisation Queue (PSQUE) on the Value Date of the settlement event. A link is offered from the Paper Settlement Authorisation Queue (PSQUE) to the Paper Settlements Confirmation (SPSTI) screen. You can use this screen to record details of delivery, for example the actual delivery date may differ from the expected date. Depositories (depots) are used for the physical storage and clearing of securities. Depots hold a physical security in a custody location, defined internally in the system by three parameters: Depot the depository where the security is held Account the account at the depot where the security is held Sub-Account if the depot uses sub-accounts, then this is the sub-account where the security is held. A typical contract will change the custody location of a security, requiring the depositories for both parties of the contract to be informed. Even if the same depository is used, the account and (and sub-account if used) will change. The depots functionality provides for the settlement of the physical security. Two inquiry screens can be used to view the total holdings of a security in a depot, and the individual transactions that have contributed to a holding

35 Overview of Settlements Setting Up Depots Before depots can be used, the following information must be defined: Depots used by your institution must be defined on the Depository Maintenance (CSDM) screen The combinations of depot/account/sub-account that are to be used by your institution and by your clients must be defined on the Depot and Account Definition (DEPAM) screen Default values for the combinations defined above can be set-up for automatic entry on Contract add and Deal add screens. These are defined on the Depot Defaults (SPSTM) screen. The following inquiry screens are provided to view the above set-up data: Depot and Account Definition Inquiry (DEPAI) Depot Defaults Inquiry (SPSTI) Using Depots When entering a securities contract, two fields define the depot details for a trade. These are Their Depot and Our Depot. Their Depot defines the depot/account/sub-account combination for the client, while Our Depot defines this information for your institution. These fields are defaulted from information defined on the Depot Defaults (SPSTM) screen. The blueprint parameter BP-MI-TCSD-UNDEF allows your institution to force an entry into the "Their Depot" field. The entry made for this blueprint will be entered in the field, and the field will become mandatory. For example, the blueprint can be used to change the value to force a non-depot entry (for example 'IGNORE'). If the blueprint is left blank, then any value can be entered in the field, or the field can be left blank. Inquiring on Holdings The following two screens allow you to view the current security holdings that comprise a portfolio, or the current holdings at a particular depot. The transactions that have affected the holding can also be viewed. Depot Holdings Inquiry (DEPSI) Depot Holdings Transaction Inquiry (DEPCI) The MIDEPOT Securities Depot Holdings report provides a list of the current holdings in a portfolio or a depot. If the portfolio is the parent portfolio of a group, then the report combines holdings in all child portfolios

36 Overview of Settlements Overview of Clean Payments Clean Payments refer to a payment or a series of payments made by a bank on behalf of a client (normally the customer of a bank) to a third party (the beneficiary). The payment may be effected through an intermediate bank (the beneficiary s bank). In many cases the client and the third party are the same. These payments are not related to any underlying contract or transaction; they are, generally, one-off payments involving the transfer of funds. The system supports different Value Dates and Currencies for the credit and debit side. The system supports the following types of clean payments: Clean payments from an account in the system to an individual, a company or a financial institution outside of the system (using the serial (MT103) or cover (MT103 and MT202) methods). Clean payments from one account in the system to another account in the system The debit and credit side of a clean payment can be a single currency, or mixed currencies, using a contract entry process. This includes the ability to set up product default values, for the standardisation of your clean payments. The system is able to produce the following S.W.I.F.T. messages as relevant to an individual clean payment: MT100, MT103, MT202, and MT210. The system will either use MT100, or MT103 messages. An MT103 will always be produced if the credit nostro has a S.W.I.F.T. Bank Operation Code unless the MT100 Override field is used on the Nostro Details (NSTRO) screen. The production of MT103 messages is defined on the System Parameters (SPMTR) screen, described in the Guide to Setting Up. Inward Clean Payments Inward clean payments refer to payment instructions received in the form of S.W.I.F.T. messages from outside institutions. The system supports the following types of inward clean payment: Inward clean payments coming in from S.W.I.F.T. to an account within the system Inward clean payments coming in from S.W.I.F.T. where your institution is acting as an intermediary When an inward clean payment is received from S.W.I.F.T., it is placed on the Inward Clean Payments queue. The S.W.I.F.T. message will be an MT100, MT101, MT103, or MT202 message. All inward clean payments received by the system are displayed on the Incoming Clean Payments Inquiry (CPINI) screen, and the message details can be viewed on the Output from Message Inquiry (MSGI) screen. You can either enter an inward clean payment into the system in the same way you would enter a clean payment initiated by your institution, or by matching the details to a previously entered clean payment. See Clean Payments Addition (CPAYA) later in Section 8 of this guide for a description of the matching process

37 Overview of Settlements Automatic Authorisation of Clean Payments When entering a clean payment into the system, if the following factors are true, then the payment will be automatically authorised: Funds are available to cover the clean payment All relevant information on the clean payment has been completed The payment is less than the authorisation limit defined by the blueprint parameters BP-CP- AUTH-LIMIT and BP-CP-AUTH-CCY

38 Overview of Settlements Clean Payments Screen Flow For clean payments of the following types, the screen flow shown below applies. Clean payments from one account in the system to another account Clean payments from an account in the system to an individual, a company or a financial institution outside of the system The following figure shows the flow of screens necessary to enter a clean payment. Enter clean payment product default values Clean Payments Default Maintenance (CPDFM) Clean Payments Addition (CPAYA) Enter clean payment details If posting to an external account, enter S.W.I.F.T. message fields MT103/MT202 Additional Detail Screens Amount below authorisation limit and funds available, the system authorises payment Automatic Authorisation Clean Payments Authorisation (CPAUT) Amount above authorisation limit or funds unavailable, choose payment to authorise Payment Made, Message placed on Settlement Queue Payment Made, Message Placed on Settlement Queue Figure 1-5. Screen Flow for Processing Clean Payments If a clean payment has not been completed, or funds are not available, then it cannot be authorised. In these cases, the payment can be amended or deleted. Once authorised, the payment must be effected using the Authorise Release of Event Messages (SETTA) screen. The authorisation limit, used by the system to decide which payments need authorisation, is defined for each product related to clean payments. If an individual clean payment's related product does not have its own limit, then the authorisation limit is defined by the blueprint parameters BP-CP-AUTH-LIMIT and BP-CP-AUTH-CCY (where BP-CP-AUTH-CCY is the currency of the limit amount). See the Guide to Setting Up for details about these blueprints

39 Overview of Settlements Inward Payment Screen Flow For inward clean payments of the following types, the screen flow shown below applies. Inward clean payments coming from S.W.I.F.T. to an account within the system Inward clean payments coming from S.W.I.F.T. where your institution is acting as an intermediary The following figure shows the screens necessary when entering an inward clean payment. View All Messages Incoming to the System Outbound S.W.I.F.T. Message Inquiry (MSGSI) Alert Queue (ALRTQ) View Reasons for Rejected Message Select incoming payment Incoming Clean Payments Inquiry (CPINI) Output from Message Inquiry (MSGI) View incoming S.W.I.F.T. message Enter clean payment product default values Clean Payments Default Maintenance (CPDFM) Clean Payments Addition (CPAYA) Enter clean payment details Enter S.W.I.F.T. message fields (some defaulted from clean payment details) MT103/MT202 Additional Detail Screens Amount below authorisation limit and funds available, system authorises payment Automatic Authorisation Clean Payments Authorisation (CPAUT) Amount above authorisation limit, or funds unavailable, choose payment to authorise Payment Made, Message placed on Settlement Queue Payment Made, Message Placed on Settlement Queue Figure 1-6. Screen Flow for Processing Clean Payments If a clean payment has not been completed, or funds are not available, then it cannot be authorised. In these cases, the payment can be amended or deleted. It is also possible to enter an inward clean payment using the matching process. A clean payment is entered into the system before the inward clean payment is received. When the inward clean

40 Overview of Settlements payment is received, it can be matched to the details on the clean payment. See Clean Payments Addition (CPAYA) in Section 8 of this guide for more information on the matching process. The authorisation limit, used by the system to decide which payments need authorisation, is defined for each product related to clean payments. If an individual clean payment's related product does not have its own limit, then the authorisation limit is defined by the blueprint parameters BP-CP-AUTH-LIMIT and BP-CP-AUTH-CCY (where BP-CP-AUTH-CCY is the currency of the limit amount). See the Guide to Setting Up for details about these blueprints. When a S.W.I.F.T. message is received by the system, but does not pass the system's validation (either by being incomplete or in error), then the message will be rejected. A user can view all the messages that have been rejected, and either accept the message, or close the message. A list of all messages received by the system can be viewed on the Outbound S.W.I.F.T. Message Inquiry (MSGSI) screen. If a message is rejected, the reasons for the rejection can be viewed on the Alert Queue (ALRTQ) screen (described in the Stock Exchange and Securities Administration Guide)

41 Overview of Settlements Clean Payment and Client Account Management Services Client Account Management Services (CMS) are a set of optional functions in the system that allows greater control of client accounts. One of these functions is Negative Balance Checking, and any clean payment due to be debited to an account marked as requiring a negative balance check is affected. For full details of CMS, see the Clients and Accounts Administration Guide. After a debit payment to an account that requires a negative balance check has been authorised, it is moved onto a Pending Queue, acquiring the status of 'Pending'. Once on the queue, the payment can be released in the following ways: The system can release a payment when sufficient funds are available on the account. The sleeping report RELPENDQ - Release from Pending Queue handles this automatically (this report is described in the On-Demand Reports Guide). You can force the release of a payment, regardless of sufficient funds being available. This is done from the Management Services Queue (BANQI) screen, described in the Clients and Accounts Administration Guide. Once the payment has been released from the pending queue, it is processed in the same way as other clean payments, using the CPAYMENTS - Clean Payments Processing report. The above functionality can be activated using the blueprint parameter BP-NBC, described in Blueprint Parameters in the Guide to Setting Up. An account is defined as requiring a negative balance check on the Management Services Extra Details (CAEXM) screen, described in the Clients and Accounts Administration Guide. Overview of Nostro Transfers You can effect nostro transfers, which enable funds to be transferred between two nostro accounts at different correspondent banks, providing both nostros are for the same currency and are S.W.I.F.T. members in the same country. Nostro Transfer contracts produce appropriate S.W.I.F.T. messages: MT200 or MT202, to instruct the pay nostro to transfer the funds MT210, to advise the receiving nostro that the funds have been transferred Nostro transfers can be settled via STP (straight through processing)

42 Overview of Settlements Straight Through Processing of Settlements Straight through processing (STP) can be performed on outbound settlements, this includes payments, receipts and confirmations (including reversals). The system also has functionality supporting the Straight Through Processing of Contracts, described in the Core Functions and Inquiries Guide. Note: Settlements which are the replacements of previous messages cannot be resent via STP. STP Processing Flow STP allows settlement to be performed with little or no user input. The following flow chart represents the settlement procedure. Where before the user had to authorise the settlement for processing, now the system authorises it via a strict set of validation checks. User Enters Contract Details System Produces Diary of Events System Generates Settlement Messages System Applies STP Validation STP Accepted STP Rejected System Sends or Prints Messages Settlement Remains on Settlement Queue - Authorise Manually Figure 1-7. STP Process Flow

43 Overview of Settlements STP Settlement Authorisation Once the system has generated a settlement message, it must first pass through validation to ensure it is suitable to be processed automatically. Validation of a settlement message is carried out at various levels, and covers various parameters in the system. For STP settlements to proceed, all of these levels and parameters must be set to allow the settlements through. If even one of these is set to 'No' then the STP settlement will be rejected. The levels that need to be set to allow STP are: System level, set on the System Parameters (SPMTR) screen. Location level, set on the Location Maintenance (LOCTM) screen. Accounting Centre level, set on the Accounting Centres Maintenance (ACNTM) screen. Client level, set on the Client Details - Banking (CIWSL) screen. Media Type, set on the Network Parameters (NWPTR) screen. Broker level, set up on the Brokers Maintenance (BRKRM) screen. Dealer level, set up on the Dealers and Officers (DEALR) screen. STP Indicators must also be set for the following parameters to allow STP settlements. These are controlled by a blueprint parameter, which defaults all of these to allow or disallow STP. Individual indicators can then be altered from this default value on the STP Parameters Maintenance (STPPM) screen. For example, the default could be set to allow STP for all currencies, but a certain currency could be excluded, thereby preventing STP. This process is described fully in "Accounting Centre and Location Maintenance", in the Guide to Setting Up. Product level Access Group level Client Type level Currency Message Type As well as these, if the contract is entered today, one of the following must also be true: either - The value date of the message minus the relevant Country Payment Days parameter must be equal to today. This parameter is set on the Countries (CNTRY) screen, or defaulted to the System Parameters (SPMTR) screen. or - If the value date of the message minus the relevant Country Payment Days parameter is less than today, the value date must be greater than today. This parameter is set on the Countries (CNTRY) screen, or defaulted to the System Parameters (SPMTR) screen. For an existing contract the value date of the payment message must be greater than or equal to today

44 Overview of Settlements The above screens are described in the following guides: The System Parameters (SPMTR), Location Maintenance (LOCTM), Accounting Centres Maintenance (ACNTM), STP Parameters Maintenance (STPPM) and Countries (CNTRY) screens can be found in the Guide to Setting Up. The Brokers Maintenance (BRKRM) and Dealers and Officers (DEALR) screens can be found in the Core Functions and Inquiries Guide. The Client Details Banking (CIWSL) screen can be found in the Clients and Accounts Administration Guide. The Network Parameters (NWPTR) screen can be found in the Guide to Interfaces to External Systems. Accepted STP Settlements Once an STP settlement has been successfully validated, the settlement procedure occurs automatically, sending a message via S.W.I.F.T., or printing a paper message as necessary. Payments Automatic generation of a payment is carried out at the necessary time using the details set on the contract (usually using the defaults set on the Nostro Settlement Defaults (NSDFM) or Agent Settlement Defaults (AGDFM) screens). Any settlement that contains non-standard settlement instructions can be found by using the NONSTDINS - Non Standard Settlement Instructions report, described in On-Demand Reports Guide. On the Accounting Centres Maintenance (ACNTM) screen, the Outbound STP for Non-standard Settlement Instructions indicator provides the option to allow payments with non-standard settlements to be automatically released, see the Guide to Setting Up. This may be of use where messages are being reviewed via S.W.I.F.T. Alliance prior to be being sent to the S.W.I.F.T network. Settlement Messages Settlement messages are created by the ONSETT - Settlement Message Creation report. Each time this report is used, it will perform STP validation, even if the contract had passed STP validation previously. If a settlement message is validated successfully, it will be processed by the relevant report (either S.W.I.F.T. Message Extraction (ONSEND), On-Line Paper Confirmations/Payments (ONPAPER) or S.W.I.F.T. CASmf Interface (SWIFTCAS) reports) for conversion into the correct format prior to sending

45 Overview of Settlements Rejected STP Settlements Settlements that have been rejected by the system validation process are returned to the settlement queue and remain unprocessed. You can view all the failed STP events by using the STPFAIL - STP Failure Analysis report, see On-Demand Reports Guide. This report will tell you: The Settlement that failed. The Accounting Centre of the failed Settlement Why the STP failed. With this information, you can process the settlement manually using the manual processing steps described in this guide. A settlement that fails STP cannot be re-submitted for STP. However, it is possible to change the STP levels using the STPFAIL - STP Failure Analysis report to allow an identical settlement message processed at a later date to be automatically released

46 Overview of Settlements Netting Netting is the process by which institutions and their clients mutually agree to replace the need to settle payments on an individual basis, for the same currency and value date, with a single combined settlement. Consequently settlement risk is reduced, with the added benefit of lower transaction costs due to the lower volume of settlements made. The compilation of the netting agreements within the system is completely flexible (exceptions to this are clean payments, nostro transfers, securities, and OTC options) and will allow most payments to be included in a netting agreement, with the client agreement being established at either an Accounting Centre or Location level, as controlled by the Allow Nettings field on the System Parameters (SPMTR) screen, see the Guide to Setting Up. The settlement process itself also provides flexibility for the user to confirm or remove individual payments prior to the generation of the netted settlement

47 Overview of Settlements Establishing Netting The system supports Comprehensive Bilateral Settlement Netting, with the flexibility to allow netting types to be defined using most products (exceptions to this are clean payments, nostro transfers, securities, and OTC options). The following diagram shows the sequence in which the netting screens are to be used in establishing netting types, and subsequent client agreements. The screens below not documented in this guide can be found in the Guide to Setting Up. System Parameters (SPMTR) Can the netting functionality be used in this system? Location Maintenance (LOCTM) Can the netting functionality be used for this location? Is this product type nettable? Product Type Maintenance (PRTPM) Accounting Centre Maintenance (ACNTM) Can the netting functionality be used for this accounting centre? Link nettable product types to a netting type Netting Type to Product Linkage (NTTPM) Netting Type to Accounting Centre Linkage (NTBRM) Can the accounting centre or location use this netting type? Characteristics of the Netting Type Netting Type Maintenance (NTTYM) Client Netting Agreements (NTAGM) Establish Client Netting Agreement Client Netting Agreement - Currency Cut Off Days (NTACM) Client / currency cut-off rules. Client Netting Agreement - Product (NTAPM) Maintain included products for client Figure 1-8. Establishing Netting Agreements

48 Overview of Settlements STP and Netting Settlements that are suitable for processing using either STP or netting will first go to the netting settlements queue (see the Netted Settlements - Lead In (NETCN) screen). From here you can choose which settlements to include in an individual netting agreement. Any settlements not included in the agreement are processed as normal, using STP or manual authorisation as appropriate. See the Netted Settlements - Authorise (NETTA) screen for information on how to include an individual payment in an individual netting agreement

49 Overview of Settlements Continuous Linked Settlement Continuous Linked Settlement (CLS) is a global clearing house operating on a Payment Versus Payment (PVP) basis for the settlement of Foreign Exchange trades (FX Market and FX Swaps), but limited to seven major currencies. All trades that have been successfully matched (that is, both trading parties have sent confirmations that agree) contribute to the creation of balances for each currency, which are settled within a settlement window on the maturity date of the contracts. A number of banks have become members of CLS and these banks provide a CLS service to nonmember banks, which are known as Third Party Banks. Urbis provides the functionality to support CLS processing for the Third Party Banks. For information on the screens used for CLS within Urbis, see Section 11, Continuous Linked Settlement Screens. The CLS process works as follows: 1. The FX trade is executed and both parties send an MT300 FX Confirmation to CLS. 2. CLS will perform a matching process to ensure that all relevant details agree. If contract details agree then the contract is given a status of Matched and is therefore included for settlement within the system. 3. Contracts that are not matched are shown as Alleged trades, with the counterparties either deleting the trades or sending an amended confirmation to rectify the reason for mis-match, for example wrong maturity date. Unmatched deals at cut-off time are to be settled individually. 4. At settlement, statements are generated for the settlement obligations for each CLS member, who will check these totals and effect the necessary payments to settle any money owed. Settlement is made through the relevant nostro, either using the listed nostro for the currency, or by entering a separate nostro on the Nostro Transfer Add (NSXFA) screen. Setting Up Continuous Linked Settlement The following information must be set up before CLS can be used in the system: CLS Data Define the CLS Providers. These are the member banks that are providing CLS access for your institution and clients. There can be a different provider defined for each accounting centre or location. This is done on the CLS Provider Detail Maintenance (CLSDM) screen. Define the Counterparties that can use CLS. These can be internal or external clients, but they must have been entered into the system as clients. Enter the CLS clients on the CLS Counterparty Maintenance (CLSCM) screen. Clients are set-up on the Client Details Banking (CIWSL) screen (described in the Clients and Accounts Administration Guide). Define the Currencies that can be used by CLS. This is done on the CLS Currency Maintenance (CLSCY) screen. Currencies are set-up on the Currencies Maintenance (CCYS) screen (described in the Guide to Setting Up). Accounting Models for FX products that can utilise CLS and Nostros that are used to settle CLS. For existing products to use CLS, new accounting models must be added. This is described in "Setting Up Accounting Models" in the Guide to Setting Up

50 Overview of Settlements System Settings Define the system parameters for CLS. These include the S.W.I.F.T. address of the CLS provider, the level at which CLS is applied (either accounting centre or location), and the Product. This is done on the System Parameters (SPMTR) screen (described in the Guide to Setting Up). Define the default CLS settlement instructions. When an FX contract is defined as a CLS contract, the settlement instructions contained in the product of the FX contract will be replaced by the set of default settlement instructions for CLS. These default instructions are contained within a special product defined for CLS. The product created for CLS is entered on the System Parameters (SPMTR) screen (described in the Guide to Setting Up). Using Continuous Linked Settlement A contract can be defined as suitable for CLS either manually or automatically. Either method will use the following criteria to determine whether the contract is suitable: The client must be a CLS member or user Both currencies in the contract must be eligible for CLS The contract must not mature on the day of input. The contract must not have a back-dated maturity date. The contract must be entered into the system before the Local Cut-Off time defined on the CLS Provider Detail Maintenance (CLSDM) screen. For FX swaps contracts, each leg is treated as a separate contract when assigning CLS. One leg can pass the criteria for CLS, and be accepted for CLS, while the other leg does not meet the CLS criteria and is not accepted for CLS. A single confirmation is sent for each leg. Manual Definition of CLS Contracts: The CLS Deal field is used to define a contract as CLS. This field is found on the relevant contract entry screen (for FX Swap deals, there is a CLS Deal field for each leg). Set this field to "Yes" to define the contract as suitable for CLS. The CLSCHANGE CLS Update Report must be run to confirm the contract as being suitable for CLS. If this field is entered as "No", then the contract will be excluded from CLS processing, and this decision cannot be changed. This report is described in the On-Demand Management Reports Guide. Automatic Definition of CLS Contracts: The CLS Deal field is used to define a contract as CLS. This field is found on the relevant contract entry screen (for FX Swap deals, there is a CLS Deal field for each leg). If the CLS Deal field is left blank when the contract is entered, then the CLSCHANGE CLS Update Report will decide whether the contract is suitable for CLS. Each contract that passes the criteria listed above for CLS deals has the CLS Deal field set to "Yes" (unless the contract has been manually excluded from CLS processing). When a contract is defined as suitable for CLS, an MT300 S.W.I.F.T. message will be produced and sent to the CLS provider. All other S.W.I.F.T. messages will be suppressed. If the contract is manually excluded from CLS, then the MT300 will be cancelled, and the suppressed S.W.I.F.T. messages will be sent

51 Overview of Settlements Euro Related Information Economic and Monetary Union (EMU) is a process by which certain countries in the European Union are converting their national currencies (also called in currencies) into a single European currency called the Euro. The system supports this conversion process fully for all currencies and all phases of the conversion (see "Euro Related Information" in the Core Functions and Inquiries Guide for more information)

52 Overview of Settlements

53 Section 2 Static Data Introduction This section provides a description of following screens for managing settlements static data: Agent Details (AGNTM) and Agent Inquiry (AGNTI) Agent Settlement Defaults (AGDFM) Agent Default Inquiry (AGDFI) Non Standard Settlement Instructions (NSTDM) Nostro Details (NSTRO) Nostro Settlement Defaults (NSDFM) Nostro Default Inquiry (NSDFI) Client Settlement Instructions for LA (CISIM) LA Client Settlement Instructions Authorisation Queue (CDATI) Payment Instruction Narratives (PCNRM) SWIFT Tag Code Update Level Maintenance (STAGA) For each screen the following is provided: A description of its use An example of the screen A full description of the fields on the screens, and valid entries, is given in Section 12, Definition of Field Names. Please refer to the Starter s Guide for a description of how to access and use screens

54 Static Data Agent Details (AGNTM) Details of agents, who are third parties responsible for receiving or paying funds on any contract, are held on the Agents table. On this table you define the following for each agent: The nickname and full name of the agent The address of the agent The agent's country of residence The agent's addresses for communication systems - S.W.I.F.T. - CHAPS (if the CHAPS interface is being used, this is the sort code of the agent) - CHIPS (documentary purposes only) - FEDWIRE (documentary purposes only) - TELEX (documentary purposes only) If the agent always receives funds via an intermediary bank, either the S.W.I.F.T. BIC code, the CHAPS sort code or the postal address of that intermediary. Whether an Authenticator Key is held to allow postings to be made for the agent Whether your institution has a Nostro account at the agent's institution Note: Once installation is complete, you can only delete an agent from the system by running the NSTAGNTDEL - Delete Nostros and Agents report (see the On-Demand Reports Guide for details). The following fields in this table are used by the S.W.I.F.T. interface: S.W.I.F.T. Address The S.W.I.F.T. address of the agent bank. Note that, if you do not enter a valid S.W.I.F.T. address, the S.W.I.F.T. message will not be sent. This will be reported at transmission time. BEI S.W.I.F.T. Address If the agent is not a bank, then this field should be switched 'On'. Full Name The full name of the agent. City The mnemonic of the city of residence of the agent. City mnemonics are defined in the General Purpose Narratives table (GNARR), type CI. Country of Residence The mnemonic of the country of residence of the agent. Country mnemonics are defined on the Countries (CNTRY) screen. Account Number at Central Bank The number of your account at the Central Bank. This field is used in S.W.I.F.T. messages if blueprint parameter BP-SWIFT is set to 'Y'

55 Static Data BIC Code or Address The S.W.I.F.T. BIC Code or the address of a bank that is acting as intermediary between yourselves and the agent bank Note: If agent settlement defaults are set up for a counterparty using the Agent Settlement Defaults (AGDFM) screen, then details of any intermediary are taken from that screen. The Sort Code fields are used by the CHAPS messaging system to route settlement messages for agents and intermediaries. The following figure shows an example of the Agent Details screen

56 Static Data Figure 2 1. Agent Details screen

57 Static Data Agent Inquiry (AGNTI) This inquiry shows a summary of agents. The inquiry lists agents alphabetically by nickname. Enter Start Nickname to begin the listing at another point in the records. If you enter an incomplete Start Nickname, details of all agents are displayed alphabetically from that nickname. For example, if you enter M in the Start Nickname field, agents are listed alphabetically from M. If you do not enter a Start Nickname, details of all agents are displayed alphabetically from A. An example of this inquiry screen is given in the following figure: Figure 2 2. Agent Inquiry screen

58 Static Data Agent Settlement Defaults (AGDFM) This screen allows you to enter details of standard settlement defaults for a pay or receive agent. The defaults appear on the contract screens at deal input, once the counterparty and currency are known. The defaults do not apply to the delivery of securities. You can set up a default pay or receive agent for each combination of counterparty, currency and accounting centre. Default nostros are set up using the Nostro Settlement Defaults (NSDFM) screen. If funds are to be transferred to the counterparty's agent via an intermediary, then details of the intermediary must be entered on this screen. To apply the default to all accounting centres, enter eight asterisks (********) in the Accounting Centre field. If a location is entered, a record is created for each accounting centre within the location. Switching Apply to All Contracts on means that all diary events for contracts with a value date equal to or greater than the entered start date will be amended to use these defaults. Switching this field off denotes that only contracts input on or after the start date may use these defaults. The Start Date field may be used to enter future dated changes to the default. Standard settlement instructions can be set up for a defined period of time by entering an end date. The New End Date field can be used to change the time period. The new end date must be earlier than the existing end date. When you add a set of standard settlement defaults, the record is given a status of Awaiting Authorisation. When it is in this status it is not active. To activate the record it must be authorised. This is achieved by displaying the record on the screen and, clicking on Authorise. If you need to change an authorised record, you must have authority to perform both change and authorise functions on this screen. Once you have performed the change you will not need to use the Authorise function. There is one exception, if you need to change the end date of a record, the change and authorise functions must be performed separately. The existing record will remain effective until the new record is authorised. The Preferred Account at Agent and Preferred IBAN fields defines the counterparty's account at the agent in normal format, and in IBAN format. Only one of these fields needs to be entered. If a BIC address or free format address is entered, then the Country of Residence field must also be completed. At present, this field is used for documentation purposes only. The Sort Code field is used by the CHAPS messaging system to route settlement messages for agents and intermediaries. Details of the standard settlement instructions for a client/accounting centre combination are given on the Agent Default Inquiry (AGDFI) screen. A complete listing of default agents is included in the STDFMLST - Standard Settlement Defaults List report (see the On-Demand Reports Guide for details)

59 Static Data The following figure shows an example of the Agent Settlement Defaults screen: Figure 2 3. Agent Settlement Defaults screen

60 Static Data Agent Default Inquiry (AGDFI) This screen allows you to display details of and inquire on standard settlement defaults for a pay or receive agent. You can use this screen to select an unauthorised record and start the authorisation process. The following figure shows an example of the Agent Default Inquiry screen: Figure 2 4. Agent Default Inquiry screen

61 Static Data Non Standard Settlement Instructions (NSTDM) This screen allows you to create non standard settlement instructions for payment agents, for use by a contract or a particular diary event for a contract. Note: At present, the Payment Indicator must always be set to Payments. If nothing is entered in the Diary Type and Date fields, the non standard settlement instructions entered on this screen will be applied to the whole of the contract schedule. For an Interest Rate Swap, you can indicate whether the non standard instructions are to be limited to the loan or deposit side of the contract. This field can be left blank if the instructions are to be applied to both sides of the contract. The Preferred Account at Agent and Preferred IBAN fields define the counterparty's account at the agent in normal format, and in IBAN format. Only one of these fields needs to be entered. If you want to apply the instructions to a single diary, you must complete the Diary Type and Date fields to identify the diary. For a Foreign Exchange Take Up, you must also enter the Take Up Reference Number to uniquely identify the diary, see the Foreign Exchange Administration Guide for details of Take Ups. For an Interest Rate Swap compensating payment, you must also enter the Compensating Payment Sequence Number to uniquely identify the diary, see the Forward Rate Agreements and Interest Rate Swaps Administration Guide for details of compensating payments. The following figure shows an example of the Non Standard Settlement Instructions for Pay Agents screen:

62 Static Data Figure 2 5. Non Standard Settlement Instructions screen

63 Static Data Nostro Details (NSTRO) This screen allows you to define the bank's nostros. These nostros are your accounts with other banks through which contracts are settled. Each nostro must also have either a client or general ledger account. The combination of account and currency must be unique for each nostro. Nostros using a client account must be set up as a client (see the Clients and Accounts Administration Guide). For each nostro you define the following on the Nostro Details (NSTRO) screen: The number, name and currency of the nostro The address of the nostro in various message transfer systems The account number at the bank which holds the nostro account The account number at your own bank The account number of the other bank's vostro account with us Whether or not the nostro bank requires us to issue MT210 (Notice to Receive) advices via S.W.I.F.T. When creating a nostro for the euro currency, the nostro number defined for the euro cannot be used for any other currency. Similarly, a nostro cannot be set up for the euro using the same number as nostros set up for other currencies. Refer to "Euro Related Information" in the Core Functions and Inquiries Guide for further information on how Economic and Monetary Union (EMU) affects nostros. Note: Once installation is complete, you can only delete nostros from the system by running the NSTAGNTDEL - Delete Nostros and Agents report (see the On-Demand Reports Guide for details). Only nostros that are not used by functions within the system can be deleted. The following fields are used by the S.W.I.F.T. interface: Nostro Longname The long name of the nostro. S.W.I.F.T. Address The S.W.I.F.T. address of the nostro. This is read in from the S.W.I.F.T address for the nostro entered in the client record, and cannot be changed on the Nostro Details (NSTRO) screen, only on the client details screen. Note that, if you do not enter a valid S.W.I.F.T. address, the S.W.I.F.T. message will not be sent. This will be reported at transmission time

64 Static Data MT210 Advices via S.W.I.F.T. Flag Whether or not the nostro bank requires your institution to issue MT210 advices via S.W.I.F.T. Switch 'On' - Produce MT210 advices via S.W.I.F.T. Switch 'Off' - Suppress MT210 advices via S.W.I.F.T. and generate printed messages only Our Account Number On Their Books The account number used by the nostro bank for our nostro account. Option 53B This is used when formatting MT100, MT103, MT200, or MT202 S.W.I.F.T. messages, and controls what will appear in Field 53B on the message. City of Residence This field retrieves the full name of the Nostro City from the General Purpose Narratives (GNARR) table, type CI. It is used to construct the full name and address field in the S.W.I.F.T. messages where the S.W.I.F.T. address is unknown. The city of residence must be the same as that contained in the client details of the nostro. Country of Residence The mnemonic of the country of residence of the nostro. Country mnemonics are defined in the Countries (CNTRY) table. The country of residence must be the same as that contained in the client details of the nostro

65 Static Data The following figure shows an example of the Nostro Details screen. Figure 2 6. Nostro Details screen

66 Static Data Nostro Settlement Defaults (NSDFM) This screen allows you to enter details of standard settlement defaults. The defaults appear on the contract screens at deal input, once the counterparty and currency are known. The defaults do not apply to the physical delivery of securities, whose details are determined from the contract's depot. A nostro can be defaulted for each combination of product, settlement currency and accounting centre. You can also set up a default nostro for a combination of client, product, settlement currency and accounting centre. You set up default nostros for payments and receipts separately. Default pay and receive agents are set up using the Agent Settlement Defaults (AGDFM) screen. To apply the default to all accounting centres, enter eight asterisks (********) in the Accounting Centre field. If a location is entered, a record is created for each accounting centre within the location. Switching Apply to All Contracts on means that all diary events for contracts with a value date equal to or greater than the entered start date will be amended to use these defaults. Switching this field off denotes that only contracts input on or after the start date may use these defaults. You can enter a default vostro account for clients that have an account at your bank. In this case, the contract's nostro field is set to 'V' and the contract's agent field is set to the default vostro account number. Standard settlement instructions can be set up for a defined period of time by entering an end date. The New End Date field can be used to change the time period. The new end date must be earlier than the existing end date. When you add a standard settlement default, the record is given a status of Awaiting Authorisation. When it is in this status it is not active. To activate the record it must be authorised. This is achieved by displaying the record on the screen and, clicking on Authorise. If the nostros have been created as a group using the "All Currencies" field, then they can be authorised as a group by switching 'On' the "Authorise All Currencies" field and clicking Authorise. If you need to change an authorised record, you must have authority to perform both change and authorise functions on this screen. Once you have performed the change you will not need to use the Authorise function. There is one exception, if you need to change the end date of a record, the change and authorise functions must be performed separately. The existing record will remain effective until the new record is authorised. Details of the standard settlement instructions for a client/accounting centre combination are given on the Nostro Default Inquiry (NSDFI) screen. A complete listing of default nostros is included in the STDFMLST - Standard Settlement Defaults List report (see the On-Demand Reports Guide for details)

67 Static Data Note: The Nostro Default Inquiry (NSDFI) screen should be used for inquiring on nostro defaults. You can then link to the Nostro Settlement Defaults (NSDFM) screen to obtain further information on an individual default. The following figure shows an example of the Nostro Settlement Defaults screen: Figure 2 7. Nostro Settlement Defaults screen

68 Static Data Nostro Default Inquiry (NSDFI) This screen allows you to display details of and inquire on standard settlement defaults for a pay or receive Nostro. You can use this screen to select an unauthorised record and start the authorisation process. The following figure shows an example of the Nostro Default Inquiry screen: Figure 2 8. Nostro Default Inquiry screen

69 Static Data Client Settlement Instructions for LA (CISIM) If you have the Loans Administration (LA) module, you can use this screen to set the default payment and receipt settlement instructions for each client used in LA contracts. When Show Defaults is selected, the settlement information set up at the Accounting Centre level is displayed. These accounting centre defaults will have been specified using the Nostro Settlement Defaults (NSDFM) screen. Settlement defaults for LA contracts at the Client level are based on a specific product type and currency. When asterisks are displayed in the Product Type field and the settlement instructions are added, the instructions will apply to all products in the specified currency by default. However, when you add settlement instructions for a specific product type, these override any instructions you have set up for all product types. If you have blueprint parameter BP-ATH-REQ-CISIM set on, authorisation is required for additions and changes using this screen. Additions and changes must be made with the status of Awaiting, and then authorised using the LA Client Settlement Instructions Authorisation Queue (CDATI) screen. If you do not have this blueprint parameter set on, additions and changes using this screen must be made with the status of Authorised. Use the Settlement Details area of this screen to specify the payment currency, the paying bank and the receiving agent for payments. For example, you could set up payment instructions for a client so that all products for that client would be paid for from a particular bank in a specific location to the counterparty s agent. Use the Beneficiary Details area of this screen to specify the name, address and account details of the beneficiary. The first name and address set up for the client in the Client Names and Addresses (NAMDM) (see the Clients and Accounts Administration Guide) screen is displayed as the default set up for the beneficiary when you inquire on the settlement instruction defaults for a client. To override the defaults in this window, perform an inquiry without selecting Show Default then add different information. To make an inquiry about the settlement instructions that has been entered using this screen. To do this, switch off "Show Defaults". Enter or select the client s short name, city and currency, authorisation status (if applicable) and, if required, a specific product type. Note: If you are adding or changing information, you must not have the Show Defaults field switched off. The following figure shows an example of the Client Settlement Instructions for LA screen

70 Static Data Figure 2 9. Client Settlement Instructions for LA screen

71 Static Data LA Client Settlement Instructions Authorisation Queue (CDATI) This screen is used for authorising additions and changes made on the Client Settlement Instructions for LA (CISIM) screen. This screen is only used if you have the Loans Administration module, and only if you have blueprint parameter BP-ATH-REQ-CISIM set on. Additions and changes made with the status of Awaiting, are authorised using this screen. Authorisation can only be done by a different user from the one who made the original change. To authorise a new or changed record, highlight the required record in the list, and click on Authorise. This links to the Client Settlement Instructions for LA (CISIM) screen, where the status of the record can be changed from Waiting to Authorised. To authorise deletion of a record, highlight the required record in the list, and click on Authorise Delete. The following figure shows an example of the LA Client Settlement Instructions Authorisation Queue screen. Figure LA Client Settlement Instructions Authorisation Queue screen

72 Static Data Payment Instruction Narratives (PCNRM) Special payment narratives can be set up to appear as printed messages on payments and confirmations. These narratives are entered on the Payment Instruction Narratives (PCNRM) screen. If no narrative is set up for the agent, nostro and currency combination a default message is printed on confirmations and payment advices. Caution Once installation is complete, care must be taken when deleting a payment instruction narrative. If you delete a payment instruction narrative, a default message is printed on those payments and confirmations that use the deleted narrative. The following figure shows an example of the Payment Instruction Narratives screen. Figure Payment Instruction Narratives screen

73 Static Data Security for SWIFT Tag Codes (STAGA) This screen is used to record the security code associated with a particular S.W.I.F.T. message type/tag code combination. There are currently six security codes available for use. These security codes are used in conjunction with the access group functionality to control who can update specific fields of S.W.I.F.T. messages. See "Defining Access Security" in the Guide to Setting Up for details of access groups. Particular uses of this message security feature are: If you set the same security level for a number of message type/tag code combinations, you can allow a user to update a number of fields If you do not apply a particular security level to a message type/tag code combination, then any user that can perform a change on the Settlement Message Review and Repair (MESSR) screen will be able to update them If you set a security level on a message type/tag code combination but do not authorise it for any access group, you can prevent a field from being updated by any user The recommended procedure for setting the update protection on messages is as follows: Identify those users that need to add messages using the Settlement Message Add (MESSA) screen and identify the message types that they will need to add Identify those users that need to repair messages using the Settlement Message Review and Repair (MESSR) screen. Identify the message type and tag fields that each user is to be allowed to update. For example on a MT103 (EMU Customer Transfer) message, you may want a user to be able to update the Sender to Receiver Information field (tag code 72). Highlight any message types and tag fields that no user must be allowed to update. For example on a MT103 (EMU Customer Transfer) message, you may not want any user to update the Amount field (tag code 32A). You now have details of the updating that is to be allowed for each message type and the users that are to perform the updates. You must now analyse the information according to the following rules: - Determine the access groups of the users who will be performing the updates/additions, so that you can see which access groups will need to be updated. It may be that you will have to add new access groups or change the access groups to which certain users are attached. - If a message type/tag code combination can be added or updated by anyone it must not be allocated a security code. - There are six security codes available (identified by numbers 5 through 10). - If only specific users are to be allowed to add or update a message type/tag code combination (for example, MT103/72), then it must be allocated a security code. - If different message type/tag code combinations (for example, MT103/56a and MT103/57a) are to be added or updated by the same group of users, then give them the same security code. Use the Security for SWIFT Tag Codes (STAGA) screen to set the security level identified for each message type/tag code combination for which adding/updating is to be restricted. For example, set a security level of 6 to the Sender to Receiver Information field (tag code 72) of the MT103 (Customer Transfer) message type

74 Static Data Amend the access groups of the users who are to add or repair messages. For full details of how to set up/maintain access groups, see "Setting Up Access Groups" in the Guide to Setting Up. Using the example above, if the operation number of the Settlement Message Review and Repair (MESSR) screen is set to 111, then you could authorise operations (change) and for an access group named SETTLE2 using the Access Group Authorisation (ACCES) screen. All users in access group SETTLE2 would then be able to update the Sender to Receiver Information field of Customer Transfer messages. Users in the SETTLE2 access group would also be able to update any other message/field combinations that have a security level of 6. If the update of a tag field (such as, tag code 72) is to be restricted for all message types, then use the Security for SWIFT Tag Codes (STAGA) screen to set up a security level for a combination of the tag code and a 'Blank Message' (MT999) message type. This sets the security level for the tag code on all message types. If a user is only to be allowed to add or update those tag code/message type combinations that can be updated by any user, then give the user update access to the Settlement Message Review and Repair (MESSR) screen using the standard security features described in "Defining Access Security" in the Guide to Setting Up. Do not give the user update access to any of the fields controlled by the use of the Security for SWIFT Tag Codes (STAGA) screen. Notes: The Settlement Message Add (MESSA) screen and the Settlement Message Review and Repair (MESSR) screen will have different operation numbers. Therefore, if a user is to be allowed to add messages using the Settlement Message Add (MESSA) screen and repair messages of the same type on the Settlement Message Review and Repair (MESSR) screen, then separate entries will be required for the two operations in the access group

75 Section 3 Contract Auditing/Authorisation Introduction This section provides a description of following settlements screens: Deals Input Confirmation (AWBOI) Settlement Instructions Confirmation (AWSTI) For each screen the following is provided: A description of its use An example of the screen A full description of the fields on the screens, and valid entries, is given in Section 12, Definition of Field Names. Please refer to the Starter s Guide for a description of how to access and use screens

76 Contract Auditing/Authorisation Screen Flow for Contract Auditing/Authorisation The screens used to audit and authorise contracts are illustrated below: Add a contract Enter Contract Details Select contract for review of contract management details Deals Input Confirmation (AWBOI) Settlement Instructions Confirmation (AWSTI) Select contract for review of settlement details Review/change contract management details Contract Change Screen Contract Change Screen Review/change of settlement details Remove contract from contract management queue Deals Input Confirmation (AWBOI) Settlement Instructions Confirmation (AWSTI) Select securities contract for review of depot details Settlement Instructions Confirmation (AWSTI) Remove contract from settlements queue Figure 3 1. Contract Auditing/Authorisation Screens

77 Contract Auditing/Authorisation Deals Input Confirmation (AWBOI) This screen displays details of contracts that have been input on a specified date, but that have not been reviewed and removed from the contract management queue. Contracts are listed by contract number. The main details of the contract, such as product, amount, start and maturity dates, are also shown. Details of contracts of all contract types are displayed. The purpose of this screen is to enable the department responsible for validating contracts to review and confirm details of all contracts entered into the system. Note: This screen does not show deal inputs for Loan Administration contracts. Depending on the needs of your organisation, the use of the contract management queue may have been made mandatory using blueprint parameter BP-VIEW-UNAUTH (see Blueprint Parameters in the Guide to Setting Up for details). If you make the use of the queue mandatory, then settlement messages cannot be generated until the contract has been removed from the queue using the Deals Input Confirmation (AWBOI) screen. For an overview of the use of the contract management queue see 'Settlement Process' in Section 1. Confirming Contract Details To confirm the details of a contract, you must link to the relevant contract change screen. Deals Input Confirmation (AWBOI) provides an automatic link to contract change screens. To do this, select the contract that you want to verify and click Contract. The system displays the relevant contract change screen with the contract details displayed. You may change details in the amendable fields if you wish. When you have agreed contract details, click Return to go back to the Deals Input Confirmation (AWBOI) screen. Removing a Contract from the Contract Management Queue Once you have confirmed the details of a contract by viewing it on the contract change screen, you may remove the contract from the queue. To do this, select the contract that you want to remove from the queue and click Remove. To remove multiple contracts from the queue, select the desired contracts, and click the Remove button

78 Contract Auditing/Authorisation The following figure gives an example of the Deals Input Confirmation (AWBOI) screen: Figure 3 2. Deals Input Confirmation screen

79 Contract Auditing/Authorisation Settlement Instructions Confirmation (AWSTI) This screen displays details of contracts that have been input on a specified date, but that have not been reviewed and removed from the contract settlement queue. Contracts are listed by contract number. The main details of the contract and whether settlement instructions are standard (as defaulted from the Nostro Settlement Defaults (NSDFM) and Agent Settlement Defaults (AGDFM) screens) or are to be advised, are also shown. Details of contracts of all contract types are displayed. The purpose of this screen is to enable the department responsible for settlements to review and confirm settlement details of all contracts entered into the system. Note: This screen does not show deal inputs on the settlement queue for Loan Administration contracts. Depending on the needs of your organisation, the use of the contract settlement queue may have been made mandatory using blueprint parameter BP-VIEW-UNAUTH (see Blueprint Parameters in the Guide to Setting Up for details). If you make the use of the queue mandatory, then settlement messages cannot be generated until the contract has been removed from the queue using the Settlement Instructions Confirmation (AWSTI) screen. For an overview of the use of the contract settlement queue see 'Settlement Process' in Section 1. Confirming Contract Settlement Instructions To confirm the details of a contract, you must link to the relevant contract change screen. The Settlement Instructions Confirmation (AWSTI) screen provides an automatic link to contract change screens. To do this, select the contract that you want to verify and click Contract. The system displays the relevant contract change screen with the contract details displayed. You may change details in the amendable fields if you wish. When you are satisfied with the settlement details, click Return to go back to the Settlement Instructions Confirmation (AWSTI) screen. Note: Details are displayed in amendable fields on contract change screens only if you select an unstarted or active contract on the Settlement Instructions Confirmation (AWSTI). Removing a Contract from the Contract Settlement Queue Once you have confirmed the details of a contract by: viewing it on the contract change screen and, if it is a securities contract, viewing its depot details on the Depot Details Confirmation (CNBDC) screen you may remove the contract from the queue. To do this, select the contract that you want to remove from the queue and click Remove. To remove multiple contracts from the queue, select the desired contracts, and click the Remove button

80 Contract Auditing/Authorisation The following figure gives an example of the Settlement Instructions Confirmation (AWSTI) screen: Figure 3 3. Settlement Instructions Confirmation screen

81 Section 4 Accounting Authorisation and Paper Settlements Introduction This section provides a description of following settlements screens: Accounting Authorisation Queue (ACQUE) Accounting Authorisation (ACATM) Paper Settlement Authorisation Queue (PSQUE) For each screen the following is provided: A description of its use An example of the screen A full description of the fields on the screens, and valid entries, is given in Section 12, Definition of Field Names. Please refer to the Starter s Guide for a description of how to access and use screens

82 Accounting Authorisation and Paper Settlements Screen Flow for Accounting Authorisation The screens used to authorise the postings associated with manual accounting models are illustrated below: Set up manual accounting model Accounting and Exposure Amount Parameters (ACEXM) Enter Contract Details Enter contract details Accounting Authorisation Queue (ACQUE) Enter actual amounts and authorise posting Accounting Authorisation (ACATM) Enter method of accounting for discrepancies Figure 4 1. Accounting Authorisation Screens

83 Accounting Authorisation and Paper Settlements Accounting Authorisation Queue (ACQUE) The accounting authorisation queue lists cash settlement amounts to be posted on a given value date by contract number. Events are only listed if they have had a record set up on the Accounting and Exposure Amount Parameters (ACEXM) screen. The Accounting and Exposure Amount Parameters (ACEXM) screen enables you to list up to ten amounts that compose the total amount to be posted on a diary event. See the Guide to Setting up for more information about this screen. When an event comes to value, the actual details associated with it may be different from expected when the deal was entered. For example, a reduced amount may be paid. For events using accounting models set to manual authorisation (see Setting Up Accounting Models in the Guide to Setting Up for details), the Accounting Authorisation Queue (ACQUE) screen enables you to enter the actual amount paid or received on a cash settlement event. The Expected Amount field displays the amount originally expected for the event. This can be overridden by entering a different amount in the Actual Amount field. The system posts the amount that you enter in the Actual Amount field. If such a discrepancy occurs you must adjust the contract schedule using the appropriate schedule maintenance screens to cater for it. The Diary By Contract Number (DICNI) inquiry screen shows the expected amounts. The ACCTRECON - Accounting Reconciliation and the ACMDLAUD - Accounting Models Audit reports show both the original amount and the actual amount for each event reported. The Accounting Authorisation Queue (ACQUE) screen also provides a link to the Accounting Authorisation (ACATM) screen where you can allocate the actual amount paid or received on a settlement event against different portions of the total amount expected. To link to the secondary screen, select a contract and click the Authorisation button. Note: Events that do not generate a cashflow, such as daily accrual (DY) events, are not shown on the Accounting Authorisation Queue (ACQUE) screen

84 Accounting Authorisation and Paper Settlements The following figure gives an example of the Accounting Authorisation Queue (ACQUE) screen: Figure 4 2. Accounting Authorisation Queue screen

85 Accounting Authorisation and Paper Settlements Accounting Authorisation (ACATM) When a cash settlement event comes to value, the actual details associated with it may be different from expected when the deal was entered. The actual details are recorded on the Accounting Authorisation Queue (ACQUE) screen. When a discrepancy occurs with the amount received, you may use the Accounting Authorisation (ACATM) screen to record how you want the amount to be accounted for. Note: This process applies to events using accounting models that are set to Manual authorisation only. In such cases, the settlement amount cannot be posted until it is confirmed on the Accounting Authorisation (ACATM) screen. The following figure gives an example of the Accounting Authorisation (ACATM) screen:

86 Accounting Authorisation and Paper Settlements Figure 4 3. Accounting Authorisation screen Accounting Amount Parameters Most settlement events on a contract have an amount that must be paid or received. However, this amount may represent a total of smaller amounts that contribute to it. For example the amount to be received at maturity (MA) on a Money Market loan could be composed of principal and interest. This subdivision of a settlement amount can be recorded on the Accounting and Exposure Amount Parameters (ACEXM) screen. Allocating Amounts using Accounting Authorisation (ACATM) To reach the Accounting Authorisation (ACATM) screen you must select an event on the Accounting Authorisation Queue (ACQUE), then click the Authorisation button. The Accounting Authorisation (ACATM) screen is displayed with the main details of the contract together with the Expected Amount from the original contract diary and the Actual Amount entered on the Accounting Authorisation Queue (ACQUE) screen. Also displayed are Accounting Model Amounts as set up on the Accounting and Exposure Amount Parameters (ACEXM) screen. You may overwrite any of these Accounting Model Amounts so if there is a discrepancy, you can decide how the amount actually paid or received is accounted for. When you are satisfied with the accounting model amounts, you can confirm them as follows, switch 'On' the Confirm field and click Ok. When a record is confirmed, its status is changed from Unposted to Posted. You can confirm events before they occur; this means that the amounts are available for posting when the event date is reached

87 Accounting Authorisation and Paper Settlements Screen Flow for Paper Settlement Management The screens used to manage the settlements associated with interest bearing and discounted securities contracts are illustrated below: Enter Contract Details Add an interest bearing or discounted security contract Paper Settlement Authorisation Queue (PSQUE) Review/Change status of security paper settlement Figure 4 4. Paper Settlement Screens

88 Accounting Authorisation and Paper Settlements Paper Settlement Authorisation Queue (PSQUE) For interest bearing and discounted security contracts, this queue provides a list of amounts to be settled by value date and contract number. Which amounts are displayed depends on the settlement status you select. Settlement status can be one of the following: To be delivered Delivered To be received Received Defaulted - i.e. the counterparty has failed to deliver The settlement status is not to be confused with the contract status that is displayed with the details for each event. You can also display list events that have been removed from the queue. Paper settlement events for all securities appear on the Paper Settlement Authorisation Queue (PSQUE), unless Delivery is set to No on the Repurchase Agreements - Add (REPOA) screen

89 Accounting Authorisation and Paper Settlements The following figure gives an example of the Paper Settlement Authorisation Queue: Figure 4 5. Paper Settlement Authorisation Queue screen Changing the Status of a Paper Settlement Amount You can change the settlement status of an amount as follows: To be delivered can be changed to Delivered or Defaulted Delivered can be changed to Defaulted To be received can be changed to Received or Defaulted Received can be changed to Defaulted Defaulted can be changed to Delivered or Received, depending on whether the amount is a deliverable or receivable To change the status of a paper settlement amount, click the Delivered, Received, or Defaulted button. You may remove any amount, regardless of status, from the queue. This has no impact on processing, it merely enables you to reduce the number of events displayed when you no longer need to see them. To do this, click the Removed button

90 Accounting Authorisation and Paper Settlements

91 Section 5 Depots Introduction This section provides a description of following settlements screens: Setting Up Depots Screens Depository Maintenance (CSDM) Depot and Account Definition (DEPAM) Depot Defaults (SPSTM) Depot and Account Definition Inquiry (DEPAI) Depot Defaults Inquiry (SPSTI) Depot Holdings Inquiry Screens Depot Account Holdings Position Inquiry (DEPSI) Depot Holdings Transaction Inquiry (DEPCI) For each screen the following is provided: A description of its use An example of the screen A full description of the fields on the screens, and valid entries, is given in Section 12, Definition of Field Names. Please refer to the Starter s Guide for a description of how to access and use screens

92 Depots Screen Flow for Setting Up Depots The screens used to define depots are illustrated below: Depository Maintenance (CSDM) Define Depositories Used by Your Institution or Clients Depot and Account Definition (DEPAM) Define Allowed Combinations of Depot/Account/ Sub-Account Depot Defaults (SPSTM) Define Default Combinations of Depot/Account/ Sub-Account Figure 5 1. Depot Definition Screens

93 Depots Setting Up Depots Screens Depository Maintenance (CSDM) This screen allows you to define the depositories used by your institution and clients. Before a depository can be used, it must first be defined on this screen. The accounts and sub-accounts at the depository must then be defined on the Depot and Account Definition (DEPAM) screen. See 'Introduction to Depots' in Section 1 of this guide for more information. The Stock Accounting Sub-balances are used by the Stock Exchange Securities module to track the movement of stock between depositories during the settlement process of a contract. These fields provide the headings for fields displayed, for example, on the Transaction Stock Movements Inquiry (SATRI), from where you can see the movement of stock. See the Stock Exchange and Securities Administration manual for more information

94 Depots The following figure shows an example of the Depository Maintenance screen: Figure 5 2. Depository Maintenance screen

95 Depots Depot and Account Definition (DEPAM) This screen allows you to identify the Depository/Account/Sub-Account combinations that are valid for your institution and your clients. Before a combination can be used in a contract, it must be identified on this screen. Before a depository can be entered on this screen, it must be defined on the Depository Maintenance (CSDM) screen. The start date defines when the depot account combination can be used in the system. If an end date is defined, then this defines the date when the depot account combination cannot be used from. If a new depot account is entered to replace the one shown, then the start date of the new record should match the end date of the old record. The start and end dates on this screen are used to define whether a particular combination is valid on the settlement date of a contract. If an end date is entered, you must ensure that the following start date corresponds to this, or you will be unable to enter a trade based on the combination. When closing a depot account, you must also delete any defaults defined for the combination on the Depot Defaults (SPSTM) screen. The Depot and Account Definition Inquiry (DEPAI) can be used to view a list of all combinations currently allowed by the system. The following figure shows an example of the Depot and Account Definition screen: Figure 5 3. Depot and Account Definition screen

96 Depots Depot Defaults (SPSTM) This screen can be used to define default combinations of Depot/Account/Sub-Account for use when entering contracts. The default combinations can either be for your institution, or for one of your clients. The default combination is based on three parameters Product Type, Currency, and Accounting Centre. Any of these parameters can be defined as a wildcard, which will let any value of the parameter be acceptable when assigning the default combination. Enter the following values to define a parameter as a wildcard: Product Type '******' Currency '****' Accounting Centre '*******' The Start Date and End Date fields define when the default combination can be used. The default combination is available on the Start Date, until the End Date. If a new default combination is entered for the same set of parameters, the old default combination will automatically be assigned an End Date dated one day before the new combination's Start Date. The following figure shows an example of the Depot Defaults screen: Figure 5 4. Depot Defaults screen

97 Depots Depot and Account Definition Inquiry (DEPAI) This screen allows you to inquire on all the Depository/Account/Sub-Account combinations that have been defined in the system. The inquiry will either display combinations valid for your institution, or for your clients. The inquiry can be further limited by entering one or more of the following filter fields: Definition Valid On and After Start Depository Start Account Start Sub-Account Any contract that has not yet reached the date defined in the 'Definition Valid On and After' field will appear in green on this screen. From this screen you can link to other screens for further information. To do this, highlight a line and: Click the Transaction Inquiry button to link to the Depot Holdings Transaction Inquiry (DEPCI) screen Click the Holdings Inquiry button to link to the Depot Holdings Inquiry (DEPSI) screen Click the Definition button to link to the Depot and Account Definition (DEPAM) screen

98 Depots The following figure is an example of the Depot and Account Definition Inquiry screen: Figure 5 5. Depot and Account Definition Inquiry screen

99 Depots Depot Defaults Inquiry (SPSTI) This screen can be used to view the default combinations currently defined in the system. The inquiry can either be run for default combination relevant to your institution, or an individual client. The inquiry can also be limited by entering a Product Type or Depot. The Show All field allows default combinations, which have expired to be viewed. From this screen you can link to the Depot Defaults Maintenance (SPSTM) screen for more information on a particular default. To do this, highlight a default value and click the Details button. The following figure shows an example of the Depot Defaults Inquiry screen: Figure 5 6. Depot Defaults Inquiry screen

100 Depots Depot Holdings Inquiry Screens The following screens are available to view holdings in depots, and the transactions that affect a holding: Depot Account Holdings Position Inquiry (DEPSI) Depot Holdings Transaction Inquiry (DEPCI) Depot Account Holdings Position Inquiry (DEPSI) This screen allows you to view a summary of your institution's holdings of securities, either for a single portfolio or at a depot. If viewing holdings at a depot, you can also enter an account and sub-account to limit the inquiry. The Start Date field is used to display holding position on the entered date. The position on the date is displayed, as well as any future deals. A contract will be included only if the As At Date of the inquiry is after the Input or Value Date of the contract. The Date Indicator field defines whether the Input or Value Date of a contract is used. From this screen you can link to the Depot Holdings Transaction Inquiry (DEPCI) screen by highlighting a holding and clicking the Holdings Inquiry button. The following figure is an example of the Depot Account Holdings Position Inquiry screen: Figure 5 7. Depot Account Holdings Position Inquiry screen

101 Depots Depot Holdings Transaction Inquiry (DEPCI) This screen allows you to view the transactions that have affected the holding of a security. To start the inquiry, enter an Instrument and click Ok. The inquiry can be limited by either entering a portfolio or a depository/account/sub-account combination. The From and To date fields allow the inquiry to be further limited to transactions with either an Input Date or a Value Date between these dates. The following figure is an example of the Depot Holdings Transaction Inquiry screen: Figure 5 8. Depot Account Holdings Contract Inquiry screen

102 Depots

103 Section 6 Individual Settlement Authorisation Introduction This section provides a description of following settlements screens: Outstanding Settlement Messages (SETCN) Authorise Release of Event Messages (SETTA) Authorise Release of Event Messages for LA Participants (SETTB) Settlement Message Add (MESSA) Settlement Message Review and Repair (MESSR) And the Inquiry screen: S.W.I.F.T. CASmf Interface Inquiry (CASMI) For each screen the following is provided: A description of its use An example of the screen A full description of the fields on the screens, and valid entries, is given in Section 12, Definition of Field Names. Please refer to the Starter s Guide for a description of how to access and use screens. If your institution is using the Straight Through Processing (STP) facility in the system, then you will only need to use the screens in this section for processing settlements that are not processed via STP

104 Individual Settlement Authorisation Screen Flow for Settlement Message Authorisation The screens used to authorise the individual settlement messages associated with contracts are illustrated below. Note that the Authorise Release of Event Messages for LA Participants (SETTB) screen is used for Loans Administration only: Automatic Message Generation (ONSETT) Settlement messages generated automatically from contract diary Outstanding Settlement Messages (SETCN) View contracts with outstanding messages and select a contract for authorisation Authorise Release of Event Messages for LA (SETTB) Authorise Release of Event Messages (SETTA) Optionally select a message for review/repair Settlement Message Review and Repair (MESSR) Optionally view details of message and repair if necessary Authorise Release of Event Messages for LA (SETTB) Authorise Release of Event Messages (SETTA) Authorise release of message for sending/printing Print Confirmations and Payment (ONPAPER) Report prints details of settlement S.W.I.F.T.CASmf Interface (SWIFTCAS) Report extracts details of settlements ready for sending via S.W.I.F.T. Alliance interface Settlement Message Extraction (ONSEND) Report extracts details of settlement and processes into a file in S.W.I.F.T. format. Figure 6 1. Settlement Message Authorisation Screens

105 Individual Settlement Authorisation Outstanding Settlement Messages (SETCN) This screen is used to inquire on lists of contracts for which messages, associated with events, have not yet been printed, or sent via S.W.I.F.T. The screen then enables you to select a contract so that you can see a summary of the outstanding messages on the Authorise Release of Event Messages (SETTA) screen. The latter screen can then be used to authorise individual messages for sending or printing. Contracts are displayed on this screen in value date order, with the oldest contract being displayed first. The following fields can be used as filters to limit the inquiry; Start Value Date, Contract Type, Product Type, Message Type, and View Authorised Deals Only. The contracts displayed on the Outstanding Settlement Messages (SETCN) screen can be controlled using a combination of blueprint parameter BP-VIEW-UNAUTH (see the Blueprint Parameters section of the Guide to Setting Up) and the 'View Authorised Deals Only' field on the screens. The two functions can be used together as follows: If BP-VIEW-UNAUTH is set to 'Y', then only contracts that have been confirmed using both the Deals Input Confirmation (AWBOI) and the Settlement Instructions Confirmation (AWSTI) screens will be displayed. The 'View Authorised Deals Only' field is overridden. If BP-VIEW-UNAUTH is set to 'C', then only contracts that have been confirmed using the Settlement Instructions Confirmation (AWSTI) screen will be displayed. In this case if the 'View Authorised Deals Only' field is set to: - Yes (Y) or Back Office (B), only contracts that have been confirmed using both the Deals Input Confirmation (AWBOI) and the Settlement Instructions Confirmation (AWSTI) screens will be displayed - No (N) or Settlements (C), only contracts that have been confirmed using the Settlement Instructions Confirmation (AWSTI) screen will be displayed If BP-VIEW-UNAUTH is set to 'B', then only contracts that have been confirmed using the Deals Input Confirmation (AWBOI) screen will be displayed. In this case if the 'View Authorised Deals Only' field is set to: - Yes (Y) or Settlements (C), only contracts that have been confirmed using both the Deals Input Confirmation (AWBOI) and the Settlement Instructions Confirmation (AWSTI) screens will be displayed - No (N) or Back Office (B), only contracts that have been confirmed using the Deals Input Confirmation (AWBOI) screen will be displayed If BP-VIEW-UNAUTH is set to 'N', then all contracts will be displayed. In this case if the 'View Authorised Deals Only' field is set to: - Yes (Y), only contracts that have been confirmed using both the Deals Input Confirmation (AWBOI) and Settlement Instructions Confirmation (AWSTI) screens will be displayed - Back Office (B), only contracts that have been confirmed using the Deals Input Confirmation (AWBOI) screen will be displayed - Settlements (C), only contracts that have been confirmed using the Settlement Instructions Confirmation (AWSTI) screen will be displayed - No (N), all contracts will be displayed If your institution is using Multiple S.W.I.F.T. terminals, you will only be able to view those messages sent or received by your S.W.I.F.T. Terminal unless you have been given special authorisation. Authorisation to view S.W.I.F.T. messages from any terminal is defined on the Setting Up Operations (OPERS) screen. The S.W.I.F.T. Terminal ID is defined for your

106 Individual Settlement Authorisation accounting centre on the Accounting Centres Maintenance (ACNTM) screen. Both of these screens are described in the Guide to Setting Up for more details on this screen. To view a summary of the outstanding messages for a contract on the Authorise Release of Event Messages (SETTA) screen. To do this, select the contract and click the Authorise Settlements button. Note: No automatically generated messages can be printed, or sent via S.W.I.F.T., until they have been authorised using the Authorise Release of Event Messages (SETTA) screen, unless they have been sent by STP. The following figure shows an example of the Outstanding Settlement Messages screen: Figure 6 2. Outstanding Settlement Messages screen

107 Individual Settlement Authorisation Authorise Release of Event Messages (SETTA) This screen is used to view and authorise a list of settlement messages associated with contract diary events, including: Messages not yet printed, or sent via S.W.I.F.T. (by setting the View Messages field to Unsent ) Messages already sent but which you now wish to review, reprint, or re-send (by setting the View Messages field to Sent ) All Messages (this includes all messages that appear in the above two categories). For institutions using STP, settlement messages need only be authorised from this screen if they have not been processed via STP. The screen can also be used to view messages that were produced, but that are no longer current because the contract has been changed. For example, if a maturity date is changed, then the screen can display the original maturity settlement message, the reversal of the original maturity settlement message and the new maturity settlement message. The display of non-current messages can be prevented using blueprint parameter BP-VIEW-ALL (see the Blueprint Parameters section of the Guide to Setting Up). The Authorise Release of Event Messages (SETTA) screen then enables you to: Authorise messages for sending Authorise messages for printing View details of a message in S.W.I.F.T. format, so that it can be validated and repaired if necessary using the Settlement Message Review and Repair (MESSR) screen. If it is essential that repair takes place before the message is sent, then this is indicated by "See MESSR" within the message summary. Delete messages Note: No messages can be printed, or sent via S.W.I.F.T., until they have been authorised, either manually or via the STP process. If the Authorise Release of Event Messages (SETTA) screen displays a message with a Tag Code of MT000/000000, then this indicates that details of the message have not been generated because the ONSETT - Settlement Message Creation report has not processed it. Initial Message Authorisation Once the inquiry has been made using the Unsent option, and the requested list of events is displayed, you may make entries in the following fields: Media You can choose whether to send the message as a printed message or as a S.W.I.F.T. message. To do this, click on the Media field to activate the dropdown list and select either Printed or S.W.I.F.T

108 Individual Settlement Authorisation Action Using this field you can perform the following actions: Make a selection by clicking on the relevant Action field to activate the dropdown list. Select Delete if you wish to delete the message, in which case no entry should be made in the Media field. Select Netting Inquiry to link through to the Netting Inquiry (NETTI) screen. Select Non Standard Instructions to link through to the Non Standard Instructions (NSTDM) screen (if appropriate). Select Not Authorised if the message has been authorised incorrectly, and is not yet ready to be authorised. Select Participants to link through to the Authorise Release of Event Messages for LA Participants (SETTB) screen (for Loans Administration contracts only). Select View to display the message details on the Settlement Message Review and Repair (MESSR) screen. Select Send if you wish to authorise the message. This entry may be used in conjunction with the Media field. Select Reprint if you wish to reprint the selected message, or if the original message was sent electronically via S.W.I.F.T., then the message will be resent. Messages Already Authorised Once the inquiry has been made using the Sent option, and the requested list of events is displayed, you may make entries in the following fields: Media You can send the message again, as a printed message or as a S.W.I.F.T. message. To do this, click on the Media field to activate the dropdown list and select either Printed or S.W.I.F.T. Action Using this field you can view, delete or resend a message: Select View to display the message details on the Settlement Message Review and Repair (MESSR) screen. Select Delete if you wish to delete the message, in which case no entry should be made in the Media field. Select Resend/Reprint if you wish to send the message again. This must be used in conjunction with the Media field. Note: If a S.W.I.F.T. message has been repaired, it cannot be resent via S.W.I.F.T. You can also use the Action field to link to the Netted Payments Inquiry (NETTI) screen to view a summary of all the payments included within the netted payment. This is only possible if the contract being viewed is a consolidated netting contract. For further information, see the Netted Payments Inquiry (NETTI) screen. To access the Netted Payments Inquiry (NETTI) screen from the Authorise Release of Event Messages (SETTA) screen. To do this, search for the required contract, highlight the required event in the event list. Then select 'Netting Inquiry' from the Action field and click the Ok button

109 Individual Settlement Authorisation The following figure shows an example of the Authorise Release of Event Messages screen. Figure 6 3. Authorise Release of Event Messages screen

110 Individual Settlement Authorisation Authorise Release of Event Messages for LA Participants (SETTB) This screen is used only for Loans Administration contract types. Use this screen to authorise the release of confirmations and payment messages for participants in these contracts, or to delete messages. You can update the Authorisation code to send, re-send or delete individual messages to participants. This screen is similar to the Authorise Release of Event Messages (SETTA) screen except that there is no update indicator since this screen only relates to individual confirmations or payment messages for participants. See Authorise Release of Event Messages (SETTA) for full details of use. The following figure shows an example of the Authorise Release of Event Messages for LA Participants screen. Figure 6 4. Authorise Release of Event Messages for LA Participants screen

111 Individual Settlement Authorisation Settlement Message Review and Repair (MESSR) This screen is used to view the details of a settlement message in S.W.I.F.T. format. If you have sufficient authority (see 'Message Update Protection' in Section 1), then you can update the settlement message. Different tag fields within a message may have different levels of security, therefore you may be able to update some fields but not others. This screen can be accessed by selecting a message on the Authorise Release of Event Messages (SETTA) screen in which case full details of the message will be displayed automatically. Alternatively you can access the screen directly in which case you must enter the contract number and message type, then, click the Inquire button. The screen will display details of the first message of the selected type that was generated for the contract. To display a particular message, you must also enter the message number. Using this screen you can: Change an existing line Insert a line into a message Delete a line from a message To change a line, switch 'On' the Select field of the line you are changing. Edit the tag code and data as necessary and click the Change button. To insert a line, switch 'On' the Select field of the line above that you want to add a line and click the Add button. To delete a line, switch On in the Select field of the line to be deleted and click the Delete button

112 Individual Settlement Authorisation You can use this screen to view the status of a settlement message. The CASmf Status field is only displayed once the message has been authorised for sending. It will then display the status of the message that is whether it has been sent, unsent or rejected. If the message is rejected, the reject code and the number of times the message has been rejected will both be shown. The following figure shows an example of the Settlement Message Review and Repair screen. Figure 6 5. Settlement Message Review and Repair screen

113 Individual Settlement Authorisation Screen Flow for Manual Message Production The screens and reports used to produce settlement messages manually are illustrated below: Settlement Message Add (MESSA) Enter a settlement message manually S.W.I.F.T. CASmf Interface (SWIFTCAS) Report extracts details of settlements ready for sending via S.W.I.F.T. Alliance interface Settlement Message Extraction (ONSEND) Report Extracts Details of settlement and processes into a file in S.W.I.F.T. format Print Confirmations and Payments (ONPAPER) Report prints details of settlement Figure 6 6. Manual Settlement Message Production

114 Individual Settlement Authorisation Settlement Message Add (MESSA) This screen is used for manually entered settlement messages. To utilise the screen you must have a knowledge of S.W.I.F.T. formatted messages. You can Add settlement messages Change messages that have been entered manually View messages that have been entered manually Send messages that have been entered manually If you have sufficient authority (see 'Message Update Protection' in Section 1), then you can add or change settlement messages. Different tag fields within a message may have different levels of security, therefore you may be able to update some fields but not others. To view a message you must enter the reference number and message type, then click the Inquire button. The screen will display details of the first message of the selected type that was entered for the reference number. To display a particular message, you must also enter the message number. Using this screen you can: Change an existing line Insert a line into a message Delete a line from a message To change a line, switch On the Select field of the line you are changing. Edit the tag code and data as necessary and click the Change button. To insert a line, switch On the Select field of the line above that you want to add a line and click the Add button. To delete a line, switch On in the Select field of the line to be deleted and click the Delete button. When you have finished adding details of a message, click the Add button. To update any part of a message, update the appropriate fields and, click the Change button. To send a message, set the Send Message field to "Yes" and perform a change as described above. This will cause the message to be processed by either the ONSEND - Settlement Message Extraction, the ONPAPER - Print Confirmations and Payments or the SWIFTCAS - S.W.I.F.T. CASmf Interface reports, see the On-Demand Reports Guide for details

115 Individual Settlement Authorisation The following figure shows an example of the Settlement Message Add screen. Figure 6 7. Settlement Message Add screen

116 Individual Settlement Authorisation S.W.I.F.T. CASmf Interface Inquiry (CASMI) Use this screen to inquire on a S.W.I.F.T. message using the CASmf Interface, for both outgoing and incoming messages. To use this screen, you must enter your S.W.I.F.T. Terminal ID, and whether you want to inquire on Input or Output messages (that is messages Input to S.W.I.F.T. or Output from S.W.I.F.T.). You can also limit the inquiry by entering a time and/or date from which to search. If your institution is using Multiple S.W.I.F.T. terminals, you will only be able to view those messages sent or received by your S.W.I.F.T. Terminal, unless you have been given special authorisation. This special authorisation is defined on the Setting Up Operations (OPERS) screen. The S.W.I.F.T. Terminal ID is defined for your accounting centre on the Accounting Centres Maintenance (ACNTM) screen. These screens are described in the Guide to Setting Up. From this screen, you can link to the Settlement Message Review and Repair (MESSR) screen to view messages leaving the system or the Output from Message Inquiry (MSGI) screen to view messages arriving in the system from S.W.I.F.T. To do this, highlight the message you want to view and click the Details button. The following figure shows an example of the S.W.I.F.T. CASmf Interface inquiry (CASMI) screen. Figure 6-8. S.W.I.F.T. CASmf Interface Inquiry screen

117 Section 7 Loans Administration Fee Settlements Introduction Fee settlements for prepaid and accrued fees must be authorised manually if your accounting model uses Accounting Events for Authorised Fee Settlement as described in the following section. Authorisation is achieved using the following two screens: LA Fee Settlement Confirmation (LARSM) Use this screen to enter the date on which a fee settlement was paid or received by your institution and to mark it as Awaiting Authorisation. This places the fee settlement in the queue for authorisation. LA Fee Settlement Authorisation (LAFAM) Use this screen to authorise the fee settlements that have been marked as Awaiting Authorisation. Manual authorisation does not apply to flat fees that only have a single payment. For syndicated fees, authorising settlement for the borrower automatically authorises settlement for the participants. Accounting Events for Authorised Fee Settlement When a fee settlement is due, it is possible to ensure that manual authorisation takes place by utilising an accounting model for authorised fee settlement events. You utilise these accounting events by manually authorising a standard event, such as a fee settlement event. Therefore, the settings of your accounting models can be used to utilise the authorised fee settlement events instead of the standard fee settlement events. Note: It is possible to set up accounting models to utilise both standard events and authorised events, but this must be done with care or duplicate postings may result. The accounting events for authorised fee settlement postings are: Agent/Borrower Authorised Fee Settlement (AFF) User Bank Authorised Fee Settlement (UFF) Participant Authorised Fee Settlement (PFF) Sub-Participant Authorised Fee Settlement (XFF) Net Bank Authorised Fee Settlement (TFF) For further details of accounting models and accounting events, see the Guide to Setting Up

118 Loans Administration Fee Settlements Loans Administration Fee Settlements Screens This section provides a description of the following Loans Administration Fee Settlement screens. LA Fee Settlement Confirmation (LARSM) LA Fee Settlement Authorisation (LAFAM) For each screen the following is provided: A description of its use An example of the screen See the Starter s Guide for a description of how to access and use screens

119 Loans Administration Fee Settlements LA Fee Settlement Confirmation (LARSM) Use the LA Fee Settlement Confirmation (LARSM) screen to confirm that a fee settlement has been paid or received. You can also use the screen to identify late fee payments. All types of settlement event are displayed on this screen. You can select an accrued/pre-paid fee event to generate an authorised fee settlement accounting event. To begin the authorisation process for a fee settlement, change the status from Unconfirmed to Awaiting Authorisation. To do this, select a record, then select Awaiting Authorisation from the Status field drop down list. Enter a settlement date and click Change to commit the change in status of the fee settlement. The settlement event then becomes available for authorisation by a different user. The next step in the authorisation process is performed via the LA Fee Settlement Authorisation (LAFAM) screen. When authorisation has been completed on the LA Fee Settlement Authorisation (LAFAM) screen, the status on the LA Fee Settlement Confirmation (LARSM) screen will be Confirmed. The following figure shows an example of the LA Fee Settlement Confirmation screen. Figure 7 1. LA Fee Settlement Confirmation screen

120 Loans Administration Fee Settlements LA Fee Settlement Authorisation (LAFAM) Use the LA Fee Settlement Authorisation (LAFAM) screen to manually authorise fee settlements that had their status changed to Awaiting Authorisation on the LA Fee Settlement Confirmation (LARSM) screen. This can only be done by a different user from the one who changed the status on the LA Fee Settlement Confirmation (LARSM) screen. The LA Fee Settlement Authorisation (LAFAM) screen can also be used to inquire on fee settlements that are either awaiting authorisation or have been authorised. If you are a different user from the user responsible for last updating a fee settlement s status, you can authorise a settlement as follows. Set the Status field to Waiting and click Inquire. Select a record, then select Payment Only or Payment and Accounting from the Authorise field drop down list and click Change to commit the change in status of the fee settlement. The effect of changing the status is: Payment Only Causes the payment messages to be generated but postings are not performed. This status can be utilised for any settlement date. Payment and Accounting Causes payment messages to be generated (if not already generated via the Payment Only status) and postings are performed. This status can be utilised when the settlement date is today or in the past. Note: If a client or participant has netted payments, no messages are produced for that client/participant. The following figure shows an example of the LA Fee Settlement Authorisation screen. Figure 7 2. LA Fee Settlement Authorisation screen

121 Section 8 Clean Payments Introduction to Clean Payments Clean Payments refer to a payment or a series of payments made by a bank on behalf of a client (normally the customer of a bank) to a third party (the beneficiary). The payment may be effected through an intermediate bank (the beneficiary s bank). These payments are not related to any underlying contract or transaction; they are, generally, one-off payments involving the transfer of funds. The payment or payments may be made in any currency. See Overview of Clean Payments in Section 1 of this guide for more details. The following screens are described in this section: Setting Up Clean Payment Defaults Clean Payments Default Maintenance (CPDFM) Adding Clean Payments into the System Clean Payments Addition (CPAYA) Clean Payment Message Input Screen One 103 (CP100, CP101, CP102, CP103) either singly or as part of an MT103/MT202 cover settlement Clean Payment Message Input Screen One 202 (CP202, CP203) either singly or as part of an MT103/MT202 cover settlement Clean Payments Authorisation (CPAUT) Inquiring on and Changing Clean Payment Details Outward Clean Payments Amendment (CPAYC) Clean Payments Inquiry Screen One 103, Screen Two, Screen Three, and Four (CPMT1), (CPMT2), (CPMT3), and (CPMT6) Clean Payments Inquiry Screen One 202, and Screen Two (CPMT4) and (CPMT5) Outward Clean Payments Inquiry (CPAYI) Clean Payments Inquiry by Account (CPACQ) Clean Payments Inquiry by Product (CPPRQ)

122 Clean Payments Inward Clean Payment Screens Outward S.W.I.F.T. Messages Inquiry (MSGSI) Incoming Clean Payments Inquiry (CPINI) Output from Message Inquiry (MSGI)

123 Clean Payments Clean Payments Status While entering a clean payment into the system, its status will change depending on where it is in the process. The status on the original instruction listed is updated to reflect the associated clean payment contract. Therefore, if a clean payment status is changed, the inward clean payment status will also change. The following are the possible status values for Clean Payments and Inward Clean Payments: Clean Payments Status Incomplete - The Inward Clean Payment has been partially entered into the system Unauthorised - The Clean Payment has been entered, is above the Authorisation Limit, and has not been authorised. The payment is also unauthorised if insufficient funds are available Rejected - The Clean Payment has been rejected, and must be amended before being authorised again Deleted - The Clean Payment will be deleted from the system during the next purge Authorised - The Clean Payment has been entered into the system and authorised Posted - The clean payment has been authorised and processed by the CPAYMENTS - Clean Payments Processing report, and has past the Posting Date. This includes sending S.W.I.F.T. messages to the Settlement queue, and posting of payments to client accounts Pending - See Clean Payment and Client Account Management Services in Section 1 of this guide Inward Clean Payments Status Received - The Inward S.W.I.F.T. message has been received from S.W.I.F.T. and is on the Incoming Clean Payments Inquiry (CPINI) queue pending processing Incomplete - The Inward Clean Payment has been partially entered into the system Unauthorised - The Inward Clean Payment has been entered, is above the Authorisation Limit, and has not been authorised Rejected - The Clean Payment has been rejected, and must be amended before being authorised again Deleted - The Clean Payment will be deleted from the system during the next purge Authorised - The Inward Clean Payment has been entered into the system and authorised Posted - The clean payment has been authorised and processed by the CPAYMENTS - Clean Payments Processing report. This includes sending S.W.I.F.T. messages to the Settlement queue, and posting of payments to client accounts Pending - See Clean Payments and Client Account Management Services in Section 1 of this guide

124 Clean Payments Clean Payment Screens Clean Payments Default Maintenance (CPDFM) Use this screen to set-up defaults for a clean payment product. If a clean payment is entered via the Clean Payments Add (CPAYA) screen for a product which has defaults, these default values will be displayed on the Clean Payments Add (CPAYA) screen for use in creating the clean payment. The use of defaults thereby saves keystrokes and standardises payments involving the same product. The authorisation limit defined on this screen will apply to all clean payments for that product. This limit defines the amount below which a clean payment does not need authorising. If no limit is set, the blueprint parameter BP-CP-AUTH-LIMIT defines the authorisation limit, and BP-CP-CCY defines the authorisation currency. When entering a clean payment using a product type, it is possible to overwrite any of the supplied default values. Note: When entering the details of a received inward message from the Incoming Clean Payments Inquiry (CPINI) screen, then the defaulted details from the inward message are not overwritten with product defaults. The following figure shows an example of the Clean Payments Default Maintenance screen

125 Clean Payments Figure 8-1. Clean Payments Default Maintenance screen

126 Clean Payments Clean Payments Addition (CPAYA) Use this screen to enter clean payments into the system. If the clean payment is between two accounts in your institution, then this is the only screen necessary when entering details of a clean payment. If the clean payment involves an account, individual or company outside of your institution, then you must complete additional settlement details on separate screens. For clean payments where a S.W.I.F.T. message needs to be produced, you must decide which S.W.I.F.T. message is relevant. Three S.W.I.F.T. messages are appropriate in different circumstances: MT103 - Customer Transfer. To create an MT103, enter "Yes" in the MT103 field. (See Overview of Clean Payments in Section 1 for details of MT100 messages.) MT202 - General Institution Information Transfer. To create an MT202, enter "Yes" in the MT202 field. MT210 - Notice to Receive. An MT210 is created automatically if a Nostro account is entered as the debit account, and the "MT210 Advice Via S.W.I.F.T." field on the Nostro Details (NSTRO) screen is set to Yes. When creating an MT103 or MT202, you should complete the details on the Clean Payments Addition (CPAYA) screen first. In so doing, the system will be able to enter many of the fields on the S.W.I.F.T. message production screens with the correct information. Pre-filled information will differ depending on the combination of S.W.I.F.T. message required. Once all the details relevant to the clean payment have been completed, then, switch on the "Entry Complete" field and click the OK button. If the clean payment is suitable for automatic authorisation, a message will be displayed confirming the clean payment authorisation. Finally, click the OK button again to confirm the authorisation

127 Clean Payments Before the details are entered, the system will perform a balance check on the debit account (unless the debit account is a nostro). If sufficient funds are not available, a warning message will be displayed, preventing any automatic authorisation of the payment, and requiring you to override the warning when you are authorising the payment on the Clean Payment Authorisation (CPAUT) screen. Note that account overdraft limits are not included in the calculation of sufficient funds. Deleting a S.W.I.F.T. Message If you want to delete a S.W.I.F.T. message that you have previously created then, click on either Delete MT103 button or Delete MT202 button to delete the MT103 or MT202 respectively. Inward Clean Payments When a clean payment is received by the system from another institution, it will be displayed on the Incoming Clean Payments Inquiry (CPINI) screen. You can then link to the Clean Payments Addition (CPAYA) screen to add the clean payment into your system. Key details are automatically taken from the incoming S.W.I.F.T. message, and entered into the relevant fields on the Clean Payments Addition (CPAYA) screen. For an overview of Inward Clean Payments see Inward Clean Payments in Section 1 of this guide. If you enter a clean payment before the S.W.I.F.T. message has arrived, you should enter a "*" in the Incoming Reference field. When the message arrives, you can match the message to the clean payment you previously entered and labelled in this way. The matching process only searches for clean payments with a "*" in the incoming reference field, and uses the value date, currency, and amount from the credit side of the contract. A successful match will display the Clean Payments Addition (CPAYC) screen, and if accepted, the "*" is replaced with the OSN reference from the incoming message. The incoming message itself has the Urbis contract number added to complete the cross reference. If you do not want to match against the displayed message, click the Return button to go back to the Incoming Clean Payments Inquiry (CPINI) screen. The matching process will now ignore the contract that was previously displayed. For inward clean payments, double clicking on any portion of the screen will display the Message Inquiry (MSGI) screen to view the received S.W.I.F.T. message

128 Clean Payments The following figure shows an example of the Clean Payments Addition screen. Figure 8-2. Clean Payments Addition screen

129 Clean Payments MT103 Additional Details Screens Use these screens to enter details into the MT103 - Customer Transfer message. These screens will only be accessed if you entered 'Yes' in the "Create MT103" field on the Clean Payments Addition (CPAYA) screen or Outward Clean Payments Amendment (CPAYC) screen. The fields on these screens follow the format of a standard S.W.I.F.T. message. On all the MT103 Additional Detail Screens, there are Tag fields that must be entered along with the field. For more information on appropriate use of tags, see the S.W.I.F.T. documentation. A message will only become available on the standard Message Authorisation queue when the associated Clean Payment is Posted after being authorised. On the Message Authorisation queue, you can authorise a message for release by using the Message Authorisation (SETTA) screen, see Section 6, Individual Settlement Authorisation

130 Clean Payments Clean Payment Message Input Screen One 103 (CP100) The following figure shows an example of the Clean Payment Message Input Screen One 103 screen. Figure 8-3. Clean Payment Message Input Screen One 103 screen

131 Clean Payments Clean Payment Message Input Screen Two 103 (CP101) The following figure shows an example of the Clean Payment Message Input Screen Two 103 (CP101) screen. The surrounding window is not shown, but is similar to that for the Clean Payment Message Input Screen One 103 (CP100) screen. Figure 8-4. Clean Payment Message Input Screen Two 103 screen Clean Payment Message Input Screen Three 103 (CP102) The following figure shows an example of the Clean Payment Message Input Screen Three 103 (CP102) screen. The surrounding window is not shown, but is similar to that for the Clean Payment Message Input Screen One 103 (CP100) screen. Figure 8-5. Clean Payment Message Input Screen Three 103 Screen

132 Clean Payments Clean Payment Message Input Screen Four 103 (CP103) The following figure shows an example of the Clean Payment Message Input Screen Four 103 (CP102) screen. The surrounding window is not shown, but is similar to that for the Clean Payment Message Input Screen One 103 (CP100) screen. Figure 8-6. Clean Payment Message Input Screen Four 103 Screen

133 Clean Payments MT202 Additional Details Screens Use this screen to enter details into the MT202 - Customer Transfer message. This screen will only be accessed if entered 'Yes' in the "Create MT202" field on the Clean Payments Addition (CPAYA) screen. The fields on these screens follow the format of a standard S.W.I.F.T. message. On all the MT202 Additional Detail Screens, there are Tag fields that must be entered along with the field. For more information on appropriate use of tags, see the S.W.I.F.T. documentation. Once the message has been completed and the clean payment authorised and posted, then it will pass onto the Message Authorisation queue, from where you can authorise the message for release by using the Message Authorisation (SETTA) screen, see Section 6, Individual Settlement Authorisation. Clean Payments Message Input Screen One 202 (CP202) The following figure shows an example of the Clean Payments Message Input Screen One 202 (CP202) screen. Figure 8-7. Clean Payments Message Input Screen One 202 screen Clean Payments Message Input Screen Two 202 (CP203) The following figure shows an example of the Clean Payments Message Input Screen Two 202 (CP203) screen. The surrounding window is not shown, but is similar to that for the Clean Payments Message Input Screen Two 202 (CP202) screen

134 Clean Payments Figure 8-8. Clean Payments Message Input Screen Two 202 screen

135 Clean Payments Clean Payments Authorisation (CPAUT) Use this screen to authorise an unauthorised clean payment that either exceeds the Authorisation Limit set for its product type or have failed a balance check. This screen can also be used to authorise standing orders that have failed a balance check. The Authorisation Limit is set on the Clean Payments Default Maintenance (CPDFM) screen. If the product of the clean payment does not have an authorisation limit related to it, then the authorisation limit is defined by the blueprint parameter BP-CP-AUTH-LIMIT. This screen cannot be accessed directly, and is called from the Clean Payments Inquiry by Account (CPACQ) or the Clean Payments Inquiry by Product (CPPRQ) screens, where you can select the clean payment you want to view for authorisation. If relevant, a balance check is performed to ensure sufficient funds are available. If not relevant, a warning message is displayed showing the current available balance. You can override this warning and process the clean payment (to do this switch "On" the Balance Override field). When the details are displayed, you can either authorise or reject it. To do this, in the Status field, select either Authorised or Rejected. You can also view any MT103 or MT202 message that is linked to the clean payment you are authorising. To do this, click either the View MT103 or View MT202 button to view the appropriate S.W.I.F.T. message. If the credit/debit dates are equal to today or are within the Payment Days in Advance defined for the country of the message destination, then once a clean payment has been authorised, it will be processed by the sleeping report CPAYMENTS - Clean Payments Processing. This report will send any settlement messages to the Settlements queue and carry out postings to accounts involved in the payment. The status of the message will be changed from Unauthorised to authorised, and then Posted. S.W.I.F.T. messages sent to the Settlement queue can be authorised using the Authorise Release of Event Messages (SETTA) screen, described in Section 6 of this guide. If the credit/debit dates are in the future, the CPAYMENTS - Clean Payments Processing report will carry out-processing during the appropriate overnight run. This report is described in the On-Demand Reports Guide. The following figure is an example of the Clean Payments Authorisation (CPAUT) screen

136 Clean Payments Figure 8-9. Clean Payments Authorisation screen

137 Clean Payments Outward Clean Payments Amendment (CPAYC) Use this screen to amend the details of a clean payment at any stage before it has been authorised. You can also alter any MT103 or MT202 S.W.I.F.T. message that has been created for the clean payment. From this screen you can view any S.W.I.F.T. messages related to the clean payment. To do this, enter 'Yes' in either the "Has MT103" or "Has MT202" fields and click OK. This will take you to the "Clean Payment Message Input Screen One 103 (CP100) or Clean Payments Message Input Screen One 202 (CP202) screen respectively. You can also delete the MT103 or MT202 message attached to a clean payment from this screen. To do this, click either the Delete MT103 or Delete MT202 fields and click OK. This will delete MT103 message or MT202 message respectively. Note: If you change any Clean Payment details, some fields within an associated MT103/MT202 message will revert to their default values. If you enter a contract using automatic authorisation, it will be redisplayed with the status of 'Authorised'. You can now amend other clean payments by entering a new contract number

138 Clean Payments The following figure is an example of the Outward Clean Payments Amendment screen. Not all tab pages are shown, as they are similar to those on the Clean Payments Amendment (CPAYA) screen. Figure Outward Clean Payments Amendment screen

139 Clean Payments Outward Clean Payments Inquiry (CPAYI) Use this screen to inquire on the details of a clean payment. You can also view any related MT103 or MT202 S.W.I.F.T. message from this screen by clicking the View MT103 or View MT202 buttons. You will be taken to either the Clean Payments Inquiry Screen One 103 (CPMT1) or Clean Payments Inquiry Screen One 202 (CPMT4) screen. From this screen you can also copy, replace or delete the contract. A payment can only be replaced or deleted if it is not yet authorised. Copying a clean payment is used to make a new clean payment with many of the details of the old one. All details except Balance Override, Contract Number, Holiday Override, Width Override and Incoming Reference are entered into the new clean payment, including any relevant MT103 or MT202 S.W.I.F.T. messages. To do this, click the Copy button. Replacing a clean payment works in the same way, except that when the new clean payment is created, the old one is deleted. It is only possible to replace a contract if it has not already been authorised. To do this, click the Replace button. Deleting a clean payment is only possible if it has not yet been authorised. The delete function will also delete any related MT103 or MT202 S.W.I.F.T. message. To do this, click the Delete button

140 Clean Payments The following figure is an example of the Outward Clean Payments Inquiry screen. The tab pages are not shown, as they are similar to those for the Clean Payments Addition (CPAYA) screen shown earlier in this section. Figure Outward Clean Payments Inquiry screen

141 Clean Payments MT103 and MT202 Inquiry Screens Use these screens to view completed MT103 and MT202 S.W.I.F.T. messages. You can open these screens from the Outward Clean Payments Inquiry (CPAYI) screen. As the inquiry screens are similar to the S.W.I.F.T. message add screens described earlier in this section, then they are not shown below. You can view the S.W.I.F.T. message add screens in MT103 Additional Details Screens and MT202 Additional Details Screens earlier in this section. The following screens are included to inquire on the S.W.I.F.T. messages: For MT103 Clean Payments Message Inquiry Screen One 103 (CPMT1) Clean Payments Message Inquiry Screen Two 103 (CPMT2) Clean Payments Message Inquiry Screen Three 103 (CPMT3) Clean Payments Message Inquiry Screen Four 103 (CPMT6) For MT202 Clean Payments Message Inquiry Screen One 202 (CPMT4) Clean Payments Message Inquiry Screen Two 202 (CPMT5)

142 Clean Payments Clean Payments Inquiry by Account (CPACQ) Use this screen to view the clean payments related to a particular client account. Either the credit account, debit account or currency can be inquired upon. You can also limit the inquiry to show payments after a particular debit value date, or payments of a particular status, by using the Start Value Date or Status fields. From this screen you can link to the following screens: Outward Clean Payments Inquiry (CPAYI) - for inquiring on the details of a clean payment Outward Clean Payments Amendment (CPAYC) - for adding to or changing the details of a clean payment Clean Payments Authorise (CPAUT) - for authorising a clean payment Authorise Release of Event Messages (SETTA) - for reviewing or authorising messages related to a 'Posted' clean payment To link to one of these screens, click either the Details, Modify, Authorise or View Message buttons to go to the Outward Clean Payments Inquiry (CPAYI), Outward Clean Payments Amendment (CPAYC), Clean Payments Authorise (CPAUT) or Authorise Release of Event Messages (SETTA) screens respectively. The following figure is an example of the Clean Payments Inquiry by Account screen. Figure Clean Payments Inquiry by Account screen

143 Clean Payments Clean Payments Inquiry by Product (CPPRQ) Use this screen to view all the clean payments related to a particular accounting centre. Either debit or credit payments can be listed. You can also limit the inquiry to show payments of a particular product type, payments after a particular debit value date, and payments of a particular status. Clean payments generated as a result of standing orders are not listed on this screen; you must use the Clean Payments from Standing Orders (SOPRQ) screen (described in the Clients and Accounts Administration Guide). From this screen you can link to the following screens: Outward Clean Payments Inquiry (CPAYI) - for inquiring on the details of a clean payment Outward Clean Payments Amendment (CPAYC) - for adding to or changing the details of a clean payment Clean Payments Authorise (CPAUT) - for authorising a clean payment Authorise Release of Event Messages (SETTA) - for reviewing or authorising related messages To link to one of these screens, click either the Details, Modify, Authorise or View Message buttons to go to the Outward Clean Payments Inquiry (CPAYI), Outward Clean Payments Amendment (CPAYC), Clean Payments Authorise (CPAUT) or Authorise Release of Event Messages (SETTA) screens respectively

144 Clean Payments The following figure is an example of the Clean Payments Inquiry by Product screen. Figure Clean Payments Inquiry by Product screen

145 Clean Payments Inward Clean Payments Screens Outbound S.W.I.F.T. Message Inquiry (MSGSI) This screen allows you to view the S.W.I.F.T. messages that have been received by your system from S.W.I.F.T. Use this screen to view the S.W.I.F.T. messages that have been rejected by the system (maybe because they are incomplete, or otherwise in error). Rejected messages can either be Reinstated or Closed. To see the reason for a rejection, use the Alert Queue (ALRTQ) screen, described in the Stock Exchange and Securities Administration Guide. To Reject a message, click the Reject/Reinstate button. This will only work on messages that are currently Open. It indicates that something is wrong with the message and must be corrected before processing. To Reinstate a message, click the Reject/Reinstate button. This will only work on messages that are currently Rejected. It indicates that the message is correct and can be processed. To Close a message, click the Close Message button. A closed message will not undergo any processing, and is removed from all settlement message queues. An Open or Rejected message can be closed. From this screen you can link to the following screens: Message Inquiry (MSGI) to view the S.W.I.F.T. message. To do this, click the Message Details button. Clean Payment Incoming Message Inquiry (CPINI) to process the S.W.I.F.T. message as a clean payment. To do this, click the Inward Inquiry button. This option can only be used for 'Closed' messages. When you link to this screen, the message will be displayed at the top of the inquiry list

146 Clean Payments The following figure is an example of the Outbound S.W.I.F.T. Messages Inquiry (MSGSI) screen. Figure Outbound S.W.I.F.T. Message Inquiry screen

147 Clean Payments Incoming Clean Payments Inquiry (CPINI) Use this screen to view S.W.I.F.T. MT101, MT103, and MT202 messages received by the system that relate to clean payments. This screen displays the S.W.I.F.T. messages arriving on a particular date. By entering any or all of Accounting Centre, Sender, Currency, Status and Source, the results can be filtered to find a particular set of S.W.I.F.T. messages. From this screen you perform the following functions on an inward clean payment: Link to Clean Payments Addition (CPAYA) You can link to this screen to add an inward clean payment into the system, with details of the inward clean payment pre-filled. To do this, Highlight an inward clean payment and click the Post button. Link to Outward Clean Payments Inquiry (CPAYI) If the inward clean payment has been added to the system, this allows you to view the related outward payment. To do this, highlight an inward clean payment and click the Contract button. Link to Outwards Clean Payments Amendment (CPAYC) If you have already entered an outward clean payment into the system, this allows you to link it to an inward clean payment. To do this, highlight an inward clean payment and click the Match button. Link to the Output from Message Inquiry (MSGI) You can link to this screen to view details of the incoming S.W.I.F.T. message. To do this, highlight an inward clean payment and click the View button. Mark an Incoming Clean Payment as Reject An incoming clean payment may be unsuitable for inputting into the system due to errors in the message. You can mark it as 'Reject' to show that there are problems with the message. To do this, highlight an inward clean payment and click the Reject button. The following figure is an example of the Incoming Clean Payments Inquiry (CPINI) screen

148 Clean Payments Figure Inward Clean Payments Inquiry screen

149 Clean Payments Output from Message Inquiry (MSGI) Use this screen to view the details of an incoming S.W.I.F.T. message. You can open this screen from the Incoming Clean Payments Inquiry (CPINI) screen. The following figure is an example of the Output from Message Inquiry (MSGI) screen. Figure Output from Message Inquiry screen

150 Clean Payments

151 Section 9 Nostro Transfers Introduction Nostro transfers cause funds to be transferred between two nostro accounts at different correspondent banks. Both nostros must be in the same currency, although the payment may be made in any currency. The NSXF Contract type used for nostros is supported by simple accounting models, allowing a nostro transfer to be related to an underlying contract or transaction. This is especially important when using the Continuous Linked Settlement (CLS) functionality, which uses nostro transfers to settle the balance. For more information on accounting models, see Setting Up Accounting Models in the Guide to Setting Up. The nostro transfer screens can only be used if the parameters, held on the S.W.I.F.T. Parameters (SWPTR) Table, indicate that S.W.I.F.T. messages may be generated (see the Guide to Interfaces with External Systems for details)

152 Nostro Transfers Nostro Transfer Screens This section provides a description of the following Nostro Transfer screens. Nostro Transfer Add (NSXFA) Nostro Transfer Reversal (NSXFR) Note: A list of all Nostro Transfer contracts, including those which have been reversed, may be obtained by running the Nostro Transfers List report (NSXFLST), see the On-Demand Reports Guide for details. For each screen the following is provided: A description of its use An example of the screen See the Starter s Guide for a description of how to access and use screens

153 Nostro Transfers Nostro Transfer Add (NSXFA) The Nostro Transfer Add screen is used to add Nostro Transfer contracts. This enables funds to be transferred between two nostro accounts at different correspondent banks, provided both nostros belong to the same accounting centre, are for the same currency and are S.W.I.F.T members in the same country. The contracts produce appropriate S.W.I.F.T. messages: MT200 or MT202, to instruct the Pay Nostro to transfer the funds MT210, to advise the Receiving Nostro that the funds are on their way. This message is only sent if the Nostro has a S.W.I.F.T address and the MT210 Advices Via S.W.I.F.T indicator, on the Nostro Details (NSTRO), is set to Yes. Otherwise, the advice is printed by ONPAPER A contract causes automatic account postings. It is not possible to enter Nostro Transfers any further forward than the number of Payment Advance Days for the particular country, nor is it possible to enter backvalued, or incomplete, contract details. Nostro transfers may be reversed (see the Nostro Transfer Reversal (NSXFR) screen). The following figure shows an example of the Nostro Transfer Add Screen. Figure 9 1. Nostro Transfer Add screen

154 Nostro Transfers Nostro Transfer Reversal (NSXFR) This screen is used to reverse existing nostro transfer contracts, entered on the Nostro Transfer Add (NSXFA) screen, provided that they have: Not already been reversed Not yet come to value. In order to reverse a transfer, you must enter the contract number (Reverse Contract Number) and Transfer Amount associated with the original transfer. The contract reversal produces two printed paper advices (one is sent to the bank from which the funds were to have been moved, the other to the Account With Bank). If the original message has already been sent, then the reversal will be paired with the original message, and both messages sent. Note: This screen cannot be accessed directly to perform nostro transfers generated from CLS (continuous linked settlement) processing. You must use the CLS Balance Inquiry (CLSBI) screen to select the currency and balance to reverse, before linking to the Nostro Transfer Reversal (NSXFR) screen to perform the reversal. See Section 11 for more information. The following figure shows an example of the Nostro Transfer Reversal screen. Figure 9 2. Nostro Transfer Reversal screen

155 Section 10 Netting of Contracts Introduction to Netting Netting is the process by which institutions and their clients mutually agree to replace the need to settle payments on an individual basis, for the same currency and value date, with a single combined settlement. Consequently settlement risk is reduced, with the added benefit of lower transaction costs due to the lower volume of settlements made. The compilation of the netting agreements within the system is completely flexible and will allow most payments to be included in a netting agreement (exceptions to this are clean payments, nostro transfers, securities, and OTC options). The settlement process itself also provides flexibility for the user to confirm or remove individual payments prior to the generation of the netted settlement. This section provides a description of the following screens: Setting up Netting Types Netting Type Maintenance (NTTYM) Netting Type to Product Linkage (NTTPM) Netting Type to Accounting Centre Linkage (NTBRM) Entering Netting Agreements Client Netting Agreements (NTAGM) Client Netting Agreement - Currency Cut Off Days (NTACM) Client Netting Agreement - Product (NTAPM) Authorising Netting Settlements Netted Settlements - Lead In (NETCN) Netted Settlements - Authorise (NETTA) Netting Inquiries Netting Agreements Inquiry (NTAGI) Netted Payments Inquiry (NETTI)

156 Netting of Contracts Setting up Netting Types Netting Types are set up to contain default values for netting settlements. This is useful for quickly entering netting agreements and to standardise settlements. A netting type contains the following information: Technical Details: for example Event/Contract. These values define how a netting settlement works. Obsolete Date: defines the date a netting agreement becomes obsolete. This is set up on the Netting Type Maintenance (NTTYM) screen. Product Type: defines which product types are allowed to be netted in a netting type. This is set up on the Netting Type to Product Linkage (NTTPM) screen. Accounting Centre: defines which accounting centres are allowed to use a netting type. These are set up on the Netting Type to Accounting Centre Linkage (NTBRM) screen

157 Netting of Contracts Netting Type Maintenance (NTTYM) Use this screen to define the characteristics of a netting type. This screen can be used to add, change or delete netting types. These defaults cannot be overridden for a client netting agreement, and any changes to a netting type on this screen will affect all instances of it. Note: With the current functionality of the system, the following fields are restricted: Novation/Settlement is restricted to Settlement and Comprehensive/Paired is restricted to Comprehensive. From this screen you can link to the Netting Type to Product Linkage screen where you define which product types are related to a netting type. To do this, click the Products button. The following figure shows an example of the Netting Type Maintenance (NTTYM) screen. Figure Netting Type Maintenance screen

158 Netting of Contracts Netting Type to Product Linkage (NTTPM) Use this screen to define the product types to be associated with a netting type. Only product types that are associated with a netting type can be used in a netting settlement. Each netting type can have any number of product types associated with it, and this screen will allow you to add or remove product types from a netting type. The following figure shows an example of the Netting Type to Product Linkage (NTTPM) screen. Figure Netting Type to Product Linkage screen

159 Netting of Contracts Netting Type to Accounting Centre Linkage (NTBRM) Use this screen to define which netting types are allowed for a particular accounting centre or location. If location netting is in operation, then a valid location code must be entered and the Accounting Centre field left blank. Conversely, if netting at accounting centre is in operation, the Location field must be left blank, and a valid accounting centre must be entered. Before an accounting centre or location is assigned to a netting type, ensure that it is allowed to settle netting payments by setting the Netting field on the Accounting Centre Maintenance (ACNTM) screen or Location Maintenance (LOCTM) screen to Yes. The Accounting Centre Maintenance (ACNTM) screen and Location Maintenance (LOCTM) screen are defined in the Guide to Setting Up. The following figure shows an example of the Netting Type to Accounting Centre Linkage (NTBRM) screen. Figure Netting Type to Accounting Centre Linkage screen

160 Netting of Contracts Entering Netting Agreements Before any netted settlements can be agreed between you and a client, a client netting agreement must be made. This defines the terms of the netting allowed for a client, and any changes to the default values of the agreement. A netting agreement is defined as follows: Client Shortname and City: the client s identification details. These are set up on the Client Netting Agreements (NTAGM) screen. Location or Accounting Centre: defines which location or accounting centre is to be used for the agreement. This is set up on the Client Netting Agreements (NTAGM) screen. Netting Type: defines which netting type is to be used for the agreement. This defines the basic details of how a netting will work. This is set up on the Client Netting Agreements (NTAGM) screen. Agreement Start and End Date: value dates that netting is valid between, based on the payment value date. These are set up on the Client Netting Agreements (NTAGM) screen. Default Currency Cut Off Days: defines the number of days prior to a value date that netting balances must be agreed. This applies to all currencies in an agreement. This is set up on the Client Netting Agreements (NTAGM) screen. Cut off Days, Cut off Time: defines new cut off date and time for a currency if they are different from the Default Currency Cut Off Days. This is set up on the Client Netting Agreement - Currency Cut Off Days (NTACM) screen. Product Type: defines product types that are allowed in a client netting agreement. These are set up on the Client Netting Agreement - Product (NTAPM) screen. Product types can also be removed from a netting type for an agreement. Only product types allowed to a particular netting type can be included in a client netting agreement. The product types allowed for a netting type are set up on the Netting Type to Product Linkage (NTTPM) screen

161 Netting of Contracts Client Netting Agreements (NTAGM) Use this screen to enter, maintain or delete a netting agreement with a client. A client can have any number of netting agreements arranged for them, covering different combinations of currency, location or accounting centre, netting type and agreement dates. You must complete this screen before any netting agreements can be made for a client. From this screen you can link to two other screens that must be completed when creating a client netting agreement. You can link to these screens as follows: Click the Cut Off Rules button to go to the Client Netting Agreement - Currency Cut Off Days (NTACM) screen. Click the Products button to go to the Client Netting Agreement - Product (NTAPM) screen. The Default Currency Cut-Off Days field is used to default the number of days prior to value date that you wish to agree netting balances. This default is then applied to the Cut-Off days field on the Client Netting Agreement - Currency Cut Off Days (NTACM) screen. Note: The Payment Days in Advance field on the Countries (CNTRY) screen still controls when settlement messages are produced. The following figure shows an example of the Client Netting Agreements (NTAGM) screen. Figure Client Netting Agreements screen

162 Netting of Contracts Client Netting Agreement - Currency Cut Off Days (NTACM) After establishing the client netting agreement, all currencies are included by default, as per the comprehensive Netting Type. All these currencies are assigned the Default Currency Cut-Off Days value as set on the Client Netting Agreement (NTAGM) screen. It is important to amend immediately the Cut-Off Days value for any currency for which the default does not apply. For Comprehensive netting types, you can: Exclude currencies not included by the client agreement. To do this, enter the details of the agreement in the Location or Accounting Centre, Client Shortname, City and Netting Type Identifier fields. Enter the name of the currency you want to delete in the Currency field and Click Delete. Alter the default currency cut off date. To do this, enter the details of the agreement in the Location or Accounting Centre, Client Shortname, City and Netting Type Identifier fields. Enter the name of the currency you want to change in the Currency field. Enter the new Cut off Days and Cut off Time in the appropriate fields. Click Change. Note: The Last Cut-Off Date is a display only field that shows the Value Date for the last occasion that a netting balance has been settled. The system uses this date to ensure that netting balances are processed in an orderly manner

163 Netting of Contracts The following figure shows an example of the Client Netting Agreement - Currency Cut Off Days (NTACM) screen. Figure Client Netting Agreement - Currency Cut Off Days screen

164 Netting of Contracts Client Netting Agreement - Product (NTAPM) This screen allows you to define which product types are allowed in each individual client netting agreement. These are then validated against the product types allowed for a netting type, set up on the Netting Type to Product Linkage (NTTPM) screen. The following figure shows an example of the Client Netting Agreement - Product (NTAPM) screen. Figure Client Netting Agreement - Product screen

165 Netting of Contracts Authorising Netting Settlements Once a client netting agreement has been entered, payments can be settled via netting. Two screens in the system allow you to select which individual payments to include in a netted settlement: Netted Settlement - Lead In (NETCN) Netted Settlement - Authorise (NETTA) The following flow chart shows the process of selecting individual payments to be included in a netted settlement: Contract Input, validation to see if suitable for netting. Contract Entered into the system Select nettable balance for processing Netting Settlements - Lead In (NETCN) Select individual payments to include in netting agreement Netted Settlements - Authorise (NETTA) Authorise Release of Event Messages (SETTA) Payments rejected for netting are moved to the settlements queue for processing Items Accepted and Processed Event messages for netted payments await authorisation Figure Flow Chart for Authorising Netting Settlements

166 Netting of Contracts Netted Settlements - Lead In (NETCN) This screen is used to view and select nettable balances that are due for settlement. All the unprocessed nettable balances for a selected location or accounting centre are displayed, grouped into settlements that can be netted together. To view the payments that are attached to the nettable balance, and to apply the relevant include/exclude and settlement decisions, you must link to the Netted Settlements - Authorised (NETTA) screen. To do this, highlight the group you are interested in. Click the Authorise button at the bottom of the screen. The Client Shortname and City, Netting ID, Value Date and Currency fields act as filters to help you find the specific group of nettable balances which interest you. After inquiring, a list of the groups of nettable balances meeting these filters will be displayed. All combinations of filters are allowed. The following figure is an example of the Netted Settlements - Lead In (NETCN) screen. Figure Netted Settlements - Lead In screen

167 Netting of Contracts Netted Settlements - Authorise (NETTA) This screen is used to apply decisions to each of the individual payments in a nettable balance prior to the creation of the netted contract. Any of the individual payments on this screen can be included or left out of the final netted contract. In the Select column the user can apply the following decisions: Yes (Y) - Include in the nettable balance. No (N) - Do not include in the nettable balance. Remove (R) - Remove from the nettable balance and send to the Outstanding Settlement Messages (SETCN)/Authorise Release of Event Messages (SETTA) screens for manual processing as an individual item. Send (S) - Remove from the nettable balance and return to the Outstanding Settlement Messages (SETCN)/Authorise Release of Event Messages (SETTA) screens, using STP, if possible. After the nettable balance and settlement instructions have been agreed, the user must set the Apply Decision and Cut-Off fields according to whether single or multiple netting is being used (single/multiple netting is set up on the System Parameters (SPMTR) screen): If single netting, then both the Apply Decision and Cut-Off fields must be set to Yes, as netting for the customer/currency/value date can only be performed once. If multiple netting, then only set the Apply Decision to "Y" to produce a netted contract for the payments selected. Setting the Cut-Off field to "Y" signifies that no further netting will be possible for the customer/currency/value date combination. The contract number for the netted contract (contract type NETT) will appear as part of the status bar at the foot of the screen. The user must now use the Outstanding Settlement Messages (SETCN)/Authorise Release of Event Messages (SETTA) screens to send the appropriate settlement message (MT210 or MT202). If Location netting is being used, the Accounting Centre is the main Accounting Centre for a location

168 Netting of Contracts The following figure shows an example of the Netted Settlements - Authorise (NETTA) screen. Figure Netted Settlements - Authorise screen

169 Netting of Contracts Netting Inquiries Overview of Netting Inquiries If you know the Netting Identifier, the following netting screens can be used to inquire on relevant details: Netted Payments Inquiry (NETTI) Netting Type to Product Linkage (NTTPM) Netting Type Maintenance (NTTYM) Netting Type to Accounting Centre Linkage (NTBRM) Client Netting Agreements (NTAGM) Client Netting Agreement - Currency Cut Off Days (NTACM) Client Netting Agreement - Product (NTAPM) When using these screens you should input the Netting Identifier first. When you then select from a field with a drop down list box, only relevant field entries will be displayed. For example on the Netting Type to Product Linkage (NTTPM) screen, after selecting the Netting Identifier, the drop down list box for Product Type will only include those product types linked to that Netting Identifier. On some screens, there is an indicator that allows you to bypass this facility, and view all of the information in a drop down list. Switching the indicator 'On' immediately allows you to view all information relevant when you select the drop down list. The following screens are affected: Client Netting Agreement - Product (NTAPM), Display all Products and Display all Netting Identifiers Netting Type to Accounting Centre Linkage (NTBRM), Display all Accounting Centres and Display all Netting Identifiers Client Netting Agreement (NTAGM), Display all Netting Identifiers Use the Netting Agreements Inquiry (NTAGI) screen if you do not know the Netting Identifier for the netting agreement you are inquiring on

170 Netting of Contracts Netting Agreements Inquiry (NTAGI) You can use the Netting Agreements Inquiry (NTAGI) screen to inquire on netting agreements by Location or Accounting Centre, Client Shortname and City, or Netting Identifier. To navigate through to other linked screens, select the required netting agreement, and choose one of the following options: Click Included Products to link to the Client Netting Agreement - Product (NTAPM) screen. Click Currencies to link to the Client Netting Agreement - Currency Cut Off Days (NTACM) screen. Click Maintain to link to the Client Netting Agreements (NTAGM) screen. The following figure shows an example of the Netting Agreements Inquiry (NTAGI) screen. Figure Netting Agreements Inquiry screen

171 Netting of Contracts Netted Payments Inquiry (NETTI) The Netted Payments Inquiry (NETTI) screen gives a summary of all payments included within the netted payment. The inquiry can be restricted by currency. This screen can only be accessed from the Authorise Release of Event Messages (SETTA) screen or the Authorise Release of Event Messages for LA Participants (SETTB) screen (for LA Commercial Loans contracts) and only if the contract being viewed is a consolidated netting contract. The following figure shows an example of the Netted Payments Inquiry (NETTI) screen. Figure Netted Payments Inquiry screen

172 Netting of Contracts

173 Section 11 Continuous Linked Settlement Screens Introduction This section provides a description of the following continuous linked settlements screens. For more information on Continuous Linked Settlement, see Section 1. CLS Provider Detail Maintenance (CLSDM) CLS Counterparty Maintenance (CLSCM) CLS Currency Maintenance (CLSCY) CLS Balance Inquiry (CLSBI) CLS Balance Breakdown Inquiry (CLSCI) For each screen the following is provided: A description of its use An example of the screen A full description of the fields on the screens, and valid entries, is given in Section 12, Definition of Field Names. Please refer to the Starter s Guide for a description of how to access and use screens

174 Continuous Linked Settlement Screens CLS Maintenance Screens CLS Provider Detail Maintenance (CLSDM) This screen allows you to enter and inquire on information related to the provider of the Continuous Linked Settlement (CLS) service. A record can be created for one of the following: An accounting centre A location. If a record is entered for a location, it will be automatically applied to all accounting centres related to that location. For all locations and accounting centres. If "********" is entered in the Accounting Centre field, then the record will apply to all locations and accounting centres. Whenever a change is made to the CLS details on this screen, then the CLSCHANGE CLS Update report should be run. This will update all affected contracts with the new details. This report is described in the On-Demand Management Reports Guide. When changing or deleting a record, this report can be initiated from this screen, after the changes have been made. To do this, switch 'On' the "Update Affected Deals" field. Adding a Record When adding a record, you must enter the Start Date, and either the Accounting Centre or Location. The S.W.I.F.T. Address, Name, Address Line, and Cut Off Time are also mandatory. Before the record can become active it must be authorised. To do this, enter the record into the system by clicking the Add button. A user who has authorisation access can now authorise the record by inquiring on the record and clicking the Authorise button. Changing a Record Once a record has been authorised, it can only be changed by someone who has authorisation access. The Start Date, Accounting Centre, and Location of the record cannot be altered during a change. Entering an End Date will stop CLS processing for this provider from this date (the value date of the CLS contract is used for calculating the cut-off point). Inquiring on a Record To inquire on a record, enter Start Date and either the Accounting Centre or Location. The record displayed will be the record with the closest Start Date before the date inquired upon. Deleting a Record The record can be deleted by clicking the Delete button. When deleting an authorised record, the Update Affected Deals field must be switched 'On', any contracts using this provider will be removed from CLS processing

175 Continuous Linked Settlement Screens The following figure shows an example of the CLS Provider Detail Maintenance screen: Figure CLS Provider Detail Maintenance screen

176 Continuous Linked Settlement Screens CLS Counterparty Maintenance (CLSCM) This screen allows you to maintain the clients with which you will settle using the CLS functionality. You can also use this screen to inquire on the clients that have already been entered. Whenever a change is made to the CLS details on this screen, then the CLSCHANGE CLS Update report should be run. This will update all affected contracts with the new details. This report is described in the On-Demand Management Reports Guide. The report can be initiated from this screen, either in Inquiry mode or Update mode using the Run CLSCHANGE Report field. Adding a Client To add a client to the list, enter the client's Shortname and City, also enter the Start Date and the End Date. Then switch 'On' the Select field adjacent to the client and click the Add button. The client will be entered on the list, but cannot be used until authorised. A user who has authorisation access must inquire on the client details and authorise the client. To do this, switch 'On' the Select field adjacent to the client, and click the Authorise button. The client must have a SWIFT Address defined for them on the Client Details Banking (CIWSL) screen (see the Clients and Accounts Administration Guide). Changing and Deleting a Client Once a client has been authorised, only a user with authorisation access can change any details. Only the Start Date and End Date can be altered. The client is removed from the list once the End Date has been reached. Inquiring on Client Records To inquire on the clients listed on this screen, click the Inquire button. The inquiry can be limited by using the Start Shortname, Show Unauthorised Only, and Show All Available Clients fields

177 Continuous Linked Settlement Screens The following figure shows an example of the CLS Counterparty Maintenance screen: Figure CLS Counterparty Maintenance screen

178 Continuous Linked Settlement Screens CLS Currency Maintenance (CLSCY) This screen allows you to maintain the currencies that can be used by the CLS functionality. You can also use this screen to inquire on the currencies that have already been entered. Whenever a change is made to the CLS details on this screen, then the CLSCHANGE CLS Update report should be run. This will update all affected contracts with the new details. This report is described in the On-Demand Management Reports Guide. The report can be initiated from this screen, either in Inquiry mode or Update mode using the Run CLSCHANGE Report field. Adding a Currency To add a currency to the list, enter the Currency, the Start Date, and the End Date. Then switch 'On' the Select field adjacent to the currency and click the Add button. The currency will be entered on the list, but cannot be used until authorised. A user who has authorisation access must inquire on the currency and authorise. To do this, switch 'On' the Select field adjacent to the currency, and click the Authorise button. Changing or Deleting a Currency Once a currency has been authorised, only a user with authorisation access can change any details. Only the Start Date and End Date can be altered. The currency is removed from the list once the End Date has been reached. A currency can also be removed from the list by changing the Start Date and End Date to zero. Inquiring on Currency Records To inquire on the currencies listed on this screen, click the Inquire button. The inquiry can be limited by using the Start Currency field

179 Continuous Linked Settlement Screens The following figure shows an example of the CLS Currency Maintenance screen: Figure CLS Currency Maintenance screen

180 Continuous Linked Settlement Screens CLS Inquiry Screens CLS Balance Inquiry (CLSBI) This screen allows you to perform the following functions: Inquire on the outstanding balances for each accounting centre and location on any selected Value Date. The balances can be shown for each CLS currency using the bought or sold amounts, or combined to total balance. To do this, click the Inquire button. For more information on the individual contracts that comprise a currency balance, click the Contract button. The CLS Balance Breakdown Inquiry (CLSCI) screen will be displayed. Create a single posting for outstanding balance to the listed nostro. To do this, highlight a currency and click the Settle button. Create a single posting for outstanding balance to the listed nostro, and generate settlement messages to transfer funds to or from your CLS nostro. To do this, highlight a currency, and click the Transfer button. The Nostro Transfer Add (NSXFA) screen will be displayed, with the currency, amount of transfer, and the listed nostro displayed. You can then enter the nostro that the postings will be transferred to. Notes: If contracts for the same currency settle to different nostros, then the Settle option cannot be used. Instead each contract must be settled to the appropriate nostro individually. Alternatively, the nostros of the contracts can be changed to the same nostro. For institutions that use the Settlement Instructions Confirmation (AWSTI) and Deals Input Confirmation (AWBOI) screens, then a contract will only be displayed on the CLS Balance Inquiry (CLSBI) screen when it has been removed from one or both of these screens

181 Continuous Linked Settlement Screens The following figure shows an example of the CLS Balance Inquiry screen: Figure CLS Balance Inquiry screen

182 Continuous Linked Settlement Screens CLS Balance Breakdown Inquiry (CLSCI) This screen allows you to view the individual contracts that comprise an outstanding balance. Either enter the Location, Currency, and Value Date, or link to this screen from the CLS Balance Inquiry (CLSBI) screen. You can limit the inquiry by entering any of the Balance Type, Counterparty, and City fields. From this screen you can link to the following screens: A relevant contract inquiry screen for further information on a contract. To do this, highlight a contract and click the Contract Inquiry button. A relevant contract change screen to change the details on a contract. This could involve moving the contract out of the CLS process. To do this, click the Contract Change button. The following figure shows an example of the CLS Balance Breakdown Inquiry screen: Figure CLS Balance Breakdown Inquiry screen

183 Section 12 Definition of Field Names Introduction This section provides a definition of all the field names on settlements and queue screens. The fields are listed alphabetically and details of valid entries are given. If the field is pre-filled with a value on the screen, or defaults to a value if left blank, these values are also given. Many of the codes and mnemonics given in this section may be changed when the system is installed at your bank. Table Definition of Field Names Field Account Account at Central Bank Account Number Definition This field can be found on an MT103 and MT202 S.W.I.F.T. message and contains details relating to the Account of the person or institution displayed to the left. For an exact definition of this field refer to the S.W.I.F.T. documentation. On the LA Fee Settlement Confirmation (LARSM) and LA Fee Settlement Authorisation (LAFAM) screens, this is the account for the fee settlement. On the Depot screens, this refers to a particular account at a depository. With the Depot and Sub-Account, it defines the custody location of a security at a depot. This field can be defaulted from information defined on the Depot Defaults (SPSTM) screen. This is a free format field that you can use for own requirements. For example, you could use it to hold the account number of a central bank. On the Default Paper Settlement (SPSTM) screen, this is the number of the account at the depot that is used when a paper settlement is performed. On the Paper Settlement Confirmation (SPSTI) screen, this field initially displays the number of the settlement account at the depot. This account is the one used as standard for the contract. If necessary, this field can be overwritten so that another account is used

184 Definition of Field Names Field Account With Bank Accounting Centre Accounting Model Amounts Acknowledged Definition This field can be found on MT103 or MT202 S.W.I.F.T. messages. For an exact definition, refer to the S.W.I.F.T. documentation. This is an eight character code that identifies an Accounting Centre. It is set up on the Accounting Centres Maintenance (ACNTM) screen. For Nostro Transfer screens, this is the transaction accounting centre. It is a display only field on the Reversal screen. On the Depot Defaults screens, this defines the accounting centre this default setting will apply to. If '*******' is entered in this field, then this default will apply to all accounting centres. On the CLS screens, this is the accounting centre for which you are defining CLS details. Entering "**********" in this field will apply the CLS details to all accounting centres. This field should not be used if the Location field is entered. See Continuous Linked Settlement in Section 11 of this guide for more information. These are the amounts set up for the diary event/contract type combination on the Accounting and Exposure Amount Parameters (ACEXM) screen. They represent subdivisions of the settlement amount for the event. When you first access the Accounting Authorisation (ACATM) screen, expected amounts are displayed. The total of these amounts gives the Expected Amount. You can overwrite the accounting model amounts to record the amounts actually received. The Accounting and Exposure Amount Parameters (ACEXM) screen is documented in the Guide to Setting Up. This is the status of the S.W.I.F.T. message. It can be one of: ACK: Acknowledged. The message has been sent and an acknowledgement received. NAK - Not Acknowledged. The message has been sent, and S.W.I.F.T. has rejected it and returned it. SBU: - Sent but Unacknowledged. The message has been sent, but no acknowledgement has been received. NST: - The message has not been sent

185 Definition of Field Names Field Action Definition This indicates whether the message is to be deleted, viewed, authorised or resent/reprinted: Delete (D) - to delete the message Netting Inquiry (C) - to link through to the Netting Inquiry (NETTI) screen Non Standard Instructions (I) - to link through to the Non Standard Instructions (NSTDM) screen (not used for Loans Administration contracts). Participants (B) - to link through to the Authorise Release of Event Messages for LA Participants View (V) - to view details of the message on the Settlement Message Review and Repair (MESSR) screen Send (S) - to authorise the message for printing/sending for the first time Resend/Reprint (R) - to authorise the message for sending/printing even though it has already been sent/printed Blank - Not Authorised, select this if a message was Actual Amount Actual Date On the Authorise Release of Event Messages (SETTA) screen, you can also enter Participants (P) to link to the Authorise Release of Event Messages for LA Participants (SETTB) screen. On the S.W.I.F.T. CASmf Interface Inquiry (CASMI) screen, this is a display field showing the action carried out on the S.W.I.F.T. message. It can be Send, Read, Open or Close. On the LA Client Settlement Instructions Authorisation Queue (CDATI) screen, this field shows the last action performed on a record awaiting authorisation. This can be Add, Chg (Change), or Del (Delete). This is the actual amount paid or received at the diary event displayed. When you enter the actual amount on the Accounting Authorisation Queue (ACQUE) screen, it can differ from the Expected Amount. This is the actual date that the instrument is delivered or received, this may differ from the value date. Add PDE This field indicates whether the message is possibly a duplicate (a S.W.I.F.T. PDE). This is currently used for documentary purposes only. Address The mailing address of the CLS provider. Addresses CHAPS CHIPS FEDWIRE S.W.I.F.T. TELEX The identification numbers and telex code of the funds and message switching systems shown. All addresses, except S.W.I.F.T., are recorded for documentary purposes only. For S.W.I.F.T., the address must be either 8 or 11 characters in length. The first six characters must be alphabetic

186 Definition of Field Names Field Agent Agent Identifier Agent Agent's Address Agent's Full Name Agreement End Date Agreement Start Date All Currencies Definition On the Client Settlement Instructions for LA (CISIM) screen, this field is used for entering a default pay agent or receive agent. If the instructions are being set up for a payment, then [RCV] will be displayed after the field name to indicate that you are defining the receiving agent. If the instructions are being set up for a receipt, then [PAY] will be displayed after the field name to indicate that you are defining the pay agent. This is the nickname of the agent. Agent nicknames are defined on the Agent Details (AGNTM) screen. On the Agent Settlements Defaults (AGDFM) screen, this is the pay or receive agent that will be defaulted on to a deal entry screen when the counterparty, currency of settlement and accounting centre are known. On the Accounting Authorisation (ACATM) screen, this represents the agent associated with the settlement. The address of the agent to which paper mail should be sent. This field contains the full name of the agent related to that contract. Agent details are set up on the Agent Details (AGNTM) screen. This field contains the date when a client netting agreement is due to end. After this no netting is allowed for the client unless it is covered by a new, or different existing client netting agreement. If the netting type used in the agreement reaches its Obsolete Date before the Agreement End Date, then the agreement is terminated. This field contains the date from which a client netting agreement is valid. Switch 'On' this field to create a nostro record for each currency. Each record will have a different currency, but the rest of the values on this screen will be the same. When nostro records are created in this way, they can be authorised in bulk using the 'Authorise All Currencies' field

187 Definition of Field Names Field Amount Apply Netting Apply to All Contracts As At Date As At Date Movement Definition This is the principal, or nominal, amount of the contract. It is only displayed on the settlement queues if the contract has a principal or nominal. For Foreign Exchange market deals, the deal amount is displayed. For the Paper Settlement Authorisation Queue (PSQUE) screen, this is the nominal of the contract. For customer transfers, this is the amount to be debited (which may include charges and commission together with the transfer amount) and the amount to be credited (transfer amount). On the clean payment screens, this is the fixed amount of a clean payment transfer. On the LA Fee Settlement Confirmation (LARSM) screen, this is the amount of the payment. On the CLS screens, this is the amount of the event posting. When you have decided which payments to include in a netting authorisation, set this field to apply the netting. Yes - Apply the netting authorisation as seen on screen No - Do not apply the netting authorisation seen on screen when the screen is closed. Override - If, after selecting 'Yes' as above, new information is entered into the system that is relevant to the current authorisation, you can ignore this information and leave the authorisation as it was by selecting 'Override'. Switching Apply to All Contracts on forces defaulted settlements with the same keys to use these defaults from the entered start date. Switching this field off denotes that only contracts input on or after the start date may use these defaults. On the Depot Account Holdings Position Inquiry (DEPSI) screen, this shows you the holdings position on this date. The inquiry will only include holdings with an input or value date before the entered as at date. The Date Indicator field controls whether Input Date or Value Date is used. Future dated trades will be included in the Future Movement amount. This is the total movement in the holding of the security on the date defined by the 'As At Date'. As At Date Net Holding Authenticator Key Held The net holding of the security on the date defined by the 'As At Date' field. This only includes transactions whose Value or Input date is before the As At Date. The Date Indicator field controls whether Input Date or Value Date is used. This field indicates that your institution has exchanged authenticator keys with the agent's institution, authorising you to exchange funds

188 Definition of Field Names Field Authorisation Limit Authorisation Status Definition The limit, defined for each clean payment product type, under which a clean payment does not need to be authorised. If this is not entered, the limit is set by the blueprint parameter BP-CP- AUTH-LIMIT. This display field shows the status of the default currently being displayed. The following statuses can be displayed: Authorised Unauthorised Rejected End Date Unauthorised End Date Rejected Authorise On the LA Fee Settlement Authorisation (LAFAM) screen, this field is used to authorise fee settlements with a specified authorisation status. The possible statuses are: Payment Only (P) Payment and Accounting (A) Waiting (blank on text-based system) Authorise All Currencies Bad Debt Bad Debts Balance Balance Override If a group of nostros has been created using the "All Currencies" option on this screen, then they can be authorised as a group using this field. Switch 'On' this field and click Authorise to authorise all the nostros. This shows whether the payment is for a contract that is a bad debt. If a "Y" is in this field, then the payment is a bad debt. Switch 'On' this field to limit the inquiry to payments that are bad debts. Switch 'Off' this field to display all payments. This is the total amount of all the netting payments currently included in the netting agreement. On the CLS screens, this is the total balance of all contracts on the Value Date. The contracts included in this amount are controlled by the 'Balance Type' field. A balance check is performed on the clean payment before it can be processed. If this check is failed, a warning will be displayed, and you must either override the warning, or stop the authorisation. This can either be: Yes (Y) - Override the warning and pass the payment No (N) - Do not pass the payment Failed (F) - This is displayed if the balance check produced a warning, and must be change to either Yes or No

189 Definition of Field Names Field Balance Type Bank Bank Operation Code Bank to Bank Information BEI SWIFT Address Beneficiary Beneficiary Account Number Beneficiary Address Beneficiary Bank Beneficiary Customer Beneficiary Name BIC Code CASmf Status Definition This displays the contract amounts that will be included in the CLS balance for each currency. Enter either: Bought only include bought amounts Sold only include sold amounts Total include all bought and sold amounts. On the Client Settlement Instructions for LA (CISIM) screen, this is the default beneficiary's bank. This field can be found on MT103 S.W.I.F.T. messages. For an exact definition, refer to the S.W.I.F.T. documentation. This field can be found on MT103 or MT202 S.W.I.F.T. messages. For an exact definition, refer to the S.W.I.F.T. documentation. Switch 'On' this field if the agent is not a bank. Switch 'Off' this field if the agent is a bank. This is the S.W.I.F.T. ID of the beneficiary of the inward message. Entering this field limits the inquiry to messages sent by this S.W.I.F.T. ID. On the Client Settlement Instructions for LA (CISIM) screen, this is a free-format optional field for entering a default beneficiary Account Number. On the Client Settlement Instructions for LA (CISIM) screen, this is a free-format optional field for entering a default beneficiary address. This field can be found on an MT202 S.W.I.F.T. message. For an exact definition, refer to the S.W.I.F.T. documentation. This field can be found on an MT103 S.W.I.F.T. message. For an exact definition, refer to the S.W.I.F.T. documentation. On the Client Settlement Instructions for LA (CISIM) screen, this is a free-format optional field for entering a default beneficiary name. This field is used to enter Bank Identification Codes (BIC codes). BIC Codes can be searched using the BIC Directory window. This feature is only available on the Graphical User Interface (GUI). This field indicates the status of a sent S.W.I.F.T. message. It can be either: ACK: Acknowledged. The message has been sent and an acknowledgement received. NAK - Not Acknowledged. The message has been sent, and S.W.I.F.T. has rejected it and returned it. SBU: - Sent but Unacknowledged. The message has been sent, but no acknowledgement has been received. NST: - The message has not been sent

190 Definition of Field Names Field Change Complete CHAPS BIC Routing Code CHAPS Sort Code Definition When you have finished changing the clean payment details, you must confirm that the change is complete. To do this, switch 'On' this field and click Ok. For contracts that are to be using the CHAPS messaging system instead of S.W.I.F.T. for settlement messages, this is the CHAPS destination address. See CHAPS in Section 1 for more information. The Clearing House Automated Payments system address code Charge Amount/Currency This covers the following charge details: The amount of the charge associated with the customer transfer The currency of the charge Charge Method City City of Residence Client Number This indicates which party is to bear the cost of charges associated with the customer transfer: Beneficiary (BEN) Bank (OUR) Shared (SHA) On the Agent Details (AGNTM) and Agent Inquiry (AGNTI) screens, this is the mnemonic of the agent's city of residence. On the Authorise Release of Event Messages (SETTA), Authorise Release of Event Messages for LA Participants (SETTB) and Paper Settlement Confirmation (SPSTI) screens, this is the city of residence of the counterparty. On the CLS screens, enter the city where the client that is to be included for CLS processing is registered. This must be entered in combination with the Shortname. The City is entered on the Client Details Banking (CIWSL) screen, described in the Clients and Accounts Administration Guide. City mnemonics are set up on the General Purpose Narratives table (GNARR), type CI. The mnemonic of the city of residence for the nostro. City mnemonics are defined on the General Purpose Narratives table (GNARR), type CI. This is the client number of the client created to represent this custodian or depository. See Adding a Client in the Client and Accounts Administration Guide for more information

191 Definition of Field Names Field Client Shortname Client Shortname/City Definition The shortname that represents a client. Client Shortnames are defined on the Client Details Banking (CIWSL) screen. In the case of the Authorise Release of Event Messages (SETTA), Authorise Release of Event Messages for LA Participants (SETTB) and Outstanding Settlement Messages (SETCN) screens, this is the shortname of the client with whom the contract has been made. On the Accounting Authorisation (ACATM) screen, this represents the client for the deal to which the displayed event belongs. On the Paper Settlement Authorisation Queue (PSQUE), this is the counterparty from whom, or to whom, paper associated with the event should be delivered. On the Nostro Settlement Defaults (NSDFM) screen, this is the client for which the nostro default applies. On the Depository Maintenance (CSDM) screen, this is the client shortname of the client created to represent this custodian or depository. See Adding a Client in the Client and Accounts Administration Guide for more information. This is the client shortname and city of the client who has taken out the contract. CLS Cut-off Time (Local) CLS End Date CLS Start Date This field controls the cut-off time after which the CLS provider will no longer accept a CLS confirmation for inclusion in next days settlement. This time could be set to, for example, the time overnight runs are made at your institution. This report is described in the On-Demand Management Reports Guide. The date on which the CLS functionality for this client or currency is made inactive. This field can be left blank, if there is to be no end date for CLS for this client or currency. The date from which the CLS functionality will be available for this client or currency. The CLS functionality will only be available from this date if the Status is 'Authorised'. Changing this field date to will immediately make the client or currency inactive. Commission Amount/Currency Comprehensive /Paired This covers the following commission details: The amount of the commission associated with the customer transfer The currency of the commission This field defines which currencies are included in a client netting agreement. Comprehensive netting types cover all currencies, Paired netting types cover only two currencies. Currently only the Comprehensive option is supported by the system, so all Client Netting Agreements must be set to this

192 Definition of Field Names Field Confirm Confirmation Date Confirmation Days Advance Confirmation/ Payment Consideration Contract Definition This field enables you to confirm the details displayed: On the Accounting Authorisation (ACATM) screen, switch on to confirm the Accounting Model Amounts match those actually received. On the Paper Settlement Confirmation (SPSTI) screen, switch on to confirm the details displayed match the actual settlement details for the event. This indicates when the fee settlement was confirmed using the LA Fee Settlement Confirmation (LARSM) screen. This indicates when confirmation messages are produced. This could be on or a number of days before the settlement date, as specified on the Countries (CNTRY) screen. Indicates whether the settlement message, whose details are displayed, is a Confirmation (C) or Payment (P). This is the amount that you pay or receive for the Nominal displayed. The contract number of the contract. Contract Number Contract Type Contract Counterparty Counterparty City The number of the contract whose details are displayed. It is a unique reference number that identifies a contract, customer transfer, nostro transfer or nostro transfer reversal. This is a four character code representing a type of contract. For example FXMK represents a Foreign Exchange market deal. The codes are given on the General Purpose Narratives (GNARR) table, type CN, (see the Guide to Setting Up). Use the General Purpose Narratives Inquiry (GNARI) to view a list of contract types. On the Deals Input Confirmation (AWBOI), Settlement Instructions Confirmation (AWSTI) and Outstanding Settlement Messages (SETCN) screens, enter a contract type to restrict the contracts displayed to those of the specified type. On the Paper Settlement Authorisation Queue (PSQUE) screen, enter a contract type to restrict the contracts displayed to those of the specified type. This may be a securities contract type only. Enter a client shortname in this field to limit the inquiry to contracts that have this client as the counterparty. The city field must also be entered. This is the mnemonic of the city of the counterparty to which settlement instructions apply. City mnemonics are defined on the General Purpose Narratives table (GNARR), type CI

193 Definition of Field Names Field Counterparty Name Country Country Check Code Country of Residence Create MT103 Definition On the Agent Settlement Defaults (AGDFM) screen, this is the shortname of the counterparty to which standard settlement instructions apply. This, together with the Counterparty City, forms a unique identifier. On the Paper Settlement Confirmation (SPSTI) screen, this is the shortname of the counterparty to whom, or from whom, paper should be delivered. On the Authorise Release of Event Messages (SETTA) and Authorise Release of Event Messages for LA Participants (SETTB) screens, this is the shortname of the client with whom the contract has been made. Shortnames for counterparties are defined on the Client Details - Banking (CIWSL) screen. On the BIC Directory window (available on the GUI only), this field is used to restrict searches by country. The two-letter S.W.I.F.T. country code, defined on the Countries (CNTRY) screen, is used. This is used to define the days when the depository is on holiday, which is used to calculate scheduled event dates for contracts Country check codes are set up on the Country Check Codes (CNCHK) screen, described in the Guide to Setting Up. The mnemonic of the country in which the agent is currently based. Countries are defined on the Countries (CNTRY) table, see the Guide to Setting Up. This field shows if you want to create an MT103 message for this clean payment. Yes - Create MT103 No - Do not create MT103 Note: If the Select MT103 field is not switched on for the System Parameters (SPMTR) screen, then MT103 messages cannot be created. However MT100 messages can be created for clean payments by switching on the Create MT100 field. Create MT202 Credit Account Credit Agent Credit Amount Credit Currency On the Clean Payments Addition (CPAYA) screen, this field shows if you want to create an MT202 message for this clean payment. Yes - Create MT202 No - Do not create MT202 The account that a clean payment is to credit. The agent controlling the account that a clean payment is to credit. The amount to be credited to the credit account. The currency of the credit account

194 Definition of Field Names Field Credit Intermediary Agent Credit Narrative Code Credit Posting Narrative Credit Value Date Currency Currency/Instructed Amount Custody Location Cut Off Date Definition If an MT103 message is created with the clean payment, the details you enter in this field will be applied to the field Intermediary on the MT103 message. This is a documentary field where you can store additional information about the credit side of the clean payment. This is in the form of a narrative description taken from the General Purpose Narrative (GNARR) table type ST. This is a documentary field where you can store additional information about a clean payment, specifically related to the credit side of the payment. The date on which a clean payment is credited to the credit account. This can be forward of the as-of date. The maximum number of days forward you may date a posting is determined at installation. For postings, if you do not enter a value date, the as-of date is used. The mnemonic of a currency. This is set up on the Currencies (CCYS) table. For the Deals Input Confirmation (AWBOI) and Settlement Instructions Confirmation (AWSTI), Accounting Authorisation Queue (ACQUE) and the Accounting Authorisation (ACATM) screens, this is the contract currency. On the Paper Settlement Authorisation Queue (PSQUE), this is the currency of the nominal displayed. For the Authorise Release of Event Messages (SETTA) and Authorise Release of Event Messages for LA Participants (SETTB) screens, this is the currency of the amount related to the event displayed. For the Nostro Transfer (NSXFA) and the Nostro Transfer Reversal (NSXFR) screens, this is the transaction currency. It is a display only field in the Reversal screen. On the Depot Defaults screens, this field defines the currency this default setting will apply to. If '****' is entered in this field, then this default will apply to all currencies. This field can be found on MT103 S.W.I.F.T. messages. For an exact definition, refer to the S.W.I.F.T. documentation. This is the current location where the security is held. This includes the Depot, Account, and Sub-Account. This field contains the date after which the payment cannot be included in a netting agreement. This is controlled by the Default Currency Cut Off Days field and the Cut Off Days field and is defined as the Value Date minus the Cut Off Days. The Cut Off Days field is found on the Client Netting Agreement - Currency Cut Off Days (NTACM) screen. The Default Currency Cut Off Days field is on the Client Netting Agreements (NTAGM) screen

195 Definition of Field Names Field Cut Off Days Cut Off Time Cut-Off Date Date Indicator Debit Account Debit Agent Debit Amount Debit Currency Debit Narrative Code Debit Posting Narrative Definition This field alters for a single currency the default currency cut off days, set on the Client Netting Agreement (NTAGM) screen. The Cut Off Days field defines how many days before the value date of a payment that the payment cannot be included in a netting authorisation. For example setting cut off days to 3 means a payment cannot be included in a netting authorisation in the three days before its value date. This field is for future functionality of the system. This field indicates whether any more netting authorisations can be made for a particular client, city, value date combination during that day. This can be either: Yes (Y) - Allow other netting authorisations during this day. No (N) - Do not allow any more netting authorisations for this client for this day. Override (O) - While making a netting authorisation, another payment is added to the system that could be included in the netting authorisation. Selecting 'Override' will allow you to proceed, without including the new payment. This is the date that the S.W.I.F.T. message was sent from or received by the system. On the Non Standard Settlement Instructions (NSTDM) screen, this is the date of the specific diary event for which you are setting up non standard instructions. On the Depot Holdings Transaction Inquiry (DEPCI) screen, this shows the Input or Value Date of the contract, depending on the value defined in the 'Date Indicator' field. This controls what transactions will be included in the holdings information displayed on the screen. If 'Input Date' is selected, then only transactions whose Input Date is before the 'As At Date' will be included in the inquiry. If 'Value Date' is selected, then only transactions whose Value Date is before the 'As At Date' will be included in the inquiry. The account that a clean payment is to debit. The agent controlling the account that a clean payment is to debit. The amount to be debited from the debit account. The currency of the debit account. This is a documentary field where you can store additional information about the debit side of the clean payment. This is in the form of a narrative description taken from the General Purpose Narrative (GNARR) table type ST. This is a documentary field where you can store additional information about a clean payment, specifically related to the debit side of the payment

196 Definition of Field Names Field Debit Value Date Default Address Default Currency Cut-Off Days Default Ordering Bank Indicator Default Ordering Customer Indicator Default Senders Correspondent Bank Identifier Definition Valid On and After Delivery / Receive Indicator Definition The date on which a clean payment is debited from the debit account. This can be forward of the as-of date. The maximum number of days forward you may date a posting is determined at installation. For postings, if you do not enter a value date, the as-of date is used. This defines the address type for the agent to be included in the "Intermediary" field on the MT103 message. These addresses are defined for different transmission methods, for example S.W.I.F.T., Fedwire or Chaps. Addresses for agents are set up on the Agents Maintenance (AGNTM) screen. The values in this field are contained on General Purpose Narrative (GNARR), table type AT. See the Guide to Setting Up for more information. This field defines how many days before the value date of a payment that the payment cannot be included in a netting authorisation. For example setting cut off days to 3 means a payment cannot be included in a netting authorisation in the three days before its value date. This is applied to every currency in a client netting agreement, unless overridden on the Client Netting Agreement - Currency Cut Off Days (NTACM) screen. This field defines whether the accounting centre of the account debited during the clean payment will be transferred to the S.W.I.F.T. BIC Address field on the MT103 message. This is only relevant if the accounting centre of the account being debited is different from the accounting centre of the nostro client account. On - Use accounting centre in S.W.I.F.T. BIC Address Off - Do not use accounting centre in S.W.I.F.T. BIC Address This field defines whether the Account Long Name of the account debited during the clean payment will be transferred to the Ordering Customer field on the MT103 message. On - Use account long name in ordering customer field Off - Do not use account long name in ordering customer field This field defines whether the Client Account number of the account debited during the clean payment will be transferred to the Senders Correspondent Bank field on the MT103 message. On - Use client account in Senders Correspondent Bank field Off - Do not use client account in Senders Correspondent Bank field When a date is entered in this field, and an inquiry submitted, then any contract that has a 'Start Date' after this date will be highlighted with green text. This indicates whether the instrument displayed has been or will be DELIVERED or RECEIVED on the value date shown

197 Definition of Field Names Field Depository Depository Type Depot Depot Identifier Depot Name Description Destination Destination Branch Destination/Sender Details Definition This is the 'Depot Identifier' for this depository. On the Depot and Account Definition (DEPAM) screen, this is the depository for which you are defining depot/account/sub-account allowed combinations. This is the type of the current depository. It can be either: Clearing House (C) Internal (I) Sub Custodian (S) The code that refers to a depository. This information is maintained on the Depository Maintenance (CSDM) screen. This field can be defaulted from information defined on the Depot Defaults (SPSTM) screen. On the Paper Settlement Authorisation Queue (PSQUE) screen, this is the depot where the physical paper for the contract is held. On the Default Paper Settlement (SPSTM) screen, this is the identifier that represents the depot at which paper settlement is to be made. On the Paper Settlement Confirmation (SPSTI) screen, this field initially displays the identifier that represents the depot where the physical securities delivered on the event date are held. This depot is the one used as standard for the contract. If necessary, this field can be overwritten so that another depot is used. On the Default Paper Settlement (SPSTM) screen, this is the identifier that represents the default depot for the accounting centre, settlement currency and product type combination. On the Paper Settlement Confirmation (SPSTI) screen, this is the full name of the depot identifier displayed. A description of the depository. This is displayed on inquiry screens where the Depository is shown. The S.W.I.F.T. address to which the message will be sent. The address must be either 8 or 11 characters in length. The first six characters must be alphabetic. This represents the destination indicated on a S.W.I.F.T. message. For an exact definition, refer to the S.W.I.F.T. documentation. This is a 3 character code representing the S.W.I.F.T. code for the destination branch, related to the S.W.I.F.T. Terminal. This makes up part of the S.W.I.F.T. identifier, together with the Destination. This shows either the destination or sender of the message, depending on whether the message is leaving from or arriving at the system. If the destination or sender cannot be discerned by the system, this field will remain blank. This shows the Destination and Destination Branch of the inward clean payment

198 Definition of Field Names Field Diary Type Direction Display All Accounting Centres Display All Netting Types Display All Products Effective Date End Date Entry Complete Definition This code represents the diary event for which details are displayed. Diary Types are given as narratives on the General Purpose Narratives (GNARR) table, type DI (see the Guide to Setting Up). On the Non Standard Settlement Instructions (NSTDM) screen, this is the specific diary event for which you are setting up non standard instructions. Use this field to record whether the message is to be input to the S.W.I.F.T. system, or is output/received from the S.W.I.F.T. system. This field allows you to view all of the accounting centres in your system. It is used on the netting screens after you have entered the Netting Identifier. Setting this field to Off has the effect of limiting the accounting centres displayed to those that can be used by that Netting Identifier. Setting this field to 'On' will allow you to view all accounting centres again. This field allows you to view all of the netting types in your system. It is used on the netting screens after you have entered the accounting centre. Setting this field to Off has the effect of limiting the netting types displayed to those that can be used by accounting centre. Setting this field to 'On' will allow you to view all netting types again. This field allows you to view all of the products in your system. It is used on the netting screens after you have entered the netting identifier. Setting this field to Off has the effect of limiting products displayed to those that can be used by netting identifier. Setting this field to 'On' will allow you to view all products again. On the Nostro Transfer Reversal (NSXFR) screen, a date is displayed in this field automatically. A Nostro Transfer has already come to value (and cannot be reversed) if the Effective Date is before today. Otherwise, the Effective Date is always the same as that of the original Nostro Transfer. For a standard settlement instruction an end date can be entered after which the instruction will no longer be applied. On the Depot Defaults (SPSTM) screen, this is the date after which this default will not apply. This field is automatically updated when a new default is created, the end date being the day before the start date of the new default. On the Depot and Account Definition screens, this is the date after which the combination of Depository/Account/Sub-Account cannot be used. If an End Date is entered, the user must ensure that the Start Date of the next combination corresponds. On the CLS screens, this is the date on which you want the CLS record entered on this screen to become inactive. After this date, the accounting centre/location will not be able to perform CLS. When you have finished entering the clean payment details, you must confirm that it is complete. To do this, switch 'On' this field and click Ok

199 Definition of Field Names Field Error Indicator Event Event Date Event/Contract Exchange Rate Exchange Rate Group Expected Amount External Account Number Definition This indicates whether there is an error in the S.W.I.F.T. message. The mnemonic of the diary event that caused the message to be generated. For example IP indicates Input event. The mnemonics are given on the General Purpose Narratives (GNARR) table, type DI (see the Guide to Setting Up). On the CLS screens, this shows the event type that has forced the posting, and whether this event type is for a contract that is bought or sold. Event types shown in this field are either: MA Maturity (for FXMK & FXSW contracts) ST Start (for FXSW contracts only) The event date which defines the date from which the list of displayed diary events, associated with the selected contract, commences. You may then scroll through this list identifying events for which settlement messages need to be authorised, or reversed, before being sent/printed. When the list of diary events, associated with the selected contract, are displayed the details of each event includes its date. This defines how a client netting agreement will handle the different settlement events that make up a contract. It can be either: Event (E) - Each settlement event must be authorised to enter a netting agreement on an individual basis. Contract (C) - Each contract must be authorised once, and then all the events in that contract are authorised for netting. This is the exchange rate used to convert the clean payment amount when the Debit Currency and Credit Currency are different. This field need only be entered when the clean payment is above the limit defined by the blueprint parameters BP-CP-LIMIT and BP-CP-LIMIT-CCY. This is the Exchange Rate group used to convert the clean payment amount when the Debit Currency and Credit Currency are different. If the clean payment is above the limit defined by a blueprint parameter, then the Exchange Rate must be entered instead. The blueprint parameter BP-CP-LIMIT is the limit amount and BP-CP-LIMIT-CCY is the limit currency. This is the amount expected to be settled for the diary event displayed. This is determined from the contract details. This amount may differ from the "Actual Amount" settled. This is the depot assigned account number for this combination of Depot/Account/Sub-Account. It is used in S.W.I.F.T. messages instead of the Urbis values

200 Definition of Field Names Field Fax Fee Type Forward Movement Free Format Address Free Format Instructions From Amount From and To Full Name GL Master Has MT103 Has MT202 Holding Movement Holiday Method Definition The fax number of the CLS provider. This is for documentary purposes only. This is a code representing the fee type relevant to the event displayed. Fee types are defined on the Fee Types (FETPM) screen (see the Generalised Fees Administration Guide). This is the total amount of movement due on the security after date defined by the 'As At Date'. On the Agent Settlement Defaults (AGDFM) screen, this is a freeformat field that can be used as an alternative to the Agent or BIC Code fields. This field is a free format field that can contain any information relevant to the netting authorisation. This field can be used to limit the payments displayed to those above a specified value. These fields control the range of transactions displayed by the inquiry. Only transactions with an Input or Value Date between these dates will be displayed. Whether the Input or Value Date for a transaction is used is defined by the 'Date Indicator' field. The full name of the Agent. This is used for inquiries and reporting. This is the number of the General Ledger Master to which the displayed contract is linked. This identifies the General Ledger category. On clean payment screens, this is the General Ledger Master to which the displayed clean payment is linked. This displays whether this clean payment has an MT103 S.W.I.F.T. message attached to it. Yes an MT103 exists for this message No an MT103 does not exist for this message. This displays whether this clean payment has an MT202 S.W.I.F.T. message attached to it. Yes an MT202 exists for this message No an MT202 does not exist for this message. The nominal (or original trade value) of the transaction that affects the holding. This defines how the dates of scheduled events are altered if they fall on a holiday for the stock exchange or depository. This can be either: None (N) do not change the date of the event Following (F) change the date to the next business day

201 Definition of Field Names Field Holiday Override Definition This comprises two fields. The first indicates whether the transfer can occur on a holiday: On - Yes, events can occur on holidays Off - No, events can not occur on holidays The second field contains a value defined on the Country Check Codes (CNCHK) table representing the currencies to be checked for holidays for each contract event. Incoming Reference Input Date Input/Output Instruction Code Instructions For Instrument If the clean payment has been initiated by an inward clean payment S.W.I.F.T. message, this field shows the reference of that message. The Inward message can be inquired upon using the Incoming Clean Payments Inquiry (CPINI) screen (see Section 8 of this guide). This is the date on which a contract was entered into the system. On the Deals Input Confirmation (AWBOI) screen, enter the date for which you want to view details of the entered contracts that have yet to be removed from the contract management queue. If you do not enter a date, the current date is used. On the Settlement Instructions Confirmation (AWSTI) screen, you must enter the date for which you want to view details of the entered contracts that have yet to be removed from the contract settlement queue. On the LA Client Settlement Instructions Authorisation Queue (CDATI) screen, this is the date that the default settlement instructions record was input. This specifies whether messages Input (I) to S.W.I.F.T. or Output (O) from S.W.I.F.T. are to be displayed. This field can be found on MT103 S.W.I.F.T. messages. For an exact definition, refer to the S.W.I.F.T. documentation. For the Netted Settlements Authorise (NETTA) screen, this indicates whether the event, whose details are displayed, is for the payment (P) or receipt (R) of the Payment Amount specified. For the Payment Instruction Narratives (PCNRM) screen, this indicates if the narrative is to be printed on payments or receipts: Pay (P) Receive (R) The instrument identifier of the security that is being traded. On the Depot Account Holdings Contract Inquiry (DEPCI) screen, this is the instrument identifier of the security for which you are inquiring on the holdings

202 Definition of Field Names Field Instrument Identifier Instrument Name Intermediary Intermediary Address Intermediary Bank Intermediary BIC Code/Address Intermediary Name Intermediary: BIC Code Intermediate Nostro Account Internal Reference Last Cut-Off Date Last Cut-Off Time Last Update By Definition For securities products, this is the identifier of a particular security. It is set up on the Interest Bearing Securities Primary Static or Secondary Static screens (BSHD1, BSHD2) for Interest Bearing Securities, and on the Discounted Securities Static Maintenance (DPSTM) screen for Discounted Securities. For Futures and Options products this is the exchange and instrument concatenated. For other products this field is blank. On the Paper Settlement Queue (PSQUE) and Paper Settlement Confirmation (SPSTI) screens, this is the full name of the particular security delivered or received on the event date displayed. On the Authorise Release of Event Messages (SETTA) and Authorise Release of Event Messages for LA Participants (SETTB) screens, this field displays the name of the intermediary via which the agent is contacted. Intermediaries are set up on the Agent Details Maintenance (AGNTM) and Agent Settlement Defaults (AGDFM) screens. On the Clean Payment Message Input Screen Three 103 (CP102) screen, this field can be found on an MT103 S.W.I.F.T. message. For an exact definition, refer to the S.W.I.F.T. documentation. The address of the intermediary via which the agent is contacted. This field can be found on an MT202 S.W.I.F.T. message. For an exact definition, refer to the S.W.I.F.T. documentation. When a S.W.I.F.T. message is produced for this nostro transfer, the information entered into these fields will be transferred onto the S.W.I.F.T. message. The name of the intermediary via which the agent is contacted. The S.W.I.F.T. BIC code of the intermediary via which the agent is contacted. The account number of an account used to hold payments before they are moved to a nostro account. This is a system-generated reference number for the default values entered. This is a display only field that shows the value date for the last occasion that a netting balance was settled. The system uses this date to ensure that netting balances are processed in a chronological manner. This field is for future use only. On the LA Client Settlement Instructions Authorisation Queue (CDATI) and the LA Fee Settlement Authorisation (LAFAM) screens, this shows the usercode of the user who last updated the record

203 Definition of Field Names Field Last Updated Line Line Number Link Linked Contract Location Matched Deletions Allowed Definition On the Client Settlement Instructions for LA (CISIM) screen, this shows the date that the record was last updated. The number that is used to identify each separate line of the settlement message. This line number is only used for editing the message, it is not saved or sent as part of the message. The number of each separate line of narrative text that comprises a payment instruction. On the Outstanding Settlement Messages (SETCN) screen, use this field to view summary details of the outstanding messages for a contract. Enter 'Y' to link to the Authorise Release of Event Messages (SETTA) screen. On the Deals Input Confirmation (AWBOI) and Settlement Instructions Confirmation (AWSTI) screens this field is used to link to a contract change screen and to remove a contract from the queue. Enter 1 to link to the contract change screen. Enter R to confirm the contract and remove it from the queue. This is a documentary field indicating the contract from which details of the current contract were copied. If you are in the process of copying a contract, this field contains the number of the contract being copied. The Location can be used as an alternative to Accounting Centre for grouping netted contracts. Locations are defined on the Location Maintenance (LOCTM) screen, see the Guide to Setting Up. On the CLS Provider Detail Maintenance (CLSDM) screen, this is the location for which you are defining CLS details. The details will be applied to all accounting centres that belong to this location. See Continuous Linked Settlement in Section 11 of this guide for more information. On the CLS Inquiry screens, this is the location for which you want to see currency balance details. The amounts shown will include all accounting centres that belong to the location. If the depository allows the deletion of matched deals, then switch 'On' this field. Maturity Date Media Message Number On the Deals Input Confirmation (AWBOI) and Settlement Instructions Confirmation (AWSTI) screens, this is the date on which the contract matures. This indicates how the message is to be sent: Printed (P) - to print the message S.W.I.F.T. (S) - to use the S.W.I.F.T. network Blank - not applicable The unique number that is used to identify a message. The message number allows you to identify different S.W.I.F.T. messages of the same type

204 Definition of Field Names Field Message Priority Message Sequence Number Message Status Message Type Definition Unless your version of the system is set up to support S.W.I.F.T. payment / confirmation messages, this is a documentary field only. Otherwise, it identifies the system code associated with a standard S.W.I.F.T. message priority code Urgent U1003 Equivalent to S.W.I.F.T. message U1003 (Urgent); a Non-Delivery Warning is reported if the message has not been received within 15 minutes Normal N2020 Equivalent to S.W.I.F.T. message N2020 (Normal); Delivery Notification is reported if the message has been received within 100 minutes Urgent U3003 Equivalent to S.W.I.F.T. message U3003 (Urgent); a Non-Delivery Warning is reported if the message has not been received within 15 minutes and Delivery Notification is reported if the message has been received within 15 minutes None Indicates that, even if the client has a S.W.I.F.T. address, settlement instructions must be suppressed. This facility can be used for internal deals that do not require settlement instructions. This is the S.W.I.F.T. assigned number of the message, which is the same as the Incoming Reference number entered onto the Clean Payments screens (such as Clean Payments Addition (CPAYA)). This displays the current status of the received S.W.I.F.T. message. This can either be: Received The message has been received and is awaiting processing. Rejected The message has been rejected, either manually or by the system. This may be because it is incomplete, or has errors. Matched/Posted The message has been converted into a contract and processed successfully. Closed The message has been closed and no processing is permitted. The type of S.W.I.F.T. message. See S.W.I.F.T. Messages Generated by Contract Type in Appendix A for details of the message types supported. On the Outstanding Settlement Messages (SETCN) screen, this shows whether the message is a confirmation, payment, or notification

205 Definition of Field Names Field Message Type/Number MT100 Override MT200 to be sent MT210 Advices Via S.W.I.F.T. MT210 to be sent MT541 to be sent MT543 to be sent Definition This field is divided into two parts. The first shows the type of S.W.I.F.T. message that has been generated. The second shows the unique message number of the message. The message number allows you to identify different messages of the same type. Message type MT999 indicates that the event does not cause a S.W.I.F.T. message to be generated. Dummy messages of this type can be authorised for printing, in which case they will be processed by the ONPAPER - Online Paper Confirmations/Payments report, see the On-Demand Reports Guide for details. Switch "On" this field if MT100 messages are to be produced instead of MT103 messages. Switch "On" this field to indicate that MT200 messages can be sent, through S.W.I.F.T., to the depot. If MT200 messages cannot be sent, then this field must be switched off. This indicates whether or not MT210 notices can be sent, through S.W.I.F.T., to the Nostro. On - MT210 notices can be sent Off - Only printed messages are generated This indicates whether or not MT210 messages can be sent, through S.W.I.F.T., to the depot. On - MT210 notices can be sent Off - MT210 notices cannot be sent Switch "On" this field to indicate that MT541 messages can be sent, through S.W.I.F.T., to the depot. If MT541 messages cannot be sent, then this field must be switched off. This indicates whether or not MT543 messages can be sent, through S.W.I.F.T., to the depot. On - MT543 notices can be sent Off - MT543 notices cannot be sent Name Name and Address Narrative The name of the CLS provider. This is a free format field. On the CLS Currency Maintenance (CLSCY) screen, this is the name of the currency, defined on the Currencies (CCYS) screen. This screen is described in the Guide to Setting Up. A free-format field for the name and address of an intermediary for settlements. This can be used as an alternative to the BIC Code. On the Payment Narratives (PCNRM) screen this is a free format field that can be used for entering a narrative that is then associated with that contract. On the Accounting Authorisation (ACATM) screen this is a narrative composed of contract type, diary type and contract number

206 Definition of Field Names Field Netting Type Identifier New End Date Next Currency Next Sequence Number Nickname Nostro Nostro Currency Nostro Long Name Definition The Netting Type Identifier is used to identify the netting type used in a particular client netting agreement. Netting Type is set up on the Netting Agreement Types (NTTYM) screen. Many of the default values that affect a netting agreement are defined by the netting type. For a standard settlement instruction an end date can be entered after which the instruction will no longer be applied. If an end date has not been entered previously, then the New End Date must be later than the Start Date. If an end date has previously been entered for the instruction, then the New End Date must be later than the Start Date and earlier than the previous End Date. If a New End Date later than the existing End Date is required, then a new instruction will need to be created. Enter the name of the currency you want to authorise a netting agreement for after you have finished the current agreement. Netting of payments is allowed in any currency defined by the Client Netting Agreement. To limit the inquiry, enter a sequence number of a S.W.I.F.T. message and click Ok. The inquiry will be started from this sequence number. This is the shortname used to identify an agent. This is the client's agent who pays or receives the funds on a contract. On the Payment Instruction Narratives (PCNRM) screen, this represents the nostro associated with the payment narrative. Either the nostro name or number may be entered. On the Accounting Authorisation (ACATM) screen, this represents the nostro associated with the settlement. On the Client Settlement Instructions for LA (CISIM) screen, this field is used for entering a default pay nostro or receive nostro. If the instructions are being set up for a payment, then [PAY] will be displayed after the field name to indicate that you are defining the pay nostro. If the instructions are being set up for a receipt, then [RCV] will be displayed after the field name to indicate that you are defining the receiving nostro. On the CLS Balance Inquiry (CLSBI) screen, this is the nostro to be used for the settlement of the CLS outstanding balance for this currency. The mnemonic of the currency of the nostro. Currency mnemonics are defined on the Currencies Table (CCYS). The longname of the nostro. This is used for inquiries and reporting

207 Definition of Field Names Field Nostro Name Nostro Number Nostro Sort Code Nostro/Vostro Relationship Novation/Settlement Number of Days Number of Items Obsolete Date Option 53B Ordering Bank Ordering Customer Ordering Party Details for MT210 Ordering Party is a Bank Our Account Number Definition The shortname of the nostro. Either this or the Nostro Number are entered on contract data entry screens. On the Nostro Settlement Defaults (NSDFM) screen, this is the name of the Nostro to be used for settlements. The nostro can be defaulted on to a deal entry screen when the Product Type, Settlement Currency and Accounting Centre are known. The number of the nostro. Either this or the Nostro Name are entered on contract data entry screens. The sort code or reference number of the bank in which the nostro account is held. This field indicates whether you have an account with the institution related to the agent. Currently only the Settlement option is supported by the system, so all Client Netting Agreements must be set to this. In this instance, Settlement entails taking payments from the contract to create a net balance. This is the number of days in advance of the value date that the payment cannot be made in. For charge calculations, this is the number of items included in a posting. The field is pre-filled with '1'. For customer transfers, this is the number of items included on both the credit and debit sides. This field contains the date after which a Netting Type cannot be used to create new client netting agreements, and after which existing agreements are cancelled. When this field is switched 'On' and a S.W.I.F.T. payment message is created (MT100, MT103, MT200, or MT202), then field 53 will be completed as for Option B of the S.W.I.F.T. standards. This field can be found on MT103 or MT202 S.W.I.F.T. messages. For an exact definition, refer to the S.W.I.F.T. documentation. This field can be found on an MT103 S.W.I.F.T. message. For an exact definition, refer to the S.W.I.F.T. documentation. Information entered in these fields will be transferred to either the Ordering Bank or the Ordering Customer field on an MT210. The field that the information is transferred to is controlled by the Ordering Party is a Bank field. This field defines whether information you enter in the "Ordering Party Details for MT210" field is to be transferred to the Ordering Customer or the Ordering Bank field on the MT210. On - transfer information to Ordering Bank field Off - transfer information to Ordering Customer The number used for the nostro account in your bank

208 Definition of Field Names Field Our Account Number on Their Books Our Details Our Nostro Parent Definition The number of your bank's account in the nostro bank. This defines whether the depot details entered or displayed on this screen are relevant to either your institution, or to one of your clients. Switch 'On' this field to display or inquire on depot details for your institution. This should not be entered if you enter a client in the 'Shortname/City' fields. On the Authorise Release of Event Messages (SETTA) and Authorise Release of Event Messages for LA Participants (SETTB) screens, this is the nostro that will be used for the message. If a nostro has not been specified, then the message cannot be authorised until it has been updated. The message can be updated using the Message Review and Repair (MESSR) screen. On the Netted Settlements Authorise screen, this is the name of the nostro account of your bank that will be used in the agreement. This is the "Parent Message/Type". Parent Message/Type Pay Nostro Pay/Receive If the message displayed on this screen originated from a different incoming message, then this shows the message number and type of the original parent message. For example, when an MT103 is received, it might be broken down into various MT202's for processing. This field will show the parent MT103. The Nostro from which funds are to be moved. This is a displayonly field on the Nostro Transfer Reversal screen. On the Nostro Transfer Add screen the field is validated against the Nostro Details (NSTRO) table where the details must include a S.W.I.F.T. address. For the Authorise Release of Event Messages (SETTA), the Authorise Release of Event Messages for LA Participants (SETTB) and the Netted Settlements Authorise (NETTA) screens, this indicates whether the event, whose details are displayed, is for the payment (P) or receipt (R) of the Payment Amount specified. On the CLS Balance Inquiry (CLSBI) screen, it displays whether the balance amount is a payment or a receipt For the Payment Instruction Narratives (PCNRM) screen, this indicates if the narrative is to be printed on payments or receipts: Pay (P) Receive (R)

209 Definition of Field Names Field Pay/Receive Date Payment Amount Payment Days Advance Payment Indicator Definition This field is used to document when either the payment for the contract was made, or the payment for the contract was received. The amount of the event whose details are displayed This is the number of days in advance of a settlement date when the payment message is created, as specified on the Countries (CNTRY) screen. This is used to show whether the settlement default applies to payments made; or to receipts taken via the nostro/agent; or to both. Payments (P) Receipts (R) Both (B) Note: On the Non Standard Settlement Instructions (NSTDM) screen, this must currently be set to Payments. On the Client Settlement Instructions for LA (CISIM) screen, this applies to the default settlement instructions for the client, and may be either: Payments (P) Receipts (R) Portfolio Post Posting Narrative Preferred Account with Agent Preferred Agent Preferred IBAN The portfolio for which you want to view securities holdings information. Portfolios are set up on the Portfolio Definition (PFDFM) screen, described in the Portfolio Management Guide. If a "Yes" is displayed in this field, then that indicates that the message has been successfully posted. This field will only be used if the blueprint parameter BP-LAS- POST-ON-REL is set to "Y". See the Guide to Setting Up for more information on this blueprint. This is a free format field used to enter a description of the clean payment you are entering into the system. The counterparty's account at the agent. This field can be used when the agent does not receive funds via an intermediary. In the BIC Directory window (available on the GUI only), this field is used to restrict searches to preferred agents only. Preferred agents are indicated using the Preferred Agent field on the Agent Details (AGNTM) screen. Indicate preferred agents on the Agent Details (AGNTM) screen as follows: On - Include in Preferred Agent search Off - Do not Include in Preferred Agent search The counterparty's account at the agent, using the IBAN format. See IBAN Numbers in Section 1 for more information

210 Definition of Field Names Field Produce MT202 Product Product Currency Product Type Rate Receive Nostro Definition Switch 'On' this field to produce an MT202 for this nostro transfer, instead of an MT200. This is the product type of the contract. Product types are defined on the Product Types Maintenance (PRTPM) screen, described in the Core Functions and Inquiries Guide. This is the currency of the contract's product. Currency mnemonics are defined on the Currencies (CCYS) table. This identifies a product. Products are sub-divisions of contract types. Each contract entered into the system must be associated with a product type. Product type definitions are held on the Product Types Maintenance (PRTPM) table. On the Clean Payment related screens, this is the clean payment product type, set up on the Clean Payment Defaults maintenance (CPDFM) screen. On the Deals Input Confirmation (AWBOI) and Settlement Instructions Confirmation (AWSTI) screens, enter a product type to restrict the contracts displayed to those based on the specified product. This field may contain the instrument identifier for a Futures or Options product. On the Depot Defaults screens, this field defines the product type to which this default setting will apply. If '******' is entered in this field, then this default will apply to all product types. This is the rate used by the contract. The type of rate varies according to the type of contract. For example, the deal rate is displayed for Foreign Exchange contracts, the premium is displayed for Options and the interest rate is displayed for loans and deposits. On the Nostro Transfer Add (NSXFA) screen this is the Nostro into which funds are to be transferred. This field is validated against the Nostro Details (NSTRO) table, where the Nostro record must: Include a S.W.I.F.T. address Indicate that MT210 Notices may be sent via S.W.I.F.T. Receivers Correspondent Bank Receivers Reference Reference This field can be found on MT103 or MT202 S.W.I.F.T. messages. For an exact definition, refer to the S.W.I.F.T. documentation. The S.W.I.F.T. address of the receiver of the incoming clean payment. This is the S.W.I.F.T. address of your institution. On the Client Settlement Instructions for LA (CISIM) screen, this is a free-format optional field for entering default text that is to be displayed on the settlement message. This can be up to 50 characters, and provides a reference for the beneficiary, of a customer transfer

211 Definition of Field Names Field Reference End Reference Number Reference Number for Take Up or Compensating Diaries Reference Required Reference Start Reject Reject Authorisation Related Reference Repair Required Replaced By Replaces Contract Reporting Reference Resend Resent Definition If the depository requires a unique reference to be used in communication messages, then this is the last number in the range of applicable numbers. This is your reference number of the message. This must be numeric but can have any meaning to meet the needs of your organisation. This reference number is used with the Diary Type and Date fields to uniquely identify a Foreign Exchange Take Up diary or an Interest Rate Swap compensating payment diary. The Foreign Exchange Take Up reference number is allocated when the take up is entered on the Foreign Exchange Take Up Add (FXTKA) screen. An Interest Rate Swap is allocated a sequence number when it is entered on the Swap Compensating Payments (SWCPM) screen. If the depository requires a unique reference number on messages in addition to any contract number, then you must switch 'On' this field. The reference number is the next in a range defined by the Reference Start and Reference End fields. If the depository requires a unique reference to be used in communication messages, then this is the first number in the range of applicable numbers. This tick box is display only and refers to the Reversal Indicator heading. The box is ticked to indicate a message sent to, and rejected from, S.W.I.F.T. A single number below the Reject heading indicates the failure reason code. Select this field to reject the previously authorised displayed default. This field can be found on an MT202 S.W.I.F.T. message. For an exact definition, refer to the S.W.I.F.T. documentation. This field indicates whether or not the message must be updated before it can be sent. Update will be required if information is missing from the message, for example, if the nostro name is to be advised. This is a documentary field indicating the contract that replaced this contract. This is a documentary field indicating the contract being replaced by this contract. If you are in the process of replacing a contract, this field contains the number of the contract being replaced. This is a system-generated reference number for the default values entered. This field should be set if the settlement message is to be re-sent. This field indicates the number of times that a message has been resent/reprinted

212 Definition of Field Names Field Return Reversal Reversal Indicator Reverse Contract Number Run CLSCHANGE Report S.W.I.F.T. Address Definition When the S.W.I.F.T. message has been sent to the CASmf Interface, this field shows its status. A return of 9000 indicates the message contained no errors, and was processed properly. Any other return denotes an error, for a description of which you should refer to the CASmf Interface documentation. On the Paper Settlement Authorisation Queue (PSQUE), this indicates whether a paper settlement event has been reversed. When you delete a deal that has a paper settlement event, the original event is displayed on the Paper Settlement Authorisation Queue (PSQUE) together with a reversed entry. The reversed entry is denoted by R in the Reversal field. Note: The Reversal indicator applies to contracts with a status of To be delivered or To be received only. See Status Indicator. On the Accounting Authorisation (ACATM) screen, this indicates whether the accounting entry is to be reversed. When you delete a deal that uses manual accounting models (see Setting Up Accounting Models in the Guide to Setting Up), the deal is reversed out automatically. However, if the deal has already made postings, these must be reversed manually by you. To do this, switch 'On' this field to reverse the entry. This field is only relevant for Posted accounting entries. This field indicates whether or not a message is a reversal of a previous message. Reversals are generated when a contract update causes an actioned settlement to be invalid. In this case a new message and a reversal are generated. Reversals are actioned by printing the message using the ONPAPER report. The number of a Nostro Transfer contract to be reversed. When a change has been made to the CLS details on this screen, then the CLSCHANGE CLS Update report should be run. This field can be set to run the report from this screen. It can either be run in Inquiry Mode, or Update Mode. This report is described in the On-Demand Management Reports Guide. Inquiry - The report will produce a list of contracts affected by changes, but will not update the positions. Update the report will update the positions of contracts affected by changes. The S.W.I.F.T. address of the depot. The address must be either 8 or 11 characters in length. The first six characters must be alphabetic. On the CLS screens, this is the S.W.I.F.T. address used by the CLS provider

213 Definition of Field Names Field S.W.I.F.T. Bank Code S.W.I.F.T. Branch S.W.I.F.T. Euro Payment Indicator S.W.I.F.T. Priority S.W.I.F.T. Terminal Identifier Search for Security Level Definition This field should be entered if the S.W.I.F.T Euro Payment Indicator is set to "Y". If no entry is made in this field, an MT101 message is sent. If any of the values is selected, an MT103 message is sent. The permitted values are: Priority (SPRI) Standard (SSTD) S.W.I.F.T. Pay (SPAY) No Service (CRED) - default setting (no entry in field). The S.W.I.F.T. branch of the "Sender's Accounting Centre". This identifier is set up on the Accounting Centres Maintenance (ACNTM) screen. This field indicates that the settlement currency is euro instead of the nostro currency. The settlement message MT103 is used in place of the standard MT100 (if used) and field 72 is formatted with the appropriate codewords. Switch 'On' to send the MT103 messages instead of the MT100. If this field is set On, then the S.W.I.F.T. Bank Code field must also be entered. This field contains the S.W.I.F.T. Priority of the message, taken directly from the S.W.I.F.T. message. For an exact definition, refer to the S.W.I.F.T. documentation. The S.W.I.F.T. terminal identifier for the "Sender's Accounting Centre". This identifier is set up on the Accounting Centres Maintenance (ACNTM) screen. This is used on the BIC Directory window, used to search for, and find details on, Bank Identification Codes (BIC codes). Select either BIC Code or Nickname from the drop down list and enter all or part of a BIC code or agent nickname you want to find details on. This feature is only available on the Graphical User Interface (GUI). The security level associated with a S.W.I.F.T. message type/tag code combination. Only users with this level of security set in their access groups can update message fields identified by this message type/tag combination

214 Definition of Field Names Field Select Definition On the Netted Settlements Authorise (NETTA) screen, this field indicates which payments are to be included in the nettable balance. Entering Yes (Y) in this field will include the payment in a nettable balance. Entering No (N) in this field will leave the payment out of the nettable balance (this can also be left blank as the default value). Entering Remove (R) in this field will remove the payment from the nettable balance, and send it to the settlement queue for manual processing as an individual item. Entering Select (S) in this field will remove the payment from the nettable balance, and return it to the settlement queue, using STP if appropriate. On the Settlement Message Add (MESSA) and Settlement Message Review and Repair (MESSR) screens, this field indicates which lines are to be affected by the maintenance you are undertaking The maintenance can either be adding a line, changing a line or deleting a line. To indicate the fields that will be affected, turn the Select Indicator 'On' next to the line you are changing. On the CLS screens, when adding a new client or currency, switch 'On' this field adjacent to the client or currency and click Add to enter the information into the system. When authorising a client or currency, switch 'On' this field adjacent to the client or currency and click Authorise to authorise the client. Send Message Sender Sender to Receiver Information Sender's Accounting Centre Senders Correspondent Bank Senders Reference Sequence Number Use this field to indicate whether a message is to be sent via S.W.I.F.T. This is the S.W.I.F.T. ID of the originator of the inward message. Entering this field limits the inquiry to messages sent by this S.W.I.F.T. ID. When a S.W.I.F.T. message is produced for this nostro transfer, the information entered into this field will be transferred onto the S.W.I.F.T. message. The mnemonic of the sending accounting centre involved in a customer transfer. This field can be found on MT103 or MT202 S.W.I.F.T. messages. For an exact definition, refer to the S.W.I.F.T. documentation. The S.W.I.F.T. Address of the sender of the incoming clean payment message. This is the 'Message Sequence Number'. Session This field shows the session number of the S.W.I.F.T. message, assigned by S.W.I.F.T

215 Definition of Field Names Field Settlement Settlement Currency Settlement Date Definition The date on which the settlement is made. This is the currency for which the settlement instructions apply. Currency mnemonics are set up on the Currencies (CCYS) table. On the Nostro Details (NOSTRO) screen, this field allows settlement for a nostro defined as an "in" European currency to take place in euros. The field must only be entered if the nostro currency is an "in" currency and its value must be euros. This is the date on which this payment is due to be settled. Settlement Member Settlement Method Short Positions OK Shortname Show All Show All Available Clients Show Default This field indicates whether or not the counterparty is a member of CLS. If the counterparty is a CLS member, then the appropriate formatting is applied on MT300 messages. This defines the method by which payment instructions for the transfer of funds between parties are processed. This may be: Local (L) S.W.I.F.T. (S) Clearing (C) Vostro (V) Telex (T) Other (O) If the depository allows stock positions to be short, then you should switch 'On' this field. The mnemonic which, when used with the City, uniquely identifies a client. Client Shortnames are defined on the Client Details Banking (CIWSL) screen. Switch 'On' this field if you want to view expired default definitions, as well as current default definitions. Expired default definitions are those that have passed their 'End Date'. Switch 'On' this field to display all clients in the system with a S.W.I.F.T. address. The screen will display both authorised and unauthorised clients. On the Client Settlement Instructions for LA (CISIM) screen, when Show Defaults is selected, the settlement information set up at the Accounting Centre level is displayed. Accounting centre defaults are specified using the Nostro Settlement Defaults (NSDFM) screen. When this is not selected, client level defaults are displayed and can be amended; or new ones can be added. On - Show accounting centre level defaults Off - Show client level defaults

216 Definition of Field Names Field Show Euro Equivalents Show Unauthorised Only Definition Selecting this field when inquiring on an account will return the balance automatically converted into euros On - Show account in euros Off - Show account in default currency. Switch 'On' this field to limit the inquiry to clients who have been entered into the system, but have not yet been authorised. Show Zero Holdings Records This allows you to view holdings that have current and net zero positions. Switch 'On' this field to view zero holdings. Sort Code Source Used by the CHAPS messaging system to route settlement messages for agents and intermediaries. See CHAPS in Section 1 for more information. This is a reference code showing how the clean payment was produced. It can be either: Inward - The clean payment was entered totally on the system MT100 - The clean payment was entered into the system using an incoming MT100 message as reference MT103 - The clean payment was entered into the system using an incoming MT103 message as reference MT202 - The clean payment was entered into the system using an incoming MT202 message as reference Splitting Supported SSI Start Account This defines whether the depository allows splitting of stock prior to settlement. On - The depository supports splitting Off - The depository does not support splitting This indicates whether Standard Settlement Instructions have been used. The account from which you want the inquiry to start. Start City Start Contract Number Start Currency The name of the city, associated with a client shortname, from which you want the inquiry to start. The number of the contract that appears first in the list of contracts or events to be displayed on the screen. Enter a currency, or part of a currency, in this field to start the inquiry from that point

217 Definition of Field Names Field Start Date Start Depot Definition The date on which the contract starts. On the Inward Clean Payments Inquiry (CPINI) screen, this represents the earliest date from which you want view incoming S.W.I.F.T. messages. On the Nostro Settlement Defaults (NSDFM) and Default Agent Maintenance (AGDFM) screens, this is the date when any changes made to the data on the screen come into effect. On the Depot Defaults screens, this is the date from which this default will apply. On the Depot and Account Definition (DEPAM) screen, this is the date from which this combination of Depository/Account/Sub- Account is allowed to be used. On the Depot Account Holdings Position Inquiry (DEPSI) screen, this is the date from which you want the inquiry to start. On the CLS screens, this is the date on which you want the CLS record entered on this screen to become active. If there was a previous CLS record for this accounting centre/location, then the new record will replace it. The depot from which you want the inquiry to start. Start Instrument The instrument identifier from which you want the inquiry to start. Start Nickname Start Settlement Date Start Shortname Start Sub-Account The nickname of the agent from which you want the inquiry to start. The settlement date from which you want the inquiry to search. The shortname of the client from which you want the inquiry to start. The sub-account from which you want the inquiry to start. Start Value Date The value date from which you want the inquiry to search

218 Definition of Field Names Field Status Definition On the Deals Input Confirmation (AWBOI) and Settlement Instructions Confirmation (AWSTI) screens and the Paper Settlement Authorisation Queue (PSQUE), this is the status of the contract, it may be: Active (A) Deleted (D) Matured (M) Sold (S) Unstarted (U) On the Accounting Authorisation Queue (ACQUE), this shows whether there is a discrepancy between the Expected Amount and the Actual Amount paid or received. On the Clean Payment Authorisation (CPAUT) screen, this field can be Authorised (A) or Rejected (R). An authorised clean payment has been authorised for posting. A rejected clean payment has been viewed by a user, and they have rejected it. On clean payment screens except Clean Payments Authorisation (CPAUT), this field shows the status of the currently selected clean payment. It can be either: Incomplete (I) Unauthorised (U) Rejected (R) Deleted (D) Authorised (A) Posted (P) Pending (W) and for Inward Clean Payments Received (R) Incomplete (I) Unauthorised (U) Authorised (A) Posted (P) In Error (E) See also "Status (Cont)"

219 Definition of Field Names Field Status (Cont) Definition On the LA Fee Settlement Authorisation (LAFAM) screen, this field is used to view the fee settlements with a specified authorisation status. The possible statuses are: Payment Only (P) Payment and Accounting (A) Waiting (blank on text-based system) On the LA Fee Settlement Confirmation (LARSM) screen, this field is used to change the status of a fee settlement. The possible statuses are: Unconfirmed (blank on text-based system) Confirmed (Y) Waiting Authorisation (W) On the Client Settlement Instructions for LA (CISIM) screen, this indicates the status of the default settlement instruction record. This may be: Authorised (A) Waiting (W) On the CLS Screens, this is the status of the CLS record. This can either be: Unauthorised the record has been entered into the system but has not been authorised. The record cannot be used until authorised. Authorised the record has been authorised and can be used. On the CLS Balance Inquiry (CLSBI) screen, this is the status of the balance amount Settled The balance amount has been settled Transferred The balance amount has been successfully transferred using the Nostro Transfer Add (NSXFA) screen. On the Outbound S.W.I.F.T. Messages Inquiry (MSGSI) screen, this is the "Message Status". Status Indicator This indicates the status of the paper settlement events displayed: To be Delivered (D) Delivered (DR) To be Received (R) Received (RD) Defaulted (DF) Removed (RE) A status of Defaulted means that the counterparty has failed to deliver the paper

220 Definition of Field Names Field Stock Accounting Model Sub-Balance Codes Sub-Account Sub-Account Required Swap Side Tag Code Tag Code Description Tag Code/Data Target Indicator Definition These are the literals to be used as headings for the various stock accounting sub-balances. The first position is reserved for use as the Beneficial Position, so it cannot be defined by the user. The literals defined here are displayed in screens Holdings Inquiry (SAPNI), Holding Transactions Inquiry (SAPSI), and Transaction Stock Movements Inquiry (SATRI). The literals are defined on the General Purpose Narrative (GNARR) table, type SD, described in the Guide to Setting Up. For more information on the usage of this field, see the Stock Exchange and Securities Administration Guide. This refers to a particular sub-account at a depository. With the Depot and Account, it defines the custody location of a security at a depot. This field should only be entered if the depot uses a sub-account. This is indicated by the 'Sub-Account Required' field on the Depot Maintenance (CSDM) screen. This field can be defaulted from information defined on the Depot Defaults (SPSTM) screen. This defines whether the depository requires one of its clients to have a sub account allocated when creating a contract. Sub accounts can either be entered directly into the contract, or set up as defaults. On - Sub-account required Off - Sub-account not required This field indicates whether the non standard settlement instructions are to be applied to the loan (L) or deposit (D) side of an interest rate swap. If the field is left blank, the instructions apply to both sides of the swap. The S.W.I.F.T. tag code used to identify a particular field in a S.W.I.F.T. message. The tag code must be enclosed by colons, for example :52: A description of the field identified by the S.W.I.F.T. tag code. The S.W.I.F.T. tag code used to identify a particular field followed by the data that forms the content of the field. The tag code and data are separated by a colon. Switch "On" this field if the settlement messages sent for this contract are to use the TARGET messaging system instead of the S.W.I.F.T. messaging system. This is only appropriate for contracts with settlement currency of euro. See TARGET in Section 1 of this guide for more information

221 Definition of Field Names Field Telephone Definition The telephone number of the CLS provider. Their Account Number Their Agent Third Correspondent Bank Time To Amount Transaction Code Transaction Reference Transfer Amount Transfer Date Transfer Time Type Update Affected Deals Update Indicator The account number of their vostro account with us. This is the nickname of the agent. Agent nicknames are defined on the Agent Details (AGNTM) screen. On the Netted Settlements Authorise (NETTA) screen, this is the name of their agent who is handling the netting agreement. This field can be found on MT103 S.W.I.F.T. messages. For an exact definition, refer to the S.W.I.F.T. documentation. This is the time that the S.W.I.F.T. message was sent or received by the system. This field can be used to limit the payments displayed to those below a specified value. This field can be found on MT103 S.W.I.F.T. messages. For an exact definition, refer to the S.W.I.F.T. documentation. This field can be found on an MT103 and an MT202 S.W.I.F.T. message. For an exact definition, refer to the S.W.I.F.T. documentation. The amount to be transferred. The date the incoming clean payment message was received by the system. The time the incoming clean payment message was received by the system. Indicates whether the settlement message, whose details are displayed, is a Confirmation (C) or Payment (P). On the Outbound S.W.I.F.T. Messages Inquiry (MSGSI), this is the "Message Type". When a change has been made to the CLS details on this screen, then the CLSCHANGE CLS Update report should be run. This will update all affected contracts with the new details. Switch 'On' this field to initiate the report from this screen. This report is described in the On-Demand Management Reports Guide. This applies to LA Commercial Loans contract types only. This field determines whether updates are to be applied to the borrower and/or the participants. Blank (borrower) All (A) Participant (P)

222 Definition of Field Names Field Update Type Use Confirmation Header Format Value Definition This field shows if the contract has been altered since it was entered. It can either be: Changed (C) the contract has been amended since it was entered Deleted (D) the contract has been deleted. This field is used to determine the contents of the MT300 message. If this field is switched 'On', then the code word "TPS" will be added to field 103 in block 3 of the message header. This then refers to Field 56 on the receivers side of the contract. This is the "Value Date" of the contract. Value Date Value Date/ Currency/Amount View All Messages The date on which a transaction or event comes to value. This can be forward of the as-of date. The maximum number of days forward you may date a posting is determined at installation. For postings, if you do not enter a value date, the as-of date is used. For the Paper Settlement Authorisation Queue (PSQUE), this appears as a display and a selection field. The display field shows the value date of the settlement event displayed. In the selection field, enter a date to restrict the display to those securities contracts that have settlements on that date. For the Accounting Authorisation Queue (ACQUE), the value date appears as a display and a selection field. The display field shows the value date of the event displayed. In the selection field, you must enter a date to view details of contract events that are due on that date and that have not been removed from the accounting authorisation queue. For the Paper Settlement Confirmation (SPSTI) and Accounting Authorisation (ACATM) screens this is the date that the displayed event comes to value. On the LA Fee Settlement Confirmation (LARSM) and LA Fee Settlement Authorisation (LAFAM) screens, this is the date on which the payment was made. On the CLS screens, this is the date for which the CLS currency balances are to be viewed. It is the maturity date of the Foreign Exchange Market and Foreign Exchange Swap CLS contracts. These fields can be found on an MT103 S.W.I.F.T. message. For an exact definition, refer to the S.W.I.F.T. documentation. This enables you to specify whether all messages, including non-current messages are to be displayed. Switch 'On' this field to view all messages. Note: If blueprint parameter BP-VIEW-ALL is set to X, then non-current messages cannot be displayed

223 Definition of Field Names Field View Authorised Deals Only Definition This enables you to specify whether the deals displayed must have been confirmed using the Deals Input Confirmation (AWBOI) or the Settlement Instructions Confirmation (AWSTI) screen or both. Settlements - Confirmation using Settlement Instructions Confirmation (AWSTI) Back Office - Confirmation using Deals Input Confirmation (AWBOI) Yes - Confirmation by both screens No - All deals Note: Blueprint parameter BP-VIEW-UNAUTH can affect the use of this field, see the description of the "Outstanding Settlement Messages (SETCN)" screen in Section 6. View Messages View Next Date View Posting Vostro Account Set to Sent if you wish to display the list of events for which settlement messages have already been sent. You may then scroll through this list identifying events for which settlement messages need to be reversed or reprinted. Set to Unsent if you wish to display the list of events for which settlement messages have not yet been sent. You may then scroll through this list identifying events for which settlement messages need to be authorised before being sent/printed. Set to All if you wish to display the complete list. Sent (S) Unsent (U) All (A) Switch "On" this field and click Inquire to display the balance information for this location for the next value date. This appears as a selection field and a display field. The display field indicates whether the Actual Amount has been Posted or is Unposted. The selection field indicates whether the settlement amounts displayed are posted or unposted: Posted (P) Unposted (U) On the Nostro Settlement Defaults (NSDFM) screen, this is the account number of the vostro to be used for settlements. The vostro can be defaulted on to a deal entry screen when the Product Type, Settlement Currency and Accounting Centre are known

224 Definition of Field Names Field Width Override Definition A code used on the Clean Payments Addition (CPAYA) screen to accept an exchange rate that exceeds one of the two exchange rate width bands set up for the currency at installation. Enter the wide code (W) if the exchange rate exceeds the first width band. Enter the management code (M) if the exchange rate exceeds the second width band

225 Appendix A S.W.I.F.T. Messages Generated by Contract Type S.W.I.F.T. Message Types Supported Table A 1. S.W.I.F.T. Message Types Supported Message Type MT100 (2) MT103 (2) MT200 MT202 MT205 MT210 MT299 MT300 MT305 MT320 MT330 MT340 MT341 MT360 MT361 MT362 MT364 MT365 MT518 MT900 (1) MT910 (1) MT940 MT950 Description Customer Transfer EMU (Economic and Monetary Union) Customer Transfers Institution Transfer for its Own Account General Institution Information Transfer Institution Transfer Execution Notice to Receive Consolidated Netted Payment Foreign Exchange Confirmation Foreign Exchange Option Confirmation Fixed Loan/Deposit Confirmation Call/Notice Loan/Deposit Confirmation Forward Rate Agreement Confirmation Forward Rate Agreement Settlement Confirmation Single Currency Interest Rate Derivative Confirmation Cross Currency Interest Rate Swap Confirmation Interest Rate Reset/Advice of Payment Single Currency Interest Rate Derivative Termination/Recouponing Confirmation Cross Currency Interest Rate Derivative Termination/Recouponing Confirmation Securities Trade Confirmation Confirmation of Debit Confirmation of Credit Customer Statement Message Statement Message A 1

226 S.W.I.F.T. Messages Generated by Contract Type 1. The S.W.I.F.T. MT900 and MT910 messages are created for every posting to a client account if the Credit Advice's and Debit Advice's fields on the Client Account Static Details (WACCM) screen have been set. Either printed messages, or online S.W.I.F.T. messages can be produced. This screen is described in the Clients and Accounts Administration Guide. 2. The system will either produce MT100 or MT103 messages. The actual message produced is controlled by the System Parameters (SPMTR) screen, described in the Guide to Setting Up unless the MT100 Override field is set on the Nostro Details (NSTRO) screen. The following message types can be received by the system, and undergo processing, but cannot be sent by the system: MT101 - Request a Transfer MT203 Multiple Financial Institution Transfer The following messages can be received and viewed in the system, but undergo no processing: MT396 - Answers MT398 Proprietary Message MT970 Netting Statement MT971 Netting Balance Report A

227 S.W.I.F.T. Messages Generated by Contract Type Table of S.W.I.F.T. Message Types Generated Table A 2. S.W.I.F.T. Message Types Generated by Contract Type S.W.I.F.T. Message Type (MT) Contract Type Client Account X X Client Account Charges Client Account Postings X X Clean Payments X X X X Standing Orders (External) X X X Nostro Transfers X X Netted Contracts (NETT) X X X X X FX Market X X X X X X FX Swap X X X X X X Money Market Fixed Rate Loan X X X X X X X Money Market Fixed Rate Deposit X X X X X X X Money Market Base Rate Loan X X X X X X X Money Market Base Rate Deposit X X X X X X X Money Market Index Rate Loan X X X X X X X Money Market Index Rate Deposit X X X X X X X Money Market Discounted Loan X X X X X X Interest Rate Swap X X X X X X X X X X Forward Rate Agreement X X X X X X X A 3

228 S.W.I.F.T. Messages Generated by Contract Type S.W.I.F.T. Message Type (MT) Contract Type Commercial Loan Commitment X X X X X Commercial Loan Base Rate Loan X X X X X Commercial Loan Fixed Rate Loan X X X X X Commercial Loan Discounted Loan X X X X X Futures Purchase Futures Sale Futures Client Deal OTC Options X X X X X X Traded Options Purchase Traded Options Sale Traded Options Client Deal Fees Contract Interest Bearing Security Issue Interest Bearing Security Sale X X Interest Bearing Security Purchase X X X Interest Bearing Security Repurchase Interest Bearing Security Reverse Repurchase X X X X X X X X Zero Coupon Bond Issue Zero Coupon Bond Sale X X Zero Coupon Bond Purchase X X X A

229 S.W.I.F.T. Messages Generated by Contract Type S.W.I.F.T. Message Type (MT) Contract Type Zero Coupon Bond Repurchase X X X X Zero Coupon Bond Reverse Repurchase X X X X Discounted Security Issue Discounted Security Sale X X Discounted Security Purchase X X X Discounted Security Repurchase X X X X Discounted Security Reverse Repurchase X X X X Trade Finance Inward Collection Trade Finance Outward Collection Trade Finance Domestic Guarantee Trade Finance Foreign Guarantee Trade Finance Export Letter of Credit Trade Finance Import Letter of Credit LA Drawdown X X X X X X LA Acceptance X X X X X LA Stand-alone Fees X X X X Notes: With the exception of Nostro Transfers, S.W.I.F.T. messages are not produced for internal contract types, such as Forward Rate Agreement Interdepartmental deals A 5

230 S.W.I.F.T. Messages Generated by Contract Type S.W.I.F.T. messages are not produced for Currency Swaps or LA Guarantees. Stock Exchange contracts can produce any MT5xx S.W.I.F.T. messages (using ISO15022 standards if required) by defining them using the SX Message Format (SXMFM) screen (see the Stock Exchange and Securities Management Guide for details). The formats for the following message types are supplied with the system and can be amended as necessary: MT520 Receive Free MT521 Receive Against Payment MT522 Deliver Free MT523 Deliver Against Payment MT540 Receive Free MT541 Receive Against Payment MT542 Deliver Free MT543 Deliver Against Payment A

231 Appendix B S.W.I.F.T. Confirmation Message Construction The confirmation example shown in this section are intended to represent typical messages sent by the system, and includes all mandatory fields and many of the optional fields as designated by S.W.I.F.T. In some cases, additional fields can be added when required by entering supplementary information into the Urbis system. Throughout the examples, differences between CHAPS and S.W.I.F.T. are highlighted in bold in the relevant CHAPS fields. The NewCHAPS fields are used in the following situations: Direct Confirmation is direct to counterparty Indirect Confirmation to counterparty via agent Indirect/Intermediary Confirmation to counterparty via intermediary MT 300 Foreign Exchange Confirmation Message details shown are included on a single line after the relevant field number and option letter unless indicated otherwise. S Tag Field Name Options *S.W.I.F.T. /TARGET *NewCHAPS Mandatory Sequence A General Information Direct *NewCHAPS Indirect *NewCHAPS Indirect/Intermediary M 15A New Sequence (CrLf) 15A 15A 15A 15A M 20 Sender's Reference 16x URB/ URB/ URB/ URB/ O 21 Related Reference 16x NEW NEW NEW NEW M 22A Type of Operation 4!c NEWT NEWT NEWT NEWT O 94A Scope of Operation M 22C Common Reference O 17T Block Trade Indicator O 17U Split Settlement Indicator 4!c 4!a2!c4!n 4!a2!c 1!a 1!a TRADH20015UNIBBB TRADH20015UNIBBB HAMB2L0015UNIBBB HAMB2L0015UNIBBB B 1

232 S.W.I.F.T. Confirmation Message Construction S Tag Field Name Options *S.W.I.F.T. /TARGET *NewCHAPS Direct *NewCHAPS Indirect *NewCHAPS Indirect/Intermediary M 82a Party A A, D or J UNIBBEBB UNIBBEBB UNIBBEBB UNIBBEBB M 87a Party B A, D or J TRADHHH2LXX TRADHHH2LXX HAMBGB2L HAMBGB2L O 83a Fund or Beneficiary Customer O 77D Terms and Conditions A, D or J 6*35x Mandatory Sequence B Transaction Details M 15B New Sequence (CrLf) 13 15B 15B 15B 15B M 30T Trade Date 8!n M 30V Value Date 8!n M 36 Exchange Rate 12d 16 1,5 1,5 1,5 1,5 Mandatory Subsequence B1 Amount Bought M 32B Currency, Amount 3!a15d 17 USD USD USD USD O 53a Delivery Agent A, D or J 18 TRADHHH2LXX TRADHHH2LXX TRADHHH2LXX HSBCFFF8HXX O 56a Intermediary A, D or J 19 M 57a Receiving Agent A, D or J 20 ABCABC5Z ABCABC5Z ABCABC5Z FGGGGG7M Mandatory Subsequence B2 Amount Sold M 33B Currency, Amount 3!a15d 21 GBP GBP GBP GBP O 53a Delivery Agent A, D or J 22 O 56a Intermediary A, D or J 23 FGLOUT6M FGGGGG7M FGGGGG7M FGGGGG7M 1.56D //SC XYZ BANK 3.9 ST SWITHINS ST 4.LONDON M 57a Receiving Agent A, D or J 24 TRADHHH2LXX 57D VIA CHAPS D //SC TRADING BANK HSBCFFF8HXX 3.1 ARCHES ST 4.LONDON O 58a Beneficiary Institution A, D or J 25 Optional Sequence C Optional General Information M 15C New Sequence (CrLf) 26 15C 15C 15C 15C O 29A Contact 4*35x 27 B

233 S.W.I.F.T. Confirmation Message Construction S Tag Field Name Options *S.W.I.F.T. /TARGET *NewCHAPS Information Direct *NewCHAPS Indirect *NewCHAPS Indirect/Intermediary O 24D Dealing Method 4!c[/35x] 28 BROK BROK BROK BROK O 84a Dealing Branch Party A A, B, D or J 29 O 85a Dealing Branch Party B A, B, D or J 30 O 88a Broker Identification A, D or J 31 88D GODSELL & CO BROKERS 88D GODSELL & CO BROKERS 88D GODSELL & CO BROKERS 88D GODSELL & CO BROKERS O 71F Broker's Commission 3!a15d 32 O 26H Counterparty's Reference 16x 33 O 21G Broker's Reference 16x 34 O 72 Sender to Receiver Information 6*35x 35 Optional Sequence D Split Settlement Details M 15D New Sequence (CrLf) 36 M 17A Buy (Sell) Indicator 1!a 37 M 32B Currency, Amount 3!a15d 38 O 53a Delivery Agent A, D or J 39 O 56a Intermediary A, D or J 40 M 57a Receiving Agent A, D or J 41 O 58a Beneficiary Institution M 16A Number of Settlements A, D or J 42 5n B 3

234 S.W.I.F.T. Confirmation Message Construction MT 305 Foreign Currency Option Confirmation Message details shown are included on a single after the relevant field number and option letter unless indicated otherwise. S Tag Field Name Options *S.W.I.F.T. /TARGET *NewCHAPS Direct *NewCHAPS Indirect *NewCHAPS Indirect/Intermediary M 20 Transaction Reference Number 16x URB/ URB/ URB/ URB/ M 21 Related Reference 16x NEW NEW NEW NEW M 22 Code/Common Reference 8a/4!a2!c 4!n4!a2!c NEWT NEWT NEWT NEWT M 23 Further Identification M 30 Date Contract Agreed/Amend O 31C Earliest Exercise Date 16x BUY/CALL/A/USD BUY/CALL/A/GBP BUY/CALL/A/GBP BUY/CALL/A/GBP 6!n !n M 31G Expiry Details 6!n/4!n/12 a O 31E Final Sett Date 6!n M 26F Settlement Type 9a PRINCIPAL PRINCIPAL PRINCIPAL PRINCIPAL M 32B Underlying Curr and Amt 3!a15d GBP GBP GBP GBP M 36 Strike Price 12d 1,5 1,5 1,5 1,5 M 33B Counter Currency and Amount 3!a15d USD USD USD USD M 37K Premium Price 3!a12d USD0,0055 USD0,0055 USD0,0055 USD0,0055 M 34a Premium Paymt P or R USD GBP35918, GBP35918, GBP35918,37 O 53a Sender's Correspondent A, B or D ABCABC5Z FGGGGG7M FGGGGG7M FGGGGG7M O 56a Intermediary A or D 1. 56D //SC XYZ BANK 3. 9 ST SWITHINS ST 4. LONDON M 57a Account With Institution A or D TRADHHH2LXX 57D VIA CHAPS D //SC TRADING BANK HSBCFFF8HXX 3. 1 ARCHES ST 4. LONDON O 77D Terms and Condns 6*35x O 72 Sender to Receiver Info 6*35x B

235 S.W.I.F.T. Confirmation Message Construction MT 320 Fixed Loan/Deposit Confirmation Message details shown are included on a single line after the relevant field number and option letter unless indicated otherwise. S Tag Field Name Options *S.W.I.F.T. /TARGET *NewCHAPS Mandatory Sequence A General Information Direct *NewCHAPS Indirect *NewCHAPS Indirect/Intermediary M 15A New Sequence (CrLf) 15A 15A 15A 15A M 20 Sender's Reference 16x URB/ /80000 URB/ / URB/ / URB/ / O 21 Related Reference 16x NEW NEW NEW NEW M 22A Type of Operation 4!c NEWT NEWT NEWT NEWT O 94A Scope of Operation 4!c M 22B Type of Event 4!c CONF CONF CONF CONF M 22C Common Reference O 21N Contract Number Party A 4!a2!c4!n 4!a2!c 16x TRADH20005UNIBBB TRADH20005UNIBBB HAMB2L0005UNIBBB HAMB2L0005UNIBBB M 82a Party A A, D or J UNIBBEBB UNIBBEBB UNIBBEBB UNIBBEBB M 87a Party B A, D or J TRADHHH2LXX TRADHHH2LXX HAMBGB2L HAMBGB2L O 83a Fund or Instructing Party O 77D Terms and Conditions A, D or J 6*35x Mandatory Sequence B Transaction Details M 15B New Sequence (CrLf) 15B 15B 15B 15B M 17R Party A's Role 1!a L or B L or B L or B L or B Lender or Borrower Lender or Borrower Lender or Borrower Lender or Borrower M 30T Trade Date 8!n M 30V Value Date 8!n M 30P Maturity Date 8!n M 32B Currency/ Princ Amnt O 32H Amount to be Settled O 30X Next Interest Due Date M 34E Currency and Interest Amount 3!a15d GBP GBP GBP GBP [N]3!a15d 8!n [N]3!a15d NGBP2739,73 NGBP2739,73 NGBP2739,73 NGBP2739, B 5

236 S.W.I.F.T. Confirmation Message Construction S Tag Field Name Options *S.W.I.F.T. /TARGET *NewCHAPS Direct *NewCHAPS Indirect *NewCHAPS Indirect/Intermediary M 37G Interest Rate [N]12d 5,0 5,0 5,0 5,0 M 14D Day Count Fraction O 30F Last Day of First Interest Period 7x AFI/365 AFI/365 AFI/365 AFI/365 8!n O 38J Number of Days 1!a3!n Mandatory Sequence C Settlement Instructions for Amounts Payable by Party A M 15C New Sequence (CrLf) 15C 15C 15C 15C O 53a Delivery Agent A, D or J FGLOUT6M FGGGGG7M FGGGGG7M FGGGGG7M O 86a Intermediary 2 A, D or J O 56a Intermediary A, D or J 1. 56D //SC XYZ BANK 3. 9 ST SWITHINS ST 4. LONDON M 57a Receiving Agent A, D or J TRADHHH2LXX 57D VIA CHAPS D //SC TRADING BANK 3. 1 ARCHES ST 4. LONDON HSBCFFF8HXX O 58a Beneficiary Institution A, D or J Mandatory Sequence D Settlement Instructions for Amounts Payable by Party B M 15D New Sequence (CrLf) 15D 15D 15D 15D O 53a Delivery Agent A, D or J TRADHHH2LXX TRADHHH2LXX TRADHHH2LXX TRADHHH2LXX O 86a Intermediary 2 A, D or J O 56a Intermediary A, D or J M 57a Receiving Agent A, D or J FGLOUT6M FGGGGG7M FGGGGG7M FGGGGG7M O 58a Beneficiary Institution A, D or J Optional Sequence E Settlement Instructions for Interests Payable by Party A M 15E New Sequence (CrLf) 15E-DEPOSIT 15E-DEPOSIT 15E-DEPOSIT 15E-DEPOSIT O 53a Delivery Agent A, D or J FGLOUT6M FGGGGG7M FGGGGG7M FGGGGG7M O 86a Intermediary 2 A, D or J O 56a Intermediary A, D or J 1. 56D //SC XYZ BANK 3. 9 ST SWITHINS ST B

237 S.W.I.F.T. Confirmation Message Construction S Tag Field Name Options *S.W.I.F.T. /TARGET *NewCHAPS Direct M 57a Receiving Agent A, D or J TRADHHH2LXX 57D VIA CHAPS *NewCHAPS Indirect 1. 57D //SC TRADING BANK 3. 1 ARCHES ST 4. LONDON *NewCHAPS Indirect/Intermediary 4. LONDON HSBCFFF8HXX O 58a Beneficiary Institution A, D or J Optional Sequence F Settlement Instructions for Interests Payable by Party B M 15F New Sequence (CrLf) 15F LOAN 15F LOAN 15F LOAN 15F LOAN O 53a Delivery Agent A, D or J TRADHHH2LXX TRADHHH2LXX TRADHHH2LXX HSBCFFF8HXX O 86a Intermediary 2 A, D or J O 56a Intermediary A, D or J M 57a Receiving Agent A, D or J FGLOUT6M FGGGGG7M FGGGGG7M FGGGGG7M O 58a Beneficiary Institution A, D or J Optional Sequence G Tax Information M 15G New Sequence (CrLf) M 37L Tax Rate 12d M 33B Transaction Currency and Net Interest Amount 3!a15d O 36 Exchange Rate 12d O 33E Reporting Currency and Tax Amount 3!a15d Optional Sequence H Additional Information M 15H New Sequence (CrLf) 15H 15H 15H 15H O 29A Contact Information 4*35x O 24D Dealing Method 4!c[/35x] PHON PHON PHON PHON O 84a Dealing Branch Party A O 85a Dealing Branch Party B O 88a Broker Identification O 71F Broker's Commission A, B, D or J A, B, D or J A, D or J 3!a15d O 26H Counterparty's 16x B 7

238 S.W.I.F.T. Confirmation Message Construction S Tag Field Name Options *S.W.I.F.T. /TARGET *NewCHAPS Direct Reference O 21G Broker's Reference 16x *NewCHAPS Indirect *NewCHAPS Indirect/Intermediary O 72 Sender to Receiver Information 6*35x B

239 S.W.I.F.T. Confirmation Message Construction MT 330 Call/Notice Loan/Deposit Confirmation Message details shown are included on a single line after the relevant field number and option letter unless indicated otherwise. S Tag Field Name Option *S.W.I.F.T. /TARGET *NewCHAPS Mandatory Sequence A General Information Direct *NewCHAPS Indirect *NewCHAPS Indirect/Intermediary M 15A New Sequence (CrLf) 15A 15A 15A 15A M 20 Sender's Reference 16x URB/ / URB/ / URB/ / URB/ / O 21 Related Reference 16x NEW NEW NEW NEW M 22A Type of Operation 4!c NEWT NEWT NEWT NEWT O 94A Scope of Operation 4!c M 22B Type of Event 4!c CONF CONF CONF CONF M 22C Common Reference O 21N Contract Number Party A 4!a2!c4!n 4!a2!c 16x TRADH20005UNIBBB TRADH20005UNIBBB HAMB2L0005UNIBBB HAMB2L0005UNIBBB M 82a Party A A, D or J UNIBBEBB UNIBBEBB UNIBBEBB UNIBBEBB M 87a Party B A, D or J TRADHHH2LXX TRADHHH2LXX HAMBGB2L HAMBGB2L O 83a Fund or Instructing Party O 77D Terms and Conditions A, D or J 6*35x Mandatory Sequence B Transaction Details M 15B New Sequence (CrLf) 15B 15B 15B 15B M 17R Party A's Role 1!a L/B L/B L/B L/B M 30T Trade Date 8!n M 30V Value Date 8!n M 38A Period of Notice 3n O 32B Currency and Balance O 32H Amount to be Settled 3!a15d GBP GBP GBP GBP [N]3!a15d O 30X Interest Due Date 8!n O 34E Currency and Interest Amount [N]3!a15d M 37G Interest Rate [N]12d 5,0 5,0 5,0 5, B 9

240 S.W.I.F.T. Confirmation Message Construction S Tag Field Name Option *S.W.I.F.T. /TARGET *NewCHAPS Direct *NewCHAPS Indirect *NewCHAPS Indirect/Intermediary M 14D Day Count Fraction O 30F Last Day of the Next Interest Period O 38J Number of Days 7x AFI/365 AFI/365 AFI/365 AFI/365 8!n 1!a3!n Mandatory Sequence C Settlement Instructions for Amounts Payable by Party A M 15C New Sequence (CrLf) 15C 15C 15C 15C O 53a Delivery Agent A, D or J FGLOUT6M FGGGGG7M FGGGGG7M FGGGGG7M O 86a Intermediary 2 A, D or J O 56a Intermediary A, D or J 1.56D //SC XYZ BANK 3.9 ST SWITHINS ST 4.LONDON M 57a Receiving Agent A, D or J TRADHHH2LXX 57D VIA CHAPS D //SC TRADING BANK 3.1 ARCHES ST 4.LONDON HSBCFFF8HXX O 58a Beneficiary Institution A, D or J Mandatory Sequence D Settlement Instructions for Amounts Payable by Party B M 15D New Sequence (CrLf) 15D 15D 15D 15D O 53a Delivery Agent A, D or J TRADHHH2LXX TRADHHH2LXX TRADHHH2LXX HSBCFFF8HXX O 86a Intermediary 2 A, D or J O 56a Intermediary A, D or J M 57a Receiving Agent O 58a Beneficiary Institution A, D or J FGLOUT6M FGGGGG7M FGGGGG7M FGGGGG7M A, D or J Optional Sequence E Settlement Instructions for Interests Payable by Party A M 15E New Sequence (CrLf) 15E 15E 15E 15E O 53a Delivery Agent A, D or J FGLOUT6M FGGGGG7M FGGGGG7M FGGGGG7M O 86a Intermediary 2 A, D or J O 56a Intermediary A, D or J 1.56D //SC XYZ BANK 3.9 ST SWITHINS ST B

241 S.W.I.F.T. Confirmation Message Construction S Tag Field Name Option *S.W.I.F.T. /TARGET *NewCHAPS Direct M 57a Receiving Agent A, D or J TRADHHH2LXX 57D VIA CHAPS *NewCHAPS Indirect 1.57D //SC TRADING BANK 3.1 ARCHES ST 4.LONDON *NewCHAPS Indirect/Intermediary 4.LONDON HSBCFFF8HXX O 58a Beneficiary Institution A, D or J Optional Sequence F Settlement Instructions for Interests Payable by Party B M 15F New Sequence (CrLf) 15F 15F 15F 15F O 53a Delivery Agent A, D or J TRADHHH2LXX TRADHHH2LXX TRADHHH2LXX HSBCFFF8HXX O 86a Intermediary 2 A, D or J O 56a Intermediary A, D or J M 57a Receiving Agent A, D or J FGLOUT6M FGGGGG7M FGGGGG7M FGGGGG7M O 58a Beneficiary Institution A, D or J Optional Sequence G Tax Information M 15G New Sequence (CrLf) M 37L Tax Rate 12d M 33B Transaction Currency and Net Interest Amount 3!a15d O 36 Exchange Rate 12d O 33E Reporting Currency and Tax Amount 3!a15d Optional Sequence H Additional Information M 15H New Sequence (CrLf) 15H 15H 15H 15H O 29A Contact Information 4*35x O 24D Dealing Method 4!c[/35x] PHON PHON PHON PHON O 84a Dealing Branch Party A O 85a Dealing Branch Party B O 26H Counterparty's Reference O 72 Sender to Receiver Information A, B, D or J A, B, D or J 16x 6*35x B 11

242 S.W.I.F.T. Confirmation Message Construction B

243 S.W.I.F.T. Confirmation Message Construction MT 340 Forward Rate Agreement Confirmation Message details shown are included on a single line after the relevant field number and option letter unless indicated otherwise. S Tag Field Name Option *S.W.I.F.T. /TARGET *NewCHAPS Mandatory Sequence A Conditions of the Contract Direct *NewCHAPS Indirect *NewCHAPS Indirect/Intermediary M 15A New Sequence (CrLf) 15A 15A 15A 15A M 20 Sender s Reference 16x URB/ / URB/ / URB/ / URB/ / O 21 Related Reference 16x NEW NEW NEW NEW M 22A Type of Operation 4!c NEWT NEWT NEWT NEWT O 94A Scope of Operation 4!c M 22C Common Reference 4!a2!c4!n 4!a2!c TRADH20007UNIBBB TRADH20045UNIBBB TRADH20007UNIBBB TRADH20045UNIBBB HAMB2L007UNIBBB HAMB2L045UNIBBB HAMB2L007UNIBBB HAMB2L045UNIBBB M 23D Type of FRA 10a FIXEDFLOAT FIXEDFLOAT FIXEDFLOAT FIXEDFLOAT O 21N Contract Number Party A O 21B Contract Number Party B 16x 16x M 82a Party A A or D UNIBBEBB UNIBBEBB UNIBBEBB UNIBBEBB M 87a Party B A or D TRADHHH2LXX TRADHHH2LXX HAMBGB2L HAMBGB2L M 77H Type, Date, Version of the Agreement 6a[/8!n][// 4!n] ISDA/ //1999 ISDA/ //1999 ISDA/ //1999 ISDA/ //1999 O 14C Year of Definitions 4!n Mandatory Sequence B Transaction Details M 15B New Sequence (CrLf) 15B 15B 15B 15B M 30T Trade Date 8!n M 32B Currency, Notional Amount 3!a15d GBP GBP GBP GBP M 30F Effective Date 8!n M 30P Termination Date 8!n M 37M Fixed Rate [N]12d 7,0/4,5 7,0/4,5 7,0/4,5 7,0/4,5 M 14F Floating Rate Option 24x OTHER-ISDA OTHER-ISDA OTHER-ISDA OTHER-ISDA Optional Subsequence B1 AFB and FRABBA Details M 30V Fixing Date 8!n B 13

244 S.W.I.F.T. Confirmation Message Construction S Tag Field Name Option *S.W.I.F.T. /TARGET *NewCHAPS Direct M 38D Contract Period 4n Mandatory Subsequence B2 Other Details *NewCHAPS Indirect *NewCHAPS Indirect/Intermediary M 38G Designated Maturity 2n1!a/2n1!a 12M/12M 12M/12M 12M/12M 12M/12M M 14D Floating Rate Day Count Fraction 7x AFI/365 AFI/365 AFI/365 AFI/365 M 17F FRA Discounting 1!a Y Y Y Y M 18A Number of Repetitions 5n M 22B Financial Centre 4!c GBLO GBLO GBLO GBLO Mandatory Sequence C Settlement Instructions for Settlement Amount Payable by Party B M 15C New Sequence (CrLf) 15C 15C 15C 15C O 53a Delivery Agent A, D or J TRADHHH2LXX TRADHHH2LXX TRADHHH2LXX HSBCFFF8HXX O 86a Intermediary 2 A, D or J O 56a Intermediary A, D or J M 57a Receiving Agent A, D or J FGLOUT6M FGGGGG7M FGGGGG7M FGGGGG7M O 58a Beneficiary Institution A, D or J Mandatory Sequence D Settlement Instructions for Settlement Amount Payable by Party A M 15D New Sequence (CrLf) 15D 15D 15D 15D O 53a Delivery Agent A, D or J FGLOUT6M FGGGGG7M FGGGGG7M FGGGGG7M O 86a Intermediary 2 A, D or J O 56a Intermediary A, D or J 1.56D //SC XYZ BANK 3.9 ST SWITHINS ST 4.LONDON M 57a Receiving Agent A, D or J TRADHHH2LXX 57D VIA CHAPS D SC TRADING BANK 3.1 ARCHES ST 4.LONDON HSBCFFF8HXX O 58a Beneficiary Institution A, D or J Optional Sequence E Additional Information M 15E New Sequence (CrLf) 15E 15E 15E 15E O 29A Contact Information 4*35x O 24D Dealing Method 4!c[/35x] PHON PHON PHON PHON B

245 S.W.I.F.T. Confirmation Message Construction S Tag Field Name Option *S.W.I.F.T. /TARGET *NewCHAPS Direct *NewCHAPS Indirect *NewCHAPS Indirect/Intermediary O 88a Broker Identification O 71F Broker's Commission A or D 3!a15d O 21G Broker's Reference 16x O 72 Sender to Receiver Information 6*35x B 15

246 S.W.I.F.T. Confirmation Message Construction MT 341 Forward Rate Agreement Settlement Confirmation Message details shown are included on a single line after the relevant field number and option letter unless indicated otherwise. S Tag Field Name Option *S.W.I.F.T. /TARGET *NewCHAPS Mandatory Sequence A General Information Direct *NewCHAPS Indirect *NewCHAPS Indirect/Intermediary M 15A New Sequence (CrLf) 15A 15A 15A 15A M 20 Sender s Reference 16x URB/ / URB/ / URB/ / URB/ / O 21 Related Reference 16x NEW NEW NEW NEW M 22A Type of Operation 4!c SETT SETT NEWT NEWT O 94A Scope of Operation 4!c M 22C Common Reference 4!a2!c4!n 4!a2!c TRADH20007UNIBBB TRADH20045UNIBBB TRADH20007UNIBBB TRADH20045UNIBBB HAMB2L007UNIBBB HAMB2L045UNIBBB HAMB2L007UNIBBB HAMB2L045UNIBBB 23D Type of FRA 10a FIXEDFLOAT FIXEDFLOAT FIXEDFLOAT FIXEDFLOAT O 21N Contract Number Party A O 21B Contract Number Party B 16x 16x M 82a Party A A or D UNIBBEBB UNIBBEBB UNIBBEBB UNIBBEBB M 87a Party B A or D TRADHHH2LXX TRADHHH2LXX HAMBGB2L HAMBGB2L O 29A Contact Information O 72 Sender to Receiver Information 4*35x 6*35x Mandatory Sequence B Transaction Details M 15B New Sequence (CrLf) 15B 15B 15B 15B M 30T Trade Date 8!n M 32B Currency, Notional Amount 3!a15d GBP GBP GBP GBP M 30F Effective Date 8!n M 30P Termination Date 8!n M 37M Fixed Rate [N]12d 7,0/4,5 7,0/4,5 7,0/4,5 7,0/4,5 Optional Subsequence B1 AFB and FRABBA Details O 30V Fixing Date 8!n O 38D Contract Period 4n B

247 S.W.I.F.T. Confirmation Message Construction S Tag Field Name Option *S.W.I.F.T. /TARGET *NewCHAPS Mandatory Sequence C Settlement Instructions for the Settlement Amount Direct *NewCHAPS Indirect *NewCHAPS Indirect/Intermediary M 15C New Sequence (CrLf) 15C 15C 15C 15C M 37R Settlement Rate [N]12d 6,1 6,1 6,1 6,1 M 34E Settlement Currency and Amount [N]3!a15d GBP3609,18/ NGBP7618,66 GBP4285,5/ NGBP7618,66 GBP4285,5/ NGBP7618,66 GBP4285,5/ NGBP7618,66 O 53a Delivery Agent A, D or J FGLOUT6M(Pay) FGGGGG6M(Pay) FGGGGG6M(Pay) O 86a Intermediary 2 A, D or J O 56a Intermediary A, D or J 1.56D //SC XYZ BANK 3.9 ST SWITHINS ST 4.LONDON M 57a Receiving Agent A, D or J TRADHHH2LXX(Pay) 57D VIA CHAPS (Pay)/ 57D VIA CHAPS 57D VIA CHAPS FGLOUT6M(Rec) (Rec) (Rec) (Rec) 1.57D //SC772199(Pay) 57A HSBCFFF8HXX(Pay) 2.TRADING BANK 3.1 ARCHES ST 4.LONDON O 58a Beneficiary Institution A, D or J B 17

248 S.W.I.F.T. Confirmation Message Construction MT 360 Single Currency Interest Rate Derivative Confirmation Message details shown are included on a single line after the relevant field number and option letter unless indicated otherwise. S Tag Field Name Options *S.W.I.F.T. /TARGET *NewCHAPS Mandatory Sequence A General Information Direct *NewCHAPS Indirect *NewCHAPS Indirect/Intermediary M 15A New Sequence (CrLf) 15A 15A 15A 15A M 20 Sender's Reference 16x URB/ URB/ URB/ URB/ O 21 Related Reference 16x NEW NEW NEW NEW M 22A Type of Operation 4!c NEWT NEWT NEWT NEWT O 94A Scope of Operation M 22C Common Reference 4!c 4!a2!c4!n 4!a2!c TRADH20201UNIBBB TRADH20201UNIBBB TRADH20201UNIBBB TRADH20201UNIBBB M 23A Identification of the Swap M 21N Contract Number Party A O 21B Contract Number Party B 10a/5a FIXED/FLOAT/GROSS FIXED/FLOAT/GROSS FIXED/FLOAT/GROSS FIXED/FLOAT/GROSS 16x x M 30T Trade Date 8!n M 30V Effective Date 8!n M 30P Termination Date 8!n O 14A Business Day Convention M 32B Currency, Notional Amount 9a 3!a15d GBP GBP GBP GBP M 82a Party A A or D UNIBBEBB UNIBBEBB UNIBBEBB UNIBBEBB M 87a Party B A or D TRADHHH2LXX TRADHHH2LXX HAMBGB2L HAMBGB2L O 17A Collateral Agreement Indicator M 77H Type, Date, Version of the Agreement O 77D Additional Conditions 1!a 6a[/8!n][// 4!n] 6*35x ISDA/ //1999 ISDA/ //1999 ISDA/ //1999 ISDA/ //1999 M 14C Year of Definitions 4!n O 72 Sender to Receiver 6*35x B

249 S.W.I.F.T. Confirmation Message Construction S Tag Field Name Options *S.W.I.F.T. /TARGET *NewCHAPS Direct Information Optional Sequence B Fixed Interest Payable by Party B M 15B New Sequence (CrLf) O 37U Fixed Rate 12d *NewCHAPS Indirect *NewCHAPS Indirect/Intermediary O 37N Details of Interest Rate 6*35x Optional Subsequence B1 Interest Details M 18A Number of Repetitions 5n M 30F Payment Date 8!n O 32M Currency, Payment Amount O 17F Period End Date Adjustment Indicator O 14D Day Count Fraction M 14A Business Day Convention M 18A Number of Repetitions M 22B Financial Centre 3!a15d 1!a 7x 9a 5n 4!c Optional Sequence C Floating Interest Payable by Party B M 15C New Sequence (CrLf) 15C 15C 15C 15C M 14F Floating Rate Option 24x OTHER OTHER OTHER OTHER O 37J Cap Rate 12d O 37L Floor Rate 12d O 37N Details of Interest Rate 6*35x Optional Subsequence C1 Interest Details M 14J Reset Date Specification O 14G Averaging Frequency and Method M 38E Designated Maturity M 18A Number of Repetitions 5a FIRST FIRST FIRST FIRST 1!a/8!a 2n1!a 1D 1D 1D 1D 5n B 19

250 S.W.I.F.T. Confirmation Message Construction S Tag Field Name Options *S.W.I.F.T. /TARGET *NewCHAPS Direct *NewCHAPS Indirect *NewCHAPS Indirect/Intermediary M 30F Payment Date 8!n M 17F Period End Date Adjustment Indicator M 14D Day Count Fraction M 14A Business Day Convention M 18A Number of Repetitions 1!a Y Y Y Y 7x AFI/365 AFI/365 AFI/365 AFI/365 9a FOLLOWING FOLLOWING FOLLOWING FOLLOWING 5n M 22B Financial Centre 4!c GBLO GBLO GBLO GBLO O 37R Spread [N]12d 0,0 0,0 0,0 0,0 Optional Subsequence C2 Compounding Details M 22D Compounding Type M 18A Number of Repetitions M 30X Compounding Date 4!c 5n 8!n Optional Subsequence C3 Interpolation for Stub Periods O 38G First Stub Period, Interpolation Period O 38H Last Stub Period, Interpolation Period 2n1!a/2n1!a 2n1!a/2n1!a Mandatory Sequence D Payment Instructions for Interest Payable by Party B M 15D New Sequence (CrLf) 15D 15D 15D 15D O 53a Delivery Agent A or D O 56a Intermediary A or D O 86a Second Intermediary A or D M 57a Receiving Agent A or D FGLOUT6M FGGGGG7M FGGGGG7M FGGGGG7M Optional Sequence E Fixed Interest Payable by Party A B

251 S.W.I.F.T. Confirmation Message Construction S Tag Field Name Options *S.W.I.F.T. /TARGET *NewCHAPS Direct *NewCHAPS Indirect *NewCHAPS Indirect/Intermediary M 15E New Sequence (CrLf) 15E 15E 15E 15E O 37U Fixed Rate 12d 5,0 5,0 5,0 5,0 O 37N Details of Interest Rate 6*35x Optional Subsequence E1 Interest Details M 18A Number of Repetitions 5n M 30F Payment Date 8!n O 32M Currency, Payment Amount O 17F Period End Date Adjustment Indicator O 14D Day Count Fraction M 14A Business Day Convention M 18A Number of Repetitions 3!a15d 1!a Y Y Y Y 7x AFI/365 AFI/365 AFI/365 AFI/365 9a FOLLOWING FOLLOWING FOLLOWING FOLLOWING 5n M 22B Financial Centre 4!c GBLO GBLO GBLO GBLO Optional Sequence F Floating Interest Payable by Party A M 15F New Sequence (CrLf) M 14F Floating Rate Option 24x O 37J Cap Rate 12d O 37L Floor Rate 12d O 37N Details of Interest Rate 6*35x Optional Subsequence F1 Interest Details M 14J Reset Date Specification O 14G Averaging Frequency and 5a 1!a/8!a B 21

252 S.W.I.F.T. Confirmation Message Construction S Tag Field Name Options *S.W.I.F.T. /TARGET *NewCHAPS Method Direct *NewCHAPS Indirect *NewCHAPS Indirect/Intermediary M 38E Designated Maturity M 18A Number of Repetitions 2n1!a 5n M 30F Payment Date 8!n M 17F Period End Date Adjustment Indicator M 14D Day Count Fraction M 14A Business Day Convention M 18A Number of Repetitions 1!a 7x 9a 5n M 22B Financial Centre 4!c O 37R Spread [N]12d Optional Subsequence F2 Compounding Details M 22D Compounding Type M 18A Number of Repetitions M 30X Compounding Date 4!c 5n 8!n Optional Subsequence F3 Interpolation for Stub Periods O 38G First Stub Period, Interpolation Period O 38H Last Stub Period, Interpolation Period 2n1!a/2n1!a 2n1!a/2n1!a Mandatory Sequence G Payment Instructions for Interest Payable by Party A M 15G New Sequence (CrLf) 15G 15G 15G 15G O 53a Delivery Agent A or D FGLOUT6M FGGGGG7M FGGGGG7M FGGGGG7M O 56a Intermediary A or D 1.56D //SC XYZ BANK 3.9 ST SWITHINS ST 4.LONDON O 86a Second A or D B

253 S.W.I.F.T. Confirmation Message Construction S Tag Field Name Options *S.W.I.F.T. /TARGET *NewCHAPS Direct Intermediary M 57a Receiving Agent A or D TRADHHH2LXX 57D VIA CHAPS Optional Sequence H Amortising Schedule M 15H New Sequence (CrLf) *NewCHAPS Indirect 1.57D //SC TRADING BANK 3.1 ARCHES ST 4.LONDON *NewCHAPS Indirect/Intermediary HSBCFFF8HXX M 18A Number of Repetitions M 30G Variable Notional Start and End Date M 32U Outstanding Notional Currency and Amount M 14A Business Day Convention M 18A Number of Repetitions 5n 8!n/8!n 3!a15d 9a 5n M 22B Financial Centre 4!c Optional Sequence L Additional Amounts Payable by Party B M 15L New Sequence (CrLf) M 18A Number of Repetitions 5n M 22E Type of Payment 4!c M 30F Payment Date 8!n M 32M Currency, Payment Amount M 14A Business Day Convention M 18A Number of Repetitions 3!a15d 9a 5n M 22B Financial Centre 4!c O 53a Delivery Agent A or D O 56a Intermediary A or D O 86a Second Intermediary A or D O 57a Receiving Agent A or D Optional Sequence M Additional Amounts Payable by Party A B 23

254 S.W.I.F.T. Confirmation Message Construction S Tag Field Name Options *S.W.I.F.T. /TARGET *NewCHAPS M 15M New Sequence (CrLf) Direct *NewCHAPS Indirect *NewCHAPS Indirect/Intermediary M 18A Number of Repetitions 5n M 22E Type of Payment 4!c M 30F Payment Date 8!n M 32M Currency, Payment Amount M 14A Business Day Convention M 18A Number of Repetitions 3!a15d 9a 5n M 22B Financial Centre 4!c O 53a Delivery Agent A or D O 56a Intermediary A or D O 86a Second Intermediary A or D O 57a Receiving Agent A or D Optional Sequence N Optional General Information M 15N New Sequence (CrLf) O 29A Contact Information 4*35x O 24D Dealing Method 4!c[/35x] O 88a Broker Identification O 71F Broker's Commission A or D 3!a15d O 21G Broker's Reference 16x B

255 S.W.I.F.T. Confirmation Message Construction MT 361 Cross Currency Interest Rate Swap Confirmation Message details shown are included on a single line after the relevant field number and option letter unless indicated otherwise. S Tag Field Name Options *S.W.I.F.T. /TARGET *NewCHAPS Mandatory Sequence A General Information Direct *NewCHAPS Indirect *NewCHAPS Indirect/Intermediary M 15A New Sequence (CrLf) 15A 15A 15A 15A M 20 Sender's Reference 16x URB/ / URB/ / URB/ / URB/ / O 21 Related Reference 16x NEW NEW NEW NEW M 22A Type of Operation 4!c NEWT NEWT NEWT NEWT O 94A Scope of Operation M 22C Common Reference 4!c 4!a2!c4!n 4!a2!c TRADH20201UNIBBB TRADH20201UNIBBB HAMB2L0201UNIBBB HAMB2L0201UNIBBB M 23A Identification of the Swap M 21N Contract Number Party A O 21B Contract Number Party B 10a/5a FIXED/FLOAT/GROSS FIXED/FLOAT/GROSS FIXED/FLOAT/GROSS FIXED/FLOAT/GROSS 16x / / / / x M 30T Trade Date 8!n M 30V Effective Date 8!n M 30P Termination Date O 14A Business Day Convention 8!n a M 32B Party B, Currency and Notional Amount 3!a15d GBP / EUR GBP / EUR GBP / EUR GBP / EUR M 33B Party A, Currency and Notional Amount 3!a15d EUR / GBP EUR / GBP EUR / GBP EUR / GBP M 82a Party A A or D UNIBBEBB UNIBBEBB UNIBBEBB UNIBBEBB M 87a Party B A or D TRADHHH2LXX TRADHHH2LXX HAMBGB2L HAMBGB2L O 17A Collateral Agreement Indicator M 77H Type, Date, Version of the 1!a 6a[/8!n][// 4!n] ISDA/ //1999 ISDA/ //1999 ISDA/ //1999 ISDA/ // B 25

256 S.W.I.F.T. Confirmation Message Construction S Tag Field Name Options *S.W.I.F.T. /TARGET *NewCHAPS Agreement Direct *NewCHAPS Indirect *NewCHAPS Indirect/Intermediary O 77D Additional Conditions 6*35x M 14C Year of Definitions 4!n O 72 Sender to Receiver Information 6*35x Optional Sequence B Fixed Interest Payable by Party B M 15B New Sequence (CrLf) O 37U Fixed Rate 12d O 37N Details of Interest Rate 6*35x Optional Subsequence B1 Interest Details M 18A Number of Repetitions 5n M 30F Payment Date 8!n O 32M Currency, Payment Amount O 17F Period End Date Adjustment Indicator O 14D Day Count Fraction M 14A Business Day Convention M 18A Number of Repetitions 3!a15d 1!a 7x 9a 5n M 22B Financial Centre 4!c Optional Sequence C Floating Interest Payable by Party B M 15C New Sequence (CrLf) 15C 15C 15C 15C M 14F Floating Rate Option 24x OTHER OTHER OTHER OTHER O 37J Cap Rate 12d O 37L Floor Rate 12d O 37N Details of Interest Rate 6*35x Optional Subsequence C1 Interest Details M 14J Reset Date Specification O 14G Averaging Frequency and 5a FIRST FIRST FIRST FIRST 1!a/8!a B

257 S.W.I.F.T. Confirmation Message Construction S Tag Field Name Options *S.W.I.F.T. /TARGET *NewCHAPS Method Direct *NewCHAPS Indirect *NewCHAPS Indirect/Intermediary M 38E Designated Maturity M 18A Number of Repetitions 2n1!a 1D 1D 1D 1D 5n M 30F Payment Date 8!n M 17F Period End Date Adjustment Indicator M 14D Day Count Fraction M 14A Business Day Convention M 18A Number of Repetitions 1!a Y Y Y Y 7x 360/ / / /360 9a FOLLOWING FOLLOWING FOLLOWING FOLLOWING 5n M 22B Financial Centre 4!c GBLO GBLO GBLO GBLO O 37R Spread [N]12d 0,0 0,0 0,0 0,0 Optional Subsequence C2 Compounding Details M 22D Compounding Type M 18A Number of Repetitions M 30X Compounding Date 4!c 5n 8!n Optional Subsequence C3 Interpolation for Stub Periods O 38G First Stub Period, Interpolation Period O 38H Last Stub Period, Interpolation Period 2n1!a/2n1!a 2n1!a/2n1!a Mandatory Sequence D Payment Instructions for Interest Payable by Party B M 15D New Sequence (CrLf) 15D 15D 15D 15D O 53a Delivery Agent A or D O 56a Intermediary A or D B 27

258 S.W.I.F.T. Confirmation Message Construction S Tag Field Name Options *S.W.I.F.T. /TARGET *NewCHAPS Direct *NewCHAPS Indirect *NewCHAPS Indirect/Intermediary O 86a Second Intermediary A or D M 57a Receiving Agent A or D FGLOUT6M(GBP) FGGGGG7M(GBP) FGGGGG7M(GBP) FGGGGG7M(GBP) FGLOUS2L(EUR) FGLOUS2L(EUR) FGLOUS2L(EUR) FGLOUS2L(EUR) Optional Sequence E Fixed Interest Payable by Party A M 15E New Sequence (CrLf) 15E 15E 15E 15E O 37U Fixed Rate 12d 5,0 5,0 5,0 5,0 O 37N Details of Interest Rate 6*35x Optional Subsequence E1 Interest Details M 18A Number of Repetitions 5n M 30F Payment Date 8!n O 32M Currency, Payment Amount O 17F Period End Date Adjustment Indicator O 14D Day Count Fraction M 14A Business Day Convention M 18A Number of Repetitions 3!a15d 1!a Y Y Y Y 7x 360/ / / /360 9a FOLLOWING FOLLOWING FOLLOWING FOLLOWING 5n M 22B Financial Centre 4!c GBLO GBLO GBLO GBLO FRPA FRPA FRPA FRPA 22B 22B 22B 22B 22B 22B 22B 22B 22B 22B 22B 22B 22B 22B 22B 22B Optional Sequence F Floating Interest Payable by Party A M 15F New Sequence (CrLf) M 14F Floating Rate 24x B

259 S.W.I.F.T. Confirmation Message Construction S Tag Field Name Options *S.W.I.F.T. /TARGET *NewCHAPS Direct Option O 37J Cap Rate 12d O 37L Floor Rate 12d *NewCHAPS Indirect *NewCHAPS Indirect/Intermediary O 37N Details of Interest Rate 6*35x Optional Subsequence F1 Interest Details M 14J Reset Date Specification O 14G Averaging Frequency and Method M 38E Designated Maturity M 18A Number of Repetitions M 30F Payment Date M 17F Period End Date Adjustment Indicator M 14D Day Count Fraction M 14A Business Day Convention M 18A Number of Repetitions 5a 1!a/8!a 2n1!a 5n 8!n 1!a 7x 9a 5n M 22B Financial Centre 4!c O 37R Spread [N]12d Optional Subsequence F2 Compounding Details M 22D Compounding Type M 18A Number of Repetitions M 30X Compounding Date 4!c 5n 8!n Optional Subsequence F3 Interpolation for Stub Periods O 38G First Stub Period, Interpolation Period O 38H Last Stub Period, Interpolation Period 2n1!a/2n1!a 2n1!a/2n1!a B 29

260 S.W.I.F.T. Confirmation Message Construction S Tag Field Name Options *S.W.I.F.T. /TARGET *NewCHAPS Mandatory Sequence G Payment Instructions for Interest Payable by Party A Direct *NewCHAPS Indirect *NewCHAPS Indirect/Intermediary M 15G New Sequence (CrLf) 15G 15G 15G 15G O 53a Delivery Agent A or D FGLOUSL2L(EUR) FGLOUSL2L(EUR) FGLOUSL2L(EUR) FGLOUSL2L(EUR) FGLOUT6M(GBP) FGGGGG7M(GBP) FGGGGG7M(GBP) FGGGGG7M(GBP) O 56a Intermediary A or D 1.56D XYZ BANK(EUR) 2.9 ST SWITHINS ST 3.LONDON 1.56D //SC421016(GBP) 2. XYZ BANK 3.9 ST SWITHINS ST 4.LONDON O 86a Second Intermediary A or D M 57a Receiving Agent A or D TRADHHH2LXX TRADHHH2LXX(EUR) TRADHHH2LXX(EUR) HSBCFFF8HXX 57D VIA CHAPS (GBP) Optional Sequence H Amortising Schedule for Party B M 15H New Sequence (CrLf) 1.57D //SC772199(GBP) 2.TRADING BANK 3.1 ARCHES ST 4.LONDON M 18A Number of Repetitions M 30G Variable Notional Start and End Date M 32U Outstanding Notional Currency and Amount M 14A Business Day Convention M 18A Number of Repetitions 5n 8!n/8!n 3!a15d 9a 5n M 22B Financial Centre 4!c M 15I New Sequence (CrLf) B

261 S.W.I.F.T. Confirmation Message Construction S Tag Field Name Options *S.W.I.F.T. /TARGET *NewCHAPS Direct *NewCHAPS Indirect *NewCHAPS Indirect/Intermediary M 18A Number of Repetitions M 30G Variable Notional Start and End Date M 32U Outstanding Notional Currency and Amount M 14A Business Day Convention M 18A Number of Repetitions 5n 8!n/8!n 3!a15d 9a 5n M 22B Financial Centre 4!c Optional Sequence J Exchanges of Principal Payable by Party B M 15J New Sequence (CrLf) M 18A Number of Repetitions 5n M 22X Type of Exchange 4!c M 30F Payment Date 8!n M 32M Currency, Payment Amount 3!a15d O 53a Delivery Agent A or D O 56a Intermediary A or D O 86a Second Intermediary A or D M 57a Receiving Agent A or D M 14A Business Day Convention M 18A Number of Repetitions 9a 5n M 22B Financial Centre 4!c Optional Sequence K Exchanges of Principal Payable by Party A M 15K New Sequence (CrLf) M 18A Number of Repetitions 5n M 22X Type of Exchange 4!c M 30F Payment Date 8!n M 32M Currency, Payment Amount 3!a15d O 53a Delivery Agent A or D B 31

262 S.W.I.F.T. Confirmation Message Construction S Tag Field Name Options *S.W.I.F.T. /TARGET *NewCHAPS O 56a Intermediary A or D Direct *NewCHAPS Indirect *NewCHAPS Indirect/Intermediary O 86a Second Intermediary A or D M 57a Receiving Agent A or D M 14A Business Day Convention M 18A Number of Repetitions 9a 5n M 22B Financial Centre 4!c Optional Sequence L Additional Amounts Payable by Party B M 15L New Sequence (CrLf) M 18A Number of Repetitions 5n M 22E Type of Payment 4!c M 30F Payment Date 8!n M 32M Currency, Payment Amount M 14A Business Day Convention M 18A Number of Repetitions 3!a15d 9a 5n M 22B Financial Centre 4!c O 53a Delivery Agent A or D O 56a Intermediary A or D O 86a Second Intermediary A or D O 57a Receiving Agent A or D Optional Sequence M Additional Amounts Payable by Party A M 15M New Sequence (CrLf) M 18A Number of Repetitions 5n M 22E Type of Payment 4!c M 30F Payment Date 8!n M 32M Currency, Payment Amount M 14A Business Day Convention M 18A Number of Repetitions 3!a15d 9a 5n B

263 S.W.I.F.T. Confirmation Message Construction S Tag Field Name Options *S.W.I.F.T. /TARGET *NewCHAPS Direct M 22B Financial Centre 4!c O 53a Delivery Agent A or D O 56a Intermediary A or D *NewCHAPS Indirect *NewCHAPS Indirect/Intermediary O 86a Second Intermediary A or D O 57a Receiving Agent A or D Optional Sequence N Optional General Information M 15N New Sequence (CrLf) O 29A Contact Information 4*35x O 24D Dealing Method 4!c[/35x] O 88a Broker Identification O 71F Broker's Commission A or D 3!a15d O 21G Broker's Reference 16x B 33

264 S.W.I.F.T. Confirmation Message Construction MT 364 Single Currency Interest Rate Derivative Termination/ Recouponing Message details shown are included on a single line after the relevant field number and option letter unless indicated otherwise. S Tag Field Name Options *S.W.I.F.T. /TARGET *NewCHAPS Mandatory Sequence A General Information Direct *NewCHAPS Indirect *NewCHAPS Indirect/Intermediary M 15A New Sequence (CrLf) 15A 15A 15A 15A M 20 Sender's Reference 16x URB/ URB/ URB/ URB/ O 21 Related Reference 16x NEW NEW NEW NEW M 22A Type of Operation 4!c NEWT NEWT NEWT NEWT O 94A Scope of Operation 4!c M 22B Type of Event 4!c PTRM PTRM PTRM PTRM M 22C Common Reference 4!a2!c4!n 4!a2!c TRADH20201UNIBBB TRADH20201UNIBBB HAMB2L0212UNIBBB HAMB2L0212UNIBBB M 23A Identification of the Swap M 21N Contract Number Party A O 21B Contract Number Party B M 30T Termination/Recou poning Trade Date M 30Q Termination/Recou poning Effective Date M 30P Original Termination Date M 30V Original Effective Date M 32B Current Currency, Notional Amount 10a/5a FIXED/FIXED/GROSS FIXED/FIXED/GROSS FIXED/FIXED/GROSS FIXED/FIXED/GROSS 16x x 8!n !n !n !n !a15d GBP GBP GBP GBP M 82a Party A A or D UNIBBEBB UNIBBEBB UNIBBEBB UNIBBEBB M 87a Party B A or D TRADHHH2LXX TRADHHH2LXX HAMBGB2L HAMBGB2L O 22D Accrual of Interest Specification O 32G New Currency, Notional Amount 4!c NEXT NEXT NEXT NEXT 3!a15d GBP GBP GBP GBP O 37N Details of Interest 6*35x B

265 S.W.I.F.T. Confirmation Message Construction S Tag Field Name Options *S.W.I.F.T. /TARGET *NewCHAPS Rate Direct *NewCHAPS Indirect *NewCHAPS Indirect/Intermediary O 29A Contact Information O 72 Sender to Receiver Information 4*35x 6*35x Optional Sequence B Fixed Interest Payable by Party B M 15B New Sequence (CrLf) 15B 15B 15B 15B M 37U Current Fixed Rate 12d 3,0 3,0 3,0 3,0 O 37P New Fixed Rate 12d Optional Sequence E Fixed Interest Payable by Party A M 15E New Sequence (CrLf) 15E 15E 15E 15E M 37U Current Fixed Rate 12d 5,0 5,0 5,0 5,0 O 37P New Fixed Rate 12d Optional Sequence L Fee Payable by Party B M 15L New Sequence (CrLf) M 30F Payment Date 8!n M 32M Currency, Payment Amount 3!a15d O 53a Delivery Agent A or D O 56a Intermediary A or D O 86a Second Intermediary A or D M 57a Receiving Agent A or D Optional Sequence M Fee Payable by Party A M 15M New Sequence (CrLf) M 30F Payment Date 8!n M 32M Currency, Payment Amount 3!a15d O 53a Delivery Agent A or D O 56a Intermediary A or D O 86a Second Intermediary A or D M 57a Receiving Agent A or D B 35

266 S.W.I.F.T. Confirmation Message Construction MT 365 Cross Currency Interest Rate Swap Termination/Recouponing Message details shown are included on a single line after the relevant field number and option letter unless indicated otherwise. S Tag Field Name Option *S.W.I.F.T. /TARGET *NewCHAPS Mandatory Sequence A General Information Direct *NewCHAPS Indirect *NewCHAPS Indirect/Intermediary M 15A New Sequence (CrLf) 15A 15A 15A 15A M 20 Sender's Reference 16x URB/ URB/ URB/ URB/ O 21 Related Reference 16x NEW NEW NEW NEW M 22A Type of Operation 4!c NEWT NEWT NEWT NEWT O 94A Scope of Operation 4!c M 22B Type of Event 4!c PTRM PTRM PTRM PTRM M 22C Common Reference 4!a2!c4!n 4!a2!c TRADH20201UNIBBB TRADH20201UNIBBB HAMB2L0212UNIBBB HAMB2L0212UNIBBB M 23A Identification of the Swap M 21N Contract Number Party A O 21B Contract Number Party B M 30T Termination/ Recouponing Trade Date M 30Q Termination/ Recouponing Effective Date M 30P Original Termination Date M 30V Original Effective Date 10a/5a FIXED/FIXED FIXED/FIXED FIXED/FIXED FIXED/FIXED 16x x 8!n !n !n !n M 32B Party B, Current Currency, Notional Amount 3!a15d GBP / EUR GBP / EUR GBP / EUR GBP / EUR M 33B Party A, Current Currency, Notional Amount 3!a15d EUR / GBP EUR / GBP EUR / GBP EUR / GBP M 82a Party A A or D UNIBBEBB UNIBBEBB UNIBBEBB UNIBBEBB M 87a Party B A or D TRADHHH2LXX TRADHHH2LXX HAMBGB2L HAMBGB2L B

267 S.W.I.F.T. Confirmation Message Construction S Tag Field Name Option *S.W.I.F.T. /TARGET *NewCHAPS Direct *NewCHAPS Indirect *NewCHAPS Indirect/Intermediary O 22D Accrual of Interest Specification 4!c NEXT NEXT NEXT NEXT O 32G Party B, New Currency, Notional Amount 3!a15d GBP600000/ EUR GBP600000/ EUR GBP600000/ EUR GBP600000/ EUR O 33E Party A, New Currency, Notional Amount 3!a15d EUR / GBP EUR / GBP EUR / GBP EUR / GBP O 37N Details of Interest Rate 6*35x O 29A Contact Information 4*35x O 72 Sender to Receiver Information 6*35x Optional Sequence B Fixed Interest Payable by Party B M 15B New Sequence (CrLf) 15B 15B 15B 15B M 37U Current Fixed Rate 12d 3,0 3,0 3,0 3,0 O 37P New Fixed Rate 12d Optional Sequence E Fixed Interest Payable by Party A M 15E New Sequence (CrLf) 15E 15E 15E 15E M 37U Current Fixed Rate 12d 5,0 5,0 5,0 5,0 O 37P New Fixed Rate 12d Optional Sequence J Re-exchange of Principal Payable by Party B M 15J New Sequence (CrLf) 15J 15J 15J 15J M 30F Payment Date 8!n M 32M Currency, Payment Amount 3!a15d GBP / EUR GBP / EUR GBP / EUR GBP / EUR O 53a Delivery Agent A or D O 56a Intermediary A or D O 86a Second Intermediary A or D M 57a Receiving Agent A or D FGLOUT6M(GBP) FGGGGG7M(GBP) FGGGGG7M(GBP) FGGGGG7M(GBP) FGLOUS2L(EUR) FGLOUS2L(EUR) FGLOUS2L(EUR) FGLOUS2L(EUR) Optional Sequence K Re-exchange of Principal Payable by Party A M 15K New Sequence (CrLf) 15K 15K 15K 15K M 30F Payment Date 8!n M 32M Currency, Payment Amount 3!a15d EUR / GBP EUR / GBP EUR / GBP EUR / GBP B 37

268 S.W.I.F.T. Confirmation Message Construction S Tag Field Name Option *S.W.I.F.T. /TARGET *NewCHAPS Direct *NewCHAPS Indirect *NewCHAPS Indirect/Intermediary O 53a Delivery Agent A or D FGLOUS2L(EUR) FGLOUS2L(EUR) FGLOUS2L(EUR) FGLOUS2L(EUR) FGLOUT6M(GBP) FGGGGG7M(GBP) FGGGGG7M(GBP) FGGGGG7M(GBP) O 56a Intermediary A or D 1.56D XYZ BANK(EUR) 2.9 ST SWITHINS ST 3.LONDON 1.56D //SC421016(GBP) 2. XYZ BANK 3.9 ST SWITHINS ST 4.LONDON O 86a Second Intermediary A or D M 57a Receiving Agent A or D TRADHHH2LXX TRADHHH2LXX(EUR) 57D VIA CHAPS (GBP) Optional Sequence L Fee Payable by Party B M 15L New Sequence (CrLf) M 30F Payment Date 8!n TRADHHH2LXX(EUR) 1.57D //SC772199(GBP) 2.TRADING BANK 3.1 ARCHES ST 4.LONDON HSBCFFF8HXX M 32M Currency, Payment Amount 3!a15d O 53a Delivery Agent A or D O 56a Intermediary A or D O 86a Second Intermediary A or D M 57a Receiving Agent A or D Optional Sequence M Fee Payable by Party A M 15M New Sequence (CrLf) M 30F Payment Date 8!n M 32M Currency, Payment Amount 3!a15d O 53a Delivery Agent A or D O 56a Intermediary A or D B

269 S.W.I.F.T. Confirmation Message Construction S Tag Field Name Option *S.W.I.F.T. /TARGET *NewCHAPS Direct *NewCHAPS Indirect *NewCHAPS Indirect/Intermediary O 86a Second Intermediary A or D M 57a Receiving Agent A or D B 39

270 S.W.I.F.T. Confirmation Message Construction MT 518 Market-Side Securities Trade Confirmation Message details shown are included on a single line after the relevant field number and option letter(s) unless indicated otherwise. There are no differences between S.W.I.F.T./TARGET and CHAPS for MT518 messages. S Tag Qualifier Generic Field Name Detailed Field Name Option Securities Repurchase Agreements Mandatory Sequence A General Information M 16R Start of Block GENL GENL GENL M 20C SEME Reference Sender's Reference 4!c//16x SEME//URB/ SEME//URB/ M 23G Function of the Message 4!c[/4!c] NEWM NEWM O 98a PREP Date/Time Preparation Date/Time A or C M 22F TRTR Indicator Trade Transaction Type Indicator 4!c/[8c]/4!c TRTR//TRAD TRTR//TRAD Repetitive Optional Subsequence A1 Linkages M 16R Start of Block LINK O 13A LINK Number Identification Linked Transaction 4!c//3!c M 20C 4!c Reference (see qualifier description) 4!c//16x M 16S End of Block LINK End of Optional Subsequence A1 Linkages M 16S End of Block GENL GENL GENL End of Sequence A General Information Mandatory Sequence B Confirmation Details M 16R Start of Block CONFDET CONFDET CONFDET M 98a 4!c Date/Time (see qualifier description) A, B or C TRAD// SETT// TRAD// SETT// M 90a DEAL Price Deal Price A or B DEAL//PRCT/100,0 DEAL//PRCT/100,0 O 99A DAAC Number Count Number of Days Accrued 4!c//[N]3!n O 94B TRAD Place Place of Trade 4!c/[8c]/4!c[/ 30x] O 19A SETT Amount Settlement Amount 4!c//[N]3!a1 5d SETT//USD SETT//USD M 22a 4!c Indicator (see qualifier description) F or H 22H BUSE//BUYI 22H PAYM//APMT 22H BUSE//SELL 22H PAYM//APMT O 11A 4!c Currency (see qualifier description) 4!c//3!a B

271 S.W.I.F.T. Confirmation Message Construction S Tag Qualifier Generic Field Name Detailed Field Name Option Securities Repurchase Agreements Repetitive Mandatory Subsequence B1 Confirmation Parties M 16R Start of Block CONFPRTY CONFPRTY CONFPRTY M 95a 4!c Party (see qualifier description) O 97a 4!c Account (see qualifier description) P, Q, R or S 95PSELL//HAMBGB2L 95PBUYR//HAMBGB2L A or B O 98a PROC Date/Time Processing Date/Time A or C O 20C PROC Reference Processing Reference 4!c//16x O 70a 4!c Narrative (see qualifier description) O 22F TRCA Indicator Party Capacity Indicator C, D or E 4!c/[8c]/4!c M 16S End of Block CONFPRTY CONFPRTY CONFPRTY End of Mandatory Subsequence B1 Confirmation Parties M 36B CONF Quantity of Financial Instrument Quantity of Financial Instrument Confirmed 4!c//4!c/15d CONF//FAMT/ CONF//FAMT/ M 35B Identification of Financial Instrument [ISIN1!e12!c ][4*35x] AMORT995 AMORT991 Optional Subsequence B2 Financial Instrument Attributes M 16R Start of Block FIA O 22F 4!c Indicator (see qualifier description) 4!c/[8c]/4!c O 12a 4!c Type of Financial Instrument (see qualifier description) A, C or B O 11A DENO Currency Currency of Denomination O 98A 4!c Date/Time (see qualifier description) O 92A 4!c Rate (see qualifier description) O 13a 4!c Number Identification (see qualifier description) O 17B 4!c Flag (see qualifier description) O 90a 4!c Price (see qualifier description) O 36B 4!c Quantity of (see qualifier description) O 70E FIAN Narrative Financial Instrument Attribute Narrative 4!c//3!a 4!c//8!n 4!c//[N]15d A or B 4!c//1!a A or B 4!c//4!c/15d 4!c//10*35x M 16S End of Block FIA CONFDET CONFDET B 41

272 S.W.I.F.T. Confirmation Message Construction S Tag Qualifier Generic Field Name Detailed Field Name Option Securities Repurchase Agreements End of Optional Subsequence B2 Financial Instrument Attributes O 13B CERT Number Identification Certificate Numbers 4!c/[8c]/30x O 70E TPRO Narrative Trade Instruction Processing Narrative 4!c//10*35x M 16S End of Block CONFDET End of Sequence B Confirmation Details Optional Sequence C Settlement Details M 16R Start of Block SETDET SETDET SETDET M 22F 4!c Indicator (see qualifier description) 4!c/[8c]/4!c SETR//TRAD SETR//REPO O 17B ACRU Flag Accrued Interest Flag 4!c//1!a O 11A 4!c Currency (see qualifier description) 4!c//3!a Repetitive Optional Subsequence C1 Settlement Parties M 16R Start of Block SETPRTY 1.SETPRTY 2.SETPRTY 3.SETPRTY 4.SETPRTY 1.SETPRTY 2.SETPRTY 3.SETPRTY 4.SETPRTY M 95a 4!c Party (see qualifier) C, P, Q, R or S 1.95PSELL/HAMBGB2L 2.95PBUYR//UNIBBEBBA 3.95PDECU//FGLOUS2L 4.95PRECU//FGLOUS2L 1.95PBUYR/HAMBGB2L 2.95PSELLR//UNIBBEBBA 3.95PRECU//FGLOUS2L 4.95PDECU//FGLOUS2L O 97a SAFE Account Safekeeping Account A or B 3.SAFE//10 4.SAFE//1 3.SAFE//10 4.SAFE//1 O 98a PROC Date/Time Processing Date/Time A or C O 20C PROC Reference Processing Reference 4!c//16x O 70a 4!c Narrative (see qualifier description) C or D M 16S End of Block SETPRTY 1.SETPRTY 2.SETPRTY 3.SETPRTY 4.SETPRTY 1.SETPRTY 2.SETPRTY 3.SETPRTY 4.SETPRTY End of Optional Subsequence C1 Settlement Parties Repetitive Optional Subsequence C2 Cash Parties M 16R Start of Block CSHPRTY M 95a 4!c Party (see qualifier description) P, Q, R or S O 97A 4!c Account (see qualifier 4!c//35x B

273 S.W.I.F.T. Confirmation Message Construction S Tag Qualifier Generic Field Name Detailed Field Name Option Securities Repurchase Agreements description) O 70a 4!c Narrative (see qualifier description) C or D M 16S End of Block CSHPRTY End of Optional Subsequence C2 Cash Parties Repetitive Optional Subsequence C3 Amounts M 16R Start of Block AMT M 19A 4!c Amount (see qualifier description) 4!c//[N]3!a1 5d O 98a VALU Date/Time Value Date A or C O 92B EXCH Rate Exchange Rate 4!c//3!a/3!a/ 15d M 16S End of Block AMT End of Optional Subsequence C3 Amounts M 16S End of Block SETDET SETDET SETDET End of Sequence C Settlement Details Repetitive Optional Sequence D Other Parties M 16R Start of Block OTHRPRTY M 95a 4!c Party (see qualifier description) O 97a 4!c Account (see qualifier description) O 70a 4!c Narrative (see qualifier description) P, Q, R or S A or B C or D O 20C PROC Reference Processing Reference 4!c//16x M 16S End of Block OTHRPRTY End of Sequence D Other Parties Optional Sequence E Repo Details M 16R Start of Block REPO REPO O 98a REPU Date/Time Repurchase Date/Time A, B or C REPU O 22F 4!c Indicator (see qualifier description) 4!c/[8c]/4!c RERT//FIXE MICO//A004 O 20C SECO Reference Second Leg Reference 4!c//16x O 92a 4!c Rate (see qualifier description) O 99B CADE Number Count Repurchase Call Delay C or A 4!c//3!n REPO/5,0 O 19A 4!c Amount (see qualifier 4!c//[N]3!a1 REPA/ , B 43

274 S.W.I.F.T. Confirmation Message Construction S Tag Qualifier Generic Field Name Detailed Field Name Option Securities Repurchase Agreements description) 5d REPP/5567,9 ACRU/5567,9 DEAL/ O 70C REPO Narrative Repurchase Narrative 4!c//4*35x M 16S End of Block REPO REPO End of Sequence E Repo Details B

275 Index A ACATM screen, 4-5 to 4-6 Accepted STP Settlements, 1-24 Accounting and Exposure Amount Parameters screen, 1-12 Accounting Authorisation Queue, 1-12, 4-2 Accounting Authorisation Queue screen Description of, 4-3 Example screen, 4-4 Accounting Authorisation screen Description of, 4-5 Example screen, 4-5 ACEXM screen, 1-12 ACQUE screen, 4-3 to 4-4 AGDFI screen, 2-8 AGDFM screen, 2-6 to 2-7 Agent Default Inquiry screen Description of, 2-8 Example screen, 2-8 Agent Details screen description of, 2-2 example of, 2-3 Agent Inquiry screen description of, 2-5 example of, 2-5 Agent Settlement Defaults screen Description of, 2-6 Example screen, 2-7 AGNTI screen, 2-5 AGNTM screen, 2-2 to 2-4 Authorise Release of Event Messages for LA Participants screen Description of, 6-8 Example screen, 6-8 Authorise Release of Event Messages screen Description of, 6-5 Example screen, 6-7 Authorising Netting Settlements, AWBOI screen, 3-3 to 3-4 AWSTI screen, 3-5 to 3-6 C CASMI, 6-14 CDATI screen, 2-19 CHAPS, 1-10 CISIM screen, 2-16 to 2-18 Clean Payment Status, 8-3 Clean Payment Defaults Maintenance description of, 8-4 Clean Payment Screen Flow, 1-18 Clean Payments, 8-1 Introduction, 8-1 Overview of, 1-16 Clean Payments Addition screen Description of, 8-6 Clean Payments Authorisation description of, 8-15 example of, 8-15 Clean Payments Inquiry be Product description of, 8-23 example of, 8-24 Clean Payments Inquiry by Account description of, 8-22 example of, 8-22 Client Account Management Services, 1-21 Client Netting Agreement Description of, 10-7 Example of, 10-7 Client Netting Agreement - Currency Cut Off Days Description of, 10-8 Example of, 10-8 Client Netting Agreement - Product, Client Settlement Instructions for LA screen Description of, 2-17 Example screen, 2-17 CLS Introduction, 1-29 Screens, 11-1 Setting Up, 1-29 Using, 1-30 CLS Balance Breakdown Inquiry (CLSCI) Description of, Example of, Index-1

276 Index CLS Balance Inquiry (CLSBI) Description of, 11-8 Example of, 11-9 CLS Counterparty Maintenance (CLSCM) Description of, 11-4 Example of, 11-5 CLS Currency Maintenance (CLSCY) Description of, 11-6 Example of, 11-7 CLS Provider Detail Maintenance (CLSDM) Description of, 11-2 Example of, 11-3 Contract Authorisation, 1-3 Entry, 1-2 Contract Management Queue, 1-3, 3-2, 3-3 Contract Settlement Queue, 1-3, 3-2, 3-5 CP100, 8-10 CP101, 8-11 CP102, 8-11, 8-12 CP202, 8-13 CP203, 8-13 CPACQ, 8-22 CPAUT, 8-15 CPAY1 screen, 8-2 to 8-8 CPAYC, 8-17 CPAYI, 8-19 CPDFM, 8-4 CPINI, 8-27 CPMT1, 8-21 CPMT2, 8-21 CPMT3, 8-21 CPMT4, 8-21 CPMT5, 8-21 CPMT6, 8-21 CPPRQ, 8-23 Credit/Debit Advices, 1-12 CSDM Screen, 5-3 D Deals Input Confirmation screen Description of, 3-3 Example screen, 3-4 DEPAI screen, 5-7 DEPAM Screen, 5-5 DEPCI screen, 5-11 Depository Maintenance (CSDM) Description of, 5-3 Example of, 5-4 Depot Account Holdings Position Inquiry (DEPSI) Description of, 5-10 Example of, 5-10 Depot and Account Definition (DEPAM) Description of, 5-5 Example of, 5-5 Depot and Account Definition Inquiry (DEPAI) Description of, 5-7 Example of, 5-8 Depot Defaults (SPSTM) Description of, 5-6 Example of, 5-6 Depot Defaults Inquiry (SPSTI) Description of, 5-9 Example of, 5-9 Depot Holdings Transaction Inquiry (DEPCI) Description of, 5-11 Example of, 5-11 Depots Introduction, 1-14 Screens, 5-3 Setting Up, 1-15, 5-2 Using, 1-15 DEPSI screen, 5-10 E Entering Netting Agreements, 10-6 Establishing Netting, 1-27 Euro Related Information, 1-31 F Field Names Definitions, 12-1 to I Incoming Clean Payments Inquiry description of, 8-27 example of, 8-27 Inward Payment Screen Flow, 1-19 Index

277 Index L LA Client Settlement Instructions Authorisation Queue screen Description of, 2-19 Example screen, 2-19 LA Fee Settlement Authorisation screen Description of, 7-4 Example of, 7-4 LA Fee Settlement Confirmation screen Description of, 7-3 LAFAM screen, 7-4 LARSM screen, 7-3 Loans Administration Fee Settlements, 7-1 Introduction, 7-1 Screens, 7-2 M MESSA screen, 6-12 to 6-13 Message Generation, 1-4 Manual Production, 1-6 Repair, 1-5 Review, 1-5 Update Protection, 1-6 MESSR screen, 6-9 to 6-10 MSGI screen, 8-29 MSGSI screen, 8-25 MT100 Additional Details, 8-9 MT100 Inquiry screens, 8-21 MT202 Additional Details, 8-13 MT202 Inquiry screens, 8-21 N NETCN, NETTA screen, Netted Payments Inquiry Example of, Netted Settlements - Authorise Example of, 10-13, Netted Settlements - Lead In Description of, Example of, NETTI screen, Netting Authorising Settlements, Entering Agreements, 10-6 Establishment of, 1-27 Inquiries, Types, Setting Up, 10-2 Netting Agreements Inquiry Example of, Netting Type Maintenance Description of, 10-3 Example of, 10-3 Netting Type to Account Centre Linkage Description of, 10-5 Example of, 10-5 Netting Type to Product Linkage, 10-4 Non Standard Settlement Instructions for Pay Agents screen Example screen, 2-9 Nostro Default Inquiry screen Description of, 2-16 Example screen, 2-16 Nostro Details screen Description of, 2-11 Example screen, 2-13 Nostro Settlement Defaults screen Description of, 2-14 Example screen, 2-15 Nostro Transfer Add screen Description of, 9-3 Example of, 9-3 Nostro Transfer Reversal screen Description of, 9-4 Example of, 9-4 Nostro Transfers Introduction, 9-1 Overview of, 1-21 Screens, 9-2 NSDFI screen, 2-16 NSDFM screen, 2-14 to 2-15 NSTRO screen, 2-11 to 2-13 NSXFA screen, 9-3 NSXFR screen, 9-4 NTACM, 10-8 NTAGI screen, NTAGM, 10-7 NTAPM, NTBRM, 10-5 NTTPM, 10-4 NTTYM, Index-3

278 Index O Outbound S.W.I.F.T. Message Inquiry (MSGSI) Description of, 8-25 Example of, 8-26 Output from Message Inquiry (MSGI) Description of, 8-29 Example of, 8-29 Outstanding Settlement Messages screen Description of, 6-3 Example screen, 6-4 Outward Clean Payments Authorisation description of, 8-17 example of, 8-18 Outward Clean Payments Inquiry description of, 8-19 example of, 8-20 P Paper Settlement, 1-14 Paper Settlement Authorisation Queue Description of, 4-8 Example screen, 4-9 Paper Settlement Queue, 1-14, 4-7 Payment Instruction Narratives screen Description of, 2-20 Example screen, 2-20 PCNRM screen, 2-16 to 2-20 Pending Queue, 1-21 Process Flow, 1-2 PSQUE screen, 4-8 to 4-9 Q Queues Accounting Authorisation, 1-12, 4-2 Contract Management, 1-3, 3-2, 3-3 Contract Settlement, 1-3, 3-2, 3-5 Paper Settlement, 1-14, 4-7 R Rejected STP Settlements, 1-25 S S.W.I.F.T. IBAN Numbers, 1-11 S.W.I.F.T. BIC Codes, 1-7 S.W.I.F.T. CASmf Interface Inquiry description of, 6-14 Example of, 6-14 S.W.I.F.T. Message Security, 1-5 S.W.I.F.T. Message Status, 1-5 Securities Settlement, 1-14 Security for SWIFT Tag Codes screen Description of, 2-21 Example screen, 2-23 SETCN screen, 6-3 to 6-4 SETTA screen, 6-5 to 6-7 SETTB screen, 6-7 to 6-8 Setting up Netting Types, 10-2 Settlement Instructions Confirmation screen Description of, 3-5 Example screen, 3-6 Settlement Message Add Description of, 6-12 Example screen, 6-13 Settlement Message Review and Repair Description of, 6-9 Example screen, 6-10 Settlements Process Flow, 1-2 SPSTI screen, 5-9 SPSTM screen, 5-6 STAGA screen, 2-21 to 2-23 Static Data Introduction, 2-1 STP Accepted STP Settlements, 1-24 Netting, 1-28 Rejected STP Settlements, 1-25 Settlement Authorisation, 1-23 Work Flow, 1-22 Straight Through Processing, 1-22 T TARGET, 1-9 Index