5. Processing an SLT Contract

This chapter contains the following sections:

5.1 Introduction

A contract is a specific agreement or transaction entered into between two or more entities. In SLT module, the trade details for initiating a contract can originate from any of the following sources:

Except for trades originating from LB, you can use the ‘Secondary Loan Trading - Draft Trade’ screen to enter the details of the contract.

This section contains the following topics:

 

You can invoke the ‘Trade- Online’ screen by typing ‘TLDTDONL’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.

 

When you click the ‘New’ from the menu, the ‘Trade Type’ screen is displayed where you can specify the type of the trade you want to perform.

 

You can specify the following details in this screen:

Trade Type

Select the type of your trade from the drop-down list provided. From the menu, select ‘New’ to specify the details for a new trade deal.or select ‘Modify’ if you want to modify the details of an existing deal

Contract Ref. No.

Select the reference number of the contract whose details you want to modify, from the option list provided. This is applicable only for ‘’Modiy’ type of trades.

Product

Select the product code of the trade product you want to use for the trade deal, from the option list. All trade products maintained in the ‘Secondary Loan Trade - Product Definition’ screen are displayed in the list.

Product is enabled only for ‘New’ trades.

Position Identifier

Select the position identifier or the branch-desk-expense code combination, to be used to track the position details of a portfolio. Position identifiers corresponding to all the portfolios defined for the current branch are displayed in the option list.

Position identifier is enabled only for ‘New’ trades.

5.1.1 Specifying Trade Details

The following details are defaulted for a new trade:

The trade reference number gets generated on successful processing of the trade contract.

You can specify the following details related to the trade, in this screen:

CUSIP/ISIN

Specify the unique reference number indicating the facility to be associated with the deal. You can specify either a new CUSIP number or an existing CUSIP whose details have already been captured in the LB module.

Facility Name

Specify a name for the facility, if you are entering a new CUSIP. For existing CUSIP, the related facility name gets defaulted here.

Ticket Id

Specify a ticket Id to be associated with the trade. Many trades can be grouped together under one ticket.

All trades under the same ticket must have same trade date, expected settlement date and counterparty. In case of line trades, the counterparty can be different.

Note

Ticket Id can be ‘NULL’ if the trade originated as part of agency creation.

Cascade Participation

This option is selected by default. You can deselect this check box if the trade is Non Pro-rata CUSIP and the agency details are not available in the system. This is applicable only for ‘Par’ and ‘Distress’ types of trade.

For the trades in the Non Pro-rata, the DCF computation is considered as follows:

5.1.2 Specifying Markit Details

Trade ID

Specify the trade id to uniquely identify the associated SLT trade in Oracle FLEXCUBE for each of the trade sent from Markit.

Allocation ID

Specify the allocation id for the matching processing and manual linkage of SLT and Markit trades.

5.1.3 Specifying Contract Details

Counterparty

Select the unique identification of the counterparty involved in the trade deal from the option list. The list of all valid customers is displayed from which you can select the counterparty.

Note

The buyer or seller should be an existing customer of your bank.

Currency

Select the currency to be associated with the tranche from the option list provided.

Trade Amount

Specify the tranche amount that you want to buy or sell. The amount you specify here should not exceed the total amount for the tranche.

Trade Price

Specify the price at which the trade transaction is being carried out.

Original Trade Amount

The trade amount specified at the time of booking the contract gets displayed. Original trade amount is not impacted by any further amendments to the trade amount. This is used for calculating the broker fee involved in the trade.

Type

Select the contract type from the options available. The type of contract is not considered while processing the trade.

Quotation

Select the type of quotation to be associated with the trade, from the drop-down list. The following options are available:

PIK Amount

Specify the PIK portion associated with the funded amount for the trade.

Buy/Sell Indicator

Select ‘Buy’ option to indicate that the related trade is a buy transaction or select ‘Sell’ to indicate that it is a sell transaction.

Trade Type

Select the type of the trade from the drop-down list. The options available are as follows:

Deal Type

Select the type of the trade deal from the drop-down list. The following options are available:

Commitment Reduction Amount

Specify the amount indicating a reduction in the commitment amount for the tranche.

Commitment Reduction Price

Specify the commitment reduction discount/ premium price for trade booking and trade amendment. You cannot amend ‘Commitment Reduction Price’ alone as part of commitment reduction amendment.

Note

‘Commitment Reduction Price’ in the ‘Draft Input’ screen cannot be amended as part of any normal amendment.

Collateral %

Specify the collateral percentage.

Transfer Price

The system displays the price entered while processing the associated HFS transfer as part of PRAM in the LB module. This value is displayed only for trades processed as part of HFI to HFS transfer.

HFS Transferred Cost Basis

The system displays the lowest of LOCOM Carry Value and Transfer price, and displays it here for internal sell trades processed as part of HFI to HFS transfer.

5.1.4 Specifying Booking Details

You can specify the following details related to the booking of a trade deal

Booking Date

Booking date is the date on which the trade transaction is initiated. The system date gets defaulted here.

Trade Date

Specify the date on which the actual trade happens.

Note

Trade date cannot be greater than the expected settlement date.

Expt. Settl. Date

Expected settlement date is defaulted based on the trade date and the settlement days, maintained in the ‘Product Preferences’ screen. You can modify this, if required.

Maturity Date

Specify the contract maturity date or select the maturity date from the calendar available. Maturity date is not considered while processing the trade.

5.1.5 Specifying Other Details

You can specify following other details related to the trade deal:

Agency Id

Select the Id of the lead agent of the transaction, to whom the assignment fee needs to be sent.

Broker

Select the Id of the broker involved in the deal, if any, to whom the broker fee needs to be sent.

Assignment Fee Remitter

Select the party that remits the assignment fee to the lead agent. The options available are as follows:

Ext CUSIP/ISIN

Specify the external CUSIP number to be associated with the trade deal.

Borrower

Specify/select the borrower from the options available. Borrower is not considered while processing the trade.

Commitment Reduction/Increase Amendment

Select this check box to indicate that the amendment is due to commitment reduction/increase..

PIK Amendment

Select this check box to indicate that the amendment is due to PIK component associated with the trade amount.

Parent Line Trade

Select this check box to indicate that the associated customer trade is created as a result of a line trade.

Note

This is applicable only for trades of type ‘Customer Trade’.

Apply Cmt Redn/PIK for CUSIP Amendment

Select this check box to indicate that reduction in commitment amount is applicable for the tranche during CUSIP amendment. The reduction is applicable only if the trade has commitment reduction/PIK amount.

Document Type

The DCF (Delayed Compensation Fees) categories for a trade are derived based on the document type specified.

Select the document type from the adjoining drop down list. The list displays the following values:

Note

If the document type is 'Par' then the following funded DCF categories are applicable;

If the document type is 'Distress' then the following funded DCF categories are applicable;

Firm Account Mnemonic

The system displays the corresponding firm account mnemonic based on the position identifier/portfolio.

5.1.6 Specifying Holiday Preferences

The holiday treatment preferences specified for the product gets defaulted here. You can modify there details, if required.

Ignore Holidays

Select this check box to indicate that the settlement date is fixed without taking the holidays into account.

Consider Branch Holiday

Select this check box to indicate that the settlement date is fixed taking into consideration the holidays specified for the branch.

Holiday Ccy

Select the currency associated with a trade deal, for which you want to specify the holiday preferences.

Apply Local Ccy

Select this check box to indicate that local currency holidays need to taken into consideration while fixing the settlement date.

Apply Contract Ccy

Select this check box to indicate that the contract currency holidays need to taken into consideration while fixing the settlement date.

Remarks

Specify remarks, if any, to be associated with the trade contract.

After entering the basic trade details, you can validate the same by clicking ‘Verify’ button.

On successful validation, you can select the ‘Submit’ option to send the trade details for further processing, after authorization. All trades specified in this screen remains in the draft stage until they are selected for submission. Before submitting the details for further processing, you can modify the details any number of times by unlocking the record and amending the details. You can also delete the details, if required, before it is submitted for further processing.

After successful validation of the trade details, if you select the ‘Reject’ option, the details specified can be rejected, in case of any discrepancies.

You can also perform an amendment of the trade details in this screen, before trade settlement.

Note

Trades uploaded from Loan QT are treated as confirmed trades by default. You cannot modify the expected settlement date, in this case.

A unique reference number called the Trade Reference Number gets generated for every processed trade and the position details of the trade are also updated. The trade details are processed further in the SLT module.

You can view the details of a processed trade in the ‘Trade Online’ screen.

For more details on Trade Online screen, refer the section ‘Viewing Processed Trades’ in this user manual.

Note

The details of trades uploaded from Loans QT are processed automatically with the de­fault selection of ‘Validation’ and ‘Submit’ options.

5.2 Viewing Exceptions Summary

The exceptions arising out of validation or processing of draft trade details can be viewed in this screen. You can proceed further by unlocking the draft trade record and correcting the exceptions.

You can also view a summary of exceptions for all the failed contracts in the ‘Exceptions Summary’ screen. You can invoke the ‘Exceptions Summary’ screen by typing ‘TLSERONL’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.

 

To view the exceptions related to a particular contract, click the ‘Contract Details’ of the contract. Alternatively, you can double-click to view the exceptions .

5.2.1 Viewing Commitment Reduction Log

You can view the details of each commitment reduction for a trade by clicking the ‘CR Log’ tab.

 

In this screen, you can also view the net commitment reduction amount and the average commitment reduction price.

While calculating the final settlement reduction amount for a trade during the trade settlement, the net commitment reduction amount is considered at the average commitment reduction price.

5.3 Viewing Draft Trade Summary

You can view a summary of all the trades entered in the Draft Trade screen, in the ‘Trade Input Summary’ screen. You can invoke the ‘Draft Trade’ screen by typing ‘TLDTDUPL’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.

In this screen you can view all trade contracts at different processing status like Unprocessed, Submit, Failed, Rejected, Drafted, and Processed.

 

For ‘Failed’ trades, you can view the errors that occurred while processing the trade by clicking ‘Error Log’. Double-clicking the trade contract takes you to the ‘Draft Trade’ screen with the contract details.

 

5.4 Processing Internal Trades for HFI to HFS Transfer

In case of HFS transfer, the system automatically creates two internal trades (a ‘Buy’ and a ‘Sell’) in the SLT module based on participant transfer instructions. The ‘Buy’ trade increases the settled position of HFS Portfolio (by the amount of the transfer to HFS) whereas the ‘Sell’ trade reduces the settled position of the HFI Portfolio by a corresponding amount.

The counterparty used for the internal trades are internal customers and the settlement account maintained for these internal customers will be internal GLs. The accounting role ‘CUSTOMER’ represents internal GLs.

The Buy trade is booked against the HFS product mapped to the origination-HFS desk. The ‘Trade Amount’ for this sell trade is the ‘Transfer Amount’ entered in the ‘Participant Transfer’ screen and the Trade Priceis the ‘HFS Transferred Cost Basis’ value computed for the Sell trade. Profit and Loss is not applicable for this trade. There are no accounting entries posted for the HFS buy internal trade processed as part of HFI to HFS transfer, including settlement entries. Weighted Average Cost) WAC is always be ‘100’ and it is not recomputed during the life cycle of the trades involving HFS portfolio. Transfer Mark is computed during HFI to HFS Transfer as Transfer amount * (100 – HFS Transferred Cost Basis). This amount is uploaded systematically on HFS commitment contract as an Amort fee during internal HFS buy trade processing.

You should have maintained and attached income and expense type of amortization fee components with ‘CLP Buy Price Diff’ check box selected, to the HFS commitment product. These components should be unique to a commitment product.

The entire trade amount is considered as unfunded amount while posting accounting entries during HFS transfer for internal Sell deals.

The HFI Sell trade is booked using the Origination trade product that is mapped in the ‘Product Mapping’ screen for CLP trade for the branch. The ‘Trade Amount’ for this sell trade is the ‘Transfer Amount’ entered in the ‘Participant Transfer’ screen and the Trade Price is the ‘HFS Transferred Cost Basis’ value.

The system picks up this HFS Transferred Cost Basis and display it in the ‘Secondary Loan –Trade Online’ screen during trade upload processing. The LOCOM Carry value, HFS Transferred Cost Basis and Transfer Price is computed and stored in % terms. Note that LOCOM Carry value is not displayed in the ‘Secondary Loan –Trade Online’ screen.

Profit and Loss due to HFI to HFS transfer is posted for the HFI internal ‘Sell’ deals

5.4.1 Impact on CoC Balance

Based on the ‘Transfer Amount’ and the overall commitment amount, the system computes the pro-rata amount for each of the following balances:

Origination queue is updated for the CoC balances and automatically confirmed. Amort fee is reduced systematically on HFI commitment during internal HFI sell trade processing as part of HFS transfer. The balances computed as part of the internal trades are based on the HFS transfer amount. The amounts to be released for underlying commitment and loan/LC loan contracts in the Originations modules are computed as part of the actions (VAMI) performed on the actual contracts.

Accounting entries are posted for the prorate CoC balances for the internal sell deal.

5.4.2 Reversing Internal Trades

You have to reverse the PRAM event processed for HFI to HFS transfer in the agency module. STP for this PRAM is not processed systematically in the trading module. Upon reversal of PRAM, you have to trigger reversal events in the trading module for the internal buy and sell trades separately, to reverse the HFI to HFS transfer.

