• Author / Uploaded
• Kiran Kumar Reddy

Citation preview

Straight Through Processing (STP) Release: R19 AMR May 2019

Information in this document is subject to change without notice. No part of this document may be reproduced or transmitted in any form or by any means, for any purpose, without the express written permission of TEMENOS HEADQUARTERS SA. © 2019 Temenos Headquarters SA - all rights reserved.

Straight Through Processing (STP)

Table of Contents Introduction

3

Purpose of this Guide

3

Intended Audience

3

Overview

4

ISO 15022

4

SWIFT categorises ISO 15022 messages as

4

Trade Initiation and Confirmation messages (TIC)

4

Settlement and Reconciliation messages (S&R)

5

Configuration Parameter Files Deal Processing

7 8 12

Straight Through Processing Messages

12

MT502 Order to Buy or Sell

13

MT509 Trade status message

18

MT513 Client Advice of Execution

20

MT514 Trade Allocation Instruction

21

MT515 Client Confirmation of Purchase or Sale

22

Aggregation of MT515

25

MT544 Receive free confirmation

33

MT545 Receive against payment confirmation

34

MT546 Deliver free confirmation

35

MT547 Delivery against payment confirmation

36

Contractual and Actual Processing

37

MT509 Trade status message (Outward)

38

MT549 Request for Statement or Status Advice

42

Settlement Allegement - MT578 Message

44

Swift MX messages

49

MX Messages in T24

68

2

Straight Through Processing (STP)

Introduction Purpose of this Guide This document explains the Securities STP Module which is designed to achieve Straight Through Processing (STP) with SWIFT messages in the T24.

Intended Audience This User Guide is intended for the use of Internal Temenos users and Clients.

3

Introduction

Straight Through Processing (STP)

Overview the set of ISO 15022 messages introduced by SWIFT. Straight Through Processing1 is the next step in the evolution of Banking systems for the Securities industry.

ISO 15022 ISO 15022 is the messaging standard introduced by SWIFT for the Securities Industry. It is introduced in response to market demand for Straight Through Processing. It replaces the previous standards ISO 7775 – Scheme for Message Types and ISO 11521 – Scheme for Inter-Depository message types. The ISO 15022 series of messages replaced the ISO 7775 series of messages from November 2002 onwards. The introduction of the ISO 15022 series of messages facilitates a T+1 (Trade date + 1) settlement scenario.

SWIFT categorises ISO 15022 messages as l

Trade Initiation and Confirmation messages (TIC)

l

Settlement and Reconciliation messages (S&R)

l

Corporate Action messages (CA)

Refer the Securities Corporate Actions User Guide, for more details in the support of T24 Corporate Actions messages. In addition, the T24Securities Straight Through Processing (SP) module supports: l

Trade Initiation and Confirmation messages (TIC)

l

Settlement and Reconciliation messages (S&R)

Trade Initiation and Confirmation messages (TIC) The following are the messages supported by T24, which form part of the Trade Initiation and Confirmation series: l

MT 502 Order to Buy or Sell

l

MT 509 Trade status message

1Straight Through Processing (STP) is an initiative used by companies in the fin-

ancial world to optimize the speed at which transactions are processed. This is performed by allowing information that has been electronically entered to be transferred from one party to another in the settlement process without manually re-entering the same pieces of information repeatedly over the entire sequence of events.

Overview

4

Straight Through Processing (STP)

l

MT 513 Client Advice of Execution

l

MT 514 Trade Allocation Instruction

l

MT 515 Client Confirmation of Purchase or Sale

The following diagram illustrates the flow of messages between the T24applications.

Settlement and Reconciliation messages (S&R) The following are the messages supported by T24 which forms part of the Settlement and Reconciliation Messages series: l

MT 544 Receive free confirmation

l

MT 545 Receive against payment confirmation

l

MT 546 Deliver free confirmation

l

MT 547 Delivery against payment confirmation

The following diagram illustrates the flow of messages between T24applications:

5

Overview

Straight Through Processing (STP) .

Overview

6

Straight Through Processing (STP)

Configuration The following section explain the various parameters associated with STP. l

7

Parameter Files

Configuration

Straight Through Processing (STP)

Parameter Files SP.STP.PARAM SP.STP.PARAM is the parameter file for driving Straight Through Processing (STP) functionality. SP.STP.PARAM facilitates the controlling of STP in separate components.The components of STP are the SWIFT messages, which are controlled by the Securities Straight Through Processing Module. All the components of STP are to be selected, if a full STP system is to be installed. As there might be a requirement for partial STP (for example, Settlement is controlled through STP and Order processing is done manually), the SP.STP.PARAM can be setup accordingly, to suit the business requirement. The ID of SP.STP.PARAM is the company ID. Each company has a separate parameter record.

Figure 1 - SP.STP.PARAM

Configuration

8

Straight Through Processing (STP)

OFS.SOURCE An OFS.SOURCE record is to be setup as shown in the below screen shot. This OFS.SOURCE record defines the IN.QUEUE.DIR, OUT.QUEUE.DIR and the IN.DIR.RTN

Figure 2 - OFS.SOURCE

EB.PHANTOM An EB.PHANTOM record is to be setup as shown in the below screen shot.

9

Configuration

Straight Through Processing (STP) Figure 3 - EB.PHANTOM Refer the OFS User Guide, for more details regarding the OFS.SOURCE and EB.PHANTOM applications.

SC.PARAMETER The SC.CLASS.TYPE and EB.CLASS.TYPE fields in SC.PARAMETER must be inputted as shown in the below screen shot.

