S - PowerPoint PPT Presentation

1 / 87
About This Presentation
Title:

S

Description:

... request are rejectable, cancellation advice are not. S&R and CA ... But cancellation messages should be structurally the same accross business areas ... – PowerPoint PPT presentation

Number of Views:57
Avg rating:3.0/5.0
Slides: 88
Provided by: jlit
Category:
Tags:

less

Transcript and Presenter's Notes

Title: S


1
SR Reverse Engineering IC update
  • Karine Taquet
  • Alexandre Kech
  • SWIFT Standards Securities

2
WARNING
  • Industry Consultation is still on, so feedback on
    the decisions in this document is still welcome
  • Details such as ISO 20022 message/component/elemen
    t names may change

3
1. One Settlement Instruction and One Confirmation
Decision
  • Following the analysis of all issues and for
    consistency point of view across all SR
    messages, 1 settlement instruction and 1
    settlement confirmation is the more logical way
    to go.
  • Indicators will provide information about the
    type of instruction (RVP, DVP, RF, DF)
  • Mapping to ISO 15022 4 messages will be based on
    message type instruction type. Not considered a
    major coexistence issue.
  • To be further validated.

4
1. One Settlement Instruction and One Confirmation
B
CSD
Z
A
5
2. Listed derivatives functionality
Decision
  • All agree that it should be removed from
    Settlement and confirmation messages.
  • Specific notification messages (and logical
    suite) should be build or reuse of post-trade.
  • Coordinate with post-trade and/or derivative
    projects.
  • Minimum requirement have an ISO 20022 solution
    to cover the current ISO 15022 derivatives
    functionality.
  • Scope to be clarified during the detailed
    analysis phase.

6
34. Cancellation request and advice (issue 4)
Decision
  • Create 2 types of Cancellation messages
  • Cancellation request
  • Cancellation advice
  • Cancellation request from AO to AS
  • Cancellation advice from AS to AO
  • Cancellation request are rejectable, cancellation
    advice are not
  • SR and CA will have their own
  • But cancellation messages should be structurally
    the same accross business areas

7
34. Cancellation request
B
CSD
Z
A
8
34. Cancellation request
B
CSD
Z
A
Applies to instructions from AccOwn to AccSer
that can be cancelled
9
34. Cancellation advice
B
CSD
Z
A
10
34. Cancellation advice
B
CSD
Z
A
Applies to messages from AccSer to AccOwn that
can be cancelled
11
34. Cancellation request and advice (issue 4)
Content of the cancellation message
  • M Reference to the object to be cancelled
  • Limited list of business data to be defined
    during detailed analysis.
  • Based on mandatory info in object to be cancelled
  • Based on 10 common elements?

12
34. Cancel and replace (issue 3)
Decision
  • Have 2 modification messages
  • Transaction Processing Command for PROCESSING
    data
  • New Replace message for modification of BUSINESS
    data (eg. units, amounts)
  • The replace message would contain a complete
    settlement instruction, not only the modified
    data, to ease processing and audit trail.
  • Would contain a reference to the replaced object
    and optionaly the same limited number of data
    that would exist in the cancellation.
  • During coexistence, 20022 to 15022 possible, not
    the opposite. Acknowledged by IC group members

13
34. Cancellation and replace (issue 3)
B
CSD
Z
A
14
34. Cancellation and replace (issue 3)
B
CSD
Z
A
15
5. Status reporting
Decision
  • Settlement Transaction Status Advice
  • Intra-Position Status Advice
  • Request for Status/Statement Status Advice
  • Processing Change Command Status Advice
  • Cancellation Request Status Advice

16
5. Status reporting
B
CSD
Z
A
17
5. Status reporting
B
CSD
Z
A
18
6. Negative sign in ISO 15022
Decision
  • Align with Corporate Action logic, that is,
    posting quantity and amount with mandatory
    credit/debit information.
  • Further detailed analysis needed for
    implementation
  • Incorporate open item 14 (DWP)

