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 you are maintaining preferences for a new branch of your bank, click the ‘New’ button on the Application toolbar. The ‘Trade Finance Messaging Branch Parameters Maintenance’ screen is displayed without any details.

   If you 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 you have entered will be displayed in a tabular form.

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

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

   Field	Description
   Branch Preference In the ‘Trade Finance Messaging Branch Parameters Maintenance’ screen you can only maintain (create or modify) the preferences for the current logged in branch. However, you can view the preferences maintained for other branches. Following are the details captured here:
   Branch	Specify the branch for which you are maintaining the preferences.
   Message Archive Period	Archival is the process of storing old messages for future retrieval. You 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 you specify. You can un-archive the details of outgoing message that has been archived by loading the ‘Message History Retrieval’ screen. After you un-archive an outgoing message you can process it just as you would any other outgoing message. Note: It is recommended that you 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 you 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	You can indicate whether a testword needs to be entered before a telex message is generated from and received at your branch. You can state your 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	You can perform several activities on a message that is to be generated from your branch and on those that have come in for your branch. For example, from the outgoing or incoming browser, you can change the address to which a message should be sent. In the branch preferences screen, you 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 you 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 you perform an activity that requires authorization will be available for further processing only after it is authorized.
   SK Arrangement	You 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 you 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 you 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 you choose this option, you 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 you 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.