15.17.3 Processing Incoming Messages

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

Table 15-8 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 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 Authentication	If the contract/event in the system is awaiting for dual authorization 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 does not 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:

• Notice Date in the incoming message is equal to the Application date.
• MEI code for Participant(s) and Borrower from the message match with the MEI Code of the respective parties in the system.
• All the Participants in the tranche contract have the same MEI Code as the Participant MEI Code in the message.

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 repicked 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:

• Update the Processing Status as Hold.
• These messages continue to be in Hold status till the application date is same as the notice date. While marking the Transaction Input on the application date (beginning of day) system checks the status of all incoming messages whose processing status is Hold and is updated as Pending.
• Alternately, you can change the processing status of these messages to Processed in case no processing is required.

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 is automatically updated as Processed. The messages in the Incoming Browser which are Pending Authentication does 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:

• A single message with a given Agent Ref No. and Message ID is received.
• System checks that the MEI Code for the participants matches the MEI Code in the incoming message.
• If yes, the Participant Asset ratio for the tranche is utilized and applied to each participant while processing the message.
• The Agent Ref No of the participant with the highest asset ratio is displayed in the incoming browser.

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 is moved.