16. FpML Messaging

This chapter contains the following sections:

16.1 Introduction

FpML (Financial products Markup Language) is an XML based message standard used for complex financial products. Oracle FLEXCUBE supports generation of messages (notices) using this format. The messages can be broadly categorized into two groups:

The system supports FpML messaging for regular back-valued activity, which is not prior to any other activity. This is treated as any other current dated activity message. Any back-valued activity prior to any other event is suppressed by the system.

This chapter discusses these notices, the maintenances required and the validations that the system performs as part of the message processing.

16.2 Maintenances Required for FpML

To generate FpML messages from agent to individual participants, you need to do the following:

To generate FpML messages to Markit, you are required to maintain all the messages that you wish to generate in the ‘Message Type Maintenance’ screen and in the borrower products (tranche/drawdown), you can associate the messages to the events for which the messages should be generated. The messages to Markit are generated when the contract to which the message is attached is saved and it is handed off during authorization of these contracts.

Refer the following for more details on these screens:

16.3 Handling Initial Validations for FpML Messages

As mentioned earlier, there are various types of FpML messages that can be generated. These typically include notices from agent to individual participants, manually-generated notices to Markit, system-generated notices to Markit and updates relating to CUSIP and MEI CODE changes to Markit.

In case of notices generated to Markit, the system ensures that:

If any of the validation fails, the system suppresses the message.

Note

For display of MEI Code of the consolidated participants, note the following:

 

16.4 Notices from Agent to Investors

The following are the notices sent from Agent to Investors which can be generated in the FpML format:

To generate FpML messages, you need to maintain the Advice format for the FpML notice in ‘Advice Format Maintenance’ screen with the media value specified as ‘FPML’. These advices are in turn attached to the related events at participant product level.

Note

If you want to generate both FpML as well as non-FpML notices for an event, you need to attach both the advices at the product level.

16.4.1 Pricing Change Message

You need to maintain the following details in the ‘Free Format Message Template’ screen:

Select the ‘MAIL’ template in the ‘MAIL’ tab. On selection of the ‘MAIL’ template, the corresponding FpML template to which the ‘MAIL’ template is mapped is arrived at and the FpML template is updated in the ‘FPML’ tab

Entity details with media as ‘FPML’ is updated in the Entity section of the ‘Free Format Message’ screen for the entities associated with the Contract participants for which the ‘Send FPML’ option is selected. For any participant if there are no entities for which the ‘Send FPML’ option is selected, the FPML tabis disabled and the FPML template will not be populated.

Message Preview or Generate generates the MAIL notices and in addition, generates the FPML notice for all the entities for which the ‘Send FPML’ option is selected.

Pricing change free format message is similar to the automated pricing change notice which is getting generated in the FpML format on Margin changes//Fee rate changes for Tranche contracts.

The factory-shipped templates that are provided for pricing change free format message generation are as follows:

Pricing change notice for Fee Rate or Margin Rate change is generated at the tranche level. During the price change message generation, the system prompts for ‘Schedule date’ (user input date) which should match with Fee/Margin rate maintenance schedule date to pick up the rate. If the date is not matching, the message tags are printed blank.

Note

Fee rate change and Margin rate change free format messages are generated individual­ly.

16.5 Generating Notices Manually

You can manually generate the following notices as and when required from the ‘FpML Adhoc Message’ screen. All the notices are generated for the ZAMG event

Refer the chapter ‘Processing Outgoing Messages’ in the Messaging System User Manual for details of the screen.

16.5.1 Take on Deal Definition

The Take on Deal Definition notice can be generated for tranches that have not yet been sent to MarkIt. The system will ensure that the tranche details are sent only for the first tranche under the deal (facility) and that the tranches are not generated or handed-off more than once. You will be allowed to generate other FpML messages for tranches/ drawdowns only if the Take on Deal /Take On Facility Definition messages have been generated and handed-off to MarkIt.

The message will display ‘Ext Deal CUSIP/ISIN’ captured at the tranche level for the ‘InstrumentId’ field in ‘Deal Summary’.

Note

Assignment validation details are populated for each tranche in the Take on Deal Defini­tion Notice.

16.5.2 Take on Facility Definition

The Take on Facility Definition notice can be generated for tranches that have not yet been sent to MarkIt. The system ensures that the tranche details that are being sent are not for the first tranche under the deal (facility) and that the tranches are not generated or handed-off more than once. You are allowed to generate other FpML messages for tranches/ drawdowns only if the Take on Deal /Take On Facility Definition messages have been generated and handed-off to MarkIt.

The message display ‘Ext Deal CUSIP/ISIN’ captured at the tranche level for the ‘InstrumentId’ field in ‘Deal Summary’.

Note

Assignment validation details are populated for each tranche in the Take on Facility Defi­nition Notice.

16.5.3 Position Update of Position Statement Type

The Position Update message which contains the participant position details is generated at the borrower level. For each tranche, the details are grouped for participants for the tranche and sent as a single bulk message. You can manually send this message as a follow-up message for the ‘PositionStatement’ event type when the details of the deal or tranche are sent to Markit for the first time.

This message can be used at a tranche or drawdown level for all the participants under the tranche or drawdown and is generated only after the Take on Deal / Take on Facility notices have been generated and handed-off to Markit.

The message displays ‘Ext Deal CUSIP/ISIN’ captured at the tranche level for the ‘InstrumentId’ field in ‘Deal Summary’.

16.5.4 Drawdown Notice

The Drawdown Notice is generated at the borrower level for new drawdown bookings and principal increases on drawdowns. The notice consists of a notice for each participant and a notice for the global details for the borrower.

The message display ‘Ext Deal CUSIP/ISIN’ captured at the tranche level for the ‘InstrumentId’ field in ‘Deal Summary’.

16.5.5 Cancel Notice

The Cancel notice is generated to reverse specific notices already sent to Markit and for payment and value-dated amendment reversals.

16.6 System generated Messages

The following messages are generated by system automatically:

16.6.1 Commitment Adjustment Notice

The Commitment Adjustment notice, which is generated at the borrower level, is generated whenever principal is increased or decreased for a tranche. It has all the participant and global details and consist of a message for each participant and a message for global details for borrower. You need to maintain the message for the VAMB event for tranche products to generate the notice for tranche value-dated amendment notice.

If there are no principal changes for the value-dated amendment or if the amendment results in the tranche being decreased to nil principal and the maturity date to less than or equal to today, this notice is suppressed. You can also suppress the generation during value dated amendment if you require. Since the notice is generated only for principal changes done directly on the tranche and not as a result of any drawdown activity, the system does not generate the notice for drawdown payments on non-revolver tranches.

The message display ‘Ext Deal CUSIP/ISIN’ captured at the tranche level for the ‘InstrumentId’ field in ‘Deal Summary’.

16.6.2 Deal Definition Notice

The Deal Definition Notice is generated for tranche amendments on a tranche at the borrower level, if the contract status is updated to ‘Liquidated’. This implies that there is one message for a tranche value-dated amendment for tranche amendment. You need to maintain the message for the event VAMI for tranche products.

You can suppress this notice during value-dated amendment if you want. The system suppresses this message when during value-dated amendments the tranche contract status does not get updated to ‘Liquidated’. This is applicable for both value-dated amendments done manually and those due to SLT-LB STP.

The message display ‘Ext Deal CUSIP/ISIN’ captured at the tranche level for the ‘InstrumentId’ field in ‘Deal Summary’.

16.6.2.1 Deal Definition Notice with all Tranches for Ext Deal CUSIP/ISIN

Deal Definition Notice generated for facility/deal amendment contains details of all the active tranches that have the same Ext Deal CUSIP/ISIN as that of the facility/deal CUSIP, provided Take on Deal/Take on Facility and Position Update for Position Statement type have already been generated for all those tranches.

Deal Definition notice generated for tranche amendment contains details of all the active tranches that have the same Ext Deal CUSIP/ISIN as that of the tranche which being amended, provided Take on Deal/Take on Facility and Position Update for Position Statement type have already been generated for all those tranches.

This notice does not contain details of tranches for which Take on Deal/Take on Facility and Position Update for Position Statement type is not generated. In this case, the notice generation does not fail but excludes such tranches.

Deal Definition notice generation for a facility/deal amendment is suppressed systematically if none of the tranches under the facility/deal have the Ext Deal CUSIP/ISIN same as the facility CUSIP. Deal Definition notice for a facility/deal amendment is suppressed systematically if none of the tranches (with matching CUSIP) have Take on Deal/Take on Facility and Position Update for Position Statement type generated and handed off. This notice is suppressed systematically for a tranche amendment if the tranche does not have Take on Deal/Take on Facility and Position Update for Position Statement type already generated and handed off.

For Deal Definition generation for a tranche amendment, the details in the notice for the current tranche that is amended in Oracle FLEXCUBE contains the latest amended details and all other tranches contain the latest details. In case of facility/deal amendment, the latest details are present in the notice for all the tranches.

Note

This notice does not include details of previously liquidated/reversed tranches.

Deal Definition Notice generation for Tranche - Borrower/Co-borrower

Deal Definition Notice Generation for Facility/Deal - Assignment Fee Details

Deal Definition Notice is generated for all facility amendments (CAMD event) involving addition/amendment/removal of assignment fee details from the ‘Assignment Fees Details’ sub-screen in ‘LB Facility Contract Online’ screen.

For facility/deal - assignment fee details, this notice should be maintained for the CAMD event as part of the facility product setup.

Deal Definition Notice Generation for Tranche - Drawdown Currency