19
6. Negative sign in ISO 15022
Illustration
  • For Settlement Instruction and confirmation (as
    per issue 1 decision), settlement instruction
    type would be qualified as it is today in
    statements
  • Receive/Deliver with RECE and DELI code
  • Payment with APMT and FREE code
  • Credit/Debit at posting amount and quantity level.

20
6. Negative sign in ISO 15022
Illustration
Delivery Against Payment (543) ReceiveDeliveryIndicator DELI PaymentIndicator APMT SettlementQuantity 1000, CreditDebitIndicatior DEBI SettlementAmount USD2000, CreditDebitIndicator CRED
Receipt Against Payment (541) ReceiveDeliveryIndicator RECE PaymentIndicator APMT SettlementQuantity 1000, CreditDebitIndicatior CRED SettlementAmount USD2000, CreditDebitIndicator DEBI
21
6. Negative sign in ISO 15022
Illustration
Delivery with Payment (item 14) ReceiveDeliveryIndicator DELI Payment Indicator APMT Settlement Quantity 1000, CreditDebitIndicatior DEBI Settlement Amount USD2000, CreditDebitIndicator DEBI
Receipt with Payment (item 14) ReceiveDeliveryIndicator RECE PaymentIndicator APMT SettlementQuantity 1000, CreditDebitIndicatior CRED SettlementAmount USD2000, CreditDebitIndicator CRED
22
6. Negative sign in ISO 15022
Illustration
Receive Free (540) ReceiveDeliveryIndicator RECE PaymentIndicator FREE SettlementQuantity 1000, CreditDebitIndicator CRED
Delivery Free (542) ReceiveDeliveryIndicator DELI PaymentIndicator FREE SettlementQuantity 1000, CreditDebitIndicator DEBI
23
7. IDs and References in SR
Issues with the current ISO 15022 logic
  • 20CSEME is a catch all field (mis)used for
    message, instruction or transaction
    identification.
  • Not in line with CA
  • Unclear so numerous usage.

24
7. IDs and References in SR
Decision
  • Align with the CA concept of corporate action id.
  • Creation of a Settlement Tx ID identifying, at
    the instructing party level, a settlement
    transaction from creation to end of life.
  • Each message/document exchanged in the framework
    of this settlement transaction has its
    identification
  • Other optional identifications and references
    (such as common id, trade id, processing id for
    each party, etc) remains possible as today.

25
7. IDs and References in SR
  • The difference between an identification and a
    reference is as follows
  • An Identification is a string of characters
    identifying a object (eg, transaction,
    instruction).
  • A Reference is a string of characters identifying
    an object in another object (eg, a transaction B
    in a transaction A, an instruction in a status
    advice, )
  • Identification must be unique to the party
    creating it.

26
7. IDs and References in SR
Illustration
  • Taking a plain vanilla settlement
  • The settlement transaction is identified by party
    A as AA, by party B as BB, by the CSD as CC and
    by cpty Z as ZZ.
  • In bold are the mandatory ids and refs
  • Left aligned are IDs, right aligned are Refs.

27
7. Settlement Process
BB
CC
ZZ
AA
28
7. Settlement Process
ZZ
BB
CC
AA
29
7. Cancellation Process
BB
CC
ZZ
AA
30
7. Cancellation process
  • Pending question
  • Should it be possible to request
  • either
  • the cancellation of an instruction (eg, if one
    settlement transaction is made of more than one
    instructions)
  • or the cancellation of the settlement transaction
  • or only to cancel the settlement transaction?

31
7. Status request process
Request for transaction status
Request for cancellation status
Request for instruction status
BB
BB
AA
BB
AA
AA
32
7.Intra-position movement
Acc Serv initiated
Acc Own initiated
BB
BB
AA
AA
33
7. Block-trade settlement
BB1 ,2, 3
AA1, 2, 3
CC
ZZ
34
7. Block-trade settlement
BB1 ,2, 3
AA1, 2, 3
CC
ZZ
35
7. Block-trade settlement
AA1, 2, 3
BB1, 2, 3
ZZ
CC
36
7. Reporting process
  • Pending question in case of multiple pages for a
    statement,
  • is the statement number page number sufficient
    (see slides 37) or
  • should there be a page/message identification
    (see slides 38).