It is not possible to reverse an internal trade if the position goes negative due to the reversal.

You are not allowed to reverse the HFS internal buy trade that is processed as part of HFI to HFS transfer, if there are any open or settled trades for the CUSIP and HFS portfolio. However, you can reverse the HFS internal trade, if all the HFS open trades (sale from HFS) are reversed.

During reversal of the internal trade for HFI sell and HFS buy, WAC remains as ‘100.’ Internal trade reversal is allowed only for the trades that are systematically processed from agency as part of HFI to HFS transfer.

5.5 Viewing Processed Trades

The trades input in ‘Draft Trade’ screen that have been successfully processed can be viewed in the ‘Secondary Loan – Trade Online’ screen. This section contains the following topics:

You can invoke the ‘Trade- Online’ screen by typing ‘TLDTDONL’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.

 

The details specified in the draft trade screen are defaulted here. From this screen, you can view the accounting entries and the events associated with the trade.

You can also capture following additional details related to the trade, in this screen:

5.5.1 Specifying Fee Details

You can capture the fee details associated with a trade contract in the ‘Fee Components’ screen. To invoke this screen, click ‘Fee’ in Trade Online screen.

 

The basic trade details, given below are defaulted from the Trade Online screen:

The following details related to the fee components are defaulted from the product level:

You can modify ‘Fee Calc Basis’ and ‘Fee Basis’, if required.

Fee Rate

Specify the fee rate to be used by the system to arrive at the fee amount. You can specify either the ‘Fee Rate’ or the ‘Amount’.

Note

This is enabled only for fee types ‘Broker Fee’ and ‘Line/Accommodation Fee’.

Amount

Specify the fee amount to be associated with the selected fee component. You can specify either the ‘Fee Rate’ or the ‘Amount’.

For ‘Assignment fee’ the sum of the Buyer’s Split Amount and Seller’s Split Amount gets displayed here.

Note

This is not applicable for fee types ‘DCF’ and ‘Break-fund Fee’.

Currency

Select the trade currency from the adjoining option list. This list displays all valid currency maintained at the currency level. This option is enabled only for ‘Assignment’ type of fee.

You need to maintain a valid SSI Mnemonic either for the agent and/or for the trade counter party based on the assignment fee remitter and assignment fee type for the currency selected. This is used during the trade/ticket settlement.

The SSI Mnemonic needs to be maintained for the different parties as specified below:

Waiver

Select this check box to indicate that you want to waive off all fee components except delayed compensation fee (DCF), for the trade contract.

DCF Waiver

Select this check to indicate that you want to waive off the delayed compensation fee (DCF) associated with the trade contract.

Note

This gets displayed only for ‘DCF’ fee types.

5.5.1.1 Specifying Assignment Fee Details

For fee components of type ‘Assignment’ you can specify the following details:

Assignment Fee Type

Select the method of sharing the assignment fee between the buyer and seller, from the drop-down list. The following options are provided:

Buyer’s Split Amount

Specify the assignment fee amount that has to be booked against the buyer associated with the trade deal.

Seller’s Split Amount

Specify the assignment fee amount that has to be booked against the seller associated with the trade deal.

Note

5.5.2 Specifying SSI Mnemonics

You can capture currency-wise SSI mnemonics in the ‘ SSI Mnemonics’ screen. To invoke this screen, click ‘SSI’ in the Trade Online screen.

The basic trade details associated with the trade contract are defaulted in this screen.

5.5.2.1 Capturing Agent Mnemonic Details

If assignment fee is involved in a trade contract, you can capture the SSI mnemonic for the currency of the agent, to whom the assignment fee needs to be paid.

SSI Mnemonic

Select the SSI mnemonic value to be linked to the agent currency, from the option list provided.

5.5.2.2 Capturing Mnemonic Details for Trade Counterparties

You can also capture the SSI mnemonics for the currencies associated with different counterparties involved in the trade deal.

Ccy

Select the currency associated with the trade counterparty from the option list provided.

SSI Mnemonic

Select the SSI mnemonic value to be linked to the currency associated with the trade counterparty, from the option list.

Remarks

Specify any additional information about the mnemonics details.

5.5.3 Viewing Funding Memo Details

You can view the funding memo details associated with a trade contract by clicking the ‘Funding Memo’tab in the Trade Online screen. The funding memo details for the current trade get displayed, if it has already been extracted. You cannot make any changes in the funding memo details.

 

For more details on funding memo refer the section ‘Capturing Funding Memo Details’ in this user manual.

5.5.4 Viewing the Amortized Fee Log Details

You can view the amortized fee log details in the ‘Un Amortized Fee Log’ screen. To invoke this screen, click ‘CLP Fee Log’ in the Trade Online screen. The screen displays the status of amortization fee processed during settlement (TSTL) or reversal of settlement (RSTL) event of origination buy trade.

 

Any action which is resulting in the trade settlement reversal of the CLP Buy, attempts to refund the FEE component amounts computed for the current trade being reversed. In case if the FEE component does not have enough balance due to any of the following reasons, system will log the exception without performing the refund:

5.5.5 Reversing Trade Contract

You can reverse the trade contract details before or after trade settlement in the ‘Trade Online’ screen. You can also authorize the trade reversal transaction in this screen.

5.6 Querying Trade Contract

You can view a summary of all the processed draft trades and query for a trade in the ‘Secondary Loan - Trade Summary’ screen. You can invoke the ‘Secondary Loan - Trade Summary’ screen by typing ‘TLSTDONL’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.

Click ‘Search‘ to view summary of all processed draft trades.

 

You can view the details of a trade in the ‘Trade Online’ screen by selecting a desired row in the summary screen and double-clicking the same.

You can also query for a trade using the ‘’Advanced Search’ screen which can be invoked by clicking ‘Advanced Search’ in this screen.

 

In this screen you can perform the following types of queries for all contracts booked for a CUSIP:

5.7 Capturing Agency Details

You can capture agency branch details in the ‘Agency Detail Input’ screen.

This section contains the following topics:

From ‘Trade Settlement Detailed’ screen (TLDSETTL), click ‘Manual Funding Memo’ tab.

 

The following trade related details are displayed here:

Tranche ref no

Specify the tranche no from the adjoining option list.

Note

Global Tranche Amount

Specify the total tranche amount for a CUSIP

Upfront Fee

Specify the upfront fee here. The fee is not used while processing any settlement.

BCR Fee

Specify the BCR Fee (Benefit of Commitment reduction) here. The fee is not used while processing any settlement.

The following details are displayed and computed based on the drawdown details specified:

5.7.1 Capturing the Pricing Details

Drawdown ref no

Specify the drawdown reference number. The adjoining option list displays all valid drawdown products maintained at the Tranche level. You can select the appropriate one.

Note

In order to create a single drawdown for multiple trades, you need to select the same dum­my reference number for all the relevant trades

For the first trade under a Ticket ID for which dummy reference numbers are yet to be generated, You are required to ‘Generate’ the first dummy reference number by clicking on the ‘Generate’ button; since no values will be available for selection from the option list.

If you select a dummy reference number from the option list and press ‘Generate’ button the selected reference number will be replaced with newly generated reference number.

You can generate a dummy reference number using ‘Generate’ option and then overwrite the generated value with a value selected from the pick list. The Total Drawdown amount under a particular dummy reference is the cumulative sum of the funded amounts under the trades for the ticket

Drawdown CCY

Specify the currency of the Drawdown which can be sued for processing.

Drawdown Product

Specify the drawdown of the product. The adjoining option list displays all valid drawdown products maintained at the Tranche level. You can select the appropriate one.

Funded Amount

The total drawdown amount in the drawdown currency

Funded Amount in Trade CCy

The system displays the funded amount in trade currency.

Ex Rate

Specify the fixed exchange rate between the Funding currency and Tranche/Trade currency if both are not same. Funded amount in Trade currency gets displayed in the adjacent field using the exchange rate given.

Borrower

Specify the borrower number. The adjoining option list displays all valid borrowers maintained at the Tranche level. You can select the appropriate one.

Value Date

Specify the value Date of the Drawdown

Maturity Date

Specify the maturity date of the Drawdown. The date should be greater than the Drawdown date

The system will validate the drawdown value date and maturity date to be within the tranche value date and tranche maturity date.

Original Start Date

Specify the original start date of the Drawdown. The date should be less than or equal to Drawdown date.

Rate Type

Specify the interest rate type of the Drawdown from the options available:

Rate Basis

Specify the rate basis. The adjoining option list displays all valid rate basis maintained in the system. You can select the appropriate one.

Buyer’s Share

Specify the buyer’s share amount as on the actual settlement details. This is used for DCF computation.

For Pro-Rata agency contracts, the system populates the details based on the trade ratio whereas for Non Pro-rata agency contract, you need to provide the details for each drawdown. Only those drawdown should be captured in which the Seller of the trade is an active participant.

5.7.2 Capturing Interest Details

Component

Specify the interest component of a Drawdown

Amount

Specify the amount of the specified component

Buyer’s Share

Specify the buyer’s share amount.

Start Date

Specify the start date of interest component computation

Re-price Date

Specify the end date of interest component computation

Base Rate

The base rate for the interest component

Margin

Specify the margin details of the interest component

Final Rate

Specify the final rate of the interest component after calculating the base rate and margin.

Note

For more details on negative rate processing, refer the title ‘Maintaining Loans Parame­ters Details’ in the chapter ‘Bank Parameters’ in Core Services User Manual.

5.7.3 Auto Booking of Drawdown Details

The drawdown is created automatically in agency if you input the drawdown details in ‘Agency Details Input’ screen of funding memo during ticket / trade settlement. The Auto book of drawdown in agency through STP from SLT is applicable only Ii it satisfies all the following conditions:

If you have selected the 'Non-Prorata/PIK Settlement' option in ticket / trade settlement, the system defaults all the existing drawdown details with buyer's share and corresponding drawdown amounts in the ‘Agency Detail Input’ screen.

If the drawdown exists under a CUSIP during the trade/ticket settlement, the system does the following:

In case, if the both new drawdown and existing details are available, the system displays an error message.

The system checks if the ‘Non-prorata / PIK settlement’ option is selected, then it arrives at the corresponding drawdown amounts based on the buyer’s share for the individual drawdown’s while processing the records from the TL-LB handoff browser.

Once the trade is settled and processed in LB browser, the system does not reverse the Drawdown newly created when Trade Settlement is reversed.

If the trade settlement is reversed, then the system fires an offset VAMI that is, negative VAMI for buy reversal for all drawdowns affected as part of the settlement. But it allows the creation of drawdown for back dated ticket settlement provided there is no ticket settlement / agency activity with value date after ticket settlement date.

In case of multiple open trades with different new drawdown details in ‘Agency Details Input’ screen, the system creates multiple new drawdowns during TL-LB STP after ticket settlement.

5.7.4 Capturing Additional Drawdown Details

You can capture additional drawdown details in ‘Additional Drawdown Details’ screen by clicking ‘Addl Drawdown Details’ in the ‘Agency Detail Input’ screen.

 

Specify the following details:

RAC Rate

Specify the RAC rate. The RAC rate is difference between net rate and base rate which is always zero and validates if RAC rate is not zero.

Rate Basis (LIBOR/EURIBOR)

Specify the rate basis. The adjoining option list displays all valid rate basis maintained in the system. You can select the appropriate one.

The new drawdown is created only based on the rates mentioned in the ‘Agency Detail Input’ screen and not the details specified here.

The system displays the following details:

5.8 Capturing Origination Trade Details

Line trades are trades which are handled by a desk on behalf of another desk. Origination trade supports not only ‘Assignment type’, but also ‘Participation type’. However, the actual participation happens only during the internal Origination trade.

Trade deals involving the Origination desk are handled as line trades in Loans QT. These deals, discussed in detail in subsequent sections, can be either CLP Buy or CLP Sell.

This section contains the following topics:

5.8.1 Processing CLP Sell Line Trades

For CLP Sell line trades involving the origination desk, the following three separate trade deals are generated.

  1. Par desk selling to customer
  2. Par desk buying from Origination desk
  3. Origination desk selling to Par desk

Note

Loans QT may send multiple sell trade from Par desk to Customer (the first type of trade mentioned above) for line trades within a single ticket.

These three deals are created under the same ticket and are settled together during the ticket settlement. For the first trade, where par desk sells to customer, you need to select the ‘Parent Line Trade’ check box.

The origination trade processing is carried out as follows:

  1. When the third trade details, that is, origination desk selling to par desk, are handed off from Loans QT to Oracle FLEXCUBE, the system checks if the related trade is a line trade.
  2. If it is a line trade, then the details of this origination sell trade get populated in the ‘Line Trade – Origination Details’ screen. Unamortized fee amount, Reserve amount and the Contra amount applicable for the origination desk corresponding to the Participation sell gets defaulted, whereas Participation buy should be handled manually.
  3. The origination line trade is processed once you confirm these details.

Note

If the contra and reserve are captured in cross currency loans, then the contra and reserve is not defaulted and it is assumed to be zero.

You can invoke the ‘Line Trade - Origination Details’ screen by typing ‘TLDORGQU’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.

 

Following details related to the origination line trade are displayed here:

Note

For CLP buy line trade, if the deal type is ‘Participation’, the SLT position and the agency activities to be tracked independently for the normal participant and silent participant. In such cases, when the Participation Buy is entered for the first time, system does not have the corresponding CLP Participation commitment in place. The FEE components should be handled manually as part of manual creation of agency and origination details.