Deal Definition Notice is generated for all tranche amendments (CAMD event) involving addition/removal of currencies from the ‘Currency’ sub-screen in ‘LB tranche Contract Online’ screen.

For tranche - drawdown currency, this notice should be maintained for the CAMD event as part of the tranche product setup.

Deal Definition Notice Generation for Tranche - Maturity Date

Deal Definition Notice is generated for all tranche value dated amendments (VAMI event) involving change to the maturity date of the tranche.

In this scenario, this notice should be maintained for the VAMI event as part of the tranche product setup for the tranche which is getting amended.

Deal Definition Notice Generation for Tranche - Termination Date

Deal Definition Notice is generated for all tranche value dated amendments (VAMI event) involving change to the maturity date of the tranche and resulting in the tranche being liquidated. In this scenario, this notice should be maintained for the VAMI event as part of the tranche product setup for the tranche which is getting amended.

Deal Definition Notice Generation for Tranche - ‘Assignment Validations Appli­cable’ check box

Deal Definition Notice is generated for all tranche amendments (CAMD event) involving change to the ‘Assignment Validations Applicable’ check box in the ‘LB Tranche Contract Online’ screen. In this scenario, this notice should be maintained for CAMD event as part of the product setup.

Deal Definition Notice Generation for Tranche - ‘Assignment Validations’

Deal Definition Notice is generated for all tranche amendments (CAMD event) involving changes in details maintained in the ‘Assignment Validations‘ sub-screen in the ‘LB Tranche Online’ screen. In this scenario, this notice should be maintained for the CAMD event as part of the tranche product setup.

Deal Definition Notice is not generated if ’New Investor’ check box is amended in the ‘LB Tranche Online’ screen.

Note

Assignment validation details are populated for each tranche in the Deal Definition Notice.

16.6.3 Amend Contract Notice

The Amend Contract Notice is generated at the borrower level with one message for a drawdown amendment for the following event:

The message is a bulk message which consists of a message for each participant and a message for the global details for borrower. You need to maintain the message at the VAMB event for the drawdown product. If the VAMB event is for anything other than changes in maturity date , then the system suppresses the notice generation. You can manually suppress the notice during VAMB.

The message ‘Ext Deal CUSIP/ISIN’ captured at the tranche level for the ‘InstrumentId’ field in ‘Deal Summary’.

16.6.4 Rate Set Notice

The Rate Set Notice is generated at the borrower level with one message for a drawdown/tranche for the following events:

Rate Set Notice is a bulk message with borrower global level message and participant details. The bulk message constitutes the following messages grouped together:

You need to maintain the message at the VAMB, IRAM, MRFX, REVN and ERAM events for the drawdown product. If the VAMB event is for anything other than changes in interest rate, the system systematically suppresses the notice generation. In addition, you can manually suppress the notice during VAMB but not during IRAM, ERAM, MRFX, FRFX, and REVN events.

If the fee rate change involves fee rate change for multiple fee components, then system generates one message for each fee component for which the rate is changed. Rate set notice for Interest/Margin/Exchange/Fee rate changes is applicable only when Take on Deal/Take on Facility FpML notice and Drawdown notice are generated. Position Update Notice should also be generated if you want to generate the Rate Set Notice.

The message will display ‘Ext Deal CUSIP/ISIN’ captured at the tranche level for the ‘InstrumentId’ field in ‘Deal Summary’.

16.6.5 Repayment Notice

The Repayment Notice is generated at the borrower level for partial or full payments of principal on the drawdown. It is a bulk message for a drawdown payment with all the participant and global details and consist of a message for each participant and a message for the global details for the borrower. You need to maintain the message at the LIQD event for drawdown products.

If the payment is only for the interest, the system will suppress the notice. If the payment is for both interest and principal, then the system will generate the Interest Payment Notice for the interest liquidated and the Repayment Notice for the principal liquidated. You cannot suppress the notice generation manually during drawdown payment. However, by doing a contact amendment in the Drawdown online screen, you can suppress the message. If needed, before making the payment, an amendment can be done to suppress the notice for the termination and then payment can be done.

The message ‘Ext Deal CUSIP/ISIN’ captured at the tranche level for the ‘InstrumentId’ field in ‘Deal Summary’.

16.6.6 Interest Payment Notice

The Interest Payment Notice is generated at the borrower level for full or partial interest payments on the drawdown. It is a bulk message for drawdown interest with all the participants and global details and consist of a message for each participant and a message for the global details for the borrower. You need to maintain the message at the LIQD event for drawdown products.

If the payment is only for the principal, the system suppresses the notice. If the payment is for both interest and principal, then the system generates the Interest Payment Notice for the interest liquidated and the Repayment Notice for the principal liquidated. Or it can bulk the two notices if principal and interest are being paid together.

You cannot suppress the notice generation manually during drawdown payment. However, by doing a contact amendment (CAMD) in the Drawdown online screen, you can suppress the message. If needed, before making the payment, an amendment can be done to suppress the notice for the termination and then payment can be done.

The message ‘Ext Deal CUSIP/ISIN’ captured at the tranche level for the ‘InstrumentId’ field in ‘Deal Summary’.

16.6.7 LC Issuance Notice

The LC Issuance Notice is generated at the borrower level with one bulk message for a LC drawdown with all the participant and global details. It consists of a message for each participant and a message for the global details for the borrower. It is generated for:

To have this message generated, the ‘LC Drawdown’ preference should be selected at the drawdown level. You need to maintain the message for the following events for LC drawdown products:

You should not maintain drawdown notices for the BOOK, VAMB and DNOT events since maintaining this would lead to LC Issuance notices being generated for those drawdowns instead. You can suppress the notice manually for the new LC drawdown bookings but not for the LC increases and decreases. However, by doing a contact amendment (CAMD) in the Drawdown online screen, you can suppress the message. If needed, before making the payment, an amendment can be done to suppress the notice for the termination and then payment can be done.

The message ‘Ext Deal CUSIP/ISIN’ captured at the tranche level for the ‘InstrumentId’ field in ‘Deal Summary’.

16.6.8 LC Termination Notice

The LC Termination Notice is generated at the borrower level with one bulk message containing all the participant and global details. It consists of a message for each participant and a message for the global details for the borrower. It is generated for full payments on LC drawdown.

You need to maintain the message for the LIQD event for LC drawdown product. The message will be generated only if the ‘LC Drawdown’ preference has been selected at the drawdown level and the status of the LC drawdown contract is ‘Liquidated’. If the status is not ‘Liquidated’, then the system will suppress the generation of this message.

You cannot manually suppress the message during LC drawdown payment. However, by doing a contact amendment (CAMD) in the Drawdown online screen, you can suppress the message. If needed, before making the payment, an amendment can be done to suppress the notice for the termination and then payment can be done.

The message ‘Ext Deal CUSIP/ISIN’ captured at the tranche level for the ‘InstrumentId’ field in ‘Deal Summary’.

16.6.9 Ongoing Fee Notice

The Ongoing Fee Notice is generated at the borrower level with one bulk message for a tranche and have all participant and global details. The message consists of one message for each participant and one message for the global details for the borrower. It is generated for:

The fees which are supported by Markit are:

You are required to map these fees to fee components in Oracle FLEXCUBE to facilitate the generation of notices. To generate the notice for fee details and send it for the first time to Markit, you need to maintain the message for BOOK/FBOK/FAMD event for tranche products. For generation of notice for fee payment, you need to maintain the message for FLIQ event for tranche products. The notice for new booking/fee capture does not include the fee payment details, while the notice generated for fee liquidation will.

If there are non-adhoc fee components added newly as part of fee capture or fee amendment, then the notice is generated for the FBOK/FAMD event. If non-adhoc fee components are defined during tranche booking itself and changes are done during fee amendment, then the system will suppress the notice generation for the FBOK/FAMD event. System suppresses the notice generation for any fee rate changes (FRFX) for non-adhoc fee components.

The system will suppress the notice generation for the adhoc fee components for the BOOK event if adhoc fee components have been captured as part of tranche booking or if there are no non-adhoc fee components for which payment is done as part of the FLIQ event. You can manually suppress the notice generation during tranche booking but not during fee amendment, fee liquidation and fee revision.

The message ‘Ext Deal CUSIP/ISIN’ captured at the tranche level for the ‘InstrumentId’ field in ‘Deal Summary’.

16.6.10 One Off Fee Notice

The One Off Fee notice is generated at the borrower level with one bulk message for a tranche with all participant and global details. The message consists of a message for each participant and a message for the global details for the borrower. It is generated for fee payments of adhoc fee (USERINPUT type) components at tranche level.

The fees which are supported by Markit are:

You are required to map these fees to fee components in Oracle FLEXCUBE to facilitate the generation of notices. You need to maintain the message for FLIQ event for the tranche products.

If there are no adhoc fee components in the fee payment, the system suppresses the generation of this notice. You cannot manually suppress the notice generation during fee liquidation.

The message ‘Ext Deal CUSIP/ISIN’ captured at the tranche level for the ‘InstrumentId’ field in ‘Deal Summary’.

16.6.11 Rollover Notice

The Rollover notice is generated at the borrower level with one bulk message for a tranche with all participant and global details. The message consists of a message for each participant and a message for the global details for the borrower. It is generated for the rollover (split or consolidated) or re-pricing (split or consolidated) of drawdowns.

The rollover message contains details of only the rollover. The system sends an increase or decrease as part of rollover or re-pricing as drawdown notice or repayment notice, as is defined for the respective VAMB/LIQD event only at the time of actual rollover, since the changes are triggered only at the time of actual rollover. The system suppresses the drawdown notice for the new child contract as the rollover notice would include a section for the child contract. You are not allowed to manually suppress the notice during rollover or reprice capture.