37
7. Reporting process (1)
Pull Mode
Push Mode
Pull Mode
Pull Mode
BankA
BankA
BankA
BankA
BankB
BankB
BankB
BankB
38
7. Reporting process (2)
Pull Mode
Push Mode
Pull Mode
Pull Mode
BankA
BankA
BankA
BankA
BankB
BankB
BankB
BankB
39
8. Linkages
  • Not to be confused with referencing
  • Decision
  • Keep current ISO 15022 logic
  • Investigate need for soft linkage indicator
  • Investigate need for differentiation between
    transaction linking (this DF must be executed
    with this RF) and document linking (this
    message/doc must be processed before this
    message/doc).

40
9. COPY/CODU/DUPL
Decision
  • Keep current ISO 15022 logic
  • Clarify usage to avoid confusions

41
9. COPY/CODU/DUPL
B
CSD
Z
A
D
42
1021. Hold and release
Decision
  • Implement the SMPG agreed market practice
  • Hold indicator in settlement instruction
  • Processing change command for release/hold
    instruction

43
11. REPO and other securities financing
Decision
  • General agreement that it should be removed from
    Settlement and confirmation messages.
  • Specific securities financing messages (and
    needed suite) should be build.
  • Covering all two legs transactions
  • Repo and reverse repo
  • Securities lending and return
  • Securities Borrowing and return
  • Collateral in, opening and closing
  • Collateral out, opening and closing
  • Coordinate with any existing collateral
    settlement project.
  • Pure settlement actvities remain covered by the
    settlement messages.

44
11. REPO and other securities financing
B (servicer)
CSD
Z
A
SAMPLE Model is not done yet
45
12. Settlement transaction generated by account
servicer
  • Original proposal was to keep ISO 15022 newly
    agreed logic
  • Decision
  • All IC participants want a specific message to
    cover that process.
  • The new advice would contain the settlement
    transaction details reason for creation and
    current status.
  • Once created, it becomes a normal settlement
    transaction subject to the plain vanilla
    settlement flows

46
12. Settlement transaction generated by account
servicer
B
CSD
Z
A
47
12. Settlement transaction generated by account
servicer
B
CSD
Z
A
48
13. Delivery Versus Delivery
  • For example, for collateral substitutions
  • Decision
  • Keep the ISO 15022 logic, that is, link a receipt
    on securities 1 with delivery on securities 2
  • Reject of a specific message as it would lead to
    unnecessary work for a process correctly covered
    today with two plain vanilla DF and RF.

49
13. Delivery Versus Delivery
B
CSD
Z
A
v
50
15. MEOR, MERE, ACOW
  • Decision
  • Keep the existing ISO 15022 logic but with usage
    clarification
  • Document all existing scenarios to avoid
    confusion on what when to use MEOR/MERE versus
    ACOW.

51
16. Settlement Parties
Issues with ISO 15022
  • Addition of intermediaries between BUYR/SELL and
    REAG/DEAG is complex
  • Party names do not correspond to what they are
    effectively used for.
  • Place of settlement is not always the place of
    settlement
  • Buyer is not always the buyer, eg, when two
    settlement parties are provided only.

52
16. Settlement Parties
Decision
  • Name settlement parties for what they effectively
    are Levels in a settlement chain
  • Easy inclusion of additional levels
  • Place of settlement to be a party in the chain

