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/ClearPar Details

Trade ID

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

Note

If LQT trade that is received for trade booking (TBOK) is in ‘Failed’ /‘ Enrich’ / ‘Extracted’ status then you are not allowed to input (if ClearPar trade ID is blank) or override (if Clear­Par trade ID is not blank) the ClearPar trade ID value in 'Draft Trade' screen while process­ing such trades.

You are allowed to input the ClearPar trade ID in 'Draft Trade' screen when trade is man­ually booked (TBOK) in Oracle Banking Corporate Lending.

The maximum length for ClearPar trade ID is 25.

Trade booking or amendment fails in LQT trade browser if LQT sends ClearPar trade ID with special characters. You have to reject and resend the trade from LQT with corrected ClearPar trade ID.

You cannot save trade in draft trade screen (manual TBOK) with special characters in Markit /ClearPar trade ID.

Note: Blank space is allowed in ClearPar trade ID. If more than one ClearPar trade ID is associated with a trade then those can be separated by a blank space.

You cannot amend ClearPar trade ID during trade amendment (TAMD) processing. How­ever, Oracle Banking Corporate Lending updates the trade systematically with the new ClearPar trade ID during trade amendment when LQT sends the revised value.

If a trade amendment leads to reversal and rebook, then the new trade is updated with the ClearPar trade ID from the old (reversed) trade

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.

Primary Trade

If the ‘Primary Trade’ is selected, the system identifies the trade as a primary trade.

The value of the ‘Primary Trade’ check box is defaulted from the 'Draft Trade Input' screen. For the trades booked from LQT, the value of the ‘Primary Trade’ is defaulted from the value of the field ‘Primary Trade’ from LQT.

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;

 

Trade Standard

The following are the list of values in the ‘Trade Standard’ drop-down list.

This field is only a display-only field and the value is defaulted while processing the feed from LQT.

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.

Apply Fin Centre Holiday Currency

This check box allows you to enable financial centre holiday treatment and add the financial centres for the holiday treatment.

For more information about maintaining financial centre for holiday treatment refer to Products User Manual.

 

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.1.7 Financial Centre Holiday Treatment

Click ‘Financial Centre’ tab in ‘Trade Online’ screen to open ‘Financial Centres for Trade Expected Settle date’ screen.

 

Financial center maintained at product level is defaulted in ‘Draft Trade’ (TLDTDUPL) screen. If required, you can add or remove the financial center.

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.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 Summary’ screen by typing ‘TLSTDUPL’ 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 Capturing swap Details

Once the trade contract is authorized, Oracle Banking Corporate Lending spawns Swap contracts for each of the swap ID, Quantity captured in the Trade Online screen.

Once the Swap contracts are created for each swap ID allocation, Oracle Banking Corporate Lending creates/updates Unsettled position for the Branch (Legal Entity), Desk code, Expense code, and swap ID combination.

The Swap contract screen can be used for only viewing the individual swap ID deals. No operations can be performed from this screen.While the aggregate of Amendment, Assignment, Brokerage, and Delayed Compensation Fees can be viewed from the ‘Trade Online’ screen. The contribution/distribution of the same across the various swap contracts can be viewed from the ‘Swap Details’ screen.

Settlement of the Swap Trade needs to be triggered from the ‘Trade Settlement’ screen.

 

The trade details are defaulted from the SLT contract.

Swap Details

Swap ID

Swap ID to be entered by the user.

Swap Counterparty

Counterparty corresponding to the swap ID.

Amount

Trade amount for the swap ID. The sum of trade amount for all swap ID should be equal to the total trade amount.

OASYS ID

OASYS ID to be entered by the user.

Swap Reference Number

The system creates trade contract for each of the swap IDs. The contract ref no of the swap level trade contract is displayed here.

5.5.2 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.2.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.2 Viewing Amendment Fee History

From ‘Fee Components’ screen, click ‘Amendment Fee Details’ button to open ‘Amendment Fee History ‘screen. You can use this screen to only view ‘Amendment Fee History ‘ screen.

  1. You are not allowed to modify the amendment fee in the ‘TL Fee Amendment’ (TLDFEAMD) screen for both active and settled trades.
  2. Amendment fee component is not displayed in the ‘TL Fee Amendment’ screen
  3. You are allowed to capture/amend/waive fee in the ‘TL Fee Amendment’ screen for the remaining components

5.5.2.3 Other Trade Processing Changes for Fees

1. Amendment fee is applied systematically on a new trade when the trade is booked from LQT or manually in Oracle Banking Corporate Lending or when the trade is booked as part of trade amendment resulting in trade reversal and rebook.

 

2. Amendment fee is applied systematically on new trades when below mentioned conditions are met.

  1. Oracle Banking Corporate Lending applies amendment fee systematically for new trades as explained below

Example:-

 

Maintenance exists for CUSIP 1 as below

Amendment Date

Fee Rate

Waive

10-May-2015

0.4%

Yes

1-Jun-2015

0.3%

No

1-Jul-2015

0.2%

No

Scenario 1:- New trade is booked with CUSIP1

Trade Date

10-May-2015

Trade Amount

200,000.00

 

Record will be populated for the new trade in amendment fee input screen as below

