7. Interface between SLT and LB modules

This chapter contains the following sections:

7.1 Introduction

The data captured in the SLT module needs to be passed on to the LB module which in turn interfaces with the OL module for processing the trade details and updating positions accordingly.

Different scenarios are possible where data needs to be exchanged between SLT and LB modules. The most common scenarios where data exchange takes place are explained in the subsequent sections.

7.2 Deals Originated by Bank

All deals having bank as the lead agent is captured initially in the LB module. The following activities are involved in this scenario:

  1. Trade transaction originates in LB module.

 

A trade contract is initiated in the SLT module origination desk, once the transaction in LB module gets authorized.

 

Internal contracts are created in SLT module for the purpose of updating positions and computing WAC for Originations desks. Internal trade contracts are created with settlement days as zero. Hence, the trade date and settlement date are the same for such contracts.

Fees are not collected for these contracts and also no accounting entries are posted since the accounting entries would have already been posted in the LB module.

For a future value dated tranche booked in the LB module, the corresponding SLT contract gets created on the value date of the tranche. You cannot perform any amendment or reversal on these SLT contracts.

Events like participant transfer in the LB module does not have a corresponding action/event happening in SLT module. If a tranche gets cancelled in the LB module, a warning message is displayed that there are active contracts in SLT module.

This section contains the following topics:

7.2.1 Viewing LB Handoff Details

You can view the status of the hand-offs from LB to the SLT module in the ‘LB-TL Interface Browser’ screen. You can invoke the ‘LB-TL Interface Browser’ screen by typing ‘LBDSLTIB’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.

 

Following details are displayed in this screen:

The processing status can have any of the following values:

You can unlock the ‘Failed’ records and change the processing status to ‘Reprocess’ to select the contract for re-processing. Once the details are saved and authorized, the status in LT upload table changes to ‘Submit’ for the record marked for ‘Reprocess’ in the Interface Browser screen. The records with ‘Submit’ status are picked up by SLT job to create the trade contracts.

Note

You can view the errors associated with a contract. The PRAM/NP VAMI gets fired inter­nally for each of the underlying drawdown for both Pro-rata and Non Pro-rata tranches where the seller is the active participant.

If the bank is non - lead agent, external (non-bank) parties are allowed in the non-lead agency contract. This is applicable only for participation type of trades. PRAM is triggered on the non-lead agency contract to transfer the participation amount from bank entity to the buyer.

7.2.1.1 Processing in LB-TLT Interface Browser

PRAM for HFS transfer is updated into the LB-TL interface Browser. Two records are updated in the browser - one each for HFI and HFS portfolios. Transfer price is stored internally to compute HFS Transferred Cost Basis while processing internal trades in trading module. Note that the expense code should be unique for the combination of CUSIP and HFS/HFI portfolio.

The expense code is resolved from the associated commitment contract for the HFI originated internal trade and HFS originated internal trade. During HFS Transfer, expense code of HFI internal sell trade is defaulted to the HFS internal buy trade. If expense code is not resolved for the HFI trade and more than one expense code are mapped with the HFS portfolio, then you have to manually enrich the expense code in the LB-TL Interface Browser.

The expense code for HFS portfolio is same as the expense code mapped for the HFI portfolio, during HFI to HFS transfer under a CUSIP. Hence the expense code for the HFS internal buy trade is picked up from the associated internal HFI sell trade systematically. Processing status is ‘Handoff’ if all the details are resolved. The LB-TL job picks up and process the trades. However, this job does not process the HFS internal buy trade if commitment is not linked to the HFS participant (using the ‘STP Relink’ screen). The system logs an appropriate error message for not processing the trade. Commitment is required to upload Transfer Marks as an Amort fee during HFS internal buy trade processing.

In order to update the position, the system creates two trades - one internal sell trade to reduce the HFI position and one internal buy trade to create/update the HFS position. Both internal trades are booked and settled systematically. If HFS Buy trade fails in the LB-TL browser, then subsequent trade processing for the HFI or HFS portfolio under the CUSIP fails in the draft layer if the HFS position is not enough to cover the sale amount. This ensures that HFS position (in failed) is settled first prior to HFI position.