Figure 4 - SC.PARAMETER SC.CLASS.TYPE is the internal class used in the Securities module. SC.CLASS.TYPE and EB.CLASS.TYPE provide the class mapping between internal securities classes and EB.MESSAGE.CLASS.EB.CLASS.TYPE allows a valid EB.MESSAGE.CLASS record to be input. The EB.MESSAGE.CLASS must be used in the EB.ADVICES record. This facilitates the addition of new mapping records locally for each activity. With the above set up all the inward messages will be processed and the respective applications will be updated and authorised. Halt STP and Trade authorisation In a full STP Order Process, Orders are placed, executed and Trades created in Live status automatically. However, there may be scenarios where it is required to amend Market Settlement instructions, Broker fees and or non-standard Value date and so on. In such cases, it is possible to halt the STP process in-between to allow manual intervention. It is possible to parameterise this at CUSTOMER.SECURITY level for specific Brokers or at SECURITY.MASTER level for specific Securities. It is also possible to set this at

Configuration

10

Straight Through Processing (STP) the time of Order Creation, that is at SEC.OPEN.ORDER level or even at execution stage that is, in SC.EXE.SEC.ORDERS The following two fields are available in all the above applications and can be set as required. l

l

EXE.HLT - Indicates if the Execution must be halted and raise an Override. If this is set, then the SC.EXE.SEC.ORDERs record is left on 'Hold', even after receiving the STP inward confirmation. Users can make amendments and then authorise the record. TRADE.HLT – Indicates if the Automatic Trade authorisation is to be halted. If this is set, then the SEC.TRADE is left in 'IHLD' status, even if inward confirmation is received through STP. Users can make amendments and then authorise the record. Note: In SEC.OPEN.ORDER these fields are populated from the CUSTOMER.SECURITY record of the Broker if available, else from the SECURITY.MASTER record. In SC.EXE.SEC.ORDERS the fields are populated from the SEC.OPEN.ORDER application.

Information in this document is subject to change without notice. No part of this document may be reproduced or transmitted in any form or by any means, for any purpose, without the express written permission of TEMENOS HEADQUARTERS SA. © 2019 Temenos Headquarters SA - all rights reserved.

11

Configuration

Straight Through Processing (STP)

Deal Processing Straight Through Processing Messages The following are the messages that are handled in the Straight Through Processing module: l

MT502 Order to Buy or Sell

l

MT509 Trade status message

l

MT513 Client Advice of Execution

l

MT514 Trade Allocation Instruction

l

MT515 Client Confirmation of Purchase or Sale

l

Aggregation of MT515

l

MT544 Receive free confirmation

l

MT545 Receive against payment confirmation

l

MT546 Deliver free confirmation

l

MT547 Delivery against payment confirmation

l

Contractual and Actual Processing

l

MT509 Trade status message (Outward)

l

MT549 Request for Statement or Status Advice

l

Swift MX messages

l

MX Messages in T24

Deal Processing

12

Straight Through Processing (STP)

MT502 Order to Buy or Sell This message is primarily used for placing an order to the Broker for a Buy or Sell. This message is generated from the SEC.OPEN.ORDER application. This message uses the Soft Delivery method for processing the deliveries. MT502 is generated, if the MSG.TYPE field in SP.STP.PARAM is set to '502'. This message is primarily used for placing an order to the Broker for a Buy or Sell. This message is generated from the SEC.OPEN.ORDER application. This message uses the Soft Delivery method for processing the deliveries. MT502 is generated, if the MSG.TYPE field in SP.STP.PARAM is set to '502' and ADVICE REQD field in SEC.OPEN.ORDER is set to 'YES'. Soft Delivery facilitates the preview of SWIFT messages in their unauthorised status.

Figure 5 - Preview of an MT502 Order to Buy or Sell The Carrier (SWIFT) in the OVR.CARRIER field can be overridden at the Contract level. The SWIFT address of the Broker can be input or overridden in the Order application.

13

Deal Processing

Straight Through Processing (STP)

Figure 6 – SEC.OPEN.ORDER Soft Delivery The MT502 Order to Buy or Sell has three functions. The functions of MT502 are classified as follows: l

NEW MESSAGE - A new Order is placed to the Broker.

l

REPLACEMENT - The existing Order with the Broker is modified.

l

CANCELLATION - The existing Order with the Broker is cancelled .

All of the above functions are defined as different activities in T24. An example of a new Order is shown in the below screen shot.

Deal Processing

14

Straight Through Processing (STP)

Figure 7 - MT502 - New Message Once the MT502 - new message is generated, no fields other than the NO.NOMINAL and AMT.TO.BROKER is allowed for changing in SEC.OPEN.ORDER application. The change to NO.NOMINAL and AMT.TO.BROKER triggers an MT502 replacement message. An example of an MT502 replacement message is shown in the below screen shot.

Figure 8 - MT502 Replacement Message

15

Deal Processing

Straight Through Processing (STP) Reversal of a SEC.OPEN.ORDER and deletion of a Broker multi-value set, generates an MT502 cancellation message. An example of an MT502 cancellation message is shown in the below screen shot.

Figure 9 - MT502 Cancellation Message When an MT502 replacement or cancellation is sent, the same is to be accepted or rejected by the Broker with the MT509 Trade Status Message. To facilitate this functionality two application live files are used to record the replacement and cancellation details. SP.ORDER.DELIVERY.CONTROL

When a SEC.OPEN.ORDER is modified or cancelled, then an application live file SP.ORDER.DELIVERY.CONTROL is updated. This live file holds the details of any modification made to the AMT.TO.BROKER and the effect on the Customer's NO.NOMINAL fields in SEC.OPEN.ORDER record.

Deal Processing

16

Straight Through Processing (STP)

Figure 10 - SP.ORDER.DELIVERY.CONTROL SP.ORDER.STP.ACTIVITY

This application live file is updated when an MT502 replacement or cancellation is sent. This file denotes the status of an MT502 replacement or a cancellation that has been sent. If the BR.MSG.STATUS field has a value of 'LIVE', then there is no MT509 pending from a Broker. If the BR.MSG.STATUS is null, then an MT509 trade status message is expected from a Broker. If the status is ACCEPTED or REJECTED, the MT509 is received from the respective Brokers and the update to SEC.OPEN.ORDER is pending.

