Integrating Jurisdiction Identifiers

Automatic integration of the jurisdiction identifiers.

For regulatory reporting, as both parties of the trade (ProcessingOrg and Counterparty) have to report to a Trade Repository, one party must generate the identifiers, and the other one must “consume” them (i.e. receive them from its counterparty and use them in its messages).

When the ProcessingOrg is the “UTI Generating Party”, Calypso is able to automatically generate the identifiers, store them in 2 trade keywords (see below), use them in the outgoing DTCC GTR messages, and communicate them to the Counterparty in SWIFT Confirmation messages (fields 22M/22N).

If the ProcessingOrg is NOT the “UTI Generating Party”, Calypso must “consume” the Counterparty identifiers (fields 22M/22N). There are several possibilities:

Upon reception of the SWIFT confirmation from the Counterparty:

When the incoming confirmation is matched with an outgoing one (either manually or automatically), if the incoming message contains the identifiers and the outgoing does not, the system propagates the identifiers (on the trade linked to the outgoing message).

When the identifiers are received from the counterparty by another means (fax, phone or another platform):

The identifiers can be manually updated by the user or automatically filled thanks to a custom workflow rule.

 

Trade Keywords per Jurisdiction

Trade Keywords Jurisdiction
UTI/Issuer ESMA
UTI/TradeId ESMA
USI/USIIssuer CFTC
USI/USITradeId CFTC
CanadaUTI/Issuer Canada
CanadaUTI/TradeId Canada
HkmaUTI/Issuer Hkma
HkmaUTI/TradeId Hkma
MasUTI/Issuer Mas
MasUTI/TradeId Mas
AsicUTI/Issuer Asic
AsicUTI/TradeId Asic
FcaUTI/Issuer FCA
FcaUTI/TradeId FCA

 

This applies to the following messages:

MT300: Foreign Exchange Confirmation (fields 22L/22M/22N appear in optional sequence E)
MT304: Advice/Instruction of a Third Party Deal
MT305: Foreign Currency Option Confirmation (in optional sequence B)
MT306: Foreign Currency Option Confirmation (in optional sequence K)
MT340: Forward Rate Agreement Confirmation (in optional sequence G)
MT341: Forward Rate Agreement Settlement Confirmation (in optional sequence G)
MT360: Single Currency Interest Rate Derivative Confirmation (in optional sequence O)
MT361: Cross Currency Interest Rate Swap Confirmation (in optional sequence O)
MT600: Commodity Trade Confirmation
MT601: Commodity Option Confirmation

 

If domain "GlobalUTI" contains a jurisdiction “ESMA” with Comment = true, the trade keyword that is under MapTo of the Name GlobalUTI/Issuer in Reporting Attribute window is used instead to populate tag 22M.

If domain "GlobalUTI" contains a jurisdiction “ESMA” with Comment = false, the trade keyword that is under MapTo of the Name UTI/Issuer in Reporting Attribute window is used instead to populate tag 22M.

 

Trade Keywords for FX Swaps Far Leg per Jurisdiction

Trade Keywords Jurisdiction
UTI/TradeIdFar ESMA
USI/USITradeIdFar CFTC
CanadaUTI/TradeIdFar Canada
HkmaUTI/TradeIdFar Hkma
MasUTI/TradeIdFar Mas
AsicUTI/TradeIdFar Asic
FcaUTI/TradeIdFar FCA

 

This applies to the following messages:

MT300: Foreign Exchange Confirmation (fields 22L/22M/22N appear in optional sequence E)
MT304: Advice/Instruction of a Third Party Deal

 

Special Case for Canadian Jurisdictions

Field 22L is set as follows:

If trade keyword "ProcessingOrgRole-CA.ON.OSC", is set to “ReportingParty” or “BothReport”, field 22L is set to CAONOSC
If trade keyword "ProcessingOrgRole-CA.MB.MSC", is set to “ReportingParty” or “BothReport”, field 22L is set to CAMBMSC
If trade keyword "ProcessingOrgRole-CA.QC.AMF", is set to “ReportingParty” or “BothReport”, field 22L is set to CAQCAMF
If trade keyword "ProcessingOrgRole-CA.AB.ASC", is set to “ReportingParty” or “BothReport”, field 22L is set to CAABASC
If trade keyword "ProcessingOrgRole-CA.BC.BCSC", is set to “ReportingParty” or “BothReport”, field 22L is set to CABCBCSC
If trade keyword "ProcessingOrgRole-CA.NB.FCSC", is set to “ReportingParty” or “BothReport”, field 22L is set to CANBFCSC
If trade keyword "ProcessingOrgRole-CA.NL.DSS", is set to “ReportingParty” or “BothReport”, field 22L is set to CANLDSS
If trade keyword "ProcessingOrgRole-CA.NS.NSSC", is set to “ReportingParty” or “BothReport”, field 22L is set to CANSNSSC
If trade keyword "ProcessingOrgRole-CA.NT.NTSO", is set to “ReportingParty” or “BothReport”, field 22L is set to CANTNTSO
If trade keyword "ProcessingOrgRole-CA.NU.NSO", is set to “ReportingParty” or “BothReport”, field 22L is set to CANUNSO
If trade keyword “ProcessingOrgRole-CA.PEI.OSS” is set to “ReportingParty” or “BothReport”, field 22L is set to CAPEIOSS
If trade keyword “ProcessingOrgRole-CA.SK.FCAA” is set to “ReportingParty” or “BothReport”, field 22L is set to CASKFCAA
If trade keyword “ProcessingOrgRole-CA.YT.OSS” is set to “ReportingParty” or “BothReport”, field 22L is set to CAYTOSS

 

1. Setup

It is possible to automatically propagate (on the trade) the Counterparty jurisdiction identifiers received in the incoming SWIFT confirmation (when the jurisdiction identifiers are still empty on the trade, and the incoming and outgoing confirmations can be matched on other criteria).

The UTI propagation configuration should be available in the domain "MatchingContext.Propagation.ConfigName":

Value = UTI

 

This configuration is meant to copy the Incoming Message jurisdiction identifiers on the Trade linked to the Outgoing message.

In order for this Propagation to be eligible, three matching keys need to be setup in the Matching Context:

Reporting Jurisdiction
<jurisdiction> Issuer Code
<jurisdiction> Transaction Identifier

To make the references optional, the UTI/USI Issuer Code and UTI/USI Transaction Identifier should use the Tolerance OptionalReference.

Example for UTI/USI:

Make sure that Usage = None for the Reporting Jurisdiction.

Check Propagation and select the UTI config name. You can select the action t propagate the UTI keywords. The default action is UPDATE.

 

2. Process

In both matching and unmatching, when intending to propagate or reset the jurisdiction identifiers on the trade, the system will apply the action UPDATE. If this action is not available, the matching / unmatching will fail.

 

2.1 Matching

When matching one incoming confirmation with an outgoing one (either automatically or manually through the Matching Manager), if the incoming message has a UTI/USI and the outgoing does not, the system will add the UTI/USI information as follows:

Update keyword UTI/Source with “UTIPropagation” (this is used to undo the propagation in case an unmatch is performed).

Update the trade keywords based on the jurisdiction:

It first checks if any DTCC GTR Reporting attributes is mapped to any of the trade keywords listed above in the Reporting Attributes window, based on the jurisdiction, and propagates their value.
If no mapping is found the Reporting Attributes window, it checks the trade keywords defined in the domain "DTCC-GTR-ReportingData", and propagates their value.

 

Example:

The Incoming MT360 confirmation (Msg id 10045014) contains the jurisdiction identifiers in the fields 22L (Reporting Jurisdiction ESMA), 22M (Issuer) and 22N (Transaction Identifier).

In the Matching Manager, this Incoming MT360 Confirmation received from the Counterparty is matched with an Outgoing one (Msg id 10045013, corresponding in Calypso to Trade Id 10009408, which has no jurisdiction identifier):

During the matching process, the jurisdiction identifiers available in the Incoming MT360 message are copied in the trade keywords GTR-UTI/Issuer and GTR-UTI/TradeId on the trade 10009408. Moreover, the UTI/Source keyword is updated with the value “UTIPropagation”.

In this example, GTR-UTI/Issuer and GTR-UTI/TradeId are the alias for UTI/Issuer and UTI/TradeId defined in the domain "DTCC-GTR-ReportingData".

 

2.2 Unmatching

When a matching is undone, if the trade linked to the outgoing message has the keyword UTI/Source = “UTIPropagation”, then the system will remove the keywords corresponding to the jurisdiction identifiers.