Reviewing Payment Messages

Once transfers are verified, the payment messages are generated. They will not however be sent until they are actually settled. This default behavior may be modified through the Transfer workflow.

1. Message Configuration

You should have message configurations for the following event types as needed: <transfer_status>_SEC_DELIVERY and <transfer_status>_SEC_RECEIPT for security transfers, and <transfer_status>_PAYMENT and <transfer_status>_RECEIPT for cash transfers.

Sample payment message setup

•

The message template "Payment.selector" allows picking up automatically the proper MTx92, MT202 or MT103 XML templates.

•

The message template "Securities.selector" allows picking up automatically the proper MT540-543 XML templates.

•

The message template "PaymentCOV.selector" allows producing "standard" MT202, "standard" MT103, MT104, "standard" MT210, and related "standard" MT192 and 292, when no cover message is required, for non-financial counterparties.

It also allows producing the MT202 COV (instead of a standard MT202) when a cover message is required. A cover message is required when the counterparty SDI (settlement instruction) is flagged with "Msg".

Sample payment counterparty SDI that requires a cover message

•

The message template "PaymentCOVAll.selector" applies to non-financial counterparties as well as financial counterparties.

If "Msg" is checked in the Agent tab of the counterparty's SDI and "Msg" is checked in the Agent tab of the PO's SDI, MT202Cov (to PO agent) and MT103 (to counterparty agent) messages are generated instead of MT202 and MT202.

•

The message template "Payment205COV.selector" allows producing "standard" MT205, "standard" MT103, "standard" MT210, and related "standard" MT192 and 292, when no cover message is required.

It also allows producing the MT205 COV (instead of a standard MT205) when a cover message is required. A cover message is required when the counterparty SDI is flagged with "Msg".

•

The message template MT103XferAgent allows producing MT103 messages with tag 53B (Sender's Correspondent) when "Msg" is checked in the SDIs for Transfer Agent trades.

•

The message template MT202Switch allows replacing Tag 21 with the content of Tag21_MT202.xml. You can customize Tag21_MT202.xml as needed.

Refer to Calypso Messages documentation for details on specifying message configurations and generating messages.

Refer to Calypso Message Grouping documentation for information on generating grouped messages.

Refer to Calypso Swift Messages documentation for information on Swift messages features and message keywords.

Refer to Calypso Cash Management documentation for information on payment messages and statements integration (MT103, MT202, MT202COV, MT204, MT205, MT205COV, MT210, MT900, MT910, camt.054, MT940, MT942, MT950, MT970, camt.053).

See MX Payment Messages Generation and MX Payment Message Integration for setup information on MX payment messages.

Note on Canceled Payment Messages

When canceling a payment message, the template used is not a cancellation template if Payment.Selector is not used.

In order to use the cancellation template, you need to add the original template to the domain “Templates.CANCEL” with Comment = <cancellation template>.

Example:

Value = MT202XferAgent

Comment = MT292

Prevent Generation of Canceled Payment Messages

You can use domain "MsgEngineCheckCancelSDFilter" to list SDFilter for which the cancel messages will not be generated for previously SETTLED Payment Messages.

MT199 Messages

You can generate MT199 messages using the MT199_UNIV message template for legal entity role Tracker.

You can define the following info in the domain "MT199_UNIV":

•

Value = Tag21_RelatedReference – Comment = Trade keyword that contains tag 20 of incoming MT103

•

Value = Tag121_UETR – Comment = Trade keyword that contains tag 121 UETR of the incoming MT103

•

Value = MT199Receiver – Comment = Short name of legal entity with role Tracker.

The corresponding trade keywords must be defined in the domains "tradeKeyword", "PropagateTradeKeyword", "XferAttributes".

2. Safe Settlement

It is possible to link two messages, one Receipt Message and one Payment Message, and send the Payment Message only if the Receipt Message reaches a specific status.

This applies to trades with two payment messages (cash payments against security payments).

The rule ReleaseCredit should be set on the Message Workflow of the Receipt/Debit Message Type, on the transition for which it is safe to send the Payment/Credit Message Type.

Example: SENT – ACK – ACKED.

It requires the following domains to be defined:

•

DebitAcceptanceMessageTypes

Value = Receipt Message, example SEC_RECEIPTMESSAGE

Comment = Linked Payment Message, example PAYMENTMSG

•

DebitAcceptanceMessageAction

Value = Linked Payment Message, example PAYMENTMSG

Comment = Action to be applied to the linked message, example SEND

In this example, the rule ReleaseCredit is set in the SEC_RECEIPTMESSAGE message workflow on the transition SENT – ACK – ACKED. When the SEC_RECEIPTMESSAGE reaches the status ACKED, the action SEND will be applied to the linked PAYMENTMSG.

3. Viewing Payment Messages

From the Calypso Navigator, navigate to Reports > Message Reports > Message Report (menu action reporting.ReportWindow$Message). You can also bring up the Task Station.

Double-click a message to drill-down to the actual payment document.

Check that all payments and receipts are sent before cut-off if any cut-off is specified.

You can configure the columns that you want to display. Choose for details.