Amendment Date

Fee Rate

Waive

Fee Amount

10-May-2015

0.4%

No

800.00

1-Jun-2015

0.3%

No

600.00

1-Jul-2015

0.2%

No

400.00

Amendment fee amount for the new trade is 1,800.00

Scenario 2:- New trade is booked with CUSIP1 due to trade amendment

Trade Date

10-May-2015

Trade Amount

200,000.00

Record will be populated for the new trade in ‘Amendment Fee Input’ screen as below

Amendment Date

Fee Rate

Waive

Fee Amount

10-May-2015

0.4%

Yes

800.00

1-Jun-2015

0.3%

No

600.00

1-Jul-2015

0.2%

No

400.00

Amendment fee amount for the new trade will be 1000.00

  1. Once the trade is booked, you are allowed to waive or un-waive the trade record for a specific amendment date in the ‘Amendment Fee Input’ screen
  2. Amendment fee is systematically applied as explained above for the trades booked with Par, Distress and Origination desks.
  3. There is no change in amendment fee for the existing trades (trades booked prior to this enhancement). Existing trades are impacted only in the below mentioned scenarios.

5.5.3 Specifying Settlements Details

For information on settlement details, refer to ‘Processing Settlements’ topic in Settlements User Manual.

5.5.4 Specifying MIS Details

To invoke the MIS details screen for a contract, click on the ‘MIS’ button.

 

For a contract, the transaction type of MIS class, the cost code and pool code are picked up from the product under which the contract is processed. The composite MIS code is picked up from the definition made for the customer, on behalf of whom the contract is being processed.

The interest calculation method for the refinancing rates of the pool is picked up default from Pool Codes maintenance.These can be changed. For an account, the transaction type of MIS class is picked up from the account class, along with the cost codes and pool codes. The composite type of MIS class is defaulted from those defined for the customer. These too can be changed.

5.5.5 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.5.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.5.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.6 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.7 Maintaining Events

A contract goes through different stages in its life cycle. In Oracle Banking Corporate Lending, the different stages a contract passes through in its life cycle are referred to as ‘Events‘.

At an event, typically, you would want to post the accounting entries to the appropriate account heads and generate the required advices.

For more information on events, refer to ‘Maintaining Details Specific to SLT’ topic in Bilateral Loans User Manual.

5.5.8 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.9 Financial Centre Holiday Treatment

Click ‘Financial Centre’ tab in ‘Trade Online’ screen to open ‘Financial Centres for Trade Expected Settle date’ screen.

 

Financial center maintained at trade draft level is displayed in ‘Trade Online’ (TLDTDONL) screen.

5.5.10 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.5.11 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

Alternative Risk-Free Rates Preferences

The options of ‘Alternative Risk-Free Rates Preferences’ are defaulted from 'Loans Syndication – Borrower Product Definition’ (LBDPRMNT). If required, you can modify it.

For more information on ‘Alternative Risk-Free Rates Preferences’ fields, refer to Interest User Manual.

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 Banking Corporate Lending, 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 Banking Corporate Lending, 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 Banking Corporate Lending 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.

Note

ClearPar trade ID is view only during trade settlement. Oracle Banking Corporate Lending does not perform any validations (except special character validation) for the ClearPar trade ID value during trade booking and trade amendment.

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 mandatory 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 Banking Corporate Lending, 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.

Or

You can invoke the ‘Funding Memo’ screen by typing ‘TLCFMEMO’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.

 


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.

 

Note

The ‘Interest Details’ gets defaulted from ‘Manual Funding Memo’. You cannot modify the details, you can only view the details. For more information on ‘Alternative Risk-Free Rates Preferences’, refer to Interest User Manual.

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

5.15.2.1 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.2.2 Specifying LOR Adjustments

LOR (Lender Of Record) Adjustments

In ‘LOR Adjustment’ section displays the till date accrual amount between the last liquidation date and settlement date component-wise for the funded amount portion for all to the drawdowns.

Manual LOR Adjustments

You can provide interest manually in specific cases (All types of Buy trade) and one Sell trade where deal type is assignment and agency is non lead. The settlement of interest is optional during any type of trade settlement (Trade/Ticket/Combined Ticket).

For information on accounting entries, refer to 'LOR Accounting Entries' section.

5.15.2.3 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.2.4 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.3 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.4 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.

 

The below details are displayed for each sub-ticket reference number.

The below details are displayed for each currency when more than one currency is associated with the ticket/combined ticket settlement.

During ticket settlement authorization, based on whether the ‘Pmt Msg Netting at Ticket Level’ is checked or unchecked at the branch level in Secondary Loan Trading - Branch Parameters Maintenance (TLDBRPRM), 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 Specifying Payment Details

For information on payment details, refer to ‘Processing Fee Details’ chapter in this User Manual.

5.17.6 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.7 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

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 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.17.8 Field 72 Population in Wire Messages

  1. If the SSI mnemonic of the trade counterparty already contains field 72 details, the existing details are retained and the below information is added in the next available free line in the wire messages.
  2. If the length of the line exceeds 35 characters after concatenating the below, then only the first 35 characters are populated.

Note