PRAM to reverse the HFS transfer is not updated in the browser. You have to manually reverse the internal trades after reversing the HFS transfer in agency as part of PRAM. New PRAM after the reversal is updated in the browser and internal trades are processed as explained above.

If there is no position in the HFI portfolio in trading module while processing the PRAM event from the browser, then trade processing fails for both buy and sell trades and the processing status is updated as ‘Failed’ with an appropriate exception message. You have to update the balances manually in the trading module and reprocess the PRAM event in the browser to process the internal trades.

The system does not validate commitment/loan/CoC balances from the origination module during internal trade processing. It performs validations during PRAM and these origination balances are stored for internal trade processing during HFS transfer (PRAM) in LB module.

Note

The aforementioned functionality is applicable to bank originated deals as well as deals where bank is not the lead agent.

7.2.1.2 Handing off Contracts for Reprocessing

You can repeat the handoff-for the contracts in ‘Extracted’ status in the LB-TL Interface Browser screen. ‘Extracted’ status indicates that the contracts have not been handed-off properly.

You can re-run the handoff for such contracts in the ‘SLT Handoff Rerun’ screen. You can invoke the ‘SLT Handoff Rerun’ screen by typing ‘LBDLTHOF’ 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 re-process the handoffs that have failed by selecting the borrower contract reference number and borrower event sequence number of the contract for which handoff should be repeated.

You need to specify the following details here:

Contract Reference No.

Select the contract for which you wish to repeat the handoff process. All contracts in ‘Extracted’ status in the ‘LB-TL Interface Browser’ screen are displayed here.

Event Sequence No.

Select the event sequence number associated with the contract selected.

Click ‘Run’ to handoff the details of the selected contract.

7.2.2 Future Buy/Sell Deal with Bank as Lead Agent

When a sell deal is captured in SLT module, the system checks if a CUSIP corresponding to the Branch-Desk-Expense Code combination exists in the LB module.

When the deal is settled and authorized in SLT, the transaction details flow to the LB module which in turn initiates a participant transfer event in the LB module.

Note

You can perform settlements in the LB module only if CUSIP exists for the branch/desk/expense code combination.

The following diagram illustrates this scenario:

 

7.2.3 Participation Sell where Bank as Lead Agent

As part of STP processing from agency to agency wrapper, a new wrapper contract is created with the sell participation trade amount as on the sell participation settlement date for the first participation sell trade.

For a first time participation sell for a CUSIP, bank selling to external counterparty, system creates an agency wrapper tranche with the following inputs:

It also creates a new facility contract for the Agency Facility amount where the Facility start date and end date is same as the agency facility start and end dates.

You have to maintain the product details to map the agency product to wrapper product. Otherwise, the agency wrapper contract uses the same product and expense code as of the main agency contract for Facility/Tranche/Drawdown.

Following details are displayed in TLS- LB Interface Browser (TLDLDIFB) screen:

 

During LB-wrapper Handoff, the processing status can have any of the following values:

Using this screen, you can unlock the failed record and change the processing status from ‘Failed’ to ‘Reprocess’ and save for ones which have failed during Agency to wrapper handoff.

You can view the exception log associated with a contract by using the ‘Exception Details’ section.

If the agency wrapper contract for the Silent participant and CUSIP combination is available with a positive tranche balance, then STP of the PRAM from the agency contract will be done to the agency wrapper contract as a NPVAMI to increase the wrapper contract amount and add the buyer/increase the pro-rata share for the buyer of the silent sell participation.

Settlement party for the agency wrapper contract is the Silent participant id that has been used for the Trade processing in the Agency contract.

The STP processes are as follows:

Before processing the STP to the wrapper, system performs the basic contract balance (Principal) validations. In case of any exceptions, system does not proceed and the event is in ‘Failed’ status. No validation is done for interest/fees.

Events prior to the current event of the same contract should be in processed status.

If there is any subsequent Participation sell after all the participations are elevated, you need to manually update the position in the existing wrapper contract by initiating the NP VAMI for the new trade amount at the tranche level and NP VAMI at the drawdown level based on the pro-rata share of the drawdown in the tranche.

