Activity Messaging

The Advice field provides a link to a record in EB.ADVICES, which controls the output of delivery messages and the format of the messages and deal slip. By defining the records in this file, users have total control of the type and format of the eventual output. Users are also able to use their own mapping records instead of the standard mapping records. The Advice, Activity Class and Activity fields form an associated multi-value set.

The Activity Class field denotes the Activity Class ID for which the corresponding delivery message defined in the Eb.Advice field has to be triggered. If a specific value is not selected in ACTIVITY.ID, then the same advice is generated for all activities, which belong to this class. If selected, the value should have a valid record in AA.ACTIVITY.CLASS.

For example, if there is a need to generate a message whenever rate change happens, then LENDING-CHANGE-INTEREST in this field generates the same message for both LENDING-CHANGE-PRINCIPALINT and LENDING-CHANGE-PENALTYINT Activities, where PRINCIPALINT and PENALTYINT are Properties belonging to the Interest class.

The Activity field denotes the Activity ID for which the corresponding delivery message defined in the Eb.Advice field should be triggered. An entry in this field is a more specific definition of the advice being generated.

For example, when a special message is generated whenever penalty interest is changed, then stating LENDING-CHANGE-PENALTYINT in this field generates the advice defined below. It does not generate the message when PRINCIPALINT is changed.

The Role field indicates that the delivery message gets processed only if matching customer role exists for the customers of the arrangement. If customer role does not match, no message processing happens for the customer. If not defined, then is applicable to all customers.

The Content field indicates whether only the current information or previous and current information needs to be passed to form the message. Allowed values are:

• CHANGE - Only the current property details needs to be passed
• ALL - Both current and previous property details needs to be passed

The Send Advice field allows the user to determine whether the given advice or message needs to be sent for the given activity. Allowed values are - YES and NO.

The Pre Notice Activity field specifies the activity for which pre notice delivery message to be generated.

The Pre Notice Days field specifies the number of days before which a pre notice advice has to be generated for the corresponding Activity.

Basic message types can be identified through the DE.MESSAGE application. A numeric message identifier is used to identify the type of message to be produced. To produce a message, a number of possible data fields are defined that together make up the content of the message. A single message type can be generated by many different applications.

The DE.MAPPING application allows the user to map the raw delivery handoff data generated from the delivery event application to the field content defined in the DE.MESSAGE table. For each different application (and possibly sub-division within application), the map between the handoff data and required data layout must be defined.

A formatting application exists for some formatted output to allow the final layout of the message based on field definition, position and conversion options. Examples include DE.FORMAT.PRINT and DE.FORMAT.SWIFT.

Rules based (or soft) delivery allows one or more delivery message types to be generated from a single delivery event. The application generates the delivery event with an identifying ADVICES code together with a collection of unformatted delivery handoff data from the underlying application.

The EB.ADVICES application is used to define the type, formatting and additional content of the delivery messages to be generated. The key to the EB.ADVICES table is the advice code allocated by the application. In the case of AA, the advice code is allocated according to the Activity Messaging Property.

EB.ADVICES allows the user to define:

• Message type – DE.MESSAGE to be generated.
• The DE.MAPPING record to be used to map the data from the application to the message format.
• A specific printed format code to be used in the key to DE.FORMAT.PRINT for printed advices.
• Whether a deal slip is to be produced in addition or instead of a delivery advice.
• An API to allow additional information to be created and include in the delivery handoff.

The application generates a delivery event including the following information:

• Advices code
• Advice identifier code
• Activity details
• Send Message Indicator
• Data Handoff Details – Nine fixed handoff records can be created and an unlimited number of named handoff records can be created

To manage the flexible structure of the AA module, the ability to create named data handoff records is available. To use this facility, the application must provide a list of named records in one of the fixed data handoff records. The data records associated with the named list area also handed off by the application. The fixed record containing the list of names must be specified in the Record Name Loc field of DE.MAPPING record The Input Rec No field has to be configured with the handoff record name and the associated INPUT.FILE has to be specified.