You need to maintain the message for the actual rollover events – ROLL/CROL/SPTI/MRGI – for the drawdown products. This is maintained at the actual rollover event instead of the usual RNOT/CRNT/SPTB/MRGB events as Markit expects the principal increase/decrease notices as part of the rollover to be sent along with the rollover notice. In addition, Markit requires the child drawdown contract id to be populated in the rollover notice, so that subsequent messages sent for the child contract are applied properly in Markit on the right child drawdown.

The rollover type mentioned in the notice, define the type of rollover done. The possible values are:

The message ‘Ext Deal CUSIP/ISIN’ captured at the tranche level for the ‘InstrumentId’ field in ‘Deal Summary’.

16.6.12 Reprice Message

Oracle FLEXCUBE supports both Merge Reprice and Split Reprice message generation in FpML format. The FpML formats used for generating messages for Rollover instruction processing is used for generating the FpML notice for Reprice events.

The Split Reprice advice is generated during SPNT event for drawdown contracts. The Reprice message is generated in FpML format for SPNT event. The message generation and handoff processing follows the similar processing of Split Reprice advice.

The Merge Reprice advice is generated during MRGB event for drawdown contracts. The Reprice message is generated in FpML format for MRGB event. The message generation and handoff processing follows the similar processing of Merge Reprice advice.

16.6.13 Drawdown Notice

The Drawdown Notice is generated at the borrower level for new drawdown bookings and principal increases on drawdowns. The notice consists of a notice for each participant and a notice for the global details for the borrower.

For generation for new drawdown bookings, you need to maintain this message at BOOK/DNOT event for drawdown products. For principal increases on drawdown, you need to maintain the message at the VAMB event for drawdown products. For both events, you have the option of suppressing the generation.

Principal increases on the drawdown caused due to rollover with increase and STL-LB STP activities will also result in the generation of the message. You do not have an option to suppress the generation for these operations.

The message ‘Ext Deal CUSIP/ISIN’ captured at the tranche level for the ‘InstrumentId’ field in ‘Deal Summary’Cancel Notice.

The Cancel notice is generated to reverse specific notices already sent to Markit and for payment and value-dated amendment reversals. You need to maintain the messages at the REVP event for drawdown products for payment reversals and the VAMC event for the value-dated amendment reversals for drawdown and tranche. The notice is sent for the message ID of the bulk messages sent for the payment / value-dated amendment – this covers all the underlying messages of the original bulk message.

16.6.14 Position Update of PositionStatement type

The Position Update message which contains the participant position details is generated at the borrower level. For each tranche, the details are grouped for participants for the tranche and sent as a single bulk message. You can send this message for the event ‘Assignment’ when there is a change in participant positions in a tranche. For this you need to maintain the message for the PRAM/PAMI events for tranche only.

This message can be used at a tranche or drawdown level for all the participants under the tranche or drawdown and is generated only after the Take on Deal / Take on Facility notices have been generated and handed-off to Markit.

The message ‘Ext Deal CUSIP/ISIN’ captured at the tranche level for the ‘InstrumentId’ field in ‘Deal Summary’.

16.6.15 Prime Increase Message

The system generates the Prime Increase FpML message for participants when additional borrowing is required for prime loans.

Prime Increase FpML message is generated only for the Drawdown contracts having Main Interest component with Rate Type as ‘FLOATING’. The system does not refer to the preference maintained for the box ‘Prime Loan’ at Drawdown product preference. The system determines the Drawdown as Prime if Floating Rate Type of Main Interest component is attached with the Drawdown.

Prime Increase is a Drawdown Value-Dated Amendment Event (VAMI) in Oracle FLEXCUBE to increase the Drawdown amount (Borrowing amount). The system generates the Prime Increase message during Value Dated Amendment operation.

The Prime Increase message is same as the drawdown message. The latest Drawdown amount including the amount that is increased in the Value Dated Amendment operation is sent in the Prime Increase message. The Prime Increase FpML message is generated for the ‘VAMB’ event

The system sends floatingRateIndex value as Prime/Libor for the Prime Increase message. Agent Ref No will be sent in the Prime Increase message if already available in the system, else Agent Ref No will be sent blank. Message Generation and Handoff processing follows the processing of Drawdown Advice.

16.6.16 Outgoing FPML Changes for Negative Rate

The following outgoing FpML notices sends interest and margin rates in negative if the rates are maintained in negative for the associated contracts.

Individual FpML messages for each participant

Notice Name

Associated Event

Remarks

Systematic / Free format

Drawdown Notice

DNOT

During drawdown booking

Systematic

Rate Reset Notice

IRFX

During drawdown Interest rate fixing

Systematic

Interest Payment Notice

NOTC

During Interest payment

Freeformat

Split Rollover Notice

RNOT

During Split Rollover booking

Systematic

Consolidated Rollover Notice

CRNT

During consol Rollover Booking

Systematic

Pricing Change Notice

MRFX

During Margin rate revision at drawdown level.

Systematic

 

Bulk FpML notices (One message with all participant details)

Notice Name

Associated Event

Remarks

Systematic / Free format?

Drawdown Notice

DNOT

During drawdown booking

Systematic

Rate Set Notice

IRAM

During Interest rate amend­ment

Systematic

VAMB

During interest rate amend­ment in VAMI screen

Systematic

MRFX

During drawdown Margin rate revision

Systematic

Interest Repayment Notice

LIQD

During full or partial interest payment on drawdown

Systematic

Split Rollover Notice

RNOT

During Split Rollover booking

Systematic

Consolidated Rollo­ver Notice

CRNT

During consol Rollover Book­ing

Systematic

 

16.7 Messages from Markit for Prime Increase

The Prime Increase message is consumed from Markit in the same way the drawdown message is consumed in Oracle FLEXCUBE. The system processes the new Drawdown message as Prime Increase message only when the following conditions are satisfied:

The checkbox ‘Prime Loan’ at Drawdown product preference is not used to determine the drawdown as Prime Drawdown.

If the agent reference number is already associated with an active Drawdown in Oracle FLEXCUBE, the system performs Prime increase by doing a value dated amendment for Drawdown(VAMI).

If the agent reference number is not associated with any Drawdown in Oracle FLEXCUBE then:

If FloatingRateIndex is not USD-Prime-Reference in the Drawdown message and the agent reference number is already associated with an active Drawdown in Oracle FLEXCUBE, the message processing will fail.

‘Agent Ref No’ is displayed in the ‘Value Dated Amendment’ screen. The system consumes and processes value dated amendment (prime increase)

Once the message is received from Markit and is displayed in the incoming interface browser, the system performs the basic validations of External CUSIP/ISIN, Message ID, Notice Date and MEI Code for participant(s) and borrower. These validations are similar to the validations of other messages which are consumed.

If any of the validations fail or the system is unable to process the message, the system logs the following exceptions:

If the incoming message fails to process due to any data mismatch between the incoming data and Oracle FLEXCUBE, you can use the ‘Enrich’ option for the key important fields.

For the message Prime increase notice, if the notice date is equal to the application date and the effective date is earlier than the application date, the system considers it as a back-dated value-dated amendment and all the back-value checks are applied.

The dual authorization functionality is applicable for these messages and status is updated as ‘Pending Authentication’ after which you have to manually authorize it. Once authorized, the system updates the process status as ‘Processed’.

Exception processing, Re-linking, Clipping of the message is applicable as per the incoming FpML message processing. Only amount increase is allowed as part of prime increase consumption processing.

Incoming messages with Message Name as ‘Drawdown Notice’ and DrawdownEventType as ‘NewDrawdownEvent’ are placed in the Incoming Browser with the processing status as ‘Pending’

The system processes these messages as follows:

Note

 

16.8 Messages from Markit for Trade Settlement

The following messages are communicated between Markit and Oracle FLEXCUBE for processing trade settlement from Markit for agented deals:

Message

Description

Occurrence

Flow

Trade Details - Agent View

Trade details that the agent can use to setup the trade in their system (LB). Trade is consumed in Oracle FLEXCUBE and is populated into the Agency confir­mation browser with all the rele­vant details of the trade.

Can be received multiple times prior to Settlement/ TradeUpdateNotification

Markit to Oracle FLEX­CUBE

Trade Status Update Notifica­tion

Markit trade status will be updated in Oracle FLEXCUBE based on the status received.

Cancelled/Removed/Suspended

Can be received only once prior to Settlement and it isoptional

Markit to Oracle FLEX­CUBE

Submit Agency Update

Notifies the update to agent to signify final transfer of asset is needed. Trade is marked as closed.

Can be received only once on Settlement

Markit to Oracle FLEX­CUBE

Position Update Notice

This is an inventory message and this is sent with type as "Assignment".
Oracle FLEXCUBE validates the position of the investor involved in the trade and update and build the message and send it back to Markit

Is sent only once on suc­cessful processing of Sub­mitAgencyUpdateNotice in Oracle FLEXCUBE

Oracle FLEX­CUBE to Markit

 

16.8.1 Syndicated Loan Trade Notice

The Syndicated Loan Trade Notice message is a trade-related message that is received from agent to set up the trade in Oracle FLEXCUBE. Each Syndicated Loan Trade Notice message contains the following details:

16.8.2 Trade Update Notice

The Trade Update Notice message is an update notification on the trade received from Markit to notify the trade status in Oracle FLEXCUBE. Each Trade Update Notification message contains the following details:

Each Trade Update Notification Message comprises the following primary details:

A system job processes all the uploaded messages. Based on the trade id, all the trades corresponding to this message are identified. If the trade id does not exist, then the message is marked as ‘Rejected’.

Confirmation status is updated as ‘Rejected’ for trades, based on this message. You cannot change the confirmation status for rejected trades. Trade Update Notification message is sent only if the trade settlement should be blocked in Markit/Oracle FLEXCUBE.

16.8.3 Processing of Trade Update Notice Message in LB Module

When any Trade Update Notice message with ‘Suspended’ status is processed for a Markit trade id, the trade is enabled and you can process it further.

System consumes the Syndicated Loan Trade Notice message for trade that is suspended. System also consumes this notice any number of times before processing the following messages:

Markit always sends a Trade Update Notice message for each allocation.

Markit does not send the Syndicated Loan Trade Notice message again for the allocation which is closed.

16.8.4 Processing of Trade Update Notice Message in SLT Module

When any Trade Update Notice message with ‘Suspended’ status is processed for a Markit trade id, the trade is enabled and you can process it further.

After receiving a trade with status as ‘Suspended’, system does not reject but consumes and processes the following messages:

For unallocated trades, Markit always sends Trade Match Notice and Settlement Details Notice messages together. After processing this Settlement Details Notice message, Trade Match Notice message can be received again. System consumes the Trade Match Notice messages without rejection, and processes them again for the same trade any number of times before Trade Closed Notice or Trade Update Notice is received with ‘Cancelled’ or ‘Removed’ status.

For allocated trades, Markit sends Trade Match Notice and Settlement Details Notice messages together for the parent trade, before the actual allocation. After allocation, Markit sends Settlement Details Notice for the allocated trades after Syndicated Loan Trade Allocation message.

For allocated trades, the following processing takes place:

If a new Trade Match Notice is received with ‘replacedTradeIdentifier’, then the trade mentioned in ‘replacedTradeIdentifier’ is marked as ‘Cancelled’ and the trade received as part of the Trade Match Notice is treated as a new trade. If any allocation is closed under a trade, then there is no impact on the closed trade as part of new trade processing.

If Trade Match Notice is received again for an existing Markit trade Id, then the old allocations are removed from the system and closed allocation(s), if any, are retained. New allocation received as part of Syndicated Loan Trade Allocation is used for further processing. If any of the allocation is closed, then new allocation message should also contain details of closed allocation along with new allocation.

After an allocation is closed under a trade, if Markit sends Trade Match Notice with ‘replacedTradeIdentifier’ and Syndicated Loan Trade Allocation with new allocations, then:

After receiving new Syndicated Loan Trade Allocation message for SLT, new Syndicated Loan Trade Notice Agent should be sent again for agency. Settlement is not done in LB until the matched Markit trade is settled in SLT.

Trade Update Notice is received at Markit trade id level and not at individual allocation level. System does not validate the allocation ids sent by Markit in the Trade Update Notification but marks all allocations (for allocated trades) under the Markit Trade Id as Suspended/Cancelled/Removed.

Trade Update Notice message with status as ‘Suspended’ can be received multiple times before Trade Closure

Trade Update Notice with status as ‘Cancelled or ‘Removed’ can be received after receiving Trade Update Notice with status as ‘Suspended’

16.8.5 Submit Agency Update Notice

The Submit Agency Update Notice message is the closure message for a trade that has already been received from Markit to notify that the trade is closed in Markit and settlement can be initiated systematically in Oracle FLEXCUBE.

The Submit Agency Update Notice message contains the following details:

Each Submit Agency Update Notice Message comprises the following primary details:

A system job processes all the uploaded messages. On receipt of this message when system is in online mode during intra-day, the trade is marked as ‘Closed’ in the system and the position update message is sent to Markit, based on the following:

If this message is received when the system is in batch mode, then message is processed as follows:

The message processing is successful only when the validations are successful and the Position Update message is handed off to Markit. The following details are updated in the system on successful processing of the Submit Agency Update Notice message:

If the message processing fails, then the following details are updated in the system:

If the buyer/seller/SLT trade is not resolved, then the trade is rejected. You can enrich the trade by selecting the buyer/seller/SLT trade manually. Combination of Markit trade ID and Ext CUSIP/tranche reference number should be selected to fetch a single record. On enriching the buyer/seller, system does the following:

Buyer/Seller is defaulted to all other trades under that Markit trade ID. If bank counterparty is involved, then you should resolve SLT trade for all trades under that Markit trade ID. If resolution of SLT trade can be done for all records, closure processing takes place status is updated accordingly. If System could not resolve SLT trade reference number for any of the trades, then the resolved SLT trade reference numbers remain with the tranches and status fields are not changed. If bank counterparty is not involved, then closure processing takes place and the status fields are changed accordingly.

Enrichment is allowed for SLT trade only if bank counterparty is involved in the trade. On enriching the SLT trade reference number, system carries out validations/resolution is done based on buyer/seller and for all other tranches trade reference number under Markit trade ID.

16.8.6 Position Update Notice

Once all the trades for a Markit Trade Id are marked as ‘Closed’, system sends the Position Update Notice message to Markit for all such trades. Once this message is generated successfully, you can view the message in the ‘FpML Message Browser’. Position update message for a Markit Trade ID will not be allowed to generate/ handoff from this Browser. If message generation fails, it should be generated after user marks for reprocessing from Markit Agency Interface Browser

One bulk Position Update message is generated for all the tranches(facilities) under the Markit Trade Id.

Position Update message for a CUSIP/ISIN is sent only if the Original Take-on Facility/Take-On Deal message was already sent to Markit along with Initial Position Update message. If Take-On deal/facility message is not sent to Markit for a CUSIP/ISIN under a Markit Trade id, then the Position Update message for all the CUSIP/ISIN’s under the Trade ID will not be sent to Markit.

Position Update message would consists of the following primary fields;

Appropriate Position Update message status is updated in Markit Agency Interface Browser. This status indicates whether or not system has sent the Position Update message to Markit successfully for a Markit Trade id.

System does not initiate Consolidation and Trade Processing until the position update message is generated and handed-off to Markit successfully.

Note

16.9 Impact of Markit Trades on Tranches and Drawdowns in LB

Since the Position Update message is sent to Markit before the ‘Participant Transfer’ is actually processed in LB Tranche, there is an impact on processing of events in the LB module. When the actual Participant Transfer is triggered in LB tranche as a result of message from Markit, the generation of Position Update message is suppressed during participant transfer.

For the tranches for which Markit messages have been received for trade processing and the Position Update message has been handed off to Markit, system does not allow processing of any events which could send FpML messages to Markit (based on the product event advice setup) till the actual Participant Transfer is done on the tranche. The following table lists the screens where this validation is done and processing is blocked:

Sl. No

Screen Name

Blocking events

1

Borrower Tranche Input

To block Reversal

2

Messaging Processes- FpML Adhoc Message

To block the generation of position update message for the external CUSIP/ISIN

3

Borrower Drawdown Input

To block new Drawdown booking /Reversal

4

Fee Liquidation

To Block new FLIQ

5

Fee Amendment

To Block FAMD

6

Fee Rule Maintenance

To block Fee rule maintenance

7

Interest Rate Fixing

To block IRAM(Interest Rate Amendment)

8

Participant Transfer

To block Any new participant Transfer

9

Value Dated Amendment

To block any amendment and also reversal

10

Repricing

To block new Repricing for a contract

12

Draft Transfer

To block any new participant transfer for the contract

13

Manual Payment

To block new payment and payment rever­sal

14

Consol Rollver Input

To block rollover for a contract

15

Trade Settlement

To block any settlement which will change the participant ratio for the corresponding external CUSIP

16

Ticket Settlement

To block any settlement which will change the participant ratio for the corresponding external CUSIP

In scenarios, where there is a necessity to process a particular event on a tranche or on its underlying Drawdowns and the actual automatic participant transfer (assignment) is still pending processing, the processing of Participant Transfer can be done manually from the ‘Pending Trade Processing Queue’ for the tranche.

16.10 Handling Status for Processing Markit Agency Trade Settlement

Following are the various statuses handled for processing Markit Trades and Agency Trade Settlement in the system:

These messages have been explained in detail in the following sections.

16.10.1 Message Status

Details on Message Status are given below:

16.10.2 Markit Trade Status

Details on Markit Trade Status are given below:

16.10.3 Confirmation Status

Details on Confirmation Status are given below:

16.10.4 Process Status

Details on Process Status are given below:

16.10.5 Position Update Message Status

Details on Position Update Message Status are given below:

16.10.6 Participant Transfer Process Status

Details on Position Update Message Status are given below:

16.11 Messages from Markit for Trade Settlement in SLT

The messages received from Markit are mainly for identifying the workflow, displaying the funding memo and enabling the user for initiating SLT trade settlement.

The following messages are communicated from Markit to Oracle FLEXCUBE for processing trade settlement from in SLT module:

Message

Description

Occurrence

Flow

Trade Match Notification

Markit sends successful match mes­sage to both buyer and seller of the trade. System consumes this mes­sage and populates it in the Trade settlement Queue to do a trade match

Can be received multiple times prior to Settle­ment

Markit to Oracle FLEXCUBE

Trade Allo­cation

Message

Allocation definition structure.
System consumes this message and populates in the Trade settlement Queue and does a trade match

Can be received multiple times prior to Settle­ment

Markit to Oracle FLEXCUBE

Trade Status Update Noti­fication

Possible Trade Status from Markit:

  • Suspended
  • Cancelled
  • Removed

Can be received only once prior to Settlement

Markit to Oracle FLEXCUBE

Settlement Details