53
16. Settlement Parties Delivery logic
ISO 20022 ISO 15022 (plain vanilla usage involving a CSD)
ReceivingParty1 PSET
ReceivingParty2 REAG
ReceivingParty3 REI2
ReceivingParty4 REI1
ReceivingParty5 RECU
ReceivingParty6 BUYR
54
16. Settlement Parties Delivery logic
ISO 20022 Definition
ReceivingParty1 First receiving party in the settlement chain. In a plain vanilla settlement, it is the Central Securities Depository where the receiving counterparty requests to receive the financial instrument.
ReceivingParty2 Receiving party that interacts with the Receiving Party 1.
ReceivingParty3 Receiving party that interacts with the Receiving Party 2.
ReceivingParty4 Receiving party that interacts with the Receiving Party 3.
ReceivingParty5 Receiving party that interacts with the Receiving Party 4.
ReceivingParty6 Receiving party that interacts with the Receiving Party 5.
  • ReceivingParty1 open question
  • For physical settlement, choice between
  • - it is the country of the party that will
    physically receive the physical securities (No MP
    change). OR
  • - It is the party that will physically receive
    the physical securities (change in MP).
  • For internal transfer, choice between
  • - It is the central securities depository where
    the receiving party would receive the securities
    if settlement takes place at CSD (no MP change)
    OR
  • - it is the party in the settlement chain where
    the transfer will effectively take place (change
    in MP).

55
16. Settlement Parties Delivery logic (3
receiving parties involved)
ISO 20022 ISO 15022
ReceivingParty1 PSET
ReceivingParty2 REAG
ReceivingParty3 BUYR
56
16. Settlement Parties Delivery logic (4
receiving parties involved)
ISO 20022 ISO 15022
ReceivingParty1 PSET
ReceivingParty2 REAG
ReceivingParty3 RECU
ReceivingParty4 BUYR
57
16. Settlement Parties Receive logic
ISO 20022 ISO 15022 (plain vanilla usage involving a CSD)
DeliveringParty1 PSET
DeliveringParty2 DEAG
DeliveringParty3 DEI2
DeliveringParty4 DEI1
DeliveringParty5 DECU
DeliveringParty6 SELL
58
16. Settlement Parties Need to identify the
beneficiary or ordering customer?
ISO 20022 ISO 15022
Investor INVE in sequence F
  • During the IC meeting, it was suggested that the
    side of the investor be provided.
  • Today, it is not easy to identify whether the
    investor provided is on the receive or delivery
    side.
  • Proposal (to be aligned in ISO 15022?) would
    become

59
16. Settlement Parties Need to identify the
beneficiary or ordering customer?
ISO 20022 ISO 15022
ReceivingInvestor RINV in sequence F
DeliveringInvestor DINV in sequence F
60
16. Settlement Parties Current Market Practice?
  • For plain vanilla settlement (90 cases), MP
    does not change
  • Minimum 3 levels in the settlement chain

MP for delivery ISO 20022 Delivery
CSD of Cptys receiving agent ReceivingParty1
Receiving agent ReceivingParty2
Client of receiving agent ReceivingParty3
61
16. Settlement Parties What if more than one
depository
  • Existing Market practice applies

MP for delivery ISO 20022 Delivery
CSD of Cptys receiving agent ReceivingParty1
Receiving agent ReceivingParty2
Client of receiving agent ReceivingParty3
Place of safekeeping DeliveringParty1
62
16. Settlement Parties What if more than 2
depositories
CL R Part
CL D Part
CSD3 Part
CSD1 Part
CSD2
CSD1
CSD3
ISO 20022 Delivery MP for delivery MP for receipt ISO 20022 Receipt
ReceivingParty1 CSD 3 CSD 1 DeliveringParty1
ReceivingParty2 CSD 3 Participant CSD 1 Participant DeliveringParty2
ReceivingParty3 Client Receiving Part Client Delivering Part DeliveringParty3
DeliveringParty1 CSD 1 CSD 3 ReceivingDepository
  • As agreed at ECSDA, CSD1 and CSD 3, with the
    above info, should know that they need to go to
    CSD 2.

63
16. Settlement Parties Physical Delivery logic
(MP change proposed)
ISO 20022 ISO 15022
ReceivingParty1 REAG
ReceivingParty2 BUYR
  • ReceivingParty1 is the party receiving the
    physical certificates
  • More (or less) parties may be involved

