Increasing Certainty and Promoting Intraday Settlement Finality: A Service Description for Settlement Matching MARCH 2013 1
Table of Contents Executive Summary...3 Background and Current Processing...5 New Settlement Process...6 Stage 1 Reducing DTCC s RAD Default Limits in... Half Targeted for July 2013... 7 Stage 2 Stock Lending Profiles Targeted for Q3 2013...8 Stage 3 Reducing DTCC s RAD Default Limits... to Zero Targeted for January 2014... 10 Stage 4 Subjecting ID Transactions to Receiver... Approval Targeted for Q1 2014... 13 Appendix A Key Changes for Stage 3... 18 Appendix B Key Changes for Stage 4...23 Appendix C Settlement Matching Website...26 Appendix D Settlement Matching Transaction Matrix...27 2
Executive Summary The Depository Trust & Clearing Corporation (DTCC), through its subsidiary, The Depository Trust Company (DTC), will institute Settlement Matching for DTCC Participants beginning in 2013, bringing significant enhancements to the settlement process and further reducing risk for DTCC and its Participants. Settlement Matching will be introduced in a manner that promotes institutional trade affirmation and encourages straight-through processing (STP) by implementing a transaction matching component into DTCC s existing settlement processes. DTCC will leverage existing infrastructure to provide Participants with the ability to authorize or match transactions prior to settlement. This will eliminate the need for reclamation transactions and the accompanying credit and liquidity risk, a significant step in risk mitigation for the industry. In addition to the inherent credit and liquidity risks, a number of other drawbacks come with the current settlement process, including the inability to credit underlying customer accounts without risk of reversal, limited transparency of erroneous or disputed transactions, and costly manual intervention. Also, most reclaims are processed primarily late in the day making it difficult for the original deliverer to take corrective action or use the securities for other funding opportunities. In contrast, Settlement Matching will bring benefits to the U.S. market, including: Enhanced intraday settlement finality through the elimination of reclaim processing, Improved straight-through processing capabilities, Promotion of best practices for institutional trade matching, and, Better positioning the industry for a shortened settlement cycle. The Settlement Matching initiative follows on DTCC s recent efforts to further reduce systemic risk and its heightened focus on risk management. It also aligns DTCC with the intraday settlement finality recommendations of the Committee on Payment and Settlement Systems of the International Organization of Securities Commission, collectively known as CPSS-IOSCO. Settlement Matching will be supported in one of two ways: Affirmed institutional transactions will be sent to DTCC in a straight-through processing manner and will automatically trigger the settlement match, otherwise known as passive matching. In addition, DTCC will leverage current exemption functionality to allow receivers to pause or prevent settlement and allow Participants to make appropriate credit decisions. Unaffirmed institutional trades and other transactions types such as stock loan and stock loan returns, future dated and same day deliver orders and payment orders will be matched leveraging the current Receiver Authorization Delivery (RAD) process. Implementation plans for Settlement Matching for unaffirmed institutional transactions and other transactions types are as follows: Beginning in July 2013, DTCC will require significantly more transactions to be authorized in the 3
RAD system. Specifically, DTCC will lower the current RAD thresholds from $15 million and $1 million for securities and payments, respectively, to $7.5 million and $500,000. Participants are encouraged to automate their RAD interaction with DTCC if not already in place. Beginning in January 2014, DTCC will require all transactions to be authorized in the RAD system. Specifically, DTCC will lower the RAD thresholds from $7.5 million and $500,000 for securities and payments, respectively, to zero. Again, Participants are encouraged to automate their RAD interaction with DTCC if not already in place. Implementation for affirmed institutional transactions is as follows: Beginning in Q1 2014, DTCC will support Passive Matching for all affirmed institutional trades to promote both trade affirmation and STP settlement. In preparation, Participants should ensure that they are able to leverage new reporting as well as receiver exemption from Passive Matching. The purpose of this document is to help prepare Participants for the changes that will come with Settlement Matching, provide details for each implementation stage and advise them on what steps they will need to take in the coming months. For more information on Settlement Matching, please contact your Relationship Manager, or Jack Manuel, DTCC Director, Settlement Product Management at jmanuel@dtcc.com or (212) 855-5921 4
Background and Current Processing DTCC has set the benchmark for the safe and secure settlement of financial transactions in the U.S. for more than 40 years and has delivered certainty, reliability and risk mitigation to facilitate the growth of these markets into the deepest, most liquid and efficient in the world. DTCC has historically leveraged a deliverer based system to ensure maximum throughput and efficient settlement for the millions of obligations that settle each day. Beginning in 1996 and pursuant to the industry s migration to same day funds settlement, DTCC introduced receiver controls. In order to preserve settlement throughput, DTCC implemented these controls for Deliver Orders (DOs) over $15 million and Payment Orders (POs) over $1 million. These thresholds allowed the receiver to review and approve high value transactions without impeding transaction throughput for their lower value transactions. The transactions that could be approved by receiving Participants were no longer permitted to be reclaimed at DTCC. To ensure that the receiver had no restrictions in reclaiming erroneous transactions, same-day reclaims for DOs below $15 million and POs below $1 million are permitted without regard to debit cap and collateral monitor risk management controls or RAD. DTCC settles approximately 1.4 million transactions per day after netting with a value of approximately $550 billion. DTCC receives the vast majority of its settlement-related transactions from three sources: National Securities Clearing Corporation (NSCC) NSCC is the central counterparty to cleared trades in the U.S. and submits netted settlement obligations to DTCC each day. These transactions, representing approximately 550,000 transactions and $65 billion, are pre-matched, locked in and not available for reclaim. These Continuous Net Settlement (CNS) transactions will not require an additional Settlement Matching. Omgeo As a Qualified Vendor approved by the Securities and Exchange Commission (SEC), Omgeo submits affirmed institutional transactions directly to DTCC in real-time. Today they are subjected to a deliverer authorization to support Participants inventory management. Once the deliverer authorizes the transaction, DTCC will process subject to RAD limits and will support reclaims by receivers which override DTCC controls. Reclaims for affirmed institutional transactions are generally low (under 1%) as the trade terms have been agreed in advance. Participants As Participants, banks, brokers (and their Service Providers) submit transactions directly to DTCC. These transactions types are deliverer driven and primarily consist of unaffirmed institutional transactions, future dated and same day DOs and POs. If these transactions exceed the current RAD levels ($15 million and $1 million) they may be approved by the receiver and will not be reclaimable. If they are below the RAD limits, which most are, they will bypass RAD and the receiver can reclaim at any time on that settlement date. These transactions carry higher reclaim rates currently approximately 5%. The ability to reclaim a processed transaction undermines intraday finality. Allowing receiving Participants to unilaterally reverse transactions late in the afternoon of settlement date means processed transactions are not reliable until the end of DTCC s reclaim cutoff which generally occurs at approximately 3:30 PM. This lack of intraday certainty can preclude the timely updating of customer s accounts by Participants and extends the window of risk associated with processed transactions until very late in the settlement day when there is generally little opportunity to react to unknown transactions. To resolve such risk, DTCC will provide the receiver of each transaction the ability to either passively or actively approve transactions prior to settlement obviating the need for reclaims. 5
New Settlement Process Settlement Matching will improve the overall U.S. settlement process by enhancing intraday finality and reducing risks of reclaims. DTCC plans to implement Settlement Matching by leveraging existing workflows and functionality while also promoting best practices. Settlement Matching will: 1. Reduce fails and related financing costs through the provision of additional transparency around potential settlement errors that can be resolved earlier on settlement date. 2. Provide for prudent review by receivers as transactions hit their DTCC accounts in lieu of relying on a late day reversal or reclaim process. 3. Eliminate the ability for Participants to generate false intraday credits in lieu of actual funding through the elimination of reclaims. 4. Reduce costs associated with the back and forth nature of deliveries and reclaims. Settlement. Matching has also been identified as a key enabler to move to a shortened settlement cycle. With Settlement Matching, only matched transactions will be submitted to DTCC s settlement systems. Unmatched transactions will be routed to RAD where they will remain until approved or until the end of the processing day, at which point DTCC will no longer attempt to process the transaction. Once a transaction is matched, it will be subjected to the same control checks and processing cutoffs that are currently in place. Any transaction that completes in DTCC s settlement system will be considered final and no longer eligible for reclaim processing, i.e., the return of an erroneously approved transaction will be processed by DTCC as any other original transaction, subjecting it to DTCC s controls and the receiver s RAD limits. Reducing the risk of reclaims as soon as possible must be balanced against the changes necessary for DTCC and its Participants to make this implememtation seamless. DTCC recognizes that Participants will need enough lead time to review their approval process internally and with DTCC to ensure they can authorize a receive earlier in the processing day. Because of this, DTCC has chosen to implement Settlement Matching in stages. 6
STAGE 1 REDUCING DTCC S RAD DEFAULT LIMITS IN HALF TARGETED FOR JULY 2013 DTCC will leverage RAD to subject the applicable transactions 1 to the Settlement Matching requirement. RAD is an application that allows the receiver to review and either approve or cancel incoming deliveries prior to DTCC attempting to process the transaction to their account. DTCC and Participants manage transactions requiring RAD approval through the use of profile limits, of which there are three types: 1. DTCC default limits. These are the limits that DTCC has established. They currently are set at $15 million for DOs and $1 million for POs. Default limits represent the lowest value for RAD limits. Participants who elect to use default limits are instructing DTCC to subject applicable transactions above these limits to Matching and await further instruction prior to attempting to settle. 2. Global profile limits. Participants are allowed to define their own global limits for DOs and POs. Global limits allow the receiver to set a single value that is applied across all contra Participant accounts. The global limit is set at a higher value than DTCC s default limits, allowing transactions with settlement values that are greater than DTCC s default limits but less than the Participant-defined global limits to receive a passive approval and be submitted to DTCC s settlement system for further processing. 3. Bilateral profile limits. Participants are also allowed to define bilateral limits for DOs and POs. Bilateral limits allow the receiver to set a single value that is applied to a specific contra. Similar to global limits, bilateral limits are set at a higher value than DTCC s default limits which allow transactions from the specified deliverer to be passively approved. For any contra that is not assigned a specific bilateral profile by the receiver, DTCC assigns its default limits and processes accordingly. As transactions are submitted to DTCC, they are checked versus the receiver s RAD limits to determine whether the transaction requires receiver approval, and if it does, whether an active approval is needed or whether passive approval has been granted. It is important to note, however, that the return of erroneously approved transactions, whether the approval was provided passively or actively granted, will be subjected to the receiver s (the original deliverer) RAD limits and DTCC s risk controls. Impact to Participants When the RAD limits are halved, additional DOs and POs will become RAD eligible and be subjected to the Settlement Matching. Specifically, any valued DOs received between $7,500,001 and $15,000,000 and POs between $500,001 and $1,000,000 will be checked against the receiver s RAD profiles 2. Additionally unilateral reclaims with a settlement value exceeding DTCC s new default limits will no longer be supported. DTCC will process these returns as original transactions subjecting them to the receiver s controls and RAD limits. Changes to input or output There will be no input or output changes resulting from this change to RAD limits. 1 Valued transactions received directly from banks, broker or service providers and not from Omgeo. 2...Participants can gauge their anticipated increase in RAD eligible volumes for this phase by using the excel download function in the activity inquiry screen of the Settlement Web and filtering the number of applicable transactions based on their value. 7
STAGE 2 STOCK LENDING PROFILES TARGETED FOR Q3 2013 DTCC recognizes that the nature of the stock lending business is very different from business models that drive other activity. Stock loans are generally agreed upon same day and have a relatively low reclaim rate. Many lenders and borrowers feel that subjecting stock loans to an active borrower (the receiver) approval immediately after the stock loan agreement is procured would result in an unnecessary stop along the stock loan settlement process. Conversely, stock loan returns generally happen when the borrower no longer has a need for the securities or the lender requests a recall of the securities lent. In either case, the lender is expecting the position to be returned and, similar to stock loans, many lenders (the receiver) feel as though an active approval is unnecessary. To accommodate the stock lending business model, DTCC will enhance the existing RAD functionality by creating a stock lending profile which will allow Participants to establish RAD authorization limits specifically for stock loan and stock loan return activity. Participants opting to use the stock lending profile will be able to establish separate matching workflows for stock loan and stock loan return related activity which will reduce the number of transactions requiring an active approval. How the profile will work Use of the stock lending profile is optional. Participants that do not create a stock lending profile will have their applicable stock lending transactions subjected to the same RAD processing rules as any other valued DO, i.e., transactions with stock lending reason codes will be subjected to the same DTCC default limits or Participant-defined bilateral or global limits as any other valued DO. 3 The stock lending profile will be available through the Settlement Web only. As with other profiles maintained in the Settlement Web, access to the profile will be controlled by a user s role. 4 Participants will be allowed to establish bilateral and global limits for stock lending transactions based upon the reason codes listed below. Applicable stock lending transactions will be checked against the receiver s stock lending profile limits where it will be provided with a passive approval or await the receiver s active approval based on the parameters of the stock lending profile. 10 - Stock Loan 20 - Stock Loan Return 220 - Repo Tracking 230 - Repo Tracking Return 260 - OCC Stock Loan 270 - OCC Stock Loan Return 280 - ADR Stock Loan (Untracked) 290 - ADR Stock Loan Return (Untracked) 3...Stock lending transactions that are free of payment, as is the case for any other free DO, will not be subjected to the Settlement Matching requirement. 4 For more information on roles and the Settlement Web, see important notice #1245-11 published August 31, 2011 8
600 - Collateral DO 610 - Collateral DO Return 630 - Repo with Memo Decrease 640 - Repo Return with Memo Decrease 704 - OCC Stock Loan (Untracked) 706 - OCC Stock Loan Return (Untracked) As today, all profile creations and modifications in the Settlement Web will be subjected to secondary approval and will be effective upon that approval. Stock lending profiles will not be customizable by reason code or asset class. 9
STAGE 3 REDUCING DTCC S RAD DEFAULT LIMITS TO ZERO TARGETED FOR JANUARY 2014 When DTCC reduces its RAD default limits to zero, all valued RAD eligible DOs and POs will be subjected to the Settlement Matching requirement. DTCC will continue its support of Participant-defined global or bilateral RAD limits, i.e., Participants will continue to be allowed to define RAD limits in excess of DTCC s default limits, allowing receives to be processed to their account without active approval being granted (passive authorization). The impact of this stage is that Participants may see a significant increase in transactions that are eligible for RAD processing, and the return of erroneously approved transactions that will be processed by DTCC as an original transaction, i.e., they will be subjected to DTCC s controls and the receiver s RAD limits. To assist Participants with earlier authorizations of these items, DTCC will make Night Deliver Order (NDO) 5 output and the ability to authorize receive transactions manually or via automated messages available sooner. Approving receives early, e.g., before the start of the night cycle, will permit Participants in certain cases to preserve their current delivery fees, e.g., if a receive is necessary to complete a delivery to CNS, and it isn t authorized until the day cycle, the delivery to CNS in the day cycle will be subject to the NSCC CNS day fee of $0.40. DTCC strongly recommends that Participants automate their matching process in advance of this implementation. Making Night Deliver Order (NDO) output available earlier Currently, DTCC makes available NDO output regarding a delivery s status, e.g., awaiting approval in RAD, etc. at approximately 9:00 P.M. on S-1. As this implementation nears, DTCC will accelerate the timing of output and the application of deliverer and receiver authorization profiles. Profiles, i.e., delivery authorization and receiver RAD profile limits, will continually be applied in real-time to any additional NDO instructions received after noon on S-1. Both receivers and deliverers of NDO transactions will be provided with options that will permit them to choose to commingle current day and next-day RAD output messages (and filter as necessary) or only accept RAD output messages for the next settlement date after the current day s RAD messaging for valued transactions has completed. The default option will be to have DTCC withhold NDO output until approximately 4:00 P.M. on S-1 when the day cycle processing has completed. 6 The output messages communicated at this time will be of the current transaction status, i.e., output messages will reflect the results of the NDO authorization profile as well as any subsequent deliverer or receiver updates to NDO transactions. Additional output messages resulting from deliverer or receiver actions will be made available as they occur in real-time. Alternately, Participants can elect to receive their NDO output as early as noon on S-1. Output messages at this time will reflect the status of each transaction following the NDO authorization profile being applied. 5...NDOs are deliveries that are input by Participants before settlement date and are processed in the night cycle which typically starts at 8:00 pm on S-1. 6..If DTCC has a settlement extension, the availability of these messages will also be delayed. DTCC recommends that firms begin taking the output at noon on S-1 to avoid delays from processing extensions and filter which transactions require approval on settlement date and those for the next-day s processing. 10
It should be noted that either of the options above represent change from today s processing and that Participants may need to make coding changes to accommodate the new timing of NDO output availability. To assist automated Participants with processing additional NDO receives requiring approval, DTCC will repurpose existing filler space within the RAD output file layout into two new fields - an intended delivery date and settlement date. The intended delivery date will allow Participants to filter NDO activity due to settle on the following business day from day cycle RAD transactions. The settlement date will provide Participants with another field which may be used as part of their matching criteria. An additional change to RAD output will be the inclusion of a Transaction Type Indicator. This new field will allow participants to distinguish ID transaction from NDOs or other same day settling transaction types. To further assist Participants with the Settlement Matching requirement, DTCC will repurpose existing filler spaces within its settlement outputs to include the IMS TID. 7 Making the IMS TID available through settlement output will allow Participants to link transactions approved in RAD 8 to the actual output record. Allowing Participants to make updates earlier Today receivers of NDOs are not made aware that a transaction is awaiting their authorization in RAD until the NDO authorization profile is applied which, as mentioned above, occurs at approximately 9:00 P.M. on S-1. Since DTCC is accelerating the timing of this profile to noon of S-1, RAD input processing windows will also be extended allowing receivers to provide authorizations of their NDOs earlier in the settlement cycle. As this implementation nears, DTCC will begin accepting NDO transaction updates as early as noon of S-1 through the Settlement Web and automated messages. While expanding the NDO receiver authorization window will allow Participants to provide authorizations earlier in the settlement cycle, it also introduces the potential need for a receiver to reverse an approval that may have been provided in error. Manual reversals of approved receives will be allowed in the Settlement Web only. Reversal commands received prior to the start of the night cycle will change the transaction status from approved to unprocessed. Approval reversals will not be allowed once a transaction is submitted for settlement. However, if the transaction pends in DTCC s settlement system, receivers will be allowed to submit Pend Cancels. DTCC will consider the cancellation as a final transactions status and no longer attempt to process the delivery. Participant adjustments to RAD limits ahead of DTCC lowering default limits Currently, DTCC does not allow bilateral or global limits to be set below DTCC s default limits. Prior to this implementation, DTCC will amend this practice and begin accepting bilateral and global limits at any level. This change is being offered so Participants will not have to coordinate the lowering of their limits on the same day that DTCC s reduces its limits to zero. Any bilateral or global limits established below DTCC s current default limits during this interim time will not be applied. 7 The IMS TID is a unique transaction identifier assigned by DTCC that remains constant throughout the settlement process. 8 In RAD, the IMS TID is referred to as the RAD Sequence Number. 11
The table below summarizes the key changes targeted for Stage 3. Appendix A of this document outlines the more detailed specifications to facilitate the Stage 3 changes outlined in this document. Change to: Changes Impact at this Stage Format RAD Output 1. Intended Delivery Date will be made available in the filler of the message. 2. Settlement Date will be made available in the filler of the message 3. Real-Time RAD Output will be available at noon on S-1 4. Create a Transaction Type Indicator field 1. This is an optional field for Participants, but can be used to filter messages between Same Day and Next Day transactions. 2. This is an optional field for Participants, but can be used as an additional matching criterion. 3. Participants can receive their output as early as noon on S-1 or opt to have their real-time output delayed until approximately 4:00 PM. 4. Participants will provided with an indicator as to whether the transaction is ID, a future dated NDO or a same-day transaction 1. Proprietary MQ (already available via ISO) 2. Proprietary MQ (already available via ISO) 3. Proprietary MQ (ISO messages are real-time) 4. Proprietary MQ messaging (already available via ISO) Settlement Output 1. RAD Sequence Number (IMS TID) 1. This is an optional field for Participants, but can be used as an additional matching criterion 1. Proprietary MQ (already available via ISO) RAD Transaction Commands 1. Introduce a reversal command 2. Input processing windows will be extended 1. Receivers will be allowed to reverse an approval of an NDO receive prior to the start of night cycle processing 2. Transaction updates will be accepted as early as noon of S-1 1. Manual Input via Settlement Web only 2. Automated input via proprietary MQ and ISO and manual input via the Settlement Web ATP Pend Processing 1. Introduce receiver pend cancels 1. Receivers will be allowed to cancel pending receives that may have been approved in error 1. Manual Input via Settlement Web and Proprietary MQ and ISO 12
STAGE 4 SUBJECTING ID TRANSACTIONS TO RECEIVER APPROVAL TARGETED FOR Q1 2014 Currently, Omgeo submits affirmed institutional transactions in real-time to DTCC until noon on S-1 where they await deliverer authorization prior to DTCC processing. Deliverers of ID transactions manage their ID authorizations through the IMS Authorization and Exemption (ANE) system. ANE allows deliverers to provide global or individual authorizations or exemptions of their ID deliveries through automated messages or manually via PTS or PBS. Cancellations can also be made but on an individual transaction basis. On noon of S-1, DTCC applies a Participant s ID Authorization Profile which allows deliverers of ID transactions to choose between providing an active or passive authorization for their unprocessed ID deliveries (the default setting is active). Subsequent deliverer updates are allowed until the night cycle begins. 9 Deliveries authorized as a result of this profile and subsequent deliverer updates are prepped for night cycle processing which begins at approximately 9:00 P.M. on S-1. It is at this time that that DTCC routes transactions to RAD or its settlement system depending on applicable ID Trades profiles and makes output available to Participants. There will be no changes to this process. With this implementation, DTCC, in addition to requiring deliverer authorization, will begin to require receiver authorization of the ID transaction prior to settlement. DTCC will leverage RAD to facilitate receiver approval and output of ID receives and extend the same automated and manual deliverer ANE capabilities outlined above to the receivers of ID transactions. DTCC will commingle ID transaction output with the NDO output from stage 3 (ID transactions will be distinguishable from other DOs see Transaction Type Indicator mentioned in Stage 3). This earlier output will permit Participants to update ID receives earlier in the settlement process as discussed above for NDOs ID Receiver Authorizations DTCC will create an ID receiver authorization profile in RAD to actively or passively authorize their unprocessed ID receives. Similar to the ID deliverer authorization profile, the receiver profile will be applied to all. ID receives in an unprocessed state at noon of S-1. The default profile for receivers will be passive, i.e., the receive will be submitted to DTCC s settlement system on S-1 when the night cycle begins if the deliverer also authorized the transaction. The passive default setting for the profile will permit straight-through-processing as the majority of Participants consider institutional transactions as matched when they are affirmed and therefore do not require a second authorization. However, DTCC will offer the ability for receivers to exempt individual transactions or create an active profile for those firms that require additional time to perform credit checks and/or confirm customer instructions. Receivers of ID with active profiles will not have their receives submitted for settlement upon deliverer authorization. Instead, these transactions will remain in an unprocessed or, if applicable, exempt state until receiver authorization is indicated. Exempted or unprocessed transactions should be authorized/approved in order to receive the lower ID fee of $0.05. Unmatched ID Transactions Transactions that are not authorized by both parties when the profile is applied will be considered unmatched by DTCC and not submitted to the settlement system for processing. The status of each transaction will be made available to Participants through the Settlement Web (today, receivers don t see an exempted or can- 9 Deliverer updates submitted after the beginning of DTCC s night cycle are accepted but processed in the following day cycle. 13
celled ID delivery) or systemically through RAD output. Any transaction with an unmatched status that is subsequently matched through automated or manual means will be accepted into DTCC s settlement system where it will be subjected to applicable cutoffs and DTCC s risk management controls. Allowing Participants to make updates earlier ID transactions currently follow a serial approval process. With this implementation, DTCC will begin to support a parallel approval process allowing the receiver to authorize, exempt or cancel an ID delivery in RAD as soon as DTCC receives the instruction from Omgeo. DTCC will continue to allow deliverers to make transaction updates and begin to accept receiver updates to ID transactions prior to and after the authorization profile being applied. 10 Transaction updates can be communicated to DTCC automatically or manually through the Settlement Web. For Automated Updates Deliverers of ID transactions will continue to manage their ID authorizations through IMS ANE system. Receivers of ID will provide updates for their ID receives through RAD. To ensure RAD capabilities for ID receivers mirror that of ANE functionality provided to ID deliverers, DTCC will change RAD input for ID in three ways: 1. A receiver exemption command will be created. Today the concept of exempting a delivery applies to ANE only. The addition of the receiver exemption command in RAD will synchronize RAD transaction statuses with ANE, providing ID receivers the same transaction update capabilities afforded to ID deliverers in ANE. a. This change will be made for ISO and proprietary formats. 2. Global update capabilities will be introduced. This will allow receivers to globally authorize or exempt their ID receives through RAD mirroring deliverer global updates currently available to ID deliverers in the ANE system. b. This change will be made to the proprietary formats only as global command processing already exists in ISO. 3. A new field for the ID control number will be created. The addition of this field will allow ID receivers to approve, exempt or cancel an ID transaction using the Omgeo control number. c. This change will be made to the proprietary format only as ISO users are allowed to use the. Omgeo control number today. Rather than modifying the existing RAD input file specifications to accommodate these changes and potentially forcing all Participants to make coding changes, DTCC will create another version (Version 2) of the layout and make it available to interested parties. DTCC will continue to support version 1 of the RAD input file specifications for those Participants who have already coded to approve their ID receives in RAD using the RAD Sequence Number. Participants who want to use the new input capabilities outlined above must use Version 2. 10..Output messages reflecting deliverer or receiver updates prior to the authorization profile application will not be made available. The initial output message will depend on the option you choose and always reflect the current deliverer and receiver transaction status. 14
To reflect to the new RAD exemption transaction status on output messages, DTCC will add another value to the RAD Action Code field within the existing RAD output file specifications. For Manual Updates DTCC will continue to support PTS and PBS deliverer authorization, exemption and cancellation capabilities of ID transactions, but receiver updates will be available in the Settlement Web only. ID transactions will be available for viewing and updates as they are received by DTCC. Participants will be offered an option allowing them to isolate their ID transactions requiring action from other non-id transactions. The new functionality in the Settlement Web will provide receivers and deliverers of ID transactions the same update capabilities available to deliverers of ID in PTS and PBS today, i.e., global update options will be available for approvals and exemptions, but cancellations will be permitted for individual transaction only. END OF DAY DROP PROCESSING Matched Drops Recycle drops, which are matched transactions that fail to complete in DTCC s settlement system, will be processed and reported as they are today. If the deliverer has a reintroduced drop profile established, DTCC will submit the failed delivery on behalf of the Participant according to that profile. If the deliverer does not have a profile established, redelivery will be the responsibility of the delivering party. In either case, DTCC will subject the reintroduced delivery to the Settlement Matching requirement, i.e., deliverer and receiver authorization/ approval will be required again. Unmatched RAD Drops RAD drops, which are unmatched transactions that do not get submitted for settlement, will be included in the RAD drop output file that is available today. From the Deliverer s Perspective If you authorized, as the deliverer, your delivery but the transaction is unmatched because the receiver did not provide authorization, i.e., the receiver took no action, exempted or cancelled the instruction, DTCC will reintroduce the delivery instruction for you if your firm has an active reintroduced drop profile. If no profile exists, you, as the deliverer will be responsible for the redelivery. In either case, the receiver will need to react to the new delivery if and when it is submitted to DTCC. If the receiver authorized your delivery but the transaction is unmatched because you as the deliverer did not provide authorization, end of day processing will be as follows: If the status of your delivery ends the day in an: 1. Cancelled status Once cancelled, the transaction status is final, i.e., DTCC will no longer allow for processing updates. 2. Unprocessed status The transaction status will be changed to exempt where it will remain in IMS for 21 business days or until you as the deliverer provide DTCC with an update, either cancelling or authorizing the transaction. If you subsequently authorize the exempted transaction during this window, 15
DTCC will reinitiate the transaction and re-subject it to the Settlement Matching requirement by making it available for receiver approval. 3. Exempted status the transaction status will be maintained in IMS for 21 business days or until you as the deliverer provide DTCC with an update. If authorized, the transaction will follow the process outlined above. From the Receiver s Perspective Receiver statuses will be maintained through the intended delivery date only. As a result of this, end-of-day processing rules are the same regardless of whether you as the receiver authorized, exempted, cancelled or left the receive in an unprocessed state. In all cases, DTCC will drop the status with the applicable end of day cutoff of the intended delivery date, e.g., an approval for a transaction due to settle today will not remain active for tomorrow s business date. The table below summarizes the key changes targeted for Stage 4. Appendix B of this document outlines the changes DTCC will make to its existing file specifications to facilitate the Stage 4 changes outlined in this document. Changes to: Changes Impact Format RAD Input 1. Introduce exemptions as a transaction status in RAD 2. Create global transaction update capabilities 3. Create an ID control number field 1. ID receivers and deliverers will be permitted to exempt transactions through RAD 2. Global updates will be permitted through RAD 3. Participants will be able to provide authorizations using the Omgeo control number 1. Automated through ISO and Version 2 of Proprietary MQ and manually through the Settlement Web 2. Automated through ISO and Version 2 of Proprietary MQ and manually through the Settlement Web 3. Automated through ISO and Version 2 of Proprietary MQ and manually through the Settlement Web RAD Output 1. Modify the RAD action code to include exempted transactions 2. Real-time RAD output will be available at noon on S-1 1. Output will reflect the new input outlined above 2. Participants can receive their output as early as noon on S-1 or opt to have their real-time output delayed until approximately 4PM. 1. Proprietary MQ and ISO 2. Proprietary MQ (ISO messages are real-time) ID Receiver Authorization Profile 1. Create an authorization profile for ID receivers 1. ID receivers will be provided with an option to provide passive or active authorizations of their ID receives the default will be passive 1. RAD Profile setting With the completion of the Settlement Matching Initiative, DTCC will have successfully eliminated the systemic risks inherent with reclaimed transactions and more closely align its settlement processes with international 16
standards regarding intraday settlement finality. DTCC will publish additional materials regarding this initiative in advance of each implementation stage including the timing of changes, testing availability, etc. Questions regarding the Settlement Matching initiative can be directed to your Relationship Manager or Jack Manuel, DTCC Director, Settlement Product Management at jmanuel@dtcc.com or (212) 855-5921. 17
Appendix A Key Changes for Stage 3 Participants may see a significant increase in RAD eligible receives when DTCC lowers its default limits to zero. DTCC strongly recommends that Participants consider automating their matching process internally with DTCC s RAD in advance of this implementation. This appendix contains extracts from existing file specifications and highlights the changes DTCC will make to these formats to facilitate each of the Stage 3 changes previously outlined in this document. Participants are advised to verify that each of the current filler spaces being modified by DTCC as part of this initiative do not drive any internal programming as these fields will be repurposed as outlined below. To incorporate the Intended Delivery Date and Settlement Date fields into RAD output, DTCC will repurpose the existing filler spaces starting below. Link to the existing RAD output file specification: http://www.dtcc.com/products/documentation/asset/ccf/settlement/20_16_mqradoutput.pdf CURRENT STATE: Filler 126 9 (was: Share-Qty) Valuable space Filler 135 2 Value Spaces FUTURE STATE: Intended Delivery Date 126 5 The date the transaction is scheduled for processing. Julian date format Settlement Date 131 5 The intended settlement date of the transaction Julian date format Filler 136 1 DTCC use only reserved for the future use An additional change to RAD output will include a Transaction Type Indicator. This new field will allow 18
Participants to distinguish ID transactions from NDOs or other same day settling transaction types. DTCC will repurpose the existing filler space below for this new indicator. CURRENT STATE OF RAD OUTPUT: Filler 173 1 Value space FUTURE STATE OF RAD OUTPUT: Transaction Type Indicator 173 1 1..Affirmed Institutional. Transaction (ID) 2..FutureDated Deliver Orders,. e.g., NDOs 3..Other (Same Day Transactions, eg. DO, PO Pledge) To incorporate the IMS TID field into the applicable settlement outputs, DTCC will repurpose. the existing filler spaces below for each of the following transaction types. It should be noted that, where possible, the IMS TID will be available in two formats a non-displayable character (referred to below as the RAD Sequence Number that is currently available on RAD output) and hexadecimal (referred to below as the IMS TID) For Deliver Orders: (Available in Version 2 only) Link to existing DO file specifications: http://www.dtcc.com/products/documentation/asset/ccf/settlement/01delorder.pdf CURRENT STATE: Filler 740 55 Value spaces. 19
FUTURE STATE: RAD Sequence Number 740 8 This field is the IMS TID displayed in the nondisplayable character version. This is the current format used in RAD output. IMS TID 748 16 This is the number generated by DTCC which uniquely identifies any transaction. Filler 764 31 Value spaces For Payment Orders: Link to existing PO file specifications: http://www.dtcc.com/products/documentation/asset/ccf/settlement/02payment.pdf DTCC supports three types of payment orders Security Payment Orders (SPO), Premium Payment Orders (PPO) and ACAT Payment Orders. Each payment order type will be modified as follows: SPOs: (Exhibit 5 from the link above) CURRENT STATE: Filler 414 037 Value spaces FUTURE STATE: RAD Sequence Number 414 08 This field is the IMS TID displayed in the. non displayabel character version. This is the current format used in the RAD output. IMS TID 422 16 This is the number generated by DTCC which uniquely identifies any transction. Filler 438 13 Value spaces PPOs: (Exhibit 6 from the link above) 20
CURRENT STATE: Filler 425 26 Value space FUTURE STATE: RAD Sequence Number 425 08 This field is the IMS TID displayed in the non displayable character version. This is the current format used in the RAD output. IMS TID 433 16 This is the number generated by DTCC which uniquely identifies any transction. Filler 449 2 Value space ACAT Payment Orders: (Exhibit 7 from the link above) CURRENT STATE: Filler 449 16 Value spaces Future State: Due to insufficient filler space availability, only the RAD Sequence Number version of the IMS TID will be available through ACAT Payment Order output. RAD Sequence Number/ (IMS TID) 449 08 This field is the IMS TID displayed in the non displayable character version. This is the current format used in the RAD output. Filler 457 08 Reserved for Future use. The reversal command allowing Participants to reverse a receive that may have been approved in error prior to the beginning of night cycle processing will not be supported through automated input, but the results of the reversal will be made available through RAD output. When the receiver approves a transaction in RAD, the approval is communicated through the RAD Action Code field with an A. If an approval of an NDO receive is reversed, the RAD Action Code will be changed from 21
an A (approved) to a W indicating that the transaction is now awaiting approval or cancellation. Please note that the RAD Action Code E is a change being made for Stage 4 of this initiative and will be explained further in Appendix B. RAD ACTION CODE 172 1 Action Code Values: - W = Waiting for approval or cancellation - A = Approved - R = Cancelled by Receiver - D = Cancelled by Deliverer - E = Exempted by Receiver Receivers will have the ability to cancel pending transactions through proprietary MQ and ISO messaging as well as manually through the Settlement Web. No changes to input or output file formats are required to accommodate this new functionality, i.e., automated receiver pend cancels will be submitted using the same Proprietary MQ or ISO formats used by deliverers and output will be available through existing formats. Participants are reminded that, with this implementation, input processing windows will be extended and output will be made available earlier in the settlement cycle. Participants are advised to begin scoping necessary coding changes to accommodate the new timing of NDO and applicable ID transaction output. 22
Appendix B Key Changes for Stage 4 With this implementation, receiver approval of all ID deliveries will be required by DTCC. This appendix contains extracts from existing file specifications and highlights the changes DTCC will make to these formats to facilitate each of the Stage 4 changes previously outlined in this document. Similar to Stage 3 changes, Participants are advised to verify that each of the current filler spaces being modified by DTCC as part of this initiative do not drive any programming as these fields will be repurposed as outlined below. Changes to Proprietary Input ID receivers will provide automated updates for their ID receives through RAD. To ensure RAD capabilities for ID receivers mirror that of ANE functionality provided to ID deliverers, DTCC will create a new version (Version 2) of the RAD input file specifications which will include the following modifications. Version 2 is an optional format but must be used by Participants if they want to use the new functionality. CURRENT STATE OF RAD INPUT: Position Length Format Field Name Field Description 55 1 Character RAD Request Code The request codes have the following values: A approval by Receiver C cancelled by Receiver D cancelled by Deliverer FUTURE STATE OF RAD INPUT VERSION 2 Using the new RAD request codes, receivers will be allowed to submit individual exemptions by using the RAD request code E. Participants submitting global commands will be allowed to define the parameters of their submission and provide a global approval by indicating F or a global exemption using G. Position Length Format Field Name Field Description 55 1 Character RAD Request Code The request codes have the following values: A approval by Receiver C cancelled by Receiver D cancelled by Deliverer E exempted by Deliverer F Global Approval by Receiver G Global Exemption by Receiver Version 2 will also include a new field for the ID Control Number. The addition of this field will allow ID receivers to match an ID transaction using the Omgeo control number. The new field, along with additional filler 23
space, will be added to the end of the existing RAD input file specification. Position Length Format Field Name Field Description 97-105 9 Character ID Control. Number Represents the Omgeo Control Number 106-205 100 Character Filler Reserved for Future Use Changes to ISO Input A new ISO command, RXMP, will be created for MT530 messages to allow ISO users to submit exemptions for their ID receives. The RXMP command will be available through the command indicator field below. Changes to Proprietary Output Creating the new exemption command for RAD input necessitates the creation of a new exemption status for RAD output. To accomplish this, DTCC will modify the RAD Action Code field within the existing RAD output file specifications to include the new exempted status E. CURRENT STATE OF RAD OUTPUT RAD ACTION CODE 172 1 Action Code Values: - W = Waiting for approval or cancellation - A = Approved - R = Cancelled by Receiver - D = Cancelled by Deliverer 24
FUTURE STATE OF RAD OUTPUT RAD ACTION CODE 172 1 Action Code Values: - W = Waiting for approval or cancellation - A = Approved - R = Cancelled by Receiver - D = Cancelled by Deliverer - E = Exempted by Receiver Changes to ISO Output A new status code reflecting the new receiver exemption command, RXMP, outlined above, will be created and made available in all MT548 ISO output messages. Participants are reminded that, with this implementation, input processing windows will be extended and output will be made available earlier in the settlement cycle. Participants are advised to begin scoping necessary coding changes to accommodate the new timing of their ID transaction output. 25
Appendix C Settlement Matching Website The website below was created to provide Participants with a centralized location for Settlement Matching information. DTCC will leverage this website throughout this initiative to communicate additional materials well in advance of each implementation stage. DTCC has made the file specifications containing the changes outlined in this document available through the Technical Specs section of the site. www.dtcc.com/settlement_matching 26
Appendix D Settlement Matching Transaction Matrix Transaction Type Input Output Current State Settlement Matching Current State Settlement Matching Same Day Settling Value Transactions, e.g., Day DOs and POs Receiver status updates are processed in RAD between approximately 3:00 A.M. through the end of the current business date No change to processing windows New Functionality: Receiver Pend Cancels will be allowed Real-time messaging available No Changes Future Dated Night Deliver Orders Receiver status updates are processed through RAD beginning at 9:00 P.M. on S-1 (automated users) and 3:00 A.M. (manual users) and continue through to the end of the current intended delivery date Receiver status updates will be accepted as early as noon of S-1 New Functionality: Receiver Pend Cancels will be allowed Approval reversals prior to the start of the night cycle will be available for manual users Real-time messaging available Changes to proprietary MQ: RAD Output: Three new fields will be added - Intended delivery date, Settlement Date, and the Transaction Type Indicator Settlement Output: Will include the RAD Sequence Number (IMS TID) Timing of Output: Available as early as noon of S-1 or option to delay until 4:00 P.M. on S-1 ID Deliverers Real-time deliverer updates are available to automated and manual users through the ANE system No Change ANE output reflecting ID deliverer updates does not exist Output reflecting ID deliverer updates will be made available through RAD All NDO changes mentioned above will apply ID Receivers Receiver status updates are not applicable* Receiver transaction status updates will be managed through RAD New Functionality: ID Receiver Authorization Profile Receiver exemptions Global transaction updates Receiver Pend Cancels will be allowed Not applicable Output reflecting ID receiver updates will be made available through RAD In addition to all NDO changes above, RAD output will be enhanced to include an exemption transaction status indicator *This chart does not reflect ID input or output changes for Participant that elect to use the RAD ID Trades profile 27