3. Maintaining Messaging Branch Preferences

The messaging preferences that you indicate for your branch will govern 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 FL­EXCUBE.

This chapter contains the following sections:

3.1 Messaging Branch Parameters Maintenance

This section contains the following topic:

3.1.1 Invoking Messaging Branch Parameters Maintenance screen

To invoke the ‘Messaging Branch Parameters Maintenance’ screen, type ‘MSDPREF’ 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 will be displayed in a tabular form.

The screen is shown below:

Branch Preference

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

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 invoking 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 FLEXCUBE 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 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:

Processing SWIFT Messages if SK arrangement is ‘Validate’ in the static messaging table:

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

 

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.

3.2 Message Type Maintenance

This section contains the following topic:

3.2.1 Maintaining Message Types

You can maintain message types in Oracle FLEXCUBE through the ‘Message Type Maintenance’ screen. To invoke ‘Message Type Maintenance’ screen, type ‘MSDMSTYM’ 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 FLEXCUBE. 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 mes­sage 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_N­BRN

Return Transaction from NEFT Branches

N07

REJECT_TRN_NIND

NEFT - Transmission of Rejected Trans­actions 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

Check this 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

Check this box to indicate that this message will be available in the product to be maintained against a particular event.

3.2.1.1 Viewing Message/Advice

Select a message/ advice and click ‘View’ button to view the complete message/advice. The system will display the following details in a new window..

You can view the following details:

3.3 Swift Tag Maintenance

This section contains the following topic:

3.3.1 Querying for SWIFT Message Tag Description

You can query for tag descriptions for SWIFT messages using the screen ‘Swift Tag Maintenance’ screen. You can invoke the screen by typing ‘MSDMSGTM’ in the field at the top right corner of the Application tool bar and click the adjoining arrow button.

The screen is as shown below:

Specify the following fields:

Swift Tag Maintenance

Swift Message Type

Specify the swift message type. The adjoining list displays a list of message types maintained in the system. Choose the appropriate one.

Description

The system displays the message description.

Tag Description

Tag Name

The system displays the tag name.

Description

The system displays the description.

Tag Option

Lines

The system displays the number of lines required for the tag.

Sequence

The system displays the tag sequence number.

Repeatable

Indicates whether the tag is repeatable or not.

All Options

Indicates all options.

Sequence Name

Specify the sequence number.

Note

Swift message tag descriptions are factory shipped. However, it can also be maintained using this screen.

3.4 Message Preview

This section contains the following topics:

3.4.1 Viewing SWIFT Message Tags

You can view the SWIFT messages and tag descriptions using the ‘Message Preview Browser’ screen. You can invoke this screen by typing ‘MSDMSPRV’ in the field at the top right corner of the Application tool bar and click the adjoining arrow button.

You can search for the messages based on the following parameters:

Module

Specify the module. The adjoining list displays a list of module names maintained in the system. Choose the appropriate one. This is applicable only for the following modules:

Contract Reference

Specify the contract reference number. The adjoining list displays a list of reference numbers maintained in the system. Choose the appropriate one.

Once you have set the search parameters, click ‘Execute Query’ button. The system displays the messages that satisfy the search criteria.

3.4.2 Print Button

From the ‘Message Preview’ screen, you can print a message/advice using the ‘Print’ button. Select the message/advice and click ‘Print’ button to print the message.

3.4.3 Maintaining Message Type for Account Opening

You can maintain a specific message type to be associated with account opening event class.

The Events Class Maintenance screen is as shown below:

Specify the following details.

Module

Specify the module as ‘DE’.

Message Type

Specify as ‘ACC_OPADV’.

For further details, refer the section ‘Maintaining Message Types’ in this User Manual.

You can specify a format for this message using the ‘Advice Format Maintenance’ screen. Then you can associate this message to the event class maintained for account opening.

Refer the chapter Maintaining Advice Formats in this User Manual for details about format maintenance.

3.5 Messages

This section contains the following topics:

3.5.1 Maintaining RTGS Messages

The system will support the following RTGS payment messages:

Sr. No

Network (from Product)

Message Type (Outgoing /Incoming)

Product Type (from Product Category)

Transfer Type (from Product Category)

Message Name

Message Description

1

RTGS

Outgoing

Outgoing Payment

Customer

R41

This message will be generated for outgoing pay­ment contract to customer using RTGS product.

2

RTGS

Incoming

Incoming Payment

Customer

R41

This is a Incom­ing RTGS Pay­ment to customer

3

RTGS

Outgoing

Outgoing Payment

Bank

R42

This message will be generated for outgoing pay­ment contract to bank using RTGS product.