Confirm/Reject

Select the option to indicate whether you want to confirm or reject the details specified in this screen.

The line fee gets settled as part of line trade booking. Line fee income for the par desk is passed during the line trade and line fee expense for the origination desk is passed during the origination sell deal.

For origination sell deal, the unamortized fee, reserve amount and contra amount are considered for PnL calculation.

The carrying value, cost of carry and PnL are computed based on the following formulae:

The PnL entries, in case of loss, are passed as part of trade booking, whereas the PnL entries, in case of profit, are passed as part of trade settlement for the origination desk.

Any amendments to the CLP Sell line origination trades resulting in change of position or PnL, results in an internal reversal of the trade and the trade is re-booked with the revised details. The PnL entries of the original trade is reversed and the reserve, contra and unamortized fee amount as per the revised trade is considered for PnL computation. However, amendment from assignment to Participation type or vice versa is not allowed. It has to be handled by means of reversing the current trade and rebooking the revised trade with the proper deal type.

The amendments also get populated in the ‘Line Trade – Origination Details’ screen and the amended details have to be confirmed before it can be processed further.

A batch program in the OL module handles the reclassification of an exposure as Held for Sale (HFS), for the origination trade amounts. It identifies the list of open trades and trades booked on the current date and arrives at the reclassification break up required for funded amount, unfunded amount and LC amount for each of the origination entity. The reclassification entries are passed for the affected loans and commitment contracts as part of the ‘TRCL’ event. If the cost of credit valuation is selected for the commitment underlying the trades, instead of the re-classification happening during batch, the system does the re-classification during trade booking itself.

Note

5.8.2 Processing Cost of Credit Valuation for Commitments

If a cost of credit valuation is required for a commitment, when booking is done for a sell trade and the confirmation is received from the origination queue, the following events takes place:

Note

The offset entry (Credit leg) for these events are posted to the SLT OL Bridge GL (main­tained in ‘SLT Branch parameters’ screen) instead of the regular account it would have been posted into, if the triggering had been done manually at the commitment level.

Additionally, the system computes the following balances:

If there is any amendment in the trade amount, then all the balances required to be computed for the cost of credit valuation is recomputed based on the latest trade amount and new entries posted.

As part of the settlement (TSTL), the system does the net recovery in the following order:

After net recovery is done, the residual of each of the amounts that was not recovered is recorded, so that the balances in the GL’s for each of these amounts are correct. The net entries for the difference between the Recovery amount for each of the Write-off / Contra / FAS91 fees / Marks and the actual balance populated in Origination Queue is posted at the trade level.

5.8.3 Validating Unamortized Fee

You can re-compute the unamortized fees at TL and OL layer during the origination queue confirmation. If the recomputed fee is different from the existing computed fee then an override is displayed to show the newly computed unamortized fee amount. Click OK if you want the system to overwrite the existing fee and do the processing based on the recomputed fee.

5.8.4 Processing CLP Buy Line Trades

For CLP Buy line trades involving the origination desk, the following three separate trade deals are generated.

  1. Par desk buying from Customer.(Customer trade)
  2. Par desk selling to Origination/CLP desk
  3. Origination/CLP desk buying from Par desk

These three deals are created under the same ticket and are settled together during the ticket settlement.

The origination trade processing is carried out as follows:

  1. When the third trade details, i.e, origination desk buying from par desk, are handed off from Loans QT to Oracle FLEXCUBE, the system checks if the related trade is a line trade.
  2. If it is a line trade, then the details of this origination buy trade get populated as a separate queue in the ‘Line Trade – Origination Details’ screen.
  3. Unamortized fee amount, Reserve amount and the contra amount applicable for the Origination desk corresponding to the trade is not fetched to the origination queue for CLP buy trades.
  4. The origination line trade is processed once you confirm these details.

Upon trade settlement authorization, the system does the amortization FEE liquidation to pass the accounting entries for the price differential during the elevation process of the trade. If the CLP commitment is not associated with the relevant Income/expense amortization FEE components, accounting entries are not passed during trade elevation. The amortization FEE adjustments are to be handled manually.

If the new amortization FEE entries are passed during trade settlement authorization, it does not have any impact on the FEE component due to any kind of CLP Buy trade amendments before the settlement.

Any amendment to the Line Origination buy trades resulting in change of position, the original trade is internally be reversed and rebooked for the revised details. Any change in the unamortized fee which is triggered by Buy trades which is leading to the exceptional cases have to be handled manually.

5.9 Trading with PIK Facility

A PIK loan is a type of loan that does not involve any cash flows from the borrower to the lender, between the drawdown date and the maturity date. Trades involving PIK always need to have the quotation method specified as ‘Flat’.

For trades involving the PIK component, the following three scenarios are possible:

If the PIK allocation has already happened before the trade is booked, there is not any separate trade processing for the PIK portion. PIK also is treated as part of normal trade amount.

If the PIK happens in the agency, resulting in a commitment increase, the commitment increase details are handed off to Loans QT with the indication that the increase in the commitment is due to PIK. The commitment increase due to PIK is considered at a prize equal to zero except for origination trades, where it is considered at price equal to 100. Loans QT sends an internal deal to Oracle FLEXCUBE to the extent of the commitment increase and settled position gets updated with the PIK amount. This internal trade is booked and settled immediately in SLT. For a buy deal, the costing details are updated and for a sell deal the PnL entries are updated. For open trades, Loans QT sends trade amendments to the extent of PIK amount. During settlement, the PIK amount is not considered as it is priced at zero.

If the PIK changes in the agency do not result in commitment increase, the existing settled position remains unchanged. For open trades, the funded portion increases by the PIK amount and the unfunded portion decreases by the PIK amount.

Note

5.10 Querying Position Balances

Positions are maintained for each CUSIP for a combination of desk, branch, expense code, and swap Id/settlement party in case of silent participation. The positions get updated when you book a trade and also when any amendment happens to the trade amount or the buy/sell indicator.

A buy deal results in an open position which gets reduced by a subsequent sell of the CUSIP. A short sell results in a negative position. Position for a CUSIP, can be negative due to short sells, before the settlement date. On the actual settlement date a CUSIP cannot have a negative position.

You can view the position balances for a given position identifier in the ‘Position Balances’ screen.

This section contains the following topics:

You can invoke the ‘Position Balance’ screen by typing ‘TLDPOSBL’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.

 

You can specify the following details in this screen:

Position Identifier

Select the position identifier for which you want to view position balances for the associated CUSIP.

Following details related to the CUSIP associated with the position identifier selected, are displayed:

Commitment reduction and PIK amounts are considered for computing settled WAC, at the prices of 100% and zero respectively. The remaining trade amounts are considered at the trade price. The settled WAC is calculated for the net trade amount using the trade price, during trade settlement or reversal of trade settlement. Settled WAC is calculated for all the costing methods (LIFO, FIFO, and WAC) and is applicable for internal trades also.

Note

Settled WAC is not used for any processing in SLT. It is used only for funding activities.

You can get a more detailed view of the balances in the ‘Position Balance Enquiry’ screen. You can invoke the ‘Position Balance Enquiry’ screen by typing ‘TLSPOSBQ’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.

 

In this screen you can specify any of the following search parameters:

Position Identifier

Select the position identifier to be used to query the position balances for the CUSIPs.

Portfolio

Select the portfolio to be used to query the position balances for the CUSIPs.

Position Qualifier

Select the position qualifier to be used to query the position balances for the CUSIPs.

Desk

Select the desk for which you want to query the position balances.

Branch

Select the branch for which you want to query the position balances.

Expense Code

Select the expense code for which you want to query the position balances for the CUSIPs.

SWAP Counterparty

Select the SWAP counterparty of the CUSIP for which you want to query the position balances.

The details related to position balances get displayed, according to the search parameters specified. All records satisfying the values specified get displayed for the combination of position identifier and CUSIP.

Note

Branch, desk, and expense code are defaulted, if you specify a value for portfolio.

5.10.1 Resolving Multiple Portfolio Mapping to a Single Expense Code

In case of multiple portfolio mappings for the same expense code, desk code and branch code combinations, system checks if the position (settled or unsettled) is non-zero for any of the mapped portfolios. If system finds any such portfolio, then it is taken as trade portfolio and further processing is done. However, if no position is found or the position (settled and unsettled) is zero, then system takes the default portfolio and proceed with trade processing.

5.10.2 Updating Positions for Commitment Reductions/ Increases

Commitment reductions can happen during trade amendment either using ‘Draft Trade’ screen or from Loans QT. Commitment reduction can happen in the agency, when there is a re-payment for a non-revolving tranche or when there is a reduction in the tranche amount. Commitment increases also can happen during value dated amendments.

The details of the commitment reductions or increases happening in the agency are handed off to Loans QT. The settled positions for the trade amounts for open trades and inter company sell trades are amended, corresponding to these details that are handed off.

Internal trades are automatically settled in the system. For internal trades created because of commitment reduction, system posts accounting entries during settlement since price is involved for the commitment reduction.

To handle commitment reduction for open position, Loans QT sends trade amendments for each open trade. Each of these commitment reductions will be treated with their respective price to calculate PnL or to update the WAC.

The impact of commitment reduction should be considered in case of reversal and rebook (TCNC + TREV + TBOK) of a trade due to trade amendment. Since each commitment reduction can have different price associated with it, the net commitment reduction amount is considered at an average price for such cancellation and rebook.

As part of trade reversal, system cancels and reverses the events (TCNC + TREV).

Note

In case of commitment reduction for CLP trades, the CR price is always considered as 100 for all the three trades irrespective of the CR price received from LQT.

The following a/c entries will be posted during settlement of internal trade created because of commitment reduction:

For Internal Buy Trade with discounted price

Accounting Role

Amount Tag

Dr/Cr

CUSTOMER (Internal GLs)

UNFND-DIS-BUY

Dr

SLT-PREM-DISC

 

UNFND-DIS-BUY

Cr

For Internal Buy Trade with premium price

Accounting Role

Amount Tag

Dr/Cr

SLT-PREM-DISC

UNFND-PRM-BUY

Dr

 

CUSTOMER (Internal GLs)

UNFND-PRM-BUY

 

Cr

For Internal Sell Trade with discounted price

Accounting Role

Amount Tag

Dr/Cr

SLT-PREM-DISC

UNFND-DIS-SEL

Dr

CUSTOMER (Internal GLs)

UNFND-DIS-SEL

Cr

For Internal Sell Trade with premium price

Accounting Role

Amount Tag

Dr/Cr

CUSTOMER (Internal GLs)

UNFND-PRM-SEL

Dr

SLT-PREM-DISC

UNFND-PRM-SEL

Cr

5.11 Calculating Realized Profit and Loss

Realized PnL is calculated during the booking of a trade as well as during cancellation of a trade. During trade amendment, if there are any changes in the position or price, then also realized PnL is calculated.

The costing method to be used for calculating PnL is derived from the portfolio for which the deal has been booked. The costing methods used can be any of the following:

Realized P&L could result out of either a sale of CUSIP under the same position, or a buy of CUSIP under the same position, if the position is short.

5.11.1 Calculating Realized PnL for Commitment Reductions

When an amendment record comes from Loans QT, a corresponding amendment event gets initiated for the SLT contract also. During amendment the realized PnL entries are not reversed. For the amendment, realized PnL entries are posted for the difference between the initial trade amount and the amended amount.

If the costing method for the portfolio is WAC, it remains unchanged for commitment reductions. The commitment reduction amount is considered at par price for PnL and WAC calculations.

The following example illustrates the computation of realized PnL during commitment reductions:

Example

Let us assume that there is an unsettled buy deal for 100mn, where the costing method used is WAC. If there is a commitment reduction to the extent of 20%, the trade amount is amended to 80mn. PnL entries are posted for a sale of 20mn at par. The PnL is computed by comparing the par price with the price at which the trade was done.

Similarly, if the costing method is WAC and there is an unsettled sell deal for 100mn, in the event of commitment reduction of 20%, the trade amount is amended to 80mn.

PnL entries are posted for a buy of 20mn at par.

5.12 Re-valuating Positions

Revaluation is performed for each open position under a CUSIP against the corresponding position identifier. For each combination of CUSIP and position identifier, the system generates a unique position contract reference number. The revaluation and reserve events along with the related accounting entries are passed for this position reference number.

The revaluation accounting entries are posted for the total position (settled + unsettled) as part of EOD batch program. These accounting entries posted are reversed during the BOD batch for the next working day.

Revaluation is performed using the market price details captured for the CUSIP. If the costing method defined for the portfolio is WAC, the system compares the market price with the WAC for the position. If the costing method is either LIFO or FIFO, then the system compares the trade price with the market price for each deal. A single set of accounting entries are posted for the position contract reference number, netting the revaluation entries for all deals under the CUSIP.

You can view the re-valuation preferences for a position contract in the ‘Position Detail’ screen. You can also view the revaluation accounting entries associated with the contract in this screen.

You can invoke the ‘Position Detail’ screen by typing ‘TLDPOSDT’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.

 

A position contract reference number gets automatically generated when a trade is booked for the first time. This reference number is generated for a combination of the position identifier and CUSIP. In this screen, you can only view the details of position contract and the events. The following details related to position contract are displayed:

The following details are defaulted from portfolio maintenance.