64
16. Settlement Parties Internal Transfer
  • Suggested during IC that the current MP for
    internal transfers should be changed.
  • ReceivingParty1 and DeliveringParty1 should be
    the party that will effectively book the
    transfer.
  • Current logic is to always provide the settlement
    chain down to the CSD, even if the settlement
    takes place earlier in the settlement chain. Why?
  • avoid a specific settlement chain for internal
    transfer when in facts, it may end up being a
    normal settlement (eg, custodian account
    segregation at CSD).
  • limit the number of party combination scenarios

65
16. Settlement Parties Internal Transfer logic
(MP not change)
ISO 20022 Delivery MP for delivery MP for receipt ISO 20022 Receipt
ReceivingParty1 CSD CSD DeliveringParty1
ReceivingParty2 CSDs participant ABC CSDs participant ABC DeliveringParty2
ReceivingParty3 Client Acc at ABC 1234 Client Acc at ABC 4321 DeliveringParty3
  • In this case, settlement/transfer takes place at
    ABC.
  • But if ABC had segregated accounts at CSD, it may
    be that ReceivingParty1 and DeliveringParty1 is
    the CSD, not ABC.
  • Only an example

66
16. Settlement Parties Internal Transfer logic
(MP change suggested)
ISO 20022 Delivery MP for delivery MP for receipt ISO 20022 Receipt
ReceivingParty1 ABC ABC DeliveringParty1
ReceivingParty2 Client Acc at ABC 1234 Client Acc at ABC 4321 DeliveringParty2
  • If ABC have segregated accounts at CSD, ABC will
    have to modify the instruction, before sendout to
    CSD, to change receivingparty1 and
    deliveringparty1 to become CSD.
  • With current MP, this is not needed. Better STP
    throughout the settlement chain.

67
17-26 Detailed open issues
  • List of detailed gaps that would probably be
    maintained in ISO 15022 and included in ISO 20022
  • 17. Conditional delivery indicator
  • Business case to be clarified
  • 18. Validity date in settlement instruction
  • Business case to be clarified
  • 19. Settlement Cycle in statements
  • Business case to be clarified

68
17-26 Detailed open issues
  • 20. Allegement rejection message
  • IC is negative so far
  • 22. Generic Message Element
  • XML Extension should be used
  • 23. Place of trade VARI
  • Maintenance request to be submitted
  • 24. Identification of place of settlement with
    DSS
  • Pending settlement parties (open item 16)

69
17-26 Detailed open issues
  • 25. Qualifier intermediary
  • Maintenance request to be submitted
  • 26. Ordering customer as payment parties
  • Maintenance request to be submitted
  • ISO 20022 Payment parties to be reused.
  • Other CRs (SR 2009 and 2010) will be reviewed as
    part of the BVG/MWG

70
Resulting ISO 20022 messages
  • -20 ISO 15022 messages effectively covering -
    90 instruction type/activity combinations
  • -30 ISO 20022 messages
  • Important decisions
  • MT 540-3 ? 1 Settlement Instruction
  • Listed derivatives and securities financing
    functionalities in dedicated messages
  • One cancellation request and one cancellation
    advice
  • Status reporting per process ? - 5 status
    messages