Figure 11 - SP.ORDER.STP.ACTIVITY

17

Deal Processing

Straight Through Processing (STP)

MT509 Trade status message This message is designed as an Inward or Outward message in T24. The MT509 is processed only if the MSG.TYPE field in SP.STP.PARAM is set to '509'. This message is processed by a phantom defined in EB.PHANTOM. An MT509 Trade Status Message can be used in T24 for receiving the status of previously sent MT502 messages for replacement or cancellation. The status advised in an MT509 can be ACCEPTED or REJECTED. Depending on the status advised, an action is triggered. If the MT502 replacement or cancellation is rejected by an MT509, then the SEC.OPEN.ORDER is modified accordingly. The AMT.TO.BROKER field for the respective Broker is suitably modified. When the AMT.TO.BROKER field in SEC.OPEN.ORDER is modified, the customer NO.NOMINAL must also be modified. The modification details are stored in the SP.ORDER.DELIVERY.CONTROL application. When an MT509 advises Acceptance or Rejection, this is recorded in SP.ORDER.STP.ACTIVITY application. Modifications to SEC.OPEN.ORDER and SC.EXE.SEC.ORDERS is not allowed until all MT509 messages are received.

SP.ORD.MANUAL.UPD However, if a SEC.OPEN.ORDER must be modified or an execution is to be input, then the SP.ORDER.STP.ACTIVITY must be set to 'LIVE' in BR.MSG.STATUS for all the Brokers. This can be achieved manually through the SP.ORD.MANUAL.UPD application.

Figure 12- SC.ORD.MANUAL.UPD

Deal Processing

18

Straight Through Processing (STP) In the SC.ORD.MANUAL.UPD application, the respective Broker number from whom the MT509 is pending can be input and the ACCEPTED or REJECTED status is manually entered. This action updates SC.ORDER.STP.ACTIVITY and triggers the necessary changes.

19

Deal Processing

Straight Through Processing (STP)

MT513 Client Advice of Execution This is an Inward message which is processed in T24. The MT513 is processed, only if the MSG.TYPE field in SP.STP.PARAM is set to '513'. This message is received from a Broker to whom previously the MT502 Order to Buy or Sell was sent. This message advises the execution of the Order in full or in part. This message is processed by a phantom job defined in EB.PHANTOM application. Currently, T24 processes only advice of execution (new message) and does not process a cancellation of execution. This message updates the SC.EXE.SEC.ORDERS with the execution details received from the Broker. The following fields in SC.EXE.SEC.ORDERS is updated from MT513 received from the Broker: l

BROKER.NO

l

NOMINAL.RECD

l

PRICE

Deal Processing

20

Straight Through Processing (STP)

MT514 Trade Allocation Instruction This is an Outward message from T24. The MT514 is processed only if the MSG.TYPE field in SP.STP.PARAM is set to '514'. This message is sent to the Broker for each allocation made out of the execution MT514. The Trade allocation message carries one allocation only at a time, hence there is multiple MT514s generated from an execution (MT513). Each MT514 Trade Allocation Instruction has the SEC.TRADE ID as a reference. Trade allocation instructions is sent only if the TRADE.CREATION field in SC.EXE.SEC.ORDERS is set as BY.PORTFOLIO Trade allocation instructions is sent only if the TRADE.CREATION field in SC.EXE.SEC.ORDERS is set to BY.PORTFOLIO and ADVICE.REQD is set to 'YES' in SC.EXE.SEC.ORDERS. The ADVICE.REQD can be set to YES, only if TRADE.AGGREGATION is not set to YES for the Broker.

21

Deal Processing

Straight Through Processing (STP)

MT515 Client Confirmation of Purchase or Sale MT515 is an Inward message from the Broker advising confirmation of a Purchase or Sale for each MT514 previously sent. The MT515 is processed only if the MSG.TYPE field in SP.STP.PARAM is set to '515'. This message is processed by the OFS.GLOBUS.MANAGER, which processes the MT515s and authorise the respective SEC.TRADE The MT515 directly completes the SEC.TRADE For example Fund Orders, only an MT515 is received (without an MT513). In such instances, the MT515 automatically completes and authorises the Order Execution (SC.EXE.SEC.ORDERS) record and creates a Trade (SEC.TRADE). The Trade record is created either in IHLD or LIVE status depending on the Authorise Trade field. On receiving MT515 Inward string message, the system validates whether the reference is SEC.TRADE reference (SCTRSC) or SEC.OPEN.ORDER reference (OPODSC). If the reference is SEC.OPEN.ORDER reference, then the system processes the MT515 message and checks for the values in the corresponding SC.EXE.SEC.ORDERS record and executes the record. The values from MT515 are mapped to the fields in SC.EXE.SEC.ORDERS The tags that are taken for authorising SC.EXE.SEC.ORDERS record are detailed in the below table. MT515

SC.EXE.SEC.ORDERS

:98A::TRAD//

TRADE.DATE

:98A::SETT//

VALUE.DATE

90B::/DEAL//ACTU

PRICE

36B::CONF/UNIT

NOMINAL.RECD

:90B::TSTM//

INT.CRT

:19A::CHAR//

BR.BROKER.COMM

:19A::EXEC// :19A::OTHR//

Deal Processing

22

Straight Through Processing (STP)

23

Deal Processing

Straight Through Processing (STP) Executing Orders

Delivery A Delivery advice is created automatically with all relevant information relating to the transaction.

Delivery message

Deal Processing

24

Straight Through Processing (STP)