You can view the accounting entries related to revaluation by clicking ‘Events’ in the ‘Position Detail’ screen.

Note

Revaluation for HFS position is done for total position based on HFS cost basis and mar­ket price.

For more details on market price maintenance, refer the section ‘Maintaining Market Price Details’ in this user manual.

5.13 Maintaining CUSIP-Tranche Linkage

You can link a CUSIP to multiple tranches using the ‘CUSIP-Tranche linkage’ screen.

You can invoke the ‘CUSIP-Tranche Linkage’ screen by typing ‘TLDCULNK’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.

 

The system uses the CUSIP-Tranche linkage to accrue DCF for that CUSIP. Note that you can maintain records in this screen only if the box ‘Allow CUSIP/ISIN Swing’ is selected in the ‘Loan Parameters’ screen.

Specify the following details.

CUSIP/ISIN No

Specify the CUSIP for which you want to maintain linked tranche details. The adjoining option list displays all valid CUSIP/ISIN numbers maintained in the system. You can also select the appropriate one from it.

Tranche Details

Specify the following tranche details for the CUSIP/ISIN.

Tranche Ref no

Specify the tranche to which you want to link the CUSIP. The adjoining option list displays all active and liquidated tranches maintained in the system. If the specified CUSIP is linked to both lead and non lead (wrapper) tranches or with only lead tranches, then the option list displays only lead tranches. If the specified CUSIP is linked to non lead (wrapper) tranches, then the option list displays only non lead tranches for which CUSIP amendment has been performed on a tranche contract.

You can also select the appropriate one from it.

Note that you have to maintain the Tranche which is currently associated in the agency for the CUSIP, if the tranche is active.

In addition, you cannot delete a tranche if it is linked to the CUSIP in the agency. The deleted tranche is not considered for DCF calculation.

Start Date

Specify the date from which the tranche should be linked to the CUSIP. This date should lie between the associated tranche value date and maturity date.

End Date

Specify the date until which the tranche should be linked to the CUSIP. This date must be greater than the start date. You should leave this field blank if the Tranche is active. Accrual is done till this date.

Share %

If the dates given for tranches overlap, then you have to provide the share percentage for those tranches. The sum of all share percentages should add up to 100.

If you mention the share percentage for multiple tranches, you should ensure that the start and end dates are the same for all those tranches.

Facility Name

The system displays the facility linked to the specified tranche.

Save the record after entering all details. The record have to be authorized in order to become effective. If an unauthorized record exists for a CUSIP in the ‘CUSIP-Tranche Linkage’ screen, then settlement of trade linked with the CUSIP fails as DCF catch up accrual will happen online during settlement. Such unauthorized maintenance is shown in EOD pending queue and EOD is not allowed until the maintenance is authorized.

Active commitments should be linked to all the self participants under the active tranche which is currently linked to the new CUSIP; otherwise the system does not allow you to save this record.

The system performs position validation for the new CUSIP between agency and trading. Self participant position under the tranche should match with the settled position for the CUSIP, portfolio and expense code combination in trading module. This validation is done for all the self participants associated with the active tranche which is currently linked to the new CUSIP.

You can perform the following operations on this screen only from the Head Office branch:

5.14 Viewing CUSIP-Tranche Linkage Summary

You can view a summary of all CUSIP-Tranche linkage records in the system, using the ‘CUSIP-Tranche Linkage Summary’ screen. You can invoke the ‘CUSIP-Tranche Linkage Summary’ screen by typing ‘TLSCULNK’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.

 

The system displays the following details:

You can query on records by clicking the ‘Advanced Search’ option.

5.15 Capturing Funding Memo Details

Funding memo is and advice sent to the trade counterparty, containing the trade details like counterparty, agency contract details, trade date, global commitment amount, drawdown details, fee details, settlement accounts, and so on.

This section contains the following topics:

You can capture the funding memo details as well as the settlement details in the ‘Trade Settlement/ Funding Memo Generation’ screen. You can invoke the ‘Trade Settlement’ screen by typing ‘TLDSETTL’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.

 

The basic trade details are defaulted in this screen. You can specify the following details here:

Agency Id

Select the Id of the lead agent of the transaction, to whom the assignment fee needs to be sent.

Actual Settlement Date

Specify the date on which the actual settlement of the trade happens. You can also select the date by clicking positioned adjacently.

Assignment Fee Type

The assignment fee type is defaulted from the trade contract. You cannot modify this value.

Assignment Fee Remitter

The assignment fee remitter is defaulted from the trade contract. You can modify it, if required. Select the counterparty that remits the assignment fee to the lead agent. The options available are as follows:

5.15.0.1 Specifying Fee Liquidation Details

You can indicate the fee types that you want to liquidate as part of the trade settlement. All the fee components associated with the trade contract are listed here.

Liquidate

All fee components are selected for liquidation, by default. You can deselect only the broker fee or amendment fee, if required. All other fees need to be liquidated mandatorily during trade settlement.

5.15.0.2 Specifying Funding Memo Details

You can specify the preferences related to funding memo generation, here. You can indicate the following details:

Funding Memo Status

The current status of the funding memo gets displayed here. The following values are possible:

Funding Memo Source

Select the source of the funding memo from the drop-down list. If the CUSIP corresponds to an already existing agency in Oracle FLEXCUBE, you can select any of the following options:

If the agency is not an existing agency in system, you can select the memo source as ‘Manual’ and specify the details manually. For an existing agency, the system defaults this option (manual). In addition, it defaults the tranche and drawdown details in ‘Agency Details Input’ screen based on the following:

The trade equivalent amount of such drawdown is derived based on the formula below:

Refer Agency Capturing details in this chapter

If the CUSIP does not exist, then the memo source gets defaulted to ‘Upload’, and it gets disabled. If the funding memo source is ‘Upload’ then you need to upload the data required for generating the funding memo.

Funding Memo Advice Required

Select this check box to indicate that funding memo needs to be automatically generated during the authorization of FMEM event.

If due to agency activity, any changes happen to the funding memo before trade settlement, then you can regenerate the funding memo. The system marks such trades for regeneration of funding memo and during trade settlement such trades are excluded from settlement.

If the payment message is already generated for the trade based on already existing funding memo, an override message is displayed while you try to regenerate the funding memo. If the payment message is already generated, you cannot modify the selection of fees to liquidate during funding memo re-generation.

You can maintain the static text part of the funding memo using Advice Format under Message Maintenance. The dynamic part in the funding memo advice is populated using the various advice tags.

For more details on advice formats, refer the section ‘Maintaining Advice Formats’ in Messaging user manual.

5.15.1 Specifying Fee Details

You can specify the assignment fee details during ticket settlement in the ‘Assignment Fee Details’ screen. To invoke this screen, click ‘Fee’ in the Ticket Settlement screen.

Assignment Fee Type

The system displays the assignment fee type.

Currency

Specify the currency for which you want to maintain. The adjoining option list displays all the currencies that are maintained in the system. You can select the appropriate one.

Amount

Specify the fee amount.

Buyer’s Split Amount

Specify the buyer’s split amount.

Seller’s Split Amount

Specify the seller’s split amount.

5.15.2 Viewing Funding Memo Details

You can view the funding memo details in ‘Funding Memo Details’ screen, which can be invoked by clicking ‘Funding Memo’ in ‘Trade Settlement/ Funding Memo Generation’ screen. You can also invoke this screen by clicking ‘Funding Memo’ in the SLT Trade Online screen. You cannot make any modifications to the funding memo details if you invoke this screen from the Trade Online screen.

 

System defaults value captured in the ‘Agency Detail Input’ screen here. You can view the following basic details related to the trade contract, which you cannot modify:

Note

For Non-Lead agency contracts, where bank is the buyer of the trade with the external trade counter party, the system will not default the agency details in the ‘Funding Memo Details’ screen even if the details exist in the system. You need to capture the tranche and drawdown details related to such trades.

You can provide fee amount in negative during trade/ticket settlement.

5.15.3 Viewing Pricing Details of Drawdowns

For each drawdown under the tranche, you can view the details related to pricing. If the funding memo source is ‘Agency’, the basic funding memo details including the pricing details are fetched from the agency transactions. Otherwise, you need to provide the funding memo details in a predefined Excel format and upload it to the funding memo screen.

The following details are displayed for each drawdown:

Market Rate

Specify the current market interest rate to calculate the break funding fee.

5.15.4 Viewing Fee Details

You can view the details related to the fee components in the ‘Fee Details’ tab.

You can view the following details here:

Actual Fee Amount

The fee amount calculated by the system gets displayed here also. But you can modify this value, if required.

5.15.5 Viewing DCF Details

Delayed compensation fee is associated with trades for which the trade settlement date exceeds the expected settlement date. You can view the delayed compensation fee details related to a trade in the ‘Delayed Compensation Fee Details’ screen. To invoke this screen, click ‘DCF Details’ in ‘Funding Memo Details’ screen.

 

Delayed compensation fee is calculated for the DCF fee components at the tranche level individually. If the funding happens in different currencies, DCF is displayed for the fee or interest components along with the currency wise break ups.

Note

If the funding memo source is ‘Agency’, the DCF and Break funding fee will be computed based on the underlying agency data. Otherwise, you need to provide these details in a predefined excel format and upload it to the funding memo screen.

5.15.6 Viewing Break Funding Fee Details

You can view the details of the break funding fee in the ‘Break Funding Fee Details’ screen. To invoke this screen, click ‘BFF’ in ‘Funding Memo Details’ screen.

 

The break funding cost for each drawdown main components will be arrived at based on the drawdown base rate and the current market rate that you specified in ‘Funding Memo Details’ main screen.

5.15.7 Viewing Currency-wise Settlement Details

You can view the currency wise settlement details corresponding to a trade contract in the ‘Currency Details’ tab in the ‘Funding Memo Details’ screen. The details populated based on the agency data captured in the ‘Agency Details Input’ screen.

 

In this screen the settlement details corresponding to the different fee components are displayed. If the funding happens in different currencies, the outstanding amount and fee amounts get displayed for the various currencies involved.

5.16 Settling Trades Individually

The following activities take place during the settlement of a trade contract:

You can initiate the settlement of a trade contract in the ‘Trade Settlement Detailed’ screen

Refer the section ‘Capturing Funding Memo Details’ for more details on this screen.

You need to manually initiate the settlement of a trade on, before or after the ‘Expected Settlement date’. You need to specify the ‘Actual Settlement Date’, greater than or equal to the trade booking date.

The settlement of the trade happens as follows:

  1. Funding memo details are extracted and payment messages are generated before the trade settlement.

If the actual settlement date is less than or equal to the system date, funding memo generation, payment message generation and trade settlement happens together. If the actual settlement date is a future date, then funding memo and payment messages are generated in advance and trade settlement happens as part of the BOD batch process on actual settlement date. Payment message can be generated either during trade settlement authorization or during the EOD batch process, depending on the number of settlement days maintained for the combination of branch and currency.

  1. All fee components, except broker and amendment fees are liquidated as part of trade settlement.
  2. Settlement amount is computed as follows:

Settlement Amount = Funded Amount - Original trade amount x (1-price)

  1. In case of multi currency funding, the settlement amount is computed as follows

For the trade currency,

Settlement Amount = F–F*(1-price)–UF*(1-price)–[CR1*(CRP1-price)+CR2*(CRP2-price) +….+ CRn*(CRPn-price)]

Where,

The settlement formula is further derived as follows:

Settlement Amount = F – F* (1-price) – UF * ( 1-price) – Net_CR * (Avg_Cr_Price – price)

Where,

For the other funded currencies,

Settlement Amount = Funded Amount * Price

  1. The difference between the Funded amount and the Settlement amount gets posted to the premium/discount account.

In case of any benefit that needs to be accrued in the event of commitment reduction, BCR (Benefit of commitment reduction) fees will be separately calculated and displayed in the funding memo. But it is not considered for settlement separately. Likewise, the upfront fee calculated and displayed in the funding memo also not considered for settlement separately.

The formula for BCR (Benefit of commitment reduction) fee is computed as follows:

BCR Fee = Net_CR * (Avg_Cr_Price – price)

The formula for the upfront fee is computed as follows:

Upfront Fee = UnFunded Amount * (1-price)

Note

    • Settlement Date can be back-valued but can not be less than the value date of the any agency activity of underlying agency contract.
    • If the Funding memo status is ‘Regenerate FMEM’ due to the agency operations, then you are not allowed to proceed with trade settlement until the funding memo regeneration happens.

5.16.1 Capturing External Counterparty Mnemonic Details

The system enables the ‘Ext Part SSI’ tab for the trade settlement if the trade is of participation sell type and an external counterparty is being added to the tranche as part of settlement. Click this tab to capture counterparty details, currency wise SSI mnemonic and customer entities.

Specify the following details.

Counterparty Details

Specify the following counterparty details.

Tranche Ref No

The system displays the tranche reference number.

CUSIP/ISIN

The system displays the CUSP/ISIN.

Counterparty

The system displays the counterparty number.

Settlement Details

The SSI details are defaulted for the counterparty. However, you can modify them.

Currency

Specify the currency for which you want to maintain SSI mnemonic details. The adjoining option list displays all valid currency codes maintained in the system. You can also select the appropriate one from it.

SSI Mnemonic

Specify the SSI mnemonic value that should be linked to the currency. The adjoining option list displays all valid combinations available for the counterparties and SSI mnemonics maintained in the system. You can also select the appropriate one from it.

