2.1.1 Load Messaging Branch Parameters Maintenance

This topic provides systematic instructions to load messaging branch parameters maintenance.

1. On Homepage, type MSDTFPRF in the text box, and click next arrow.
   The Trade Finance Messaging Branch Parameters Maintenance screen is displayed.
   

   
   Description of the illustration msdpref__cvs_pref.jpg

   
   
2. On Trade Finance Messaging Branch Parameters Maintenance screen, specify the fields.

   If user are maintaining preferences for a new branch of their bank, click the New’button on the Application toolbar. The Trade Finance Messaging Branch Parameters Maintenance screen is displayed without any details.

   If user are calling a branch preference record that has already been defined, double-click a record of your choice from the summary screen. In the Summary screen, all the branch preference records that user have entered will be displayed in a tabular form.

   For more information on fields, refer to Table 2-1:

   Table 2-1 Trade Finance Messaging Branch Parameters Maintenance - Field Description

   Field	Description
   Branch	Specify the branch for which user are maintaining the preferences.
   Message Archive Period	Archival is the process of storing old messages for future retrieval. User can specify the number of days for which an outgoing message should be kept in the Outgoing Message Browser. A message will be automatically archived after the number of days that user specify. User can un-archive the details of outgoing message that has been archived by loading the ‘Message History Retrieval’ screen. After user un-archive an outgoing message user can process it just as user would any other outgoing message. Note: It is recommended that user indicate a value of ‘one’ in this field. In this case, only those messages that have been triggered for generation today will be displayed in the Outgoing Message Browser.
   PDE Archive Period	Specify the number of days for which messages should be kept in the queue for PDE Possible Duplicate Emission) identification. System does not consider messages for PDE identification post the PDE archive period maintained here. Note: The PDE archive period should be less than or equal to message archival days.
   Text for Duplicate	Every message is maintained in the Outgoing Browser, as an un-generated copy of the original. When the copy is generated, it will contain, along with the contents of the original message, any additional text that user have maintained in the Text for Duplicate field.
   Hold Mail Text	All the mail advices generated for a customer for whom Add Hold Mail Text is checked at the Customer Address Maintenance would have the hold mail text maintained in this field. This text will be displayed on top of the message.
   Test Word Check	User can indicate whether a testword needs to be entered before a telex message is generated from and received at their branch. User can state their preference from the Yes/No option that is available.
   PDE Functional Validation	Check this box to indicate that system should identify an outgoing message as PDE (Possible Duplicate Emission) using functional key or not. The PDE validation is done either using the hash value of the SWIFT message or using the tag/field value of the message. If this option is checked, Oracle Banking Trade Finance identifies duplicate messages by performing PDE functional validations also. Hash value based validation shall be done irrespective of this option being checked.
   Indicating the activities that require authorization	User can perform several activities on a message that is to be generated from their branch and on those that have come in for their branch. For example, from the outgoing or incoming browser, user can change the address to which a message should be sent. In the branch preferences screen, user can indicate the activities which when performed on an incoming or outgoing message, would require subsequent manual authorization for the message. Several activities have been listed in this screen. A message, on which an activity which has been selected in this screen is performed, would require subsequent manual authorization for the activity to take effect. A message, on which an activity not selected in this screen is performed, would be automatically authorized with the activity taking effect. The activities that user can choose from are: Cancel Hold Change Node Testword Auth Repair Incoming Carry Forward Change Media Regenerate Change Address Reinstate Release Carry Forward Branch Move Change Media Change Priority Testword Check Auth Repair Incoming A message on which user perform an activity that requires authorization will be available for further processing only after it is authorized.
   SK Arrangement	User can choose the action to be performed on the message based on the Swift Key arrangement with the receiver. The options available for choosing are: Validate - If user choose this option, the system validates if a SK arrangement exists between your bank and the receiver. If Yes, then the original SWIFT message is generated otherwise, the message will go to repair. Generate FFT - If user choose this option, the system validates if a SK arrangement exists between your bank and the receiver. If Yes, then the original SWIFT message is generated otherwise, MT 999 (Free Format Messages) will be generated instead of the SWIFT message. No Validation - If user choose this option, user are instructing the system not to Validate but send the original SWIFT message always. Processing SWIFT Messages if SK arrangement is Validate in the static messaging table: Oracle Banking Trade Finance checks for the value in the branch’s SK arrangement Field If the field value is No validate, Oracle Banking Trade Finance will generate messages the normal way. If the SWIFT keys have been exchanged then the swift message will be generated If SWIFT keys have not been exchanged with the receiver and the value of SK arrangement for the branch is Validate then the following messages will go to repair: MT420, MT754 and MT756. For all other messages, the original SWIFT message gets generated whether swift key exists or not. If SWIFT keys have not been exchanged with the receiver and the value of SK arrangement for the branch is Generate FFT then the message MT999 would be generated instead of original SWIFT message.
   Duplicate Advice Tracker	Check this box to track the duplicate advices. When an advice is duplicated or regenerated, the word Reprint appears over the advice. Generation of MT999. Message header is changed from the original header to MT999 That portion of the message after tag 21 will be prefixed with tag 79 followed by the original SWIFT message The message will be populated with the same contents as the original SWIFT message with the respective SWIFT tags The system will generate MT999 even if the SWIFT Key Arrangement does not exist with the receiver. MT999 will be generated for the following SWIFT messages: MT750 – Advice of Discrepancy MT734 – Advice of Refusal MT752 – Authorization to pay, accept or Negotiate
   Saving the record	After user have made the mandatory entries, save the record. This record should be authorized before the End of Day process (EOD) is run. Click Exit or Cancel button to return to the Application Browser.