If there are no free lines in the already existing field 72 details, then the below information is not added.

  1. If the SSI mnemonic does not have field 72 details, the system adds the below information in line 1 of field 72 in the wire messages.
  2. If the length of the line 1 of field 72 exceeds 35 characters after concatenating the below, then line 1 of field 72 displays only the first 35 characters.

This functionality is application for Trade, Ticket, Combined Ticket, and Automated Settlement.

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 Authorizing 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 authorization is online for all the trades that are settled as part of combined ticket settlement.

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

 

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 Banking Corporate Lending 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 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 is 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 tranches 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.18.4 Specifying options in Loan Parameters screen

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

ClearPar TradeID in Field72

By default, ‘ClearPar TradeID in Field72’ check box is not selected in ‘Loan Parameters’ screen.

 

Auto Confirm Messages

 

Automate Ticket Settlement

The ‘Automate Ticket Settlement’ check box is selected by default. If required you can clear this check box.If the new flag ‘Automate Ticket Settlement’ is selected, then the system automates the trade settlement process. The system processes only the effective ‘Settlement Details Notice’ (SDN) where the tag value is ‘True’ for the tag list ‘is Effective’ received from Markit. If the tag value is ‘False’, the system does not process the SDN message.

The other notices mentioned below which are received from Markit are not processed.

If the ‘Automate Ticket Settlement’ check box is cleared, that is, system processes all the notices received from Markit mentioned above and you have to manually initiate trade settlement after the trade closed notice is received.

The system processes ‘Combined Ticket Settlement’ as part of automated settlement based on trade ID, allocation ID and multi CUSIP combination. Refer the below table for processing based on multiple CUSIPs

SDN Message

Markit / ClearPar
Trade ID

Allocation ID

CUSIP

Consolidated Ticket Settlement Reference

OBCL Trade Reference

MSG01

TR1

TR1001

A

ABC

FC01

MSG01

TR1

TR1001

B

ABC

FC02

MSG01

TR1

TR1001

C

ABC

FC03

MSG02

TR2

TR1002

X

XYZ

FC04

MSG02

TR2

TR1002

Y

XYZ

FC05

MSG02

TR2

TR1002

Z

XYZ

FC06

If there are multiple CUSIPs present in the SDN message and the validations fails for one of the CUSIPs, the confirmation status is updated as ‘Unconfirmed’ only for the failed CUSIP. The confirmation status for the other valid records within the same SDN message is updated as ‘Confirmed’ but systematic settlement is not processed for the same. Refer the below table for the details on processing multiple CUSIPs within the same SDN message with respect to confirmation status.

Trade ID

Allocation ID

CUSIP

Consolidated Ticket Settlement Reference

Confirmation Status

Processing in OBCL

Threshold
Validation

Error Message

‘Auto Confirm Messages’ check box not selected

TR1

001

A

XYZ1

Uncon­firmed

Settle­ment is not pro­cessed

Suc­cessful

N/A

TR1

001

B

XYZ1

Uncon­firmed

Settle­ment is not pro­cessed

Failed

Error details of
threshold validation

TR1

001

C

XYZ1

Uncon­firmed

Settle­ment is not pro­cessed

Failed

Error details of
trade price mis­match

‘Auto Confirm Messages’ - Check box selected

TR1

001

A

XYZ1

Confirmed

Settle­ment is not pro­cessed

Suc­cessful

N/A

TR1

001

B

XYZ1

Uncon­firmed

Settle­ment is not pro­cessed

Failed

Error details of
threshold validation

TR1

001

C

XYZ1

Uncon­firmed

Settle­ment is not pro­cessed

Failed

Error details of
trade price mis­match

‘Auto Confirm Messages’ - Check box selected

TR1

001

A

XYZ1

Confirmed

Settle­ment is pro­cessed

Suc­cessful

N/A

TR1

001

B

XYZ1

Confirmed

Settle­ment is pro­cessed

Suc­cessful

N/A

TR1

001

C

XYZ1

Confirmed

Settle­ment is pro­cessed

Suc­cessful

N/A

5.18.5 Auto Creation of New Mnemonics

 

The system tries to match the incoming effective SDN with existing settlement instructions available in Corporate Lending as below.

The system validates the following fields even for NULL values.

System tries to match the SDN field with the Corporate Lending fields in the below order of preference under two levels.

Level 1:

Order

Primary SDN Tag

Secondary SDN Tag

OBCL Field

1

<qfn:correspondentInforma­tion>

<qfn:abaNumber>

F56 or F57

2

<qfn:correspondentInforma­tion>

<qfn:swift>

F56 or F57

3

<qfn:intermediaryInforma­tion>

<qfn:swift>

F56 or F57

Level 2:

Order

Primary SDN Tag

Secondary SDN Tag

OBCL Field

1

<qfn:beneficiaryInformation>

<qfn:accountNum­ber>

F58 or F59

2

<qfn:beneficiaryInformation>

<qfn:iban>

F58 or F59

3

<qfn:forFurtherCredit>

 

F58, F59, or F72

5.19 Specifying Adjustment Rate

Margin paid by the participant to the sub-participant may be less or more whichever is applicable to the tranche. It can have both positive and negative value.