Entity Details

The entity details are defaulted for the counterparty. However, you can modify them.

Entity ID

Specify the entity that should be linked to the SSI mnemonic value and currency combination. The adjoining option list displays all entities maintained for the linked counterparty. You can also select the appropriate one from it.

Entity Name

The system displays the name of the specified entity.

Remarks

Specify remarks if any.

Primary Entity

Select this check box to indicate that the entity is a primary entity.

If the trade/ticket settlement for which SSI details are captured is pending processing from LT to LB, and another trade or ticket with the same CUSIP+Counterparty+Currency combination is settled in that interval, the latest SSI details captured will override all the other SSI details captured during the processing.

If settlement is performed to add a new external participant and subsequently if the settlement reversal is performed, the system will retain the SSI/Entity details captured during the settlement and will default the same during subsequent settlements.

5.17 Settling Trades at Ticket Level

A ticket is associated with multiple trades. Every trade contract have a ticket Id corresponding to the ticket to which it belongs. You can settle all trades corresponding to a ticket, together, by means of ticket settlement.

This section contains the following topics:

You can perform the ticket settlement, which takes care of all trades corresponding to the ticket in the ‘Ticket Settlement’ screen. You can invoke the ‘Ticket Settlement’ screen by typing ‘TLDTKSTL’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.

 

You need to specify the following details in this screen:

Ticket Id

Specify the ticket Id for which you want to initiate settlement.

Actual Settlement Date

Specify the date on which the actual settlement should happen for all trades associated with the ticket.

Agency Id

The system displays the agency id.

Note

The agency id is displayed only if you have internally maintained the ‘ASGNFEE_P­MNT_ATTKT’ parameter value as ‘Y’.

If the ‘Agency id’ is not maintained at trade level, then you need to do the following before proceeding with ticket settlement:

If the ‘Agency id’ is maintained at trade level, then the system does the following validations before proceeding with ticket settlement:

Funding Memo Advice Reqd

Select this check box to extract funding memo details or the individual trades under the ticket before settlement processing.

You can suppress funding memo advice generation at the trade level

The following details related to individual trades under the ticket are displayed:

During each trade under a ticket, system extracts the drawdown details if the agency contract exists. The DD amount is the actual DD balance under the Tranche. And if the agency contract does not exist, you can select the funding memo source as “Manual” and specify the Drawdown details for each trade.

Process Status

The status of the trade settlement gets displayed here. The status can be any of the following:

Trade Auth Status

The status of trade authorization is displayed here. The status can be any of the following:

Settlement Status

The actual status of the settlement gets displayed here. The status can be any of the following:

Ticket settlement takes place as follows:

  1. Click ‘FMEMO’ for each trade to invoke the ‘Funding Memo Details’ screen.
  2. Save the ticket settlement details after completing the funding memo generation activity for each trade.
  3. All fee components across the trades under the ticket get displayed in ticket settlement screen. You cannot deselect any of the components during ticket settlement.
  4. Once you save the ticket settlement details, a background job process performs trade settlement for each trade under the ticket.
  5. While settling individual trades under the ticket, system considers only the applicable fees for the trade and liquidates accordingly. Accounting entries are passed at trade level.
  6. You can authorize a ticket settlement only after all the trades under the ticket are settled successfully. You cannot authorize individual trade settlements, if the settlement is done using ticket settlement.
  7. Payment messages are generated during the authorization of the ticket if the settlement date is on or before the system date. If the actual settlement date is in the future, then the payment messages are generated in advance as per currency wise settlement days.
  8. Payment message gets generated for the ticket if the ‘payment message netting required’ option is enabled at branch parameters screen. Else the payment messages will be sent for the trades, independently.

If any of individual trade settlement fails, then ‘Settlement status’ for the trade gets updated as ‘Failed’. Failed trades need to be settled manually using the trade settlement screen.

You can delete ticket settlement details, if required, before it gets authorized. But you cannot perform a reversal for the ticket settlement. However, you can reverse trade settlements for individual trades using the trade settlement screen.

Note

Settlement for a ticket can happen only once. If a ticket has already been settled and a new trade comes from Loans QT with the same ticket Id, it needs to be settled individually. Ticket settlement is not possible in such scenarios.

5.17.1 Viewing Currency Wise Settlement Details in Ticket Settlement

DCF on the drawings/commitment/facility/utilization amount are computed only if the agency contract exists in the system. You have to capture the Agency Details and drawdown details, if the agency does not exist. System computes the DCF only for the DCF-FIX-MARGIN sub component using the Margin rate captured along with the drawdown details.

You can overwrite fee values in the FEE Details Tab for each trade. Market rate is captured for each drawdown to compute the Break funding FEE. After the drawdown details and FEE details are confirmed, system displays the currency wise settlement amount for each trade in the Funding Memo Details screen.

Drawdown details captured in the Agency details input screen can be modified only in the agency input screen. You have to confirm the currency wise settlement amounts for each trade under the ticket. After the confirmation, system displays the currency wise settlement amount for the ticket and you cannot overwrite any amounts at the ticket level. Click Payment details in the ‘Payment details’ button in the ticket settlement screen. The currency wise settlement details are displayed in the ‘consolidated details’ for each counter party individually for each drawdown currency across all the trades under the ticket and payment message related details for each currency counterparty combination.

In case of multi counter party Tickets, system captures the SSI mnemonic for each combination of counter party and currency. The cash flows is consolidated for the combination of Ticket, Counter Party and Currency and payment messages are generated for each of these combinations if they are associated with cash flows. The accounting entries are passed at the trade level for the trade counter party.

Note

The accounting entry should be reconciled with the ticket level payment message manu­ally.

In case of multi counter party tickets, system internally creates separate contract numbers for each counter party and payment messages are generated for these new contract ref numbers. These contract numbers are displayed along with the counter party as Sub Ticket Ref No.

5.17.2 Handling Exceptions during Ticket Settlement

If any exception occurs during funding memo generation, you need to reverse the trade through trade online screen. During authorization of the trade reversal, the trade is removed from ticket settlement list. If all other trades are in ‘FMEM Extracted’ status then the ticket status also gets updated to ‘FMEM Extracted’ and all such trades under the ticket is picked up for further processing.

If any failure happens during the settlement process as background job, you need to settle the failed trades independently, using the trade settlement screen. After successful completion of the trade settlement the ticket status gets updated to ‘Processed’ if all other trades corresponding to the ticket are also in ‘Processed’ status. If you are unable to perform trade settlement from the trade settlement screen, then you need to reverse the trade and then proceed with ticket settlement.

If any failure occurs during authorization of the ticket, you can authorize such trades independently from the trade settlement screen. On successful authorization, the trade authorization status gets updated as ‘Authorized’, and if all other trades are also authorized then ticket authorization status also gets updated as ‘Authorized’.

5.17.3 Viewing Settlement Instructions before Authorization

During ticket settlement authorization, system enforces the authorizer to visit the settlement information to view and verify whether the SSI mnemonic selected is valid and the settlement details of the payment message are appropriate.

For authorizing ticket settlement, click ’Authorize’ button in the ‘Authorization’ (TLDTKSAU) screen.

 

During ticket settlement authorization, based on whether the ‘Payment Message Netting at Ticket Level’ is checked or unchecked at the branch level, you have to visit the settlement information for all the sub ticket reference number available under the trade or the trade reference numbers available under the ticket respectively.

On clicking the ‘Settlement Info’ button, the following screen is invoked:

 

The authorizer is not allowed to proceed with authorization unless the ‘Settlement Information’ screen is visited for each and every trade reference number or sub ticket reference number.

Similarly, during trade settlement authorization too, you are enforced to visit the settlement information screen in order to proceed with the authorization.

5.17.4 Specifying Fee Details

You can specify the assignment fee details during ticket settlement in the ‘Assignment Fee Details’ screen. To invoke this screen, click ‘Fees’ in the Ticket Settlement screen.

 

 

Specify the following details:

Counterparty

Specify the counterparty for which you want to maintain. The adjoining option list displays all the counterparties from all the trades under the ticket. You can select the appropriate one.

Currency

Specify the currency for which you want to maintain. The adjoining option list displays all the currencies that are maintained in the system. You can select the appropriate one.

If the selected currency for a particular trade and counterparty combination can be different from trade currency.

Example

Ticket ID: TIK1

Contract Ref No: TR1 (where trade currency is USD)

Counterparty: C1

Currency: GBP (selected in Fee sub-screen)

The same fee currency cannot be selected more than once for a given counterparty

Example

Consider Ticket ID TIK1 with two underlying trades TR1 and TR2, with the same Counterparty C1 and trade currency USD and GBP respectively

If you want to record two fee records one after the other, the system does not allow the second record to be captured unless a different currency is specified

Example

Ticket ID: TIK1

Contract Ref No: TR1 (where trade currency is USD)

Counterparty: C1

Currency : GBP (selected in Fee sub-screen)

Ticket ID: TIK1

Contract Ref No: TR2 (where trade currency is GBP)

Counterparty: C1

Currency : GBP (selected in Fee sub-screen)

For a combination of counterparty and currency, only one trade is allowed to select for posting Assignment fee currency. For a particular Contract Ref No that is. trade, only a single posting of Assignment Fee is allowed.

Example

Continuing the above example, if user defines a fee record as follows system does not allow Contract Ref No. TR1 to be selected for a subsequent record

Ticket ID: TIK1

Contract Ref No: TR1 (where trade currency is USD)

Counterparty: C1

Currency: USD (selected in Fee sub-screen)

Trade Reference no

Specify the trade reference number for which you want to maintain. The adjoining option list displays the list of trade reference numbers for the selected counterparty under the ticket. You can select the appropriate one.

Assignment fee remitter

The system defaults the value when you select the of trade reference number. However, you can change this value by choosing – Buyer or Seller.

Assignment Fee Type

Select the assignment fee remitter from the adjoining option list. The following are the options that get displayed:

Amount

Specify the fee amount.

Buyer’s Split Amount

You can specify the amount for each counterparty, currency combination.

Seller’s Split Amount

You can specify the amount for each counterparty, currency combination. Whereas if the assignment fee type is Buyer, Seller or SPLIT the following validations need to be followed:

5.17.5 Capturing Currency-wise SSI Mnemonics

You can capture currency-wise SSI mnemonics for the counterparties as well as the agencies involved in trades associated with a ticket in the ‘Ticket SSI Mnemonic’ screen. To invoke this screen, click ‘SSI’ in the Ticket Settlement screen.

 

The following details are displayed in this screen:

You can specify the following details:

Ccy

Select the currency for which you want to maintain the SSI mnemonic, from the option list provided.

SSI Mnemonic

Select the SSI mnemonic to be associated with the currency, from the option list provided.

The details specified in this screen are propagated to all trade contracts associated with the ticket.

Remarks

Specify any additional information about the SSI mnemonics details.

5.17.6 Capturing Mnemonic Details

If there is a participation sell deal trade that is not successfully handed over to the LB module, the system enables the ‘Ext Part SSI’ tab . Click this button to capture counterparty details, currency wise SSI mnemonic and customer entities.

 

Specify the following details.

Counterparty Details

Specify the following counterparty details.

Tranche Ref No

The system displays the tranche reference number.

CUSIP/ISIN

The system displays the CUSP/ISIN.

Counterparty

The system displays the counterparty number.

Settlement Details

The SSI details are defaulted for the counterparty. However, you can modify them.

Currency

Specify the currency for which you want to maintain SSI mnemonic details. The adjoining option list displays all valid currency codes maintained in the system. You can also select the appropriate one from it.

SSI Mnemonic

Specify the SSI mnemonic value that should be linked to the currency. The adjoining option list displays all valid combinations available for the counterparties and SSI mnemonics maintained in the system. You can also select the appropriate one from it.

Entity Details

The entity details are defaulted for the counterparty. However, you can modify them.

Entity ID

Specify the entity that should be linked to the SSI mnemonic value and currency combination. The adjoining option list displays all entities maintained for the linked counterparty. You can also select the appropriate one from it.

Entity Name

The system displays the name of the specified entity.

Remarks

Specify remarks if any.

Primary Entity

Check this box to indicate that the entity is a primary entity.

If the trade/ticket settlement for which SSI details are captured is pending processing from TL to LB, and another trade or ticket with the same CUSIP+Counterparty+Currency combination is settled in that interval, the latest SSI details captured will override all the other SSI details captured during the processing.

If settlement is performed to add a new external participant and subsequently if the settlement reversal is performed, the system retains the SSI/Entity details captured during the settlement and defaults the same during subsequent settlements.

5.18 Settling Combined Tickets

In the combined ticket settlement screen, you can perform the settlement for multiple buy trades and multiple sell trades under one or more tickets with various counterparty and currency combinations across CUSIPs as part of a single transaction. You can process the settlement if the option is selected at the bank level in the ‘Loans Parameters’ screen.

This section contains the following topics:

You can invoke the ‘Combined Ticket Settlement’ screen by typing ‘TLDMTSTL’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.

 

The system generates Consol Ticket Refno for a new combined ticket settlement.

Ticket ID

Select the multiple Ticket Ids for settlement under the generated consolidated ticket reference number.

Actual Settlement date

Specify the actual settlement date for all the tickets/trades settled under generated consolidated ticket reference number.

Payment Msg Suppress