Settlement details for a Secondary trade.
This is the Markit funding memo that system uses to compare with the Funding memo generated by the system as per the balances in the system.

Can be received multiple times prior to Settle­ment

Markit to Oracle FLEXCUBE

Trade Closed

Notification of trade closing for coun­terparties from Markit

Can be received only once on clo­sure of the trade in Markit

Markit to Oracle FLEXCUBE

 

The FpML message from Markit would be parsed by the Java adapter. If ‘Markit Trade Settlement Allowed’ box is deselected in ‘Loans Parameters’ screen, then Markit messages are not processed in the system. However, if this check box is selected, then all the Markit messages are uploaded by the Java adapter the system.

16.11.1 Trade Match Notice

Trade Match Notice message is the first message received from Markit to initiate SLT trade settlement process in Oracle FLEXCUBE.

Each Trade Match Notice message consists of the following primary details:

Each message from Markit can have trade details of multiple trades under one facility. The following details are the same across all the trades (CUSIP/ISINs) under the message:

The following primary details are sent from Markit to Oracle FLEXCUBE as part of Trade Match Notice message:

Markit Fields

Description

Party

MEI code of the buyer and seller

Approval

Approval Type, status and approver details. These are used by the system for user information only. No pro­cessing impact

replacedTradeIdentifier

This indicates the old Markit trade that is being replaced by the current Markit trade. The replaced Trade Identifier should be a valid Markit Trade ID that was previously consumed by Oracle FLEXCUBE

Product Type

It is always ‘SyndicatedLoanTradeNotice’

TradeID

Unique Trade Id for each Markit trade. It consists of two Id’s, Markit Trade Id and LQT Ticket Id which is the Ticket Id of the SLT trade

SellerTradingParty

Reference to the Party who sells the position

BuyerTradingParty

Reference to the Party who buys the position

TradeDate

Trade Date

ExpectedSettlementDate

Expected Settlement Date of all the trades under this Markit Trade ID

TradingAssociation

LSTA / LMA. Applicable for all the Trades under a Markit TradeID

DocumentationType

Par/ Distressed. Applicable for all the Trades under a Markit TradeID

FormOfPurchase

Assignment or Assignment-Only Applicable for all the Trades under a Markit TradeID. Any other type of For­mOfPurchase results in the trade being in unmatched status in Oracle FLEXCUBE.

Participation trades are out of scope of this FS

AccrualSettlementType

Flat or SWOA. Applicable for all the Trades under a Markit TradeID. Any other type of AccrualSettlement­Type results in the trade being in rejected in Oracle FLEXCUBE.

TradeType

Primary/Secondary. Applicable for all the Trades under a Markit TradeID

AssignmentFeeDetails

Wrapper Element. Assignment Fee Remitter and Assignment Fee Paid By. Applicable for all the Trades under a Markit TradeID

Deal Summary

Wrapper Element. Includes CUSIP/ISIN and Value Date of the facility. Facility will be unique for all the Tranches in TradeMatchNotice

MultiFacilityTradeDetails

Wrapper Element. Contaisn the details of the traded amount for each Tranche. Contain the facilityTradeDe­tails element that occurs multiple times, for each of the tranche under the Markit trade id

FacilityTradeDetails

Wrapper Element and is repeated for every tranche under the Markit trade id

FacilitySummary

Wrapper Element. Consists of instrumentid and origi­nal commitment(tranche) amount with currency

multiFacilityTradeDetails-> facili­tyTradeDetails-> facilitySum­mary -> instrumentId

CUSIP/ISIN of the tranche, based on which the Tranche is identified in Oracle FLEXCUBE

multiFacilityTradeDetails -> facil­ityTradeDetails -> tradedCom­mitmentAmount

Trade amount with currency

TradePrice

Trade Price

 

System resolves the details from ‘Markit SLT interface Browser’ and populates the details in the ‘Markit Trade Settlement queue’. For each trade from Markit, the details of the trades are resolved and detailed validations are done based on the following:

16.11.2 Syndicated Loan Trade Allocation Message

The Syndicated Loan Trade Allocation message is sent if any secondary trade is allocated to multiple counterparties. This message is sent only after the Trade Match Notice message is sent since this message carries the Parent Trade information.

Each Syndicated Loan Trade Allocation message consists of the following details:

The primary details in this message are summarized below:

Markit Fields from XML Message

Description

Notice Date

Message generation Date

Party Details

Allocated / Allocating Party MEI Code values

TradeID

Unique Trade Id for each Markit trade. Consists of two Id’s, Markit Trade Id and LQT Ticket Id which will be the Ticket Id of the SLT trade

AllocatingParty

Identifies the party allocating the trade as a reference. This will be the Trade Counterparty of Parent Trade

AllocationID

Unique Allocation id for each allocation. Each Alloca­tion message can have more than one Allocation ID

AllocatedParty

Trade counterparty of the allocated Trade

MultiFacilityTradeDetails

Wrapper Element. This will contain the details of the traded amount for each Tranche. Contains the facili­tyTradeDetails element that occurs multiple times, for each of the tranche under the Markit trade id

FacilityTradeDetails

Wrapper Element and is repeated for every tranche under the Markit trade id

FacilitySummary

Wrapper Element. It consist of instrument d and orig­inal commitment(tranche) amount with currency

multiFacilityTradeDetails-> facilityTradeDetails-> facil­itySummary -> instrumen­tId

CUSIP/ISIN of the tranche, based on which the Tranche is identified in Oracle FLEXCUBE

multiFacilityTradeDetails -> facilityTradeDetails -> tradedCommitmentA­mount

Trade amount with currency

TradePrice

Trade Price

 

Oracle FLEXCUBE does the necessary validation and matching by resolving the details from ‘Markit SLT Interface Browser’ and then Trade details are populated in the ‘Markit Trade Settlement queue’. For each allocation from Markit, the details of the trades are resolved and detailed validations are done based on the following:

16.11.3 Trade Update Notification

The Trade Update Notification message is the update notification on a trade that has already been received from Markit to notify the trade status to Oracle FLEXCUBE. Each trade consists of the following details:

Each Trade Update Notification message consists of the following primary details:

Based on the Trade Id/ Allocation ID, all the trades corresponding to this message are identified. If the Trade Id/Allocation Id does not exist in the system, then the message is marked as ‘Rejected’ in the ‘SLT interface Browser’.

Markit Trade Status field is updated with the update status received from Markit in this message. This update is also applicable for all the individual SLT trades under the Markit Trade Id.

Trade Update Notification message is sent only if the trade settlement is blocked in Markit/Oracle FLEXCUBE and thereby it is optional.

16.11.4 Settlement Details Notice

The Settlement Details Notice message constitutes of the Funding Memo details from Markit. Each message consists of the following primary details:

The following details are sent from Markit to Oracle FLEXCUBE as part of the Settlement Details Notice message:

Markit Fields from XML Message

Description

SettlementPlatform

Defines the platform on which the trade is being settled. This field always has the value ‘Markit Clear’.

Trade ID

Unique Trade Id for each Markit trade. It consists of the Markit Trade Id and LQT Ticket ID, which is the Ticket Id of the SLT trade

AllocationID

The identifier that defines the allocation (applicable when the trade involves an allocating party). This can have only one Allocation ID

Seller/Buyer

Reference to the Seller and Buyer of Trades

ProposedSettlementDate

Expected Settlement Date as received in the Trade Match notice

Party

MEI codes for the Seller and Buyer involved in the trade

facilitySettlementDetails

Wrapper Element which is repeated for each tranche

TradedCommitmentAmount

Original Trade Amount for the CUSIP/ISIN

RevisedCommitmentA­mount

Revised Trade Amount for the CUSIP/ISIN

Facility Identifier

Wrapper Element. Includes instrument id (External CUSIP of the tranche), tranche Currency and the original commitment (tranche) amount

Facility contracts

Wrapper Element. For each tranche, it carries the Draw­down Details and the associated DCF details for each Drawdown

Contract -> loancontract­summary-> identifier -> con­tractid

Drawdown reference number

Contract -> loancontract­summary-> original amount

Original drawdown amount with currency

Contract -> loancontract­summary-> maturitydate

Maturity date of the drawdown

Contract -> amount

Global Drawdown amount with currency

Contract -> effective date

Value date of the Drawdown

Contract -> participation­Amount -> globalAmount

Global Drawdown amount with currency

Contract -> participation­Amount -> shareAmount

Traded portion of the Drawdown amount with currency

Settlement Amount

Wrapper Element. This could repeat multiple times for each of the Settlement currency, Payment Type, Payer and Receiver combination

System does the necessary validations and matching by resolving the details from ‘Markit SLT interface Browser’ and then the trade details are populated in the ‘Markit Trade Settlement queue’. The details of each trade are resolved and detailed validations are done based on the following:

16.11.5 Trade Closed Notice

Markit sends the Trade Closed Notice message to Oracle FLEXCUBE after a trade is settled in Markit. This message consists of the following primary details:

Markit Fields from XML Message

Description

TradeID

Unique Trade Id for each Markit trade. It consists of Markit Trade Id and LQT Ticket Id which is the Ticket Id of the SLT trade

AllocationID

One Allocation ID at a time for an allocation of the Parent Trade ID. This is null if the Trade is not an allocated trade

Effective Date

Actual Settlement Date. This is always be the current Applica­tion date in Oracle FLEXCUBE

TradeCompletelySet­tled

The possible values are True/False. If the message is for the last trade/allocation under the Markit Trade Id/Allocation Id, then this is ‘True’. For rest of the prior messages, it remains false, as all the allocations are not yet settled