4

RTGS

Incoming

Incoming Payment

Bank

R42

This is a Incom­ing RTGS Pay­ment to Bank

5

RTGS

Incoming

Reject of Outgoing Payment

Customer

R42

This Message is for a return of our Outgoing Pay­ment- If the tag  7495 contains /RETURN/ and outgoing pay­ment reference number contains (for instance, :7495:/RETURN/
/012COPB112730001) then it is a Reject of Outgo­ing Payment  oth­erwise it is a Incoming Pay­ment and prod­uct can be resolved based on the network and Transfer type as Customer

6

RTGS

Incoming

Reject of Outgoing Payment

Bank

R42

This Message is for a return of our Outgoing Pay­ment- If the tag  7495 contains /RETURN/ and outgoing pay­ment reference number contains (eg: :7495:/RETURN/
/012COPB112730001) thenit is a Reject of Outgo­ing Payment  oth­erwise it is a Incoming Pay­ment and prod­uct can be resolved based on the network and Transfer type as Bank

7

RTGS

Outgoing

Reject of Incoming Payment

Bank

R42

This message and transaction will be generated when authorizer rejects the incom­ing payment of bank

8

RTGS

Incoming

Incoming Payment

Bank

R44

Credit Notifica­tion.

Refer the Debit/Credit Notification section for detail of this message

9

RTGS

Incoming

Outgoing Payment

Bank

R43

Debit Notification.

Refer the Debit/Credit Notification section for detail of this message

10

RTGS

Incoming

Workflow

 

R09

This is a return message for our outgoing pay­ment received from the RBI. This is only the Ack/NAck mes­sage for outgo­ing payments. If it is Ack message then system will update message status as Fully Completed (PD). If it is NAck mes­sage then system will reverse the corresponding outgoing pay­ment contract and the message status will be updated as Pro­cess Reversed (PR)

11

RTGS

Incoming

Workflow

 

R90

This is a return message for our outgoing pay­ment received from the PI (Par­ticipant Inter­face). This is only the Ack/NAck message for out­going payments. If it is Ack mes­sage then system will update mes­sage status as Partially Com­pleted (HD). If it is NAck message then system will reverse the corre­sponding outgo­ing payment contract and the message status will be updated as Process Reversed (PR)

RTGS Debit and Credit Notifications

Debit Notifications are incoming messages from RBI generated to indicate that a debit has been applied to a participants settlement account by the transaction initiated by RBI. The message format is R43. This notification will consist of debits in the settlement account initiated by RBI only.

Credit Notifications are incoming messages from RBI generated to indicate that a credit has been applied to a participants settlement account by the transaction initiated by RBI. The message format is R44. This notification will consist of credits in the settlement account initiated by RBI only.

3.5.2 Maintaining NEFT Messages

The system will support the following NEFT payment messages:

Sr. No

Network (from Product)

Message Type (Outgoing/ Incoming)

Product Type (from Product Category)

Transfer Type (from Product Category)

Message Name

Message Description

1

NEFT

Outgoing

Outgoing Payment

Customer

N06

This message will be generated for outgo­ing payment contract to customer using NEFT product.

2

NEFT

Outgoing

Reject of Incoming Payment

Customer

N07

This message will be generated for the return of incoming payment. This mes­sage will be gener­ated when authorizer rejects the incoming payment from the incoming authoriza­tion queue or repair queue. The product category for this return of incoming payment transaction will be picked up from the product category of incoming payment

3

NEFT

Incoming

Incoming Payment

Customer

N02

This is a Incoming NEFT Payment

4

NEFT

Incoming

Reject of Outgoing Payment

Customer

N02

This Message is for a return of our Outgo­ing Payment- Check the Related Refer­ence Number tag in the message. If the field is there then it is a Return of Outgoing Payment

5

NEFT

Incoming

Reject of Outgoing Payment

 

N03

This Message is from RBI for a return of our Outgoing Payment- There are two Possi­bilities of this Mes­sage - it can be a Reject of the Outgo­ing Payment or a Reschedule Message - to Find out whether it is a Reject mes­sage - Check the Related Reference Number and Reject Codes - if the Reject code doesn't fall into the Reschedule list then it is a reject of Outgoing Payment - otherwise Resched­ule Message and the message status will be updated as Rescheduled(RS)

6

NEFT

Incoming

Work­flow(Reschedule)

 

N03

This Message is from RBI for a reschedule of our Outgoing Pay­ment-

The reject code type of this message will be ‘Reschedule’ - If it is a Reschedule mes­sage then system will update only the mes­sage status of the contract as Resched­uled (RS). This reschedule message normally will be com­ing in during the day. Our scheduler will pick up this message and resend it to net­work for next sched­ule