The message carrier type used for the message production is defined in the DE.PRODUCT table. This allows the DE.CARRIER (For example, PRINT, SWIFT, EMAIL, etc.) to be allocated to specified message types and optionally by customer and linked account. The DE.MSG.LINK enquiry can be used to show the messages that have been produced by an arrangement.

Any delivery event created from the AA application generates the following delivery handoff data:

The user can view the content of the delivery handoff using the standard DE.HANDOFF.DETS delivery enquiry.

Certain Properties may not be required in the content of delivery messages produced from AA. For example, the system managed Property Classes such as Accounting, Activity Api and Activity Messaging.

The Del Info Reqd field on AA.PROPERTY.CLASS is used to indicate if any Property of this class is to be included in the delivery handoff. The value Y indicates that the Property Class has to be included. This field is delivered, pre-configured and cannot be amended.

New messages (or existing messages can be amended) can be created for the ARRANGEMENT.ACTIVITY application. The message type is defined in the DE.MESSAGE application and has a numeric message number between 1 and 9999.

When the message is created, the user has to define the data elements that the message is to be comprised of . Read Delivery User Guide for more information on DE.MESSAGE application

Having defined the message, the next step is to define the mapping between the handoff data and the message content in the DE.MAPPING table. The key to this table is comprised of:

• Message Type (the key to DE.MESSAGE)
• Application identifier (AA should be used in this case)
• Application sub type identifier

It is recommended that a different application identifier be chosen for each Product Line (and possibly different Product Groups under the same Product Line) as this allows multiple products to produce the same message type from different content. For an AA mapping definition, the following has to be defined:

• Link between named handoff records and underlying applications – For example:
  • INPUT.REC.7 MEMBER is the named Customer Property Class
  • INPUT.REC.8 COMMITMENT is the named Term Amount Property Class
• The handoff record number that contains the name of the product properties is also to be defined in the Record Name Loc field. For the AA module, record 7 always contains the property definition.
• The mapping between the message fields and the delivery handoff records can then be defined using Input Position, Input Name and Header Name fields. Where data is to be mapped from a property, the Input Position has to contain the name of the property, and Input Name has to contain the field name from the property.
• Data contained in the fixed data handoff records has to be mapped by specifying either:
  • Input Position as the record number with Input Name as the required field name.
  • Input Position only in the format record field.

Delivery events generated from AA module must contain an EB.ADVICES code. The Activity Messaging Property allows either an AA.ACTIVITY or AA.ACTIVITY.CLASS to be linked to an EB.ADVICES code.

In order to generate a delivery event for an ADVICE code that has already been defined in EB.ADVICES must be defined. Associated with this code must be either:

• The AA.ACTIVITY name that should trigger the production of the event (or)
• The AA.ACTIVITY.CLASS name that should be used in the production of the event for any AA.ACTIVITY of this AA.ACTIVITY.CLASS

The EB.ADVICES table provides the link between the ADVICE code allocated and the message types to be produced. The specified message type has to be associated with this Activity (multiple message types can be linked if required). Then MAPPING.KEY has to be the ID of the DE.MAPPING record built for the product and message.

Additional handoff data can be added to the delivery event, this is controlled by the definition in the EB.ADVICES table for the ADVICE code. The User Routine field allows an API to be written that can modify or add additional data to one or more of the handoff data records.

It is possible to suppress the delivery message at the arrangement level. This can be done using the Send Advice field. This field denotes whether the message needs to be sent or not. The user has to trigger the update activity of Activity Messaging to amend the setup at the arrangement level. The structure of the Activity Messaging Property Class has to be modified with the Send Advice field. Read the Delivery user guide for more information.

Pre Notice Activity field controls the activity for generating the advice for an activity, for example, LENDING-CANCEL-ARRANGEMENT. The Pre Notice Days field controls the time in advance when the notification is produced.

Pre-Notification (Delivery Advice) is available for all scheduled activities across Product Lines such as Lending, Deposits, and Accounts (For example: Interest resets, Rollovers and so on).