Aggregation of MT515 Some Brokers send Aggregated MT515 messages. The Aggregation is mainly done for Administrative convenience and for lowering the costs, as there is fewer SWIFT messages and fewer Settlements. The messages are grouped by certain pre-defined criteria and only one message is sent by the Broker per group. The use of Aggregated messages allows reconciling the Aggregated messages with the pre-execution messages (MT513) received from the Broker and their Underlying transactions. As a consequence of this Aggregation, the Settlement instructions sent to the custodian (MT541 – Receive against payment, MT543- Deliver against payment) is also Aggregated. When Settlement status (MT548) and confirmation (MT545 or MT547) is received from the custodian, they must be desegregated and reconciled with the Underlying trades in the System before updating the status or processing the Settlement for individual Trades. A diagrammatic representation of the flow of messages are shown in the below screen shot.

The various business events in the Order flow and their corresponding T24 actions are detailed in the below table:

25

Deal Processing

Straight Through Processing (STP)

A diagrammatic representation of the above flow (with multiple Orders) is shown in the below screen shot.

In this case, the MT515 messages are not aggregated. For each Purchase or Sale, an individual confirmation is sent by the Broker that is then used to authorize the individual Trades in T24. The system can handle Aggregated Trade confirmation messages received from a Broker, if TRADE.AGGREGATION field is set to 'YES' in the CUSTOMER.SECURITY record for that Broker. In this case, the Broker sends one MT515 message for a number of Trades having the same grouping parameters. Once an Aggregated message is received, it must be reconciled with the pending Trades pertaining to these confirmations. If Aggregation is to be set by Stock Exchange for a Broker, then the STK.EXC.AGGREGATE field in CUSTOMER.SECURITY must be set to 'YES'. The AGGREGATION field must be set to 'YES' in the STOCK.EXCHANGE record, for those Stock Exchanges for which aggregation is required. For example, the system

Deal Processing

26

Straight Through Processing (STP) Aggregates only those Trades of the Broker in a Stock Exchange which is set for Aggregation. In short, if STK.EXC.AGGREGATE is set, then the Trades are Aggregated; only if both Broker and Stock exchange conditions are met.. The Aggregation of MT515 is based on the following grouping parameters: l

Broker

l

Security Number (Instrument)

l

Transaction Type – Buy/Sell

l

Trade Currency

l

Trade Date

l

Settlement (Value) Date

l

Depository

l

Delivery Instruction and

l

Stock Exchange

Once an Order is executed and the SC.EXE.SEC.OREDERS are authorized, a record is created in SP.AGGREGATION (the ID of Aggregation record is the SEC TRADE ID). Noted: That a record is created in SP.AGGREGATION only for Trades where an allocation instruction (MT514) is not required to be sent to the Broker. In case of transactions where allocation instructions are sent, an individual confirmation (MT515) is received for each allocation sent. Note: The back-dated transactions are not included for Aggregation and as a result, is not updated in the Aggregation table and the Reconciliation table. The confirmations for these transactions are handled either manually or based on individual confirmation (MT515) received from the Broker. The Aggregation holds the following details: Record 1

27

Deal Processing

Straight Through Processing (STP)

Record 2

A record is then built in the Reconciliation table (SP.RECONCILIATION), based on the Aggregation parameters specified. If a record already exists for the group (the ID is the concatenation of the Aggregation parameters specified), the quantity and amount details are adjusted to reflect the new transaction being added to the

Deal Processing

28

Straight Through Processing (STP) group. If no record exists for the group, a new record is created. The Transactions are added to the Reconciliation record till the time the status of the Reconciliation record is changed to ‘MATCHED’ or till the cut-off time is set, or whichever is earlier.

When an Aggregated MT515 message is received from the Broker, the Incoming message is reconciled with the record with the same grouping parameters. If there is no existing Reconciliation record for the group, a new record is created in the Reconciliation table with details (including nominal and amount) from the Incoming message. The status of the record is set to ‘UNMATCHED’ and the Status Narrative is updated as ‘NOREC’. If a record exists for the group and has a status ‘MATCHED’, it means that the Reconciliation is already performed against an earlier MT515 and the new message must be placed in the repair queue. If there is a record with the same grouping parameters in ‘PENDING’ status, then Reconciliation is attempted. If there is no match, then the status of the group must be changed to 'Unmatched' and the reason for Reconciliation failure is also updated. The reason for this could be either:

29

Deal Processing

Straight Through Processing (STP)

l

Matching record for the group not found

l

Quantity not matched or

l

Amount not matched.

In order to allow small discrepancies in amount, the tolerance levels are provided. The tolerance (expressed in percentage terms) are specified in the CONF.TOL.PERC field in the CUSTOMER.SECURITY. If there is a difference in the amounts between the Incoming message and the Reconciliation record, then the difference is within the tolerance specified. The status is still set to ‘Matched’, but the status narrative is updated as ‘MTCHTOL’. If there is a match, then: 1. All the Underlying trades belonging to the group are authorized. 2. Status is be set to MATCHED. 3. Settlement instruction (MT541 or MT543) is generated to be sent to the custodian, provided the Aggregation of Settlement instruction (SETTLE.AGGREGATION field in CUSTOMER.SECURITY) is set. Note: This Aggregation only pertains to MT541 and MT543 and not the free of payment transactions. 4. Settlement instruction reference is updated in the Reconciliation record. The Settlement status is set to ‘PENDING’. If a Reconciliation record exists and has the status ‘Unmatched’, it means that a previous attempt to Reconciliation has failed. The MT515 reference updated in the Reconciliation record is replaced with the new MT515 ID and the Reconciliation attempted again. If the Reconciliation has failed, the users can perform one or more of the following actions: l

l

l

Remove one or more Trades from the group - If the RECON.UPDATE in the Aggregation record is set to ‘REMOVE’, the quantity and amount pertaining to the Trade(s) are adjusted from the group totals in the Reconciliation record. Add one or more Trades to the group – If a Trade is missing, then create a new trade (in SEC.TRADE). A new Aggregation record is created for the transaction and the details added to the Reconciliation record for the group. In order, to cater to exceptional cases where a Trade already exists but the Aggregation record is missing, then create a new record in Aggregation table for the Trade and set the RECON.UPDATE field to 'ADD'. Modify the Underlying Trade – amount, price, commission and so on. The Aggregation record is updated with the revised details and the Reconciliation record is also adjusted accordingly. If a change is expected in Reconciliation