If there are any subsequent sell Participation trade with the same external counterparty or with new external counterparty, system triggers Non pro rata VAMI to increase the wrapper contract amount on the wrapper tranche and wrapper drawdown.

7.3 Deals where Bank is not Lead Agent

For deals captured in the SLT module where bank is not the Agent also you need to capture the trade details in the LB module. On settlement date, system checks if the CUSIP for the branch/desk/expense code combination exists in LB. If the CUSIP does not exist, you need to upload the funding memo details in the predefined format.

For a first time buy, the CUSIP does not exist in the agency and the hence you need to create the agency contract corresponding to the trade that happens in SLT. In this agency contract that gets created in LB, the participant involved is the desk handling the buy trade in SLT. The participation percentage is taken to be 100% in this case.

When there is a subsequent trade deal related to the same CUSIP, the contract amounts are updated appropriately, as the contract already exists in LB.

The following diagram illustrates this scenario:

 

The following example demonstrates the contracts that are created in LB, in this scenario:

Example

Let us assume that on Day 1, a purchase of 100mn happens for a CUSIP, on behalf of Desk1 (in Branch Br001).

On the settlement date, in LB module, a tranche for 100mn gets created in Branch 001. A Participant contract also created with Desk1 as the participant with 100% participation.

Assume a second trade on Day 10, where 200mn of the same CUSIP is purchased on behalf of Desk2 (in Branch Br002).

On the settlement date of this trade,

The existing tranche maintained in Branch (Br001) is updated to 300mn.

A new Participant contract for Desk 2 for 200mn is created.

The ratio of the participants would be changed as follows: -

This section contains the following topics:

7.3.0.1 Viewing SLT Handoff Details

You can view the status of the hand-offs from SLT to the LB module in the ‘SLT-LB Interface Browser’ screen. You can invoke the ‘TLS-LB Interface Browser’ screen by typing ‘TLDLDIFB’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.

 

Following details are displayed in this screen:

The processing status can have any of the following values:

Note

The agency contracts having status ‘Handoff’ or ‘Reprocess are taken up for further processing as a background job process. For contracts in ‘Extraction’ status, you need to make corrective actions according to the exception log that is displayed. You can view the exception log associated with the contract. While processing, the system checks if the trade is a Pro-rata tranches or Non Pro-rata tranches. Then the system arrive the drawdown PRAM/ NP VAMI amounts based on the following:

The PRAM/NP VAMI amount for a Tranche/DD is Buyer’s share amount available in ‘Agency Details Input’ screen.

After making necessary corrections, you need to unlock the concerned record in the ‘SLT-LB Interface Browser’ screen and change the status to ‘Processed’.

For contracts in ‘Failed’ status, you need to make the necessary corrections in LB and then update the status in the browser screen as ‘Reprocess’.

Note

For inter-desk trades, SLT to LB handoff will be done only for buy trades.

7.3.0.2 Processing of TL-LB

The status of the handoffs from SLT to LB module is viewed in ‘SLT-LB Interface browser’. The SLT trade details and corresponding events on the agency contract are displayed in this screen

In the TL-LB processing, the following process happens after the drawdown details have been captured in the funding memo and when the settlement is captured:

In the ‘TL-LB job browser’, the drawdown which has created as part of the first trade and the second trade is in the failed status. If you perform an action on the drawdown in the Agency module that affects the outstanding balance, then the outstanding balance does not match the value captured in TL module. This has to be handled manually.

7.3.0.3 Handing off Trade Details for Reprocessing

If the data population of upload tables have failed, that is, when the status in the browser is ‘Extraction’, you can rerun the handoff to populate the upload tables.

You can re-run the handoff in the ‘SLT Handoff Rerun’ screen. You can invoke the ‘SLT Handoff Rerun’ screen by typing ‘TLDREHOF’ 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 re-process the handoffs that have failed by selecting the trade reference number and event sequence number of the contract for which handoff should be repeated.

You need to specify the following details here:

Trade Reference No.

Select the trade contract for which you wish to repeat the handoff process. All contracts in ‘Extraction’ status in the ‘LB-TL Interface Browser’ screen are displayed here.

Event Sequence No.

Select the event sequence number associated with the trade selected.

Event Code