Select the check box to indicate that the payment message should not be generated for each counterparty/agent and currency combination.

The system displays all the active trades under the ticket id selected.

Agency Id

Select the agency id from the adjacent list of agency id maintained in the system. If assignment fee is captured for any trade under a ticket then agency id maintenance is mandatory.

Select?

The check box against each trade for the selected ticket id gets selected for settlement. Deselect this check box to indicate that the trade in ‘Trade Details’ section is not selected for settlement. Deselected trades are allowed to be settled later in the combined ticket settlement screen with a new consol ticket ref no.

At least one trade should be selected for settlement under the generated ticket id, else you have to delete the generated ticket id. You can delete the ticket id before saving the details in the combined ticket settlement screen.

You can view the rest of the details under the Trade Details and Fee Detail section.

5.18.1 Specifying Fee Details

You can specify the assignment fee details during the combined ticket settlement. To invoke this screen, click ‘Fee’ in the Combined Ticket Settlement screen.

 

You can select a trade under which the assignment fee to be settled for the combination of counterparty and currency.

Refer ‘Specifying Fee Details’ section in the current chapter for details in this screen.

Specifying SSI Mnemonics

You can capture currency-wise SSI mnemonics for the counterparties as well as the agencies involved in trades associated with a ticket in the ‘Ticket SSI Mnemonic’ screen. To invoke this screen, click ‘SSI’ in the ‘Combined Ticket Settlement’ screen.

 

Refer ‘capturing currency-wise SSI Mnemonics’ section in the current chapter for details in this screen.

5.18.2 Capturing Mnemonic Details

If there is a participation sell deal trade that is not successfully handed over to the LB module, the system enables the ‘Ext Part SSI’ tab. Click this button to capture SSI details for external participants.

 

Refer ‘capturing currency-wise SSI Mnemonics’ section in the current chapter for details in this screen

5.18.2.1 Saving and Authorising Combined Ticket Settlement

You can save the transaction and after the successful validations applicable for a trade during settlement, a background job assigned for each branch picks up the record and process the settlements. You can authorize the combined ticket settlement once settlement is processed for all the trades selected for settlement across all the tickets under a Consol ticket reference. The authorisation is online for all the trades that are settled as part of combined ticket settlement.

If the settlement is failed for any trade under a consol reference number, the Consol Ticket status is updated as ‘Failed’. Process status is updated as ‘Failed’ for the failed trade. You have to save the settlement for the failed trade in the trade settlement screen. Once the settlement is processed for all the failed trades, Consol Ticket Status is updated as ‘Processed’.

If settlement authorization is failed for any trade under a consol reference number, you cannot authorize the combined ticket settlement. You have to authorize the trade in the trade settlement screen. After the authorization of the all the failed trades, combine ticket settlement can be authorized. Consol Auth Status gets updated as ‘Authorized’ after authorizing combined ticket settlement record. If authorization is failed for any trade during combined ticket settlement authorization then the trade should be authorized in the trade settlement screen.

You cannot delete any record in trade settlement screen when trade settlement processing or trade settlement authorization is failed for the trade in the combined ticket settlement screen. Combined ticket settlement reversal is not allowed. Reversal of trade settlement for individual trades is allowed from the trade settlement screen, after authorizing combined ticket settlement. The trade is allowed to be settled again in the combined ticket settlement screen after the settlement reversal provided all the validations are successful.

Trades under a ticket can be settled partially. For instance, if there are two trades under a ticket id, user can settle one trade first and then user can settle the second trade under the same ticket id later. Combined ticket settlement can be allowed with actual settlement date as back dated or current dated; provided all the existing validations for the actual settlement date is successful. Future dated settlement is not allowed in combined ticket settlement screen.

Below operations are allowed in the above screen:

If multiple buy and sell trades are getting settled under different tickets that belong to same CUSIP, portfolio, and expense code then buy and sell position for the CUSIP, portfolio and expense code is consolidated and is validated with the current Oracle FLEXCUBE position. Consolidation can result into any of the following:

Note: Net position validation for self participant is done against total position in TL. Net position validation for external participant is done against TRANSFER_AVL balance in LB.

Counterparty need not be the same for net position validation. The validation can be applicable for both lead and non lead tranches including desk to desk transfer.

If combined ticket settlement is unauthorized then settlement with the same ticket id which is unauthorized in the combined ticket settlement screen, is not allowed in the existing ticket or trade settlement screen. Combined ticket settlement is not allowed if any ticket is pending for authorization in trade or ticket settlement screen.

You can maintain assignment fee under a consol ticket reference for the combination of agent id, counterparty and currency. The system does not perform any validations if assignment fee is settled multiple times for the same combination of ticket id, counterparty, and currency and it should be operationally controlled.

You can choose a trade under which the assignment fee to be settled for the combination of counterparty and currency, which need not be the trade currency. Appropriate override is displayed if combined ticket settlement is saved without assignment fee details. If assignment fee is captured in multiple currencies for the same agent id/counterparty then SSI should be captured for all the currencies for the agent / counterparty. Assignment fee entries are posted at the trade level for the assignment fee currency.

During combined ticket settlement, if assignment fee is maintained for a trade (driver contract) and the trade settlement fails for the driver contract then, the settlement can be performed in the individual trade settlement screen. SSI should be maintained during trade settlement for the driver

If settlement fails in the trade settlement screen, then user have to delete the combined ticket settlement and will have to perform combined settlement again.

If ‘Allow Combined Ticket Settlement’ is selected then Desk to desk transfer functionality is allowed only from the combined ticket settlement screen and STP is done systematically in LB. Desk to Desk transfer functionality is applicable for both lead and non-Lead tranches. The system considers inter-desk trades as normal SLT trades and accounting entries gets posted based on the maintenance at the product level.

If you don’t want the accounting entries to be posted for desk to desk type of trades then it needs to be handled operationally with appropriate product maintenance

The system performs validation during desk to desk transfer that all the buy trades booked under one of the tickets with particular CUSIP, position identifier and counterparty combination should match with all the sell trades booked under another ticket by flipping position identifier and counterparty compared to buy trades under the same CUSIP.

The sum of all buy trade amounts for a particular CUSIP, position identifier and counterparty combination should match with the sum of all sell trade amounts for the mentioned combination. Multiple CUSIPs are allowed to be settled under a single desk to desk ticket. Position will be updated systematically for each CUSIP individually in LB.

Desk to desk transfer is allowed only from combined ticket settlement screen. Desk to desk transfer is allowed to be clubbed with other SLT trades. However net position validation is done separately for desk to desk trades and SLT trades. Ticket id should be unique for each leg within a desk to desk transfer. Desk to Desk transfer is applicable only between Par and Distress desks. Origination desk and TRS desk are not allowed to be participated in desk to desk transfer. Desk to Desk transfer is applicable only for assignment type of trades.

Net position movement is processed from TL to LB only for the trades settled in combined ticket settlement screen by consolidating the position for the combination of CUSIP and Position identifier/self-participant across one or more tickets. Once ticket(s) is/are settled and authorized system will group all the trades under the ticket(s) based on CUSIP and position identifier.

All the trades settled under the ticket(s) are marked as ’Combined’ in current TL-LB interface browser and the consolidated record is populated in the new TL–LB Consolidated browser. One row is populated for each net position for the combination CUSIP and position identifier with default status as ‘Handoff’.

A job process either PRAM or NPVAMI STP for the net position and update the status as processed else failed with appropriate exception.

If Participation buy and sell trades are settled together under a consol reference number, the Consolidated TL LB browser gets populated with two events; one for buy and another for sell. Process status for participation buy is updated as ‘Manual’ by default in the Consolidated STP browser.

Net position movement is applicable only for Non lead tranches for SLT trades with assignment and participation and for lead and non lead tranches during desk to desk transfer only with assignment. Net position movement is not applicable for Non lead tranches for CLP trades and Lead trances for CLP and SLT.

The message is populated in the forward processing browser with consolidated ticket reference number or consolidated sub ticket reference number. For single message, the payment message gets populated with consolidated ticket reference number and for multiple payment messages, each payment message gets populated with unique reference number.

The system generates the payment messages during the authorization of combined ticket settlement. If the settlement authorization fails for any trade, then you need to perform the authorization in the Trade Settlement screen.

If multiple counterparties exist under a ticket, then:

The Field 72 in the payment messages are populated with the following combination.

‘NETTING + LQT TICKET ID + BORROWER FROM LQT TICKET ID’

Note

During combined ticket settlement, system always sends the settlement acknowledgement message to LQT at the individual trade level irrespective of the flag value in SLT branch parameter screen. Message is sent to LQT only for the trades that are selected for settlement.

5.18.3 Consolidated Interface Browser

The system can process TL LB STP for net position for the combination of CUSIP and position identifier for the trades settled in combined ticket settlement screen. You can invoke the ‘LB Consolidated Interface Detailed’ screen by typing ‘TLDLBCIB’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.

 

The system consolidates the position for the combination of CUSIP and portfolio under the Consol ticket reference and populates one event in the Consolidated TL-LB STP browser. Each row consists of PRAM or NPVAMI details that are processed in LB.

Trade details and participant details are available for each record.

Click ‘Trade Details’ tab to view the trade details that are consolidated across CUSIPs and Tickets.

Click ’Participant Details’ tab to view the participant details for whom the update is required in LB.

All the records are in one of the following processing status:

You can view the exceptions in the ‘Exception’ tab.

5.19 Settling DCF on First-time

On the settlement of the first trade for a first-time buy, following events occur:

  1. Self participant is added to the tranche through a Non pro-rata VAMI (NPVAMI).
  2. NPVAMI is executed on the tranche to reduce the first time buy investor position to zero and to reduce the tranche amount to the trade amount.
  3. NPVAMI on the tranche to reduce the first time buy happens only when the tranche amount is not zero and is equivalent to the first-time buy investor amount before the trade settlement is STPed.

Note

    • If settlement of trade for the first-time buy is prior to some agency activity, like Pro-rata VAMI or Payment, then cascading of NPVAMI happens to the agency activity as well.
    • STP from agency for the first time buy investor is blocked.

Consider the following example:

A Tranche TR1 is created with 10M with first-time buy investor’s participation as 100% on 01-Jan-2011.

Pro-rata VAMI is executed on TR1 for 5M on 15-Jan-2011.

Trade for the first-time buy with 8M is settled on 05-Jan-2011.

This trade results in the following sequence of actions

  1. NPVAMI is executed for 8M through the settlement of trade for the first-time buy.
  2. NPVAMI executes for 10M on the trade settlement date.
  3. As part of cascade of NPVAMI, another NPVAMI for 5M happens for first-time buy participant on 15-Jan-2011.

The net result is that, TR1 remains with 8M as the tranche amount with 0% participation for first-time buy investor and 100% participation for the participant who is added through settlement of trade for the first time buy.

Note

If the ‘Non-Prorata / PIK settlement’ flag is selected during the trade / ticket settlement, and if the existing self participant is not having 100% share, the system restricts the user from proceeding with the settlement. This is as per the existing functionality irrespective of zero tranches and non-zero tranches.

5.20 Reversing Trade Settlement

You can reverse a trade settlement in the by clicking the reversal button in the ‘Trade Settlement/Funding Memo Generation’ screen.

During reversal either of the following actions takes place:

You can regenerate the funding memo and resettle the trade, once the trade settlement is reversed. You need to mandatorily re-generate funding memo before re-settlement.

The accounting entries passed during trade settlement get reversed when you do a reversal of the trade settlement. During trade settlement reversal, an override message gets displayed informing to reverse all the fees that were manually liquidated. No advices are generated during trade settlement reversal.

Note

If any agency activities have happened for the CUSIP after the trade settlement, you can­not reverse that settlement.

5.21 Reversing Trade

You can perform reversal of a trade by clicking the reversal button in the Trade Online screen.

During trade reversal either of the following actions takes place:

No advices are generated during reversal of trade. You are not allowed to perform any activities on a trade, once it gets reversed.

5.22 Calculating Reserve

Reserve allocation or provisioning needs to be done for buy trades that have not been sold for a period that exceeds a pre-defined number of days. Reserve calculation preferences are captured in the ‘Portfolio maintenance’ screen. If the number of days up to which a buy deal remains un-sold exceeds the ‘Reserve Days’ specified, reserve calculation gets activated.

The following maintenances need to be done for the calculation of reserve:

For more details on these maintenances, refer the section ‘Maintaining details specific to SLT module’ in this user manual.

For each buy deal booked in SLT, Oracle FLEXCUBE checks if the difference between the current system date and the trade booking date exceeds the ‘Reserve days’. If it exceeds, then the system computes the reserve as follows:

Reserve = Trade Amount * Bid/Ask Factor * Age Factor

FIFO logic is used to identify trades for which the reserve computation is applicable i.e, buy deals are set off against the sell deals that happen, if any, in a FIFO manner, so that only the remaining buy trades are applicable for reserve calculation.

Reserve calculation happens as part of the EOD batch. For calculating number of days, Calendar days are considered and not working days.

Accounting entries for reserve calculation are posted during month-end as part of RESV event. If the month-end happens to be a holiday, the entries are posted on the previous working date. But the computation will be done for the period including the month-end.

5.23 Reclassification

Reclassification is applicable for Normal and CLP trades. During trade booking, the system checks whether CUSIP exists in the agency module or not. If it does not exist, the trade is marked for reclassification (‘Reclass Required’ is marked as ‘Y’ internally). This validation and marking the trade for re-classification is done only during trade booking

