Straight Through Processing (STP) PDF

Straight Through Pro-
cessing (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 7
Parameter Files 8
Deal Processing 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
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
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 Pro-
cessing. 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 Ini-
tiation 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 per-
formed 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
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 T24applic-
ations.
Settlement and Reconciliation messages (S&R)

The following are the messages supported by T24 which forms part of the Set-
tlement 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
Overview 6
Configuration
The following section explain the various parameters associated with STP.
l Parameter Files
7 Configuration
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 com-
ponents.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 require-
ment 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 para-
meter record.
Figure 1 - SP.STP.PARAM
Configuration 8
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
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
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 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.
l 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 con-
firmation 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 doc-
ument may be reproduced or transmitted in any form or by any means, for any pur-
pose, without the express written permission of TEMENOS HEADQUARTERS SA. ©
2019 Temenos Headquarters SA - all rights reserved.
11 Configuration
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
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
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
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
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 func-
tionality two application live files are used to record the replacement and can-
cellation 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 modi-
fication made to the AMT.TO.BROKER and the effect on the Customer's
NO.NOMINAL fields in SEC.OPEN.ORDER record.
Deal Processing 16
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
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 Mes-
sage 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 suit-
ably 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 applic-
ation.
Figure 12- SC.ORD.MANUAL.UPD
Deal Processing 18
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 manu-
ally entered. This action updates SC.ORDER.STP.ACTIVITY and triggers the necessary
changes.
19 Deal Processing
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 pro-
cessed by a phantom job defined in EB.PHANTOM application. Currently, T24 pro-
cesses 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
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 mes-
sage carries one allocation only at a time, hence there is multiple MT514s gen-
erated 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
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 ref-
erence 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
23 Deal Processing
Executing Orders
Delivery
A Delivery advice is created automatically with all relevant information relating to
the transaction.
Delivery message
Deal Processing 24
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 Aggreg-
ated 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 cus-
todian (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 Set-
tlement 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
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 mes-
sage 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
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 Aggreg-
ated; 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 Recon-
ciliation 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
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
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
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 cus-
todian, 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 pre-
vious 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 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.
l 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 trans-
action 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'.
l 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
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 auto-
matically (based on incoming MT515 message) or manually. For manual Recon-
ciliation, 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 pre-
ceding MT513 are explained below. This is true of cases where Orders and Exe-
cutions 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 Recon-
ciliation 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 Recon-
ciliation, are performed only if the reference of the Incoming MT515 message are
known and recorded already. The SP.AGGREGATION record must be created manu-
ally 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 Set-
tlement instruction is the MT515 ID as stored in the Reconciliation record.
31 Deal Processing
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 auto-
matically generated when the Cut-off time is reached.
Consequently, the Incoming Settlement status messages (MT548) and the Set-
tlement confirmation messages (MT545/547) are also aggregated. Based on the ref-
erence 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 mes-
sage 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
MT544 Receive free confirmation

This is an Inward message which is processed in T24. The MT544 is processed only
from the depository to whom the MT540 Receive Free is sent. This message con-
firms 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
MT545 Receive against payment confirmation

from the depository to whom the MT541 Receive against payment is sent. This mes-
sage 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 Cus-
tomers. 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 pro-
rating Customer nominals against Settled nominals from the Broker and prorating
cash amounts is handled in MT545 Inward processing.
Deal Processing 34
MT546 Deliver free confirmation

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
MT547 Delivery against payment confirmation

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 respect-
ive 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 nom-
inal to the Broker and prorating cash amounts is handled in the MT547 Inward pro-
cessing.
Deal Processing 36
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 appro-
priately. Any error or inability to perform an update to SC.SETTLEMENT is recorded
in an exception log.
37 Deal Processing
MT509 Trade status message (Outward)

The Outward trade status message is used to reject a received Trade status mes-
sage and cancel a previously sent Trade status message. The message can be
triggered from T24 for the following situations:
l Request the Status of a Trade
l Reject a previously received MT513, MT515 either Manually or Auto-
matically.
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 Content Usage
Deal Processing 38
AUTO.COMPARE 513 515 Allows the input of valid

SWIFTDE.MESSAGE types for auto-
544 545
matic comparison.
546 547
USER.ROUTINE Routine The user routine, which must exist on
name thePGM.FILE, to be called in the com-
pare routine when the above mes-
sage 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 gen-
eration of an MT509 through the
SP.STATUS application; if there is
reason to reject the Incoming mes-
sage.
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
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 Content Usage

ORD.EXE.REF Allows the input of a valid
SEC.OPEN.ORDER reference.
Deal Processing 40
STATUS.QUALIFIER ':MTCH' Is mapped to message MT509

':AFFM'
':CPRC'
':RPRC'
STATUS.CODE 'CANP, PEND, AFFI, Mapped to message MT509
NAFI, MACH, NMA
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
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 trig-
gering enquiries and reports.
The SP.STATUS record linked to an MT576 is shown in the below screen shot, fol-
lowed by a diagram illustrating the flow for an MT576 message.
Figure 17 - SP.STATUS
Deal Processing 42
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:
Field Usage
TOTAL.EX.NOM Holds the total number of nom-
inals 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 exe-
cution record.
REMAIN.NOM Updated with the remaining
nominals as per the MT576
message.
43 Deal Processing
Settlement Allegement - MT578 Message

The MT578 Swift message is a settlement allegement message sent by the cus-
todian 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 incom-
ing 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 miss-
ing, are as below:
• TRADE.DATE
• SECURITY.NUMBER
• PAY.INSTR
• TRANS.INSTR
• NOMINAL
• BROKER.NO
• PORTFOLIO.NO
Deal Processing 44
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
Deal Processing 46
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 reas-
ons 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 cre-
ated 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
User can use the enquiry provided to list such records and manually reverse or
delete the SECURITY.TRANSFER record, as required.
Deal Processing 48
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
l XML.IN.DIR - Defines the name of the directory used to hold incoming MX

xml messages.
l XML.ARC.DIR - Defines the name of the directory used to hold achieved MX
xml messages received.
l 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
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
DE.PRODUCT
Deal Processing 52
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
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
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
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
57 Deal Processing
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
1. Right click and click 'Open archive', to open the tocfee.ear using 7zip.
1. Open tocfplugin-ra.rar file in tocfee.ear folder.
1. Open the tcserver.xml for configuring the BFL paths.
59 Deal Processing
1. Open the tcserver.xml for configuring the Batch File Listener paths.
1. Check the paths mentioned in tcserver.xml
Deal Processing 60
1. Check the paths mentioned in tcserver.xml

Request path
Response path
61 Deal Processing
Deal Processing 62
SC.EXE.SEC.ORDERS - Before MX INWARD Processing
63 Deal Processing
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
Redemption order Confirmation 'Setr.006.001.03'.
65 Deal Processing
Order Instruction Status Report 'Setr.016.001.03'.
Deal Processing 66
67 Deal Processing
MX Messages in T24
SC Settlement Inward Messages
MX Message Description Equivalent MT
ses- Securities Settlement Transaction Status 548
e.024.001.05 Advice - message sent in response to a
Securities Settlement Transaction Instruc-
tion to give a status of the instruction.
ses- Securities Settlement Transaction Con- 544/545/546/54-
e.025.001.05 firmation - message sent by the executing / 7
servicing party in response to a Securities
Settlement Transaction Instruction to con-
firm settlement.
ses- Securities Settlement Transaction Reversal 544/545/546/54-
e.026.001.04 Advice - message sent to reverse a pre- 7
viously confirmed transaction
ses- Securities Transaction Cancellation Request 548
e.027.001.03 Status Advice - message sent to request can-
cellation of a previously sent transaction
instruction
ses- Securities Settlement Transaction Gen- 548
e.032.001.05 eration Notification - notification that a
securities movement has been auto-gen-
erated without a matching trade or transfer
(for example through a corporate action)
SC Settlement Outward
MX Message Description Equivalent MT
ses- Securities Transaction Cancellation Request 540/541/542/54-
e.020.001.04 - generic cancellation message to cancel a 3
previously sent confirmation message
ses- Securities Settlement Transaction Instruc- 540/541/542/54-
e.023.001.05 tion - message sent by an instructing party 3
(for example an investment manager) to
the servicing party (for example a CSD).
Deal Processing 68
Corporate Actions Event Inward

MX Message Description Equi-
valent MT
seev.031.001.0- Corporate Action Notification - message used to 564
5 notify details of a corporate actions event and
optionally; account information, eligible balances
and entitlements.
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 568
3 used for information on taxation conditions, regis-
tration details, confirmation of holdings transfer
and other ancillary information.
seev.039.001.0- Corporate Action cancellation advice - message 564
5 used to cancel previously announced corporate
action event.
Corporate Actions Event Outward

valent MT
seev.033.001.0- Corporate Action Instruction - message used to 565
5 instruct election for a corporate action event
Fund Messages
valent MT
setr.010.001.03 Subscription order 502
setr.004.001.03 Redemption order 502
setr.006.001.03 Redemption Order confirmation - confirmation 515 (513)
or the execution of a redemption order
setr.012.001.03 Subscription order confirmation - confirmation of 515 (513)
the execution of a subscription order
setr.016.001.03 Order instruction status report - report of the 509
status of an order. Sent in response to an order
status request
69 Deal Processing
setr.005.001.03 Redemption Order cancellation request - request 502 CANC

to cancel a redemption order
setr.011.001.03 Subscription order cancellation request - mes- 502 CANC
sage requesting the cancellation of a subscription
order
setr.013.001.nn- Switch Order 502
n
setr.014.001.nn- Switch Order cancellation request 502 CANC
n
setr.015.001.nn- Switch order confirmation (Inward) 515
n
Deal Processing 70

Straight Through Processing (STP) PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Straight Through Processing (STP) PDF

Caricato da

Copyright:

Formati disponibili

Straight Through Pro-

Information in this document is subject to change without notice.

© 2019 Temenos Headquarters SA - all rights reserved.

SWIFT categorises ISO 15022 messages as

Trade Initiation and Confirmation messages (TIC)

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

l MT 513 Client Advice of Execution

Settlement and Reconciliation messages (S&R)

the time of Order Creation, that is at SEC.OPEN.ORDER level or even at execution

Note: In SEC.OPEN.ORDER these fields are populated from the

MT502 Order to Buy or Sell

Figure 5 - Preview of an MT502 Order to Buy or Sell

Figure 6 – SEC.OPEN.ORDER Soft Delivery

Figure 7 - MT502 - New Message

Figure 8 - MT502 Replacement Message

Reversal of a SEC.OPEN.ORDER and deletion of a Broker multi-value set, generates

Figure 9 - MT502 Cancellation Message

MT509 Trade status message

Figure 12- SC.ORD.MANUAL.UPD

In the SC.ORD.MANUAL.UPD application, the respective Broker number from whom

MT513 Client Advice of Execution

MT514 Trade Allocation Instruction

MT515 Client Confirmation of Purchase or Sale

A diagrammatic representation of the above flow (with multiple Orders) is shown in

Noted: That a record is created in SP.AGGREGATION only for Trades

The Aggregation holds the following details:

A record is then built in the Reconciliation table (SP.RECONCILIATION), based on the

l Matching record for the group not found

Note: This Aggregation only pertains to MT541 and MT543 and

4. Settlement instruction reference is updated in the Reconciliation record. The

ID on account of change in the Transaction details, then the System updates

Aggregation of Settlement Instructions

The consolidated Settlement instruction (MT540/MT542) are also generated at a

Parent Child Trades

MT544 Receive free confirmation

MT545 Receive against payment confirmation

MT546 Deliver free confirmation

MT547 Delivery against payment confirmation

Contractual and Actual Processing

MT509 Trade status message (Outward)

Field Content Usage

AUTO.COMPARE 513 515 Allows the input of valid

Field Content Usage

STATUS.QUALIFIER ':MTCH' Is mapped to message MT509

The following screen illustrates a typical live SP.ORDER.DELIVERY.CONTROL record

MT549 Request for Statement or Status Advice

Settlement Allegement - MT578 Message

Acceptance or Rejection of the incoming MT578 Allegement Message

MT578 CANC (or REMO) INWARD

Prerequisites for MX messages

l XML.IN.DIR - Defines the name of the directory used to hold incoming MX

Note: The STP.ORDER field is also available in SEC.OPEN.ORDER. If it is

SetUp and Transaction screens for Inward Messages

Configure JBOSS and BFL

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.

Configure JBOSS and BFL

Configure JBOSS and BFL

1. Check the paths mentioned in tcserver.xml

Configure JBOSS and BFL

1. Check the paths mentioned in tcserver.xml