71
Resulting ISO 20022 messages
72
Resulting ISO 20022 messages
Instruction Process Instruction Process
ISO 15022 ISO 20022
MT 540 (NEWM) Settlement Instruction HoldIndicator N
MT 541 (NEWM) Settlement Instruction HoldIndicator N
MT 542 (NEWM) Settlement Instruction HoldIndicator N
MT 543 (NEWM) Settlement Instruction HoldIndicator N
MT 540 (NEWM) for securities financing Securities Financing Instruction
MT 541 (NEWM) for securities financing Securities Financing Instruction
MT 542 (NEWM) for securities financing Securities Financing Instruction
MT 543 (NEWM) for securities financing Securities Financing Instruction
MT 540 (NEWM) for listed derivatives Trade Notification (post-trade project)?
MT 541 (NEWM) for listed derivatives Trade Notification (post-trade project)?
MT 542 (NEWM) for listed derivatives Trade Notification (post-trade project)?
MT 543 (NEWM) for listed derivatives Trade Notification (post-trade project)?
73
Resulting ISO 20022 messages
Instruction Process Instruction Process
ISO 15022 ISO 20022
MT 540 (PREA) Settlement Instruction HoldIndicator Y
MT 541 (PREA) Settlement Instruction HoldIndicator Y
MT 542 (PREA) Settlement Instruction HoldIndicator Y
MT 543 (PREA) Settlement Instruction HoldIndicator Y
MT 524 (NEWM) Intra-Position Movement Instruction
74
Resulting ISO 20022 messages
Modification Process Modification Process
ISO 15022 ISO 20022
MT 530 (NEWM) Transaction Processing Command
MT 540-3 23GCANC MT 540-3 23GNEWM Replace Instruction
MT 540-3 23GCANC MT 540-3 23GNEWM for securities financing Securities Financing Modification Instruction
75
Resulting ISO 20022 messages
Cancellation Request Process Cancellation Request Process
ISO 15022 ISO 20022
MT 540 (CANC) Cancellation Request
MT 541 (CANC) Cancellation Request
MT 542 (CANC) Cancellation Request
MT 543 (CANC) Cancellation Request
MT 540 (CANC) for listed derivatives Cancellation Request
MT 541 (CANC) for listed derivatives Cancellation Request
MT 542 (CANC) for listed derivatives Cancellation Request
MT 543 (CANC) for listed derivatives Cancellation Request
MT 540 (CANC) for securities financing Cancellation Request
MT 541 (CANC) for securities financing Cancellation Request
MT 542 (CANC) for securities financing Cancellation Request
MT 543 (CANC) for securities financing Cancellation Request
MT 524 (CANC) Cancellation Request
MT 549 (CANC) Cancellation Request
76
Resulting ISO 20022 messages
Status Reporting Process Status Reporting Process
ISO 15022 ISO 20022
MT 549 (NEWM) Request For Status/Statement
MT 548 (INST) 25DSPRC Request For Status/Statement Status Advice
MT 548 (INST) 25DIPRC Settlement Transaction Status Advice
MT 548 (INST) 25DIPRC (PREA) Settlement Transaction Status Advice (trade details on hold indicator Y)
MT 548 (INST) 25DIPRC for listed derivatives Trade Status (Post-Trade project)?
MT 548 (INST) 25DIPRC for securities financing Settlement Transaction Status Advice Or Securities Financing Instruction Status Advice
MT 548 (INST) 25DTPRC Transact. Process. Command Status Advice
MT 548 (INST) 13BLINK//524 25DIPRC Intra-Position Movement Instruction Status Advice
MT 548 (CAST) 25DCPRC Cancellation Request Status Advice
MT 548 (CAST) 13BLINK//524 25DCPRC Cancellation Request Status Advice
77
Resulting ISO 20022 messages
Status Reporting Process Status Reporting Process
ISO 15022 ISO 20022
MT 548 (INST) 25DIPRC//CGEN MT 540 (NEWM/RECO) for generated inx Generated Settlement Transaction Advice
MT 548 (INST) 25DIPRC//CGEN MT 541 (NEWM/RECO) for generated inx Generated Settlement Transaction Advice
MT 548 (INST) 25DIPRC//CGEN MT 542 (NEWM/RECO) for generated inx Generated Settlement Transaction Advice
MT 548 (INST) 25DIPRC//CGEN MT 543 (NEWM/RECO) for generated inx Generated Settlement Transaction Advice
MT 548 23GCAST MT 548 23GINST Replace Instruction Status advice Or Settlement Transaction Status Advice
MT 548 23GCAST MT 548 23GINST for securities financing Securities Financing Modification Instruction Status advice Or Securities Financing Instruction Status Advice Or Settlement Transaction Status Advice
78
Resulting ISO 20022 messages
Confirmation Processes Confirmation Processes
ISO 15022 ISO 20022
MT 544 (NEWM) Settlement Confirmation
MT 545 (NEWM) Settlement Confirmation
MT 546 (NEWM) Settlement Confirmation
MT 547 (NEWM) Settlement Confirmation
MT 544 (NEWM) for securities financing Settlement Confirmation
MT 545 (NEWM) for securities financing Settlement Confirmation
MT 546 (NEWM) for securities financing Settlement Confirmation
MT 547 (NEWM) for securities financing Settlement Confirmation
MT 544 (NEWM) for listed derivatives Trade status advice (post-trade project?)
MT 545 (NEWM) for listed derivatives Trade status advice (post-trade project?)
MT 546 (NEWM) for listed derivatives Trade status advice (post-trade project?)
MT 547 (NEWM) for listed derivatives Trade status advice (post-trade project?)
MT 508 (NEWM) Intra-Position Movement Advice
79
Resulting ISO 20022 messages
Reversal Process Reversal Process
ISO 15022 ISO 20022
MT 544 (RVSL) Reversal Advice
MT 545 (RVSL) Reversal Advice
MT 546 (RVSL) Reversal Advice
MT 547 (RVSL) Reversal Advice
80
Resulting ISO 20022 messages
Reconciliation processes Reconciliation processes
ISO 15022 ISO 20022
MT 549 (NEWM) Request For Status/Statement
MT 535 23GNEWM 22FSTTY//ACCT Accounting Statement of Holdings
MT 535 23GNEWM 22FSTTY//ACCT Custody Statement of Holding
MT 536 (NEWM) Statement Of Transactions
MT 537 23GNEWM 22FSTST//STAT Statement Of Pending Transactions
MT 537 23GNEWM 22FSTST//TRAN Statement Of Pending Transactions
MT 538 (NEWM) Statement of Intra-Position Advice
MT 586 (NEWM) Statement of Allegements
81
Resulting ISO 20022 messages
Cancellation Advice Process Cancellation Advice Process
ISO 15022 ISO 20022
MT 544 (CANC) Cancellation Advice
MT 545 (CANC) Cancellation Advice
MT 546 (CANC) Cancellation Advice
MT 547 (CANC) Cancellation Advice
MT 508 (CANC) Cancellation Advice
MT 535 (CANC) Cancellation Advice
MT 536 (CANC) Cancellation Advice
MT 537 (CANC) Cancellation Advice
MT 538 (CANC) Cancellation Advice
MT 578 (CANC) Cancellation Advice
MT 586 (CANC) Cancellation Advice
82
Resulting ISO 20022 messages
Allegement process Allegement process
ISO 15022 ISO 20022
MT 578 (NEWM) Allegement Advice
MT 586 (NEWM/PORT) Portfolio Transfer Allegement
83
Resulting ISO 20022 messages
Removal process Removal process
ISO 15022 ISO 20022
MT 578 (REMO) Removal Advice
84
Resulting ISO 20022 messages
  • Settlement Instruction
  • Securities Financing Instruction
  • Trade Notification (post-trade project)?
  • Intra-Position Movement Instruction
  • Transaction Processing Command
  • Replace Instruction
  • Securities Financing Modification Instruction
  • Cancellation Request
  • Cancellation Advice
  • Request For Status/Statement
  • Request For Status/Statement Status Advice
  • Settlement Transaction Status Advice
  • Trade Status (Post-Trade project)?

85
Resulting ISO 20022 messages
  • Securities Financing Instruction Status Advice
  • Transaction Processing Command Status Advice
  • Intra-Position Movement Instruction Status Advice
  • Cancellation Request Status Advice
  • Generated Settlement Transaction Advice
  • Securities Financing Modification Instruction
    Status advice
  • Settlement Confirmation
  • Intra-Position Movement Advice
  • Reversal Advice
  • Accounting Statement of Holdings
  • Custody Statement of Holding
  • Statement Of Transactions

86
Resulting ISO 20022 messages
  1. Statement Of Pending Transactions
  2. Statement of Intra-Position Advice
  3. Statement of Allegements
  4. Allegement Advice
  5. Portfolio Transfer Allegement
  6. Removal advice

87
WARNING
  • Industry Consultation is still on, so feedback on
    the decisions in this document is still welcome
  • Details such as ISO 20022 message/component/elemen
    t names may change
Write a Comment
User Comments (0)
About PowerShow.com