Deal Processing

30

Straight Through Processing (STP) ID on account of change in the Transaction details, then the System updates the Aggregation and Reconciliation records accordingly. Once these changes are done, the group can then be reconciled either automatically (based on incoming MT515 message) or manually. For manual Reconciliation, RECON.NOMINAL and RECON.AMOUNT must be entered in SP.RECONCILIATION record. If this matches with the nominal and amount in the Reconciliation, then the status is set to ‘MATCHED’, when the user authorizes this record. If a record is Reconciled (Status – MATCHED), then only the following action is allowed: l

Cancel the Trade – If this is set to 'Yes', then the Underlying Trades are reversed and the Settlement instructions sent are also reversed. The audit trail of the cancellation is available in the history of the application.

Now, the scenarios where a MT515 is received from the Broker without a preceding MT513 are explained below. This is true of cases where Orders and Executions are processed outside of T24 and T24 processing starts only from the Customer confirmation (MT515) stage. Besides, the Brokers may also send a direct MT515 based on their Agreements with the Bank. In this case, based on the MT515 received, the Underlying Trade(s) are authorized. If the Broker sends Aggregated MT515, the processing is similar to the Reconciliation process described above. In this case, the execution is processed manually (instead of through incoming MT513). Once the execution is authorized and Trade is created, a record is also created in the Aggregation table. Subsequent processing remains the same irrespective of whether execution is processed manually or through an Incoming execution advice from the Broker. If the Broker is not set for Aggregation, then the problem is in reconciling the Incoming MT515 with the Underlying Trade, as there are many MT515s for the same set of parameters as the Underlying Transaction. In such cases, the Reconciliation, are performed only if the reference of the Incoming MT515 message are known and recorded already. The SP.AGGREGATION record must be created manually for these Trades and the reference recorded in the NON.AGGR.BROKER fields (Broker who sends the message) and NON.AGGR.MT515.REF. Subsequently, when a MT515 message is received, all the Trades pertaining to the above confirmation are identified and authorised.

Aggregation of Settlement Instructions As mentioned above, if the flag for Settlement instructions is set for aggregation, then the Settlement instructions which is to be sent is Aggregated. The Aggregation pertains only to MT541/543 messages and not to the free of payment transactions (MT540/542). With Aggregation, the Settlement instructions are not generated from the individual transactions. Once the Reconciliation of MT515 is performed, a consolidated Settlement instruction is generated. The sender’s reference on the Settlement instruction is the MT515 ID as stored in the Reconciliation record.

31

Deal Processing

Straight Through Processing (STP) The consolidated Settlement instruction (MT540/MT542) are also generated at a set Cut-off time, without waiting for the MT515. The Cut-off time must be set in the MT515.CUT.OF.TIME field in the CUSTOMER.SECURITY of the Broker. If Aggregation is to be done by Stock Exchange as well, then the Cut-off time must be defined in the AGGR.CUT.OF.TIME field in the STOCK.EXCHANGE record. Where Cut-off time is set, then the Aggregated Settlement instruction is automatically generated when the Cut-off time is reached. Consequently, the Incoming Settlement status messages (MT548) and the Settlement confirmation messages (MT545/547) are also aggregated. Based on the reference to the Incoming message, the Reconciliation record is identified. If there is a match against a Reconciled record, then the status as in the Incoming MT548 message is updated for all the Underlying individual Trades. With regard to the Settlement confirmations, in case of a match, the Underlying individual Trades are identified and the Settlement processed for each Trade. In case of full Settlement (nominal and quantity in the Settlement instruction matches with the nominal and quantity settled as per Incoming message), the Settlement records pertaining to each Trade are updated and the Settlement is completed. In case of partial Settlements, the Settlement of individual Trades are on a pro-rata basis. Parent Child Trades Aggregation is also supported for Parent Child Trades. In the case of Parent Child Trades, the Parent Trades, that is, the Broker side are aggregated. The MT54X message are suppressed in the Parent Trade and instead are sent from the SP.RECONCILIATION record as per the existing functionality. Note: All Parent Trades with same Depository are aggregated and single MT54X are sent to the Parent Depository. All Child Trades with same CU.DEPOSITORY are aggregated and separate MT54X are sent to the CU.DEPOSITORY (Sub-account).

Deal Processing

32

Straight Through Processing (STP)

MT544 Receive free confirmation This is an Inward message which is processed in T24. The MT544 is processed only if the MSG.TYPE field in SP.STP.PARAM is set to '544'. This message is received from the depository to whom the MT540 Receive Free is sent. This message confirms the receipt of Stock in full or in part from the respective Broker with whom the Trade is done. The MT544 advises the receipt of Stock which is recorded in the SC.SETTLEMENT application. The BR.NOM.RECD.DEL and CU.NOM.RECD.DEL fields in SC.SETTLEMENT are populated with the Settled nominal advised in MT544. As SEC.TRADE allows the multiple Customers and multiple Brokers at the same time, the receipt of Stock from the respective Broker is marked. Similarly, the nominal received or settled by the Broker is prorated among the Customers. This process of prorating Customer nominal against the settled nominal from the Broker is handled in MT544 Inward processing.

33

Deal Processing

Straight Through Processing (STP)