The rate given in 'Secondary Loan Trading – Draft Trade (TLDTDUPL)’ can be viewed in 'Trade-Online', 'Ticket Settlement', and 'Combined Ticket Settlement' screens.

5.20 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.21 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.22 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.23 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 Banking Corporate Lending 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.24 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.24.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.25 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.26 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 Banking Corporate Lending, 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 Banking Corporate Lending:

OBCL Field

Corresponding Loans QT Field

Remarks

Amendment Allowed Through Draft Trade

OBCL 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 Bank­ing Corporate Lending Gen­erated Ref No

NO

Reverse the existing trade and rebook the new trade

User Ref No

 

User Input Ref No in Oracle Banking Cor­porate Lending

NO

Reverse the existing trade and rebook the new trade

Custom Ref No

 

Populated in Oracle Bank­ing Corporate Lending

NO

Reverse the existing trade and rebook the new trade

Version

 

Oracle Bank­ing Corporate Lending Ver­sion

 

 

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 Banking Cor­porate Lending

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 Bank­ing Corporate Lending Sys­tem 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 Bank­ing Corporate Lending 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 Banking Corporate Lending’

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’

 

TradeID

LQT Trade ID

CUSIP

Internal CUSIP

FundMnemonic

LQT Counterparty mnemonic

5.26.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.26.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.26.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.1.3 Amending Financial Centre Holiday Treatment

Financial center maintained at product level is defaulted in ‘Secondary Loan Trading – Draft Trade’ (TLDTDUPL) screen. If required, you can add or remove the financial center.

5.27 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.27.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.27.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.27.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.27.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.28 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 Banking Corporate Lending. 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.28.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.29 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.29.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.29.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.29.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. 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.

5.30 SLT Processing for LMA / LSTA Participation

  1. The LQT upload processing is enhanced with the existing LQT feed for ‘Doc Type’.
  2. The LQT feed contains the below values for ‘Doc Type’
  1. The value consumed from the LQT feed is displayed in the ‘Trade Standard’ field in the ‘Draft Trade Input’ and ‘Trade Online’ screens as follows

 

Note

Value from the LQT feed is taken as it is in the ‘Draft Trade’ screen. There is no validation to check the value of the ‘LMA / LSTA Participation’ check box at the LT product level or whether the trade is sell and participation.

  1. Similarly, the ‘Doc Type’ field in the ‘LQT Trade Browser’ screen displays the values as ‘LMA’ / ‘LSTA’ / ‘Non-Standard’ based on the LQT feed.
  2. When an amendment for the field ‘Doc Type’ is received from LQT, OBCL systematically reverses and rebooks the trade contract.
  3. During LT-LS upload processing, the system processes the below (only for the sell and participation trades).

Note

No changes are envisaged in the LT processing of buy and participation trades as well as buy / sell and assignment trades and the same continues to work

If the trade received from LQT has the value ‘LMA’ or ‘LSTA’ in the field ‘Doc type’, ‘Sell’ for ‘Buy/Sell Indicator’ and ‘Participation’ in the ‘Deal Type’ and the ‘LMA / LSTA Participation’ check box is selected at the LT product level, the system checks if the external participant is available in the ‘Portfolio Maintenance’ and ‘Position Identifier Maintenance’ screens and do the below processing. For all other items (non-standard, buys and assignment type activity), portfolio does not systematically created.

If the external participant is not available in both the maintenance screens mentioned above, then OBCL systematically uploads the external participant details in both the maintenance screens with the ‘LMA / LSTA Participation’ check box as selected

If the external participant is available in both or any of the maintenance screens mentioned above with the value of the new field ‘LMA / LSTA Participation’ as unchecked, then LT-LS handoff is failed with appropriate error message.

An external participant is added in the corresponding LS tranche and drawdown contracts once the trade is settled.

The value of the ‘LMA / LSTA’ Participation’ check box is propagated from the trade standard value in the newly added external participant in the LS tranche and drawdown contracts with the ‘Self Participant’ check box selected.

If the trade received from LQT has the value ‘Non-Standard’ in the field ‘Doc type’ or , ‘Buy’ for ‘Buy/Sell Indicator’ or ‘Assignment’ in the ‘Deal Type’ and the ‘LMA / LSTA Participation’ check box is selected at the LT product level or the field ‘Doc type’ has the value ‘LMA’ or ‘LSTA’ and the ‘LMA / LSTA Participation’ check box is cleared at the LT product level, system does the below processing.

The system does not populate the ‘Portfolio Maintenance’ and ‘Position Identifier Maintenance’ screens.

An external participant is added in the corresponding LS tranche and drawdown contracts once the trade is settled for non-standard participation. There is no LS update for external participant on buy participation or any assignment settlement,

The value of the ‘Trade Standard’ is propagated as ‘Non-Standard’ to the ‘LMA / LSTA Participation’ in the newly added external participant in the LS tranche and drawdown contracts with the ‘Self Participant’ check box unchecked.

Note