Specify the event code associated with the selected trade.

Click ‘Run’ to handoff the details of the selected contract.

7.3.1 Handing-off Commitment Reduction Details

Commitment reductions can happen in the agency due to events like value dated amendments for the tranche, capitalized rollover of non-revolving contracts or any action resulting in principal payment for non revolving contracts so on.

These commitment reductions details can be handed off to the external system Loans QT using the ‘Commitment Reduction Handoff’ screen.

You can invoke the ‘LQT Commitment Reduction Handoff’ screen by typing ‘TLDCOMRH’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.

 

In this screen you need to specify the following:

Borrower Reference No.

Select the reference number of the borrower tranche whose commitment reduction details you wish to hand-off.

Total commitment reduction for the borrower along with the break up for each of the position identifier and the facility name gets displayed, once you select the borrower reference number.

Commitment Reduction Price

Specify the commitment reduction discount/ premium price.

The commitment reduction (or increase) is triggered in the LB module when there is a payment of a non-revolving tranche or when there is a reduction (or increase) in the tranche amount. Upon commitment reduction/ increase in the agency, system will hand-off the details to Loans QT.

Note

Commitment reduction price is a mandatory input. If you click the ‘Handoff’ button without specifying the ‘Commitment Reduction Price’, system gives an error message and the data is not handed off to LQT. Also, commitment reduction price is disabled and no vali­dation is done for commitment reduction due to PIK activity.

Click ‘Handoff’ to initiate the handoff process.

As part of commitment reduction handoff, the ‘Commitment Reduction Price’ is sent to the external system Loans QT as Commitment Reduction (CR) key. The CR key has the value of the ‘Borrower Tranche Reference Number – Event Sequence Number’ to uniquely identify a particular commitment reduction. The system will compute DCFCOC on the trades that are handed off successfully.

The CR key is sent from LQT to Oracle FLEXCUBE as part of trade amendment upload, to handle commitment reduction for open trades. Also, the CR key is sent as part of the internal deal upload from LQT to handle the commitment reduction for settled position. System refers to the CR key to resolve the respective commitment reduction price.

You can reject commitment reduction hand-off records that are failed and unprocessed, by clicking the ‘Reject’ button. On clicking this button, the system will mark the status of such failed and unprocessed records as ‘Rejected.’ The system will not send the rejected records to LQT.

This button is enabled only if the check box ‘Allow CUSIP/ISIN Swing’ is selected in the ‘Loan Parameters’ screen.

7.3.2 Viewing LQT Trade Browser Details

You can view the LQT trade browser details in the ‘LQT Trade Browser’ screen. You can invoke the ‘LQT Trade Browser’ screen by typing ‘TLDTRDBW’ 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:

7.4 Viewing Multiple Firm Account

You can view the MCC Firm Account Mapping details in the ‘MCC - Firm Account Mapping’ screen.

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

 

Existing firm account mnemonic cannot be uploaded from MCC Upload.

The system displays the following details:

Note

7.5 Viewing Referential Data from Secure

You can view the data received from Secure in the ‘Secure Data’ screen.

You can invoke the ‘Secure Data Mapping’ screen by typing ‘TLSECURE’ 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:

7.6 Viewing the Markit SLT Interface Browser

You can view all the incoming messages from Markit using the ‘Markit SLT Interface Browser’ screen. This section contains the following topics:

You can invoke the ‘Markit SLT Interface Browser Detailed’ screen by typing ‘TLDMKTIF’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.

 

In this screen, the Markit details are populated without any translation/resolution. Each row is populated for a Markit Message ID.

System displays the following details in this screen:

Message Status

System updates the message status while processing the Markit messages or during settlement in Oracle FLEXCUBE. System displays only of the following values:

Markit Trade Status

System updates the Markit trade status while processing the Markit messages or during settlement in Oracle FLEXCUBE. System displays only of the following values:

7.6.1 Viewing Trade Details

You can view the trade details of multiple tranches under a Markit Trade id in the ‘Trade Details’ screen. You can invoke this screen by clicking the ‘Trade’ tab in the ‘Markit SLT Interface Browser Detailed’ screen.

 

7.6.2 Viewing Allocation Details

