CTS stands for ‘Consolidated trade summary file’. This was an industry wide mandatory change that was initiated from DTCC. The format of the CTS file was modified to a new layout by DTCC and the existing programs were not able to process the new file. Instead of modifying the entire process to handle the new file, a new job was introduced to convert the new file to the old layout.

JCL: This job consisted of four programs that converted the three different types of data in new CTS file to the old layout.

Program 1: This created a header file with appropriate cycle number and time.

Program 2: This program extracted all the gross records from the new file and converted them to the old layout into the output file1.

Program 3: This program consisted of two steps. i) Extracted all the net records from the new file and converted them to the old layout. ii) Performed netting operation on the net records depending on cusip, qty, and settlement date. The netted records in old layout were written into the output file2.

Program 4: This program extracted all the balance order records from the new file and converted them to the old layout into the output file3.

All the three output files along with header file were merged using SORT card. This created the CTS file with old layout from new file. The existing processes were able to handle this file without any abend.

SPO stands for ‘Special Payment Orders’. SPOs do not enter into the normal trade life cycle of a security. These SPO trades are received by the users either through telephone or email. Since SPO trades were very minimal in number, they are manually settled by the users. This process was automated by creating two screens using CICS.

Screen 1: Trades were entered through this screen and it contained fields such as CUSIP, Amount and settlement date.

Screen 2: The trades that were entered in screen 1 can be approved or rejected in screen 2.

Note: The same user who entered the trade in screen 1 cannot approve the trade. Only an authorized second user will validate the trade information and approve that trade.

Background Transaction: All the approved SPO related information was stored in a VSAM file. This transaction would read the SPO items and check with other open SPO items for matching. In case a match is encountered, the status of the trade was changed to ‘matched’ and the information as sent to DTCC for authorization through MQ. Once the trade gets authorized in DTCC(Depository trust clearing corporation), NSCC(National Securities Clearing corporation) will settle the trade between the buyer and seller. The credit and debit information would also be modified in the book keeping process to avoid breaks.

JCL: A job was created and scheduled to run at the start of every day. This job created the SPO report, which had status of all SPO items that were entered the previous day. This report will be mailed to the SPO users’ everyday using SMTP protocol in the JCL.

SPO stands for ‘Special Payment Orders’. SPOs do not enter into the normal trade life cycle of a security. These SPO trades are received by the users either through telephone or email. Since SPO trades were very minimal in number, they are manually settled by the users. This process was automated by creating two screens using CICS.

Screen 1: Trades were entered through this screen and it contained fields such as CUSIP, Amount and settlement date.

Screen 2: The trades that were entered in screen 1 can be approved or rejected in screen 2.

Note: The same user who entered the trade in screen 1 cannot approve the trade. Only an authorized second user will validate the trade information and approve that trade.

Background Transaction: All the approved SPO related information was stored in a VSAM file. This transaction would read the SPO items and check with other open SPO items for matching. In case a match is encountered, the status of the trade was changed to ‘matched’ and the information as sent to DTCC for authorization through MQ. Once the trade gets authorized in DTCC(Depository trust clearing corporation), NSCC(National Securities Clearing corporation) will settle the trade between the buyer and seller. The credit and debit information would also be modified in the book keeping process to avoid breaks.

JCL: A job was created and scheduled to run at the start of every day. This job created the SPO report, which had status of all SPO items that were entered the previous day. This report will be mailed to the SPO users’ everyday using SMTP protocol in the JCL.

SPO stands for Special Payment Orders. SPOs do not enter into the normal trade life cycle of a security. These SPO trades are received by the users either through telephone or email. Since SPO trades were very minimal in number, they are manually settled by the users. This process was automated by creating two screens using CICS. Screen 1: Trades were entered through this screen and it contained fields such as CUSIP, Amount and settlement date. Screen 2: The trades that were entered in screen 1 can be approved or rejected in screen 2. Note: The same user who entered the trade in screen 1 cannot approve the trade. Only an authorized second user will validate the trade information and approve that trade. Background Transaction: All the approved SPO related information was stored in a VSAM file. This transaction would read the SPO items and check with other open SPO items for matching. In case a match is encountered, the status of the trade was changed to matched and the information as sent to DTCC for authorization through MQ. Once the trade gets authorized in DTCC(Depository trust clearing corporation), NSCC(National Securities Clearing corporation) will settle the trade between the buyer and seller. The credit and debit information would also be modified in the book keeping process to avoid breaks. JCL: A job was created and scheduled to run at the start of every day. This job created the SPO report, which had status of all SPO items that were entered the previous day. This report will be mailed to the SPO users everyday using SMTP protocol in the JCL.