Markit sends this message only after the Trade Match and Settlement Details notices are sent to Oracle FLEXCUBE. For an allocated trade, each Each Trade Closed Notice message is always for a single Markit Allocation Id. If it is an unallocated trade, then this message is for a single Markit Trade Id.

The latest trade details available in the system for the Markit trade id/allocation id sent in Trade Closed Notice message are used for validation/matching. System processes this message only to resolve the relative Oracle FLEXCUBE trades that can be allowed to settle manually and trade settlement is initiated automatically.

Post all the validations, the trade details are updated in the ‘Markit Trade Settlement queue’ with the appropriate status. The status is updated accordingly in the ‘Markit Agency Interface Browser’ also.

16.12 Processing Manual Trade Settlement

After the successful processing of Trade Closed Notice message, Oracle FLEXCUBE allows you to manually initiate the SLT trade settlement. If the closure message is processed, then you can selectthe ‘Process Settlement’ check box in the ‘Trade Settlement Queue’. If you check this box, then you can overwrite the fee amount in the ‘Funding Memo’ screen. on saving the trade, the FMEM/TSTL is registered.

System allows you to delete the FMEM/TSTL events and on deletion, the events are accounting entries are deleted. The record remains unchanged in the ‘Trade Settlement Queue’. On successful authorization, the events and accounting entries too get authorized. The appropriate settlement status is then updated in the ‘Markit Interface Browser’.

The required SSI maintenance should exist for the trade to process the settlement successfully. The SSI enrichment is not allowed from the Trade Settlement Queue.

If a trade is manually settled using the ticket/trade settlement screens, then the match status is updated as ‘Unmatched’ and you cannot initiate settlement for such trades from the queue.

The funding memo generated from Oracle FLEXCUBE and the subsequent settlement is based on Oracle FLEXCUBE calculations. If you override the ‘Suppress funding Memo’ message in the settlement queue marking it as ‘Yes’, then the funding memo advice is not sent to the trade counterparty. This is also applicable for ‘Suppress payment message’. For such cases, wire/payment message is not sent to the trade counterparty.

You can suppress funding memo and payment message from the Markit Trade Settlement queue only during trade settlement.

Oracle FLEXCUBE does not send any additional wire/payment message in case of Settlement amount/Fee amount mismatch between Oracle FLEXCUBE and Markit. Ticket level settlement message is then sent to LQT if the current trade under the Markit trade id is the last trade to be settled successfully for the associated LQT Ticket ID. Note that are is no notification sent to Markit for the settlement failures. You should manually correct the necessary details based on the exceptions and then can re-initiate trade settlement from the settlement queue.

The following are the generic validations for Markit trade settlement:

Note

Manual trade settlement is initiated from the Markit Trade Settlement queue. Oracle FL­EXCUBE sends an acknowledgement message to LQT when the last trade under a LQT ticket id is settled successfully in Oracle FLEXCUBE and all the other trades are already settled.

16.13 Handling Status for Processing Markit SLT Trade Set­tlement

Following are the various statuses handled for processing Markit Trades and SLT Trade Settlement in the system:

16.13.1 Message Status

Details on Message Status are given below:

16.13.2 Markit Trade Status

Details on Markit Trade Status are given below:

16.13.3 Oracle FLEXCUBE Trade Status

Details on Oracle FLEXCUBE Trade Status are given below:

16.13.4 Match Status

Details on Match Status are given below:

16.13.5 Oracle FLEXCUBE Settlement Status

Details on Oracle FLEXCUBE Settlement Status are given below:

16.14 Viewing the Markit Agency Interface Browser

You can view all the inbound messages from Markit as well as query/reprocess open trades linked to a particular buyer/seller or Markit Trade Id or Message/process status using the ‘Markit Agency Interface Browser’ screen. You can invoke the ‘Markit Agency Interface Browser’ screen by typing ‘LBSMKTIF’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.

 

In this screen, you can view the summary of all the tranche/trades under a Markit id. System displays the following details in this screen:

The message sequence number is the running sequence number for the Markit messages for a day and is reset every day. The format of the message sequence number is ‘YYYYMMDDMKTASSSSSS’.

If a Markit message is rejected in the system, then you can re-process the message in this screen.

Note

 

16.14.1 Viewing Error Messages

You can view the exception log associated with the contract in ‘Markit Agency Interface Browser Detail’ screen. You can invoke the ‘Markit Agency Interface Browser Detail’ screen by typing ‘LBDMKTIF’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.

 

16.15 Transferring Updated Information to Markit

Whenever there is a change in External CUSIP for a tranche, a change in External CUSIP for a drawdown or a change in MEI CODE, the system transfers the data to Markit by generating the relevant messages. These are explained below:

16.15.1 For a Tranche

If, for a tranche, the current CUSIP value is blank and a new External CUSIP has been entered, the system sends a new Take On Facility notice to Markit. If the External CUSIP for the tranche was not blank initially but has been updated with a new CUSIP, then the system will send:

The notices are sent as part of an offline activity that begins after the tranche amendment for the CUSIP update is saved. The authorization of this update can happen only after the message generation is completed. If the tranche amendment is deleted, then the generated messages are deleted too. Once the generation is complete and the authorization of the tranche amendment is done, the handoff to Markit will happen. After the offline activity is through, the messages at the drawdown level are generated and till all such messages are generated and handed off for the drawdowns corresponding to the amended tranches, no events are allowed for the tranches.

16.15.2 For a Drawdown

If, for a drawdown, the current CUSIP value is blank and a new External CUSIP has been entered, the system sends a new Drawdown notice to Markit. If the External CUSIP for the drawdown was not blank initially but has been updated with a new CUSIP, then the system will send:

The notices are sent as part of an offline activity that begins after the authorization of the tranche amendment. End of day Pending Transactions show any message pending generation/handoff and Marking of End of Transaction Input are not allowed till the message generation and handoff is completed. In addition, no further events are allowed for drawdowns for which messages are being generated and handed-off till the process is complete.

16.15.3 For MEI CODE

MEI CODE is a UDF at a Customer level that is maintained in the system. Whenever this is updated, saved, and authorized at the customer level, then:

The End of Day Pending Transactions show any message pending generation/handoff and Marking of End of Transaction Input is not allowed till the message generation and handoff is completed. Additionally, no further events are allowed on the underlying tranche/drawdowns which have the participant with the MEI CODE changed, till the messages are generated and handed off.

16.16 Viewing FpML Messages

The FpML messages that have been generated can be viewed through the ‘FpML Message’ screen for events triggered manually. The operations for which the messages can be viewed are:

16.17 Viewing the Markit Agency Interface Browser

You can view all the incoming messages from Markit, query/reprocess the message/process status in the ‘Markit Incoming Interface Browser’ screen.

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

 

In this screen, you can view the following details:

Processing Status

Select the processing status from the adjoinign drop-down list. The list displays the following values:

You can process the following Markit messages in this screen:

16.17.1 Querying Messages

You can use the ‘’Advance Search’ screen to query the message details. From the menu, click ‘Advance Search’.

 

16.17.2 Viewing Error Messages

You can view the exception log associated with the contract by clicking the ‘Exception Details’ button against the tranche. You can also view the ‘Enrich’ related field exceptions details in this screen.

 

 

16.17.3 Processing Incoming Messages

The following are the various statuses handled by the system for processing messages:

Processing Status

Description

Hold

If the Notice Date is in the future

WIP

If the queue for which processing is initiated but not completed e.g. due to message clipping process

Failed

If the message is failed because of missing maintenance in the system or duplicate message

Enrich

If it relates to an item which is pending for corrective action or waiting for corrected message from Markit.

Pending Authenti­cation

If the contract/event in the system is awaiting for dual authoriza­tion or the notice date in message is earlier than current date

Pending

If the message which is yet to be processed

Processed

If the incoming FpML message is processed successfully

If the processing status is ‘Pending’ then the system verifies whether the External CUSIP is mentioned in the incoming message corresponds to an active Borrower Tranche contract in the system and the Message ID is not already present in the Incoming Browser as ‘Processed’ If the External CUSIP/ISIN doesn’t correspond to an active borrower tranche, then the system updates the processing status of the message as ‘Failed’.

If the active tranche contract is not found or if the same message ID has been previously processed successfully, then the system updates the processing status as ‘Failed’ and display an exception message.

If the External CUSIP is an active tranche contract, the system validates the following

Once the above validations are completed, the system performs specific validation based on various message types. Details of these validations are provided in the subsequent sections.

Once the message is successfully processed, the system updates the processing status as ‘Processed’.

While processing any message, if data in any of the fields in the Incoming Browser is not received in the incoming browser or if the information received does not match with the data in the system, the Processing Status is updated as ‘Enrich’ and you need to manually enter the data and change the Processing Status back to ‘Pending’. The message is then be re-picked up for processing.

For message ‘Drawdown Notice’, if the notice date in the incoming message is greater than the application date, the system does the following

For message ‘Drawdown Notice’ if the Notice Date in the incoming message is equal to the application date and effective date is earlier than application date, then the Drawdown is created with back value dated effective date and the system updates the Processing Status as ‘Processed’.

If any messages for which the contract/event in the system is awaiting for your dual authorization, the system updates the Processing Status as ‘Pending Authentication’. Such processing is required in scenarios such as when borrower/investor is classified. The event/contract is processed in the system but it requires you to manually perform dual authorization.

You can view the messages which have overrides requiring Dual authorization in the ‘Dual Auth Screen/ Drawdown Summary’ screen.

