Integrating Settlement Returns

This document describes the settlement returns function and the basic setup to be done in the system to integrate and process incoming MT536, MT537, MT540, MT541, MT542, MT543, MT544, MT545, MT546, MT547, MT548, MT578, and MT586 messages within Calypso.

• MT536: Statement of Transactions
• MT537: Statement of Pending Transactions
• MT540: Receive Free
• MT541: Receive Against Payment
• MT542: Deliver Free
• MT543: Deliver Against Payment
• MT544: Receive Free Confirmation (vs. an MT540 outgoing message)
• MT545: Receive Against payment Confirmation (vs. an MT541 outgoing message)
• MT546: Deliver Free Confirmation (vs. an MT542 outgoing message)
• MT547: Deliver Against payment Confirmation (vs. an MT543 outgoing message)
• MT548: Settlement Status and Processing Advice
• MT578: Alleged Settlement
• MT586: Statement of Alleged Settlement

 

It also describes the generation of MT530 messages to request settlement instruction changes.

 

You can also use the Swift MX messages instead of the Swift messages.

 

1. Setup Requirements

 

1.1 Environment Properties

Review the following properties as they impact the integration of the incoming messages.

Environment Properties

Description
CHANGE_CASH_SIGN_FOR_PARTIAL_SETTLE

True or false. When set to true, the system bypasses the check that the cash amount of an incoming netted transfer cannot have an opposite sign from the outgoing transfer. Default is false.

CHECK_QUANTITY_FOR_SECURITY_MATCHING

Default value is false. If false the system tries to apply automatically the action PARTIAL_SETTLE on the transfer that would have a quantity higher than the quantity of the incoming message. If true the message is not matched and falls in the Security Matching Window.

PARTIAL_CASH_FOR_SECURITY_MATCHING

Applies when the security amount of the incoming message is the same as the transfer amount, but the cash amounts differ.

If false, the transfer is settled, regardless of the cash amount. The cash amount of the incoming message is set on the transfer.

If true, the transfer is split. The security transfer is settled and the cash transfer is failed. If WRITE_OFF_FOR_SECURITY_MATCHING is true, and the cash difference is within the settlement tolerance, the failed transfer becomes a settled WRITE_OFF transfer.

USE_NUMERIC_FOR_RELA_REF

True or false. Default is true. When importing Tag 20C RELA reference, all non-numeric characters are removed.

You need to set USE_NUMERIC_FOR_RELA_REF to false to keep all characters.

USE_TRANSFER_FOR_EXTERNAL_REF

Default value is false.

Set to false, the system tries to match the reference of the incoming swift (tag 20C::RELA) with a Calypso MessageId. If set to true, the system tries to match the reference of the incoming swift (tag 20C::RELA) with a Calypso TransferId.

In any case, if there is no correspondence found (MessageId or TransferId), the system tries to match the reference of the incoming message with the content of the transfer attribute MATCHING_REF.

WRITE_OFF_FOR_SECURITY_MATCHING

True to allow writing off the cash difference when the difference is within the settlement tolerance, or false otherwise.

 

1.2 Domain Values

Make sure that the following domains are defined.

Domain Name

Domain Values

domainName

Add the following domains:

• MatchingReason: Allows translating TAG24B Qualifier and Reason Code. Add a value for each combination of Qualifier/Reason Code, and enter the description in the Commend field. It will be displayed in the Message Report, column “Matching Reason Attribute”.
– Value = NMAT//CMIS, Comment = Matching Instruction Not Found
– Value = NMAT//DDAT, Comment = Settlement Date Rejection
– Value = NMAT//DDEA, Comment = Disagreement Deal Price
– Value = NMAT//DMON, Comment = Disagreement Settlement Amount
– Value = PEND//FUTU, Comment = Awaiting settlement date
– Value = PEND//LACK, Comment = Lack of Securities
– Value = PENF//BLOC, Comment = Account Blocked
– Value = PENF//DKNY, Comment = Counterparty returned shares
• ProductSelectorTypes.Repo: To use the “ISIN” criteria available in the Security Matching Window.
• flowTypeWriteOff: To determine the transfer type when applying a write off. If blank, the transfer type remains PRINCIPAL. This allows defining a specific workflow for write-off transfers.
• leAttribute.OPT_OUT_INDICATOR: List of values for OPT_OUT_INDICATOR legal entity attribute.
• leAttributeType.PARTIAL_INDICATOR: List of values for PARTIAL_INDICATOR legal entity attribute.
• keyword.CATradeBasis: Set the Comment as:

Comment=MultipleSelection of keyword value allowed. Trade was executed CUM or EX (MT540-43 :22F::TTCO//4!c)

• keyword.HoldRelease: List of values for trade keyword HoldRelease.
• keyword.PRIR: List of values for trade keyword PRIR.
• keyword.SETR: List of value for trade keyword SETR.
• messageExcludeTemplates
• messageExcludeAction
• TradeMessageRef: List of message attributes to be set as trade keywords by workflow rule SetTradeMessageRef.
• XferMessageRef: List of message attribute to be set as xfer attributes by workflow rule SetXferMessageRef.

flowType

Add the WRITE_OFF value.

flowTypeWriteOff

Add the WRITE_OFF value.

incomingType

Value = MT536, MT578, MT86, etc.

Comment = Incoming message type - The incoming message type is used to configure the incoming message workflow.

Examples:

Value = MT536 - Comment = INC_RECON

Value = MT537 - Comment = INC_RECON

Value = MT548 - Comment = INCOMING

Value = MT578 -Comment = INC_SETTALLEGE

Value = MT586 - Comment = INC_SETTALLEGE

keyword.CATradeBasis

Add the following values:

• CCPN: Trade was executed cum coupon
• XCPN: Trade was executed ex coupon
• CWAR: Trade was executed cum warrants
• XWAR: Trade was executed ex warrants
keyword.HoldRelease

Add the following values:

• YPRE: Set Comment=Release
• NPRE: Set Comment=Hold
keyword.PRIR

Add the following values for the priority indicator:

• 0001
• 0002
• 0003
• 0004
keyword.SETR

Add the following value:

• BYIY

leAttribute.OPT_OUT_INDICATOR

Add the following value:

• NOMC: No market claims should be automatically created.

leAttributeType.PARTIAL_INDICATOR

Add the following values:

• PART: Partial Settlement is allowed.
• NPAR: No Partial settlement allowed.
• PARC: Partial Settlement Cash Threshold allowed.
• PARQ: Partial Settlement Quantity Threshold allowed.
messageExcludeAction

Add the following values:

• CHG_DETAIL
messageExcludeTemplates

Add the following values:

• MT530
• sese.030.001

messageType

Add the values INCOMING and INC_SETTALLEGE corresponding to the incoming messages.

MsgAttributes

Add the following values.

For all messages:

• Cash Amount: Cash amount
• Nominal Amount: Quantity of security
• Ccy: Currency in which the cash amount is expressed
• Security Code: ISIN of the security
• PORef: Content of tag 20C::RELA//xxxx
• Reference: Content of tag 20C::RELA//xxxx without the extension -yyy
• AgentRef: Content of tag 20C::SEME//xxxx
• Place Of Settlement: Content of tag 95a::PSET
• Cntp Agent: Content of tag 95a::DEAG (REAG)
• CounterParty: Content of tag 95a::BUYR (SELL)
• PO Account: Safe Keeping account of the Processing Org
• CertificateNumber
• UTI_Ref: UTI reference
• RemainingSettlementQty (for MT54X): Content of tag 36B::RSTT//
• TotalSettledQty (for MT54X: Content of tag 36B::PSTT// or 36B::ESTT//
• RemainingSettlementAmount (MT545 and MT547 only): RemainingSettlementAmount from split transfer – content of tag 19A
• TotalSettledAmount (MT545 and MT547 only): TotalSettledAmount from split transfer + content of tag 19A

For MT548 and MT537:

• Matching_Date: Content of tag 98C::MTCH// (MT548 only)
• Matching_Status: Content of tag 25D::MTCH/xxxx
• Message_Function: Content of tag 23G
• Matching_Reason: Content of tag 24D
• RejectReason: Content of tag 70D
• MatchingComment: User-defined comment for manual matching
• PREP_Date: Contains the preparation date
• Settlement_Reason
• Settlement_Status
• UnreleasedQuantity: Content of tag 36B::/PREL
• CTPY_MITI: Content of tag 20C::/CMIT
• Penalty_Amount_Ccy: currency of tag :19A::AMCO
• AggregatedGlobalAmountCcy: currency of tag :19A::GBNT
• BilateralNetAmountCcy: currency of tag :19A::AGNT

For MT548:

• Acknowledged_Date: Content of ASTS field
• Matching_Date: Content of MTCH field
• Processing_Status: Content of field :25D::IPRC//PPRC
• TRRF_Reference – Tag 20C::TRRF//
• MITI_Reference – Tag 20C::MITI//
• CMIT_Reference – Tag 20C::CMIT//
• TCTR_Reference – Tag 20C::TCTR//
• CLTR_Reference – Tag 20C::CLTR//
• CLCI_Reference – Tag 20C::CLCI//
• TRCI_Reference – Tag 20C:://TRCI

For MT537:

• FailingDays
• Frequency_Indicator
• PenaltyAmount
• PenaltyDate
• PenaltyPayDate
• PenaltyTradeId
• PeriodFrom
• PeriodTo
• PreparationDate
• PreviousPCOM
• PreviousPREF
• ProcessingDate
• PenaltyRef
• PenaltyComRef
• Quantity Type (tag 36B)
• Nominal Amount (tag 36B)
• Payment Currency (tag 19A)
• Payment Amount (tag 19A)
• Payment Date (tag 98A)
• CSD_Counterparty (tag 95P CASD)
• CSD_Depository (tag 95P DCSD
• CMPU (tag 17B, Yes or No)

ProductSelectorTypes.Repo

Add any Product Type that could be involved in the Security Matching process like Bond, BondConvertible, ADR, Equity, etc.

PropagateLEAttribute

Add the following values:

• OPT_OUT_INDICATOR
• PARTIAL_INDICATOR
PropagateTradeKeyword

Add the following values:

• HoldRelease
• PRIR
• BenefCodeReason
• BenefName
• PARTIAL_INDICATOR
• SETR
• STCO

SWIFT.Templates

Add the following values:

• MT544
• MT545
• MT530
tradeKeyword

Add the following values:

• UTI_Ref
• SETR - When trade keyword SETR = BYIY, it is propagated to the field :22F:SETR// on the outgoing messages
• FX Ccy to get - Currency of Tag 11A::FXIS ot 11A:FXIB
•  

For MT537:

• AggregatedAmount
• BilateralNetAmount
• PenaltyRef
• PenaltyComRef
• PreviousPREF
• PreviousPCOM
• PenaltyType
• FailingDays
• PenaltyDate

XferAttributes

Add the following values:

• Reference: Content of tag 20C::RELA//xxxx
• MessageId: Id of the incoming message the transfer is indexed with. Can contain several values (in case you receive first a MT548 then a MT54X)
• MATCHING_REF: Id of the related outgoing message or transfer. The value of this transfer attribute must match Tag 20C (Related Reference) of the incoming MT548 or MT54X to allow Calypso to index the message with the related transfer
• Settlement_Reason
• Settlement_Status
• OPT_OUT_INDICATOR
• PARTIAL_INDICATOR
• HoldRelease
• PRIR
• HoldReleaseOverride
• PRIROverride
• PARTIAL_INDICATOROverride
• CATradeBasis
• BenefCodeReason
• BenefName
• SETR
• STCO
• UTI_Ref

For MT537:

• Common_Reference
• T2S_Ref
• PCTI_Reference
• PORef
• ClientRef
• FailedDate
• PenaltyRef
• PenaltyComRef
• Penalty_Reason
• Penalty_Status
• PenaltyTradeId
• PenaltyTradeId2
• PenaltyAmount
• PenaltyAmount2

XferAttributes.CHG_DETAIL.Editable

Add the following values (list of fields that can be edited by the action CHG_DETAIL):

• HoldRelease
• HoldReleaseOverride
• PRIR
• PRIROverride
• PARTIAL_INDICATOR
• PARTIAL_INDICATOROverride

Buy-In Process:

• BuyIn_Indicator
• Deferral_Indicator
• CashCompensation
• BuyIn_Price
XferAttributesForMatching

Add the following value:

• CATradeBasis
XferMessageRef
• CertificateNumber

For MT537:

• ClientRef
• FailedDate
• Penalty_Reason
• Penalty_Status
• PenaltyAmount
• PenaltyAmount2
• PenaltyComRef
• PenaltyRef
• PenaltyType

 

1.3 Bond Definition

You can set the security code UNIT_SWIFT_FORMAT to true to express tag 36B in quantity (UNIT format). It is expressed in nominal amount (FAMT format) otherwise.

 

Overwritten existing solutions and and manipulate the quantity type. For example, if a bond (1 ISIN) has a quote type UnitaryPrice, then tag 36B::SETT of the MT54X messages will be populated with UNIT. But if the depository is expecting to receive the information in FAMT, then the following will be done:

Add the LE attribute [ProductFamily]/[ProductType].[SubType].QuantityType on the PSET (Place of Settlement) with below possible values:

• UNIT to populate tag :36B::SETT//UNIT
• FAMT to populate tag :36B::SETT//FAMT

To populate the value on the tag, check bonds characteristics as following:

• ProductType.SubType

If available, then populate.

If not available, then check ProductType

– If available, then populate.
– If not available, then check ProductFamily

If available, then populate.

If not available, then apply default (Priority n°3)

 

Priorities order:

• LE Attribute [ProductFamily]/[ProductType].[SubType].QuantityType
• Security Code
• Bond Quote Type (default)

 

Example :

Bond.Bonos.QuantityType = UNIT è [ProductType].[SubType].QuantityType

BondAssetBack.QuantityType =FAMT è [ProductType].QuantityType

Bond.QuantityType = FAMT è [ProductFamily].QuantityType

 

NB: Product Family <> Product Group

 

1.4 Message Workflow

Static Data Filters

MT548PENA: Message template = MT548 and MSGAttributes.Message_Function = PENA.

 

INCOMING Workflow

Make sure that the following message workflow rules are available:

• SetXferMessageRef - If the incoming message has a TransferId not null (the message has been indexed to a Calypso transfer), this rule applies the action UPDATE by default on the indexed transfer and sets the attributes of the incoming message (defined in domain "XferMessageRef") in the transfer attributes. It also sets in the attribute MessageId of the indexed transfer the incoming message id. This attribute can contain several MessageIds in case the transfer is indexed first with a MT548 and then with a MT54X.

You can set the action to be applied in the rule parameter.

Note: If the incoming message has a TransferId equals to 0 (the message has not been indexed to a Calypso transfer), the message remains in its original status (PENDING according to our suggestion below) because the rule blocks it.

If the value of a message attribute is empty, in a subsequent message, the corresponding transfer attribute is removed from the transfer even if it contains a value. you can use the domain “XferMessageRefKeep” to define the list of transfer attributes to keep even if the message attribute is empty on the incoming message.

• UnSetXferMessageRef - This rule is executed when the user hits the UNDO button of the Security Matching Window. This rule applies the UNDO action (or action specified in comment) to the indexed transfer and removes the content of the transfer attributes defined in the domain “UnSetXferMessageRef”. If the transfer was indexed to a MT548 and to a MT54X, applying the UNDO on the MT54X incoming message just removes its related id from the list of MessageIds stored on the transfer but keep the MessageId of the MT548 already matched).

Note: If the MessageId contained only one MessageId and if the UNDO is applied on this given message, the system removes it from the MessageId attribute but also removes the content of the Reference attribute as it is not longer indexed to any incoming message.

• SetTradeMessageRef: When field :20U::TRRF// is set in the incoming message, it populates the new message attribute “UTI_Ref”. The workflow rule SetTradeMessageRef must be set on action UPDATE to set trade keywords on the trade for the message attributes defined in domain "TradeMessageRef".

The content of the trade keyword "UTI_Ref", when not null, is propagated to field :20U::TRRF// of the outgoing messages.

• MatchIncomingSecurity - This rule applies to the indexed transfer. The action applied to the transfer depends on the type of incoming message. For MT548/MT537 (or any message defined in domain "NonSettlementMessage"), the action applied depends on the Incoming Status Config you have defined. If the domain "NonSettlementMessage" is empty, and the incoming message type is defined in the domain "IncomingSecurityAdvice", the rule MatchIncomingSecurity handles the incoming message as a non settlement message, and the action depends on the Incoming Status Config.

For MT536 and MT544-MT547, the system applies the action SETTLE or PARTIAL_SETTLE (if environment property CHECK_QUANTITY_FOR_SECURITY_MATCHING is set to false and if the settled quantity is less than the quantity of the transfer).

For MT540-MT543, the system applies the action SPLIT.

Note: If the incoming message has the flag MatchB equals to false (at least one of the matching criteria is not respected), the message remains in its original status because the rule blocks it.

• MatchIncomingSecurityAdvice - This rule sets string tag25D with message attribute “ATTR_MATCHING_STATUS” if the incoming message has tag25D starting with MTCH, or “ATTR_SETTLEMENT_STATUS” if the incoming message has tag25D starting with SETT.

This rule handles "sese" messages defined in the domain "IncomingSecurityAdvice".

When integrating a MT548 message, this rule moves the associated trade to the status defined in the Mapping Status Config if any.

• PropagateFX2Xfer - This rule propagates FX message attributes to the transfer when RESU and EXCH are provided on the incoming MT545 and MT547, in the case where the actual settlement currency is different from the transfer currency. It should be set on the MATCH action. It must be used in conjunction with the transfer rules GenerateFXSettlement and ResetFXSettlement. See below for details.
• ReleaseMsgPendingCancelConf - This rule holds generation of the new swift instruction message until the confirmation of the MT54x Cancel request is executed, in case of security transfer amendment.
• CreatePenaltyTrade - This rule creates a Simple Transfer trade of type PENALTY using the data of the MT548/MT537, links the message to the Simple Transfer and applies the action UPDATE on the indexed transfer to store the Trade ID of the penalty trade in transfer attribute PenaltyTradeId.

By default, the settle date of the penalty trade is created using the date rule (17th business day of the month for example) specified in the Agent legal entity attribute "PenaltySettleDate".

Example:

A penalty trade is created for each daily MT537 message with Tag 22H::PNTP//SEPF (matched trade with failed settlement), and for a MT537 message with Tag 22H::PNTP//LMFP (matched trade that is not settled by the settlement date).

The domain “CreatePenaltyMsgAttribute” is used by the workflow rule CreatePenaltyTrade to store selected message attributes from the MT537 as trade keywords on the penalty trade.

The domain “CreatePenaltyTradeKeyword” is used by the workflow rule CreatePenaltyTrade to propagate selected trade keywords from the original trade to the penalty trade.

 

The trade date of the penalty trade is set based on Agent attribute PenaltyTradeDateSEFP. It can be set to DACO (default) or PEDA.

IF :22H::PNTP = SEFP:

• If PenaltyTradeDateSEFP <> PEDA:

Use date in tag 98A::DACO (message attribute ComputationDate) to set the Trade Date of the Penalty Trade. DACO not being mandatory, if not available continue using the Todate from STAT and preparation date as currently done

• If PenaltyTradeDateSEFP = PEDA:

Use date in tag 98A::PEDA (message attribute PenaltyDate) to set the Trade Date of the Penalty Trade. If PEDA not available, use DACO and if DACO not available, use preparation date as currently done

IF :22H::PNTP <> SEFP (message attribute ComputationDate) that means equal to LMFP Late Matching fail penalty:

Use date in tag 98A::DACO to set the Trade Date of the Penalty Trade if available, or field 69:STAT otherwise

 

Message attribute PenaltyPayDate is set with date in field 98A with qualifier PAYD (:98A::PAYD or :98C::PAYD) in sequence D1 (16R:PENACUR).

If option C, then just keep the date and disregard the time.

 

The workflow rule CreatePenaltyTrade can also handle lifecycle of penalty trades based on Penalty Status and Reason from incoming MT537 in Block PENDET, Tag 25D::PNST (penalty status) and Tag 24B:: (penalty reason).

• No penalty status – New penalty trade is created
• Penalty status = :25D::PNST//ACTV – If penalty trade does not already exist, create a new one, otherwise update the existing penalty trade
• Penalty status = :25D::PNST//REMO – Cancel existing penalty trade
• Penalty status = :25D::PNST//SWIC or RLOC:
– If penalty reason = ACTV/UPDT – Create new trade or update existing trade
– If penalty reason = REMO – Cancel existing penalty trade
– If penalty reason = NCOM – No action
• Penalty status = :25D::PNST//REIC – Create new trade or update existing trade
• Penalty status = :25D::PNST//NCOM or OTHR – CreatePenaltyTrade is not applied and an exception is raised – To avoid this, you can set a dedicated transition based on message attribute Penalty_Status, without the rule CreatePenaltyTrade, to send such messages to a specific status for review.

 

To link incoming Monthly MT537 with penalty type = SEPF to the Penalty Trades created with daily MT537, you can use the following rules:

• SetMT537MonthlyAmount - To copy the following message attributes from the Monthly MT537 message:
– Penalty_Amount to trade keyword MonthlyConfirmedAmount
– AggregatedGlobalAmount to trade keyword AggregatedGlobalAmount
– BilateralNetAmount to trade keyword BilateralNetAmount
– PenaltyPayDate to trade keyword PenaltyPayDate
– PeriodFrom to trade keyword PeriodFrom
– PeriodTo to trade keyword PeriodTo
– Penalty_Amount_Ccy to trade keyword MonthlyConfirmedAmountCcY
– AggregatedGlobalAmountCcy to trade keyword AggregatedGlobalAmountCcy
– BilateralNetAmountCcy to trade keyword BilateralNetAmountCcy

The trade is saved using the UPDATE action.

The Penalty Trade Settlement Date may be modified based on environment property ReferenceDateForPenalty. It can be set to PeriodTo, PayDate or not set (default).

– If ReferenceDateForPenalty = Not set - The Settlement Date is not modified.
– If ReferenceDateForPenalty = PayDate AND Linked Penalty Trade Settlement Date <> from date in message attribute PenaltyPayDate:

Store Penalty Trade Settlement Date in tradekeyword OriginalPenaltySettleDate

Update Settlement Date to match date in message attribute PenaltyPayDate

– If ReferenceDateForPenalty = PayDate AND Linked Penalty Trade Settlement Date = from date in message attribute PenaltyPayDate:

The Settlement Date is not modified.

– If ReferenceDateForPenalty = PeriodTo AND Linked Penalty Trade Trade Date <> from date in message attribute PeriodTo:

Store Penalty Trade Settlement Date in tradekeyword OriginalPenaltySettleDate

Update Settlement Date by getting the Next Date returned by PenaltySettleDate date rule when applied to date in message attribute PeriodTo.

Note: PenaltySettleDate date rule is stored in Agent attribute "PenaltySettleDate".

– If ReferenceDateForPenalty = PeriodTo AND Linked Penalty Trade Trade Date = from date in message attribute PeriodTo

The Settlement Date is not modified.

• ReprocessMT537Monthly – To tentatively link the sub-messages of a Monthly MT537 of type SEFP, to the Simple Transfer trades of type PENALTY with PenaltyRef = PREF tag and PenaltyComRef = PCOM tag (created from daily MT537 messages).

If PenaltyRef is available, then look for Penalty trade where: Message Attribute PenaltyRef = Trade Keyword PenaltyRef and Message Attribute PenaltyComRef = TradeKeyword PenaltyComRef.

If PenaltyRef is not available, then look for Penalty trade where: Message Attribute PenaltyComRef = Trade Keyword PenaltyComRef.

 

We suggest the following INCOMING message workflow (subtype = INCOMING):

Orig Status

Action

Resulting Status

STP

Rules

Task

Filter

NONE

NEW

PEND MTCH UPDATE

F

 

T

MT548

NONE

NEW

PEND SETT UPDATE

F

 

T

MT544-MT547

NONE

NEW

PENDING

F

  

T

MT548PENA

PEND MTCH UPDATE

CANCEL

CANCELED

F

 

F

 

PEND MTCH UPDATE

MATCH

VER MTCH UPDATE

T

SetXferMessageRef,SetTradeMessageRef

T

MT548_MTCH

PEND MTCH UPDATE

MATCH

VER MTCH-SETT

T

SetXferMessageRef,SetTradeMessageRef

T

MT548_MTCH-SETT

PEND MTCH UPDATE

MATCH

VER SETT UPDATE

T

SetXferMessageRef,SetTradeMessageRef

T

MT548_SETT

PEND MTCH UPDATE

REJECT

REJECTED

F

 

T

 

PEND SETT UPDATE

CANCEL

CANCELED

F

 

F

 

PEND SETT UPDATE

MATCH

VER SETT UPDATE

T

SetXferMessageRef,SetTradeMessageRef

T

 

PEND SETT UPDATE

REJECT

REJECTED

F

 

T

 

PENDING

INDEX

INDEXED

 T SetXferMessageRef,SetTradeMessageRef T  

INDEXED

PROCESS

PROCESSED

 T CreatePenaltyTrade T  

PROCESSED

CANCEL

CANCELED

F

 

F

 

PROCESSED

UNDO

PEND MTCH UPDATE

F

UnSetXferMessageRef

Comment = UPDATE

F

MT548

PROCESSED

UNDO

PEND SETT UPDATE

F

UnSetXferMessageRef

Comment = UPDATE

T

MT544-MT547

VER MTCH UPDATE

CANCEL

CANCELED

F

 

F

 

VER MTCH UPDATE

MATCH

PROCESSED

T

MatchIncomingSecurityAdvice

T

 

VER MTCH-SETT

CANCEL

CANCELED

F

 

F

 

VER MTCH-SETT

MATCH

PROCESSED

T

MatchIncomingSecurity

MatchIncomingSecurityAdvice

T

 

VER SETT UPDATE

CANCEL

CANCELED

F

 

F

 

VER SETT UPDATE

MATCH

PROCESSED

T

MatchIncomingSecurity

PropagateFX2Xfer

T

 

The static data filters can be defined based on the Message Template and the Message Status attributes.

 

INC_SETTALLEGE Workflow

This workflow is specified for the subtype INC_SETTALLEGE for incoming messages MT578 and MT586.

Orig Status

Action

Resulting Status

STP

Rules

Filter

ALLEGED

CANCEL

CANCELED

F

 

 

ALLEGED

MATCH

MATCHED

T

 

Msg Function Not NEWM

ALLEGED

REMOVE

REMOVED

F

 

 

INVESTIGATE

CANCEL

CANCELED

F

 

 

INVESTIGATE

PROCESS

ALLEGED

T

MatchIncomingSecurityAdvice

 

NONE

NEW

INVESTIGATE

F

 

 

 

INC_RECON Workflow

We suggest the following INC_RECON message workflow (subtype = INC_RECON):

Orig Status

Action

Resulting Status

STP

Rules

Task

Filter

NONE

NEW

PENDING

 T

 

  

 

PENDING

INDEX

INDEXED

 T

SetXferMessage

 

DailyFrequency

PENDING MATCH MATCHED T

SetMT537MonthlyAmount

 

MonthlyFrequency

PENDING REPROCESS PENDING F ReprocessMT537Monthly   MonthlyFrequency
PENDING CANCEL CANCELED F

 

  

 

INDEXED

PROCESS

PROCESSED

 T

CreatePenaltyTrade

 

DailyFrequency

INDEXED CANCEL CANCELED F     DailyFrequency
PROCESSED CANCEL CANCELED F      
PROCESSED UNDO TO BE REPROCESSED F UnSetXferMessageRef

Comment = UPDATE

   DailyFrequency
TO BE REPROCESSED MATCH PENDING F      

 

1.5 Transfer Workflow

On the VERIFIED-SETTLE-SETTLED transition, add the rule ResetXferMessageStatus.

ResetXferMessageStatus: This rule resets the following attributes when the transfer is settled: Matching_Status, Matching_Reason and RejectReason.

To handle pre-settlements, add a transfer workflow transition ADD_PRE-SETT_LINK to link incoming messages to transfers via the rule MatchIncomingSecurity without changing the transfer’s status.

Also, make sure the actions AUTO_SETTLE and AUTO_FAIL are defined on the transfer workflow.

Define the following static data filters:

 

Orig Status

Action

Resulting Status

STP

Rules

Task

SD Filter

PENDING

AUTHORIZE

VERIFIED

T

CheckNetting

PropagateLEAttribute

PropagateTradeKeyword

   

PENDING

EXECUTE

VERIFIED

  

SetKnownFlag

PropagateLEAttribute

PropagateTradeKeyword

   

VERIFIED

ADD_PRE-SETT_LINK

VERIFIED

F

 

T

 

VERIFIED

AUTO_FAIL

FAILED

T

CheckToBeFailed

T

Xfer not WRITE_OFF

VERIFIED

AUTO_SETTLE

SETTLED

T

CheckToBeSettled

F

Xfer not WRITE_OFF

VERIFIED

AUTO_WRITEOFF

SETTLED

T

 

F

Xfer WRITE_OFF

VERIFIED

FAIL

FAILED

F

 

T

 

VERIFIED

PARTIAL_SETTLE

SPLIT

F

 

F

 

VERIFIED

SETTLE

SETTLED

F

 ResetXferMessageStatus

F

 

VERIFIED

SPLIT

SPLIT

F

 

F

 

VERIFIED

UNSPLIT

CANCELED

F

 

F

 

FAILED

CANCEL_MSG

FAILED

F

 

T

 

 

Incoming Settlement Currency different from Outgoing Transfer Currency

When RESU and EXCH are provided on the incoming MT545/MT547 messages, it indicates that the incoming settlement currency is different from the outgoing settlement currency.

You can use the following setup to match the incoming and outgoing payment messages, and settle the outgoing messages with the proper amount.

Message rule: PropagateFX2Xfer – To be set in INCOMING workflow on MATCH action to propagate the following message attributes to the transfer:

• FX Resulting Amount
• FX Resulting Ccy
• FX Resulting Pair
• FX Resulting Type
• FX Resulting Quote

The transfer rule GenerateFXSettlement should be set on the SETTLE and PARTIAL_SETTLE actions. It updates the original transfer with FX Resulting Type = Original Settlement, and generates a transfer to offset the original transfer and a transfer with the actual settlement information from the FX attributes.

The transfer rule ResetFXSettlement should be set on the AUTHORIZE action to reset the FX attributes.

 

1.6 Incoming Status Config

From the Calypso Navigator, navigate to Configuration > Messages & Matching > Incoming Status to define the action to be applied to the transfer / trade matched with the incoming message.

This configuration applies to the incoming messages of type INCOMING.

For handling pre-settlement, you also need the following mapping:

» Enter the fields described below and click Add.
» Then click Save to save your changes.

 

Fields Details

Fields

Description

Incoming Msg Type

Click ... to select the type of message for which you want to define a mapping status config.

You can double-click the label to add new message types.

Incoming Status

Select the value to map with the incoming message tag 25D + 24B.

You can click ... to define all the possible combinations. Use the “-“ to separate the content of tag 25D with the content of tag 24B.

Incoming SD Filter

Click ... to select a static data filter to filter the incoming messages.

You can double-click the label to define static data filters.

Workflow

Click ... to select the workflow transition to be applied to the transfer matched with the incoming message that satisfies the fields Incoming Msg Type, Incoming Status and Incoming SD Filter.

You will be prompted to select a Processing Org (can be ALL), an event class (PSEventTransfer for a transfer or PSEventTrade for a trade), a Subtype (can be ALL), a Product (can be ALL), and a transition:

Description

Enter the comment that will be displayed on the task created when the selected workflow transition is applied.

 Ⓘ   [NOTE: The selected workflow transition should have "Create Task" checked]

 

When the system applies the MatchIncomingSecurity, it combines the content of tag 25D and tag 24B if any, separated with a "-". It then looks for a Mapping Status Config where the incoming status matches the combined string.

If the system does not find any eligible Mapping Status Config, the incoming message remains in its original status, and sets the comment of the corresponding message task to "No possible action on transfer".

If the system finds an eligible Mapping Status Config, it applies the action of the corresponding transition to the transfer matched with the incoming message, and populates the comment with the user-defined description.

 

When integrating a MT548 message, the MatchIncomingSecurityAdvice message workflow rule moves the associated trade to the status defined in the Mapping Status Config if any.

 

1.7 Matching Context

From the Calypso Navigator, navigate to Configuration > Messages & Matching > Matching (menu action "refdata.MatchingContextConfigurationWindow") to bring up the Matching Context window.

This configuration applies to the incoming messages of type INC_SETTALLEGE (MT578 and MT586 messages). They can be matched with security settlement messages.

Incoming message will be in status ALLEGED and should potentially be matched with non-sent security messages.

See Matching Context for details.

 

2. Generation of MT540, MT541, MT542, MT543 for Security Margin Calls and Simple Transfers

The following tags are specific to Security Margin Calls and Simple Transfers provided the proper trade keywords are populated.

There is an additional tag 22F::STCO = TRIP when product type = MarginCall or SimpleTransfer, and trade keyword Pledged_Collateral = True.

 

Tag 22F::STRE contains:

• COLO if product type = MarginCall or SimpleTransfer, and trade keyword bookingType = “Delivery to CP” OR “Return to PO”
• COLI if product type = MarginCall or SimpleTransfer, and trade keyword bookingType = “Delivery to PO” OR “Return to CP”

 

Tag 22F::COLA = value of trade keyword CollateralExposureType if product type = MarginCall or SimpleTransfer.

 

2.1 MT54X messages by Market / Custodian

The following changes have been made on MT54X messages to cover custodians’ specificities:

 

Field 22F STCO is populated with PART only for some markets in T2S scope.

• If Priority n°1 new SDI attribute to be developed on LE with PO role:

Name: PARTIAL_INDICATOR.ALLOWED

Value: SD Filter instead of open field

 

Priorities order:

• PO SDIs attribute PARTIAL_INDICATOR.ALLOWED (New solution)
• PARTIAL_INDICATOR defined on transfer (Existing solution)

 

NB: It is recommended to use SDIs attribute OR Trade keyword solution and NOT both at the same time.

 

Example:

• SDI attribute PARTIAL_INDICATOR.ALLOWED = SD filter TRUE -> :22F::STCO//PART
• SDI attribute PARTIAL_INDICATOR.ALLOWED = SD filter AND PARTIAL_INDICATOR = NPAR -> :22F::STCO//NPAR

 

Field 22F STAM is added only for the Irish Market.

• If Priority n°1 new SDI attribute to be developed on LE with CPTY role:

Name: STAM

Value: (Optional)/Code

• If Priority n°2 new SDI attribute to be developed on LE with PO role:

Name: STAM

Value: (Optional)/Code

 

Priorities order:

• CPTY SDIs attribute (New solution)
• PO SDIs attribute (New solution)
• Trade Keyword (Existing solution)

 

NB: It is recommended to use SDIs attribute OR Trade keyword solution and NOT both at the same time.

 

Example:

• SDI attribute STAM = CRST -> :22F::STAM//CRST

 

Field 94B TRAD is populated with TRAD//OTCO/XHKG for the Hong Kong Market.

• If Priority n°1 new SDI attribute to be developed on LE with PO role:

Name: Place

Value: (Optional)/Code/Narrative

 

Priorities order:

• PO SDIs attribute
• Trade Keyword

 

NB: It is recommended to use SDIs attribute OR Trade keyword solution and NOT both at the same time.

 

Example:

• SDI attribute = OTCO/XHKG -> :94B::TRAD//OTCO/XHKG

 

3. Incoming Messages Import

Incoming messages are imported using the MESSAGE_MATCHING scheduled task.

When using the scheduled task, please put in the Swift File attribute the name of the swift file to integrate and in the InputDir the path to access this file as shown below:

The system indexes the incoming message using TAG 20C (Related Reference) which can be the outgoing message id or the Transfer Attribute MATCHING_REF when there is no outgoing message.

When an extension -01 or -02 is the Related Reference suffix, we skip it to index using the message id or transfer attribute without that suffix.

When there is no message id, transfer id or transfer attribute MATCHING_REF which matches TAG 20C of MT548 or MT54X then the INCOMING message is saved but blocked in a status PENDING (depending on your INCOMING message workflow).

If TAG 20C::RELA does not match, incoming MT5x messages can be linked to MT548 messages based on the references listed in domain “SecuritiesIncomingReferences”, in the order in which they are listed.

The following references can be used: SEME, TRRF, COMM, MITI, PCTI, CMIT, TCTR, CLTR, CLCI, TRCI.

So if the domain contains MITI, CMIT and CLCI, the system will try to match the incoming message with the MITI reference. If it does not match, it will try the CMIT reference and if it does not match, it will try the CLCI reference.

The matching process is described below.

 

3.1 Automatic Matching

The Message Matching process consists in verifying if the outgoing message or related MATCHING_REF transfer attribute is valid in the system.

If a matched message (MatchingB flag is true on the INCOMING message) or transfer is found, then the system applies the MatchIncomingSecurity message workflow rule.

For all incoming messages, if there is a cash difference, the process will depend on the environment property PARTIAL_CASH_FOR_SECURITY_MATCHING.

If false, the transfer is settled, regardless of the cash amount. The cash amount of the incoming message is set on the transfer.

If true, the transfer is split. The security transfer is settled and the cash transfer is failed. If WRITE_OFF_FOR_SECURITY_MATCHING is true, and the cash difference is within the Automatic settlement tolerance, the failed transfer becomes a settled WRITE_OFF transfer.

 

MT536, MT537, MT548

We check if we can apply the actions MATCH or UNMATCHED based on the TAG 25D (Status) MATCH or NMAT. Additional checks are done on:

 

Function

(INST for new message / CAST for cancel message).

If the Message Function of the incoming message is different from the function of the outgoing message, we do not MATCH messages; the flag MatchB is set to false. This means that the incoming message will have to be treated via the Security Matching Window.

For an incoming message bearing a function CAST, we match the outgoing message (CANC) with the incoming message and apply the MATCH action on the incoming message when the related outgoing message (CANC) is found and Quantity Type, Quantity, Security Code and function matches; no action is applied on the transfer which stays in CANCELED or REMOVED status.

 

Quantity

Whatever the value set to the environment property CHECK_QUANTITY_FOR_SECURITY_MATCHING, if the Quantity field of the incoming message is different than the Quantity of the outgoing Message (or related transfer with the attribute MATCHING_REF) then we save the incoming message but do not apply the MATCH action on this message nor on the related transfer; The flag MatchB is set to false. This means that the incoming message will have to be treated via the Security Matching Window.

If the Quantity field of the incoming message is equal to the Quantity of the outgoing message (or related transfer with the attribute MATCHING_REF) then we apply the MATCH action on the incoming message and the action MATCH or UNMATCHED on the related transfer based on the value MACH or NMAT of Tag 25D.

 

Type of Quantity

(FAMT is used for bond-related products by default unless the security code UNIT_SWIFT_FORMAT is set to true on the Bond Definition)

(UNIT is used for equity-related products by default)

If the Type of Quantity of the incoming message is different than the Type of Quantity of the incoming message, then we save the incoming message but do not apply the MATCH action on it nor on the related transfer; the flag MatchB is set to false. This means that the incoming message will have to be treated via the Security Matching Window.

 

Security Code

If the Tag35B starts by:

• ISIN - The ISIN security code is used for matching.
• /US/ - The CUSIP security code is used for matching.
• /GB/ - The SEDOL security code is used for matching.
• /HK/ - The HK security code is used for matching.

Otherwise, the code after the 4 first characters of Tag35B is matched against the Common security code.

So, if for example the code in the Incoming Message for Tag35B = /XS/123456789, it will be matched against the Common security code = 123456789.

If the incoming message cannot be matched against any code, then we save the incoming message but do not apply the MATCH action on it nor on the related transfer; the flag MatchB is set to false. This means that the incoming message will have to be treated via the Security Matching Window.

 

ISIN can split MT536 message by using environment property SPLIT_MT536 = true.

If set to true: The environment property will split the MT536 per transaction (i.e. one BO Message per transaction in MT536).

If set to false: It will create single BO Message (default behavior).

 

Attributes

If you add SecurityMatching to the domain “MessageAttributeCopier”, the following attributes are not copied to the cancellation message, if any: _Matching_Reason and _Matching_Status.

 

Proprietary Account

When the incoming MT536 or MT537 contains a proprietary account, it is split between each sub-account and reconciled using the Security Reconcile Window (menu item reporting.SecurityReconcileWindow).

You can select the ACOW reference. It allows displaying all the transfers where XferAttributes.ClientRef = ACOW and all the messages where MsgAttributes.ClientRef = ACOW.

 

When the MT537 message has not been indexed to a transfer, you can use the Security Reconcile window to Force Match the message (or multiple messages) to a transfer:

When clicking on Force Match, the Transfer Id is set on the Message Id in order to perform the indexation. During indexation, if the ACOW reference does not give the message id of the transfer, it checks if this reference matches the XferAttributes.ClientRef. If Data Source Scheme = IBRC and ACOW reference does not match XferAttributes.ClientRef, then it looks at MT537 field :20C::MITI// and see if it matches the transfer attribute T2S_Reference.

 

When integrating the MT537, the message field MATCHB is set to true if the message has been indexed to a transfer or false otherwise.

 

MT540, MT541, MT542, MT543

An incoming MT540-MT543 is received. Its reference (tag 20C::SEME) is stored in the Msg attribute AgentRef. The incoming MT540-MT543 can be matched through the Matching Manager with a Transfer.

Then, an Incoming MT544-M547 is received. Its tag 20C::RELA contains the reference SEME of the Incoming MT540-MT543. Therefore, the incoming MT544-MT547 can be automatically indexed to the incoming MT540-MT543 and the trade (the indexation is done thanks to the tag 20C:RELA of the MT544-MT547 compared to the AgentRef attribute of the MT540-MT543).

 

Tag 95P is added for Data Source Scheme = ECLR (Euroclear) and CEDE (Clearstream) - Participant Account owner - SWIFT address of the PO (for direct participant) or SWIFT address of PO custodian (for indirect participant).

 

When the MatchIncomingSecurity rule is doing a SPLIT, it sets the transfer attribute MatchIncomingSecurity = true. You can add the transfer rule CheckMatchWithMessageTemplate on the transition VERIFIED - AUTO_SETTLE - SETTLED that checks this attribute.

If it is true, and the rule param contains the incoming message template, the partial transfer moves to status SETTLED. If it is true and the rule param does not contain the incoming message template, the partial transfer moves to status VERIFIED.

If it is false or not set, the partial transfer moves to status SETTLED.

 

MT536, MT544, MT545, MT546, MT547

For MT536, MT544, 545, 546 and 547, we apply the action MATCH on the incoming message and PARTIAL_SETTLE (if CHECK_QUANTITY_FOR_SECURITY_MATCHING is set to false and the quantity of the incoming message is lower then the quantity of the outgoing message or of the transfer) or SETTLE actions on the related transfer based on Tag 23G (Function) and 36B (Quantity Type and Quantity).

When LOOK_PARENT_CONTACT = true, the receiver of the incoming message is set to the PO of the trade related to the outgoing message linked to the incoming message.

If there is no linked message or no trade is found, or LOOK_PARENT_CONTACT = false, the receiver is set to the first legal entity that matches the BIC code of the message.

 

Checks are done on:

 

Function

(NEWM for new message / CANC for cancel message).

If the Message Function of the incoming message is different from the function of the outgoing message, we do not MATCH messages; the flag MatchB is set to false. This means that the incoming message will have to be treated via the Security Matching Window.

For MT544, 545, 546 and 547 bearing a function CANC, we match the outgoing message (CANC) with the incoming message and apply the MATCH action on the incoming message when the related outgoing message (CANC) is found and Quantity Type, Security Code and function matches; no action is applied on the transfer which stays in CANCELED or REMOVED status.

 

Type of Quantity

Same behavior as MT548.

 

Security Code

Same behavior as MT548.

If one of these criteria do not match between outgoing (or related transfer) and incoming messages, then the incoming MT544, 545, 546 and 547 are saved but blocked in VERIFIED (action MATCH is not applied on the INCOMING message); as a consequence, the related transfer stays in its original status (e.g. VERIFIED).

 

Quantity

If the incoming message quantity is lower than the outgoing message quantity (or related transfer), and if CHECK_QUANTITY_FOR_SECURITY_MATCHING is set to false, we apply the PARTIAL_SETTLE action on the transfer (and MATCHED action on the incoming message). If the CHECK_QUANTITY_FOR_SECURITY_MATCHING is set to false we block the incoming message in VERIFIED status and the incoming message will have to be treated via the Security Matching Window.

When a PARTIAL_SETTLE action is applied on the related transfer, we CANCEL the initial transfer and create two new transfers (bearing the reference of the Parent Transfer).

By default, the new transfer corresponding to the part which is settled goes to SETTLED applying the AUTO_SETTLE action and CheckToBeSettled workflow rule.

The new transfer corresponding to the part of the transfer which is not settled goes to UNSETTLED (or similar status) applying the AUTO_FAIL action and CheckToBeFailed workflow rule.

By default, MT544-MT547 PAIN messages apply partial settlements and MT544-MT547 PARC messages only

apply partial settlements if the message quantity matches the remaining quantity. If environment property

PartialSettlementNoCheck = true, MT544-MT547 PARC messages apply partial settlements without checking of the

remaining quantity.

 

When the incoming message quantity matches the outgoing message quantity (or related transfer security quantity), the system applies the SETTLE action on the related transfer, it sets on the transfer the Real Settle Date displayed in the incoming message and the eventual Real Cash Amount settled. The incoming messages goes to MATCHED based on the INCOMING message workflow suggested.

 

Amount

When environment property CHANGE_CASH_SIGN_FOR_PARTIAL_SETTLE =true, the system bypasses the check that the cash amount of an incoming netted transfer cannot have an opposite sign from the outgoing transfer.

 

Propagating References to UNSETTLED/FAILED transfer

Upon partial settlement of MT54x messages, the following attributes are set on the resulting failed transfer:

• OriginalReference – Reference from original transfer
• OriginalUTI_Ref - UTI_Ref from original transfer
• OriginalCommon_Reference - Common_Reference from original transfer
• OriginalState_Ref - State_Ref from original transfer
• OriginalT2S_Ref - T2S_Ref from original transfer
• Original<attribute> - <attribute> from original transfer defined in domain “OriginalMT54xCancelReference”.

Example, if domain “OriginalMT54xCancelReference” contains Value = CustomRef, then attribute OriginalCustomRef is set to CustomRef of original transfer.

 

Cancel Message on UNSETLLED/FAILED transfer

You can generate a cancel message on the UNSETLLED/FAILED transfer by applying action CANCEL_MSG.

Such message should be configured with the template SecuritiesCancelation.selector so that the references that have been propagated to the UNSETLLED/FAILED transfer are set on the message.

 

If you are not using IBRC, you can set environment property IBRC_CHECK = false, to bypass the IBRC check to improve the performance of MT545 messages upload.

 

MT537 Penalty / MT548 Penalty

When integrating an MT537/MT548 with function of the message = PENA (:23G:PENA), an MT537/MT548PENA message is created which is indexed to the message id specified in the ACOW or RELA reference (:20C::RELA//MT541REF001), and a Simple Transfer penalty trade is created.

Tag 23 is saved in message attribute "Message_Function".

A cash penalty rate is applied based on the type of fail.

 

When MT548 sender legal entity attribute Data Source Scheme is defined in domain “CSDR_DataSourceScheme_ACOW”, MT548-PENA (22H::STST//PENA) messages are truncated per block :16R:PENDET (repetitive block) instead of block :16R:PENA and are indexed with block :16R:RELTRAN field :20C::ACOW// where the id set in this field is the same as the one displayed in same block field :20C::RELA//.

 

MT537 messages are indexed using the following algorithm:

The system first looks for a reference in ACOW or RELA in incoming MT537 and tries to match it to message attribute:

• PORef - If found, process ends and message is indexed (if Is External = False)
• AgentRef - If found, process ends and message is indexed (if Is External = True)

If not found:

• Look for Xfer with Xfer attribute T2Sref with same value as reference in tag MITI
• Look for Xfer with Xfer attribute Common_Reference with same value as as reference in tag COMM
• Look for Xfer with Xfer attribute Clientref with same value as as reference in tag ACOW

 

MT537

Daily frequency - Provides a daily penalty report that includes new and amended penalties, and daily bilateral net amounts per counterparty, currency, custodian.

Monthly (14th business day of the following month) - Provides monthly penalty report with monthly bilateral net amounts per counterparty, currency, custodian, and a list of the penalties of the month.

Monthly (15th business day of the following month) - Provides a report with net amounts per currency, custodian to be paid / received on the 17th on the month.

Monthly (17th business day of the following month) - Collects and re-distributes penalties as needed.

 

MT548 - CA Claim

The MT548 is indexed to the CA trade Claim using the MT548 field 20C::PREV// that is = to the message Id of the underlying transaction that is failed.

When receiving an MT548 with message function CLAI (:22F::SETR//), the system indexes the incoming message to a CA trade and/or transfer using the incoming field :20C::PREV as being the message_id of the original settlement instruction and the CA trade keyword CAFailedTransfer, as being the transfer Id creating the CA trade claim.

 

MT544-7 - CA Claim

The MT544-7 is indexed to the CA Claim transfer using the MT544-7 field 20C::PREV// that is = to the message Id of the underlying transaction that is failed.

When receiving an MT544-7 with message function CLAI (:22F::SETR//), the system indexes the incoming message to a CA trade and/or transfer using the incoming field :20C::PREV as being the message_id of the original settlement instruction and the CA trade keyword CAFailedTransfer, as being the transfer Id creating the CA trade claim.

The MT544-7, once indexed to the corresponding CA claim transfer, applies the action SETTLE on the transfer.

NO PARTIAL SETTLEMENT is allowed on CA market claims.

If several transfers are generated from a CA trade claim, then the system indexes the MT544-7 to the transfer where transfer amount = MT544-7 field 19A::ESTT.

 

3.2 Manual Matching

From the Calypso Navigator, navigate to Processing > Matching > Security Matching (menu action reporting.SecurityMatchingWindow) to perform manual matching.

» Enter search criteria as needed and click Load – The search criteria are described below.
» You can also click Default to load the default template.

You can define templates from the Configure menu.

» You can configure the color of the transfers / messages based on their status using the Color menu.
– Matched : Messages/transfers that are matched
– UnMatched : Messages/transfers that are not matched
– Processed : Messages/transfers that have been processed during the current session
– Included : Messages/transfers loaded from the “Include Transfers from Messages” or “Include Messages from Transfers”

 

Search Criteria

Fields

Description

Value Date

Start/End

Enter the Value Start Date and Value End Date as needed to load the transfers and messages.

Trade Date

Start/End

Enter the Trade Start Date and Trade End Date as needed to load the transfers and messages.

Trade Date From ...To

Same as “Value Date From.. To” but for Trade Date. No default value.

Custodian

Click ... to select a legal entity of role Agent.

Transfer Status

Click ... to select transfer status codes as needed.

Custodian BIC

Enter the BIC code.

You can also enter a few letters of the BIC code, and click ... to display the corresponding contacts. Then select a contact.
Message Status

Click ... to select message status codes as needed.

Swift Type

Click ... to select a swift message type as needed.

Filter Set

Select a filter set as needed to filter transfers.
Message Type

Click ... to select message types as needed.
Transfer Type

Click ... to select a transfer types as needed.

Quantity From/To

Enter a range of traded quantities as needed.

Currency

Click ... to select settlement currencies ad needed.

Nominal Amount From/To

Enter a range of traded nominal amounts as needed.

Swift Function

Click ... to select swift functions as needed.

Security Code

You can select a security code and its value to load the corresponding product.

The types of products that can be searched from this field can be set in the domain “ProductSelectorTypes.Repo".

Reference

You can select a reference and its value to load the corresponding message / transfer. If you select "Reference", you can load transfers / messages based on the RELA field.

For "Reference", if your Reference is 12345 you will be able to find the transfers/messages using “12345”, “123%”, “%345” or “%34%”.

Include Transfers from Messages

Check to load transfers/messages that satisfy the criteria,and their associated transfers.

Include Messages From Transfers

Check to load transfers/messages that satisfy the criteria, and their associated messages.

 

Functions

Once the messages and transfers are loaded, you can select a transfer and a message, and apply the following actions:

• Match - To match the selected transfer and the selected message - You will be prompted to enter a comment that will be stored in the message attribute MatchingComment.
• Force Match - To force matching of the selected transfer and the selected message in case they don't match.
• Undo - To undo a function previously applied to the selected transfer and the selected message.
• Reject - To reject an incoming message.

 

Matching Process

The Security Matching tool allows manually matching an incoming message that the system has not been able to match automatically with a Calypso transfer.

There can be several reasons why an incoming message has not been matched automatically. Depending on the type of matching criteria that is not respected, you will have different operations to do and will be able or not to match manually the incoming message with an outgoing message (or related transfer).

Below is the list of reasons why an incoming message would not be matched with a Calypso transfer.

 

Different or empty reference (TAG 20C RELA) (not blocking)

You have to investigate and find the eventual Calypso transfer that could match with this incoming message. If you find a Calypso transfer that has the same characteristics (except the reference), you will be able to match them. If one (or more) of the characteristic of the transfer the user has selected is different, you may face one the case described below.

 

Different Message Function, Security Code, Type of Quantity and/or Quantity (blocking)

You won’t be able to match an incoming message with a Calypso transfer if the Message Function, the Security Code, the Type of Quantity and/or the Quantity is/are different. If you try to match them, you will get an error message displaying the list of items that do not match.

If the Message Function, the Security code and/or the Type of Quantity does not match, you can just reject the incoming message. It is not possible to force the matching. If the Quantity is different, you will be able to match them depending on the case described below.

 

Different Quantity (can be blocking)

• Incoming Message Quantity lower than Calypso transfer Quantity (not blocking):

In this case, you can split the Calypso transfer you want to match with this incoming message. To do so, right click on the transfer and apply the action SPLIT. Input the Quantity and Cash Amount you want for each new transfer and apply. You will then be able to match the incoming message and the transfer coming from the split that has the right Quantity.

• Incoming Message Quantity higher than Calypso transfer Quantity (blocking):

In this case, you can just reject the incoming message as it is not possible to force the matching of an incoming message that as a Quantity higher than the Calypso transfer selected.

If the matching can manually be achieved (matching criteria respected but reference different or not existing), the impacts of the Match process are different on the Message and on the Transfer:

• On the Message - The system applies the action MATCH (whatever the status of the incoming message selected). If the incoming message was not indexed (no transfer id was set on it), the system sets in this field the transfer id of the Calypso transfer the incoming message is manually matched with.
• On the Transfer - The action applied depends on the type of incoming message (MT548 or MT54X) and depends on the incoming message function.
– Incoming Message MT548:

Only the Message Function INST is implemented. As a consequence, if the MT548 received has not the Message Function INST, the system won’t apply any action on the related transfer. The transfer will remain it is original status. You will have to apply manually the expected action. Future development could be planed once the particular case of CAST clearly defined (not which status the transfer is supposed to reach but which action has to be applied as only action are coded in Calypso core.)

If the MT548 received has the Message Function INST, the system will set the id of the message selected in the MessageId attribute and it will also store the Reference of the incoming message (TAG 20C RELA) in the Reference attribute. Depending on the content of the incoming message (especially TAG25G MTCH//MACH or MTCH//NMAT) the system will either apply the action MATCH or the action UNMATCH on the selected transfer.

– Incoming Message MT54X:

Only the Message Function NEWM is implemented. As a consequence, if the MT54X received has not the Message Function NEWM, the system won’t apply any action on the related transfer. The transfer will remain it is original status. You will have to apply manually the expected action. Future development could be planed once the particular case of CANC and RVSL clearly defined (not which status the transfer is supposed to reach but which action has to be applied as only action are coded in Calypso core.)

If the MT54X received has the Message Function INST, the system will set the id of the message selected in the MessageId attribute and it will also store the Reference of the incoming message (TAG 20C RELA) in the Reference attribute. Depending on the content of the incoming message (especially TAG 36B corresponding to the quantity defined) the system will either apply the action SETTLE on the related transfer (in case of full settlement) or it will require first a split of the related transfer (in case of partial settlement). Once the original transfer will be split, the user will be able to match the transfer corresponding to the settle quantity with the incoming message. The action SETTLE will be applied to this transfer. When the system applies the SETTLE action on the transfer, it updates the settle date and eventually the cash settlement amount of the transfer.

 

Cash Difference

If PARTIAL_CASH_FOR_SECURITY_MATCHING is true, and WRITE_OFF_FOR_SECURITY_MATCHING is true, and the cash difference is within the Manual settlement tolerance, the failed transfer becomes a settled WRITE_OFF transfer.

 

Undo Process

The impact of the Undo process is different on the transfer and on the message.

• On the Message - The system applies the action UNDO to the selected message. The workflow rule UnSetXferMessageRef is applied and as a consequence the content of the TransferId, TradeId and MatchingComment is emptied. This rule also sets the MatchB attribute to false and it changes the status of the incoming message to PENDING (according to the incoming message workflow suggested).
• On the Transfer - The UnSetXferReference also applies the action UNDO (or action specified in comment) on the indexed transfer. It removes the transfer attributes defined in the domain “UnSetXferMessageRef”. If there was only one id listed it the MessageId attribute, it also removes the content of the attribute Reference.

 

Reject Process

The Reject process can only be applied to an incoming message. It also only impacts the Message. It just applies the action REJECT to the incoming message selected.

 

3.3 Alleged Messages

The system only processes MT578/MT586 messages where the Function of the Message (Field :23G::) contains one of the following values:

• NEWM - New message.
• CANC - Cancellation Request - Message requesting the cancellation of a previous alleged message – Used when an account servicer wants to inform the account owner that the alleged settlement is canceled (by counterparty or account servicer), or a detail has changed.
• REMO – Removal - Message sent to acknowledge that a previously alleged message is no longer valid – Used when an alleged message is no longer outstanding (because the alleged party sent its instruction, i.e. the counterparty transaction has been matched).

 

New Messages (23G:: NEWM)

When an MT578 or an individual level MT586 Alleged Settlement message is received, Calypso will create a message of type INC_SETTALLEGE.

From the incoming message workflow this message will have a status of Alleged.

Calypso will not attempt to “match” the incoming alleged message to a Calypso object (Trade/Transfer or Outgoing Message) and therefore Calypso will not attach the Alleged message to a Calypso object.

The Alleged message will be displayable on the Message Report.

You can also run the Matching Manager to view possible matches. The Matching Manager requires the Matchable Builder engine, and the Matching engine to be running in order to create matchable items from incoming items and outgoing items, and to display possible matches.

See Matching Manager for details.

 

Canceled Messages (23G:: CANC)

When Calypso receives an incoming MT578/586 message with a Message Function of CANC Calypso will update the status of the previously received MT576/586 to Canceled.

 

Removed Messages (23G:: REMO)

When Calypso receives an incoming MT578/586 message with a Message Function of REMO Calypso will update the status of the previously received MT576/586 to Removed.

 

4. CSDR - Calculation of Penalties for Fails

You can setup the calculation of the following penalties:

• Settlement Fail Penalty (SEFP): Penalties for matched trades but failing to settle
• Late Matching Fail Penalty (LMFP): Penalties for matching after Intended Settlement Date

 

The scheduled task CSDR_PENALTY_ESTIMATION allows calculating the SEFP and LMFP penalties for security transfers with product code CSDR_Eligibility = Y and transfer attribute Matching_Status = MTCH//NMAT.

Example:

 

The penalty rate is based on product code CSDR_Penalty_Category and is defined in the domain “CSDRApplicableRates” as:

Value = CSDR_Penalty_Category or ISO currency

Comment = Penalty rate in bps or quote name of the Rate Index to be applied

The penalty rate is applied to the price on the valuation date: rate * price * quantity.

 

Examples:

Name = CSDRApplicableRates

Value = EUR

Comment = MM.EUR.EONIA.1D.EONIA

 

Name = CSDRApplicableRates

Value = Shares,liquid,non-SME

Comment = 1

 

The domain CSDRPenaltyDirection should contain the penalty direction based on transfer attribute Matching_Reason.

Examples:

Name = CSDRPenaltyDirection

Value = PENF//LACK_PAY

Comment = PAY

 

Name = CSDRPenaltyDirection

Value = PENF//LACK_RECEIVE

Comment = RECEIVE

 

The transfer workflow rule PropagateCSDREstimatedPenalties is used to propagate the transfer attributes to the penalty trades. It should be added on the following transitions:

VERIFIED - UPDATE_PENALTY - VERIFIED

FAILED - UPDATE_PENALTY - FAILED

 

The penalties are calculated by the CSDR_PENALTY_ESTIMATION scheduled task. The only task attribute is the transfer workflow action to be applied to the transfers. It should be the same action as the action previously configured with the workflow rule PropagateCSDREstimatedPenalties.

Example:

When multiple agents have the same BIC Code as Tag 95P:ASDP, the agent with Contact LE Role = Agent is selected.

 

The penalties are stored in the transfer attributes LMFP_EstimatedAmount, LMFP_EstimatedDate, SEFP_EstimatedAmount, SEFP_EstimatedAmount.

The transfer attribute Penalties_EstimatedAmount contains LMFP_EstimatedAmount + SEFP_EstimatedAmount.

Example:

 

5. MT530 Generation

 

5.1 Setup Requirements

 

Legal Entity Attributes

Set the attribute OPT_OUT_INDICATOR and PARTIAL_INDICATOR on the counterparty as needed.

 

Message Setup

The static data filter checks that the transfer action is CHG_DETAIL.

 

In the domain "XferAttributes.RemoveForSPLIT", you can specify which transfer attribute needs to be removed when performing a split. It should contain Reference. This is used to populate Tag 20C::PREV on the MT530 message with the message ID of the correct MT543 message which is linked to the Transfer on which the CHG_DETAIL action is applied.

 

5.2 Process

To generate an MT530 message, apply the action CHG_DETAIL to a transfer.

It brings up the Transfer Settlement Details Input window where the default values are set according the existing transfer attributes.

Any amendments are made using the respective Override attributes.

Editable attributes are defined in the domain "XferAttributes.CHG_DETAIL.Editable".

If no attributes are defined, all the fields are editable.

 

The MT530 message is generated.

The MT548 received following a change request indicates either the amendment has been accepted or rejected, using MT530 field :25D::TPRC//PACK (accepted) or REJT (rejected). The MT530 message will be accepted or rejected accordingly.

 

5.3 Buy-In Process

For the buy-in process, you first need to apply action CHG_DETAIL to a failed transfer and change Hold Release to NPRE. The corresponding MT530 message is generated.

Then apply the CHG_DETAIL action again when the buy-in process has been initiated, and specify the details of the buy-in:

The corresponding MT530 message is generated with the buy-in information.

 

On the buy-in trade, you need to set trade keyword SETR = BYIY so that it can be set on the generated MT541.

 

6. Swift MX Messages

You can use Swift MX messages instead of Swift MT messages.

 

6.1 Message Coverage

Swift MX Description Swift MT Function 23G

sese.020

Securities Transaction Cancellation Request (outgoing).

MT540 Receive Free

MT541 Receive Against Payment

MT542 Deliver Free

MT543 Deliver Against Payment

CANC

sese.023

Securities Settlement Transaction Instruction (outgoing).

MT540 Receive Free

MT541 Receive Against Payment

MT542 Deliver Free

MT543 Deliver Against Payment

NEWM

sese.021

Status Request on sese.023

 

 

sese.024

Securities Settlement Transaction Status Advice (incoming).

MT548 Settlement Status and Processing Advice

INST

sese.025

Securities Settlement Transaction Confirmation (incoming).

MT544 Receive Free Confirmation

MT545 Receive Against Payment Confirmation

MT546 Deliver Free confirmation

MT547 Deliver Against Payment confirmation

NEWM

sese.027

Securities Transaction Cancellation Request Status Advice (incoming).

MT548 Settlement Status and Processing Advice

CAST
sese.028

Alleged Settlement

New MT578

  
sese.029

Alleged Settlement

Removed MT578

  

sese.030

Securities Settlement Conditions Modification Request (outgoing).

MT530 Transaction Processing Command

  

sese.031

Securities Settlement Conditions Modification Status Advice (incoming).

MT548 Settlement Status and Processing Advice

  
sese.020

Alleged Settlement

Canceled MT578

  

semt.017

Securities Transaction Posting Report

MT536

 

semt.018

Securities Transaction Pending Report

MT537

 

semt.021

Statement Request for semt.017

Please refer to Calypso Messages documentation, Statement Requests.

MT549

 

 

6.2 Domain Values

The following messages need to be added to the domain "incomingType": INCOMING_SESE024, INCOMING_SESE025, INCOMING_SESE027, INCOMING_SESE031, SESE020, SESE028, SESE029, SEMT017, SEMT018.

The comment should be set to INCOMING except for the messages below.

For SESE020, SESE028 and SESE029, the comment should be set to INC_SETTALLEGE.

For SEMT017, the comment should be set to POS_RECON.

 

The domain "IncomingSecurityAdvice" defines the list of "sese" messages to be accepted by the rule MatchIncomingSecurityAdvice: sese.024, sese.025, sese.027, sese.031, sese.020, sese.028, sese.029.

 

The domain "MX.Templates" contains all Swift MX messages.

 

The domain "MX.Versions" contains all the Swift MX messages and their version number.

 

Domain "MessageExcludeTemplates" contains sese.030.001.

 

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 = SEMT017

Comment = MatchingSystem

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

 

6.3 sese.023.T2S

When trade keyword STCO = BPSS, /SctiesSttlmTxInstr/SttlmParams contains:

<SttlmTxCond>

<Cd>BPSS</Cd>

</SttlmTxCond>

 

6.4 sese.024.T2S

When counterparty attribute INTERNAL_SETTLEMENT = INTS, tag /SctiesSttlmTxStsAdvc/SttlmParams/ contains:

<SttlmTxCond>

<Cd>INTS</Cd>

</SttlmTxCond>

 

Message attribute Processing_Status based on the field /SctiesSttlmTxStsAdvc/PrcgSts/PdgPrcg with value IPRC//PPRC.

Message attribute Processing_Reason based on the field SctiesSttlmTxStsAdvc/PrcgSts/PdgPrcg/Rsn/Cd/Cd with value PPRC//PREA etc.

Message attribute Matching_Date based on the field SctiesSttlmTxStsAdvc/TxDtls/MtchdStsTmStmp.

Message attribute Acknowledged_Date based on the field /SctiesSttlmTxStsAdvc/TxDtls/AckdStsTmStmp.

 

Message attribute AdditionalReasonInformation based on /Document/SctiesSttlmTxStsAdvc/PrcgSts/Rjctd/Rsn/AddtlRsnInf

Message attribute AdditionalReasonInformation based on /Document/SctiesSttlmTxStsAdvc/PrcgSts/Canc/Rsn/AddtlRsnInf

 

6.5 semt.027

Message attribute AdditionalReasonInformation based on /Document/SctiesTxCxlReqStsAdvc/PrcgSts/Rjctd/Rsn/AddtlRsnInf

Message attribute AdditionalReasonInformation based on /Document/SctiesTxCxlReqStsAdvc/PrcgSts/Dnd/Rsn/AddtlRsnInf

 

6.6 semt.017

Message attributes:

• PeriodFrom
• PeriodTo
• Frequency_Indicator

 

You can use the Security Reconcile Window (menu item reporting.SecurityReconcileWindow) to reconcile incoming messages with outgoing messages (see above in MT536 integration for examples).

You can add more templates to the domain "SecReconWindowSwiftTypes" to have them available in the Security Reconciliation window as needed.

 

6.7 semt.018

Message attributes:

XML Tag

Path

Message Attribute
<SctiesTxPdgRpt> <SctiesTxPdgRpt> Message_Function
<StmtId> /Document/SctiesTxPdgRpt/StmtGnlDtls/StmtId AgentRef
<SfkpgAcct> /Document/SctiesTxPdgRpt/SfkpgAcct PO_Account
<AcctOwnrTxId> /Document/SctiesTxPdgRpt/Sts/Tx/AcctOwnrTxId Client_Ref
<SctiesTxTp> /Document/SctiesTxPdgRpt/Sts/Tx/TxDtls/SttlmTxOrCorpActnEvtTp/SctiesTxTp/Cd Trade_Type
<SctiesMvmntTp> /Document/SctiesTxPdgRpt/Sts/Tx/TxDtls/SctiesMvmntTp MvtType
<Pmt> /Document/SctiesTxPdgRpt/Sts/Tx/TxDtls/Pmt Money Amount
<FinInstrmId> /Document/SctiesTxPdgRpt/Sts/Tx/TxDtls/FinInstrmId/ISIN Security_Code
<PstngQty> /Document/SctiesTxPdgRpt/Sts/Tx/TxDtls/PstngQty/Qty Nominal
PstngAmt> /Document/SctiesTxPdgRpt/Sts/Tx/TxDtls/PstngAmt/Amt SettleAmount
<SttlmDt> /Document/SctiesTxPdgRpt/Sts/Tx/TxDtls/SttlmDt/Dt PreperationDate
<MtchgSts> /Document/SctiesTxPdgRpt/Txs/StsAndRsn/IfrrdMtchgSts/Umtchd Matching_Status
<SttlmSts> /Document/SctiesTxPdgRpt/Txs/StsAndRsn/SttlmSts/Pdg/Rsn/Cd/Cd Processing Status

 

6.8 Message Setup for Bonds

Define PO and Receiver as needed.

Address = SWIFT

Gateway = MX

Format = MX

Event Message Type Template Name Static Data Filter
VERIFIED_SEC_DELIVERY SEC_DELIVERY_MSG sese.030.001

 
VERIFIED_SEC_RECEIPT SEC_RECEIPT_MSG sese.030.001  

VERIFIED_SEC_RECEIPT

SESE_RECEIPT

 SecuritiesSettlementTransactionInstruction.selector

 

VERIFIED_SEC_DELIVERY

SESE_DELIVERY

 SecuritiesSettlementTransactionInstruction.selector

 

CANCELED_SEC_RECEIPT

SESE_RECEIPT

 SecuritiesSettlementTransactionInstruction.selector

 

CANCELED_SEC_DELIVERY

SESE_DELIVERY

 SecuritiesSettlementTransactionInstruction.selector

 

SECURITY_TRANSACTION_STATUS

ALL

sese.021.001

 

 

For T2S messages, you need to use the templates:

• SecuritiesSettlementTransactionInstructionT2S.selector with the static data filter "ApplyXferAction"

ApplyXferAction - Static Data Filter IN "XferAction<>CHG_DETAIL" and "XferAction<>UPDATE_MATCHING"

XferAction<>CHG_DETAIL - Transfer Action NOT IN CHG_DETAIL

XferAction<>UPDATE_MATCHING - Transfer Action NOT IN UPDATE_MATCHING

• sese.030.001.T2S with the static data filter "XferAction=CHG_DETAIL".

XferAction=CHG_DETAIL - Transfer Action IN CHG_DETAIL

 

The gateway formats the envelop of the message to comply with DataPDU or Swift Alliance Lite (https://www2.swift.com/uhbonline/books/public/en_uk/al_2_2_autoc_inst_user_guide_20111118/b93.htm). The value is MX for standard and SAA for both DataPDU and Swift Alliance Lite.

 

6.9 Incoming Message Workflow - Subtype = INCOMING

Orig Status Action Resulting Status STP Rules Task Static Data Filter

ALLEGED

 CANCEL CANCELED F

 

T

 
ALLEGED MATCH PROCESSED T

 

T

 MT578-NOT NEWM
ALLEGED REMOVE

CANCELED

F

 

T

 
INVESTIGATE CANCEL

CANCELED

F

 

T

 
INVESTIGATE PROCESSED ALLEGED T MatchIncomingSecurityAdvice

T

 
NONE NEW PENDING

F

 

 F

 
PEND SETT UPDATE CANCEL

CANCELED

F

 

 F

 
PEND SETT UPDATE MATCH VER SETT UPDATE T SetXferMessageRef T

 
PEND SETT UPDATE REJECT REJECTED

F

 

T

 
PEND STAT UPDATE CANCEL CANCELED

F

 

F

 
PEND STAT UPDATE MATCH PROCESSED T MatchIncomingSecurityAdvice

F

 MT548_IPRC_TRPC
PEND STAT UPDATE

MATCH

 VER SETT UPDATE

T

 SetXferMessageRef

F

 MT548_SETT
PEND STAT UPDATE

MATCH

 VER STAT UPDATE

T

 SetXferMessageRef

T

 MT548_MTCH
PEND STAT UPDATE REJECT REJECTED

F

 

T

 
PENDING CANCEL CANCELED

F

 

F

 
PENDING PROCESS INVESTIGATE T

 

F

 MT578,586
PENDING

PROCESS

 PEND SETT UPDATE

T

 

T

 MT544-7,SESE025

PENDING

PROCESS

 PEND STAT UPDATE

T

 

T

MT537,MT548,SESE024,

SESE027,SESE031
PROCESSED CANCEL CANCELED F

 

F

 

PROCESSED

 UNDO PEND SETT UPDATE

F

 UnSetXferMessageRef

T

 MT544-7,SESE025
VER SETT UPDATE CANCEL CANCELED

F

 

F

 

VER SETT UPDATE

 MATCH PROCESSED

T

 MatchIncomingSecurity

T

 
VER SETT/STAT CANCEL CANCELED

F

  

F

 
VER SETT/STAT MATCH PROCESSED

T

MatchIncomingSecurity,
MatchIncomingSecurityAdvice

T

 
VER STAT UPDATE CANCEL CANCELED

F

  

F

 
VER STAT UPDATE MATCH PROCESSED T MatchIncomingSecurityAdvice

T

 

 

Where the following static data filters need to be defined:

• MT544-7,SESE025

• MT537,MT548,SESE024,SESE027,SESE031

• MT548_IPRC_TRPC

 

Incoming sese.023 Messages

The following message attributes are populated:

Del Type - DeliveryType=//Document/SctiesSttlmTxInstr/SttlmTpAndAddtlParams/Pmt/text()

MvtType - MvtType=//Document/SctiesSttlmTxInstr/SttlmTpAndAddtlParams/SctiesMvmntTp/text()

TradeDate - TradeDate=//Document/SctiesSttlmTxInstr/TradDtls/TradDt/Dt/Dt/text()

SettleDate - SettleDate=//Document/SctiesSttlmTxInstr/TradDtls/SttlmDt/Dt/Dt/text()

Security Code - ISIN=//Document/SctiesSttlmTxInstr/FinInstrmId/ISIN/text()

Nominal - Quantity=//Document/SctiesSttlmTxInstr/QtyAndAcctDtls/SttlmQty/Qty/Unit/text()|//Document/SctiesSttlmTxInstr/QtyAndAcctDtls/SttlmQty/Qty/FaceAmt/text()

Cntp Agent - DelAgent=//Document/SctiesSttlmTxInstr/DlvrgSttlmPties/Pty1/Id/AnyBIC/text()|//Document/SctiesSttlmTxInstr/DlvrgSttlmPties/Pty1/Id/NmAndAdr/Nm/text()|//Document/SctiesSttlmTxInstr/DlvrgSttlmPties/Pty1/Id/PrtryId/Id/text()

Cntp Agent - RecAgent=//Document/SctiesSttlmTxInstr/RcvgSttlmPties/Pty1/Id/AnyBIC/text()|//Document/SctiesSttlmTxInstr/RcvgSttlmPties/Pty1/Id/NmAndAdr/Nm/text()|//Document/SctiesSttlmTxInstr/RcvgSttlmPties/Pty1/Id/PrtryId/Id/text()

Cash Amount - SettleAmount=//Document/SctiesSttlmTxInstr/SttlmAmt/Amt/text()

Ccy - SettleCurrency=//Document/SctiesSttlmTxInstr/SttlmAmt/Amt/@Ccy

Other Security Code - OtherID = /Document/SctiesSttlmTxInstr/FinInstrmId/OthrId/Id/text()

 

6.10 Incoming Message Workflow - Subtype = INC_SETTALLEGE

sese.029 (REMOVE) / sese.020 (CANCEL) are linked to the original sese.028 (NEW) message via the unique identifier TxId. The system creates a linkage between the BO messages by storing the BO message id of sese.028 in the Msg Linked Id of the related sese.029 and sese.020 messages.

The workflow rule MatchIncomingSecurityAdvice also supports sese allegement messages:

• In case of incoming sese.029, the workflow rule will apply action REMOVE on linked message sese.028. and message sese.029 will go straight to status MATCHED. If the action is not available, the workflow rule will return false and throw an exception. The message sese.029 will remain in status INVESTIGATE. If the linked message is not available, the workflow rule will return false and throw an exception. The message sese.029 will be stuck in previous status INVESTIGATE
• In case of incoming sese.020, the workflow rule will apply action CANCEL on linked message sese.028. and message sese.020 will go straight to status MATCHED. If the action is not available, the workflow rule will return false and throw an exception. The message sese.020 will remain in status INVESTIGATE. If the linked message is not available, the workflow rule will return false and throw an exception. The message sese.020 will be stuck in previous status INVESTIGATE

 

Note that the set up below is just a suggestion and that the configuration can be adjusted as needed.

 

MatchIncomingSecurityAdvice workflow rule on INVESTIGATE – PROCESS – ALLEGED transition:

 

SD Filter on ALLEGED – MATCH – MATCHED transition:

 

6.11 Incoming Message Workflow - Subtype = POS_RECON

Orig Status Action Resulting Status STP Rules Task Static Data Filter
NONE NEW UNPROCESSED

F

 

 F

 
UNPROCESSED

PROCESS

 PROCESSED

T

 

T

  

 

6.12 Payment Message Workflow

On the PENDING - AUTHORIZE - TO_BE_SENT transition, add the workflow rule SetXferMsgRef to set the transfer attribute Reference on the associated security transfer.

This rule sets the xfer attribute Reference = Message Id on the security transfer associated with the payment message.

Used for sese.023 integration / sese.021 generation.

 

6.13 Allegement Messages Matching

The incoming Allegement Message sese.028 can be matched against the outgoing sese.023 (SecuritiesSettlementTransactionInstruction.selector) based on the matching context tracking config.

The value SESE028 needs to be added to the domain "ExternalMessageField.MessageMapper".

 

Sample Tracking Matching Context

 

6.14 Scheduled Task MESSAGE_MATCHING

Specific MX attributes

• Swift Message delimiter = </Env:RequestPayload>
• External Message Type = MX

 

6.15 Example

Trade captured with the following trade keywords (T2S additional fields).

 

Message sese.023.001 is generated:

 

Message sese.024.001 is integrated leading the message to PROCESSED and the referenced instruction to MATCHED:

 

Releasing the Preadvice mode by applying the transfer action CHG_DETAIL triggers a message sese.030.001:

 

Finally, integrating the settlement confirmation sese.025.001 moves the transfer to SETTLE.

 

6.16 Generating a sese.021 Message

In order to generate a sese.021 message, the message engine needs to subscribe to PSEventGenericOnObject events.

 

From the Transfer report, right-click a security transfer and choose Process > Security Transaction Status to generate a sese.021 message.

The sese.021 message gets generated with AccntOwnrTxId = sese.023 Message Id which is picked from xfer attribute Reference.

Example:

 

7. Iberclear Swift Messages

 

7.1 Proprietary Accounts and Sub-Accounts

A proprietary account is a SETTLE account of SubType Security, defined with "Is Proprietary" checked, and the account attribute XferAgentAccount that contains the account at Iberclear.

A sub-account of a proprietary account is defined with the Proprietary Account and a Sub-Account Type. Sub-account types can be defined in the domain "SubAccountType".

The trades are directly impacting the sub-accounts and not the proprietary account but the settlement return messages contain the proprietary account.

 

The account attribute IsDefault must be set to true for the sub-accounts with sub-account type = AWAS. In this case, the BALANCE FROM and TO format does not display the Data Source Scheme.

Example: It displays :93A::FROM//AWAS instead of :93A::FROM/IBRC/AWAS.

 

7.2 Integrating Settlement Restrictions

This section describes the settlement restriction process: Generation of MT524, and integration of MT508 and MT538.

The outgoing MT524 message is sent by PO or account owner to its account servicing institution (or custodian) to instruct the movement of securities within the PO holdings (Nostro sub-accounts).

This message must not be used to move securities out of or into a safekeeping account. It instructs only movements that affect the status/availability of the security, that is, movements from one sub-balance to another or intra-position transfers, within a safekeeping account.

The incoming MT508 message is sent by the account servicing institution (or custodian) to an account owner or PO to confirm the increase or decrease in securities with a given status within a holding, that is, intra-position transfer.

The incoming MT524 is creating Transfer Agent trades between two sub-accounts.

The incoming MT538 message allows reconciling settlement restrictions. One message is sent per proprietary account. It is split between each sub-account and reconciled using the Security Reconcile Window.

 

Setup Requirements

LifeCycle engine: You need to add TransferAgent to the domain "LifeCycleEntityType", and to launch the LifeCycle engine. This applies the same action on the second transfer of the TransfertAgent trade.

 

Message configurations for MT524 messages.

You can use a static data filter that filters trades based on the Trade element "Is Same Proprietary".

 

Integration by sub-account is triggered if the sender LE attribute "UseSubBalance" is set to true.

 

Generating MT524 Messages

The MT524 is sent when transferring securities from one sub-account to another sub-account within the same proprietary account using Transfer Agent trades when the "Msg" checkbox is checked.

Sub-accounts are defined with a proprietary account and a type.

 

Integrating MT508 Intra-Position Advices

The incoming MT508 is used to confirm participants the execution of a movement between balances of the same securities proprietary account.

 

Add MT508 to the domain "incomingType". The Comment should contain the incoming message type.

 

INCOMING Message Workflow

• NONE – New – PENDING
• PENDING – PROCESS – INVESTIGATE, Use Stp = true, SDFilter = MT508, rule = SetXferMessageRef
• INVESTIGATE – MATCH – PROCESSED, Use Stp = true, rule = MatchIncomingSecurity

 

MatchIncomingSecurity - This rule applies to the indexed transfer. The action applied to the transfer depends on the type of incoming message. For MT508, the system applies the action SETTLE or PARTIAL_SETTLE (if environment property CHECK_QUANTITY_FOR_SECURITY_MATCHING is set to false and if the quantity settled is lower that the quantity of the transfer).

SetXferMessageRef - This rule applies the action UPDATE on the indexed transfer and sets the attributes of the incoming message in the transfer attributes. It also sets in the attribute MessageId of the indexed transfer the incoming message id.

 

MT508 messages are integrated using the scheduled task MESAGE_MATCHING.

The system indexes the MT508 to the previously sent MT524 using the linked reference and updates the corresponding transfer accordingly.

The following transfer attributes are saved on the transfer:

When integrating the message MT508, need to record as incoming msg and xfer attributes the following:

• ReconciledAmount = Amount field :36B::PSTT//FAM/
• FailedAmount = Amount field :36B::RSTT//FAM/
• AgentRef = MT508 reference field :20C::SEME/
• PORef = Reference = MT524 linked reference field :20C::RELA/
• T2S_Ref = MT508 T2S reference field :20C::MITI/
• PCTI_Reference = MT508 Iberclear reference field :20C::PCTI/
• Format Issue = Format issue when integrating the message
• PO Account = Proprietary account deducted from field 97::SAFE/ and account attribute XferAgentAccount

In case environment property LOOK_PARENT_CONTACT = true, if the PO of the incoming message with proper BIC Code is a parent PO, then we look at accounts associated with children PO for which XferAgentAccount = Tag 97 of incoming message to set the proper PO.

• Security Code = ISIN field :35B::ISIN/
• NominalAmount = Amount field :36B::ESTT//FAM/

 

Integrating MT524 Messages

Add MT524 to the domain "incomingType". The Comment should contain the incoming message type.

The integration of MT524 (using INCOMING message workflow) creates a Transfer Agent trade where:

• Cpty = PO defined in the Safekeeping account of the message MT524 (field 97B:: SAFE/IBRC/CEND/) where the reference is mapped with the Proprietary Account property XferAgentAccount
• Book = book defined in the PO attribute LE.DEFAULT_BOOK
• Trade Date = MT524 field 98C:PREP date/time
• Settle Date = MT524 field 98A:SETT date
• Transfer Type = SECURITY
• Security/ISIN = Security/ISIN defined in the MT524 field 35B::ISIN
• Quantity = MT524 field 36B::SETT/FAMT/trade quantity
• Nominal = deducted from quantity using the bond set up face value
• From = SDI that is linked to the nostro account defined by the sub-account type in field :93A::FROMIBRC/
• To = SDI that is linked to the nostro account defined by the sub-account type in field :93A::TOBAIBRC/

 

Trade keywords:

• State_Ref
• Common_Reference
• T2S_Ref
• PCTI_Reference
• PORef
• IncomingTrade = true

 

Integrating MT538 Messages

The incoming MT538 message allows reconciling settlement restrictions. One message is sent per proprietary account. It is split between each sub-account and reconciled using the Security Reconcile Window.

The following reconciliation keys are used:

• Transaction Settlement date :98A::SETT//
• Identification of the proprietary account :97A::SAFE//IBRC/CEND/XferAgentAccount property
• ISIN :35B::ISIN
• Quantity of securities :36B::ESTT//FAMT/100
• Transaction reference :20C::PCTI//

 

You can reconcile the messages using the Security Reconcile Window (menu action reporting.SecurityReconcileWindow).

 

7.3 MT54X Specific Format for Iberclear

The following fields are specific to Iberclear - They are populated if PO agent legal entity attribute Data Source Scheme = IBRC and if Iberclear is the place of settlement.

 

Sequence A – Tag 98C – Processing Date/Time - MESSAGE_CREATIONDATE Format yyyyMMDDHHMMSS.

 

Sequence C – Tag 95P – Participant Account owner - SWIFT address of the PO (for direct participant) or SWIFT address of PO custodian (for indirect participant).

 

Sequence C – Tag 97B – Safekeeping Account - PO agent account number.

 

Sequence E – Tag 22F – Sub-account type.

 

Sequence B – Tag 25D – Value of trade keyword Matching_Status - Add Matching_Status to domains "tradeKeyword" and "PropagateTradeKeyword", and set workflow rule PropagateTradeKeyword in transfer workflow.

 

Sequence F – Other Party Central Counterparty

The following fields are only populated if the trade keyword CCP contains the SWIFT address of a CCP configured in the domain “MEFFCLEAR.BIC”.

• Sequence E - Settlement Details - :22F::CCPT//YCCP
• Optional Repetitive Sequence F - Other Parties

Field :95P::TRAG// (Triparty Agent) = SWIFT address code of the central counterparty being involved in the operation = Trade keyword CCP

Field :95P::BRKR// (Broker) = BIC code of the PO used in the SDI

Field :97A::SAFE// (account where the security is maintained) = Account set in the PO legal entity attribute MeffclearAccount.

 

Sequence E – Tag 22F - Settlement Details Bilateral Transaction

Values for :22F::SETR/:

• ProductType=Repo / Subtype = Repo, Value = //SBBK
• ProductType=Repo / Subtype = Reverse Repo, Value = //BSBK
• ProductType=TransferAgent, Value = //OWNI
• ProductType=Repo / Subtype=BuySellBack, Value = //BSBK
• ProductType=Repo / Subtype=SellBuyBack, Value = //SBBK
• ProductType=Bond, Value = /IBRC/OTCS
• ProductType=SecLending / Direction=both / Loan Type = Fee Unsecured, Value = //OWNE
• ProductType=SecLending / Direction=Lending / Loan Type <> Fee Unsecured, Value = //SECL
• ProductType=SecLending / Direction=Borrowing / Loan Type <> Fee Unsecured, Value = //SECB

If the SDI attribute "FinancialIntermediary" is set, then Value = OAUX.

 

Added an LE attribute in CSD format on the PO Agent.

If the LE attribute CSD format is set to:

• TRUE, then check Data Source Scheme of the PSET and generate MT54X messages with CSD specific format.
• FALSE, then continue with the process as it is (check if Receiver=PSET) to generate MT54X messages with CSD specificities.

 

7.4 MT530 Specific Format for Iberclear

Block A – Tag 98C – Processing Date/Time - MESSAGE_CREATIONDATE Format yyyyMMDDHHMMSS.

 

Bock A – Tag 95P – Participant Account owner - SWIFT address of the PO (for direct participant) or SWIFT address of PO custodian (for indirect participant).

 

Block A– Tag 97B – Safekeeping Account - PO agent account number.

 

Block B - Tag 20C –References

The following fields are stored as transfer attributes when integrating MT548 messages using the transfer workflow rule "SetXferMessageRef":

• State_Ref
• Common_Reference
• T2S_Ref
• PCTI_Reference
• PORef

 

Add the domain "XferMessageRef" to list all the message attributes that need to be set as transfer attributes for the workflow rule SetXferMessageRef.

• Matching_Status
• Matching_Reason
• Settlement_Status
• Settlement_Reason
• RejectReason
• PREP_Date
• PORef
• AgentRef
• PCTI_Reference
• T2S_Ref
• State_Ref
• Common_Reference
• FailedAmount
• ReconciledAmount

 

7.5 Auto-Collateralization

This section describes the auto-collateralization on stock. The on-stock procedure is triggered intraday when the DCA account linked to the securities account for collateral supply lacks funds to settle sufficiently a transaction.

When the auto-collateralization process is triggered, Iberclear will send intraday the following messages.

 

Integration of MT543 to Create Repo Intraday

Integration of MT543 where Sequence E - Settlement Details field :22F::SETR//COLO triggers the creation of a repo trade.

Security Matcher: The messages (MT543, MT547, MT541, MT548, and MT545) related to auto-collateralization are identified based on the following information:

• Sequence E - Settlement Details field :22F::SETR//COLO
• Sequence A – Linkage field :20C::PCTI// reference same per instruction and its related messages.
• Sequence E - Settlement Parties field receiving (REAG) account :97B::SAFE/IBRC/CEND/ account property ‘Auto-Collateralization’ set to true.

 

Repo trade is created with:

• Repo Type = Standard
• Direction = Repo
• Book = LE attribute.DEFAULT_BOOK_COLLATERAL of the receiver of the SWIFT (PO)
• Mirror Book = LE attribute.MIRROR_BOOK_COLLATERAL of the receiver of the SWIFT (PO)
• Counterparty = Short name of the receiver of the SWIFT with role = PO
• Trade Date = Start Date = Field :98A::TRAD//8!n
• End Date = Field :98A::SETT//8!n
• Sec. Code = Field :35B:ISIN
• Sec. Quantity = Field :36B ::SETT//FAMT/15d
• Sec. Value + Sec. Currency = Field :19A::SETT//[N]3!a15d where the 3 characters corresponds to the currency.
• Cash Frequency = ZC
• Cash Fixed Rate = 0.000

Legal entity attributes:

DEFAULT_BOOK

MIRROR_BOOK

 

The following trade keywords are set:

• TradeType = Iberclear Auto-Collateralization
• ReceivingAccount = Account name of the sub-account AWAS where Proprietary account is populated in field :97B::SAFE/IBRC/CEND/ReceivingAccount under :95P::REAG section
• ProvidingAccount = Account name of the sub-account where Proprietary account is populated in field :97B::SAFE/IBRC/CEND/ProvidingAccount under :95P::DEAG section and where the sub-account type is populated under field :22F::SSBT/IBRC/EEUR => PO Account
• PCTI_Reference = Field :20C::PCTI// of the incoming MT543 Sequence A.
• SettlementDetails = field :22F::SETR//COLO
• PORef = Field :20C::SEME// of the incoming MT543.
• Matching_Status = Field :25D::MTCH//MACH of the incoming MT543.

The trade keyword PCTI_Reference must be added to the domain “PropagateTradeKeyword” in order to create a transfer attribute PCTI on the transfers.

 

The mirrored trade has the following trade keywords:

• TradeType = Iberclear Auto-Collateralization
• ReceivingAccount = Account Name of the sub-account AWAS where Proprietary account is populated in field :97B::SAFE/IBRC/CEND/ReceivingAccount under :95P::REAG section
• ProvidingAccount = Account name of the sub-account where Proprietary account is populated in field :97B::SAFE/IBRC/CEND/ProvidingAccount under :95P::DEAG section and where the sub-account type is populated under field :22F::SSBT/IBRC/ => PO account
• SettlementDetails = field :22F::SETR//COLO
• Matching_Status = Field :25D::MTCH//MACH of the incoming MT543.

 

Integration of MT547 to Settle Transfer

Security matcher: Index MT547 – SETTR//COLO with the repo start leg transfer using the following matching criteria:

• MT547 field :20C::PCTI// = Transfer attribute PCTI_Reference
• Event type = SEC_DELIVERY

The system applies the action SETTLE or PARTIAL_SETTLE on the linked/related transfer.

 

Integration of MT541 to Index to the far leg Transfer

Indexing the incoming message MT541-PREA to the far leg of the repo using the Event type = SEC_RECEIPT where:

• Sequence E - Settlement Details field :22F::SETR//COLO:
• Trade keyword TradeType = Iberclear Auto-Collateralization and
• Sequence E - Settlement Details field :22F::SETR//COLO = transfer attribute SettlementDetails
• :97B::SAFE/IBRC/CEND/IBRCBBVAESMMXXX000000001P0EX = trade keyword ProvidingAccount.
• Field :35B:ISIN = Trade ISIN
• Field :98A::SETT// = Trade End date
• Field :98A::TRAD// = Trade Start Date

 

When there are several candidate transfers (same day, same ISIN, same amount), the MT541 is linked to the first transfer found that is not yet linked to any MT541 (as per xfer attributes).

 

The transfer is updated with the following attributes using SetXferMessageRef rule:

• PORef = Field :20C::SEME// of the incoming MT541.
• Matching_Status = Field :25D::MTCH//MACH of the incoming MT541
• HoldRelease = NPRE (Holding the settlement linked to the MT541-PREA)
• PCTI_Reference = incoming message field :20C::PCTI//

 

Generation of MT530 to Release Payment

Using action CHG_DETAIL, change the value of HoldRelease attribute from YPRE to NPRE leading to the generation of the MT530.

Add the following values to domain "XferAttributes":

• LinkAction
• LinkQualifier
• LinkQualifierOverride
• LinkReference
• LinkReferenceOverride

Add the following values to domain "XferAttributes.CHG_DETAIL.Editable":

• LinkQualifierOverride
• LinkReferenceOverride

Tag :20C::PCTI// is populated with transfer attribute PCTI_Reference and :20C::PREV// with transfer attribute PORef only when trade keyword TradeType = Iberclear Auto-Collateralization is populated. If not, the standard MT530 template is used.

 

Integration of MT548 - SETR//COLO Confirming Change

Security matcher: Index MT548– SETTR//COLO with the repo transfer using the following matching criteria:

• MT548 field :20C::PCTI// = Transfer attribute PCTI_Reference
• Event type = SEC_DELIVERY

 

Update the linked transfer with the attributes listed in the linkage information from the incoming MT548 as transfer attributes:

• State_Ref
• Common_Reference
• T2S_Ref
• PCTI_Reference
• PORef

 

Integration of MT545 - SETR//COLO to Settle the Transfer

Security matcher: Index MT545 – SETTR//COLO with the repo end leg transfer using the following matching criteria:

• MT545 field :20C::PCTI// = Transfer attribute PCTI_Reference
• Event type = SEC_RECEIPT

The system applies the action SETTLE or PARTIAL_SETTLE on the linked/related transfer.

 

7.6 Blocking Securities

You can capture Transfer Agent trades to block positions on "blocking accounts" (using sub-account type AWAS). This generates MT542 and MT540 messages.

You need to set the following trade keywords on the trades:

• "Matching_Status" = MTCH//MACH
• "BenefCodeReason"
• "BenefName"
• "PARTIAL_INDICATOR"
• "SETR"
• "STCO"

Example:

 

Unblocking Process

You can apply the workflow transfer action UNBLOCK on the transfers previously created. It needs the transfer workflow rule CreateOppositeXferAgentTrade which:

• Creates a new Transfer Agent trade, opposite if the trade linked to the transfer to which the action is applied
• Propagates the transfer attributes to the new trade
• Sets the trade keyword AutomaticTrade = True

 

7.7 Pledging Securities

You can capture Transfer Agent trades to pledge positions. This generates MT542 and MT540 messages.

You need to set the following trade keywords on the trades:

"Matching_Status" = MTCH//MACH

"BenefCodeReason"

"BenefName"

"SETR" = IBRC/CUPG to mention this is the pledging process

"PARTIAL_INDICATOR" = NPAR

"STCO"

Example:

Add BenefCodeReason, BenefName, PARTIAL_INDICATOR, SETR, STCO to domain "PropagateTradeKeyword".

 

Unpledging Process

You can apply the workflow transfer action UNBLOCK on the transfers previously created. It needs the transfer workflow rule CreateOppositeXferAgentTrade which:

• Creates a new Transfer Agent trade, opposite if the trade linked to the transfer to which the action is applied
• Propagates the transfer attributes to the new trade
• Sets the trade keyword AutomaticTrade = Yes

 

7.8 Settling Penalty Trades

The flag MatchB is now set to true for incoming MT545/MT547 messages linked to penalty transfers.

This allows the workflow rule MatchIncomingSecurity to support transfers of type PENALTY.

• If message amount > transfer amount – No action.
• If message amount = transfer amount - Action SETTLE is applied to the penalty transfer
• If message amount < transfer amount - Action PARTIAL_SETTLE is applied to the penalty transfer

 

Note that this only applies if the Netting Type of the netted transfer containing penalty transfers has the netting key TransferType.

 

8. Clearstream Specificity

If Agent of the PO has Legal Entity attribute Data Source Scheme = CEDE, and Place of Settlement (PSET) is equal to agent of the PO (Cleastream), and Trade Type = “Repo”, and Repo Type = “Standard”:

Tag 22F::SETR// of block SETDET is set to “TRAD”.

 

9. Euroclear Specificity

If Agent of the PO has Legal Entity attribute Data Source Scheme = ECLR, and Place of Settlement (PSET) is equal to agent of the PO (Euroclear), and Trade Type = “Repo”, and Repo Type = “Standard”:

Tag 22F::SETR// of block SETDET is set to “TRAD”.

 

10. Repos

You should use the templates MT54XREPO for repo messages.

 

Default Behavior

22F:SETR is set to REPU for all Security Settlement Messages (MT541/3) when:

Trade Product = Repo

AND Direction = Repo

AND Repo Type not equal to Triparty, Buysellback nor Pledge

 

22F:SETR is set to RVPO for all Security Settlement Messages (MT541/3) when:

Trade Product = Repo

AND Direction = Reverse

AND Repo Type not equal to Triparty, Buysellback nor Pledge

 

BuySide Behavior

You need to add the following transfer attributes: EventTypeActionName and Returned_Collateral_Id.

 

If you set SDI Attribute RepoSettleIndicator = Alternative on the Processing Org.

Tag 22F:SETR is set as follows:

 

If you set SDI Attribute RepoLinkedMessages = true on the Processing Org.

On a collateral return, if transfer attribute Returned_Collateral_Id is set, Tag 20C::PREV// is set to the message ID of the original collateral payment message.

 

11. VP Securities Swift Messages

 

The following fields are specific to VP Securities - They are populated when PO agent legal entity attribute Data Source Scheme = VPDK and SDI attribute T2S = true on the counterparty SDI.

 

25D::MTCH//MACH - The trade keyword Matching_Status must be set to MTCH//MACH and added to domains PropagateTradeKeyword and xferAttributes.

 

:22F::STCO//DLWM - Delivery without matching

 

:22F::SETR//OWNE - Account to account transfer

 

:97A::SAFE//<SDI account>

• When xfer Payer Role = PO, this field contains the Counterparty SDI A/C.
• When Xfer Payer Role = Counterparty, this field contains the PO SDI A/C.

 

:20C::PROC//<message ID> - Unique message id, different from :20C::SEME//

 

12. Processing GC Pooling Settlement Messages

To process GC Pooling Settlement Messages, you need to set the Domain Value GCPoolingSettlement = SettlementOnly (Default value is blank).

For GC Pooling, Clearstream is the sender of MT544-7 and MT536 messages. These messages confirm the settlement of the collateral allocations.

There can be 2 types of messages:

- Messages related to the GC Pooling baskets: These are recognized based on a specific security code GCPool_PFOD=true (e.g. DE000CASHPY4)

- Messages related to other securities (GCPool_PFOD=false). For these, you need to make other validations on sender and accounts, as the same sender can send messages not related to GC Pooling.

The messages for sender other than GC Pooling baskets can be identified based on the following criteria:

1. Sender

To identify Sender, you need to set LE attribute ‘GCPoolingSettleConfSender’ for Eurex GC Pooling Triparty Agents. When the Sender of the Incoming Message has LE attribute GCPoolingSettleConfSender then check for Safekeeping Account criteria, else standard integration process is continued.

2. Safekeeping Account

You can identify Safekeeping account in tag 97A::SAFE:

- If MT536 Incoming Message is available from 97A::SAFE under block :16R:SUBSAFE else, under block :16R: GENL

- If MT544-47 Incoming Message is available from 97A::SAFE under block :16R: FIAC

Note: The value in the tag must match Account Property ‘XferAgentAccount’ of the Calypso Account.

If an Account Property ‘ReservationAccount/SegregationAccount/PledgeAccount’ = True then check next criteria, else the message is not related to GC Pooling and standard integration process is continued.

3. Not a Source Account

To identify such source account, you need to set the Domain Value “GCPoolingSourceAccount” that stores list of potential source accounts.

Check if Counterparty Safekeeping account is available in block 16R SETPRTY as follows:

With the above config when MT544, MT545 or MT536 messages with:

22H::REDE//RECE →Safekeeping accounts in 97a::SAFE/ for parties 95a::DEAG, 95a::DECU and 95a::SELL

22H::REDE//RECE →If at least one of those safekeeping accounts is included in the Domain Value: GCPoolingSourceAccount → Then criteria is not met.

When MT546, MT547 or MT536 messages with:

22H::REDE//DELI →Safekeeping accounts in 97a::SAFE/ for parties 95a::REAG, 95a::RECU and 95a::BUYR

22H::REDE//DELI →If at least one of those safekeeping accounts is included in the Domain Value GCPoolingSourceAccount →Then criteria is not met.

 

When Incoming Settlement Confirmation Message is related to GC Pooling, the BO Message is created with the Message attribute “GCPoolingSettleMessage”.

SimpleTransfer Trade of Type ‘Cash’ is created if ISIN has the Security Code = GCPool_PFOD, else SimpleTransfer Trade of Type ‘Security’ is created.

 

MT548 Settlement Status

MT548 messages for GC Pooling collateral allocation can be identified as follows.

- If Sender and Safekeeping Account criteria are met, the BO Message is created with the Message attribute “GCPoolingSettleMessage”.