7

NEFT

Incoming

Reject of Outgoing Payment

Customer

N09

This Message is from SFMS for a return of our Outgoing Pay­ment- There are two Possibilities of this Message - it can be a Reject of the Outgo­ing Payment or a Reschedule Message - to Find out whether it is a Reject mes­sage - Check the Related Reference Number and Reject Codes - if the Reject code doesn't fall into the Reschedule list then it is a reject of Outgoing Payment and message status will be updated as Processing Failed(XE) - other­wise it will be a Reschedule Message and message status will be updated as Rescheduled(RS).

8

NEFT

Incoming

Workflow

(Resched­ule)

 

N09

This Message is from SFMS for a resched­ule of our Outgoing Payment-

The reject code type of this message will be ‘Reschedule’ - If it is a Reschedule mes­sage then system will update the message status as Resched­uled(RS) and system will resend the mes­sage to the network on next working day

9

NEFT

Incoming

Workflow

 

F20

This is an acknowl­edgement message from SFMS. If this message is received then the message status of original con­tract will be updated as Partially Com­pleted(HD)

10

NEFT

Incoming

Workflow

 

F25

This is a Negative acknowledge mes­sage from SFMS. If this message is received then sys­tem will reverse the corresponding outgo­ing payment contract and the message sta­tus will be updated as Processing Reversed(PR)

11

NEFT

Incoming

Workflow

 

F26

This is a Negative acknowledge mes­sage from SFMS User. If this message is received then sys­tem will reverse the corresponding outgo­ing payment contract and the

message status will be updated as Pro­cessing Reversed(PR)

12

NEFT

Incoming

Workflow

 

F27

This is a acknowl­edgement message from Bank API. If this message is Negative Acknowledgement then the correspond­ing contract will be reversed and the message status will be updated as Pro­cessing Reversed (PR). If this message is Positive Acknowl­edgement then the message status of original contract will be updated as Fully Completed(PD)

11

NEFT

Outward/ Inward Credit Con­firmation Message at branch

 

 

N10

This is acknowledg­ment for N02 and N06.

3.6 PDE Validations on SWIFT Messages

This section contains the following topics:

3.6.1 Performing PDE Validations on SWIFT Messages

Oracle FLEXCUBE 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 FLEXCUBE 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’ op­tion 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 let­ter

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.

3.6.2 Processing PDE Messages

The system detects the messages (Incoming/Outgoing) as PDE messages by performing the validations discussed in the above section. The Incoming and Outgoing PDE messages are processed by the system in the following manner:

3.6.2.1 Incoming PDE Messages

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 will mark 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 will continue to get uploaded as a normal message. If the PDE trailer is NOT present in the incoming message, then the message upload will continue as normal.

In the case of incoming messages with a PDE trailer, the ‘PDE Flag’ check box in the ‘Incoming Message Browser’ screen will be checked.

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.

3.6.2.2 Outgoing PDE Messages

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 opt to release the message without the PDE trailer or else release it with the PDE trailer. If you opt 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 will be changed to ‘E’ (Exception) and this will not be picked up by EMS (Electronic Messaging System).

Due to message size restrictions in Oracle FLEXCUBE, 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.

3.7 Agreement with Sender/Receiver BIC

This section contains the following topic:

3.7.1 Maintaining Agreements with Sender/Receiver BIC

You can maintain agreement with the sender/receiver BIC through the ‘Agreements with Sender/Receiver BIC Maintenance’ screen. You can invoke the ‘Agreements with Sender/Receiver BIC Maintenance’ screen by typing ‘ISDCCYRS’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.

You need to capture the following information in this screen:

BIC Code

Specify the BIC code. The value entered here must be a valid BIC code in the system with the options Generate MT102, Generate MT102+ and Generate 101 selected.

Message Type

Select the message type from the option list.

Direction

Indicate whether the BIC-currencies amount maintenance is for incoming or outgoing or both type of messages. You have the following options here.

Product for Consol Debt

Specify the product for consolidated debit entry to ordering customer. This can be specified for incoming MT101.

No. of Transactions per Message

Specify the total number of transactions for each message (MT101).

Cutoff Incoming

Specify the cutoff time in hours and minutes for the incoming messages.

Cutoff Outing

Specify the cutoff time in hours and minutes for the outgoing messages.

Transaction Currency Limit Details

The details displayed here depend on the direction specified. They are used for MT101, MT102 and MT102+.

Incoming MT101

If the message is an incoming MT101, on receiving the message the following checks will be made before uploading the transactions.