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 June 2004 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 Section 5. Depots Introduction Screen Flow for Setting Up Depots Setting Up Depots Screens Depository Maintenance (CSDM) xii

13 Contents 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) Inward Clean Payments Screens Outbound S.W.I.F.T. Message Inquiry (MSGSI) Incoming Clean Payments Inquiry (CPINI) Output from Message Inquiry (MSGI) xiii

14 Contents Section 9. Nostro Transfers Introduction Nostro Transfer Screens Nostro Transfer Inquiry (NSXFI) Nostro Transfer Maintenance (NSXFM) Nostro Transfer Queue (NSXFQ) 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 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 xiv

15 Contents 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 13 MT 341 Forward Rate Agreement Settlement Confirmation... B 16 MT 360 Single Currency Interest Rate Derivative Confirmation... B 18 MT 361 Cross Currency Interest Rate Swap Confirmation.. B 25 MT 364 Single Currency Interest Rate Derivative Termination/ Recouponing... B 34 MT 365 Cross Currency Interest Rate Swap Termination/Recouponing... B 36 MT 518 Market-Side Securities Trade Confirmation... B 40 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 xvii

18 Figures 6 3. Authorise Release of Event Messages screen Authorise Release of Event Messages for LA Participants screen 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 Inquiry screen Nostro Transfer Maintenance screen Nostro Transfer Queue 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 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. On double clicking the record displayed, with the criteria BIC Code, all the details including Agent Nickname, Chaps Address will be displayed in another popup window. On double clicking the record displayed, with the criteria Nickname, all the details including Chaps Address, SWIFT Address will be displayed in another popup window. 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

28 Overview of Settlements The following figure is an example of the BIC Directory window that allows you to inquire on BIC codes. 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. The system allows entering a Clean payment to credit a Nostro account without sending any payment messages. It is possible to send payments messages for a clean payment that credits a Vostro or GL account. 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 Maintenance (NSXFM) 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 Related Account, 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'. Related Account The intermediary related account of the agent

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 field are used by the CHAPS messaging system to route settlement messages for agents and intermediaries

56 Static Data The following figure shows an example of the Agent Details screen. 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. The Related account field defines the intermediary related account of the agent. 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 only for payment agents, for use by a contract or a particular diary event for a contract. 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

62 Static Data The following figure shows an example of the Non Standard Settlement Instructions for Pay Agents screen: 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. Whether or not the nostro bank requires us to issue MT103/ MT200/ MT202 (General Financial Institution Transfer) advices via S.W.I.F.T. The intermediary BIC code and related account number for nostros 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 MT103/200/202 Advices via S.W.I.F.T. Flag Whether or not the MT103/MT200/MT202 advices via S.W.I.F.T. should be generated for this nostro Switch 'On' - Produce MT103/MT200/MT202 advices via S.W.I.F.T. Switch 'Off' - Suppress MT103/MT200/MT202 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. Intermediary BIC Code This is the intermediary Bank Identification code for the nostro. Nostro Intermediary Related Account This is the related account number for the nostro intermediary. 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. To facilitate intermediary for nostros enter the Intermediary BIC Code and Nostro Intermediary Related Account details. 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. If the Nostro and Agent are in different countries and the settlement instructions are not in the euro currency, you must enter an intermediary, a valid agent, as the beneficiary. 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

70 Static Data The following figure shows an example of the Client Settlement Instructions for LA screen. 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 Static Data The following figure shows an example of the Security for SWIFT Tag Codes screen: Figure Security for SWIFT Tag Codes screen

76 Static Data

77 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

78 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

79 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

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

81 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

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

83 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

84 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

85 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

86 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

87 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:

88 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

89 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

90 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

91 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

92 Accounting Authorisation and Paper Settlements

93 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

94 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

95 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

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

97 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

98 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

99 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

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

101 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

102 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

103 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

104 Depots

105 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

106 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

107 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

108 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. The screen does not display messages that were included as part of a Netting Agreement. To view a summary of the outstanding messages for a contract on the Authorise Release of Event Messages (SETTA) screen, 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

109 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). Copy Confirmation messages (this includes messages with COPY that appear next to ACTION). 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

110 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

111 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

112 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

113 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

114 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

115 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

116 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

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

118 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

119 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

120 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

121 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

122 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

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

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

125 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

126 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

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

128 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. You can enter a Clean payment to credit a Nostro account without sending any payment messages. It is also possible to send payment messages for a clean payment that credits a Vostro or GL account. If the blueprint parameter BP-EXTD-NARR is set to YES, the system permits extended narratives for clean payments. The 5 additional lines referred to as Extended Narrative are maintained (added/ changed/ deleted/ inquired) on the Extended Narratives pop up window. To enter the extended narrative, double mouse click the Notepad icon next to Debit and Credit posting narrative field and it opens the Extended Narratives pop up window. If the extended narratives exist, the Notes icon is displayed. On the extended narratives pop up window the first line as entered on the clean payment screen will be displayed and the following five lines can be entered. Click Ok to transfer the data to the CPAYA screen or click Close to close the window without the changing the data or click Clear to remove the data. 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