You can view the allocation details for an allocation id using the ‘Allocation Details’ screen. Each allocation can have trade details of multiple tranches under a Markit Trade. You can invoke this screen by clicking the ‘Markit Allocation Details’ tab in the ‘Markit SLT Interface Browser Detailed’ screen.

 

7.6.3 Viewing Currency-wise Settlement Details

You can view the currency-wise net settlement amount across the tranches under a Markit Trade id using the ‘Currency wise Settlement Details’ screen. To invoke this screen, click the ‘Currency wise Settlement Details’ tab in the ‘Markit SLT Interface Browser Detailed’ screen.

 

7.6.4 Viewing the Error Messages

You can view the exception details for all the trades using the ‘Exception’ tab.

 

The exception details that are logged in the Markit SLT interface Browser are as follows:

CUSIP/TradeID

Exception Details

 

TradeID-1

 

MEI code is not found in Oracle FLEXCUBE for CUSIP-2

 

Invalid Accrual settlement type for CUSIP-3

7.7 Matching Process and Manual Linkage of SLT and Markit Trades

Matching is the process to uniquely identify the associated SLT trade in Oracle FLEXCUBE for each of the trade sent from Markit under a Markit Trade id. The matching process is initiated based on the following scenarios:

You can match the Oracle FLEXCUBE SLT trade with market trade using the following primary fields:

If the trade goes through Markit Settlement Process, then each LQT trade to Oracle FLEXCUBE should have a ‘Markit Trade ID’. LQT should also send ‘Markit Allocation ID’ for the allocated Trades along with Markit Trade ID. If the Trade is not of type Allocation, then the Allocation ID is blank.

System does not allow you to change the Markit Trade ID and Allocation ID during manual trade amendment. Each message received from Markit comprises of a valid Trade ID and an associated LQT Ticket ID and each Trade ID/Allocation ID can have multiple tranche details.

During the matching process, the following fields are compared along with the primary fields between Oracle FLEXCUBE SLT Trade and the Markit trade:

If the above listed fields do not match, then the match status is updated as ‘Unmatched’. The exception details are logged and the Trade Reference Number will be blank. If Match status is ‘Unmatched’, then you can manually link a SLT Trade reference number to a Markit Trade in the settlement queue.

Enriching Trade reference number is possible only is the following criteria are met:

In case of manual linking, if the value is null, then the Markit Trade ID/Allocation ID of the Markit trade is updated for the SLT Trade in Oracle FLEXCUBE.

If there is any trade amendment/settlement which leads to TAMD/TCNC/TREV/TSTL events for the trade, then system automatically changes the match status from ‘Matched’ to ‘Unmatched’ for the unsettled trades in the Settlement Queue. If the Match status is ‘Unmatched’, then you can manually initiate the matching process from Trade settlement queue. Matching is also done during manual trade settlement processing from trade settlement queue.

If there are any unauthorized transactions pending for Markit trades in the trade settlement queue, you cannot close the EOD batch in Oracle FLEXCUBE.

7.8 Settlement Queue for Markit Trades

You can view the settlement details for Markit trades as well as query details based on the status and the various Markit and Oracle FLEXCUBE identifiers using the ‘Markit Trade Settlement Queue’ screen. This section contains the following topics:

You can invoke the ‘Markit Trade Settlement Queue Detailed’ screen by typing ‘TLDTRDSQ’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.

 

In this screen, each row is populated for a SLT trade reference number.

Each Markit message is split into one/many trades to match the Oracle FLEXCUBE SLT Trade Reference numbers, based on the number of allocations/CUSIP’s in the message. This screen has a row for each allocation/trade, so that each row is mapped to one SLT Trade reference number in Oracle FLEXCUBE.

System displays the following details in this screen:

Specify the following details:

Process settlement

Select this check box to manually initiate trade settlement for the trade. This box is enabled only after the final closure message is received from Markit.

Suppress Payment Message

Select this check box if you want to suppress the payment message during trade settlement. This check box is selected based on the product setup. However, you can edit this check box.

Suppress Funding Memo

Select this check box if you want to suppress the funding memo during trade settlement. This check box is selected based on the product setup. However, you can edit this check box.

