MX Payment Messages Generation

For the list of supported messages, see Swift Messages.

MX payment messages are generated by the Message engine based on Message Setup Configurations.

For information on integrating MX Payment Messages, see MX Payment Messages Integration.

For information on integrating camt.053, camt.054 messages, see Integrating Payment Messages and Statements.

1. Setup Requirements

1.1 Access Permissions

The following access permissions are required.

Outgoing Message Identifier Config

Create/Update: AddModifyOutgoingMessageIdentifier

Remove: RemoveOutgoingMessageIdentifier

Incoming Linked Message Identifier Config

Create/Update: AddModifyIncomingLinkedMessageIdentifier

Remove: RemoveIncomingLinkedMessageIdentifier

ISO 20022 External Code

Create/Update: AddModifyISO20022ExternalCode

Remove: RemoveISO20022ExternalCode

1.2 Environment Property

When environment property VALIDATE_MX_FORMAT = true, the Sender engine blocks an MX message if there is an XSD validation error and creates an exception task.

1.3 Agent Legal Entities

Member ID and Clearing System

The following legal entity attributes are used to populate tags: ClrSysId/Cd and ClrSysMmbId/MmbId.

<jurisdiction>ClrSysID_Code - Clearing system identification code

<jurisdiction>MmbId_ID - Clearing system member ID

They are currently used for message templates for the APN (pacs.009 messages), CHAPS, SIX and TARGET2 jurisdictions. For tags like Instructing Agent (InstgAgt) and Instructed Agent (InstdAgt), they allow sending the clearing member id instead of BIC information. Other jurisdictions expect BIC information instead.

Whenever member id information is used, it takes priority over BIC information, if both are present for a specific legal entity. If these LE attributes are not populated for a specific legal entity, then BIC information is populated like other jurisdictions.

Example:

SIXClrSysID_Code (Value of attribute should be populated with CHSIC as expected by SIX)

SIXMmbId_ID (Value of attribute should be populated with member identification assigned by SIX)

In order to populate ClrSysID_Code and MmbId_ID in payment messages for CBPR jurisdiction add :-

•

SDI Attribute in CP SDI "ClearingSystem" - This can have any value eg: CHIPS, FEDWIRE etc.

•

LE attributes in Counterparty Agent LE : a) CHIPSClrSysID_Code b)CHIPSMmbId_ID

Calypso will look for the set of Legal Entity Attributes starting with CHIPS, pick up the values from LE attributes as defined above to populate the same in MX payment messages.

LEI

If the LEI legal entity attribute is configured, the LEI tag is added to the messages for pacs008 and pacs009 CORE & COV CBPR+.

1.4 Counterparty Legal Entity

For admi.005 messages, the tags Report name (RptNm) and Scheduled date & time (FrDtTm) are only populated if counterparty attribute Admi005_P27_Receiver = false.

The tags Balance (Bal) and Date Time Range (DtTmRg) are only populated if legal counterparty Admi005_P27_Receiver = true.

1.5 Settlement Instructions

It is recommended that the settlement instructions use the SWIFT settlement method but there is no restriction.

Additionally, you may create different settlement method for each jurisdiction (TARGET2, SIX, MEPS, etc.), so that it can be used in SD Filter for picking up appropriate message setup.

To generate a cover message pacs.009.001.COV.<jurisdiction>, you need to check the Msg checkbox.

Sample PO Settlement Instructions

PO SDI Attribute <jurisdiction>SttlmPrty – The value is used in the messages (pacs.008, pacs.009, pacs.009COV) in the SttlmPrty tag. Valid values are NORM, HIGH and URGT. If the attribute does not have a value, the SttlmPrty tag defaults to NORM.

CBPRSttlmPrty

CHAPSSttlmPrty

MEPSSttlmPrty

There are free text name fields available in SDI for tags of Dbtr, DbtrAgt, Cdtr, CdtrAgt and IntrmyAgt1. These fields are used to populate name tags of legal entities in ISO20022 MX messages when multiple names (sort codes) are assigned to single legal entity.

PO SDI Attributes IBAN.Agent and IBAN.Intermediary – If the value is set to “true” or is no set, and the A/C field is populated, payment messages use the IBAN tag. If the value is set to "false", the tag Othr/Id is used. The payment message will be not be valid if the IBAN tag is used and the value is not a valid IBAN format.

SDI Attribute	Agent / Intermediary tab	Tag
IBAN.Agent	Agent A/C	DbtrAcct
IBAN.Intermediary	Intermediary A/C	DbtrAgtAccount

Sample Counterparty Settlement Instructions

Counterparty SDI Attributes IBAN.Agent, IBAN.Intermediary and IBAN.Intermediary2 – If the value is set to “true” or not set, and the A/C field is populated, payment messages use the IBAN tag. If the value is set to "false", the tag Othr/Id is used. The payment message will be not be valid if the IBAN tag is used and the value is not a valid IBAN format.

SDI Attribute	Agent / Intermediary tab	Tag
IBAN.Agent	Agent A/C	CdtrAcct/SttlmAcct
IBAN.Intermediary	Intermediary A/C	CdtrAgtAccount
IBAN.Intermediary2	Intermediary2 A/C	IntrmyAgt1Acct

If you set "Sender To Receiver Info" in the "Attributes & Notes" tab of the SDI, it populates tag InstrForNxtAgt/InstrInf of pacs.008/pacs.009 similar to tag 72 of MT103/MT202.

Population of this tag varies depending on jurisdiction as some allows 6 lines each of 35 characters like existing MT messages whereas some jurisdiction allows 4 lines each of 140 characters.

Example:

It can also be populated using the UPDATE_XFER_ATTR transfer action.

It can also be populated from the SenderInfo transfer attribute.

Optional tag SchmeNm is supported in pacs.009, pacs.009 COV, pacs.009 ADV, pacs.008, pacs.008 STP of CBPR jurisdiction. SchmeNm tag is present for the Creditor Account, Creditor Agent Account, Intermediary Agent account and is used to populate the External Account Identification Number which is provided by the SWIFT and the ID is used to populate the Identification Number of the particular Account Identification Code.

For CHATS messages, <Ctgy><Prty> is populated from Counterparty SDI attribute CategoryPurposeProp, and <Purp><Prty> is populated from Counterparty SDI attribute PurposeProp.

For CBPR messages, CategoryPurpose and CategoryCode are supported as well.

Tag <InstrForCdtrAgt> (InstructionForCreditorAgent_Info) is supported for pacs.009 MX messages and can be populated for the CBPR+ messages with the help of the Transfer attribute and SDI attribute.

The user can provide the Instruction for the creditor agent in the Attribute configuration window in the tag “InstructionForCreditorAgent_Info”.

User needs to set the “SetInternalAttribute” keyword in the workflow rule for the transfers.

If the user wants to pass the instructions to the creditor agent by the Trade attribute window, then the user needs to provide the information in the “InstructionForCreditorAgent_Info” tag of the attribute window.

To populate the information user needs to set the “PropagateTradeKeyword” workflow rule in the Transfer Workflow.

User can pass the Instruction for Creditor Agent with the help of the Counterparty SDI window by using the “InstructionForCreditorAgent_Info” section in the SDI window.

TARGET2 Settlement Instructions

In order to configure TARGET2 settlement instructions and integrate the TARGET2 directory, the counterparties and processing organizations need to have the role Addressee.

The TARGET2 directory is uploaded using the scheduled task LOAD_TARGET2_DIRECTORY.

The legal entity contacts used for the settlement instructions need to have the Swift code populated with the TARGET2 Addressee BIC code.

Sample TARGET2 directory:

The settlements instructions need to use the TARGET2 settlement method. In this case, the Addressee field is displayed, from which you can select the addressee from the TARGET2 directory. The Addressee is the Addressee registered in the TARGET2 directory for the Agent, Intermediary1 or Intermediary 2. The corresponding TARGET2 ID is stored in the SDI attribute Target2_Id.

For pacs.004 and pacs.008 message added the addressline tag under the Intermediary agent 2. Tags <TownName> and <Country> are now optional tags [0..1] for the Intermediary Agent 2 and these can be present or absent based on the user setting up the Legal entity contact.

The new logic for <AddressLine> tag is introduced with multiplicity [0..3] and up to 35 characters.

If the SWIFT BIC is present in the contact window, then calypso will populate the BIC tag and the name/ postal address should not be populated.

SDI Identifier fields

SDI Identifier fields are used to populate the tags Clearing System Code and Member Id in pacs.008, pacs.009 CORE and COV APN for Creditor Agent, Intermediary 1 and Intermediary 2, instead of using the Legal Entity Attributes APNClrSysID_Code and APNMmbId_ID.

Domain name: MX.ClearingSystemCode

Value: AU

Comment: AUBSB

The system looks for the CP SDI Identifier fields to populate the tags Clearing System Code and Member Id for Creditor Agent, Intermediary 1 and Intermediary 2:

•

use "AU" and the domain value created previously to populate the tag Clearing Member <Cd>AUBSB</Cd>

•

use the six digits with <MmbId>BSBCode</MmbId>;

If SDI Identifier fields are not present, then look for the Legal Entity Attributes APNClrSysID_Code and APNMmbId_ID to populate the above tags.

The SDI identifier message will be populated as Clearing System code and Clearing System Member ID in the Camt.057 message for the Debtor, Debtor Agent and Intermediary Agent.

User needs to set the ClearingSystem SDI attribute value XXXX and the Clearing System code can be present either in the respective Legal entity Attribute window for the Attribute type XXXXClrSysID_Code or in the domain value “MX.ClearingSystemMapping” having the Value XXXX and populate the Code in the Comment.

To populate the Clearing system Member ID user can use the SDI attribute field (Beneficiary, Agent and Intermediary) or can use the Identifier field in the SDI window or can also use the respective legal entity attribute window having the Attribute Type as XXXXMmbId_ID.

Both the Clearing System code and MemberId should be populated together either with the Standard SDI or the Manual SDI.

Setting up SDI for RTGS (e.g. AusPayNet, CHAPS, TARGET2, etc.) Settlements

The following table provides details about setting SDI for RTGS settlements:

We identify 3 main business case configurations:

•