In the above scenario, if the external participant is available in both or any of the mainte­nance screens with the value of the ‘LMA / LSTA Participation’ as unchecked / checked, then system does not fail the LT-LS handoff.

 

  1. An external participant have the same value for the field ‘LMA Participation’ or ‘LSTA Participation’ under one CUSIP. If two trades are received from LQT for same CUSIP with different values in the field ‘Doc Type’, the value of the first trade getting settled (as part of trade/ticket settlement) is defaulted in the external participant.

Refer the below example for the processing of trades with the LQT feed as LMA / Non-Standard for different trades under same CUSIP and same external participant.


Scenarios

Doc Type' for Trade 1 in LQT Feed for the external participant EP1 and CUSIP1

Trade 1 Settled?

LT Product - LMA/LSTA Participation flag after Trade 1

Doc Type' for Trade 2 in LQT Feed for the same external participant EP1 and CUSIP1

Result

Scenario 1

LMA

Yes

Checked

Non-Standard

LT - LS handoff happens after Trade 1 settlement. EP1 is added in the tranche with flag as LMA and EP1 is auto populated in position & portfolio tables. After Trade 2 settlement, EP1 flag value at tranche / position / portfolio table are not be changed. Only the position is increased in the tranche. At the tranche level, the EP1 have the value as LMA

Scenario 2

LMA

Yes

Unchecked

LMA

LT - LS handoff happens after Trade 1 settlement. EP1 is added in the tranche with flag as LMA and EP1 is auto populated in position & portfolio tables. After Trade 2 settlement, EP1 flag value at tranche / position / portfolio table is not changed. Only the position is increased in the tranche. At the tranche level, the EP1 have the value as LMA

Scenario 3

LMA

No

Unchecked

LMA

LT - LS handoff happens after the settlement of Trade 1 / Trade 2. EP1 is added in the tranche with flag as Non-Standard but EP1 is not auto populated in position and portfolio tables.

Scenario 4

LMA

No

Checked

Non-Standard

Trade Standard of the trade which gets settled first, is propagated to the counterparty at the tranche level. If trade 1 gets settled first, LT - LS handoff happens after Trade 1 settlement. EP1 is added in the tranche with flag as LMA and EP1 is auto populated in position and portfolio tables. After Trade 2 settlement, EP1 flag value at tranche / position / portfolio table will not be changed. Only the position is increased in the tranche. At the tranche level, the EP1 have the value as LMA.
If trade 2 gets settled first, LT - LS handoff happens after the settlement of Trade 2. EP1 is added in the tranche with flag as Non-Standard but EP1 is not auto populated in position and portfolio tables.

Scenario 5

Non-Standard

No

Unchecked

LMA

LT - LS handoff happens after the settlement of Trade 1 / Trade 2. EP1 is added in the tranche with flag as Non-Standard but EP1 is not auto populated in position and portfolio tables.

Scenario 6

Non-Standard

Yes

Checked

LMA

LT - LS handoff happens after Trade 1 settlement. EP1 is added in the tranche with flag as Non-Standard. EP1 is not auto populated in position and portfolio tables. After Trade 2 settlement, EP1 flag value is not changed. Only the position is increased. At the tranche level, the external participant have the value as Non-Standard.

Scenario 7

Non-Standard

Yes

Unchecked

LMA

LT - LS handoff happens after Trade 1 settlement. EP1 is added in the tranche with flag as Non-Standard. EP1 is not auto populated in position & portfolio tables. After Trade 2 settlement, EP1 flag value is not changed. Only the position is increased. At the tranche level, the external participant have the value as Non-Standard.

Scenario 8

Non-Standard

Yes

Unchecked

Non-Standard

LT - LS handoff happens after Trade 1 settlement. EP1 is added in the tranche with flag as Non-Standard. EP1 is not auto populated in position & portfolio tables. After Trade 2 settlement, EP1 flag value is not changed. Only the position is increased. At the tranche level, the external participant have the value as Non-Standard.

Scenario 9

Non-Standard

No

Checked

LMA

Trade Standard of the trade which gets settled first, is propagated to the counterparty at the tranche level. If trade 2 gets settled first, LT - LS handoff happens after Trade 1 settlement. EP1 is added in the tranche with flag as LMA and EP1 is auto populated in position & portfolio tables. After Trade 2 settlement, EP1 flag value at tranche / position / portfolio table is not changed. Only the position is be increased in the tranche. At the tranche level, the EP1 have the value as LMA.
If trade 1 gets settled first, LT - LS handoff happens after the settlement of Trade 2. EP1 is added in the tranche with flag as Non-Standard but EP1 is not auto populated in position & portfolio tables.

Note

It is assumed that the LMA/LSTA Participation check box at the LT product is selected in all the scenarios before the LQT feed for Trade 1 is received.

It is also assumed that the ‘Deal Type’ is ‘Participation’ and the ‘Buy/Sell Indicator’ is ‘Sell’ for all the trades mentioned in the above scenarios. For assignment / buy trades, LMA / LSTA propagation to LS and auto-population in portfolio / position maintenance does not happen

If a trade is processed with the ‘Trade Standard’ value as ‘LMA’ / ‘LSTA’ and before LT - LS handoff, if the record status of either ‘Portfolio Maintenance’ or ‘Position Identifier Maintenance’ or both is closed then LT-LS upload processing is failed and exception is logged advising that the respective maintenance is closed.