Once you authorize the contract/event, the Processing Status of the message will be automatically updated as ‘Processed’. The messages in the Incoming Browser which are ‘Pending Authentication’ will not delay the End of Day Batch processing in the system, provided the overrides have been confirmed and the event/contract has been authorized.

If the tranche involves more than one participant with the same MEI code then:

On receiving a message for a message ID that has been ‘Failed’, the system proceeds to process the latest message received and the failed message will be moved.

16.17.4 Re-linking the message

The Messages with processing status as Enrich/ Failed remains in the Incoming Browser until the agent resends the corrected message with the same Message ID. If the Agent sends the corrected message, the Message ID is the same as that of the original message. The system increments the Msg Seq No and Processing Status of the second message will be ‘Pending’.

You are allowed to input the agent reference number and the system validates if it is not linked to any active or liquidated contracts.

If there are multiple agent reference numbers under a loan, the system does not validates as only one agent reference number is linked to a drawdown. It should be controllable such that multiple agent reference number under the same loan is not linked to multiple active or liquidated drawdowns in the system.

16.17.5 Clipping the message

The incoming message from Markit may be for a single MEI which may represent multiple investors or a single MEI for a single investor or a multiple MEI for multiple investors.

While processing the message, the Borrower Tranche contract in the system is identified based on the External CUSIP/ISIN in the incoming message. The branch code, drawdown product(s) and participant(s) thus be identified.

If the tranche involves more than one participant with different MEI Codes (that is,. only one of the MEI Codes matches with the MEI Code in the incoming message) then:

Once the messages are received in the Incoming Browser for each MEI Code in the tranche, then the system validates the External CUSIP/ISIN, Value date, Maturity date, Borrower, Tranche Global Amount, Borrower Amount combination and checks that the number of messages equals the number of participants with different MEI Codes.

Once the above conditions are met, the system processes the messages together to create a single contract/trigger a single event with all participants.

 

16.17.6 Drawdown Notice

The incoming messages with Message Name as ‘Drawdown Notice’ and Drawdown Event Type as ‘New Drawdown Event’ is placed in the Incoming Browser with Processing Status as ‘Pending’. You can view and process it by clicking ‘ Drawdown Details‘ tab against the message.

 

 

If the External CUSIP/ ISIN in the message is an active Borrower Tranche or If the Message ID is not already processed and if the Agent Ref No. in the message is not found for any active Borrower Drawdown contract, then the system will validate as follows:

Drawdown product is resolved based on floating Rate Index in the incoming message:

You need to select the drawdown product in the ‘Product Code’ field in the ‘Detail’ sub-screen of the Incoming Browser. Products allowed for the tranche will be available for selection. Then you need to update the Processing Status as ‘Pending’ which is picked up by the system for re-processing.

The main interest component is taken from product to apply the interest rate received. The system Tranche Margin Rate is deducted from the margin rate received in FpML message and residual rate are applied for DD margin component

Once all the validations on the incoming message are successful, a new drawdown is booked and BOOK, DNOT, IRFX, EXFX (if drawdown currency is different from tranche currency) events are fired.

The newly created drawdown is auto-authorized if there are no overrides that require dual authorization and Processing Status is updated as ‘Processed’, whereas the newly created drawdown will be created as unauthorized if there are any overrides that require dual authorization. Processing Status is ‘Pending Authentication’ in such cases and the drawdown have to be manually authorized after dual authorization.

If the drawdown is not authorised, while marking the EOTI, the system prompts you to clear the pending authorizations.

If the Processing Status is ‘Enrich’, you can enrich the following fields:

Further the below fields can be enriched provided these dates fall on a holiday

The system logs the following exceptions during processing:

If Processing Status is ‘Enrich’ then you can modify the above mentioned fields in the Incoming Browser and then change the ‘Processing Status’ to ‘Pending’ so that system picks up for re-processing. The message is marked for ‘Enrich’ if the exception is due to the following:

If the notice date is earlier than the application date, then the system does not process the contract/event in the system and marks the ‘Processing Status’ of the Incoming Message as ‘Pending Authentication’. You can change the Processing Status to Pending or Processed.

If the notice date is greater than application date for a drawdown notice, then the system will consider the message as an ‘Intent Message’ and mark the Processing Status as ‘Hold’ irrespective of Effective Date (drawdown value date) and it retains the message in the Incoming Browser till the event date and on event date during batch, it updates the Processing Status as ‘Pending’ so that the job pickups the incoming message for processing

If the notice date is application date and effective date is future-dated with Message Name as ‘Drawdown’, then the system processes the message to create an uninitiated drawdown and update the Processing Status as ‘Processed’.

The new drawdown (current/future dated) is created and auto authorized if there are no overrides requiring dual authorization. If there are any such overrides the drawdown needs to be manually authorized after dual authorization. The ‘Processing Status’ is automatically updated as ‘Processed’

16.17.7 Rate Set Notice

The Incoming messages with Message Name as ‘Drawdown Notice’ and event type as ‘Rate Set Event’ is placed in the Incoming Browser with Processing Status as ‘Pending’. You can view and process it by clicking ‘Details‘ button against the message.

Based on the ‘Agent Ref No’ the system will identify the drawdown for which the rate amendment has to be applied. If the matching drawdown is not present, then the system marks ‘Processing Status’ as ‘Failed’ by logging an exception ‘Drawdown is not available’.

Once the drawdown is identified, the system checks the main interest component type. If the interest component is of type ‘LIBOR’ and the ‘Rate fixing is required’ option is selected as ‘Yes’, the system will pick up the rate fixing date, start date, end date, interest rate, and margin from the message, whereas if the ‘Rate fixing is required’ option is selected as ‘No’, the system will update processing status as ‘Failed’ and log an exception ‘Rate fixing is not applicable’.

If the rate fixing is captured for start date and end date from the Rate Set Notice, then the system updates the base rate for the entry with matching Rate Effective Start Date and Rate Effective End Date. If the notice date is on application date and the Rate Effective Start Date is in future, then the system processes the message to capture rate fixing information so that system applies the rate for Rate Effective Start Date and update the Processing Status as ‘Processed’

Once the incoming message with event type as ‘RateSetEvent’ is processed:

The following fields can be enriched by clicking on the ‘Enrich’ button provided these dates fall on a holiday

The system logs the following exceptions during processing:

If the notice date is in future, the system considers the message as an Intent message and will mark the Processing Status as ‘Hold’. The message is retained in the Incoming Browser till the event date and on event date during batch processing system marks the Processing Status as ‘Pending’, so that the messageis picked for processing.

If Incoming Intent message for Drawdown/Rollover and Rate set message are received at the same time for the same contract with same Agent Reference number and is effective on the system date or prior, the system consumes and processes the Intent message and the Rate Set messageis changed to ‘Processed’ automatically.

Only the message process status will be marked as ‘Processed’ for the Rate Set Notice. The system does not process the message and there are no events registered in Oracle FLEXCUBE.

Note

If the Intent message is received on its own, it is consumed as normal.

If the notice date) is earlier than application date (past value dated), the system does not process the contract/event in system and marks the ‘Processing Status’ of the Incoming Message as ‘Pending Authentication’. Once you have changed the status to ‘Pending’, the system will pick up the message for re- processing.

16.17.8 Interest Payment Notice (Scheduled / Unscheduled)

Incoming messages with Message Name as ‘Interest Payment Notice’ is placed in the Incoming Browser with Processing Status as ‘Pending’. You can view and process it by clicking ‘Interest Payment Details‘ button against the message.

Based on the Agent Ref No., the system identify the drawdown for which Interest payment needs to be processed. Once the drawdown is identified, the system compares the notice date with application date to decide whether it is an intent payment / actual payment.

If the notice date is the same as application date and payment date is later than application date where Payment Date matches a defined schedule date and ‘Liquidate Interest on Prepayment’ option is selected as ‘No’, then the system triggers a future value dated payment event (BLIQ) and change the ‘Processing Status’ of the incoming message as ‘Processed’. The actual payment event is automatically triggered on the effective date and payment related accounting entries are posted with value date as the Payment date

If the payment is actual payment that is, notice date is on application date and there are no pending schedules, then system will check the option ‘Liquidate Interest on Prepayment’ at drawdown contract and proceed to process the particular schedule as follows:

If the ‘Liquidate Interest on Prepayment’ option is selected as ‘Yes’ at the drawdown contract, then the system will do the following:

System compare the principal and interest due amounts for the schedule in the system with the corresponding amounts in the incoming message and processes the messages if the difference is within the variance for principal and interest.
If the drawdown is in currency other than USD then the variance amount is compared with the equivalent of threshold variance for interest or principal using the latest exchange rate between the currencies.

If payment date does not match any defined schedule date for the interest component, then the payment is considered as unscheduled and the system checks if there are any pending schedules. If so, the system gets the earliest pending schedule date and settle this schedule only, based on the Oracle FLEXCUBE amount provided it is within the defined variance for interest payment. If not, the message is not processed

If the processing fails because of the following exceptions, then you can enrich correct the data in the Incoming Browser. Once you have corrected the below fields from the incoming interface browser and the Processing Status is updated as ‘Pending’, the system picks up for processing

During processing, the system logs the following exceptions:

If the notice date is earlier than application date, the system does not process the contract/event in the system and marks the ‘Processing Status’ of the Incoming Message as ‘Pending Authentication’. You can change the Processing Status to Pending or Processed.

If the notice date is later than the application date and Message Name is ‘Interest Payment Notice’, the system will consider the message as an Intent message and updates the Processing Status as ‘Hold’. It retains the message in the Incoming Browser till the event date and on event date during batch system updates the Processing Status as ‘Pending’ so that the job picks up the incoming message for re-processing