Click the ‘Initiate Matching Process’ button to force the matching process for resolving the trade reference number. This is done in view mode, and SLT trade reference number is populated with the match status as ‘Matched’ after successful matching; else the match status is marked as ’Unmatched’ and the trade reference number is set to blank.

7.8.1 Viewing the SSI Mnemonic Details

You can view the Oracle FLEXCUBE settlement details of the trade counterparties and Agent using the ‘Flexcube SSI Mnemonic’ screen. To invoke this screen, click the ‘SSI Mnemonic’ tab in the ‘Markit Trade Settlement Queue Detailed’ screen.

 

7.8.2 Viewing the Funding Memo Details

You can view the final settlement amount in the ‘Funding Memo Details’ screen. To invoke this screen, click the ‘Funding Memo’ button in the ‘Markit Trade Settlement Queue’ (TLDTRDSQ) screen.

7.8.3 Viewing the Funding Memo Reconciliation Details

You can view the funding memo details of Markit and Oracle FLEXCUBE for manual reconciliation using the ‘Markit Trade Settlement Queue’ screen. To invoke this screen, click the ‘Fmemo Reconciliation’ tab in the ‘Markit Trade Settlement Queue’ (TLDTRDSQ) screen.

 

Trade reference number is the primary field under which the following details are provided:

Oracle FLEXCUBE

Markit

Commitment reduction amount

The difference between TradedCommitmentAmount and RevisedCommitmentAmount under MultiFacilitySettlement­Details-->facilitySettlementDetails. This will be trade portion of commitment reduction amount

Buyer’s share of Funded amount for each drawdown

Traded portion of the funded amount sent from Markit in con­tract -> participationAmount -> shareAmount

DCF amount for each draw­down

As summarized in DCF reconciliation table

The following DCF reconciliation table given below provides the details of the various Fee Categories associated with Delayed Compensation Fee and the resolution process in Oracle FLEXCUBE for each category:

DCF Computation

Category

Description

Settlement

Oracle FLEXCUBE resolution from Markit message

DCF Compu­tation on interest type category

Margin Rate for Fixed type Drawdowns

Margin Rate is applied on the Draw­down(amt) which has Fixed interest

Seller to Buyer

The expected business process is that there is always be one funded DCF category for each drawdown. So Markit match can be done one to one, based on the Con­tract Id and Oracle FLEX­CUBE Drawdown Ref match

All-in-rate inter­est for Fixed type Drawdowns

All-in-Rate is applied on the Draw­down(amt) which has Fixed interest

Seller to Buyer

The expected business process is that there is always be one funded DCF category for each drawdown. So Markit match can be done one to one, based on the Con­tract Id and Oracle FLEX­CUBE Drawdown Ref match

All-in-rate inter­est for Floating type Drawdowns

All-in-Rate is applied on the Draw­down(amt) which has floating interest

Seller to Buyer

The expected business process is that there is always be one funded DCF category for each drawdown. So Markit match can be done one to one, based on the Con­tract Id and Oracle FLEX­CUBE Drawdown Ref match

DCF Cost of Funds for Float­ing type Draw­downs

Average Libor Rate is applied on the Draw­down which has float­ing interest

Buyer to Seller

The expected business process is that there is always be one funded DCF category for each drawdown. So Markit match can be done one to one, based on the Con­tract Id and Oracle FLEX­CUBE Drawdown Ref match

DCF Compu­tation on both Funded/unfunded Amount

DCF for Cost of Carry

The computation is based on Rule of 25

 

This is not reconciled ,as its applicable only for Dis­tressed, and Markit scope is for PAR & TRS only

DCF Compu­tation on Fee type category

Commitment Fee

Commitment Fee Rate applied on unu­tilized Commitment amount

Seller to Buyer

Sum of all these four fees for the tranche is com­pared with the DCF fee amount received for the contractid that Oracle FLEXCUBE had sent in the ongoing fee msg as part of the agency mes­sages, based on the Con­tract Id and Oracle FLEXCUBE Drawdown Ref match.

Utilization Fee

Utilization Fee Rate applied on Total out­standing amount

Seller to Buyer

Facility Fee