If a trade is received with the ‘Doc Type’ value as ‘LMA’ and before it is settled, the ‘LMA/LSTA Participation’ is not selected at the LT product level and an amendment is received for the trade to change the ‘Doc Type’ value as ‘LSTA’, system reverses and rebook the trade. The trade standard value is ‘Non-Standard’ since the check box is not selected at the product level and the external participant is added in the tranche with the field value as ‘Non-Standard’.

  1. When you reverse the trade settlement (RSTL) for a trade where LT – LS handoff is already happened, system reduces the position for the participant in the tranche. The system does not remove the participant from the tranche and the field value propagated to the participant as part of LT – LS handoff is not changed. In addition, system does not remove the maintenance uploaded as part of LT – LS upload processing from the position / portfolio screens. Hence, after RSTL, if you upload a trade amendment / correction with amended ‘Doc_Type’ value, the system does not propagate the amended value to LS participant / position / portfolio maintenance after settlement. The LS participant added as part of the initial trade settlement continues to exist and the only the position is increased in accordance with the amended trade. The field value remains the same in the LS participant in the tranche. This has to be operationally controlled.

5.31 SLT Processing for Primary Delayed Compensation

5.31.1 Portfolio Details screen

You can invoke the ‘Portfolio Details’ screen by typing ‘TLDPOMNT' in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.

 

Unfronted

The ‘Unfronted’ check box is enabled only for the portfolios where the desk is ‘ORIGINATIONS-PRM’.It is not selected by default. You are allowed to select the check box before the record is authorized once.

The LOV displays only the portfolios where the desk is ‘ORIGINATIONS-PRM’.

Linked Unfronted Portfolio

The default value of the ‘Linked Unfronted Portfolio’ is null. You are allowed to select a value from the LOV.

The LOV displays only the active and authorized portfolios for which the ‘Unfronted’ check box is selected and the same should not be linked to any other portfolio. You need to create the un-fronted portfolio first, before linking the same to a fronted portfolio.

The system validates at the time of saving the portfolio that the MEICODE of the trading portfolio and the ‘Linked Unfronted Portfolio’ (if selected) should be same. Appropriate error messages are displayed if the validation is failed.

You are allowed to link only one ‘Linked Unfronted Portfolio’ with a fronted portfolio.

You are allowed to modify existing trading portfolios and maintain ‘Linked Unfronted Portfolio’ from the LOV only when ‘Linked Unfronted Portfolio’ is blank and the ‘Unfronted’ check box is not selected.

During copy action, the system copies the value of the ‘Unfronted’ to the newly created portfolio. However, the system does not copy the value of the new field ‘Linked Unfronted Portfolio’.

You are allowed to maintain settlement instructions for the newly created ‘Linked Unfronted Portfolio’ even before portfolio maintenance.You are allowed to maintain position identifier for the newly created ‘Linked Unfronted Portfolio’.

You are allowed to do the LS OL product component mapping maintenance for the newly created ‘Linked Unfronted Portfolio’. You should maintain the same expense code for the fronted as well as un-fronted portfolios.

5.31.2 Position Identifier Screen

You can invoke the ‘Position Identifier Detailed’ screen by typing ‘TLDPIMNT' in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.

 

5.31.3 Trading on Lead Agent Deals

  1. When a trade is received from ClearPar / Markit with the value of the field ‘Primary Trade’ as selected, the system checks if the portfolio resolved has any linked un-fronted portfolio.
  2. If the resolved portfolio contains any linked un-fronted portfolio, the system creates two records in the agency confirmation browser based on the asset ratio of participant which is involved in trading along with the linked portfolio which is listed within the tranche.
  3. Similarly, two records are populated in the 'Pending Trade Browser' screen based on the asset ratio of participant which is involved in trading along with the linked portfolio which is listed within the tranche during settlement.
  4. You should submit PRAM for both the records for the trade to get settled and positions are updated in the tranche contracts.
  5. Primary trades are applicable only for sell type of trades. The system does not validate that buy primary trades cannot be booked. The same should be operationally controlled.


Tranche Amount / Position prior to settlement:

Tranche (Agented)

Asset Ratio

P1 (Fronted Portfolio)

60%

P2 (Linked un-fronted portfolio)

30%

P3

10%

Tranche Amount

$10,000

P1 Share (Fronted Portfolio)

$6000

P2 Share (Linked un-fronted portfolio)

$3000

P3 Share

$1000

Trade received from ClearPar/Markit: Participant1 selling $1000 to Participant3

Two records are populated in agency confirmation browser as below

Trade Amount

$1000

Record1 (Fronted P1 selling to P3)

$666.66 ((6000 / 9000) *1000)

Record2 (Un-fronted P2 selling to P3)

$333.33 ((3000 / 9000) * 1000)

 

 

 

 

Below is participant position after the trade is settled.

Tranche Amount

$10,000

P1 Share (Fronted Portfolio)

$ 5333.34 ($6000-666.66)

P2 Share (Linked un-fronted portfolio)

$ 2666.67 ($3000-333.33)

P3 Share

$2000