If the counterparty is Financial and a RTGS member (scenario #1), the counterparty is its own agent. A pacs.009 will be sent to the counterparty itself, as agent.

•

If the counterparty is not a RTGS member but its agent is, check “Msg” for the Agent in counterparty SDI. If the counterparty is Financial (scenario #2), the agent receives a pacs.009. If the counterparty is non-Financial (scenario #5), the counterparty's agent receives a pacs.008 and agent configured in Processing Org SDI receives pacs.009COV.

•

If the counterparty and its agent are not RTGS members, the last Intermediary has “Msg” box checked. The last intermediary receives a pacs.009 if the Counterparty is Financial (scenarios #3 & #4), or a pacs.008 if counterparty is non-Financial (scenarios #6 & #7). If the counterparty is financial, its agent shouldn’t receive any message so “Msg” box remains unchecked . If the counterparty is non-financial, a pacs.009COV should be sent to the agent configured in Processing Org SDI, so “Msg” box is ticked.

1.6 Domain Values

Message Templates

Domain "MX.Templates"

This domain lists of all MX templates which are eligible for message generation within calypso. This is used in message setup to select specific template name.

admi.002.001.CHATS

admi.005.001

admi.007.001.T2

camt.029.001.APN

camt.029.001.CBPR

camt.029.001.MEPS

camt.029.001.SIX

camt.050.001.MEPS

camt.050.001.SIX

camt.050.001.T2

camt.050.001.T2S

camt.054.001.CBPR

camt.056.001.APN

camt.056.001.CBPR

camt.056.001.CHATS

camt.056.001.MEPS

camt.056.001.SIX

camt.056.001.T2

camt.057.001.CBPR

camt.058.001.CBPR

camt.107.001.CBPR

pacs.002.001.CBPR

pacs.002.001.SIX

pacs.004.001.APN

pacs.004.001.CBPR

pacs.004.001.CHAPS

pacs.004.001.CHATS

pacs.004.001.SIX

pacs.004.001.T2

pacs.008.001.APN

pacs.009.001.APN

pacs.008.001.CBPR

pacs.009.001.CBPR

pacs.009.001.ADV.CBPR

pacs.009.001.COV.CBPR

pacs.008.001.CHAPS

pacs.009.001.CHAPS

pacs.009.001.COV.CHAPS

pacs.008.001.CHATS

pacs.009.001.CHATS

pacs.009.001.COV.CHATS

pacs.008.001.MEPS

pacs.009.001.MEPS

pacs.009.001.COV.MEPS

pacs.008.001.SIX

pacs.009.001.SIX

pacs.008.001.T2

pacs.009.001.T2

pacs.009.001.COV.T2

pacs.010.001.CBPR

pacs.010.001.CHATS

pacs.010.001.T2

pain.001.001.CBPR

PaymentCOVMXCBPR.selector

PaymentCOVMXCHAPS.selector

PaymentCOVMXMEPS.selector

PaymentCOVMXSIX.selector

PaymentCOVMXT2.selector

seev032

seev.033.001.ECMS.T2S

seev036

seev.040.001

seev.040.001.ECMS.T2S

seev.041.001

seev044

semt002

sese.020.001.ECMS

sese.023.001.T2S

sese.023.001.ECMS

transmission.report.2.0.5

trck.001.001

xsys.002.001.APN

xsys.003.001.APN

xsys.002.001.MEPS

xsys.003.001.MEPS

Example:

Domain “MX.EnhancedTemplate.Revision.Version” - Enhanced TS2.1 Template

To switch to the enhanced template, the message needs to be added to the domain “MX.EnhancedTemplate.Revision.Version” with comment = TS2.1.

Example:

Value = pacs.004.001.CHAPS

Comment = TS2.1

Ⓘ [NOTE: As of 17 August 2022, CHAPS messages use the enhanced TS2.1 Template, whether this domain is set or not]

Domain "MX.BAH.Versions"

MX message consists of application header (generic across jurisdiction) and “Document” (main message body). This domain is used for storing AppHeader version to be used for specific MX template. As of now some jurisdictions are using version 1 while some are using version 2 of AppHeader. AppHeader version for specific MX template is mentioned in “Comment” of domain value.

camt.029.001.APN

camt.029.001.CBPR

camt.029.001.MEPS

camt.029.001.SIX

camt.050.001.MEPS

camt.050.001.SIX

camt.050.001.T2

camt.050.001.T2S

camt.054.001.CBPR

camt.056.001.APN

camt.056.001.CBPR

camt.056.001.CHATS

camt.056.001.MEPS

camt.056.001.SIX

camt.056.001.T2

camt.057.001.CBPR

camt.058.001.CBPR

pacs.002.001.CBPR

pacs.002.001.SIX

pacs.004.001.APN

pacs.004.001.CBPR

pacs.004.001.CHAPS

pacs.004.001.CHATS

pacs.004.001.SIX

pacs.004.001.T2

pacs.008.001.APN

pacs.009.001.APN

pacs.008.001.CBPR

pacs.009.001.CBPR

pacs.009.001.ADV.CBPR

pacs.009.001.COV.CBPR

pacs.008.001.CHAPS

pacs.009.001.CHAPS

pacs.009.001.COV.CHAPS

pacs.008.001.CHATS

pacs.009.001.CHATS

pacs.009.001.COV.CHATS

pacs.008.001.MEPS

pacs.009.001.MEPS

pacs.009.001.COV.MEPS

pacs.008.001.SIX

pacs.009.001.SIX

pacs.008.001.T2

pacs.009.001.T2

pacs.009.001.COV.T2

pacs.010.001.CBPR

pacs.010.001.CHATS

pacs.010.001.T2

pain.001.001.CBPR

trck.001.001

Example:

The Comment contains the AppHeader version.

Domain "MX.Versions"

Calypso has changed MX version (e.g. 08, 09 etc) with jurisdiction name (SIX, T2, CBPR, etc.) for supporting multiple jurisdictions. But, while generating the message, specific version is required to be populated in MsgDefIdr tag of AppHeader, this domain is used for defining version of the specific MX template.

camt.029.001.APN

camt.029.001.CBPR

camt.029.001.MEPS

camt.029.001.SIX

camt.050.001.MEPS

camt.050.001.SIX

camt.050.001.T2

camt.050.001.T2S

camt.054.001.CBPR

camt.056.001.APN

camt.056.001.CBPR

camt.056.001.CHATS

camt.056.001.MEPS

camt.056.001.SIX

camt.056.001.T2

camt.057.001.CBPR

camt.058.001.CBPR

camt.107.001

pacs.002.001.CBPR

pacs.002.001.SIX

pacs.004.001.APN

pacs.004.001.CBPR

pacs.004.001.CHAPS

pacs.004.001.CHATS

pacs.004.001.SIX

pacs.004.001.T2

pacs.008.001.APN

pacs.009.001.APN

pacs.008.001.CBPR

pacs.008.001.CBPR.STP

pacs.009.001.CBPR

pacs.009.001.ADV.CBPR

pacs.009.001.COV.CBPR

pacs.008.001.CHAPS

pacs.009.001.CHAPS

pacs.009.001.COV.CHAPS

pacs.008.001.CHATS

pacs.009.001.CHATS

pacs.009.001.COV.CHATS

pacs.008.001.MEPS

pacs.009.001.MEPS

pacs.009.001.COV.MEPS

pacs.008.001.SIX

pacs.009.001.SIX

pacs.008.001.T2

pacs.009.001.T2

pacs.009.001.COV.T2

pacs.010.001.CBPR

pacs.010.001.CHATS

pacs.010.001.T2

pain.001.001.CBPR

seev.033.001.ECMS.T2S

seev.040.001.ECMS.T2S

semt.002.001

semt.002.002

sese.020.001.ECMS

sese.023.001.T2S

sese.023.001.ECMS

trck.001.001

Example:

The Comment contains the message template version.

This domain also allows populating the RequestType tag with below information for CHAPS messages:

RequestType = <message type> + “.” + <comment from domain MX.Versions> for a given message

Example:

Domain = MX.Versions

Value = pacs.008.001.CHAPS

Comment = 08

=> RequestType = pacs.008.001.08

Domain "MX.T2"

For all T2 messages except camt.050, the comment of the domain "MX.T2" for Value = ReceiverDNRTGS is used to set the DN receiver.

Example:

Domain = MX.T2

Value = ReceiverDNRTGS

Comment = cn=rtgs,o=trgtxepm,o=swift

For T2 camt.050, if the GLAccount defined at PO SDI level has attribute Target2_MCA = true, the comment of the domain "MX.T2" for Value = ReceiverDNCLM is used to set the DN receiver.

Example:

Domain = MX.T2

Value = ReceiverDNCLM

Comment = cn=clm,o=trgtxepm,o=swift

If Target2_MCA = false or not set, the comment of the domain "MX.T2" for Value = ReceiverDNRTGS is used to set the DN receiver.

For T2 messages, the full name receiver is set as follows:

When tag <DN> = "cn=clm,o=trgtxepm,o=swift" , the tag <FullName> is the comment of Value = SAA.ReceiverCLM in domain MX.T2.

When tag <DN> = "cn=rtgs,o=trgtxepm,o=swift", the tag <FullName> is the comment of Value = SAA.Receiver in domain MX.T2.

Example:

Domain = MX.T2

Value = SAA.Receiver

Comment = TRGTXEPMXXX

For T2 Reda025:

Domain = MX.T2

Value = ReceiveDNCRDM

Comment = cn=crdm,o=trgtxe2s,o=swift

Reda025SenderDN=cn=cms,ou=t2s,o=dknbdkkk,o=swift

Domain "SWIFT.Templates.GPI"

UETR is generated for all templates defined under this domain.

pacs.008.001.APN

pacs.009.001.APN

pacs.008.001.CBPR

pacs.009.001.CBPR

pacs.009.001.COV.CBPR

pacs.008.001.CHAPS

pacs.009.001.CHAPS

pacs.009.001.COV.CHAPS

pacs.008.001.CHATS

pacs.009.001.CHATS

pacs.009.001.COV.CHATS

pacs.008.001.MEPS

pacs.009.001.MEPS

pacs.009.001.COV.MEPS

pacs.008.001.SIX

pacs.009.001.SIX

pacs.008.001.T2

pacs.009.001.T2

pacs.009.001.COV.T2

pacs.010.001.CBPR

pacs.010.001.T2

pacs.010.001.CHATS

pain.001.001.CBPR

Domain "MX.Templates.COV"

Cover message templates are defined under this domain.

pacs.009.001.COV.CBPR

pacs.009.001.COV.CHAPS

pacs.009.001.COV.CHATS

pacs.009.001.COV.MEPS

pacs.009.001.COV.T2

Domain "MX.BAH.BusinessService.Versions"

This domain allows users to set the business service <BizSvc> version.

pacs.008.001.APN

pacs.009.001.APN

pacs.009.001.ADV.CBPR

pacs.008.001.CHAPS

pacs.009.001.CHAPS

pacs.008.001.CHATS

pacs.009.001.CHATS

camt.058.001.CBPR

camt.107.001

Example:

The Comment contains the business service version.

For the APN jurisdiction, the BizSvc tag is set as follows:

•

apn.hvcs.<comment from domain MX.BAH.BusinessService.Versions>: For domestic message across HVCS.

•

apn.hvcs.xbrdr.<comment from domain MX.BAH.BusinessService.Versions>: For onward cross border payment using an Australian Intermediary.

"xbrdr" is added if counterparty SDI attribute MX.BAH.BusinessService = xbrdr.

This domain also allows populating the RequestSubtype tag with below information for CHAPS messages:

RequestSubtype = “boe.chaps.” + <comment from domain MX.BAH.BusinessService.Versions> for a given message

Example:

Domain = MX.BAH.BusinessService.Versions

Value = pacs.008.001.CHAPS

Comment = l4l.01

=> RequestSubtype = boe.chaps.l4l.01

Domain "MX.CHATS"

Value = SAA.Receiver

Comment = <SAA receiver>

Value = BAH.Receiver

Comment = <BAH receiver>

Value = ReceiverDN

Comment = <DN receiver>

Domain “messageType”

PaymentOrder

PaymentStatusNotification

ReceiptNotice

RequestCancellation (Used for camt.056 messages)

ResolutionOfInvestigation (Used for camt.029 messages)

CorporateActionMovementConfirmation (Used for seev.036)

Domain "iso20022Type"

Types available for ISO20022 External Codes window.

Domain "jurisdiction"

This domain is used in ISO20022 External Config window. See ISO20022 External Codes for details.

Domain "MXOtherJurisdiction"

You can define jurisdictions not supported by Calypso in that domain.

This is used to retrieve the IncominLinkMessageIdentifier for these jurisdictions.

Domain ”SimpleTransfer.subType”

Add the value RETURN to the domainName ”SimpleTransfer.subType”. This transfer type is used by RETURN transfer required in pacs.004 (Payment Return) message generation process.

Domain "SAA.Revision.Version"

This domain is used to populate the Revision tag as:

Revision = <comment from domain SAA.Revision.Version> for a given message

The default value is 2.0.5 if not set.

Example:

Domain = SAA.Revision.Version

Value = pacs.008.001.CHAPS

Comment = 2.0.11

=> Revision = 2.0.11

For Reda025 messages:

Domain = SAA.Revision.Version

Value = reda.025.001.T2S

Comment = 2.0.5

=> Revision = 2.0.11

Domain "SaaMessageIdentifier"

Note: This would not have any impact on MsgDefIdr of AppHeader.

For Reda025 messages:

Domain = SaaMessageIdentifier

Value = reda.025.001.T2S

Comment = DRAFT5

Domain "camt056CancellationReason"

This is an optional domain that can be used to populate the default cancellation reason code (CxlRsnInf/Rsn/Cd) in camt.056 messages.

Example:

Value = <jurisdiction>

Comment - <default cancellation reason code>

Domain "camt058CancellationReason"

This is an optional domain that can be used to populate the default cancellation reason code (CxlRsnInf/Rsn/Cd) in camt.058 messages.

Example:

Value = <jurisdiction>

Comment = <default cancellation reason code>

Domain "camt056CancellationReasonProp"

This is an optional domain that can be used to populate the default proprietary cancellation reason code (CxlRsnInf/Rsn/Prop) in camt.056 messages.

Example:

Value = <jurisdiction>

Comment - <default proprietary cancellation reason code>

Proprietary reason codes are only allowed in specific jurisdictions and should be set accordingly.

Domain "MessageExcludeTemplate"

This domain is used for both camt.056 and camt.029 messages for Request to cancellation and response to that request.

Example:

Domain "MappingIncomingWithContact"

When the SWIFT BIC code is looked up in the LE Contact, it is using Contact Type = ALL by default. Then the corresponding processing org is selected.

You can use another contact type by adding it to the domain “MappingIncomingWithContact”:

Value = <message type>

Comment = <LE Contact type to be used to lookup the processing org>

Example:

Value = PACS009

Comment = MatchingSystem

If there is no contact with this contact type, the first contact found is used.

Domain "MemberId"

Value = Reda025

Comment = PUNB143566LONDON

Domain "ClearingSysPropId"

Value = Reda025

Comment = T2S

Domain "NetworkInfo"

Value = Reda025

Comment = esmig.t2.iast

Value = <message type>

Comment = <value of tag Network Info Service>

Tracker Messages

Domain "role"

Value = tracker

Domain "MT199_UNIV"

Value = MT199Receiver

Comment = Short name of legal entity with role Tracker

Domain "UniversalConfirmation"

Value = TrackerReceiver

Comment = Short name of legal entity with role Tracker

Value = Trck.001TagInstrId

Comment = pacs.008TagInstrId

Value = Trck.001TagUETR

Comment = pacs.008TagUETR

Value = pacs.008TagInstrId and Value = pacs.008TagUETR must also be added to the domains "tradeKeyword", "PropagateTradeKeyword", "XferAttributes".

Trade Keywords

Add the following values to the domains "tradeKeyword".

LinkedEndToEndId

LinkedInstructionId

LinkedMessageType

LinkedMessageIdentifier

LinkedInterbankSettleAmount

LinkedInterbankSettleDate

LinkedUETR

RegulatoryReportingState

ReturnAdditionalInformation

ReturnInstructedAgentBIC

ReturnInstructingAgentBIC

ReturnReason

TxId

EndToEndId

MessageType

MessageIdentifier

InstructedAgentBIC

InstructingAgentBIC

pacs.008TagInstrId

pacs.008TagUETR

Add the following values to the domain "PropagateTradeKeyword".

LinkedEndToEndId

LinkedInstructionId

LinkedMessageType

LinkedMessageIdentifier

LinkedInterbankSettleAmount

LinkedInterbankSettleDate

LinkedUETR

RegulatoryReportingState

ReturnAdditionalInformation

ReturnInstructedAgentBIC

ReturnInstructingAgentBIC

ReturnReason

TxId

EndToEndId

InstructionId

MessageType

MessageIdentifier

InstructedAgentBIC

InstructingAgentBIC

pacs.008TagInstrId

pacs.008TagUETR

SIX 2022 Release

To activate the SIX 2022 release, you need to set Value = true in domain “MXUseSIX2022” and set the template name and version in domains “MX.Versions” and “MX.XSD.Version”.

Example:

Domain = MX.XSD.Version

Value = pacs.009.001.SIX

Comment = 08.ch.02

This release covers:

•

Update of all MX messages to ISO version level 2019.

•

All messages - Mandatory use of UETR. InstructionId is no longer used to populate UETR.

•

Added ClrSys = SIC for SIX jurisdiction.

•

Added SIXSttlmPrty SDI attribute to populate SttlmPrty tag.

•

Added CategoryPurposeProp SDI attribute to populate CtgyPurp tag.

•

Removed ESRPMT payment type.

•

pacs.004 integration – UETR needs to be added to the matching keys of the matching context. ClrSys changed from PCH to SIC.

•

camt.025 integration – Request type changed from CSC to SIC.

SIX 2023 Release

To activate the SIX 2023 release, you need to set Value = true in domain “MXUseSIX2023” and set the template name and version in domains “MX.Versions” and “MX.XSD.Version”.

Example:

Domain = MX.XSD.Version

Value = pacs.009.001.SIX

Comment = 08.ch.03

This release covers:

•

camt.029: tag /Document/RsltnOfInvstgtn/CxlDtls/TxInfAndSts/CxlStsRsnInf/AddtlInf: ATR053/" replaces "ATR7", "ATR057/" replaces "ATR6";

•

XSD update for the below messages:

pacs.009 => pacs.009.001.08.ch.03

camt.029 => camt.029.001.09.ch.02

camt.056 => camt.056.001.08.ch.03

•

Remove dependency on domain MXUseSIX2022 for all SIX templates: pacs.004, pacs.008, pacs.009, camt.029, camt.050, camt.056, camt.025 (integration only).

SIX 2024 Release

To activate the SIX 2024 release, you need to set Value = true in domain “MXUseSRChanges” and set the template name and version in domains “MX.Versions” and “MX.XSD.Version”.

Example:

Domain = MX.XSD.Version

Value = camt.029.001.SIX

Comment = 09.ch.03

This release covers:

•

Adjustments to reclaims from the "Bank and third-party system payments (pacs.009)" Message - Pacs.009 is added as underlying message in camt.056 and camt.029.

•

Standardization of the amount split for all participants - Amount split handling in pacs.008 and pacs.009: Added new tag Service Level in Code format to populate “SPLI” if Transfer attribute “SplitKey” is populated OR “BusinessReason” is set to “SPLIT”, if not present, populate with the transfer attribute ServiceLevelCode.

•

XSD update for the below messages:

camt.029 => camt.029.001.09.ch.03

camt.056 => camt.056.001.08.ch.04

CHAPS 2025 May enhanced data update

This release covers:

•

Added the support of the Purpose tag in Code format in pacs.008 and pacs.009 CHAPS messages - The Transfer Attribute Keyword “PurposeCode” or the Counterparty SDI attribute “PurposeCode” are added to populate the Purpose in code format.

•

Added the LEI for IntrmyAgt1, IntrmyAgt2, Dbtr, Cdtr, CdtrAgt for pacs.008, pacs.009 CORE and COV, and pacs.004 CHAPS messages – Populated the LEI tag with the Legal Entity Attribute LEI, and removed the dependency with CASH_USE_LEI_FOR_SWIFTMX Legal Entity Attribute for already implemented LEI logic for Pacs.009 CORE and Pacs.009 COV.

1.7 Message Setup

There are two fields in the message setup which are specifically important for MX messages:

•

Gateway - It can be selected as either MX or SAA or FILE or "customized" gateway. If SAA is selected, additional technical header info required for SWIFT Alliance Access is populated in MX messages. If MX gateway is selected, then the message is not populated with SAA technical header. If FILE gateway is selected the SAA technical header is not populated by default. For populating SAA technical header with FILE gateway, domain MX.DisplaySAAHeader should be set to TRUE.

•

Format type - It should be selected as MX which allows to select templates defined in MX.Templates domain

pacs.008 / pacs.009 Messages

The message template "PaymentCOVMX<jurisdiction>.selector" allows generating pacs.008 / pacs.009 messages based on whether the counterparty is financial or non-financial. It also generates pacs.009.001.COV messages (cover messages) if the Msg checkbox is checked on the PO SDI and the counterparty is non-financial.

Alternatively, you can use the message template pacs.008 / pacs.009 with specific static data filters.

Sample message setup with PaymentCOVMXCBPR.selector

camt.056 Messages

camt.056 messages are generated when the RECALL action is applied on a transfer for which the pacs.008 / pacs.009 message was generated (recommended approach) or through trade cancellation.

Ⓘ [NOTE: You need to chose one or the other. You cannot configure both options]

Option 1 - Sample message setup for RECALL action

Static data filter

On the Message workflow for payments messages (PaymentOrder), you need to add the UpdateTransfer rule on the SENT - ACK - ACKED transition to update the transfer with the xfer attribute MXJurisdiction using the following rule parameter:

Option 2 - Sample message setup for trade cancellation

The message setup is the same except that the template should be set to "PaymentCOVMX<jurisdiction>.selector".

This process is described below.

seev.040 Messages

Configuration of the message set up in order to assign the generation of the seev.40 once the election has been canceled is shown below. The SDFilter can be used to configure the specific CA events on which a seev.040 needs to be sent, using the CA event SWIFT code and/or the CA option SWIFT code.

As per the existing logic of MT565(CANC), the generation of the message following a cancellation of an instruction should be displayed in the message tab of the Election Management GUI, linked to the Agent election object.

Use existing workflow - Election message workflow (subtype = CA_ELECTION)

EVENT_TYPE = PARTIALLY_ELECTED_CAELECTION_CANCELLATION

pacs.010 Messages

For CBPR, the message template PaymentCOVMXCBPR.selector generates pacs.010.001.CBPR messages for the receipt transfers.

Alternatively, you can use the message template pacs.010.001.CBPR.

For T2, the message template PaymentCOVMXT2.selector generates pacs.010.001.T2 messages for the receipt transfers.

Alternatively, you can use the message template pacs.010.001.T2.

Sample message setup with pacs.010.001.T2

Sample message setup for pacs.010.001.COL.CBPR

camt.050 Messages

camt.050 messages are generated for the payments of Transfer Agent trades.

Sample message setup

camt.057.001.CBPR Messages

For CBPR, the message template PaymentCOVMXCBPR.selector generates camt.057.001.CBPR messages for the receipt transfers.

Alternatively, you can use the message template camt.057.001.CBPR.

Sample message setup with camt.057.001.CBPR

SDI attribute "CAMT057TagsunderNtfctn" should be set on the PO SDI, with value as either "True/False/Blank". If the value is "True", then tags will be placed under <Ntfctn> else under <Itm>.

Now DbtrAgt, IntrmyAgt & XpctdValDt tags will be populated under Ntfctn or Ntfctn/Itm tag based on the above logic.

The updated logic for IntrmyAgt tag is such that it will try to get in this precedence as Intermediary1 in PO Receiver SDI > if not present, Intermediary2 in CP Payer SDI > if not present, Intermediary1 in CP Payer SDI > if not present, Agent in CP Payer SDI.

camt.058 Messages

camt.058 messages are generated when the RECALL action is applied on a transfer for which the camt.057 message was generated (recommended approach) or through trade cancellation.

Option 1 - Sample message setup for RECALL action

In this sample setup, Message Type is ReceiptNotice. But you can also use a setup with a dedicated Message Type = RequestCancellation.

This is a manual process. When the RECALL action is applied, the “Transfer RECALL” window pops up.

Option 2 - Trade cancellation

The message setup is the same except that the template should be set to "PaymentCOVMXCBPR.selector".

The camt.058 is generated from the reverse transfer generation when doing the trade cancellation, because the original transfer, of direction RECEIVE, is in SETTLED status.

pacs.004 Messages

pacs.004 messages are generated for the return payments of Simple Transfer trades.

Sample message setup

Static data filter

You can also use the PaymentCOVMX<jurisdiction>.selector templates.

trck.001.001 Messages

trck.001.001 messages are used for universal confirmation of pacs.008 messages. They provide status update on payments received through pacs.008.

The trades associated with the pacs.008 messages must contain the trade keywords pacs.008TagInstrId and pacs.008TagUETR.

Create a message setup for the case of SETTLED_RECEIPT, and for the case of FAILED_RECEIPT.

Example:

pacs.002.001.CBPR Messages

pacs.002.001.CBPR messages can be generated from the Matching Manager when rejecting incoming pacs.008 / pacs.009 messages.

Sample message setup

camt.029 Messages

camt.029 messages are generated when action REJECT_REQUEST is applied on receipt transfers for which pacs.008/pacs.009 is integrated and camt.056 (Request for cancellation) is received.

Sample message setup

Target2Message static data filter is the same as used in camt.056 message.

camt.054 Messages

Sample message setup

camt.055 Messages

The CustomerPaymentCancellationRequest message is issued by the initiating party to request the cancellation of an initiation payment message previously sent (such as CustomerCreditTransferInitiation pain.001 or CustomerDirectDebitInitiation pain.008).

It should be noted that pain.008 is not supported by Calypso currently.

Sample message setup

camt.055 messages are generated when the RECALL action is applied on a transfer for which the pain.001 / pain.008 message was generated.

In this sample setup, Message Type = RequestCancellation.

This is a manual process. When the RECALL action is applied, the “Transfer RECALL” window pops up.

Static data filter

pain.001 Messages

Payment messages for customer transfer payments.

Sample message setup

admi.005 Messages

admi.005 messages allow requesting reports to the receiver. Open the MX BO Message Generator window using menu action refdata.MXBOMessageGeneratorFormatWindow.

Sample message setup

1.8 pacs.002.001.CBPR Messages - Additional Setup

Domain Values

Domain “eventType”

PAYMENT_STATUS

Domain “eventClass”

PSEventGenericOnObject

Domain “MessagePaymentStatusApplyAction”

REJECT_PAYMENT

Domain “messageAction”

REJECT_PAYMENT (same action as domain “MessagePaymentStatusApplyAction”)

Message Engine

Add subscription to PSEventGenericOnObject.

Message Workflow for Incoming pacs.008 / pacs.009

Add transition UNPROCESSED – REJECT_PAYMENT – CANCELED

See MX Payment Messages Integration for information on integrating pacs.008 / pacs.009 messages.

In the matching context, for pacs.008 / pacs.009, select Allow Payment Status in “More Options” panel.

1.9 Suggested Transfer Workflow

Orig Status	Action	Resulting Status	Wkf Rule	STP	Filter	Comment
PENDING	ACCEPT	VERIFIED	CheckTarget2Valid	Y
PENDING	UPDATE_DATE	PENDING	UpdateSettleDate
PENDING	ASSIGN	CANCELED
PENDING	CANCEL	CANCELED
VERIFIED	MATCH	SETTLED	CopyPacsKeyword			Action depends on Matching app configuration
VERIFIED	MANUAL_MATCH	SETTLED				Action depends on Matching app configuration
VERIFIED	AUTO_SETTLE	SETTLED			Only applicable to Transfers generating PACS008/9/10 and outgoing Return Xfer	If not rejected prior to Settle Date, payment must be considered settled Scheduled Task PROCESS_TRANSFER should be run daily to apply AUTO_SETTLE action
VERIFIED	CANCEL	CANCELED
VERIFIED	ASSIGN	CANCELED
VERIFIED	SPLIT	SPLIT
VERIFIED	REJECT	TO_BE_REGENERATED				Received PACS.002 rejection
VERIFIED	RECALL	TOBECANCELED	AddRecallDateAttribute		Only applicable to Transfers generating PACS008/9/10	Generates camt.056 The RECALL action automatically updates the RECALL_DATE on the transfer
TOBECANCELED	CANCEL	CANCELED
TOBECANCELED	SETTLE	SETTLED
VERIFIED	REJECT_RECALL	VERIFIED	RemoveXferAttributes (Param Recall_Date)			T2 does not necessarily sends camt.029 negative (status RJCR) to confirm rejection ofRECALL_REQUEST. Payment needs to move to SETTLED at Settle Date through Scheduled Task PROCESS_TRANSFER Manage Recall status by running a Transfer Report where the RECALL_DATE <> null.
VERIFIED	ACCEPT_RECALL	CANCELED	RemoveXferAttributes (Param Recall_Date)
TO_BE_REGENERATED	ASSIGN	CANCELED
TO_BE_REGENERATED	CANCEL	CANCELED
TO_BE_REGENERATED	UPDATE_DATE	PENDING	UpdateSettleDate
SETTLED	RECALL	SETTLED	AddRecallDateAttribute		Only applicable to Transfers generating PACS008/9/10	Generates camt.056
SETTLED	REJECT_RECALL	SETTLED	RemoveXferAttributes (Param Recall_Date)			As an answer might not be received, payment should move back to Settled through Scheduled Task PROCESS_TRANSFER - Recommend to use SD Filter based on Recall Date to select transfer with recall date greater than x days.
SETTLED	RETURN	SETTLED	RemoveXferAttributes (Param Recall_Date, Request_Date)			System Transition (applied at pacs.004 linkage. Reason should be stored as XferAttribute). IF Xfer Amounts are the same RETURN else PARTIAL_RETURN
SETTLED	UNMATCH	VERIFIED
SETTLED	REQUEST	SETTLED	AddRequestDateAttribute		Only applicable to Transfers NOT generating PACS008/9/10	Received camt.056 and potentially generates a camt.029 if necessary - The system REQUEST transfer action will automatically update the REQUEST_DATE on the transfer.
SETTLED	REJECT_REQUEST	SETTLED	RemoveXferAttributes (Param Request_Date)		Only applicable to Transfers NOT generating PACS008/9/10	Received camt.056 and potentially generates a camt.029 if necessary with status RJCR

Note: AMEND, UPDATE, SPLIT and FAIL transitions should be added where applicable.

The transfer workflow rules are described below.

AddRecallDateAttribute

When applied, a new Recall_Date transfer attribute will be saved on transfer.

If a Recall_Date is already available on transfer, then it will be updated with new action date (only the latest recall date will be stored)

AddRequestDateAttribute

When applied, a new date Request_Date transfer attribute will be saved on transfer.

If a Request_Date is already available on transfer, then it will be updated with new action date (only the latest request date will be stored)

CheckTarget2Valid

Purpose of this workflow rule is to control that the payment is compliant with Target2 Rules.

Check if value date respects the configuration defined in Value Date Control (see Value Date Control for details)

•

If yes, return True

•

Else, return False (block the transition)

CopyPacsKeyword

It allows copying MsgAttributes to the related Matched transfer as XferAttributes upon integration. It is used in pacs.008/pacs.009 message integration process.

RemoveXferAttributes

When applying RECALL/REQUEST action, a new date Recall_Date/Request_Date will be stored.

Then, when the answer to the recall request is received from the payment beneficiary, the Recall_Date/Request_Date should be removed so users can know that there is no longer a pending Recall/Request attached. Recall_Date/Request_Date can be passed as “Rule Param”.

So this rule, should be set on transitions with original status where Recall/Request action can be applied.

In the proposed workflow, it should be set in transitions with actions REPLY and RETURN

When applied, workflow rule will:

•

If Recall_Date/Request_Date available, delete it

•

If Recall_Date/Request_Date not available, take no action

The workflow rule does not block the transition.

1.10 Swift LAU Encryption

You can define LAU encryption keys using the Swift LAU window.

Please refer to Calypso Swift Messages documentation for details.

2. ISO20022 General Configuration

2.1 Value Date Control

Menu action refdata.ValueDateControlConfigWindow.

To ensure that the value date of the Transfer is within the accepted time frame. This is based on the warehousing period allowed for specific jurisdiction. This configuration is used in the transfer workflow rule (CheckTarget2Valid) which should be configured in the Transfer workflow if you intend to use such functionality.

It is a unique combination of currency and method. Below information must be completed:

•

Currency

•

Method

•

Calendar (e.g. it should be Target2 holiday calendar)

•

Cut off Time

•

Number of days (if value date is more than x days from current date)

•

Day Type (business/calendar)

•

ChangeSettleDate: This flag will is used in UpdateSettleDate workflow rule

•

Timezone

Example:

This means that for payments in EUR and settled in Target 2, the calendar to be used is TARGET and it cannot be generated 10 calendar days before Value Date.

2.2 Reference Management

In case of ISO20022 MX messages, multiple identifiers (InstructionId, EndToEndID, UETR, etc.) are populated in a message.

The functionality below provides support for message vs. message matching functionality if there is an expectation to match a specific identifier in outgoing message (generated by Calypso) vs. a specific identifier in the incoming message (received and integrated in Calypso).

Message Attribute MessageIdentifier is populated based on Outgoing Message Identifier setup and it can be matched against the message attribute mentioned in Incoming Linked Message Identifier.

Setting Up Outgoing MessageIdentifier

Menu action refdata.OutgoingMessageIdentifierConfigWindow.

Outgoing MessageIdentifier is the Message Identifier that will be stored as Message attribute of outgoing messages. When indexed incoming messages is integrated, this attribute is used to link it.

Fields:

•

Template - Message Template of the outgoing message for which this configuration is done. "PaymentCOVMX<jurisdiction>.Selector" templates cannot be used for this setup.

•

Method - Settlement Method of the PO SDI.

•

Object Identifier - Field that populates the message attribute MessageIdentifier. Possible values: MessageId, TransferId, MsgAttribute.<message attribute>, XferAttribute.<transfer attribute>. If MsgAttribute/XferAttribute is used, it should be available at the time of message generation.

Example: pacs.008.001.T2 – Target2 - MsgAttribute.UETR

In this scenario, outgoing pacs.008.001.T2 for Target 2 contains the attribute MessageIdentifier with the value from message attribute UETR.

For xsys.002 and xsys.003 integration, you need to add:

pacs.008.001.MEPS - SWIFT - MsgAttributes.EndToEndId

pacs.009.001.MEPS - SWIFT - MsgAttributes.EndToEndId

Setting Up Incoming Linked Message Identifier

Menu action refdata.IncomingLinkedMessageIdentifierConfigWindow.

This applies to incoming messages only.

It determines which reference of the incoming indexed message should be used to link it with outgoing message.

When integrating the incoming message, the system should find the outgoing message that contains the message attribute MessageIdentifier with same value as the message attribute of the incoming message defined in this configuration.

Fields:

•

Template - Message Template of the incoming message for which this configuration is done. "PaymentCOVMX<jurisdiction>.Selector" templates cannot be used for this setup.

•

Message Attribute - Message attribute of the incoming message to be used for matching message attribute MessageIdentifier of outgoing message.

•

Applicable Outgoing Templates - Outgoing message templates to which this configuration applies (separated by ";"). "PaymentCOVMX<jurisdiction>.Selector" templates cannot be used for this setup.

Example: pacs.004.001.T2 – LinkedUETR - pacs.008.001.T2;PACS.009.001.T2

In this scenario, LinkedUETR attribute of incoming pacs.004.001.T2 is matched with MessageIdentifier attribute of outgoing messages pacs.008.001.T2;pacs.009.001.T2.

For xsys.002 and xsys.003 integration, you need to add:

xsys.002.001.MEPS - LinkedOriginalMsgId - pacs.008.001.MEPS;pacs.009.001.MEPS

xsys.003.001.MEPS - LinkedOriginalMsgId - pacs.008.001.MEPS;pacs.009.001.MEPS

2.3 ISO20022 External Codes

Menu action refdata.ISO20022ExternalCodeWindow.

This window is used to store ISO20022 external codes published by SWIFT per specific jurisdictions. These are used to set various codes (Return Reason, Payment Cancellation Rejection, etc.) in MX messages (pacs.004, camt.029, camt.056, camt.058).

SWIFT published list of codes is available at below link:

https://www.iso20022.org/catalogue-messages/additional-content-messages/external-code-sets

You need to enter the following columns:

•

Type - This is the type ISO20022 external code (e.g., ReturnReason, PaymentCancellationRejection, etc.). It is defined in iso20022Type domain

•

Code – This is the code as published by SWIFT or jurisdiction

•

Name – This is the name as published by SWIFT or jurisdiction. It is not used in MX messages, but it is displayed for information purposes

•

Definition – This is the definition of the code as published by SWIFT or jurisdiction. It is not used in MX messages, but it is available for information purposes

•

Jurisdiction – This is a column used to maintain separate codes per jurisdiction for the same “type”

•

Code Type – Whenever ISO20022 external codes are populated in MX messages, it is either populated in “Cd” or “Prtry” tag. It is an optional column used in case of need to populate proprietary (Prtry) code in MX messages. If this type is not selected, code will be populated in “Cd” tag by default.

Detailed usage of the different “types”:

ReturnReason - Used in pacs.004 message generation when RETURN action is applied on transfer. It is used for populating return reason code (RtrRsnInf/Rsn/Cd).

PaymentCancellationRejection - Used in camt.029 message generation when REJECT_REQUEST action is applied on transfer. It is used for populating Cancellation Status Reason code (CxlStsRsnInf/Rsn/Cd or Prtry).

InvestigationExecutionConf - Used in camt.029 message generation when REJECT_REQUEST action is applied on transfer. It is used for populating Confirmation Status Code (Sts/Conf).

CancellationReason - Used in camt.056 message generation when RECALL action is applied on transfer. It is used for populating Cancellation reason code (CxlRsnInf/Rsn/Cd or Prtry). It is also used when UPDATE_CANCEL_REASON is applied on camt.056 message for populating Cancellation reason code (CxlRsnInf/Rsn/Cd or Prtry).

CancellationReasonReceipt - Used in camt.058 message generation when RECALL action is applied on transfer. It is used

for populating Cancellation reason code (CxlRsnInf/Rsn/Cd). It is also used when UPDATE_CANCEL_REASON is applied on camt.058 message for populating Cancellation reason code (CxlRsnInf/Rsn/Cd)."

3. Disabling xml tag population in ISO20022 MX message templates

A new feature is provided to disable xml tag population in ISO20022 MX message templates and move them as Optional tags. "Optional MX Tag Suppress" can be configured using action key > refdata.OptionalMXTagSuppressWindow.

To disable a tag and add it as optional tag:

•

Click on New .

•

Define a config for tags to be suppressed for which select a message format type (ex., MX, SAA) and select a template type.

•

Details section will show all the tags that will be suppressed and added as Optional XML Tags.

•

Click on Save .

The tags are moved from main message to optional tags.

4. SAA DataPDU Header

The SAA DataPDU header is slightly different for each jurisdiction.

You can use a different PO contact types to populate specific information in the respective Data PDU headers:

•

The <Service> tag can be populated using the MXNetInfoService addressMethod of PO contact type.

•

The <DN> Distinguished Name tag under <Sender> can be populated using the MXDistinguishedName addressMethod of sender PO contact type.

•

The <DN> Distinguished Name tag under <Receiver> can be populated using the MXDistinguishedName addressMethod of Receiver PO contact type for all jurisdictions, except TARGET2. For TARGET2, the Receiver DN is configured using the domain "MX.T2" as described above.

•

The <FullName> tag under <Receiver> is populated using the receiver SWIFT BIC for all jurisdictions except TARGET2. For TARGET2, the full name is set in the domain "MX.T2" as described above.

For example, you can have a message setup for the Default PO contact type for CBPR and the Settlement PO contract type for Target2.

CBPR message setup and Sender Default contact details

CBPR Message

<Sender> (from sender Default contact)

<DN>cn=calyus33,ou=xxx,o=calyus33,o=swift</DN>

<FullName><X1>CALYUS33XXX</X1></FullName>

</Sender>

<Receiver> (from receiver contact)

.../...

</Receiver>

<NetworkInfo> (from sender Default contact)

<Service>swift.finplus!pf</Service>

</NetworkInfo>

TARGET2 message setup and Settlement contact details

TARGET2 Message

<Sender> (from sender Settlement contact)

<DN>cn=live,ou=esmig,o=calyus33,o=swift</DN>

<FullName><X1>CALYUS33XXX</X1></FullName>

</Sender>

<Receiver> (from MX.T2 domain)

<DN>cn=rtgs,o=trgtxepm,o=swift</DN>

<FullName><X1>TRGTXEPMXXX</X1></FullName>

</Receiver>

<NetworkInfo> (from sender Settlement contact)

<Service>swift.tst2.iast!p</Service>

</NetworkInfo>

5. Business Application Header

The domain “MX.DisplayAppHeader” allows activating or deactivating the generation of the Business Application Header (BAH) for a given template.

The default is TRUE so if this domain value is not defined then the BAH is generated for the MX Messages.

You can add a template to the domain with Comment = FALSE to deactivate the generation of the BAH. As of now only the SIX jurisdiction allows messages without BAH. BAH is mandatory for all other jurisdictions.

The following BAH fields are supported:

Name

Path

Description

From

/Document/AppHdr/Fr/FIId/FinInstnId/BICFI

Provides the message sender SWIFT details

/Document/AppHdr/To/FIId/FinInstnId/BICFI

Provides the message receiver SWIFT details

Business Message Identifier

/Document/AppHdr/BizMsgIdr

Provides the Calypso generated Message ID

Message Definition Identifier

/Document/AppHdr/MsgDefIdr

This field displays the name of the business document. It is dependent on the MX template generated and the defined MX.Version assigned to the template

Example - pacs.008.001.08

Irrelevant data (e.g. COV) is removed when populating MsgDefIdr tag as per requirement of respective jurisdiction.

Business Service

/Document/AppHdr/BizSvc

This field identifies which specification the message complies with. The supported elements are:

Service Administrator: defaulted to boe

Service: defaulted to CHAPS

Version: Based on domain MX.BAH.BusinessService.Versions

An example of a <BizSvc> is boe.chaps.01

Creation Date

/Document/AppHdrCreDt

Provides the message creation date

Clearing System prop id

/Document/AppHdr/Fr/FIId/FinInstnId/ClrSysMmbId/ClrSysId/Prtry

Only applicable for TARGET2

Check "Sender" (Processing Org) contact type from message setup with addressMethod = T2ClrSysID_Code

If addressMethod (first preference) is missing for contact type, then populate legal entity attribute (second preference) T2ClrSysID_Code

Clearing System member id

/Document/AppHdr/Fr/FIId/FinInstnId/ClrSysMmbId/MmbId

Only applicable for TARGET2

Check "Sender" (Processing Org) contact type from message setup with addressMethod = T2MmbId_ID

If addressMethod (first preference) is missing for contact type then populate legal entity attribute (second preference) T2MmbId_ID

Other Id

SenderAppHeadOtherId: /AppHdr/Fr/FIId/FinInstnId/Other/Id

ReceiverAppHeadOtherId: /AppHdr/To/FIId/FinInstnId/Other/Id

Only applicable for TARGET2

Check "Sender" contact type from message setup with addressMethod attributes;

SenderAppHeadOtherId : /AppHdr/Fr/FIId/FinInstnId/Other/Id

ReceiverAppHeadOtherId: /AppHdr/To/FIId/FinInstnId/Other/Id

•

If missing in addressMethod for contact type

Look for the same attributes in LE Attributes

•

If missing in LE attributes

Do not populate the tag.

6. Generating pacs.008 / pacs.009 and COV Messages

Message fields (some fields are in the cover message for pacs.009 Messages).

Name	Path	Configuration	Description
Message Identification	/Document/FIToFICstmrCdtTrf/GrpHdr/MsgId	System Generated	Provides the Calypso generated Message ID
Creation Date Time	/Document/FIToFICstmrCdtTrf/GrpHdr/CreDtTm	System Generated	Provides the message creation system date tine
Number of Transactions	/Document/FIToFICstmrCdtTrf/GrpHdr/NbOfTxs	Default value	Defaulted to 1
Settlement Method	/Document/FIToFICstmrCdtTrf/GrpHdr/SttlmInf/SttlmMtd	Default value	Defaulted to CLRG for RTGS messages like TARGET2, CHAPS, CHATS, etc. For CBPR+, if Cover Message is also sent then populate with "COVE" otherwise populate with "INDA".
Settlement Time Request	/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/SttlmTmReq	CPTY SDI Attribute Settlement_CLS_Time Settlement_Till_Time Settlement_From_Time Settlement_Reject_Time	Settlement_CLS_Time attribute value will be populated in CLSTm Settlement_Till_Time attribute value will be populated in TillTm. Settlement_From_Time attribute value will be populated in FrTm. Settlement_Reject_Time attribute value will be populated in RjctTm.
Clearing System	/Document/FIToFICstmrCdtTrf/GrpHdr/SttlmInf/ClrSys/Cd	Default value	Defaulted to STG
Instruction Identification	/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/PmtId/InstrId	Message keyword INSTRUCTION_ID	Provides the Calypso generated Message ID or Trade ID, depending on what is populated in EndtoEndId, MsgId.
End To End Identification	/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/PmtId/EndToEndId	Default value	Defaulted to “NOTPROVIDED”
UETR	/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/PmtId/UETR	Domain Configuration: SWIFT.Templates.GPI	A UETR is generated if the message template is added to the domain.
Service Level	/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/PmtTpInf/SvcLvl/Cd	LE Attribute: SWIFT_GPI	This field is populated with “001” if the LE Attribute SWIFT_GPI is set on either the PO or CP
Local Instrument	/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/PmtTpInf/LclInstrm/Prtry	Trade Keyword: MXPaymentType	If trade keyword is not given, then this field is defaulted to CRED. See specific logic below for pacs.008.001.SIX / pacs.009.001.SIX messages.
Local Instrument Code	/Document/FICdtTrf/CdtTrfTxInf/PmtTpInf/LclInstrm/Cd	PO SDI attribute LocalInstrumentCode
Category Purpose	/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/PmtTpInf/CtgyPurp/Cd	Derived value	If PO Parent = CP Parent, then field is set to INTC otherwise field is defaulted to CORT
Interbank Settlement Amount, Currency	/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/IntrBkSttlmAmt/@Ccy	Trade information	Populated with the settlement amount and currency
Interbank Settlement Date	/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/IntrBkSttlmDt	Trade information	Populated with the Settle Date
Settlement Priority	/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/SttlmPrty	SDI Attribute: <jurisdiction>.SttlmPrty For T2 messages, it is the PO SDI Attribute: RTGSSttlmPrty	Provides the value as given in the SDI Attribute. Possible values are URGT, HIGH, and NORM.
Instructed Amount, Currency	/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/InstdAmt/@Ccy	Trade information	Populated with the initial amount to be transferred before deduction of any charges
Exchange Rate	/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/XchgRate	Trade information	Populated with the exchange rate, if any.
Charge Bearer	/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/ChrgBr	SDI attribute: Details_Of_Charges See also SDI attribute SenderChargeFeeType below.	Based on value defined in the SDI attribute. If Details_Of_Charges = OUR then field is populated as “DEBT” If Details_Of_Charges = BEN, then field is populated as “CRED” If Details_Of_Charges = SHA, then field is populated as “SHAR”
Charges Information Amount	/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/ChrgsInf/Amt/@Ccy	Based on Fee Type: REMITTANCE	Populated with the REMITTANCE fee amount and currency.
Charges Information Agent (with BIC)	/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/ChrgsInf/Agt/FinInstnId/BICFI	LE Contact: SWIFT value	Populated with the LE Contact BIC assigned to the REMITTANCE fee payer/receiver
Charges Information Agent (with Clearing System Identification “Code”)	/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/ChrgsInf/Agt/FinInstnId/ClrSysMmbId/ClrSysId/Cd	LE Attribute: <jurisdiction>ClrSysID_Code	Populated with the LE Attribute “<jurisdiction>ClrSysID_Code” assigned to the REMITTANCE fee payer/receiver
Charges Information Agent (with Clearing System Identification “Member Identification”)	/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/ChrgsInf/Agt/FinInstnId/ClrSysMmbId/MmbId	LE Attribute: <jurisdiction>MmbId_ID	Populated with the LE Attribute “<jurisdiction>MmbId_ID” assigned to the REMITTANCE fee payer/receiver
Instructing Agent	/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/InstgAgt/FinInstnId/BICFI	LE Contact: SWIFT value	Populated with the Sender.SWIFT
Instructed Agent	/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/InstdAgt/FinInstnId/BICFI	LE Contact: SWIFT value	Populated with the Receiver.SWIFT
Intermediary Agent 1 (with BIC)	/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/IntrmyAgt1/FinInstnId/BICFI	LE Contact: SWIFT value	Populated with the CP Receiving Intermediary 1 BIC Code
Intermediary Agent 1 (with Clearing System Identification “Code”)	/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/IntrmyAgt1/FinInstnId/ClrSysMmbId/ClrSysId/Cd	LE Attribute: <jurisdiction>ClrSysID_Code	Populated with the CP Receiving Intermediary 1 LE Attribute “<jurisdiction>ClrSysID_Code"
Intermediary Agent 1 (with Clearing System Identification “Member Identification”)	/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/IntrmyAgt1/FinInstnId/ClrSysMmbId/MmbId	LE Attribute: <jurisdiction>MmbId_ID	Populated with the CP Receiving Intermediary 1 LE Attribute “<jurisdiction>MmbId_ID”
Intermediary Agent 1 Account (with IBAN)	/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/IntrmyAgt1Acct/Id/IBAN	SDI Attribute: IBAN.Intermediary2 = True or not set	Account information for the CP Receiving Intermediary 1 is given on the SDI field Intermediary2 A/C. This field is populated with Intermediary2 A/C details if IBAN.Intermediary2 = True or not set
Intermediary Agent 1 Account (with Other)	/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/IntrmyAgt1Acct/Id/Othr/Id	SDI Attribute: IBAN.Intermediary2 = False	Account information for the CP Receiving Intermediary 1 is given on the SDI field Intermediary2 A/C. This field is populated with Intermediary2 A/C details if IBAN.Intermediary2 = False
Debtor (with BIC)	/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/Dbtr/Id/OrgId/AnyBIC	LE Contact: SWIFT value	Populated with the Sender.SWIFT. That is, the PO Beneficiary BIC Code
Debtor Account (with IBAN)	/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/DbtrAcct/Id/IBAN	SDI Attribute: IBAN.Agent = True or not set	Account information for the PO is given on the SDI field Agent A/C. This field is populated with Agent A/C details if IBAN.Agent = True or not set
Debtor Account (with Other)	/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/DbtrAcct/Id/Othr/Id	SDI Attribute: IBAN.Agent = False	Account information for the PO is given on the SDI field Agent A/C. This field is populated with Agent A/C details if IBAN.Agent = False
Debtor Agent (with BIC)	/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/DbtrAgt/FinInstnId/BICFI	LE Contact: SWIFT value	Populated with the PO Agent BIC Code
Debtor Agent(with Clearing System Identification “Code”)	/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/DbtrAgt/FinInstnId/ClrSysMmbId/ClrSysId/Cd	LE Attribute: <jurisdiction>ClrSysID_Code	Populated with the PO Agent LE Attribute “<jurisdiction>ClrSysID_Code"
Debtor Agent (with Clearing System Identification “Member Identification”)	/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/DbtrAgt/FinInstnId/ClrSysMmbId/MmbId	LE Attribute: <jurisdiction>MmbId_ID	Populated with the PO Agent LE Attribute “<jurisdiction>MmbId_ID”
Debtor Agent Account (with IBAN)	/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/DbtrAgtAcct/Id/IBAN	SDI Attribute: IBAN.Intermediary = True or not set	Account information for the PO Agent is given on the SDI field Intermediary A/C. This field is populated with Intermediary A/C details if IBAN.Intermediary = True or not set
Debtor Agent Account (with Other)	/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/DbtrAgtAcct/Id/Othr/Id	SDI Attribute: IBAN.Intermediary = False	Account information for the PO Agent is given on the SDI field Intermediary A/C. This field is populated with Intermediary A/C details if IBAN.Intermediary = False
Creditor Agent (with BIC)	/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/CdtrAgt/FinInstnId/BICFI	LE Contact: SWIFT value	Populated with the CP Agent BIC Code
Creditor Agent(with Clearing System Identification “Code”)	/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/CdtrAgt/FinInstnId/ClrSysMmbId/ClrSysId/Cd	LE Attribute: <jurisdiction>ClrSysID_Code	Populated with the CP Agent LE Attribute “<jurisdiction>ClrSysID_Code"
Creditor Agent (with Clearing System Identification “Member Identification”)	/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/CdtrAgt/FinInstnId/ClrSysMmbId/MmbId	LE Attribute: <jurisdiction>MmbId_ID	Populated with the CP Agent LE Attribute “<jurisdiction>MmbId_ID”
Creditor Agent Account (with IBAN)	/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/CdtrAgtAcct/Id/IBAN	SDI Attribute: IBAN.Intermediary = True or not set	Account information for the CP Agent is given on the SDI field Intermediary A/C. This field is populated with Intermediary A/C details if IBAN.Intermediary = True or not set
Creditor Agent Account (with Other)	/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/CdtrAgtAcct/Id/Othr/Id	SDI Attribute: IBAN.Intermediary = False	Account information for the CP Agent is given on the SDI field Intermediary A/C. This field is populated with Intermediary A/C details if IBAN.Intermediary = False
Creditor (with BIC)	/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/Cdtr/Id/OrgId/AnyBIC	LE Contact: SWIFT value	Populated with the Receiver.SWIFT. That is, the CP Beneficiary BIC Code
Creditor (with Name)	/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/Cdtr/Nm	SDI Beneficiary Name / CP Long Name	Populated with the Receiver.Long Name.
Creditor (with Address)	/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/Cdtr/PstlAdr/<postal address>	LE Contact: Address field or address details	Populated with LE Contact Address field or all address details. All address details are populated only if both City and Country are present. Otherwise, only the Address field is populated in the <postal address>. The address details can contain the following codes if they are present in domain "addressMethod" and set in the LE Contact: AddressType, Department, SubDepartment, StreetName, BuildingNumber, Floor, PostBox, Room, PostCode, TownLocationName, DistrictName, CountrySubDivision.
Creditor Account (with IBAN)	/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/CdtrAcct/Id/IBAN	SDI Attribute: IBAN.Agent = True or not set	Account information for the CP is given on the SDI field Agent A/C. This field is populated with Agent A/C details if IBAN.Agent = True or not set
Creditor Account (with Other)	/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/CdtrAcct/Id/Othr/Id	SDI Attribute: IBAN.Agent = False	Account information for the CP is given on the SDI field Agent A/C. This field is populated with Agent A/C details if IBAN.Agent = False
Instruction For Next Agent “Instruction Information”	/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/InstrForNxtAgt/InstrInf	“Sender to Receiver Info” as seen in the SDI Attributes tab or SenderInfo transfer attribute	Populated with value given in the SDI field “Sender to Receiver Info”
Purpose	/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/Purp/Prtry	Trade Keyword: 26T	Populated with value given in the trade keyword “26T”
Remittance Information (Unstructured)	/Document/FIToFICstmrCdtTrf/CdtTrfTxInf/RmtInf/Ustrd	SDI Attribute: Remittance_Information	Populated with the value given in the SDI Attribute Remittance_Information
Instruction Priority	/Document/FICdtTrf/CdtTrfTxInf/PmtTpInf/InstrPrty	Transfer Attribute InstructionPriority	The Instruction Priority is populated with transfer attribute InstructionPriority.

For pacs.009 cov, creditor (Cdtr), creditor agent (CdtrAgt) and intermediary agent 1 (IntrmyAgt1) depends on the receiver of pacs.008 message. The Creditor of pacs.009 cov message is the party which will receive funds settled via pacs.009 cov i.e. receiver of the corresponding pacs.008 message. Subsequently, next agents in the payment chain are considered as creditor agent and intermediary agent 1 when configured in the counterparty SDI (see 1.1.5 settlement instructions section for details).

SDI attribute SenderChargeFeeType

You can select the fee type that populates charge amount under ChrgsInf using the SDI attributes SenderChargeFeeType and Details_Of_Charges. The fee type must be defined with attribute Amount_Percentage_Value (fee percentage or fee amount).

If Default_Calculator in Fee Definition is of type “Percentage”:

•

Fee Amount = Payment Transfer amount * (Amount_Percentage_Value / 100)

If Default Calculator in Fee Definition is of type “NONE”:

•

Fee Amount = Fixed amount specified in Amount_Percentage_Value

This fee is generated using the transfer workflow rule GenerateFeeXfer.

SDI attribute Details_Of_Charges should be set with allowed values (OUR, BEN, SHA) as per jurisdiction. If it is not set up in SDI and charge information is mandatory in the respective message, it is populated as “SHAR” which means shared charges.

The user needs to set a value in SDI Attribute and basis on that values will be returned in message content in ChrdBr tag.

SDI Attribute "Details_Of_Charges"	Derived Value in "ChrgBr" tag
OUR	DEBT
BEN	CRED
SHA	SHAR
Blank	SHAR

When SDI attribute Details_Of_Charges is set to “BEN” and SenderChargeFeeType SDI attribute is configured with appropriate fee as mentioned above:

•

ChrgsInf amount is populated with the fee amount.

•

IntrBkSttlmAmt i.e. Interbank Settle Amount = Payment Transfer Amount – Fee Amount

Specific Logic for pacs.008.001.SIX / pacs.009.001.SIX Messages

pacs.009.001.SIX

CdtTrfTxInf/PmtTpInf/LclInstrm/Prtry - Shows trade keyword MXPaymentType if set, or F2FPMT otherwise.

When CdtTrfTxInf/PmtTpInf/LclInstrm/Prtry = CMPPMT then CdtTrfTxInf/PmtTpInf/SvcLvl/Prtry is populated with trade keyword ServiceLvlPmtCode if set, or "000" otherwise.

/Document/FinInstnCdtTrf/CdtTrfTxInf/InstrForNxtAgt/InstrInf - Shows counterparty SDI attribute SIXInstructionToRTGS if set, or is empty otherwise.

We can add a comma "," to separate the values for instance “LIQU,CONF”, so it will display in 2 occurrences as below:

</InstrForNxtAgt>

</InstrForNxtAgt>

pacs.008.001.SIX

CdtTrfTxInf/PmtTpInf/LclInstrm/Prtry - Shows trade keyword MXPaymentType if set, or CSTPMT otherwise.

/Document/FinInstnCdtTrf/CdtTrfTxInf/RmtInf/Ustrd is only set with REMITTANCE_INFO if CdtTrfTxInf/PmtTpInf/LclInstrm/Prtry = CSTPMT

/Document/FinInstnCdtTrf/CdtTrfTxInf/RmtInf/Strd is only set with REMITTANCE_INFO if CdtTrfTxInf/PmtTpInf/LclInstrm/Prtry = ESRPMT

/Document/FinInstnCdtTrf/CdtTrfTxInf/RmtInf/Strd/CdtrRefInf/Ref is only set with REMITTANCE_INFO_REF if CdtTrfTxInf/PmtTpInf/LclInstrm/Prtry = ESRPMT

7. Generating pacs.008 STP message

•

The pacs.008 STP message has enhanced STP feature over and above the pacs.008 and legacy MT 103 STP.

•

Name and Postal address are removed from all applicable agents (InstgRmbrsmntAgt, InstdRmbrsmntAgt, ThrdRmbrsmntAgt, IntrmyAgt1, IntrmyAgt2, DbtrAgt, CdtrAgt)

•

Selector template (PaymentCOVMXCBPR.selector) is enhanced to pick up pacs.008 STP template if all conditions mentioned below are satisfied:

SWIFT BIC is present for all applicable agents (InstgRmbrsmntAgt, InstdRmbrsmntAgt, ThrdRmbrsmntAgt, IntrmyAgt1, IntrmyAgt2, DbtrAgt, CdtrAgt)

Creditor Account (CdtrAcct) is present.

If DbtrAgt & CdtrAgt SWIFT BIC is part of below list of countries then Dbtr/Nm, Cdtr/Nm, DbtrAcct/IBAN, CdtrAcct/IBAN must be present.

Country List (AT, BE, BG, BV, CY, CZ, DE, DK, EE, ES, FI, FR, GB, GF, GI, GP, GR, HR, HU, IE, IS, IT, LI, LT, LU, LV, MQ, MT, NL, NO, PL, PM, PT, RE, RO, SE, SI, SJ, SK, VA, MC, SM, AD)

8. Generating pacs.004 Messages

pacs.004 messages are generated by the Party that returns received funds (i.e., party that received a pacs.008/009). pacs.004 must be linked to the pacs.008/009 through the unique payment identifiers.

Return can be for the total amount received or just a partial amount.

Different scenario for pacs.004 generation are explained below.

Scenario 1

•

Originator sent pacs.008/pacs.009

•

RTGS settled payment to Beneficiary account

•

Originator bank sends camt.056 requesting cancellation of pacs.008/pacs.009 sent earlier

•

Beneficiary bank responds with pacs.004 to return the funds

Scenario 2

•

Originator sent pacs.008/pacs.009

•

RTGS settled payment to Beneficiary account

•

Originator bank sends camt.056 requesting cancellation of pacs.008/pacs.009 sent earlier

•

Beneficiary bank responds with camt.029 (RJCT status/RJCR for SIX) rejecting to return the funds

Scenario 3

•

Originator sent pacs.008/pacs.009

•

Settlement date is in future/warehoused Payment is queued and hence RTGS has not settled payment yet

•

Originator bank sends camt.056 requesting cancellation of pacs.008/pacs.009 sent earlier

•

RTGS responds with camt.029 (CNCL status) to confirm that pacs.008/pacs.009 sent earlier will never reach the settlement

pacs.004 messages are generated when action RETURN is applied to a receipt transfer for which an incoming pacs.008/pacs.009 is integrated.

Eligible Transfers to which this action can be applied:

•

Transfer is linked to an incoming pacs.008 or pacs.009 message

•

Xfer attribute ReturnTransfer and ReturnedTransfer are not true (it cannot be applied on an already returned transfer)

Transfer Return Window

When the RETURN action is applied the Transfer Return window is displayed:

You can modify the amount to be returned as needed and select a return reason (See ISO20022 External Code).

Then click Ok.

1. A Simple Transfer trade is created (Transfer Type = RETURN) based on original transfer being returned & data provided in above pop-up window.

XferAttribute ReturnedTransfer = True. This is used to ensure that the RETURN action cannot be applied on same transfer again.

2. The below Trade Keywords are populated on RETURN transfer trade:

•

PACS004Direction (If original incoming message is pacs.010 then PACS004Direction = Outgoing, otherwise PACS004Direction = Incoming)

•

Returned Xfer Id (contains Xfer Id of the returned transfer)

•

ReturnReason (contains Reason code selected by user in RETURN window)

•

ReturnAdditionalInformation (contains Additional Information added by user in RETURN window)

•

ReturnTransfer (Value = True)

•

Apart from different attributes (LinkedMessageIdentifier, LinkedInstructionId, etc.) will be propagated to RETURN Xfer using PropagateTradeKeyword workflow rule. These attributes are populated on original transfer when pacs.008/pacs.009 is integrated successfully

•

LinkedMessageIdentifier (contains Xfer Attribute MessageIdentifier of Original transfer)

•

LinkedMessageType (contains Xfer Attribute MessageType of Original transfer)

•

LinkedInstructionId (contains Xfer Attribute InstructionId of Original transfer)

•

LinkedEndToEndId (contains Xfer Attribute EndToEndId of Original transfer)

•

LinkedUETR (contains Xfer Attribute UETR of Original transfer)

•

LinkedTxId (contains Xfer Attribute TxId of Original transfer)

•

LinkedInterbankSettleAmount (contains Xfer Attribute InterbankSettleAmount of Original transfer)

•

LinkedInterbankSettleDate (contains Xfer Attribute InterbankSettleDate of Original transfer)

•

ReturnInstructingAgentBIC (contains Xfer Attribute InstructedAgentBIC of Original transfer)

•

ReturnInstructedAgentBIC (contains Xfer Attribute InstructingAgentBIC of Original transfer)

•

InstgAgt_SIXClrSysID_Code

•

InstgAgt_SIXMmbId_ID

•

InstdAgt_SIXClrSysID_Code

•

InstdAgt_SIXMmbId_ID

3. The above attributes are used for the generation of the pacs.004 message.

SDI attribute Details_Of_Charges

The user needs to set a value in SDI Attribute and basis on that values will be returned in message content in ChrgBr tag.

SDI Attribute "Details_Of_Charges"	Derived Value in "ChrgBr" tag
OUR	DEBT
BEN	CRED
SHA	SHAR
Blank	N/A (Not populated)
Any value apart from BEN/OUR/SHA	N/A (Not populated)

9. Generating pacs.002.001.CBPR Messages

In the Matching Manager, right-click a pacs.008 / pacs.009 message and choose Matching > Payment Status > REJECT.

You can also apply the REJECT_PAYMENT action to a pacs.008 / pacs.009 message from the Message report.

You are prompted to provide a reason and click Ok.

The pacs.002 message is generated:

The tag BizMsgIdr contains the ID of the rejected pacs.008 / pacs.008 message.

Example:

10. Generating camt.029 Messages

camt.029 messages are generated when action REJECT_REQUEST is applied to a receipt transfer for which an incoming pacs.008/pacs.009 is integrated.

Refer to scenario mentioned in section “Generating pacs.004 messages” which are applicable for camt.029 generation.

Eligible Transfers to which this action can be applied:

•

Transfer is linked to an incoming pacs.008 or pacs.009 message

Reject Request Window

When the action REJECT_REQUEST is applied, the Reject Request Window is displayed.

•

Reason (ISO20022 code) - Stored in transfer attribute CancelReason if its Code Type is Cd or CancelReasonProp if its Code Type is Prtry

•

Reason Description (ISO20022 code description)

•

Additional Information (free text) – Stored in transfer attribute CancelAdditionalInformation

11. Generating camt.055 Messages

For generating a camt.055 message, a Customer Transfer trade shall be booked to generate pain.001 which is moved to ACK so that transfer moves to SETTLED status. RECALL action is then applied on the transfer.

The message camt.055 is generated and linked to pain.001:

The message camt.055 has details of corresponding pain.001.

12. Generating camt.056 Messages

camt.056 messages are generated when the RECALL action is applied on a transfer for which the pacs.008 / pacs.009 / pacs.010 message was generated (recommended approach) or through trade cancellation.

Ⓘ [NOTE: You need to choose one or the other. You cannot configure both options]

12.1 Option 1 - RECALL Action (Recommended Approach)

It is a manual process. Refer to the scenarios mentioned in section “Generating pacs.004 messages” which are applicable for camt.056 generation.

When the RECALL action is applied, the “Transfer RECALL” window is displayed:

•

Reason (ISO20022 allowed codes) ISO20022 codes of type CancellationReason should be configured as specified in ISO20022 External Code => This field will be stored as value for transfer attribute CancellationReason if its Code type is Cd (or blank) and CancellationReasonProp if its Code type is Prtry

•

Reason Description (ISO20022 code description) – Not modifiable. Name column of External code selected

12.2 Option 2 - Trade Cancellation

There is a possibility that a trade is canceled by an external system (outside Calypso) which triggers trade cancellation in Calypso. In such a case, if the transfer is already settled, Calypso creates a new transfer in opposite direction (Receive vs Pay) and there is an expectation to generate a camt.056 message for this transfer if there is a payment message (pacs.008/pacs.009) linked to the original transfer.

In this case, the message setup for camt.056 messages should use the "PaymentCOVMX<jurisdiction>.selector" template.

The rule CheckCancellationReason needs to be added to the VERIFIED - TO_SEND - TO_BE_SENT transition of the PaymentOrder message workflow which is used by pacs.008/pacs.009/camt.056 messages.

This rule checks that the payment cancellation reason code (CxlRsnInf/Rsn/Cd or CxlRsnInf/Rsn/Prop) is populated to avoid failure on the SWIFT network. It only applies to camt.056 messages.

Population of cancellation reason code:

You can setup a default cancellation reason code in the domains "camt056CancellationReason" and "camt056CancellationReasonProp". See above for details.

You can also use the message action UPDATE_CANCEL_REASON to set the cancellation reason code on a camt.056 message.

You need to add it to the PaymentOrder message workflow: VERIFIED - UPDATE_CANCEL_REASON - VERIFIED so that when there is a failure in the workflow due to the CheckCancellationReason rule, this action can be applied to resolve it.

Applying this action opens a popup window that allows selecting the cancellation reason code from the “ISO20022 External Codes”.

If you want the ability to change the default cancellation reason code manually, the UPDATE_CANCEL_REASON action can be added to the PaymentOrder message workflow: TO_BE_SENT - UPDATE_CANCEL_REASON - TO_BE_SENT.

13. Generating camt.058 Messages

camt.058 messages are generated when the RECALL action is applied on a transfer for which the camt.057 message was generated (recommended approach) or through trade cancellation.

Ⓘ [NOTE: You need to choose one or the other. You cannot configure both options]

13.1 Option 1 - RECALL Action (Recommended Approach)

It is a manual process. When the RECALL action is applied, the “Transfer RECALL” window is displayed:

•

Reason (ISO20022 allowed codes) ISO20022 codes of type CancellationReason should be configured as specified in ISO20022 External Code => This field will be stored as value for transfer attribute CancellationReason if its Code type is Cd (or blank) & CancellationReasonProp if its Code type is Prtry.

•

Reason Description (ISO20022 code description) – Not modifiable. Name column of External code selected.

13.2 Option 2 - Trade Cancellation

There is a possibility that a trade is canceled by an external system (outside Calypso) which triggers trade cancellation in Calypso. In such a case, if the transfer is already settled, Calypso creates a new transfer in opposite direction (Receive vs Pay) and there is an expectation to generate a camt.058 message for this transfer if there is a payment message (camt.057) linked to the original transfer.

In this case, the message setup for camt.058 messages should use the "PaymentCOVMXCBPR" template.

The rule CheckCancellationReason needs to be added to the VERIFIED - TO_SEND - TO_BE_SENT transition of the PaymentOrder message workflow which is used by camt.058 messages.

Population of cancellation reason code:

•

You can setup a default cancellation reason code in the domains "camt058CancellationReason" and "camt058CancellationReasonProp". See above for details.

•

You can also use the message action UPDATE_CANCEL_REASON to set the cancellation reason code on a camt.058 message.

•

Applying this action opens a popup window that allows selecting the cancellation reason code from the “ISO20022 External Codes”.

14. Handling Custom MX Templates

For APN and CBPR jurisdictions with custom MX templates the following domains are introduced, so that they don’t get overridden by out-of-the-box templates upon upgrade:

•

MXMessageIdentifiers – It should contain jurisdictions for which the message identifier tags should not be overridden in the MX message templates.

•

MXCustomTemplateName – It should contain jurisdictions for which the corresponding MX message templates should not be overridden