If the flag ‘SLT Borrower Reclass Required’ is checked in the ‘Loans Parameter’ screen and the tranche exists at the time of booking the trade, the system passes accounting entries with tranche borrower as related customer and there is not any reclassification in such cases.

5.23.1 SLT Batch Process for Reclassification

The SLT batch performs the accounting entry reclassification. The system selects the open and liquidated trade contracts that are marked for reclassification.

If the CUSIP for the selected trade exists in Agency and the tranche is active, the system picks up the accounting entries posted till today for the trades where related customer is different from borrower of tranche contract against the accounts where the UDF ‘Trade Reclass Required’ at the chart accounts is marked as ‘Y’ for reclassification in the ‘Chart of Accounts’ screen

Example

Debit account is customer account and Credit account is ledger account that is marked for reclassification, then Credit account alone is reclassified and Debit account is ignored

Note

Reclassification of trading balance is done only once during the life cycle of the trade.

If CUSIP is not available during trade booking, the trade is marked for reclassification. Once the CUSIP becomes available, the balance is reclassed during the same day EOD and subsequent entries are posted with related customer as tranche borrower.

If there is any problem during reclassification in the batch, the exception details are logged in an internal exception table and does not stop the batch program. The value of ‘Reclass Required’ remains as ‘Y’ (internally).

Note

5.24 Agency Confirmation

Agency confirmation is applicable only for trades where bank is the lead agent. The trade settlement details for all trades that have been saved in the Trade settlement or Ticket settlement screen get displayed in the ‘Agency Confirmation’ screen. The agency needs to confirm or reject each trade that appears in this screen.

Agency confirmation always happens at trade level and for ticket settlements, all trades under the ticket should be confirmed by the agency.

You can invoke the ‘Agency Confirmation’ screen by typing ‘TLDAGCON’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.

 

You need to specify the following in this screen:

Ticket Id

Select the ticket Id for which you want to view the trades available for settlement confirmation.

Once you select the Ticket Id, all saved trades pending for settlement are displayed. The following details related to the trades are displayed:

Confirmation Status

Select the confirmation status as ‘Confirm’ to register agency confirmation for the trade or select ‘Reject’ to indicate that you want to reject the settlement for the trade.

The trade settlement gets deleted if the agency does not confirm a trade.

While authorizing trade settlement, the system checks if the trade is confirmed by the agency. If it is confirmed, trade settlement gets authorized. If it is not confirmed or if it is rejected, the system forces you to obtain agency confirmation before proceeding with the authorization.

On authorization of the trade settlement, the trade details are transferred to the agency which in turn initiates participant transfer events corresponding to the trade.

Note

5.25 Amending an SLT Contract

You can amend the details of a trade contract in the ‘Secondary Loan Trading - Draft Trade’ screen. You need to select ‘Modify’ from the menu

You also need to select the contract reference number of the trade contract you want to modify.

Click ‘Ok’ to save the details and display the ‘Secondary Loan Trading – Draft Trade (TLDTDUPL)’ screen.

In this screen, you can make the necessary modifications to the contract details. You need to select Submit option to save the modifications and process the record further.

You can make amendments on a trade, only before the trade gets settled. For trade amendments that happen before trade settlement, if the funding memo is already generated, then the funding memo gets regenerated after the amendment.

For amendments being carried out in Loans QT, any of the following actions can happen in Oracle FLEXCUBE, based on the nature of the amendment:

If the amendment details flow in from Loans QT after trade settlement you need to manually reverse the trade settlement and fee settlements and reprocess the trade amendment.

If the trade amount amendment in Loans QT happens due to commitment reduction/increase or PIK, the new trade amount gets saved as a new version of the trade contract.

The following table lists the fields that can be received as amendment from Loans QT and the corresponding action that takes place in Oracle FLEXCUBE:

Oracle FLEXCUBE Field

Corresponding Loans QT Field

Remarks

Amendment Allowed Through Draft Trade

Oracle FLEXCUBE Process

External Ref No

TradeI

Should come from LQT, However in the absence of the Interface, Users will key in the unique value

NO

Reverse the existing trade and rebook the new trade

Contract Ref No

 

Oracle FLEX­CUBE Gener­ated Ref No

NO

Reverse the existing trade and rebook the new trade

User Ref No

 

User Input Ref No in Oracle FLEXCUBE

NO

Reverse the existing trade and rebook the new trade

Custom Ref No

 

Populated in Oracle FLEX­CUBE

NO

Reverse the existing trade and rebook the new trade

Version

 

Oracle FLEX­CUBE Version

 

 

Ticket ID

TicketI

 

NO

Reverse the existing trade and rebook the new trade

Desk

DeskC

 

NO

Reverse the existing trade and rebook the new trade

Legal Vehicle

LegalVehicleI

 

NO

Reverse the existing trade and rebook the new trade

Expense Code

FirmAcctI

Expense Code

YES

Reverse the existing trade and rebook the new trade

CUSIP

MIAltI/Loan­DealI

 

YES

Reverse the existing trade and rebook the new trade

Position identi­fier

 

 

YES

 

Firm Account Mnemonic

 

 

YES

 

Trade Product

 

Will be popu­lated in Oracle FLEXCUBE

NO

Reverse the existing trade and rebook the new trade

Deal Type

DistributionC

Assignment/Participation

YES

Reverse the existing trade and rebook the new trade

Trade Type

 

TradeTypeC

CUST/ACCM

YES

Cancellation of existing posi­tion and Trade amendment if the trade amended from CUST to ACCM. It Reverse the existing trade and rebook the new trade in case amended from ACCM to CUST.

Buy Sell indica­tor

TransTypeC

Buy or Sell

YES

Cancellation of existing posi­tion and Trade amendment

Counterparty

CptyAcctI

 

YES

Trade Amend­ment

TradeAmount

ProductQty

 

YES

 

Trade Amend­ment

Trade Currency

SettleCurrC

 

YES

 

Cancellation of existing posi­tion and Trade amendment

Trade Price

TradeProdPri­ceA

 

YES

Cancellation of existing posi­tion and Trade amendment

Booking Date

 

Oracle FLEX­CUBE System Date

 No

 

Trade Date

TradeD

 

 YES

Cancellation of existing posi­tion and Trade amendment

Expected Set­tlement Date

ExpectedSet­tleD

 

YES

Trade Amend­ment

Settlement Date

 

Oracle FLEX­CUBE will update it on actual Settle­ment

No

Actual Settle­ment date to be keyed in only during the funding memo generation / Trade settle­ment

BrokerID

SalesID

 

YES

Trade Amend­ment

Broker Fee Rate

 

Rate will be accepted for Brokerage Fee and Line Acco­modation Fees.

YES

Trade Amend­ment or Fee Amendment

Swap ID

 

Details of SWAP upload table is pro­vided later

YES

Cancellation of existing posi­tion and Trade amendment

Fee Type

FeeTypeC

ASSN/LINE. One instance of each fee is allowed. DCF does not come from LQT andit is populated during Trade upload based on the Prod Maintenance

 YES

Trade Amend­ment or Fee Amendment

Assignment Fee Type

Assignment­FeeC

 

YES

Trade Amend­ment or Fee Amendment

Assignment Fee Remitter

 

Needs to come from LQT

YES

Trade Amend­ment

Fee Amount

 

 

YES

Trade Amend­ment or Fee Amendment

Agency ID

 

 

YES

Trade Amend­ment

Quotation

InterestC

FLAT/SWOA. No processing diff b/n FLAT & SWOA except for the DCF applicability

YES

Trade Amend­ment until expected set­tlement date

Settlement Mnemonic details

 

 

YES

Trade Amend­ment

Remarks

Comments

 

YES

Trade Amend­ment

 

The fields with ‘Amendment Allowed Through Draft Trade’ value specified as ‘Yes’ can be amended in the ‘Draft Trade’ screen. For the other fields, you need to reverse the trade and re-book a new trade.

Any amendment which results in the change of position/ PnL/ WAC reverses and rebook the trade and system triggers the following events:

The steps for the amendment of CUSIP/ ISIN and ‘Firm Account Mnemonic’ are as follows:

If the CUSIP/ISIN is changed as part of the amendment, then, system does not automatically trigger the reversal and rebook of trade as the commitment reduction and PIK details for the new CUSIP/ISIN are not available. Therefore, you should apply the commitment reduction and PIK on the new trade through manual amendment.

Note

The following fields are sent as the trade settlement acknowledgement message to Loans QT as a tilde (~) separated list:

Field

Description

TransType

Default value ‘SETTLEMENT’

TransID

LQT Transaction ID

TransActionCode

Default value ‘ORIG’

OrigSys

Default value ‘Oracle FLEXCUBE

DestSys

Default value ‘LQT’

Ticket

LQT Ticket ID

SettledDate

Actual settlement Date

UserID

User ID who settled the trade

UserSettledTimeStamp

Actual settlement Date & Timestamp

FlexSettledFlag

Default value ‘P’

 

TradeI

LQT Trade ID

CUSIP

Internal CUSIP

FundMnemonic

LQT Counterparty mnemonic

5.25.1 Amending of CUSIP/ISIN and Firm Account Mnemonic

When a new trade reference number is created as part of the TBOK event, system does not consider the commitment reduction and PIK amount of the previous version and the new trade is booked with original trade amount. Hence, during CUSIP/ISIN amendment from Loans QT, system validates incoming trade amount with the original trade amount. If these two amounts do not match, system does not process that amendment and the process status is marked as ‘Failed’ in the Loans QT trade browser. You should manually mark this version of amendment as ‘Processed’ in the Loans QT trade browser and send the next version of amendment from Loans QT with the correct trade amount for successful processing.

On successful upload of the amendment from Loan QT, the latest version in the ‘Draft Trade’ screen displays the original trade amount as the trade amount and the commitment reduction and PIK amount as zero.

If the reason for CUSIP/ISIN amendment from loans QT is not ‘ChangeCusipAfterCmtRed’ and the box ‘Amount change allowed during CUSIP\ISIN Amendment’ is checked in the ‘Loans Parameters’ screen, the validation that the trade amount field of the previous CUSIP and New CUSIP should be same will be relaxed.

In such cases, the system proceeds with the CUSIP/ISIN amendment without any failure, even though there is a trade amount mismatch between the previous and new CUSIP/ISIN.

Note

If the CUSIP/ISIN amendment with different amount is received from LoansQT on a trade which is already having commitment reduction/PIK and the amendment reason is not ‘ChangeCusipAfterCmtRed’, the system does not process that amendment and the pro­cess status is marked as ‘Failed’.

However, if you change CUSIP from the ‘Draft Trade’ screen, system displays an override and changes the trade amount to the original trade amount. In addition, the existing commitment reduction & PIK amount is changed to zero.

In this case, the original trade amount is computed as follows:

If the box ‘Apply Cmt Redn/PIK for CUSIP Amendment’ is unchecked in the ‘Draft Trade’ screen and the box ‘Amount change allowed during CUSIP\ISIN Amendment’ is checked in the ‘Loans Parameters’ screen, the validation that trade amount should remain unchanged during CUSIP/ISIN amendment is relaxed.

In such cases, the system proceeds with the CUSIP/ISIN amendment without any failure and accepts a trade amount different than the amount in the previous version.

If the amendment reason from LQT is ‘ChangeCusipAfterCmtRed’, then system carry forwards the commitment reductions and PIK amount to the new trade. LQT sends this reason only during CUSIP amendment for which commitment reduction has already been applied for the trade.

If the new CUSIP does not exist in the agency, then the commitment reduction/PIK is not applied for the new trade even though the amendment reason from LQT is ‘ChangeCusipAfterCmtRed’. In addition, the ‘Apply Cmt Redn/PIK for CUSIP Amendment’ box will be unchecked in the ‘Draft Trade’ and ‘Trade Online’ screens.

If the new CUSIP exists in agency, then system validates whether the following details between the old and new CUSIP are the same:

If any one of the above validation fails, then system does not process the trade amendment and marks the trade as ‘Failed’ in the Loans QT trade browser. However, if the above validations are successful, then system reverses the existing trade and rebooks a new trade by changing the CUSIP.

System always takes the processed commitment reduction/PIK amount from agency for the old and new CUSIPs and arrives at the net commitment reduction amount/PIK by summing it all. System takes the participant share for each commitment reduction/PIK and arrives at the net commitment reduction/PIK amount. Similarly, system also computes the average reduction price by taking the commitment reduction/PIK price for the old and new CUSIPs from the processed handoffs to LQT and compares the arrived average prices.

System does not process CUSIP amendment from Loans QT if commitment reduction or PIK does not exist for the old trade, though the reason code is valid. The trade is as ‘Failed’ in the Loans QT trade browser. If any trade with CUSIP amendment fails, then you can manually correct the required details to match the validations and reprocess the amendment.

Commitment Reduction/PIK is re-applied from old trade to the new trade based on the following steps:

The above validations are based on the commitment reduction/PIK in the agency for the old and new CUSIPs where as the application of commitment reduction/PIK to the new trade in SLT is based on the commitment reduction/PIK amount of the old SLT trade.

This above process is also followed during manual amendment in ‘Draft Trade screen’ if:

Trade amendment is for changing the Buy/Sell indicator.

Note

Within a CUSIP, only one expense code can be used for a portfolio.