5.31.4 Trading on Non-Lead Agent Deals

  1. When primary trades are received from LQT, OBCL books two trades systematically as below. Ticket id is same for both the trades.
  1. Double-click on a record related to the primary trade in the LQT trade browser, the system displays only the trade booked for the fronted portfolio. You are allowed to view the trade booked for the un-fronted portfolio by querying in the field ‘Ext Contract Ref No’ in the 'Draft Trade Input' screen as well as the field ‘External Ref No’ in the 'Trade Online' screen.
  2. If amendments are received after the two trades are booked systematically, the system applies the changes on both the trades. Amendments leads to the reversal and re-book of the trade is applicable for both trades only if both the trades are booked initially.
  3. In case of unavailability of the tranche contract when a primary trade is received, the trade is booked for full amount for the fronted portfolio. The ‘Process Status’ of the trade is ‘Extracted’ and the same is available in the origination queue.You are not allowed to confirm the same in the origination queue due to short sell. After creating the tranche and position in SLT module, you are allowed to confirm the trade in origination queue.
  4. When LQT trade is received with the value of the field primary trade as ‘Yes’ and there is only one linked un-fronted self-participant present in the tranche, the system checks if the following maintenance is available.
  1. If the above maintenance is available, the system books the trade with full amount for un-fronted portfolio. If the above maintenance is not available, system fails the trade.
  2. If there is no linked un-fronted portfolio and only one fronted portfolio is present in the underlying tranche contract, the system books a trade for the entire trade amount received from LQT for the fronted portfolio.
  3. During LQT trade upload, if the resolved portfolio belongs to the new desk ‘ORIGINATIONS-PRM’ but the value of the field ‘Primary Trade’ is N, the system fails the trade booking.
  4. During settlement of primary trades received from ClearPar/Markit, the system validates the trading position held by the respective fronted portfolio and the linked un-fronted portfolio as of the application date. If the positions mismatch, trade settlement is failed with appropriate error messages. Trade is settled successfully if the positions match.

Example 1: (Both fronted as well as un-fronted portfolio available in tranche)

Fronted Portfolio - P1

Linked Un-Fronted Portfolio - P2

Tranche (Agented)

Asset Ratio

P1 (Fronted Portfolio)

60%

P2 (Linked un-fronted portfolio)

30%

P3

10%

Tranche Amount / Position prior to settlement:

Tranche Amount

$10,000

P1 Share (Fronted Portfolio)

$6000

P2 Share (Linked un-fronted portfolio)

$3000

P3 Share

$1000

Trade received from LQT: P1 selling $1000 to P3

Two trades are booked in OBCL as below

Trade Amount (From LQT)

$1000

Trade 1 (Fronted P1 selling to P3)

$666.66 ((6000 / 9000) *1000)

Trade 2 (Un-fronted P2 selling to P3)

$333.33 ((3000 / 9000) * 1000)

 

Below is participant position after the trade is settled.

Tranche Amount

$10,000

P1 Share (Fronted Portfolio)

$ 5333.34 ($6000-666.66)

P2 Share (Linked un-fronted portfolio)

$ 2666.67 ($3000-333.33)

P3 Share

$2000

Example 2: (Only fronted portfolio available in tranche)

Fronted Portfolio – P4

Linked Un-Fronted Portfolio – P5 (Not available in tranche)

Tranche (CITI Agented)

Asset Ratio

P4 (Fronted Portfolio)

60%

P6

30%

P7

10%

 

Tranche Amount / Position prior to settlement:

Tranche Amount

$10,000

P4 Share (Fronted Portfolio)

$6000

P6 Share

$3000

P7 Share

$1000

Trade received from LQT: P4 selling $1000 to P7

One trade booked for P4 in OBCL for the full amount as below

Trade Amount (From LQT)

$1000

Trade 1 (Fronted P4 selling to P7)

$1000

Below is participant position after the trade is settled.

Tranche Amount

$10,000

P4 Share (Fronted Portfolio)

$5000

P6 Share

$3000

P7 Share

$2000

Example 3: (Only un-fronted portfolio available in tranche. Portfolio maintenance is available)

 

Fronted Portfolio - P8 (Not available in tranche)

Linked Un-Fronted Portfolio - P9

Tranche (CITI Agented)

Asset Ratio

P6

60%

P9 (Linked un-fronted portfolio)

30%

P7

10%

Note

The un-fronted portfolio (P9) is linked to a fronted portfolio (P8). However, the same par­ticipant is not available in the tranche contract.

Tranche Amount / Position prior to settlement:

Tranche Amount

$10,000

P6 Share

$6000

P9 Share (Un-fronted Portfolio)

$3000

P7 Share

$1000

Trade received from LQT: P9 selling $1000 to P7

One trade is uploaded for P9 in Oracle Banking Corporate Lending for full amount as below

Trade Amount (From LQT)

$1000

Trade 1 (Fronted P9 selling to P7)

$1000

Below is participant position after the trade is settled.

Tranche Amount

$10,000

P6

$6000

P9 (Linked un-fronted portfolio)

$2000

P7

$2000

Example 4: (Only un-fronted portfolio is available in tranche. Portfolio maintenance is not available)

Un-Fronted Portfolio - P9

Tranche (Agented)

Asset Ratio