MT545 Receive against payment confirmation This is an Inward message which is processed in T24. The MT545 is processed only if the MSG.TYPE field in SP.STP.PARAM is set to '545'. This message is received from the depository to whom the MT541 Receive against payment is sent. This message confirms the receipt of Stock in full or in part and the Payment in full or in part from or to the respective Broker with whom the Trade is done. The MT545 advises both the receipt of Stock and payment made to a Broker which is recorded in the SC.SETTLEMENT application. The BR.NOM.RECD.DEL and CU.NOM.RECD.DEL fields in SC.SETTLEMENT is populated with the settled nominal advised in MT545. Similarly, the BR.AMT.REC.PAID and CU.AMT.REC.PAID fields in SC.SETTLEMENT are updated with the payment made to the Broker. As SEC.TRADE allows multiple customers and multiple Brokers at the same time, the receipt of Stock from the respective Broker are recorded. Similarly, the nominal received or settled by the Broker is prorated among the Customers. The cash to be paid to the Broker is recorded in SC.SETTLEMENT record. In turn the cash Settlement from the Customer is also recorded. This process of prorating Customer nominals against Settled nominals from the Broker and prorating cash amounts is handled in MT545 Inward processing.

Deal Processing

34

Straight Through Processing (STP)

MT546 Deliver free confirmation This is an Inward message which is processed in T24. The MT546 is processed only if the MSG.TYPE field in SP.STP.PARAM is set to '546'. This message is received from the depository to whom an MT542 Deliver Free is sent. This message confirms the receipt of stock in full or in part from the respective Broker with whom the Trade is done. The MT546 advises the Delivery of Stock which is recorded in the SC.SETTLEMENT application. The BR.NOM.RECD.DEL and CU.NOM.RECD.DEL fields in SC.SETTLEMENT are populated with the Settled nominal advised in MT546. As SEC.TRADE allows multiple Customers and multiple Brokers at the same time, the delivery of Stock to a respective Broker is marked as received in the MT546 Deliver Free confirmation. Similarly, the nominal delivered to or settled with the Broker is prorated among the Customers. This process of prorating Customer nominal against the Settled nominal from Brokers is handled in MT546 Inward processing.

35

Deal Processing

Straight Through Processing (STP)

MT547 Delivery against payment confirmation This is an Inward message which is processed in T24. The MT547 is processed only if the MSG.TYPE field in SP.STP.PARAM is set to '547'. This message is received from the depository to whom the MT543 Deliver against payment instruction is sent. This message confirms the delivery of Stock in full or in part and the Payment received in full or in part from or to the respective Broker with whom the Trade is done. The MT547 advises both delivery of Stock and payment received from the Broker which is recorded in the SC.SETTLEMENT application. The BR.NOM.RECD.DEL and CU.NOM.RECD.DEL fields in SC.SETTLEMENT is populated with the settled nominal advised in the MT547. Similarly, the BR.AMT.REC.PAID and CU.AMT.REC.PAID fields in SC.SETTLEMENT are updated with the payment received from the Broker. As SEC.TRADE allows multiple Customers and multiple Brokers at the same time, the delivery of Stock to a respective Broker is recorded. Similarly, the nominal delivered to or settled with the Broker is to be prorated among the Customers. The cash received from the Broker is recorded in SC.SETTLEMENT. In turn the cash Settlement to the Customer is also recorded. This process of prorating the Customer nominal against the settled nominal to the Broker and prorating cash amounts is handled in the MT547 Inward processing.

Deal Processing

36

Straight Through Processing (STP)

Contractual and Actual Processing Though the Actual settlement method is assumed for Straight Through Processing, entities may settle the Customer or Broker’s Cash and Nominal contractually. This method of partial contractual Settlement or partial actual Settlement are handled in T24. In Straight Through Processing, if the contractual Settlement method is used partially (for example, Customer Cash and Nominal settles contractually), then the processing of the Settlement Confirmation messages becomes complex. Inward processing handles this complex situation for the above messages (MT544, MT545, MT546 and MT547) and settles the Broker and Customer nominal appropriately. Any error or inability to perform an update to SC.SETTLEMENT is recorded in an exception log.

37

Deal Processing

Straight Through Processing (STP)

MT509 Trade status message (Outward) The Outward trade status message is used to reject a received Trade status message and cancel a previously sent Trade status message. The message can be triggered from T24 for the following situations: l

l

Request the Status of a Trade Reject a previously received MT513, MT515 either Manually or Automatically.

The MT509 Trade Status message is triggered automatically, when the following messages are received and if some of the matching process fails: l

MT513- Client advice of Execution

l

MT515- Client confirmation of Purchase or Sale

The ST.STP.PARAM application and the field descriptions are explained below as an example setup:

Figure 13 - SP.STP.PARAM Field

Deal Processing

Content

Usage

38

Straight Through Processing (STP)

AUTO.COMPARE

513 515 544 545

Allows the input of valid SWIFTDE.MESSAGE types for automatic comparison.

546 547 USER.ROUTINE

Routine name

The user routine, which must exist on thePGM.FILE, to be called in the compare routine when the above message is received. This routine facilitates the validation of additional conditions for the triggering of an automatic MT509 message.

REASON.CODE

ULNK, DSEC, This field allows the input of a set of DDEA, reject codes as defined in the DQUA, NCRR SP.REASON.CODE application leading to the automatically triggered generation of an MT509 through the SP.STATUS application; if there is reason to reject the Incoming message.

Note: The above fields form a linked set of values and that a REASON.CODE is only allowed for the MT513 and MT515 messages. The following codes can be compared in the Incoming message provided that they have been setup in the SP.REASON.CODE application: l

ULNK - The message was not recognised - unknown linked reference.

l

DSEC - Unrecognised or invalid financial instrument identification.

l

DDEA - Unrecognised or invalid deal price.

l

DQUA - Unrecognised or invalid settlement quantity.

l

NCRR - Unrecognised or invalid settlement amount currency.

A typical SP.REASON.CODE is shown in the below screen shot.

39

Deal Processing

Straight Through Processing (STP)

Figure 14 - SP.REASON.CODE The following SP.STATUS record and the field descriptions illustrate the generation of an Outward MT509 message in response to a linked MT513

Figure 15 - SP.STATUS The following is a description of the major SP.STATUS fields: Field ORD.EXE.REF

Deal Processing

Content