Facility Fee Rate applied on the Trans­fer_avl(available+out­standing) balance for a tranche

Seller to Buyer

Letter of Credit (LC)Fee

LC Fee Rate applied on LC outstanding

Seller to Buyer

Markit can send a record for a contract Id with the total DCF fees (for all the 4 fee type DCF categories and any of the Interest type DCF categories), since Oracle FLEXCUBE could have sent that contract id in the ongoing fee notice. In this case, the amount of all the 4 fee type of DCF categories and any of the 4 interest type DCF categories are summed up and reconciled with the amount sent from Markit.

The fee types given below are not be part of the Funding Memo Reconciliation as Markit does not send these fee details in the Settlement Details Notice message:

Fee Type

LQT Sent

Oracle FLEXCUBE Computed

Adhoc Fees

Yes

No

Amendment Fee

Yes

No

Assignment Fee

Yes

No

Broker Fee

Yes

No

Waiver Fee

Yes

No

Break-Funding Fee

No

Yes

Upfront Fee

No

Yes

Benefit of Commitment Reduc­tion Fee(BCR Fee)

No

Yes

For a combination of payment type, payment amount currency, payer and receiver, Markit sends the 'settlementAmount’. The ‘settlementAmount’ from Markit is at a Markit Trade Id level; therefore it is the sum of settlement amounts of all underlying Tranche/CUSIP/ISIN’s of the Trade Id. Details are displayed by arriving at the sum of all the settlement amounts, excluding fee, for all underlying SLT Trades for the trade id/allocation id and displayed with Markit’s settlement amount for the Trade Id.

The ‘settlementAmount à paymentAmount’ received from Markit are displayed along with each of the currency settlement details against the Oracle FLEXCUBE settlement amount.

The funding Memo reconciliation is a manual process done by the user. System only displays the funding memo details of Oracle FLEXCUBE and Markit in this screen.

Markit can also send the origination trade (CLP trades) which is the PO trade (Par settling to the counterparty). System identifies the associated line trades under the CUSIP/ticket id. On manual initiation of settlement, system settles all the three trades on the settlement of the PO trade. System validations ensure that the PL/OL trades are in place and the amounts for each match, will be done prior to initiating the settlement.

The buyer’s share of funded amount for each drawdown is processed as follows:

7.8.4 Viewing the Exception Log

You can view the exception details for any trades in Rejected/Failed status using the ‘Error Messages’ screen. To invoke this screen, click the ‘Exceptions’ tab in the ‘Markit Trade Settlement Queue Detailed’ screen.

 

The exception details that are logged in ‘Markit Trade Settlement Queue Detailed’ screen are as follows:

CUSIP/Trade ID

Exception Details

CUSIP-1

MEI code is not found in Oracle FLEXCUBE for CUSIP-2

Invalid Accrual settlement type for CUSIP-3

CUSIP-2

MEI code is not found in Oracle FLEXCUBE for CUSIP-2

Invalid Accrual settlement type for CUSIP-3

CUSIP-3

MEI code is not found in Oracle FLEXCUBE for CUSIP-2

Invalid Accrual settlement type for CUSIP-3

7.9 Viewing LQT Mnemonic Browser Details

You can view the trade details which are not settled with the process status as ‘Unprocessed’ in the ‘LQT Mnemonic Browser’ screen for trade for which counterparty mnemonic is amended. You can invoke the ‘LQT Mnemonic Browser’ screen by typing ‘TLDCPMND’ 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:

During authorization of the counterparty mnemonic and GFCID mapping, the system identifies the trades from LQT browser based on the counterparty mnemonic and checks the settled trade status.

The system pick up the open trades to update the counterparty and TAMD event are registered. SSI mnemonic is re-picked up based on the new counterparty. Once successfully processed, the system updates the process status as ‘Processed’

If the processing is failed for any reason, the system marks the process status as ‘Failed’, and the exception can be viewed from the error log button of trade draft screen.

Amendment is allowed but you are not be allowed to reprocess the failed version, if the latest amendment exists for the trade

To reprocess, you need select the trades which need to be re-processed and click on ‘Reprocess’ button which changes the process status for the trades to ‘Reprocess’ and the job pickups trade to reprocess.