129 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

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

131 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 becom e 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

132 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

133 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

134 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

135 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

136 Clean Payments 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. Figure 8-8. Clean Payments Message Input Screen Two 202 screen

137 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). For either side (debit or credit) of payment, if extended narrative exists, icon is displayed and double clicking on it will open the pop up window to view the extended narrative. 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

138 Clean Payments The following figure is an example of the Clean Payments Authorisation (CPAUT) screen. Figure 8-9. Clean Payments Authorisation screen

139 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. You can enter a Clean payment to credit a Nostro account without sending any payment messages. It is also possible to send payment messages for a clean payment that credits a Vostro or GL account. 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. If BP-EXTD-NARR is set to YES and extended narratives exists, an icon is displayed next to the posting narrative field on either side (debit or credit), double clicking on it will open the pop up window to enter the extended narrative. 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

140 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

141 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. If extended narrative exists, an icon is displayed next to the posting narrative field on either side (debit or credit), double clicking on it will open the pop up window to enter the extended narrative

142 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

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

144 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

145 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

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

147 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

148 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

149 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

150 Clean Payments Figure Inward Clean Payments Inquiry screen

151 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

152 Clean Payments

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

154 Nostro Transfers Nostro Transfer Screens This section provides a description of the following Nostro Transfer screen. Nostro Transfer Inquiry (NSFXI) Nostro Transfer Maintenance (NSXFM) Nostro Transfer Queue (NSXFQ) 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

155 Nostro Transfers Nostro Transfer Inquiry (NSXFI) The Nostro Transfer Inquiry screen displays various Nostro transfer records. All fields other than the contract number are inquiry only fields. This screen is linked from the Nostro Transfer Queue (NSXFQ) or the CLS Balance Inquiry (CLSBI) screens. The screen could also be invoked by itself and a Nostro Transfer Contract number could be keyed in. It will read the Nostro Transfer record corresponding to the Contract number entered or passed through Link. The following figure shows an example of the Nostro Transfer Inquiry Screen. Figure 9 1. Nostro Transfer Inquiry screen

156 Nostro Transfers Nostro Transfer Maintenance (NSXFM) The Nostro Transfer Maintenance screen is used to add / reverse, change and authorise 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. 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 Maintenance (NSXFM) screen to perform the reversal. See Section 11 for more information. Nostro transfer contracts can be changed, provided they are in unauthorized state, but not yet posted. Nostro transfer contracts can be deleted, if it is in unauthorised or authorised state, but not yet posted. Authorisation will always be carried out by a user other than the one who did the last mentioned actions

157 Nostro Transfers The following figure shows an example of the Nostro Transfer Maintenance Screen. Figure 9 2. Nostro Transfer Maintenance screen

158 Nostro Transfers Nostro Transfer Queue (NSXFQ) The Nostro Transfer Queue screen lists all nostro transfer records that satisfy the screen filter values. From this queue, user will be able to link to the Nostro Transfer Maintenance (NSXFM) screen to modify, authorise or delete the Nostro transfer transaction or to create a reversal contract. Link is provided to the Nostro Transfer Inquiry (NSXFI) screen. The screen will list all the Nostro Transfer contracts with various details such as: The Accounting Centre for which the Nostro Transfer contract was created The value date and the input date The amount and currency The pay & receive nostro The current status of the Nostro Transfer contract The last updated action, the date and the user who did the last update. Every nostro transfer contract listed on NSXFQ screen can be linked to screens such as: Nostro Transfer Inquiry (NSXFI) Nostro Transfer Maintenance (NSXFM)

159 Nostro Transfers The following figure shows an example of the Nostro Transfer Queue Screen. Figure 9 3. Nostro Transfer Queue screen

160 Nostro Transfers

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

162 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

163 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

164 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

165 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

166 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

167 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. If List Constituent Settlements on MT299 is checked, the individual settlement details will be included in the MT299 netting confirmation to the respective 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

168 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

169 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

170 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

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

172 Netting of Contracts 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

173 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. The netting decision on this screen will be defaulted to Yes. 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. Enter the value in the Start Contract Number field to limit the list of contracts starting from the value entered. 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. Only valid combinations of nostros and agents can be entered in the Our Pay Nostro, Their Recieve Agent, Our Recieve Nostro and Their Pay Agent fields. Standard settlement instructions can be entered to use the default settings for the nostro and agent for the client or the netting product. These instructions can be applied to the contract by entering SSI in the required Receive/Pay Nostro/Agent fields. Netting Contract number is generated for the netted settlement when the screen is shown and this contract number holds the non standard settlement instructions if any added. Click Settlement Instructions to set up any non standard settlement instruction NSTDM screen

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

175 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

176 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

177 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

178 Netting of Contracts

179 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

180 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

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

182 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

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

184 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

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

186 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. If the CLS Nostro Transfer contract has been created for either of the currencies, then the contract number, status and if there is any error for the same, will be displayed. 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 Maintenance (NSXFM) 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

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

188 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