If the notice date and payment date are on application date, then system checks if the ‘Liquidate Interest on Prepayment’’ flag is ‘Yes’ at the drawdown contract. For messages where the Processing Status is ’WIP’ (as mentioned above)if The Principal Repayment Notice for message clipping is not received till the end of the day then system marks the Processing Status as ‘Failed’ by logging an exception saying clipping message is not received.

If the interest payment message is present in queue with ‘Processing Status’ as ‘Failed’, and if the message is resent by the Agent with the same Message ID, the system picks the latter message for processing. Once the message is processed in the system, the payment cannot be amended.

16.17.9 Principal Repayment Notice (Scheduled / Unscheduled)

Incoming messages with Message Name as ‘Repayment Notice’ is placed in the Incoming Browser with Processing Status as ‘Pending’. You can view and process it by clicking ‘Details‘ button against the message. The ‘Interest & Principal Payment Details’ screen is displayed as shown below:

 

Based on the Agent Ref No system identifies the drawdown for which principal payment needs to be processed. Once the drawdown is identified, system compares the event date with application Date to decide whether it is an intent payment / actual payment.

If the notice date is earlier than application date, the system does not process the event in the system and marks the ‘Processing Status’ of the Incoming Message as ‘Pending Authentication’. You can change the Processing Status to Pending or Processed.

If the notice date is later than application date, the system considers the message as an intent message and update the Processing Status as ‘Hold’. It retains the message in the incoming browser till the event date and on event date during batch, system updates the Processing Status as ‘Pending’ so that the job picks up the incoming message for processing

If the notice date is the same as application date and payment date is later than application date and ‘Liquidate Interest on Prepayment is ‘No’ then the system triggers a future value dated payment event (BLIQ) and change the ‘Processing Status’ of the incoming message as ‘Processed’. The actual payment event is automatically triggered on the effective date and payment related accounting entries are posted with the value date as Payment date

If the payment is actual payment and the ‘Liquidate Interest on Prepayment’ option is selected as is ‘No’ at the drawdown contract, then the system does the following:

If the ‘Liquidate Interest on Prepayment’ option is selected as ‘Yes’ at the drawdown contract, then the system will do the following:

If the drawdown is in currency other than USD then the variance amount is compared with the equivalent of variance for interest and principal using the latest exchange rate between the currencies.

If the payment date does not match with any defined schedule date for the Principal component, then the payment is considered as unscheduled and the system will check if there are any pending schedules. If so, the system gets the earliest pending schedule date and will settle this schedule, provided it is within the defined variance for principal payment. (BLIQ/LIQD may be triggered based on payment date). If not and if payment due date is on / after the application date system proceeds with processing the message

If the processing fails because of the following exceptions, then you can enrich the data in the Incoming Browser. Once the below fields are corrected from the incoming interface browser and the Processing Status is updated as ‘Pending’, system re-picks up for processing:

During processing, the system logs the following exceptions:

If the event date and payment date/ due date is on application date, then the system checks if the ‘Liquidate Interest on Prepayment flag is ‘Yes’ at the drawdown contract. The system does the following validations

16.17.10 Fee Payment Notice

Incoming messages with Message Name as ‘Ongoing Fee Notice’ is placed in the Incoming Browser with Processing Status as ‘Pending’. You can view and process it by clicking ‘Fee Payment Details‘ tab against the message.

If the External CUSIP/ISIN in the incoming message is an active tranche contract in the system, the message is populated into the Incoming Browser with ‘Processing Status’ as ‘Pending’.

Once the Tranche is identified, if the event date is the same as application date, then based on the fee type mentioned in the message, the system identifies the component for which the payment notice has arrived.

If the payment date mentioned in the message is on or before application date, then system checks if all fee schedules before the payment date of the current message are fully paid. If there is no pending past schedules, then the system compares the fee amount due for the schedule date in the system with the fee amount due in the incoming message.

The Payment Date field can be enriched by clicking on the ‘Enrich’ button when the Processing Status is ‘Enrich’

During processing, the system logs the following exceptions:

16.17.11 Letter of Credit Issuance Notice

Incoming messages with Message Name as ‘LC Issuance Notice’ is placed in the Incoming Browser with Processing Status as ‘Pending’. You can view and process it by clicking ‘Details‘ button against the message. The ‘Drawdown Details’ tab is displayed as shown below:

 

If the External CUSIP/ ISIN in the message is an active Borrower Tranche, the fields in the Incoming Browser are populated with data from the message/tranche contract. If the Message ID is not already processed and if the Agent Ref No. in the message is not found for any active LC drawdown contract in the system, then it will proceed with the creation of a new LC drawdown as follows:

The following fields can be enriched by clicking on the ‘Enrich’ button:

During processing, the system logs the following exceptions:

System checks for exchange rate details. If the drawdown currency is different from the tranche currency and if the exchange rate is not present, then the system marks the ‘Processing Status’ as ‘Failed’ by logging an exception -Exchange rate is not presentYou need to go to ‘Detail’ sub-screen of the Incoming Browser and select the appropriate product. Products linked to the tranche will be available for selection. Then, you can change the Processing Status to ‘Pending’ and system will re-pick up the message for processing

If the borrower mnemonics at tranche is maintained as ALL type (Product, Branch, Currency, module), then system marks the Processing status as ‘Enrich’ and you need to modify the mnemonics for the tranche and resubmit the message for processing by changing the Processing Status as ‘Pending’

If the event date is greater than application date, the system considers the message as intent and will mark the Processing Status as ‘Hold’. It retains the message in the Incoming Browser till the event date and on event date during batch processing system will update the Processing Status as ‘Pending’ so that the message can be picked for re-processing

If the event date is earlier than application date, then the system does not process the contract/event in the system and marks the ‘Processing Status’ of the Incoming Message as ‘Pending Authentication’. You need to change the Processing Status to Pending or Processed.

16.17.12 Pricing Change Notice

Incoming messages with Message Name as ‘Pricing Change Notice’ is placed in the Incoming Browser with Processing Status as ‘Pending’. You can view and process it by clicking ‘Details‘ button against the message. The ‘Fee & Margin Details’ screen is displayed as shown below

 

 

If the External CUSIP/ ISIN in the message is an active Borrower Tranche, the fields in the Incoming Browser are populated with data from the message/tranche contract. If the event date is the same as application date, the system compares the message effective date with event date (notice date). If they are same, the system updates the margin / fee rate for the Tranche as below:

 

If the effective date is current or application date, then the margin/fee rate is applied for the new tranche getting booked. New margin/ rate is propagated to drawdown contracts under the tranche, based on effective date during batch (MRFX event). New fee rate is applied to tranche contracts online (FRFX event).

The following fields can be enriched by clicking on the ‘Enrich’ button (if the dates fall on holidays)

The system logs the following exceptions during processing:

 

16.17.13 Rollover Processing

Incoming messages with Message Name as ‘Rollover Notice’ will be placed in the Incoming Browser with Processing Status as ‘Pending’. You can view and process it by clicking ‘Details‘ button against the message. The ‘DD Renewal Details’ screen is displayed as shown below

 

 

If the External CUSIP/ ISIN in the message is an active Borrower Tranche, the fields in the Incoming Browser are populated with data from the message/tranche contract. Based on the Agent Ref No system identifies the drawdown contract and if the event date is the same as application date, system checks the following:

If rollover value date (payment date) and parent drawdown Maturity Date(Maturity Date) are same and are the same as event date, the system initiates rollover processing and create child contracts once the rollover interest rate fixing details and exchange rate fixing details (if drawdown currency is different from tranche currency) are available in the message. The processing Status of the message is marked as ‘Processed’

If rollover value date (payment date) and parent drawdown Maturity Date(Maturity Date) are same but are greater than event date, then the system processes the rollover instruction and create an uninitiated child contract, once the rollover interest rate fixing details and exchange rate fixing details (if drawdown currency is different from tranche currency) are available. The processing Status of the message is marked as ‘Processed’

If rollover value date (payment date) is earlier than parent drawdown Maturity Date(Maturity Date), system considers the message as a re-price instruction

System checks the count of maturing drawdowns as per the message:

System checks the count of new drawdowns as per the message:

System compares the maturing drawdown amount(s) and child drawdown amount(s) to decide whether to process principal increase/decrease rollover/reprice.

System takes the outstanding principal amount as the rollover amount and fires ROLL event for the borrower and participant contracts.

System checks if the count of maturing Loan Contracts and new Loan Contracts are more than one then system considers it as Consol+Split rollover

The following fields can be enriched by clicking on the ‘Enrich’ button

System logs the following exceptions during processing:

If the rollover value date (payment date) is earlier than application date, then the system marks the ‘Processing Status’ of the Incoming Message as ‘Pending Authentication’. If users change the Processing Status of the message to ‘Pending’, the message is picked for re-processing.

16.17.14 Incoming FPML Changes for Negative Rate

The system processes the following incoming FpML messages if interest or margin rate is received in negative.

Notice Name

Associated Event

Remarks

Systematic / Free format

Drawdown Notice

DNOT

To book a new drawdown

Systematic

Rate Reset Notice

IRAM

To perform Interest rate amend­ment on drawdown

Systematic

Interest Repayment Notice

LIQD

To process full or partial interest payment on drawdown

Systematic

Split Rollover Notice

RNOT

To process Split Rollover

Systematic

Consolidated Rollover Notice

CRNT

To process Consolidation Rollo­ver

Systematic

Pricing Change Notice

MRFX

To process Margin rate revision at drawdown level.

Systematic