The messaging preferences that you indicate for your branch governs the workflow aspects of the messaging system module. You can specify messaging preferences for your branch in the ‘Messaging Branch Preferences’ screen. In this screen you can indicate:
Note
You can specify preferences only for the branch from which you logged onto Oracle Lending.
This chapter contains the following sections:
This section contains the following topic:
To invoke the ‘Messaging Branch Parameters Maintenance’ screen, type ‘’OLDPREFN’ in the field at the top right corner of the Application tool bar and click the adjoining arrow button.
If you are maintaining preferences for a new branch of your bank, click the ‘New’ button on the Application toolbar. The ‘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 is displayed in a tabular form.
The screen is shown below:
In the ‘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
Select the Message Archive Period as 'Partial' or 'Full'. In case of partial archival, the data pertaining to the message is archived. In case full archival the data pertaining to the messages and the message gets archived.
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 contains 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 selected at the Customer Address Maintenance would have the hold mail text maintained in this field. This text is displayed on top of the message.
Test Word Check
You can indicate whether a test word 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
Select 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 Lending 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:
A message on which you perform an activity that requires authorization is 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:
Processing SWIFT Messages if SK arrangement is ‘Validate’ in the static messaging table:
Generation of MT999
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.
This section contains the following topic:
For a combination of the following, you can specify the branch (queue) to which the message is to be routed:
This maintenance can be performed through the ‘Message Queue Mapping Maintenance’ screen. To invoke this screen, type ‘MSDQMAP’ in the field at the top right corner of the Application tool bar and click the adjoining arrow button.
While processing MT700 and MT701 messages the System ensures the following:
Note
You can maintain the same BIC for the main branch as well as the sub-branch.
This section contains the following topic:
All Incoming SWIFT and Non Swift Messages are routed through a messaging queue. You need to maintain different user queues to which incoming messages are directed. Users with appropriate rights are allowed to access a particular queue.
You can invoke the ‘Message Queue Maintenance’ screen by typing ‘MSDQMNT’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.
In this screen you can capture the following details for a queue:
Note
The codes of various SWIFT and Non SWIFT messages list in the grid is not applicable for the collection queue.
You can assign a message to more than one messaging queue. At the time of maintaining rules for a message (discussed in the subsequent sections of this document), you can select the appropriate queue for each rule from the list of queues to which the message is linked.
Select ‘Add’ from the Actions menu in the Application tool bar or click add icon to add a message to the queue being defined. To remove a message from the queue, Select ‘Delete’ from the Actions menu in the Application tool bar or click delete icon.
Refer to CN Module for more details on Collection Queue.
You can maintain message types in Oracle Lending through the ‘Message Type Maintenance’ screen. To invoke ‘Message Type Maintenance’ screen, type ‘OLDMGMNT’ in the field at the top right corner of the Application tool bar and click the adjoining arrow button.
You will need to capture the following information in this screen:
Module
Specify the module for which you are maintaining message types. The adjoining option list displays all module codes available in Oracle Lending. You can select the appropriate one.
Message Type
Specify the message type for which SWIFT codes can be maintained.
Description
Enter a brief description of the message type.
Priority
Specify the priority in which a message is to be sent is displayed. You have the option to change the priority. To change the priority specified for a message, click the button marked ‘Change Priority’. Thereafter, select an option from the option-list that is available for this field.
SWIFT Message Type
Indicate the SWIFT message type in which the free format message should expressed. For the following message types in BC module, you need to indicate the SWIFT message type as MT999:
Note
NEFT and RTGS message types will be factory shipped which are available as Swift message type. These messages will be available only for PC module.
Following are the NEFT and RTGS message types generated:
Message Type |
Description |
NEFT / RTGS Message Type |
CUST_PYMT_RIND |
RTGS Customer Payment Request |
R41 |
BANK_PYMT_RIND |
RTGS Interbank Payment Request |
R42 |
DR_NOTIFICATION |
RTGS debit notification |
R43 |
CR_NOTIFICATION |
RTGS credit notification |
R44 |
STLMNT_NFTN_RBI |
RTGS sender settlement notification |
R09 |
STLMNT_NFTN_PI |
RTGS PI Response |
R90 |
CUST_PYMT_NIND |
NEFT – Incoming Payment Message |
N02 |
RETURN_TRN_RBI |
NEFT - Message for transmitting return transaction details |
N03 |
DR_MSGS_NIND |
Outward Debit Messages from NEFT Branches |
N06 |
RETURN_TRN_NBRN |
Return Transaction from NEFT Branches |
N07 |
REJECT_TRN_NIND |
NEFT - Transmission of Rejected Transactions at NEFT Service Station to Bank Branches |
N09 |
CREDIT_ACK |
Credit Acknowledgement Message for N02 and N06 |
N10 |
ACK_MSG_SFMS |
Acknowledgement message from SFMS |
F20 |
NEG_ACK_MSG |
Negative acknowledge message from SFMS |
F25 |
NEG_ACK_SUSR |
Negative acknowledge message from SFMS User |
F26 |
ACK_MSG_BKAPI |
Acknowledgement message from Bank API |
F27 |
Generate at input
Select this check box to indicate that this message is to be generated at the time of input of the contract, and not after authorization.
Show in product
Select this check box to indicate that this message will be available in the product to be maintained against a particular event.
This section contains the following topics:
Oracle Lending allows you to tag SWIFT messages (both incoming and outgoing) as duplicate if it identifies that the same message was sent/received earlier. Once the message is detected as a duplicate message the trailer of the message is appended to reflect this information.
Note
This is applicable only for MT103 and MT202 messages.
For incoming SWIFT messages which have a PDE trailer, system interprets the trailer information and sets aside those messages marking its process status as ‘Exception’. However, Oracle Lending allows you to either accept or reject the message identified as a PDE, from the Incoming message browser.
For outgoing SWIFT messages, system performs certain PDE validations, to identify duplicate messages. Following are the two types of PDE validations that the system performs:
Hash Value Based PDE Validation
System calculates the hash value of a message when the message is generated and stores it in a data store. System then compares this value with the hash values in the message log to identify duplicates.
Note
System performs hash value validation on messages as a mandatory check.
Message field (Tags) Based PDE Validation
Tag based PDE validation is performed only for Customer Transfer (MT103) and Bank Transfer (MT202) messages. You can decide the tag value based on which system needs to perform the validation.
Note
Tag value validation is done only if you have selected the ‘PDE Functional Validation’ option in the ‘Messaging Branch Parameters Maintenance’ screen.
System uses the following fields to compare and identify whether a message is a PDE or not. This data is factory shipped.
Customer Transfer MT103
Message Tag |
Option |
Tag Description |
50 |
A, K, F |
Ordering Customer |
32 |
A |
Interbank Settlement Amount |
32 |
A |
Currency |
32 |
A |
Value Date |
57 |
A, B, C, D |
Account With Institution |
59 |
A or No letter |
Ultimate Beneficiary |
Bank Transfer MT202
Message Tag |
Tag Description |
Field Position |
32 |
A |
Interbank Settlement Amount |
32 |
A |
Currency |
32 |
A |
Value Date |
58 |
A or D |
Beneficiary Institution |
Note
You can also choose not to use any of the above tags for comparison. Along with the above fields the Sender and Receiver BIC are also used for procedural validation.
The system detects the messages (Incoming/Outgoing) as PDE messages by performing the validations . The Incoming and Outgoing PDE messages are processed by the system in the following manner:
In the case of incoming messages, EMS picks up the incoming messages and inserts it into a data store. If the incoming message has a PDE trailer (message contains the text ‘PDE:’} then the system marks the process status as ‘Stopped due to PDE’. After due validations, you can release the message from the incoming PDE message queue. Once these messages are accepted it continues to get uploaded as a normal message. If the PDE trailer is NOT present in the incoming message, then the message upload continues as normal.
In the case of incoming messages with a PDE trailer, the ‘PDE Flag’ check box in the ‘Incoming Message Browser’ screen is selected.
For more details on the PDE indication of an incoming message in the Incoming Message Browser, refer section ‘Viewing the details of an Incoming Message’ in ‘Processing Incoming Messages’ chapter of this User Manual.
In the case of outgoing messages you can decide to do any of the following if the system detects a message as a duplicate, based on the PDE validations:
System displays an override when it finds a message to be a duplicate one. In this case the message is parked in the PDE queue and you can either choose to release the message without the PDE trailer, otherwise, release it with the PDE trailer. If you choose to release the message with the PDE trailer then the message is appended with PDE, else the message is released without PDE. You can also choose to reject the message. In this case the message status is changed to ‘E’ (Exception) and this is not picked up by EMS (Electronic Messaging System).
Due to message size restrictions in Oracle Lending, sometimes a single message is physically split into multiple parts and each one is stored in a distinct record in the outgoing message data store. A message is marked as ‘PDE’ if ALL the split messages are found to be duplicates.
Note
All the messages in the PDE queue (Incoming and Outgoing) are completely processed by EMS prior to initiating EOD operations.
For more details on outgoing messages in PDE queue refer section ‘Processing Outgoing Messages with PDE Trailer’ in ‘Processing Outgoing Messages’ chapter of this User Manual.