Usage Allows the input of a valid SEC.OPEN.ORDER reference.

40

Straight Through Processing (STP)

STATUS.QUALIFIER

':MTCH'

Is mapped to message MT509

':AFFM' ':CPRC' ':RPRC' STATUS.CODE

'CANP, PEND, AFFI, NAFI, MACH, NMA

Mapped to message MT509

The following screen illustrates a typical live SP.ORDER.DELIVERY.CONTROL record indicating the amendment to an Order nominal.

Figure 16 - SP.ORDER.DELIVERY.CONTROL

41

Deal Processing

Straight Through Processing (STP)

MT549 Request for Statement or Status Advice This message is sent to request messages such as a Trade Status Message (MT509), a Statement of Holdings (MT535), or a Statement of Open Orders (MT576). Refer the Stock Reconciliation section of the Securities Admin User Guide, for more details in Statements of Holdings and only a request for a Statement of Open Orders is discussed in this topic. MT576 is an Incoming message and is processed by T24. The processed message is updated in the LIVE file SP.ORDER.DELIVERY.CONTROL, which can be used for triggering enquiries and reports. The SP.STATUS record linked to an MT576 is shown in the below screen shot, followed by a diagram illustrating the flow for an MT576 message.

Figure 17 - SP.STATUS

Deal Processing

42

Straight Through Processing (STP)

Further fields relating to the receipt of an MT576 message are displayed in the SP.ORDER.DELIVERY.CONTROL LIVE file are described in the below table:

43

Field

Usage

TOTAL.EX.NOM

Holds the total number of nominals executed for a particular order by a Broker.

REMAIN.NOM.EXE

Holds the remaining quantity of nominals to be executed by the Broker as per the execution record.

REMAIN.NOM

Updated with the remaining nominals as per the MT576 message.

Deal Processing

Straight Through Processing (STP)

Settlement Allegement - MT578 Message The MT578 Swift message is a settlement allegement message sent by the custodian or sub-custodian to an account owner, stating that a counterparty has alleged an instruction against account owner's account at the account servicer and the account servicer could not find the corresponding instruction (MT54x) of the account owner.

SC.ALLEGEMENT.INWARD The table SC.ALLEGEMENT.INWARD is used to record all the details from the incoming MT578. Each MT578 message creates a record in the table SC.ALLEGEMENT.INWARD. When all fields required to identify a transaction are available, then system marks the record status as RECEIVED. If any of the required fields in the record are not available, then system marks the status as ERROR and in the ERROR.REASON field, system marks all the errors. Fields that the system requires to identify the transaction and error message if missing, are as below: • TRADE.DATE • SECURITY.NUMBER • PAY.INSTR • TRANS.INSTR • NOMINAL • BROKER.NO • PORTFOLIO.NO

Deal Processing

44

Straight Through Processing (STP)

Acceptance or Rejection of the incoming MT578 Allegement Message User can investigate and accept the message. If the user accepts the message, user should mark the STATUS of the record as “ACCEPTED”. When a record is accepted, system automatically creates a SECURITY.TRANSFER record in INAU status and the ID reference of the SECURITY.TRANSFER is stored in the field SECURITY.TRANSFER.REF in SC.ALLEGEMNT.INWARD. The ID of the SC.ALLEGEMENT.INWARD gets recorded in the SECURITY.TRANSFER created.

45

Deal Processing

Straight Through Processing (STP)

Deal Processing

46

Straight Through Processing (STP)

If the user after investigation, decides to Reject the allegement, he should change the STATUS as “REJECTED”. User can also record the Reason for Rejection in the field REJECT.REASON which gets linked to EB.LOOKUP, where standard set of reasons can be defined. If User wants to Reject the allegement after first accepting it, he can do so only after he has manually deleted or reversed the SECURITY.TRANSFER that was created when record was accepted. Status cannot be marked as REJECTED when the SECURITY.TRANSFER.REF is not Null. Only if it becomes null, can status be marked as REJECTED.

MT578 CANC (or REMO) INWARD When an MT578 inward with function as CANC or REMO is received, the existing record in SC.ALLEGEMENT.INWARD is updated with Cancellation or Removal status If the CANC (or REMO) is received when the record is in RECEIVED or REJECTED status, then system updates the Function as CANC (or REMO) and marks the status as CANCELLED. If the CANC message is received after the record is in ACCEPTED status and SECURITY.TRANSFER is already created, then system records the function as CANC (or REMO) and marks the status of the record as ‘ERROR’ with ERROR.REASON as “Cancellation received-Transfer created”

47

Deal Processing

Straight Through Processing (STP) User can use the enquiry provided to list such records and manually reverse or delete the SECURITY.TRANSFER record, as required.

Deal Processing

48

Straight Through Processing (STP)

Swift MX messages SWIFT message type is expressed in XML syntax, which is more flexible and easier to implement than the previous generation of message types (MT). These message types are developed in accordance with ISO 20022 standard and are referred as MX messages. The MX Messages supported by Temenos Core Banking are detailed here. The details of how the messages are generated and the flow are explained in detail below.

Prerequisites for MX messages OFS Source

An OFS Source record must be used with Attributes SPECIAL.CHAR.CONV and PREAUTHENTICATED set.

SP.STP.PARAM

The directories to store the Messages must be defined in this record.

49

Deal Processing

Straight Through Processing (STP)

l

l

l

XML.IN.DIR - Defines the name of the directory used to hold incoming MX xml messages. XML.ARC.DIR - Defines the name of the directory used to hold achieved MX xml messages received. OFSML.DIR - Defines the name of the directory used to store the converted OFSML messages from XML message.

Once the record is authorised, the system automatically creates the Directories.

Deal Processing

50

Straight Through Processing (STP)

DE.INTERFACE

DE.CARRIER

DE.ADDRESS

For BIC NUMBER in XML message, we need to define the BIC ADDRESS in SWIFT record.

51

Deal Processing