Any amendment to the firm account mnemonic through LQT upload may result in change of expense code, portfolio, position identifier, and so on. When the firm account mnemonic is amended through LQT upload, the expense code, portfolio, position identifier, and so on are resolved and the respective values as per the changed firm account mnemonic are displayed in the latest version of the trade.

You can change the firm account mnemonic in the ‘Draft Upload’ screen by selecting a value from the adjoining option list, which displays only the firm account mnemonics linked to the selected expense code. While amending the expense code, if there is only one firm account mnemonic linked to it, then system defaults that firm account mnemonic. However, if multiple firm account mnemonics are linked, system gives an override message to select the appropriate firm account mnemonic. Also, the draft trade is not processed if the firm account mnemonic is not selected.

5.25.1.1 Amending Buy/Sell Indicator during Loans QT Upload

Any amendment of a trade from Sell to Buy or vice versa results in a PNL/WAC change. Therefore, system reverses the existing trade and books a new trade by changing the Buy/Sell indicator.

System triggers the following events while amending CUSIP/Buy-Sell indicator:

This process is applicable even when you manually amend the Buy/Sell indicator in the ‘Draft Trade’ screen. Since amendment of the Buy/Sell indicator is stand-alone, system does not all amending other trade details along with the Buy/Sell indicator amendment. This is applicable for both Loans QT and manual trade amendment.

Note

You must amend only the buy-sell indicator. However, if you try to amend other details along with the buy-sell indicator, then the trade fails on save.

5.25.1.2 Amending Rejected Trades from Loans QT

You can successfully amend the previous latest version of the trade rejected in the Loans QT from the Loans QT trade browser when the trade is still in active status. However, no amendment is allowed for reversed and settled trades.

5.26 Processing Silent Participation

There are two possible ways in which a trade deal can be carried out. Assignment deals where bank is directly involved in the trade and silent participation deals where bank is not directly involved in a trade deal. In participation deals, bank silently participates in the trade deal.

Participations can belong to either of the following two types:

Deals involving a silent participant also flow in from SLT like other normal buy/sell deals with the only difference being in the deal type, which changes to ‘Participation’. In the LB module, the detail of each silent participant is captured and a corresponding participant contract is created.

This section contains the following topics:

5.26.1 Processing Sell Participation

The following example illustrates how sell participation deals are handled in SLT.

Example

Let us assume a tranche contract of $1bn. Let there be a drawdown of 200mn.

Let the participant contributions for the tranche and drawdown be as follows:

Participant Contributions:

Participant

Participant %

Tranche Amount

Drawdown Amount

Desk1

20%

200mn

400T

Desk2

30%

300mn

600T

External Participant

50%

500mn

1mn

Assume that bank makes sell deals to three silent participants as shown below:

 

This silent sell deals get reflected in the LB module as follows:

 

Participant

Participation %

Tranche Amount

Drawdown Amount

Desk1

8%

80mn

160T

SP1

8%

80mn

160T

SP2

4%

40mn

80T

Desk2

24%

240mn

480T

SP3

6%

60mn

120T

External Participant

 

50%

500mn

1mn

Assuming that bank is the agent, the counterparties SP1, SP2, and SP3 are added as participants in the contract with ‘silent participant’ tags. Settlements from the agent to the silent participants are handled in the same way as handling normal participants.

5.26.1.1 Elevating Sell Participation - Bank as Lead agent

Elevation is the process where a silent participant becomes a normal participant in a trade with the agency. The following steps are involved in the elevation of a silent sell participant to normal status:

  1. Loans QT send the trade amendment for elevation from ‘Participation’ to ‘Assignment’.
  2. The system considers this amendment as an exception and initiates the trade cancellation event, to cancel the participation positions.
  3. Amendment of the trade happens for changing the deal type, followed by the elevation event which marks the elevation of the trade. If the bank as Lead agent, the trade elevation event for the origination line trade is handed off to LB module.
  4. The system, internally, books assignment type of sell deals with the counterparties involved. Funding memo or trade settlements are not applicable for such trades.

You cannot perform any further operations on these trades.

If the bank is Lead agent, as part of agency handoff, the Silent participant position is reduced to the extent of the sell Participation amount and actual external party are added to the main agency contract. PRAM is triggered to indicate the participant transfer between the silent participant and the actual external participant.

If the bank is non - lead agent, on elevation of Participation trade, a negative NPVAMI will be triggered on non - lead agency wrapper contract to the extent of the participant position and the participant pro-rata share are changed.

5.26.2 Processing Buy Participation

The processing of participation buy deals can be illustrated as follows:

Example continued

Continuing on the previous example, let us assume that bank buys participation from the external participants as shown below:

 

The SLT position and the agency activities need to be tracked independently for the normal participation and silent participation.

In the LB module the normal and silent participations are handles as follows:

Normal participation: Tranche 1, Drawdown 1

Participant

Participation %

Tranche Amount

Drawdown Amount

Desk1

20%

200mn

400T

Desk2

30%

300mn

600T

External Participant

50%

500mn

1mn

Silent Participation for Desk1 and Desk3: Tranche2, Drawdown 2

 

Participant

Participation %

 

Tranche Amount

Drawdown Amount

Desk1

25%

100mn

200T

Desk3

75%

300mn

600T

Two sets of LB transactions take place, in this case, as given below:

5.26.2.1 Elevating Buy Participation

The following steps are involved in the elevation of a silent buy participant to normal status:

  1. Loans QT send the trade amendment for elevation from ‘Participation’ to ‘Assignment’.
  2. The system considers this amendment as an exception and initiates the trade cancellation event, to cancel the participation positions.
  3. Amendment of the trade happens for changing the deal type, followed by the elevation event which marks the elevation of the trade.
  4. The system, internally, books assignment type of buy deals with the counterparties involved. Funding memo or trade settlements will not be applicable for such trades.

You cannot perform any further operations on these trades.

If bank buys participation from different counterparties, you need to create separate LB contracts (tranche/drawdown) for all counterparties representing bank participation. Any agency activity involved with the borrower needs to be performed for each of these LB contracts separately.

Multiple tranches can be created with the same CUSIP to support this activity. But there can be only one tranche for each CUSIP and settlement party combination.

5.27 Processing Swap Deals

A swap is an agreement between two parties to exchange sequences of cash flows for a set period of time. Total return swap is a swap agreement in which one party makes payments based on a set rate, either fixed or variable, while the other party makes payments based on the return of an underlying asset, which includes both the income it generates and any capital gains.

The following diagram illustrates the booking of a swap contract in SLT:

 

You can capture the trade details for swap trade also in the ‘Draft Trade’ screen, like normal trade deals. The Swap details for the trade can be captured in the ‘Draft Swap Details’ screen, which can be invoked by clicking ‘Swap’ in the Draft Trade screen.

The following details related to the trade contract are defaulted in this screen:

You can specify the following details in this screen:

Swap Id

Specify the Swap Id to be used to generate the swap contract.

Swap Counterparty

Specify the counterparty associated with the swap trade being performed.

Amount

Specify the amount associated with the swap trade.

The sum of the amounts allocated for all swap trades should be equal to the total trade amount.

Oasys Id

For swap trades originating in Loans QT, Oasys Id associated with the trade gets uploaded from Loans QT. For swap trades that are being captured in SLT, you need to specify the Oasys Id to be associated with the trade.

Swap Reference No.

The system automatically creates contracts for the Swap Ids specified here. The contract reference numbers of these swap level contracts get displayed here.

Like normal contracts, you can view the swap trade contract details also in the ‘Trade Online’ screen.

You can only view the details of the swap contract in this screen. The Parent reference number in this screen refers to the parent trade contract associated with this swap contract. System also defaults the Markit details (Trade Id and Allocation Id) in this screen.

During upload of data from Loans QT, the system checks if the corresponding desk is a Swap desk. If the desk is of ‘Swap’ type then during booking as well as amendment of the contract, either the complete swap details need to be sent or no swap details should be sent. You cannot send the swap details partially.

If no swap details are sent initially, the system uses ‘UNIDENTIFIED’ as the default swap Id with 100% allocation and tracks the position under this swap Id. The actual swap contracts are created under the parent trade, when the allocation details are sent by Loans QT.

The processing of swap trade contracts is carried out in a similar way as normal trades, except that most of the activities are performed at the parent trade contract level. The corresponding accounting entries are passed on, appropriately, to the swap contracts involved. All accounting entries corresponding to swap trades are posted at the swap Id level.

The major changes in the processing of swap trade deals are listed below:

For swap deals, each combination of branch, desk, expense code, and swap Id is represented as a participant in Oracle FLEXCUBE. If the ‘Auto-generate Position Identifier’ option is enabled for the portfolio, position identifier is automatically generated for every instance of swap Id and portfolio combination, during upload of swap trade details.

5.27.1 Exchanging Information between SLT and LB modules

During settlement of the trade in SLT module, the details are handed-off to the LB module. In the LB module, any of the following processing can happen, depending on the availability of the swap details in LB:

Note

For each combination of branch, desk, expense code, and swap Id, you need to maintain an asset in the Loans module.

5.28 Forward Processing of Events

You can view the details of contracts marked for forward processing through the ‘Payment Browser’ screen. You can invoke the ‘Payment Browser’ screen by typing ‘LBDFWDPR’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.

 

Note

To carry out forward processing on an event, you have to select the Rollover Mode, Liq­uidation Mode and Initiation Mode as ‘Semi-Auto’ for tranche and drawdown. Similarly, for forward processing of fee components, the fee liquidation mode should be ‘Semi-Auto’ (in the ‘Fee Components’ sub-screen of the ‘LB Tranche Contract Online’ screen and the ‘Drawdown Contract Online’ screen). The processing for the events ROLL, LIQD, INIT, and FLIQ are processed semi-automatically.

Click the ‘View’ button to view the message that is sent out.

The system sends out a message depending on when the confirmation received from you. This is explained in the example given below:

Example

The following are the details of a contract booked:

Booking Date - 1st July 2005

Value Date – 5th July 2005

Currency – USD

Settlement Days – 2 days

If you confirm on the 1st or 2nd of July that the message needs to be generated, the message is sent on the 3rd of July (BOD).

If you confirm on the 3rd, 4th or 5th of July that the message needs to be generated, the message is released from the ‘Outgoing Message Browser’ immediately.

If you do not confirm before the 5th of July EOD that the message needs to be generated, the accounting entries are passed for the event, and the message is held in the Outgoing Message Browser.

This section contains the following topics:

5.28.1 Fetching the Contracts for Forward Processing

In this screen, you can filter the contracts required for forward processing based on the following parameters:

Date Range

The ‘From and ‘To’ dates consider Archive days and Limit days for forward processing. These dates will be automatically calculated by the system based on the application date considering the ‘Limit Days’ and ‘Archive Days’ maintained as part of branch parameters (in the ‘Syndication Loans and Commitments – Branch Parameters’ screen).

For more details on maintaining branch parameters, refer the heading titled ‘Indicating branch parameters for loan syndication’ in the ‘Reference Information for Loan Syndication’ chapter of this User Manual.

Processed Status

You can also filter the required contracts based on a processing status of the contracts. The available options are:

In Payment Browser Summary (LBSFWDPR) screen, after specifying the filter criteria, click the ‘Refresh’ from menu to fetch the contracts. The following details will be displayed in the screen:

5.28.2 Confirming the Generation of Messages for an Event

From the filtered contracts, you have to select the contracts that need to be processed. To do this, check the ‘Confirmed to Auto’ option against the respective events. This confirms that the messages for the selected events under the contract should be generated on the schedule date. However, the system does not automatically generate the messages on the schedule date. You have to manually confirm the events to generate the messages in the ‘Outgoing Message Browser’.

In the Payment Browser Summary (LBSFWDPR) screen, when you double-click the contracts the screen ‘Message Generated for the Event’ is displayed.

Click the ‘Save’ from the menu of the screen to confirm that the messages should be generated. When you save the details, the ‘Confirm’ option (in the screen above) is automatically checked.

Click the ‘Ok’ button to proceed. The messages associated with the event is released into the ‘Outgoing Message Browser’ and the ‘Hold’ status is set to ‘N’ (No). This indicates that the messages have been released successfully and are no longer on hold.

For more details on the ‘Outgoing Message Browser’, refer the ‘Processing Outgoing Messages’ chapter of the MS (Messaging System) User Manual.

5.28.3 Processing Contracts For Secondary Loan Trading

If you have selected the ‘Payment Browser’ preference as part of the preferences for the branch for secondary loan trading (in the ‘Secondary Loan Trading – Branch Parameters’ screen), then the system processes the payments meant for trading through the ‘Payment Browser’ screen. The payments that are processed through this browser are:

The system displays details of a trade/ticket settlement or pay/rec liquidation only if authorization has been done for these. In case of a trade/ticket settlement, the system displays the reference number of the respective trade or ticket. In case of a multi-customer multi-currency trade, the system displays the respective sub-ticket.

For Pay/Rec liquidation, the system displays the reference number of the Funds Transfer contract that has been created for the liquidation.

If a reversal or rebooking is done after the trade (or ticket) settlement, the new message is displayed in the Payment Browser.

As part of the settlement reversal authorisation, the message generated as part of settlement is ‘Cancelled’ if it is not handed off. In addition, system does not generate any message during settlement reversal. If the message for the settlement is handed off, the system allows settlement reversal.