OBLIGATION WAREHOUSE USER GUIDE VERSION 7.3 FEBRUARY 18, 2021 © 2021 DTCC. All rights reserved. DTCC, DTCC (Stylized), ADVANCING FINANCIAL MARKETS. TOGETHER, and the Interlocker graphic are registered and unregistered trademarks of The Depository Trust & Clearing Corporation. The services described herein are provided under the “DTCC” brand name by certain affiliates of The Depository Trust & Clearing Corporation (“DTCC”). DTCC itself does not provide such services. Each of these affiliates is a separate legal entity, subject to the laws and regulations of the particular country or countries in which such entity operates. Please see www.dtcc.com for more information on DTCC, its affiliates and the services they offer. Doc Info: February 18, 2021 Publication Code: OW137 Service: Obligation Warehouse Title: Obligation Warehouse User Guide TABLE OF CONTENTS 1. ABOUT THIS USER GUIDE 8 1.1 Revision History 8 2. COMMON CODES AND ACRONYMS 10 3. GENERAL INFORMATION 12 3.1 Scope of the Obligation Warehouse System 12 3.2 Basic Background 12 3.2.1 About the Depository Trust and Clearing Corporation (DTCC) 13 3.2.2 NSCC Guaranteed Services 13 3.2.3 NSCC Non-Guaranteed Services 13 3.2.4 DTC Settlement 13 3.3 Contact Us 14 3.4 Input Features 14 3.4.1 Post-Trade Processing of Transactions 15 3.4.1.1 Trade Capture 15 3.4.2 Clearance 15 3.4.3 ACATS 16 3.4.4 Obligation Warehouse 16 3.4.5 DTC Settlement: IMS, NYW, ESS 17 3.4.6 Settlement Away From DTC 17 3.5 Output Features 18 3.5.1 MQ Messaging 18 3.5.2 File Output 18 3.5.3 Obligation Warehouse Web 18 4. SYSTEM OPERATIONS 19 4.1 Hours of Operations 19 4.1.1 Start of Day (SOD) 19 4.1.2 During a Business Day 19 4.1.3 Close of Business 19 4.2 Holiday Processing 20 4.2.1 NSCC Holiday, Where Banks are Open 20 4.2.2 Bank Holiday, Where NSCC is Open 21 4.2.3 Federal Holidays Where Both NSCC and Banks are Closed 21 4.3 System Set Up 22 4.3.1 Set Up for Message Queue (MQ) Messaging 22 4.3.1.1 Communication Set Up 22 4.3.2 Obligation Warehouse Web 22 4.3.2.1 Obligation Warehouse Web for Access Coordinators 22 4.3.2.2 Obligation Warehouse Web Access for Users 22 4.3.2.3 Obligation Warehouse Web Access for Account Level Pair Offs 23 4.4 Extension Guidelines 23 5. ELIGIBILITY FOR OBLIGATION WAREHOUSE 24 5.1 NSCC Member Firms 24 5.2 Using Obligation Warehouse Web 24 5.2.1 Access Coordinators 24 5.2.2 Obligation Warehouse Web Users 24 5.3 Security Eligibility 24 5.3.1 CUSIP Requirements 25 5.3.1.1 Sub-Issue Type List 25 5.4 Types of Transactions 28 5.4.1 Ex-Clearing 28 5.4.2 Failed Obligations 28 5.4.3 Comparison Only Obligations 28 6. APPLICATION INPUT AND OUTPUT 29 6.1 Input Sources 29 6.1.1 Universal Trade Capture (UTC) 29 6.1.2 CMU RTTM 29 6.1.3 ACATS 30 6.1.3.1 Non-CNS ACATS Receive and Deliver Instructions 30 6.1.3.2 ACATS Exited From the New Settlement Process 30 6.1.3.3 ACATS Failed in the New Settlement Process 30 6.1.4 NSCC Balance Orders 31 6.1.5 CNS Exits 32 6.1.6 Input Methodology 32 6.1.6.1 Ex-Clearing 32 6.1.6.2 Fails 32 6.1.6.3 Comparison Only Submissions 32 6.2 Output Source 33 6.2.1 MQ Messages 33 6.2.2 AutoRoute Files 33 6.2.2.1 Intraday and End of Day Position Files 33 6.2.2.2 Intraday and End of Day Position File Layouts 33 6.2.2.3 Cash Adjustments for Mandatory Reorg. File 34 6.2.3 OW Pair Off Activity MRO File 34 6.2.4 Obligation Warehouse Web 34 7. PROCESS RULES 35 7.1 Submitting Obligations 35 7.1.1 Mandatory Fields for Bilateral Submissions 35 7.1.2 Timing of Submissions for Matching 36 7.1.3 Retaining Uncompared Submissions 36 7.2 Uncompared Status (UNC) 36 7.2.1 Available Actions for Uncompared Submissions 36 7.2.2 Automated Actions Taken by OW on Uncompared Submissions 37 7.3 Don’t Know (DK) Actions 37 7.3.1 DK Purge Rules 37 7.3.2 DK of Comparison (DKUC) Requests 38 7.3.3 DK of Cancel (DKCN) Requests 38 7.3.4 DK of Delivery (DKDL) Requests 39 7.3.5 DK of Reclaim (DKRC) Requests 40 7.4 Cancel Status (CANC) 41 7.5 Marked for Delete Status (MKDL) 41 7.6 Open Status 41 7.7 Open, Pending Acceptance (OPPA) 41 7.7.1 Automated Actions Taken by OW on Obligations in Pending Statuses 42 7.8 Pending Cancel (PCAN) 42 7.9 Pending Cancel, Pending Acceptance (PCPA) 42 7.10 Closed Status (CLSD) 43 7.11 Reclaim, Pending Acceptance (RCPA) 43 8. STATUS AND RELATED ACTIONS 44 8.1 Obligation Status: Obligation Warehouse Web, MQ Messages, File Output 48 9. AUTOMATED FUNCTIONS 51 9.1 CNS Eligibility Check 51 9.2 Mandatory Reorganization Events 51 9.2.1 Mandatory Reorg Events Applied to ACATS Transactions in the OW 52 9.2.2 Examples of Mandatory Reorg. Events in the Obligation Warehouse system 52 9.2.3 Other Corporate Action Events 54 9.3 RECAPS 55 9.4 Participant Swings 56 9.5 Administrative Action 56 9.6 Using Auto DOs 56 9.7 Pair Offs 57 9.7.1 Benefits of Pair Off Process 57 9.7.2 Pair Off Requirements 57 9.7.3 Pair Off Time of Execution 57 9.7.4 Pair Off Exclusions 57 9.7.5 Pair Off Rules 57 9.7.6 Pair Off Methodology 58 9.7.7 Pair Off Scenarios 58 9.7.7.1 Pair Off Scenario When Criteria Match Exactly for Quantity, Settlement Date and Final Money (Perfect) 58 9.7.7.2 Pair Off Scenario When Obligation Underlying Security is Classified as a Municipal 59 9.7.7.3 One-to-Many Pair Off Scenario 59 9.7.7.4 Pair Off Scenario When Remainder Balances are Used in Subsequent (Future) Pair Offs 60 9.7.7.5 Using the OW Pair Off Indicator 61 9.7.7.6 Managing the Pair Off Indicator at the Obligation Level 62 9.7.7.7 Managing by Using the Account Level Pair Off Indicator 62 10. OBLIGATION WAREHOUSE PRODUCTION SUPPORT CONTACTS 64 11. USER TESTING 65 11.1 Obligation Warehouse Web 65 11.2 MQ Messaging 65 12. CNS ELIGIBILITY FOR OPERATIONS PERSONNEL 66 12.1 Managing What is Sent to CNS 66 12.2 Precautions for CNS Eligibility Check 67 12.3 Settlement—Balancing for Closed Sent to CNS 67 12.4 Follow-Up for an Obligation Closed –Sent to CNS in Error 68 12.4.1 Requesting Reversals of Closed Obligations Set to Settle CNS 68 12.5 Research for Obligations Closed—Sent to CNS 69 13. RECAPS FOR OPERATIONS PERSONNEL 70 13.1 OW Comparison and Trade Resolution Procedures 71 13.2 RECAPS Calendar Plan 72 13.3 Managing What is Included in RECAPS 72 13.4 Precautions Related to RECAPS 73 13.5 Settlement–Balancing of RECAPS 74 13.5.1 Before the RECAPS Cycle 74 13.5.2 After the RECAPS Cycle 74 13.6 Follow-Up for an Obligation Included in RECAPS in Error 74 13.7 Research for Obligations in RECAPS 75 14. REORGS FOR OPERATIONS PERSONNEL 77 14.1 REORG Transformation in Obligation Warehouse 77 14.2 REORG Information Updates 78 14.3 Precautions for REORG in the Obligation Warehouse system 78 14.4 Settlement and REORGs—Reconciliation of REORG 79 14.5 Follow-Up of Obligation Included in REORG in Error 79 14.6 Research for Obligations Transformed by REORG 80 15. OBLIGATION STATUS AND EVENT MAP 81 16. IMPLEMENTING OBLIGATION WAREHOUSE 91 17. USING THE OBLIGATION WAREHOUSE WEB 92 17.1 Registering to Using the Obligation Warehouse Web 93 17.1.1 Becoming an Access Coordinator for Your Firm 93 17.1.2 Adding Roles to a User Profile 94 17.1.3 Resetting a Password 94 17.2 Home Page 96 17.3 Obligation Entry Page 97 17.4 Statuses of Obligations 101 17.5 Obligation Search Engine 104 17.6 Obligation Search Results 108 17.7 Available Actions for Obligations on Obligation Warehouse 110 17.8 Comparisons–Bilateral Advisory Split View 112 17.9 Settlements—Bilateral Advisory Split View 113 17.10 Exception Stats Comparisons 115 17.11 Exception Stats Settlement 118 17.12 Rejects 121 17.13 Actions—View 121 17.14 Actions—Affirm 124 17.14.1 Affirm of Comparison Request 124 17.14.2 OPEN Obligation Status 128 17.15 Actions—Modify 128 17.16 Actions—DK of Comparison Request 130 17.17 Actions—UnDK 136 17.18 Actions—Cancel 138 17.18.1 Cancel of an Uncompared Obligation 139 17.18.2 Cancel of a Compared (OPEN) Obligation 142 17.19 Actions—Un-Cancel 145 17.19.1 Un-Cancel of an Uncompared Obligation in a Cancel Status 145 17.19.2 Un-Cancel of Compared (OPEN) Obligation (a.k.a. Cancel of a Cancel Request) 146 17.20 Actions—Bilateral Agreement of Delivery Made 148 17.20.1 Delivery Notification Request 149 17.20.2 Acceptance of Delivery Notification 151 17.20.3 DK of Delivery Notification 154 17.20.4 Cancel of Delivery Notification Request 157 17.21 Actions—Reclaim Notification Request 159 17.21.1 Reclaim Notification Request 160 17.21.2 DK of Reclaim Notification Request 164 17.22 Actions--Exclusion Indicators 168 17.22.1 Exclude from CNS Eligibility Check 168 17.22.2 Remove CNS Withhold 170 17.22.3 Exclude from Mandatory Reorganization in the Obligation Warehouse system 171 17.22.4 Include for REORG 172 17.22.5 Exclude from RECAPS 173 17.22.6 Include for RECAPS 176 17.22.7 Include for Pair Offs 177 17.23 Obligation Warehouse Web Report Center 185 17.24 Account Level Pair Off Function 189 17.25 OW Participant Contact List 194 17.26 Obligation Warehouse Web Help 196 Obligation Warehouse User Guide 1. ABOUT THIS USER GUIDE This Obligation Warehouse (OW) user guide contains general knowledge about using the Obligation Warehouse (OW) the interfaces to other NSCC and DTC applications and to the outside parties, including participants and regulators. This guide explains how information flows from trade capture to clearance and then through settlement systems, such as CNS exits, NSCC Balance Orders and non-CNS ACATS receive and deliver instructions. The Obligation Warehouse (OW) service allows for transparency in the market place beyond the typical CNS transaction entering through the listed exchange. OW creates a database for non-CNS obligations to be recorded or confirmed and then held until settlement. Additionally, OW gives the industry a centralized fail file to be used by DTCC and the regulators to understand the number and types of fails occurring in the marketplace. This guide includes the pair off feature and explains the communication linkage between DTC Settlement and OW for obligations automatically sent for settlement completion. You can also review information about the process flow and features for equity clearing and the Obligation Warehouse service. Learn more about general descriptions of businesses processes and information flow in the Obligation Warehouse system. The guide assumes that you have prior securities industry experience and a basic knowledge of Purchases and Sales (P&S) and settlement processing. 1.1 Revision History The following table shows the revision history for this document: Date Version Author Description 8/27/2012 1.0 Janice First Edition DiTore 9/20/2012 1.1 Janice See fields 541-551 in the OW Position MRO - Intraday and End of Day file DiTore available from the DTCC Learning Center. 8/13/2013 2.0 Janice l ACATS DiTore l For MRO file layouts, see the OW Record Layouts and Testing section from the DTCC Learning Center. l Other Corporate Action Events l Pair Offs l Obligation Warehouse (OW) Best Practice available in the DTCC Learning Center. 9/3/2013 1.0 Janice AutoRoute Filesfor the Position MRO layout and field definition change for DiTore XPOF (exclude from pair off) 8/26/2014 3.0 Janice l Incorporating the Pair Off update into section Output Source and Pair DiTore Offs l Adding IMSC, IMSD, IMSR for Auto DO obligation sent back to Obligation Warehouse by IMS About This User Guide 8 Obligation Warehouse User Guide Date Version Author Description 2/12/2016 4.0 Janice Edits to section: DiTore l Obligation Warehouse Production Support Contacts l Common Codes and Acronyms l 18.2.3 - Resetting a password l Implementing Obligation Warehouse 11/11/2016 5.0 Janice l Edits to Submitting Obligations to add clarity to comparison submission DiTore best practices. l Edits to Section 18.5, 18.11-12, 18.19, 18.21 6/23/2017 6.0 Pawel Edits to CUSIP Requirements for new foreign security definition. Pieczara Additional edits to sections: l Mandatory Reorganization EventsMandatory Reorganization Events l Examples of Mandatory Reorg. Events in the Obligation Warehouse system l Other Corporate Action Events l REORGs for Operations Personnel l Participant Swings l REORG Information Updates l Managing What is Sent to CNS 8/10/2018 7.0 Pawel l Amended the CNS Flip Rules. See Managing What is Sent to CNS. Pieczara l Removed the Fee Guide section. See the Obligation Warehouse (OW) Fee Guide available in the OW User Guide section of the DTCC Learning Center. l Removed the Best Practices section. See the Obligation Warehouse (OW) Best Practices available in the OW User Guide section of the DTCC Learning Center. l Removed the Intraday and End of Day Position MRO record layout. See the OW MRO File Details and Sample Report section available in the OW Record Layouts section of the DTCC Learning Center. l Removed the OW Pair Off Activity MRO record layout. See the OW MRO File Details and Sample Report section available in the OW Record Layouts section of the DTCC Learning Center. l Removed the Cash Adjustments for Mandatory Reorg record layout. See the OW MRO File Details and Sample Report section available in the OW Record Layouts section of the DTCC Learning Center. 7/2/2019 7.1 Pawel Updated Managing What is Sent to CNS. Pieczara 5/5/2020 7.2 Pawel l Contact Us Pieczara l Extension Guidelines 2/18/2021 7.3 Pawel Improved the description in the ACATS section. Pieczara About This User Guide 9 Obligation Warehouse User Guide 2. COMMON CODES AND ACRONYMS The following table shows the common codes and acronyms used by Obligation Warehouse (OW): Code Definition ACAT ACATS receive/deliver instructions ACPT Accept Delivery through Obligation Warehouse Web ACRC Accept Reclaim through Obligation Warehouse Web AFFM Affirm of Uncompared obligation through Obligation Warehouse Web CADM Closed by Administrative Action CANC Uncompared Cancel status CCAN Closed due to a Participant Cancel submission CCRQ Cancel of a Cancel Request CLSD Closed status CMPE Obligation compared with all elements matching exactly CNDL Cancel of a Delivery notification by the submitter CNMT Request a Cancel of a Matched obligation CNRC Cancel a Reclaim request for bilateral acceptance CNSE CNS Exits CNUC Cancel of Uncompared obligation DCAT ACATS with Auto DO (Delivery Order) instructions DEAD Deleted Uncompared obligation due to administrative action DEDK Deleted comparison request due to DK DEPS Deleted due to Participant Swing DKCN DK of a Cancel Request on a matched obligation DKDL DK of Delivery notification request for bilateral acceptance DKPA Comparison DK, pending acceptance of delivery status DKRC DK of Reclaim notification request for bilateral acceptance DKUC DK of Uncompared obligation DKUN DK of Uncompared status DLVF Full Delivery completed DLVP Partial Delivery completed ECAT Obligation exited from the ACATS settlement process FCAT Obligation failed in the ACATS settlement process INST Instruct of Comparison Request ICNS Remove the Withhold from CNS (available to submitter of withhold) IRCP Include obligations for RECAPS processing IREO Include for Mandatory Reorganizations IPOF Include for Pair off IMSC IMS permanent cancel IMSD IMS permanent drop Common Codes and Acronyms 10 Obligation Warehouse User Guide Code Definition IMSR IMS permanent reject MKDL Obligation comparison request marked for delete status MODP Modification of matching fields MODX Modification of non-matching fields NSCC NSCC Balance Orders OPEN Compared obligation status OPPA Obligation is compared, and pending acceptance of delivery notification status PART Participant submission PCAN Obligation is compared, pending cancellation agreement by the contra status PCPA Obligation is compared, pending agreement by the contra, and pending bilateral acceptance of a delivery notification request status PMSG Participant Message POFF Pair off Full POFP Pair off Partial RCLF Full Reclaim of delivery completed RCPA Reclaim of closed obligation, pending acceptance of a delivery notification request status RECP RECAPS process REOR Mandatory Corporate Actions applied to obligation SCNS Sent to CNS SIMS Sent to IMS SUBM Internal Submission SWNG Participant Swing UNCP Uncompared obligation status UNDK Remove DK of Uncompared status UNPA Uncompared obligation and pending acceptance of delivery notification by contra XCNS Exclude from CNS processing XRCP Exclude from RECAPS processing XREO Exclude from Mandatory Reorganizations XPOF Exclude from Pair off Common Codes and Acronyms 11 Obligation Warehouse User Guide 3. GENERAL INFORMATION The Obligation Warehouse (OW) service is a product of the National Securities Clearing Corporation (NSCC) which is a member owned subsidiary of the Depository Trust and Clearing Corporation (DTCC). The services, provided for trade capture and clearing, create a common repository for the transactions from the marketplaces, including the listed exchanges and alternative trading platforms collectively. It then consolidates the transactions to reduce the burden of trade-for-trade settlement for each transaction. Additionally, NSCC provides a guarantee for specific transactions that are netted through Balance Orders or the CNS accounting service and settled at NSCC, DTC, or at another depository. The National Securities Clearing Corporation (NSCC) has upgraded and expanded the technology for the Reconfirmation and Pricing Service (RECAPS) and introduced the Obligation Warehouse (OW). The Securities and Exchange Commission (SEC) approved the NSCC Rule filing and Financial Regulatory Authority (FINRA) provided the interpretative guidance to state that the OW is a mandated service for NSCC broker dealer full service members. 3.1 Scope of the Obligation Warehouse System Obligation Warehouse provides an automated service for the matching of obligations submitted by members for U.S. securities classified as equities, corporates, or unit investment trusts. The centralized service supports bilateral matching of ex-clearing and failed obligations in real-time. Obligations held in the central repository are stored and maintained until closure or cancellation. Daily the OW checks the OPEN status obligations for CNS eligibility. Multiple times throughout the day OW transforms obligations for any of the applicable mandatory corporate action events. Additionally, the failed non-CNS obligations being stored in the Obligation Warehouse system are marked to the market price provided a new settlement date and netted during the periodic RECAPS cycle. 3.2 Basic Background Trades originate in the broker dealer community and are transacted at either a registered exchange, such as: BATS, CHX, NASDAQ, NYSE or NSX, through a qualified special representative (QSR) using the CMU RTTM or ACT comparison systems or directly between two parties. The transactions are then sent to one of NSCC trade capture systems: l If initiated on registered cash equities exchange, it is reported in Universal Trade Capture (UTC). l If matched in ACT, it is reported in UTC. l If submitted and matched through the Corporate Municipal or Unit Investment Trust Real-time Trade Matching engine (CMU RTTM), the reporting is available in RTTM. The one transaction type that is not a result of submitting through a trade capture system is the ex-clearing trade where two parties agree to terms and exchange confirmations. These ex-clearing trades can be submitted to OW and the match is recognized as an electronic form of the confirmation required by FINRA. After the transaction information is at NSCC the data moves from Trade Capture to Clearance. For the trades that entered through UTC or RTTM a sorting process takes place to recognize the underlying security and contra-parties to the trade as either CNS or Non-CNS eligible. Most transactions flow into the CNS accounting system. The securities are then netted and settled through NSCC. Those securities that are not CNS eligible are accumulated into NSCC Balance Orders, netting where possible. NSCC Balance Orders are settled at the DTC depository using delivery orders (DO’s). General Information 12 Obligation Warehouse User Guide If an obligation has not settled on settlement date then it is considered a fail. Fails are maintained in the OW and periodically marked to market during a reconfirmation and pricing service, which is known as the RECAPS process. 3.2.1 About the Depository Trust and Clearing Corporation (DTCC) DTCC is the umbrella organization comprised of several companies including: l Depository Trust Company (DTC) which is a banking company that settles and maintains securities for most U.S. entities. l Fixed Income Clearing Corporation (FICC) operates under two entities the Government Securities Clearing Corporation (GSCC) and Mortgage Backed Clearing Corporation (MBSD). Each entity compares and provides a central counterparty to clear and settle their respective transactions. l National Securities Clearing Corporation (NSCC) performs trade capture, clearance, and account transfer for transactions from the major marketplaces acting as a central counter-party for most transactions and aggregating non-guaranteed items for ease of settlement. l Some of the other firms where DTCC have interests are: DTCC Solutions and Global Trade Repository. 3.2.2 NSCC Guaranteed Services NSCC acts as the central counterparty for virtually all the broker-to-broker trading of cash equities, listed corporates, municipals and unit investment trusts in the US marketplaces. As the central counterparty for the industry in the marketplace, CNS is the core netting, allotting and fail control engine. Within CNS each security is netted to one position per member with NSCC as the central counterparty (novation). NSCC provides the final settlement instructions to its customers each day, the payment and movement of security ownership occurs at DTC. 3.2.3 NSCC Non-Guaranteed Services Transactions that are ineligible for CNS are referenced as non-CNS obligations. Settlement for non-CNS obligations occur at the direction of the members, usually through DTC. They can occur at other depositories, such as the Canadian Depository (CDS). 3.2.4 DTC Settlement In addition to NSCC’s transactions, DTC settles institutional trades, money market instruments and other financial obligations. As DTCC’s depository, DTC eliminates the movement of securities by providing book- entry deliveries, which transfers ownership of securities electronically. General Information 13 Obligation Warehouse User Guide 3.3 Contact Us Use the following NSCC contacts for information about Obligation Warehouse. You can also contact your DTCC Relationship Manager or obtain general assistance by visiting the DTCC Client Center. For... Contact... General questions and product NSCC Support by email at [email protected]. support Setup and testing NSCC Integration by email at [email protected]. Issues with logging on to the DTCC Client Support. Call the following number, and then follow the prompt system for product support. o For US and Canada, call 1 888–382–2721. o For the UK, Europe, and Asia, call +1 212–855–8099. 3.4 Input Features The following figure shows the basic input features: General Information 14 Obligation Warehouse User Guide 3.4.1 Post-Trade Processing of Transactions l Trade Capture l Clearance l ACATS l Obligation Warehouse l DTC Settlement: IMS, NYW, ESS l Settlement Away From DTC 3.4.1.1 Trade Capture Every broker-to-broker trade whether direct, on an exchange, through an alternative trading platform, ECN, or Over the Counter (OTC) must have a confirmation according to Uniform Practice Code (FINRA Rule 11100). Transactions accepted from the registered exchanges and Qualified Special Representative (QSR) submissions into NSCC through the Universal Trade Capture (UTC) appear on contract sheets. The same is true of CMU RTTM transactions, where comparisons are recorded on contract sheets. 3.4.2 Clearance From the Trade Capture function, the data enters NSCC Clearance. Clearance begins a sorting process into CNS eligible transactions available for the NSCC guarantee and non-CNS transactions. The transactions eligible for continuous net settlement process enter the CNS and settle at NSCC. The non- CNS transactions go into the NSCC Balance Order process and further delineated into balance order netting versus trade for trade obligations. These NSCC balance orders are sent to the Obligation Warehouse (OW). The information about the obligation that uniquely identifies it is the OW ID/OW control number. When the NSCC balance orders are loaded to OW as matched obligations, only the settlement component needs to be completed. In the case of CNS exits, the underlying security is no longer eligible for the CNS service so it is removed (exited) and placed in the non-guaranteed Obligation Warehouse as a matched obligation. Next, the settlement component must be completed. General Information 15 Obligation Warehouse User Guide 3.4.3 ACATS The Automated Customer Account Transfer Service (ACATS) is the NSCC central processing system for the timely transfer of customer account assets between firms. Transfers are divided into CNS and non-CNS processing. The non-CNS items are sent to OW as matched obligations. Ensure that the OW ID/OW control number is added to the DTC delivery order field. When the OW ID/OW Control Number field in the DTC Settlement system is populated, the Made delivery message is communicated directly to the Obligation Warehouse system to close the obligation. If an obligation settled through the DTC Settlement system without the OW Control Number populated on the settlement entry, a bilateral agreement is needed to close the obligation in Obligation Warehouse. Submit a Delivery Notification Request for bilateral agreement to close the obligation. If the obligation is settled outside of the DTC Settlement system, the two parties to the obligation can bilaterally agree on the settlement completion and close it. 3.4.4 Obligation Warehouse From the time the obligation, regardless of its original source, enters and matches in the Obligation Warehouse system until when it closes the underlying security can change attributes. The security can become CNS eligible or a mandatory corporate action event could occur. The OW monitors and adjusts the obligations accordingly looking at the matched obligations, closing the old and calculating the new values and reporting the necessary cash adjustments. Members who conduct business outside the common trade flow from a registered exchange, alternative trading system, electronic communications network, or through a Clearing Corp system, such as CMU RTTM. Otherwise, the confirmation process can be fulfilled using the matching facility in the Obligation Warehouse Web. OW comparison is achieved when two parties enter like details into OW through messaging or the web portal and all matching fields agree or meet the tolerances. The ex-clearing comparisons are included in the database with all other OW data. Each day the entire OW Repository is reviewed to determine if any of the open obligations are eligible for CNS. If yes, the obligation is closed and moved into CNS for settlement. General Information 16 Obligation Warehouse User Guide 3.4.5 DTC Settlement: IMS, NYW, ESS Most non-CNS obligations in the Obligation Warehouse system are settled through the DTC Settlement systems using Delivery Orders (DOs), New York Window (NYW), or Envelope Settlement System (ESS). Members submit DTC DOs or entries to NYW or ESS and include the OW control number on the record. When the settlement is Made, the completion is communicated to OW to close the obligation. This methodology is used for partials, full deliveries, and reclaims made within two days of the completed delivery. 3.4.6 Settlement Away From DTC When members elect to complete deliveries for non-CNS obligations at a depository other than DTC or settle direct with each other; obligations in the Obligation Warehouse system are closed by bilateral agreement. General Information 17 Obligation Warehouse User Guide 3.5 Output Features Obligation Warehouse uses three communication methods: MQ messaging, machine readable output (MRO) files, and a web portal known as Obligation Warehouse Web. 3.5.1 MQ Messaging For real-time input and output, the OW communicates with ISO 15022 compliant MQ messages. The MT 515 input/modification messages are submitted by members. OW returns MT 509 acknowledgments as well as MT 518 responses. OW generates reject messages using MT 598 and system notifications through MT 599. 3.5.2 File Output File output is available as machine-readable output (MRO) through NDM or FTP transmission. OW produces files for Intraday Positions, End of day Positions, Reorg. Cash Adjustments (five times daily), and the OW Pair off Activity. 3.5.3 Obligation Warehouse Web The Obligation Warehouse Web gives every Obligation Warehouse eligible member access to real-time information, in addition to input and response capability. Additionally, all output files are parsed into sections and defined as reports readily available in the Obligation Warehouse Web Report Center. These reports are available for up to two years and, upon request, up to another five years. General Information 18 Obligation Warehouse User Guide 4. SYSTEM OPERATIONS This section explains the hours of operations, holiday processing, and system set up requirements. 4.1 Hours of Operations OW hours of operation begin with the start of day, which is approximately 21:00 (9 P.M) Eastern Time the prior evening or upon completion of the end of day processing, if delayed. At the start of the day, the system processing date in the Obligation Warehouse system is advanced to the next business date, all message queue (MQ) messaging and Obligation Warehouse Web submissions are accepted and processed. The Obligation Warehouse Web is available during the hours of operation. If the member uses MQ messaging for communicating with OW, an MT 599 MQ administrative message is automatically generated for both the Good Morning and Good Night messages, to signal the beginning and end of the OW processing day. 4.1.1 Start of Day (SOD) At the start of day (SOD), OW accepts the obligations exited from CNS, apply mandatory corporate actions, and close and rebook any Participant Swing. 4.1.2 During a Business Day Balance orders are added to OW three times daily, after each generation of the Consolidated Trade Summary (CTS). Typical times of issues for the CTS are 22:00 (10 P.M), 1:00 (A.M), and 13:00 (1:00 P.M) Eastern Time. Other times during a business day when mandatory corporate actions are applied include: 10:00 (A.M), 12:30 (P.M); 14:30 (2:30 P.M), and 16:45 (4:45 P.M) Eastern Time. The CNS eligibility check is performed at 17:00 (5:00 P.M) Eastern Time where the securities of obligations in an OPEN status are validated for CNS eligibility and if acceptable, closed and sent to CNS. The OW Pair off process runs immediately after the completion of the CNS eligibility check. Only obligations in an OPEN status where both contras have marked the obligation to include for pair off are considered in this process. Obligations that pair off are either decremented or closed depending on whether it is a partial or full pair off. 4.1.3 Close of Business The close of business begins daily at 18:00 (6:00 P.M) Eastern Time. During the end-of-day (EOD) process the ACATS receive and deliver instructions for SD-1 non-CNS items are entered into OW. As the last process during the EOD, the RECAPS occur on the published predefined dates. System Operations 19 Obligation Warehouse User Guide 4.2 Holiday Processing This section explains the process for holidays. 4.2.1 NSCC Holiday, Where Banks are Open On holidays, such as Good Friday, the broker dealer community is closed for business; however, the Federal Reserve and banks are open. Here is the schedule of what to expect surrounding a holiday like the Good Friday holiday in the Obligation Warehouse (OW) product. OW is unavailable on the holiday and does not recognize the date as a valid settlement date. On the processing day immediately before the holiday, Obligation Warehouse Web and MQ messaging are open for business as usual. In the Good Friday example: l Automated additions of CNS exits, NSCC Balance Orders are made to OW for settlement dates of Monday* and Tuesday. l At 17:00 (5 P.M) Eastern Time, the CNS eligibility check runs to include settlement dates of Monday and prior. l Mandatory Corporate Actions are applied in the OW, effective for Monday’s settlement date***. l DTC Settlement Auto DO’s are created and sent to IMS for process date of Monday**. The following table shows an example for the Good Friday holiday: Obligation Warehouse (OW) One business day prior to the Day of Good Friday Function Description holiday holiday Obligation Warehouse Web access, normal Closed for business input MQ messaging to/from OW normal Closed for business Intraday and EOD MRO files normal NOT PROCESSED CNS Exits auto-load to OW normal S/D Monday NOT PROCESSED ACATS auto-load to OW normal S/D Monday NOT PROCESSED NSCC Balance Orders auto-load to normal S/D Monday* NOT PROCESSED OW Auto DO file created and sent to DTC normal S/D Monday** NOT PROCESSED Settlement CNS Eligibility Check at 5 P.M. normal S/D Monday NOT PROCESSED Eastern Time OW Pair off process normal NOT PROCESSED Mandatory Corporate Actions applied normal S/D Monday*** NOT PROCESSED The following footnotes are because the process date in the OW is still Thursday until approximately 21:00 (9 P.M.) Eastern Time on Thursday, after the start of day advances the processing date to Monday. * Except for the 12:00 P.M Eastern Time CTS obligations that have the settlement date of Thursday. ** Except for the 12:00 (P.M), and 14:30 (2:30 P.M) Eastern Time, feeds to IMS that have the settlement/process date of Thursday. *** Except for the 10:30 (A.M.), 12:30 (P.M), and 14:30 (2:30 P.M) Eastern Time reorg. cycles, which have a settlement date of Thursday. System Operations 20 Obligation Warehouse User Guide 4.2.2 Bank Holiday, Where NSCC is Open Several times throughout the year the broker dealer industry and the banks do not use the same business calendar. For example, Columbus and Veteran’s days the banks are closed for business; however, the broker dealer community is open for business. Here is the schedule of what to expect in the Obligation Warehouse when this scenario occurs On the processing day immediately before the bank holiday, OW is open for business as usual, except it does not send obligations to CNS at 17:00 (5 P.M) Eastern Time. Beginning on the processing day that equals the bank holiday: l Obligation Warehouse Web and MQ messaging are open for business as usual. l Automated additions of CNS exits, NSCC Balance Orders and non-CNS ACATS are not be made to OW. l Automated Delivery Orders (Auto DO’s) are not produced and sent to IMS. l At 17:00 (5 P.M) Eastern Time, the CNS eligibility check runs to include settlement dates of tomorrow and prior. The following table shows an example of bank holidays when NSCC is open for business. Obligation Warehouse (OW) One business day prior to Bank Day of Bank Function Description Holiday Holiday Obligation Warehouse Web access, normal normal input MQ messaging to/from OW normal normal Intraday and EOD MRO files normal normal CNS Exits auto-load to OW normal NOT PROCESSED ACATS auto-load to OW normal NOT PROCESSED NSCC Balance Orders auto-load to OW normal NOT PROCESSED Auto DO file created and sent to DTC normal NOT Settlement PROCESSED CNS Eligibility Check at 5 pm ET NOT PROCESSED normal OW Pair Off process normal normal Mandatory Corporate Actions applied normal normal 4.2.3 Federal Holidays Where Both NSCC and Banks are Closed On a weekday when both banks and NSCC are closed, the OW advances to the next available business day. For example, on the evening prior to Independence Day (July 4), the OW advances from a business processing date of July 3 to the next available business date, July 5 if it falls during the business week. System Operations 21 Obligation Warehouse User Guide 4.3 System Set Up The following section explains how to set up your system. 4.3.1 Set Up for Message Queue (MQ) Messaging Members using MQ messaging as their communication linkage with OW require set up and testing for the MQ channels and messages. Additionally, all messages types should be tested to and from the Obligation Warehouse application. 4.3.1.1 Communication Set Up For members preparing to set up MQ as their primary communication to OW, require that technical preparations are made to define MQ channels and queues. Contact the Service Activation group to obtain the appropriate prework documentation at [email protected]. Additionally, notify Relationship Services to act as the coordinator for the onboarding of MQ messaging for OW. l Define channels and queues for both test and production needs. l Run ping test with Service Activation group l Define MQ subscription to Obligation Warehouse application in test. l Contact UAT group to begin submitting MQ messages in the Obligation Warehouse system Test. l Create a plan with UAT to conduct testing of MQ messages l Define and communicate with Relationship Services the date of production MQ. l Check that production queues and channels are enabled and subscriptions active. l Begin MQ communication to OW in productions. 4.3.2 Obligation Warehouse Web Obligation Warehouse Web uses the Common Runtime Environment (CRE) registration system that allows for a single logon and password to multiple applications. Each member has assigned the Access Coordinators at their respective firm that maintains the user access and resets passwords. For more information, see the Obligation Warehouse Web User Guide available in the OW User Guide section of the DTCC Learning Center. 4.3.2.1 Obligation Warehouse Web for Access Coordinators To enable access to the Obligation Warehouse Web, the access coordinator must add the Obligation Warehouse product for the member to the firm’s profile. If the Obligation Warehouse is not listed in the menu of products, the access coordinator should request access by emailing [email protected]. The addition of the Obligation Warehouse in the list of available products for your firm should occur the same day. After the menu contains the Obligation Warehouse in the list of available products, the access coordinator adds it to the firm’s profile. The access coordinator can then begin granting users their access to the Obligation Warehouse Web. 4.3.2.2 Obligation Warehouse Web Access for Users The access coordinator at your firm sets up access to the Obligation Warehouse Web. Access coordinators grant user either read-only or read and write privileges. After access is granted, sign in to the Obligation Warehouse Web through the DTCC portal at https://portal.dtcc.com/. System Operations 22 Obligation Warehouse User Guide 4.3.2.3 Obligation Warehouse Web Access for Account Level Pair Offs The access coordinator at each firm can assign one or two Obligation Warehouse Web users with the ability to maintain the business administrative function of adding, modifying, and deleting the account level pair off preferences. 4.4 Extension Guidelines If an extension is needed for any input submission, firms should use one of the following methods to obtain support: l Email NSCC Support at [email protected]. l Telephone DTCC Client Support at 1-888-382-2721 and follow the prompt for production support. If DTCC, at its sole discretion, extends a deadline that would significantly impact reporting times, a communication is sent out. System Operations 23 Obligation Warehouse User Guide 5. ELIGIBILITY FOR OBLIGATION WAREHOUSE The following sections explain the eligibility standards for members, security eligibility, and types of transactions. 5.1 NSCC Member Firms Broker dealer members of NSCC that are known as full service (Rule 2) are required to use the mark to market service of OW known as RECAPS. The list of full service members is posted to the DTCC.com website in the NSCC Members Directories. 5.2 Using Obligation Warehouse Web Within the broker dealer NSCC member firms, specific user groups should be activated for access to the Obligation Warehouse Web to monitor and maintain obligations in Obligation Warehouse. Typically, the areas within the firm that use Obligation Warehouse Web are: l Purchases and Sales for comparisons l Corporate Actions for Mandatory Reorganizations l Settlement for cash adjustments and securities settlement reconciliation 5.2.1 Access Coordinators Each NSCC member firm has assigned at least two Access Coordinators that define the products available and register the users to have access to DTCC applications using the DTCC web portal. See also: Common Registration Access Coordinators Guide in Obligation Warehouse Documents. 5.2.2 Obligation Warehouse Web Users Obligation Warehouse Web users can be set up by the Access Coordinators at their firm to be either Read- only or Read/Write, whereby they can enter and respond to notifications within the application. 5.3 Security Eligibility The underlying security of each obligation is validated upon entering the Obligation Warehouse Web system and prior to being introduced to any downstream process or system transformation, such as RECAPS. DTCC uses the internal security master file in conjunction with the vendor-sourced information from Standard and Poors (S and P). Eligibility for Obligation Warehouse 24 Obligation Warehouse User Guide 5.3.1 CUSIP Requirements Any valid U.S. CUSIP/ISIN, recognized by SandP, denominated in U.S. dollars are eligible for OW with the exception of government, mortgage-backed and foreign securities. The foreign security check examines CUSIPs against the following criteria: Category Sub-Category OW Rules CNS-Eligible All Types Admit Foreign-Netting Eligible All Types Reject Non CNS and Non Foreign-Netting Issuer Country of Origin is U.S. Admit Non CNS and Non Foreign-Netting Issuer Country of Origin is Canada Admit Non CNS and Non Foreign-Netting Sub-Issue Type is ADR Admit Non CNS and Non Foreign-Netting Not US and Not Canada and Not ADR Reject User-defined CUSIPs are not acceptable to OW. 5.3.1.1 Sub-Issue Type List The sub-issue type is defined on the DTC security master file for each CUSIP. The following table shows which system should to use for matching a transaction in the corresponding sub-issue type. Sub-Issue Sub-Issue Type Description Comparison Method Type 5 Equity OW 10 Common Stock OW 11 Convertible Common Stock OW 12 Common Stock REIT OW 20 Preferred Stock OW 22 Preferred Stock REIT OW 23 Convertible Preferred Stock OW 24 Tender Rate Preferred Stock OW 30 Limited Partnerships OW–only valid SandP CUSIPs 40 CMO Denom in Units or Undivided OW–DTC settling only Interest 102 Auction Rate Preferred Stock (ARPS) OW 110 American Depositary Receipt (ADR) OW 111 DEPOSITARY SHARE OW 112 Muni Option call right CMU RTTM 117 Exchange Traded Funds N/A 121 Equity 144A Designated Investors OW 125 Sealed Envelopes N/A 126 Custody User CUSIP N/A 130 Real-Estate Investment Trust (REIT) OW 310 Municipal Bond CMU RTTM 311 Municipal Note CMU RTTM 312 Municipal ARN CMU RTTM Eligibility for Obligation Warehouse 25 Obligation Warehouse User Guide Sub-Issue Sub-Issue Type Description Comparison Method Type 313 Municipal VMO CMU RTTM 314 Municipal VRDO CMU RTTM 315 Muni Insurance Customer Receipt CMU RTTM 320 MMI Muni VRDO/CP CMU RTTM 330 MMI Muni CP Mode CMU RTTM 340 Muni Bearer, Callable Zero CMU RTTM 346 Muni Other Tax-Exempt CMU RTTM 450 GNMA N/A (Settles at Fed) 451 GNMA Pass Through N/A (Settles at Fed) 452 GNMA Serial Note N/A (Settles at Fed) 500 Corporate Bond (CB) or Global Corp Bond CMU RTTM (GCB) 502 MMI Bankers= Acceptance Note (BA) CMU RTTM 504 MMI Institutional Certificate of Deposit CMU RTTM 505 Certificated Money Market Instrument CMU RTTM 506 Certificated Money Market–Periodic CMU RTTM Payer 507 Certificates of Deposit CMU RTTM 525 MMI Corporate Commercial Paper CMU RTTM 526 MMI Corporate VDRO/CP CMU RTTM 530 MTN Medium-Term Note CMU RTTM 531 MMI Deposit Note CMU RTTM 532 MMI Medium-Term Bank Note CMU RTTM 533 MMI Medium Term Note CMU RTTM 540 Collateralized Mtge Obligation or Global OW CMO 541 Asset-backed Security (ABS) or Global OW ABS (GABS) 542 Non-CMO/ABS Amortizing Issue CMU RTTM 546 Corporate Other Tax Exempt CMU RTTM 550 MMI Short-Term Bank Note CMU RTTM 551 Z CPN Denom in Initial Principal Amt CMU RTTM 571 Corporate Auction Rate Note CMU RTTM 572 Convertible Corporate Debt CMU RTTM 574 Corporate Short-Term Note CMU RTTM 575 Corporate Debenture CMU RTTM 576 Corporate Variable Rate Demand CMU RTTM Obligation (VRDO) Eligibility for Obligation Warehouse 26 Obligation Warehouse User Guide Sub-Issue Sub-Issue Type Description Comparison Method Type 577 CORPORATE INSURED CUSTODIAL CMU RTTM RECEIPT 578 Tender Rate Note CMU RTTM 579 Zero Coupon Bond CMU RTTM 601 GOVERNMENT SECURITY N/A (Settles at Fed) 602 Government Trust Certificate N/A (Settles at Fed) 603 Junk and Treasury Growth Receipt (JGR) N/A (Settles at Fed) 610 US Treasury Security N/A (Settles at Fed) 611 US Treasury Bill N/A (Settles at Fed) 612 US Treasury Note N/A (Settles at Fed) 613 US Treasury Bond N/A (Settles at Fed) 620 US Government Agency Security N/A (Settles at Fed) 704 Corporate Debt Derivatives CMU RTTM 705 Equity Derivatives OW 706 Muni Derivatives CMU RTTM 708 Muni Amortized Issues CMU RTTM 720 Warrant OW 730 Right OW 760 Mutual Fund OW–Settles at DTC and is not Fund Serv Eligible 761 Closed End Fund OW–Settles at DTC and is not Fund Serv Eligible 762 (IMM) Institutional MMI Mutual Fund N/A Shares 780 EQUITY UNIT OW 781 DEBT UNIT OW 790 UNIT INVESTMENT TRUST (UIT- CMU RTTM NUVEEN ONLY) 795 UNIT INVESTMENT TRUST (UIT) CMU RTTM Eligibility for Obligation Warehouse 27 Obligation Warehouse User Guide 5.4 Types of Transactions The following section explains the types of transactions available. 5.4.1 Ex-Clearing Broker-to-broker transactions that previously were not submitted to the Clearing Corporation either directly or through a marketplace are referred to as ex-clearing. NSCC members enter transactions into OW where the security eligibility meets the criteria for OW and it is matched in real-time and maintained in the repository. An example of maintenance is the daily check of obligations for CNS eligibility. If eligible, the obligations are closed and sent to CNS for settlement. Comparison Requests where the trade date, settlement date, and processing date for OW are the same are rejected by OW. Note OW allows for submission of a blank (Obligation Warehouse Web only) or default (12/31/9999 in MQ) trade date but this practice should not be used unless the trade date is unavailable. If the trade date is known, it should be submitted in the trade date field. 5.4.2 Failed Obligations Obligations that failed to settle must be in the Obligation Warehouse system for the periodic mark to market process known as RECAPS. Obligations that originated on an exchange or other marketplace where NSCC received the transactions into the Universal Trade Capture (UTC) system are automatically included in the Obligation Warehouse system. Best practice as agreed upon by the industry, if the fail was a cash transaction (same day settlement), enter it into OW on the next available business processing day, with the trade date and settlement date populated appropriately. OW does not permit submitting an obligation where the trade date, settlement date and OW processing date are all equal. As of submissions of failed transactions are accepted into OW; whether they were cash, next day or skip day settlements. 5.4.3 Comparison Only Obligations Comparison only trades are unsupported by OW and should be matched in CMU RTTM. Eligibility for Obligation Warehouse 28 Obligation Warehouse User Guide 6. APPLICATION INPUT AND OUTPUT This section explains the application sources. 6.1 Input Sources The following sections provide information about the input sources for the application. 6.1.1 Universal Trade Capture (UTC) The following tables shows the input sources for the Universal Trade Capture application: Input Source Description Trade Capture The Trade Capture and Reporting Service validates and reports equity and Reporting transactions executed in the US equity markets throughout the trading day. Trades are submitted to DTCC (through NSCC) by an exchange or by a Qualified Special Representatives (QSRs). Processing and reporting is performed in real- time, with output distributed an average of approximately 8 seconds after receipt. Universal Trade Capture (UTC) is the primary application for clearance input to DTCC. The project was conceptualized in 2008 by DTCC, with requirements developed through industry discussions. The application was formally implemented on March 25, 2011. Correspondent Correspondent Clearing is a trade capture position movement service that allows Clearing a participant to move a position from an executing broker’s account (special representative) to a different clearing broker’s account (correspondent). Most of Correspondent Clearing input is received in real time as well. OTC The Over-the-Counter (OTC) Comparison service accepts one-sided Comparison transactions from NSCC participants and matches buyers and sellers based upon clearing firm, executing market participant ID, CUSIP or trading symbol, share quantity, price and trade date. This is being considered for a future enhancement. Foreign The Foreign Securities Comparison and Netting (FSCN) service automates the Securities comparison and receipt of locked-in trades and bi-lateral netting of non-U.S. Comparison equity transactions. With the implementation of UTC, any market is now able to and Netting submit foreign netting transactions, upon request. Most UTC trades either proceed to the CNS® application for netting and settlement or become NSCC Balance Orders. 6.1.2 CMU RTTM The Municipal Securities Rule Making Board (MSRB) mandates that all municipal trades must be submitted for automated reporting through the Corporate, Municipal and Unit Investment Trusts Real-Time Trade Matching service (CMU RTTM). The submissions to CMU RTTM are then matched and forwarded to either the CNS or to NSCC Balance Orders. Application Input and Output 29 Obligation Warehouse User Guide 6.1.3 ACATS The Automated Customer Account Transfer Service (ACATS) application provides members with a facility for moving customer assets positions from one bank/broker to another. After submitting a transfer input (TI) record, which is sourced from the transfer initiation form (TIF) that is completed by the account owner, and agreeing to the terms, the ACATS system assigns a control number to the transfer. ACATS then proceed downstream to either CNS, if eligible or another non-CNS system, such as OW staging prior to settlement. In the Obligation Warehouse Web service, the ACATS control number is assigned as the cross-reference (Xref) number. 6.1.3.1 Non-CNS ACATS Receive and Deliver Instructions For the processing of non-CNS ACATS instructions, see the documentation available n the DTCC Learning Center in the CNS ACATS DTC section. Changes affecting OW include the indicators of ECATS and FCATS. This section explains the process for non-CNS ACATS receive and deliver instruction that are ineligible for the ACATS CNS process. When an ACATS transfer has been designated as non-CNS as part of the initial transfer instruction or the security is ineligible for CNS the obligation is loaded to OW two days prior to settlement during the Close of Business processing. The conditions needed for ACATS to have OW eligibility: The ACATS settlement location = 50 with a Settlement Reason Code equal to one of the following: l IPO (Initial Public Offering) l NSET (outside CNS, DTC, Fund/Serv) as defined by ACATS l XSET (outside CNS, DTC, Fund/Serv) as defined by the submitter The obligation is loaded to OW with the X-CNS = yes indicator.) Asset transfers in safekeeping, restricted, Bank ACATS, mutual fund, or limited partnership securities are not permitted in the Obligation Warehouse system. When ACATS load to the Obligation Warehouse system and the delivering contra party uses the Automated Delivery Order (Auto DO) process, OW designates the origin as DCAT. DCAT mean the Auto DO has been sent to DTC Settlement with the OW control number in the appropriate field. By populating the OW control number on the DTC delivery order, Obligation Warehouse is notified when the delivery is made and the obligation can be closed. If an obligation settled through the DTC Settlement system without the OW Control Number populated on the settlement entry, a bilateral agreement is needed to close the obligation in Obligation Warehouse. Submit a Delivery Notification Request for bilateral agreement to close the obligation. ACATS R and D Instructions are automatically loaded to OW as part of the end of day processing. The Obligation Warehouse Web obligation source is either ACAT or DCAT, depending on whether Auto DO is used. If the automated delivery order for the ACATS R and D Instruction is later permanently canceled, dropped, or rejected in the DTC Settlement system, OW is notified and the obligation set back to an OPEN status with maintenance available. 6.1.3.2 ACATS Exited From the New Settlement Process During the CNS night cycle, the ACATS obligations that are ineligible for CNS are exited to OW, identified with the source code of ECATS. ECATS are loaded to OW during the start of day process as an OPEN obligation. 6.1.3.3 ACATS Failed in the New Settlement Process At approximately 15:10 (3:10 P.M.) Eastern Time daily, the ACATS that failed to settle is sent to OW as FCATS. The FCATS is added in real time to OW as an OPEN obligation. Application Input and Output 30 Obligation Warehouse User Guide 6.1.4 NSCC Balance Orders NSCC balance orders are accumulated from UTC and CMU RTTM where they are netted or marked trade for trade in preparation for members to create delivery orders at DTC. NSCC balance order obligations are each assigned a balance order control number for tracking throughout the remainder of the life cycle. Obligations that are extracted and loaded into the Obligation Warehouse service use the NSCC balance order control number as the cross-reference (Xref) number. This NSCC balance order load to OW occurs each time the Consolidated Trade Summary (CTS) is created. Only obligations where the securities are eligible for OW and both the receiver and deliverer are NSCC full service members with OW activated are loaded to OW. Note Time frames listed have changed with the introduction of a shortened settlement cycle in 2017. Transaction Description Multilaterally NSCC Balance Order transactions with like CUSIPs and settlement dates are marked to the Netted uniform market priced, aggregated into buys versus sells, then netted and allotted to establish the least number of obligations needed to settle the security. The remaining obligations are automatically added to OW two days prior to settlement. Bilaterally Bilaterally netted NSCC Balance Orders require that the same counterparties have multiple Netted trades in a CUSIP are netted to produce one buy and one sell for each settlement date. The resulting obligations are added to OW when the CTS is produced, typically, two days prior to settlement. Trade-for- Transactions that were traded as trade for trade as denoted on the original submission received Trade from the exchange or member. Two days prior to the settlement date, the obligation is loaded into OW with the trade for trade designation being noted by X-CNS = yes. Members using Universal Flip should be aware that conditions arise that create an obligation in the Obligation Warehouse system for the submitting firm that has not been flipped to the destination/settling firm. It is the responsibility of the member to monitor their accounts and close obligations where appropriate. Aggregated Transactions in certificates of deposit (CD’s) are aggregated in the NSCC Balance Order Trade-for- system. All like buys in the same CUSIP for the same contra are summed into one buy Trade obligation. Likewise, all sells in the same CUSIP and contra are aggregated into one sell obligation. The result is that for each contra in every CUSIP, only one buy and one sell need to be settled. The resulting buys and sells are automatically loaded to the OW two days prior to the settlement date. Special Conditions for NSCC Balance Orders include: l Balance Orders in Syndicate trades are eligible for OW but are marked X-CNS=yes. l Balance Orders where the security is a Municipal Buy-in Request are accepted in the Obligation Warehouse system buy marked with X-CNS = yes. l Balance Orders are excluded from OW when the deliverer is equal to the receiver. Obligations originating from balance orders are entered into OW at the completion of each consolidated trade summary. The obligation source field on Obligation Warehouse Web denotes NSCC for Balance Orders. Application Input and Output 31 Obligation Warehouse User Guide 6.1.5 CNS Exits If CNS suspends the eligibility of a security for any reason, the obligations are exited and sent to OW. The CNS exits include both the standard (SD-2) and non-standard (SD-1) settlements. CNS exits are added to OW with the original source of CNSE. The obligation is available for the daily CNS eligibility check, if the CUSIP becomes eligible for CNS settlement. Municipal buy-ins exited from CNS are marked with the exclusion indicator of X-CNS = yes to prevent the obligation from possibly being reintroduced to CNS for settlement. CNS exits are added as part of the OW start of day process. Obligation Warehouse Web displays the obligation source as CNSE for CNS exits. 6.1.6 Input Methodology OW allows submission of obligations using either the Obligation Warehouse Web Obligation Entry page or MT 515 Instruct, which is a 15022 ISO SWIFT like MQ messages. 6.1.6.1 Ex-Clearing Trades that are consummated outside of the traditional exchanges or CMU RTTM are required by FINRA rule 11190 to have contras exchange confirmations. OW satisfies the FINRA confirmation requirement and provides an electronic means of matching and retaining a historical record of the transaction. Two contra-parties to the obligation enter the ex-clearing transactions directly into OW. The ex-clearing transaction can be added to OW anytime during business operation through either an MQ message or directly into the Obligation Warehouse Web entry page. As a best practice, bilateral submissions for comparison (101 Confirmations) should be entered on the trade date, no later than 6:30 (A.M.) Eastern Time on TD +1. Participant bilateral submissions may be identified by the Original Source code of PART. 6.1.6.2 Fails Each contra-party to the ex-clearing trade submits their trade details to OW, where matching and response occurs in real-time. Obligations that have failed to settle are required to reconfirm and reprice using the OW RECAPS service. If an obligation was closed in error or never was submitted to OW, upon failure to settle it should be matched in the Obligation Warehouse system. The central repository of failed obligations in the Obligation Warehouse system are maintained until closed by settlement completion or canceled through bilateral agreement. As a best practice, enter bilateral submissions for obligations that have failed to settle and were not previously entered using Obligation Warehouse on SD + 1. 6.1.6.3 Comparison Only Submissions Comparison Only trades are not supported by OW and should be matched in CMU RTTM. Application Input and Output 32 Obligation Warehouse User Guide 6.2 Output Source The following sections provide the output source information. 6.2.1 MQ Messages OW uses the MT 509 Status, and MT 518 Confirmation, ISO 15022 MQ messages for communication outbound to members. Additionally, the MT 598 reject message and MT 599 Administrative messages are used. For more information, review the Participant MQ Messaging Specification document available in the OW Technical Documents section of the DTCC Learning Center. 6.2.2 AutoRoute Files OW utilizes AutoRoute files for intraday positions, end of day positions, and Cash Adjustments due to Mandatory Reorganizations. Members may request AutoRoute files by contacting their Client Support at 1- 888-382-2721, option 2, then option 4. All times in the following table are in Eastern Time AutoRoute Name Output Times Product ID # 02050703 Intraday and End of Day Position MRO (AutoRoute Intraday 16:00 (4 P.M.) and EOD Product ID: Production 02050703, PSE Test 02980703) approximately 19:00 (7 P.M). 02051658 Cash Adjustments for Mandatory Reorg. File (AutoRoute Cycles daily, beginning at SOD Product ID: Production 02051658 / PSE TEST 02981658) approximately: l 21:00 (9 P.M.) l 10:30 (A.M.) l 12:30 (P.M.) l 14:30 (2:30 P.M) l 16:45 (4:45 P.M.) 02051967 OW Pair Off Activity MRO (AutoRoute Product ID: Intraday 17:30 (5:30 P.M.) Production 02051967 / PSE Test 02981967) 02980703 Intraday and End of Day Position MRO (AutoRoute Intraday 16:00 (4 P.M.) and EOD Test Product ID: Production 02050703 / PSE Test 02980703) approximately 19:00 (7 P.M.). 02981658 Cash Adjustments for Mandatory Reorg. File (AutoRoute Two cycles daily, SOD Test Product ID: Production 02051658/ PSE TEST 02981658) approximately 21:00 (9 P.M.) and 14:00 (2 P.M.). 6.2.2.1 Intraday and End of Day Position Files The Intraday Position Machine Readable Output (MRO) is produced daily at 16:00 (4 P.M.) Eastern Time. Many firms use the Intraday Position file to reconcile and prepare for the CNS eligibility check at 17:00 (5 P.M.) Eastern Time. The End of Day MRO is created at the close of all processing for a given business day, usually about 19:00 (7 P.M.). 6.2.2.2 Intraday and End of Day Position File Layouts The Intraday and End of Day Position files share the same AutoRoute Product ID’s and file layouts. In the AutoRoute header record in position 54-55, the Intraday Position file is noted as Cycle 1, whereas the End of Day Position file is Cycle 99. This file contains a snapshot of all unmatched, open, pending delivery, pending cancel, and closed today obligations stored in the Obligation Warehouse. The new field and values are highlighted in red. Download the Application Input and Output 33 Obligation Warehouse User Guide Intraday and End of Day Position MRO (AutoRoute Product ID: Production 02050703, PSE Test 02980703) file, along with other layout files, available in the OW Record Layouts section of the DTCC Learning Center. 6.2.2.3 Cash Adjustments for Mandatory Reorg. File OW runs maintenance on OPEN obligations five times daily at the start of the processing day (SOD, about 21:00 (9:00 P.M.), 10:30 (A.M.), 12:30 (P.M.), 14:30 (2:30 P.M.), and 16:45 (4:45 P.M.) Eastern Time) to make adjustment when the underlying security has had a mandatory corporate action event. When the mandatory corporate action event occurs, OW produces a file to indicate the fail clean up and new money created in the transformation. All cash adjustments correspond to the DTC Money Settlement Code 21 seen the same day, except for the Cycle 5 cash adjustments that appears on the following business day. Download the Cash Adjustments for Mandatory Reorg. File (AutoRoute Product ID: Production 02051658) file, along with other layout files, available in the OW Record Layouts section of the DTCC Learning Center. 6.2.3 OW Pair Off Activity MRO File OW processes the Pair Off of Open obligations daily, immediately after the eligibility check for CNS, (approximately 17:15 (5:15 P.M.) Eastern Time). Upon completion of the OW Pair Off process the output is produced. The machine-readable output (MRO) version of the OW Pair Off Activity file is distributed upon completion. Download the OW Pair Off Activity MRO (AutoRoute Product ID: Production 02051967, PSE Test 02981967) file, along with other layout files, available in the OW Record Layouts section of the DTCC Learning Center. 6.2.4 Obligation Warehouse Web Every time an action has taken place in the Obligation Warehouse system the obligation is updated in real- time on the Obligation Warehouse Web. The Obligation Warehouse Web page detail view also has a history button to see each iteration, in the life cycle of an obligation. The Obligation Warehouse Web Report Center provides a report view of the output files. The Intraday and End of Day Position files are divided into more specific sections. The report is defined as follows: l Uncompared—(UNC, UNPA, DKPA, DKUN) l OPEN-(OPEN status only) l Pending—(OPPA, PCPA, PCAN, RCPA) l Closed—(CLSD, MKDL, CANC) l RECAPS-(OPEN and Closed on RECAPS day) l Corporate Actions-(OPEN and Closed on day of event.) l Pair off Activity-(OPEN and Closed on day of event.) Application Input and Output 34 Obligation Warehouse User Guide 7. PROCESS RULES This section explains the process rules for submitting an obligation. It also describes statuses and don’t know (DK) actions. 7.1 Submitting Obligations Members can enter obligations into OW as a bilateral submission using either an MQ messaging MT515 Trade Submission record or Obligation Warehouse Web Obligation Entry page. 7.1.1 Mandatory Fields for Bilateral Submissions The following table shows the mandatory fields for bilateral submissions: Field Name Description Required Required for Matching For MQ Obligation Criteria Warehouse Web Xref Cross-reference identifier sourced by the Yes Yes No firm entering. Trade Date Date of trade** Yes No No Settlement Date Settlement date. Yes Yes Yes CUSIP Identification of underlying security. Yes Yes Yes Quantity Number of equity shares, UIT units or face Yes Yes Yes amount of bonds Final Money Amount of US dollars paid at settlement. Yes Yes Yes Amount* MPID Alpha identifier of executing broker the No No If (receiver and/or transaction used by clearing members. populated, deliverer) yes Contra Clearing member NSCC number. Yes Yes Yes Receiver/Deliverer Entering Member identifies their perspective Yes Yes Yes of the transaction and the Contra has the opposing side. X-CNS indicator Marks an obligation to be excluded from No No If CNS Settlement. (default is (default is no) populated, no) yes X-RECAPS Marks an obligation to be excluded from the No No No RECAPS process (default is (default is no) no) X-REORG Marks an obligation to be excluded from No No No transformation in the event of a mandatory (default is (default is no) Reorg. no) *The money tolerance for a comparison is $5 per million of the Final Money Amount. **If the trade date was unknown and submitted through MQ message as 12/31/9999 or entered on Obligation Warehouse Web input as blank; both file output and the Obligation Warehouse Web Trade Details are blank. Process Rules 35 Obligation Warehouse User Guide 7.1.2 Timing of Submissions for Matching The following timing of submissions into OW for matching has been defined by the SIFMA SOS OW Best Practice Committee: l Bilateral submissions for comparison (101 Confirmations) should be entered on the trade date, no later than 6:30 (A.M.) Eastern Time on TD +1. As per the industry best practices the trade date, if known, should be populated with a valid business date. If the trade date is unknown, enter a blank through Obligation Warehouse Web or default value of 12/31/9999 through MQ. Trade dates submitted using blanks or default values result in output on the Obligation Warehouse Web and OW Position file as blank values. MQ messaging continues to use the default value of 12/31/9999 in the Trade Date field if the blank or default was submitted on the Comparison Request input. l Bilateral submissions for obligations which have failed to settle and were not previously entered into the OW should be entered on SD + 1. l Prime broker items should be submitted to OW after a fail has occurred. OW does provide for a window of opportunity on the afternoon (1:00 P.M. to 5:00 P.M. Eastern Time) of trade date + two days to match prime broker trades, which could then be sent to CNS. However, if a prime broker submission remains uncompared after settlement date, the item remains as uncompared until matched or canceled from OW. 7.1.3 Retaining Uncompared Submissions Uncompared submissions in the Obligation Warehouse system remain available for comparison until matched or canceled from OW, regardless of whether the settlement information has been posted on the submission. If a member, named as one of the contra-parties to an uncompared obligation, undergo a participant swing, the comparison request is deleted as part of the Participant Swing process. Uncompared obligations where the underlying CUSIP has had a corporate action event should be canceled by the instructing party. 7.2 Uncompared Status (UNC) Review this section to learn about the uncompared status (UNC). 7.2.1 Available Actions for Uncompared Submissions When the OW has receives an instruction for comparison request by the submitter, the contra is immediately notified with a comparison advisory. Responses for a Comparison Advisory request are: l Agree to match the comparison by one of the following ways: o Affirm using Obligation Warehouse Web o Send MT 515 Instruct message with like details, or o Send MT 515 Modify message to align an outstanding submission so the obligation details match. l Disagree to match the comparison request o DK through Obligation Warehouse Web identifying the appropriate DK reason on the drop-down menu o DK using an MT 515 DKUN message and include the DK reason code. See DK of Comparison (DKUC) Requests and Appendix A Code Tables in the OW Participant Interactive Message Specifications section of the DTCC Learning Center available at OW Record Layouts and Testing. l Cancel comparison request o Cancel on Obligation Warehouse Web using action pull down menu o Submit MT 515 Cancel message, use of notes suggested. Process Rules 36 Obligation Warehouse User Guide Delivery information can also be processed on an uncompared submission in the Obligation Warehouse system. Available actions are: l Accept Delivery and the delivery information is reflected as: o UNCP—Uncompared with full or partial delivery completed. o UNPA—Uncompared with a pending delivery acceptance for either a full or partial delivery. o CLSD—the uncompared prime broker transaction was closed due to full delivery being completed. l Not Accepting the Delivery of an uncompared submission, does not remove the Comparison Advisory. o UNCP—The delivery advisory was DK'ed by the contra. 7.2.2 Automated Actions Taken by OW on Uncompared Submissions OW performs regular maintenance on the OW repository. Primarily an obligation must be in an OPEN status; however, sometimes it is necessary to affect an uncompared submission. l Administrative close—When needed, OW closes uncompared obligations and lists a reason code in the notes field. l Participant Swing—When outstanding comparison requests are present, the uncompared obligations is marked for deletion. Members should resubmit comparison requests using the new member number. l Mandatory Reorg.’s—Uncompared obligations are not transformed; therefore, members should cancel and rebook the submission. l Closed Sent to CNS—Uncompared obligations are never eligible for CNS. l RECAPS—Uncompared obligations are not included in the RECAPS process. l Pair off—Uncompared obligations are unavailable for pair off. Indicators for pair off preference should be marked only on matched obligations. 7.3 Don’t Know (DK) Actions The Don’t Know (DK) action provides a way for advisories to be acknowledged with a response indicating that there is a discrepancy. Numerous DK reason codes have been defined to assist in the communication around a DK response. A DK can be applied to one of three types of advisories: Comparison, Delivery, and Cancel. 7.3.1 DK Purge Rules The DK of a comparison is active in the Obligation Warehouse system for five business days. On the fifth business day, as part of end of day processing, the uncompared obligation in a DK status is marked for deletion, which is a terminal state. When a cancel or delivery request of a matched obligation has the response of DK from the contra, the obligation remains in the previous status. DKs for cancel or delivery requests do not age. Process Rules 37 Obligation Warehouse User Guide 7.3.2 DK of Comparison (DKUC) Requests When the contra does not know or agree with the Comparison Advisory request received, the action for the obligation should be a DK. DK is available on both the Obligation Warehouse Web or using an MT 515 DKUC message. If a Comparison Advisory is DK’ed, the parties to the obligation have five business days (action date, plus four business days) to resolve the DK before it is purged from OW. Delivery information can still be accepted on an obligation while the Comparison DK is in dispute. The following table shows the reason codes for Don’t Know Uncompared (DKUC) requests: Reason Code Description E104 Invalid Security E105 Bad Quantity E106 Bad Trade Date E107 Bad Settlement Date E109 Bad Amount E110 Bad Buyer (Receiver) Party E111 Bad Seller (Deliverer) Party E127 Duplicate Record E152 Matched Comparison Only E154 We know as Customer E156 We know as Contract E158 We know settles Foreign market E160 We know as Prime Broker E162 We know as Syndicate E164 No/Incorrect MPID E166 Trade changed to clear CNS E168 Invalid CUSIP identified E170 Not Prime Broker E199 Other Bad Data 7.3.3 DK of Cancel (DKCN) Requests When the contra does not know or agree with the Cancel Request received, the action for the obligation should be a DK. DK is available on both the Obligation Warehouse Web or using an MT 515 DKCN message. The following table shows the reason codes for Don’t Know Cancel (DKCN) requests: Reason Code Description E304 Invalid Security E305 Bad Quantity E306 Bad Trade Date E307 Bad Settlement Date E309 Bad Amount E310 Bad Buyer (Receiver) Party E311 Bad Seller (Deliverer) Party Process Rules 38 Obligation Warehouse User Guide Reason Code Description E327 Duplicate Record E352 Unknown cancel (cancel request) E354 Still Open E356 Corporate Action Item E358 ACATS Reversal in process E360 Unknown Cancel for Foreign item E362 Wrong OW Control Number E391 Previous Settlement E399 Other Bad Data 7.3.4 DK of Delivery (DKDL) Requests When the contra does not know or agree with the Delivery Notification Request received, the action for the obligation should be a DK. Note The term delivery is used whether you are delivering or receiving the settlement information. DK is available on both the Obligation Warehouse Web or through an MT 515 DKDL message. The impact of applying a DKDL: l Uncompared, Pending Acceptance (UNPA) returns to UNCP status l DK, Pending Acceptance (DKPA) returns to DKUN status l Open, Pending Acceptance (OPPA) returns to OPEN status l Pending Cancel, Pending Acceptance (PCPA) returns to PCAN status. The following table shows the reason codes for Don’t Know Delivery (DKDL) requests: Reason Code Description E504 Invalid Security E507 Bad Settlement Date E509 Bad Amount E510 Bad Buyer (Receiver) Party E511 Bad Seller (Deliverer) Party E552 Previous settlement E554 Settlement type error E556 Securities not received E558 Duplicate delivery E560 Still Open E562 We know settled DLVR E564 Future Settlement date E566 Need Paperwork E568 Bad denominations Process Rules 39 Obligation Warehouse User Guide Reason Code Description E570 Need Medallion stamp E572 Wrong partial amounts (quantity, value) E574 Reclaim-received partial E576 No agent/unable to transfer E578 Settlement date difference E580 Wrong OW Control Number E582 Wrong Quantity E584 Wrong Security E586 Corporate Action item E599 Other Bad Data 7.3.5 DK of Reclaim (DKRC) Requests When the contra does not know or agree with the Reclaim of a Delivery Notification Request received, the action for the obligation should be a DK. Note The term delivery reclaim is used whether you are delivering or receiving the settlement information. DK is available on both the Obligation Warehouse Web or using an MT 515 DKRC message. The result of DK of a reclaim request: l Leave an uncompared obligation in UNCP status l Leave an open obligation in OPEN status if it was a partial Reclaim l Return a closed obligation to its previous CLSD status The following table shows the reason codes for Don’t Know Reclaim (DKRC) requests: Reason Code Description E704 Invalid Security E705 Bad Quantity E707 Bad Settlement Date E709 Bad Amount E710 Bad Buyer (Receiver) Party E711 Bad Seller (Deliverer) Party E727 Duplicate Record E762 Wrong OW Control Number E793 Settlement Type Error E799 Other Bad Data E704 Invalid Security Process Rules 40
Enter the password to open this PDF file:
-
-
-
-
-
-
-
-
-
-
-
-