Straight Through Processing (STP)

DE.PRODUCT

Deal Processing

52

Straight Through Processing (STP)

SECURITY.MASTER

Here the STP.ORDER field must be set to MX and along with this, the Broker for whom MX must be sent should also be specified.

53

Deal Processing

Straight Through Processing (STP)

Note: The STP.ORDER field is also available in SEC.OPEN.ORDER. If it is not set in SECURITY.MASTER, it can be set at the time of Order Capture.

Deal Processing

54

Straight Through Processing (STP)

MX Outward Ensure that DE.MESSAGE, DE.MAPPING, EB.ACTIVITY, EB.ADVICES, and DE.FORMAT.XML record exist. In core, there are four DE.MESSAGE records for MX502, they are as follows:

55

Deal Processing

Straight Through Processing (STP)

l

5021

l

5022

l

5023

l

5024

Once all the prerequisites are set, and when a SEC.OPEN.ORDER is input the system creates an MX502 xml message as shown below. The user must run the XML.OUTservice. F.DE.O.MSG.XML

Deal Processing

56

Straight Through Processing (STP)

57

Deal Processing

Straight Through Processing (STP)

MX INWARD

SetUp and Transaction screens for Inward Messages Configure JBOSS and BFL

1. The user must configure the tocfee.ear for processing the OFSML in T24.

Deal Processing

58

Straight Through Processing (STP)

Configure JBOSS and BFL

1. Right click and click 'Open archive', to open the tocfee.ear using 7zip.

Configure JBOSS and BFL

1. Open tocfplugin-ra.rar file in tocfee.ear folder.

Configure JBOSS and BFL

1. Open the tcserver.xml for configuring the BFL paths.

59

Deal Processing

Straight Through Processing (STP)

Configure JBOSS and BFL

1. Open the tcserver.xml for configuring the Batch File Listener paths.

Configure JBOSS and BFL

1. Check the paths mentioned in tcserver.xml

Deal Processing

60

Straight Through Processing (STP)

Configure JBOSS and BFL

1. Check the paths mentioned in tcserver.xml Request path

Response path

61

Deal Processing

Straight Through Processing (STP)

Deal Processing

62

Straight Through Processing (STP)

SC.EXE.SEC.ORDERS - Before MX INWARD Processing

63

Deal Processing

Straight Through Processing (STP)

SC.EXE.SEC.ORDERS After MX INWARD Processing

After MX INWARD Processing, the Inward message authorises the SC.EXE.SEC.ORDERS record. Therefore, the record is no longer on HLD status.

Subscription order Confirmation 'Setr.012.001.03'.

Deal Processing

64

Straight Through Processing (STP)

Redemption order Confirmation 'Setr.006.001.03'.

65

Deal Processing

Straight Through Processing (STP)

Order Instruction Status Report 'Setr.016.001.03'.

Deal Processing

66

Straight Through Processing (STP)

67

Deal Processing

Straight Through Processing (STP)

MX Messages in T24 SC Settlement Inward Messages MX Message

Description

Equivalent MT

sese.024.001.05

Securities Settlement Transaction Status Advice - message sent in response to a Securities Settlement Transaction Instruction to give a status of the instruction.

548

sese.025.001.05

Securities Settlement Transaction Confirmation - message sent by the executing / servicing party in response to a Securities Settlement Transaction Instruction to confirm settlement.

544/545/546/547

sese.026.001.04

Securities Settlement Transaction Reversal Advice - message sent to reverse a previously confirmed transaction

544/545/546/547

sese.027.001.03

Securities Transaction Cancellation Request 548 Status Advice - message sent to request cancellation of a previously sent transaction instruction

sese.032.001.05

Securities Settlement Transaction Generation Notification - notification that a securities movement has been auto-generated without a matching trade or transfer (for example through a corporate action)

548

SC Settlement Outward MX Message

Description

Equivalent MT

sese.020.001.04

Securities Transaction Cancellation Request - generic cancellation message to cancel a previously sent confirmation message

540/541/542/543

sese.023.001.05

Securities Settlement Transaction Instruction - message sent by an instructing party (for example an investment manager) to the servicing party (for example a CSD).

540/541/542/543

Deal Processing

68

Straight Through Processing (STP)

Corporate Actions Event Inward MX Message

Description

Equivalent MT

seev.031.001.0- Corporate Action Notification - message used to 5 notify details of a corporate actions event and optionally; account information, eligible balances and entitlements.

564

seev.036.001.0- Corporate Action Movement confirmation - mes- 566 5 sage used to confirm postings of cash or securities as a result of a corporate action event seev.038.001.0- Corporate Action narrative - narrative message 3 used for information on taxation conditions, registration details, confirmation of holdings transfer and other ancillary information.

568

seev.039.001.0- Corporate Action cancellation advice - message 5 used to cancel previously announced corporate action event.

564

Corporate Actions Event Outward MX Message

Description

Equivalent MT

seev.033.001.0- Corporate Action Instruction - message used to 5 instruct election for a corporate action event

565

Fund Messages MX Message

Description

Equivalent MT

setr.010.001.03

Subscription order

502

setr.004.001.03

Redemption order

502

setr.006.001.03

Redemption Order confirmation - confirmation or the execution of a redemption order

515 (513)

setr.012.001.03

Subscription order confirmation - confirmation of the execution of a subscription order

515 (513)

setr.016.001.03

Order instruction status report - report of the status of an order. Sent in response to an order status request

509

69

Deal Processing

Straight Through Processing (STP)

setr.005.001.03

Redemption Order cancellation request - request to cancel a redemption order

502 CANC

setr.011.001.03

Subscription order cancellation request - message requesting the cancellation of a subscription order

502 CANC

setr.013.001.nnn

Switch Order

502

setr.014.001.nnn

Switch Order cancellation request

502 CANC

setr.015.001.nnn

Switch order confirmation (Inward)

515

Deal Processing

70