P6

60%

P9 (Un-fronted portfolio)

30%

P7

10%

Note

The un-fronted portfolio (P9) is not linked to a fronted portfolio.

 

Tranche Amount / Position prior to settlement:

Tranche Amount

$10,000

P6 Share

$6000

P9 Share (Un-fronted Portfolio)

$3000

P7 Share

$1000

 

Trade received from LQT: P9 selling $1000 to P7. The trade received from LQT is failed.

  1. When you create a tranche contract with participants which are linked to the new desk,

the system creates position in SLT module systematically.

  1. The position for the respective fronted and linked un-fronted portfolios are updated in the

SLT module during the following events on the tranche/drawdown contracts.

  1. The position is also be updated in SLT module, if the ‘Update LT Position’ check box is selected for the participant (only for portfolios with the desk ‘ORIGINATIONS_PRM’/’ORIG’/’ORIGINATIONS_HFS’)
  1. You are not allowed to add an un-fronted / fronted portfolio to a tranche contract as part of participant transfer.
  2. Delayed compensation fees are accrued on the primary trades like the secondary loan trades.
  3. Primary trades are applicable only for sell type of trades. The system does not validate that buy primary trades cannot be booked. The same should be operationally controlled.
  4. Automated ticket settlement by means of SDN messages from Markit is not applicable for the primary trades. Booking of internal trades for creation of position from LS to SLT module is not impacted.

5.31.5 Reduction of Un-Amortized Fees during trade

  1. You should maintain the amortization fees in the existing ‘Amortization Fee’ screen for the fronted and un-fronted commitments.
  2. Origination queue screen is populated for the primary trades as well, for both fronted and un-fronted portfolio.
  3. Any fees associated with the primary trade is reduced based on the fees maintained in the ‘Amortization Fee’ screen for the commitment after the settlement of the sell trade like the CLP trades.

5.31.6 Placement Processing

  1. This functionality is applicable for the match funded placement contracts linked to both Lead agented and non-Lead agented deals
  2. After the trade settlement (sell trade) is STP’d to OL, at the time of OL negative VAMI processing, the system checks if any match funded placement contract is present for the associated loan.
  3. If any match funded placement contract is identified, the contract amount of such placement contracts are reduced systematically for each sell trade to the extent of the amount of the trade and asset ratio at the tranche level for that participant.
  4. Systematic reduction on the placement contracts is done as a prepayment. LIQD event is registered in the placement contract with value date as settlement date of the trade.

Example 1:

Tranche

Asset Ratio

P1 (Fronted Portfolio)

60%

P2 (Un-fronted Portfolio)

30%

P3

10%

Tranche Amount

$10,000

P1 Share (Fronted Portfolio)

$6000

P2 Share (Un-fronted Portfolio)

$3000

P3Share

$1000

Drawdown1 Amount

$2000

P1 Share (Fronted Portfolio)

$1200

P2 Share (Un-fronted Portfolio)

$600

P3Share

$200

Commitment1 (STP’d from Tranche P1)

$6000

Commitment2 (STP’d from Tranche P2)

$3000

Loan1 (STP’d from DD P1)

$1200

Loan2 (STP’d from DD P2)

$600

Placement1 (For Loan1)

$1200

Placement2 (For Loan2)

$600

Trade received: P1 Selling $1000 to P3.

After settlement, positions at tranche / drawdown / commitment / loan / placement contracts are as below:

Tranche Amount

$10,000

P1 Share (Fronted Portfolio)

$5333.34 ($6000- ((6000 / 9000) *1000))

P2 Share (Un-fronted Portfolio)

$2666.67 ($3000- ((3000 / 9000) * 1000))

P3Share

$2000

Drawdown1 Amount

$2000

P1 Share (Fronted Portfolio)

$1066.67 (53.33% of $2000)

P2 Share (Un-fronted Portfolio)

$533.33 (25.55% of $2000)

P3Share

$400 (10% of $2000)

Commitment1

$5333.34

Commitment2

$2666.67

Amount to be reduced on Loan1

$133.33 ($1200 - $1066.67)

Amount to be reduced on Loan2

$66.67 ($600 - $533.33)

Pre-payment on Placement1

$133.34

Pre-payment on Placement2

$66.67

After systematic reduction in the placement contract, the new position will be as follows

Placement1 (For Loan1)

$1066.67

Placement2 (For Loan2)

$533.33

If there are multiple trade settlements on the same day, for each settlement system registers LIQD event and reduce the contract amount to the extent of the amount of the trade and asset ratio at the tranche level for that participant.

 

If trade settlement is received after the treasury cut off, then system processes the reduction as a future dated payment and the payment is processed in the next day’s batch.

If the trade settlement on the primary trade is reversed (RSTL), the prepayment (LIQD) posted in the placement contract for amount reduction is not reversed. The same should be operationally controlled.

5.31.7 Trade Type Amendment

You are allowed to change the deal type (Assignment, Participation so on.) for all the active primary trades under the same LQT Ticket.

If the deal type is changed for primary trades, the system reverses and rebooks both the trades.

When the settlement is processed, the system considers the latest deal type.

 

Example 1:

  1. Both trades are settled as participation.