CMRS RegReport Rules

uto
Disclaimer and Copyright

Statement © COPYRIGHT 2016 SAPIENT CORPORATION
This document, the

accompanying software and other CMRS RegReport Rules
documentations are protected by
the international copyright laws.
Last Updated Date – Oct 10, 2017
This may be used in accordance
with the accompanying license
agreement. The responsibility of
the user is to comply with all the
applicable copyright laws. Without This document is intended only
limiting the rights under for the sole use of the intended
copyright, no part of this party as mentioned in the
document may be reproduced, footnote section of this page and
stored in or introduced into a may not be shared with any other
retrieval system, or transmitted in party without explicit written
any form or by any means permission of Sapient
(electronic, mechanical, Corporation.
photocopying, recording, or
otherwise), or for any purpose,
without the explicit written Copyright © 2016 Sapient; All
permission of Sapient rights reserved.
Corporation.
Sapient may have patents, patent

applications, trademarks, If you have comments or
copyrights, or other intellectual suggestions regarding this
property rights covering subject document, please send an e-mail
matter in this document. Except to [email protected].
as provided in any written license
agreement from Sapient, the
furnishing of this document does
not give the reader any license to
these patents, trademarks,
copyrights, or other intellectual
property.
Conten
1 INTRODUCTION.........................................9
2 INTERNAL TRADE RULE............................10
2.1 SCENARIO.............................................10
2.1.1 System Configuration...................10
2.1.2 Legal Entity Setup.........................11
2.1.3 Counterparty Setup......................11
2.1.4 Track & Trace Screen....................12
3 TRADE BETWEEN NON-US PARTIES (DF ONLY) 14
3.1 SYSTEM CONFIGURATION.........................14
4 DELEGATION RULE (EMIR, ASIC, MAS AND BOI ONLY) 15
5 INTER-AFFILIATE TRADES (DF, EMIR, REMIT AND CSA ONLY) 17
5.1 SETUP REQUIRED....................................18

5.1.1 Counterparty Screen.....................18
5.1.2 Events screen................................19
5.2 CMRS REGREPORT IMPLEMENTATION.......19
6 JURISDICTION DETERMINATION (JEDI).....21
6.1 OVERVIEW............................................21
6.2 FUNCTIONING OF JEDI............................21
6.2.1 Ignore MiFID II only deals for TRs other an Trax or Tradeweb 22
6.3 JEDI DETERMINATION ON TRACK & TRACE.23
6.4 IGNORE EOM_SNAPSHOT EVENT FOR ALL THE TRS EXCEPT BOI 23
7 RPD RULE................................................24
7.1 RPD RULE FOR DF.................................24

7.1.1 Reporting Party Override Rule......25
7.1.2 RPD Override from LE CP Configuration Screen 26
7.1.3 RPD Based on Organization Type. 26
7.1.4 CMRS RegReport Setup.................27
7.1.6 RPD on Tie Breaker.......................30
7.1.7 RPD for ICE TR...............................32
7.2 RPD RULE FOR CANADIAN REPORTING......32
7.2.1 CMRS RegReport Setup.................35
7.3 RPD RULE FOR PTT REPORTING...............36
8 RERUN RPD RULE.....................................38
9 ERE RULE.................................................41
9.1 ERE RULE (DF AND CSA ONLY)...............41

9.1.1 Source File Configurations............42
9.1.2 Scenarios and Ignore messages. . .42
9.2 ERE RULE (MIFD-II POST TRADE TRANSPARENCY) 49
10 SNAPSHOT EVENT SWITCH RULE..............50
11 ETD_POSITION_TRADE RULE (EMIR ONLY)53
12 INTERIM UTI RULE (EMIR ONLY)...............54
13 BUYER/SELLER IDENTIFIER RULE...............56
13.1 INTEREST RATE.......................................56

13.2 FOREIGN EXCHANGE...............................57
13.3 CREDIT.................................................59
13.4 COMMODITY.........................................59
13.5 EQUITY.................................................59
14 DELEGATED MESSAGE SUPPRESSION RULE (EMIR ,ASIC AND BOI ONLY) 60
14.1 WORKFLOW..........................................61
15 USI/PRIOR USI RULE (DF, ASIC, MAS, AND CSA ONLY) 63
15.1 WORKFLOW..........................................63
16 UNIQUE ID CREATION BY TR/APA.............65
16.1 GTR CREATE RULE (DF ONLY).................65

16.2 TRADEWEB TRADEID GENERATED & SHARED BY APA (MIFID-II PTT)65
17 TRN GENERATION FOR MIFID-II TRANSACTION REPORTING 66
18 MANDATORY CLEARING EXEMPTION RULE (DF AND CSA ONLY) 68
18.1 EXEMPTION FOR INTER-AFFILIATE SWAPS. . .68

18.2 EXEMPTION FOR END-USERS....................68
18.3 WORKFLOW..........................................68
19 SUPPRESS 43/45 (DF ONLY)......................71
19.1 WORKFLOW..........................................71
19.2 COUNTERPARTIES SETUP..........................71
20 RT SUPPRESS FOR FX FORWARD (DF ONLY)72
20.1 SUPPRESS APPROACH..............................72

20.2 WORKFLOW..........................................72
21 ORIGINATING TRADE ID SCENARIO...........73
22 UTI GENERATING PARTY DETERMINATION RULE (EMIR, ASIC, MAS AND BOI ONLY) 74
22.1 WORKFLOW..........................................74
22.2 UGD RULE – DTCCEU /DTCCEULITE....75
22.3 UGD RULE – ICE...................................77
22.4 UGD RULE – BOI..................................78
23 UTI DELEGATION RULE (EMIR, ASIC, ,MAS AND BOI ONLY) 80
23.1 WORKFLOW..........................................80
24 REPORTING ON BEHALF OF COUNTERPARTY (MIFID-II PTT ONLY) 81
25 MW EXISTS (EMIR, ASIC, AND MAS ONLY) 82
26 REPORTABLE PRODUCT RULE FOR ICE-TR..83

27 ADDITIONAL REPOSITORY 3 LOOKUP OVERRIDE (CSA ONLY) 84
28 IDENTIFICATION OF SINGLE-SIDE/DOUBLE-SIDE TRADE FOR ICE-TR 85
29 SOVEREIGN ENTITIES RULE (MAS ONLY). . .86
30 AUTO RESOLVE RULE................................87
31 OTC CLEARED TRADE SWITCH RULE..........88
32 ACTION SWITCHING RULE........................90
33 DESTINATION EVENT SWITCHING RULE....92
34 REPORT UPDATED USI/UTI/PARTY IDENTIFIER 93
34.1 DTCC TRS EXCEPT OTCLITE:..................93

34.2 OTCLITE TR:.......................................93
34.3 REGIS TR:.............................................93
34.4 ICE TRADE VAULT - EMIR.......................94
34.5 ICE TRADE VAULT – REMIT....................94
35 HKMA REPORTABLE RULE.........................95
35.1 SYSTEM CONFIG.....................................95

35.2 SCENARIOS............................................95
35.3 WORKFLOW..........................................96
36 ASIC REPORTABLE RULE...........................97
36.1 SYSTEM CONFIG.....................................97

36.2 SCENARIOS............................................97
36.3 WORKFLOW..........................................98
37 MAS REPORTABLE RULE...........................99
37.1 SYSTEM CONFIG.....................................99

37.2 SCENARIOS............................................99
37.3 WORKFLOW........................................101
38 PARTY 1 SNAPSHOT MESSAGE SUPPRESSION RULE (EMIR ONLY) 102
39 COUNTERPARTY MASKING (CFTC, CSA, MAS, ASIC, HKMA) 103
40 SHEKEL YIELD RULE (BOI)........................104
40.1 WORKFLOW........................................104
40.2 OVERRIDE...........................................105
41 FX SPOT REPORTABILITY RULE................107
42 RT MESSAGE SUPPRESSION RULE (CFTC ONLY) 108
42.1 RT SUPPRESSION FOR PRIME BROKER DEAL108

42.2 RT SUPPRESSION FOR NON-PRICE FORMING AMEND/CORRECTION 108
43 CLEARING THRESHOLD LOOKUP LOGIC (ESMA ONLY) 109
44 RULE FOR DETERMINING LEVEL (ESMA ONLY) 110
45 RULE FOR FILTERING NON-REPORTABLE AMEND (MIFID-II TRANSACTION & PTT ONLY) 111
46 FILTERING NON-REPORTABLE EVENTS (MIFID-II TRANSACTION & PTT ONLY) 114

47 EVENTS ON TRADES EXECUTED BEFORE MIFID II LIVE DATE (MIFID-II TRANSACTION & PTT ONLY) 116
48 REPORTING INCREASE/DECREASE EVENTS (MIFID-II TRANSACTION REPORTING ONLY) 118
49 REPORTING MULTIPLE VALUES FOR COMMON FIELDS (MIFID-II TRANSACTION & PTT ONLY) 121
50 PROCESSING THE NPO EVENT AS NEW TRADE IF POSITION HAS NOT BEEN REGISTERED
WITH TR (DTCC-EU, TRAX).......................124
51 CFI GENERATION RULE (DTCC-EU, DTCC-EULITE & TRAX) 126
52 COLLATERALIZATION LOOKUP RULE (DTCC-EU, ICE-TV EMIR) 128
53 SUPPRESS COLLATERALIZATION RULE (DTCC-EU, DTCC-EULITE ICE-TV EMIR) 129
54 ISIN VALIDATION WORKFLOW (TRAX & TRADEWEB) 130
55 SUPPRESS RULE FOR COMMERCIAL ACTIVITY FIELDS (DTCC-EU, DTCC-EULITE ICE-TV EMIR) 132
56 REPORTING TRADES WITH ONLY THE KEY IDENTIFIER (DTCC ALL TRS) 133
57 BALANCING SERVICES RULE (REMIT ONLY). .134
57.1 SCENARIOS................................................134
58 PHYSICAL DELIVERY THRESHOLD RULE (REMIT ONLY) 135
58.1 SCENARIOS................................................135
RULES SUMMARY...........................................136
Page 7
List of FiguresY
FIGURE 2-1: LEGAL ENTITY SET UP – REPORTABLE TO DF..................................................................................................10
FIGURE 2-2: COUNTERPARTIES SCREEN...........................................................................................................................10
FIGURE 2-3: TRACK & TRACE SCREEN - DEAL PROCESSED.................................................................................................11
FIGURE 5-1: COUNTERPARTIES SCREEN...........................................................................................................................17
FIGURE 5-2: EVENTS SCREEN........................................................................................................................................18
FIGURE 5-3: TRACK & TRACE SCREEN - AFFILIATE TRADE..................................................................................................19
FIGURE 6-1: TRACK & TRACE SCREEN - JEDI RULE VIEW..................................................................................................21
FIGURE 7-1: LE CP CONFIGURATION SCREEN - RPD RULE................................................................................................24
FIGURE 7-3: LEGAL ENTITY SETUP FOR RPD RULE...........................................................................................................26
FIGURE 7-4: COUNTERPARTY SETUP FOR RPD RULE.........................................................................................................26
FIGURE 7-5: TRACK & TRACE SCREEN - CMRS REGREPORT AS REPORTING PARTY................................................................28
FIGURE 7-6: TRACK & TRACE SCREEN - CMRS REGREPORT AS NON-REPORTING PARTY........................................................28
FIGURE 9-1: EXECUTION FACILITY - SEF AND CLEARINGDCOVALUE - BLANK......................................................................39
FIGURE 9-2: TRACK & TRACE SCREEN - MESSAGE IGNORED..............................................................................................40
FIGURE 9-3: EXECUTION FACILITY - SEF & CLEARING VALUE - DCO...................................................................................40
FIGURE 9-4: TRACK & TRACE – MESSAGE IGNORED.........................................................................................................41
FIGURE 9-5: EXECUTION FACILITY AS OFF-FACILITY AND CLEARINGDCOVALUE AS BLANK......................................................41
FIGURE 9-6: TRADE EXECUTED OFF-FACILITY AND NOT CLEARED.........................................................................................42
FIGURE 9-7: INDICATING EXECUTION FACILITY AS OFF-FACILITY AND CLEARINGDCOVALUE AS DCO.........................................43
FIGURE 9-8: TRACK & TRACE SCREEN; DEAL VIEW - DEAL PROCESSED................................................................................43
SAPIENT CONFIDENTIAL 424714633.docx

Page 8
Preface
The objective of this document is to help users understand the Rules
applied by the Compliance Management and Reporting System (CMRS)
RegReport application. CMRS RegReport applies various rules on the
trades flowing into CMRS RegReport and further processing of that trade
depends upon the outcome of these rules.
CMRS RegReport uses the rules to filter which trades needs to get
reported, determine the UTI generating party:
 Identify which trade to report – Not every trade is reportable.

Commodity futures trading commission (CFTC) has provided certain
guidelines to the swap data repositories (SDR), for the types of trades,
which need to be reported.
 Identify which messages need to get suppressed. For this CMRS
RegReport determines inter affiliate trades and organization type for
EMIR or delegation setup.
 Determine the jurisdiction and TR to which an incoming trade is
reportable to.
 Identify, who should report – CFTC and EMIR has laid out rules, which
CMRS RegReport uses to determine the reporting party for that deal.
 Identify, if there is any External Entity involved (e.g., Swap execution
facility (SEF), Derivatives clearing organization (DCO)), and is
responsible for reporting.
Audience
This document is intended for use by the following teams:
 Enterprise Users of CMRS RegReport

 Level 1 support team
Document Conventions
This document uses the following conventions:
Each figure in the document is labeled with a figure caption above it.
The steps to complete a procedure are presented with screenshots,
wherever necessary.
The following text highlights have been used:
Means you need to take note. It may contain helpful

suggestions or provide references to a different section

Page 9
NOTE contained in this document.
Means you need to be careful. You are capable of doing

something that might result in loss of data.
CAUTION
Means this is important. You should reflect upon it before

continuing further.
IMPORTANT
Abbreviations and Acronyms

Term Description
ASCII American standard code for information interchange
CFTC Commodity futures trading commission
CMRS Compliance Management and Reporting System
RegReport RegReport
DCM Designated contract market
DCO Derivatives clearing organization
DF Dodd Frank
DTCC Depository trust & clearing corporation
EB Execution broker
ERE External reporting entity
ESMA European Securities and Markets Authority
FRA Forward rate agreement
FX Foreign exchange
IRS Interest rate swap
LEI Legal entity identifier
MSP Major swaps participant
MW Middleware
OIS Overnight indexed swap
PB Prime broker
PET Primary economic terms
RP Reporting party
RPD Reporting party determination
RT Real time
SD Swap dealer
SDR Swap data repositories
SEF Swap execution facility
SWIFTBIC SWIFT bank identifier codes
T&T Track & Trace
UCID Unique counterparty identifier
ULID Unique legal entity identifier
USI Unique swap identifier
UTI Unique Trade Identifier

Page 10
Term Description
XCCY Cross currency

Page 11
1Introduction
CMRS RegReport Rule engine contains various rules, which are
implemented on the input files, when flowing into the system. These rules
are applied on each trade (or feed) flowing in the system and the actions
are taken respectively.
Report Updated USI/UTI/Party

SAPIENT CONFIDENTIAL
Identifier
Page 12
2Internal Trade Rule

INTERNAL trade refers to the trade booked between departments of the
same legal entity. In CMRS RegReport, if two entities in a trade have the
same Party ID & Convention, then the trade is considered to be ‘Internal’.
A trade booked with internal party, has same party ID for both the parties
involved in the trade. The behavior of internal trades will be same for
CFTC, EMIR, MiFID II Transaction Reporting, MiFID II Post Trade
Transparency (PTT) Reporting and REMIT. Both the regulations say that if
the trade is between 2 parties with same party id + convention, the trade
is exempted from reporting obligation.
2.1 Scenario
For any trade, where the parties have the same party ID & convention
combination, it will be treated as an INTERNAL trade and therefore, it will
be ignored for reporting by CMRS RegReport. (In CMRS RegReport, Party1
ID is stored as unique legal entity identifier (ULID) and Party2 ID is stored
as unique counter party identifier (UCID)).
Trade Party1 Party1 Party2 Party Statu Explanation

ID ID 2 ID s
Since, the reporting
ID of both the
CITI11 CITI11
Deal1 CITIBAN Ignore parties is the same,
20008 CITINYC 20008
01 K d so the trade is
7 7
Ignored by CMRS
RegReport.
2.1.1 System Configuration

In CMRS RegReport, the following steps are required to be followed, to
configure the parties as internal:
1. Setup the Legal Entity with its ULID.

2. Setup the Counter party with the UCID same as ULID of the above
party.
On processing the trade with the above mentioned parties, CMRS

RegReport will ignore the trade as INTERNAL and the Ignore message will
be displayed on the Track & Trace screen.

Identifier
Page 13
Party ID could be one of the following types: AVOX, DTCC, LEI,

SWIFTBIC, EIC, ACE and CICI. Both parties should have the
NOTE same party ID, as well as party ID type.
2.1.2 Legal Entity Setup

You need to setup a Legal Entity, with its reporting ID under Party ID. An
example is shown in the following figure:
Figure 2-1: Legal Entity Set up – Reportable to DF
2.1.3 Counterparty Setup

Setup counterparty, with its party ID same as mentioned above in Legal
Entity set up screen. An example is shown in the following figure:
Figure 2-2: Counterparties Screen

Identifier
Page 14
2.1.4 Track & Trace Screen

When this trade flows into the system, CMRS RegReport will recognize this
trade as an INTERNAL trade and will ignore it. Please refer to the following
snapshot for the Ignored details.
Figure 2-3: Track & Trace Screen - Deal Processed

Identifier
Page 15
In case of reporting to a GTR (single TR for both jurisdictions), the

order of priority for convention based on which Party Id will be
looked up from LE screen is mentioned below and the above flow
will remain applicable to identify Internal Trades.
1. LEI
2. CICI
3. AVOX
4. SDO
NOTE 5. EFET
6. SWIFTBIC
7. INTERNAL
8. FREEFORMATTEXT
9. IEI
10. COD

Identifier
Page 16
3Trade Between Non-US Parties

(DF Only)
This rule is applicable only for DF jurisdiction and a trade between 2 non-
US parties.
CMRS RegReport allows the reporting of such trades to be ignored. This is

done based on a flag ‘CMRSREPORT_BOTH_NON_US’ which is part of the
system configuration (to be governed by system administrator).
Scenario
For any trade, where both the parties involved in the trade are non-US
person, the trade will be ignored by CMRS RegReport provided the flag is
enabled.
Tra Party Is Party Is CMRSREP Statu Explanation

de 1 Party1 2 Part ORT_BOT s
ID US y2 H_NON_U
Person US S
? Per
son
?
Since, both
the parties
Dea are non-US;
CITIB Ignor
l20 No HSBC No False the trade is
ANK ed
1 ignored by
CMRS
RegReport.
3.1 System Configuration

In CMRS RegReport, the following steps should be followed for configuring
parties, as non-US parties:
1. CMRSREPORT_BOTH_NON_US should be set as ‘False’ by the Admin

2. Setup the Legal Entity with ‘Is US Person’ flag as unchecked.
3. Setup the Counter party with ‘Is US Person’ flag as unchecked.
When a trade flows into CMRS RegReport, which involves the non-US
parties, CMRS RegReport will identify this trade as BOTH_NON_US and

Identifier
Page 17
would ignore the trade. The Ignore message will be displayed on the Track
& Trace screen.

Identifier
Page 18
4Delegation Rule (EMIR, ASIC,

MAS and BOI Only)
If legal entity has delegated the reporting to counterparty or clearing
counterparty or any additional entity, the legal entity has no reporting
obligation and the deal will be ignored at deal processed stage. The
delegation is done on an asset class level except for Collateral.
CMRS RegReport supports delegation on 3 levels –
1. Transaction
2. Valuation
3. Collateral
These are independent and can be set irrespective of each other.
Scenario
Scenario CMRS RegReport Action
Full Delegation By LE to CP Filter all reporting
[CMRS RegReport is at LE]
Full Delegation By CP to LE Reports both the messages associated
[CMRS RegReport is at LE] with the event. CMRS RegReport
reports on behalf of both parties.
Full Delegation By CP to LE Reports only on behalf of CP.
[CMRS RegReport is at LE and LE
is not reportable to that
jurisdiction]
Independent [CMRS RegReport Reports only on behalf of LE.
is at LE]
Full Delegation By LE to ERE Filter all reporting
Full Delegation by CP to LE and Filter all reporting
further LE to ERE [CMRS
RegReport is at LE]
Full Delegation by CP to LE and Reports both the messages associated
further LE to third party with the event. CMRS RegReport
[CMRS RegReport is at third reports on behalf of both parties.
party]
Full Delegation By LE to CP Filter all reporting

Identifier
Page 19
ICE-Specific Scenario
Delegation is applicable for EMIR reporting for ICE TR but since ICE e-
confirm is a confirmation platform, the expected behavior in different
scenarios is explained below:
Scenario Single-Sided Double-Sided

Send to ICE for
confirmation but not
reporting with
Full Delegation By LE EMIRREPORTABLETRADE
to CP [CMRS Filter all reporting FIELD AS 'N'. CMRS
RegReport is at LE] RegReport will not
generate UTI and will
pass-through UTI is
coming from SS.
CMRS RegReport reports
Full Delegation By CP CMRS RegReport on behalf of both parties.
to LE [CMRS RegReport reports on behalf of Send
is at LE] both parties. EMIRREPORTABLETRADE
FIELD AS 'Y'
Reports only on behalf of
LE.
Independent [CMRS Reports only on behalf
Send
RegReport is at LE] of LE.
EMIRREPORTABLETRADE
FIELD AS 'Y'
Send to ICE for
reporting with
Full Delegation By LE EMIRREPORTABLETRADE
to ERE [CMRS Filter all reporting FIELD AS 'N'. CMRS
RegReport is at LE] RegReport will not
pass-through UTI is
coming from SS.
Send to ICE for
reporting with
Full Delegation by CP
EMIRREPORTABLETRADE
to LE and further LE to
Filter all reporting FIELD AS 'N'. CMRS
ERE [CMRS
RegReport will not
RegReport is at LE]
pass-through UTI is
coming from SS.
Full Delegation by CP CMRS RegReport CMRS RegReport reports
to LE and further LE to reports on behalf of on behalf of both parties.
third party [CMRS both parties. Send
RegReport is at third EMIRREPORTABLETRADE
Identifier
Page 20
Scenario Single-Sided Double-Sided

party] FIELD AS 'Y'

Identifier
Page 21
5Inter-Affiliate Trades (DF, EMIR,

REMIT and CSA Only)
What is Affiliate?
A type of inter-company relationship in which one company owns less than
a majority of the other company's stock, or a type of inter-company
relationship in which at least two different companies are subsidiaries of a
larger company.
As per CFTC, real time (RT) messages are not reportable for Affiliate
trades. In REMIT, Affiliate Trades executed outside the Exchange are not
reportable.
CMRS RegReport is able to identify the Inter-Affiliate trades and

successfully process them.
Scenario
Trad Even Party1 Party2 Is CMRS Comments
e ID t Affiliat RegReport
e? Result
Since the RT
message is
not
associated
with this
The event
event, CMRS
Deal TRAD JP changes to
BANKNYC Yes RegReport
321 E Morgan AFFILIATE_TR
would send
ADE
the primary
economic
terms (PET)
message for
this deal.
In CMRS RegReport, Counter parties are common across

multiple Legal Entities. If more than one Legal Entities are
setup in CMRS RegReport and the counter party is marked as
Affiliate, then CMRS RegReport considers it as affiliate for all
NOTE
the Legal Entities present in the system.

Identifier
Page 22
In ICE RRM if a trade is ignored because it’s an Affiliate

Transaction then that trade can be reported on ad-hoc basis.
This functionality has been provided on Exception View Screen.
NOTE

Identifier
Page 23
5.1 Setup Required

5.1.1 Counterparty Screen
You can specify affiliates while creating a counter party in CMRS
RegReport. , there is a checkbox field specifying, if it is an Affiliate or not.
If,
 Checked – means Counter party is an affiliate of the Registered Legal

Entity.
 Unchecked – means Counter party is not an affiliate.
Figure 5-4: Counterparties Screen

Identifier
Page 24
5.1.2 Events screen

AFFILIATE events must be created in CMRS RegReport and the respective
messages will be associated with those events.
Figure 5-5: Events Screen
Affiliate is supported for all the events. For the description of the Affiliate
events, refer to the Event Handling and Management document
5.2 CMRS RegReport Implementation

The input file, when received with an event as ‘TRADE’, CMRS RegReport
processes it. CMRS RegReport checks for the Counter party static data and
identifies, if it is an Affiliate party. If the counter party is an Affiliate party,
then CMRS RegReport identifies it to be an Affiliate trade and updates the
event of the deal as ‘AFFILIATE_TRADE’. The respective messages for the
affiliate trade are generated and are processed by CMRS RegReport.

Below mentioned is the example of ‘AFFILIATE_TRADE’:

Identifier
Page 25
Figure 5-6: Track & Trace Screen - Affiliate Trade

Identifier
Page 26
6Jurisdiction Determination (JEDI)

6.1 Overview
CMRS RegReport provides the capability to report a single Trade to
multiple TRs for multiple Jurisdictions. To accommodate this CMRS
RegReport has created a rule called JEDI which determines to which all
Jurisdiction and TR a trade can be reported to. CMRS RegReport will
determine these using the Asset Class, Legal Entity, Counter Party and the
Product which will be available in our system.
6.2 Functioning of JEDI

There are 4 major inputs to JEDI- Asset Class, Legal Entity, Counter Party
and Product. JEDI does 4 steps
1) Validation of inputs - Asset class, Legal Entity, Counter Party
In asset class validation, it is validated if the asset class is a valid asset

class. In Legal Entity validation it is validated if the Legal Entity is valid
and linked to an active CMRS RegReport Legal entity (Link Legal Entities
screen). In Counter Party Validation it is validated if the input Counter
Party is valid and linked to a CMRS RegReport Counter Party (Link
counterparties Screen). Counter Party validation is by passed for
Collateral/Collateral Link events reportable to ASIC regulation, as the
Counter Party information wouldn’t exist in these submissions. If any of
the validation fails, the entire deal is failed.
2) Identification of regulations and TRs to report to using the

configurations on Legal Entity screen
Once the validations are successful, from the Legal Entity Screen, for the
corresponding Legal Entity and Asset class we identify the regulations and
corresponding TRs to which the Legal entity is reportable for that asset
class. If the event is Collateral/Collateral Link then the TRs are identified
based on Portfolio drop down and not on the basis of Asset Class. Once
the TRs identified a validation is performed if the asset class s licensed for
that TR, Regulation and asset class
3) Validation if the Product is linked to the TR and reportable

to the Regulation selected in step 2

Identifier
Page 27
From the Regulations and TRs identified in step 2, it is validated if the

Product is valid product, it is linked to TRs identified in step 2(Link
Products Screen) and the Product is reportable to Regulations identified in
step2 (Product Regulation Map Screen).
Only those Regulation TR pairs are taken which satisfy this validation,
other Regulations – TRs pairs are ignored from processing. This rule is by
passed for Exchange traded Derivatives Products, Collateral Events and
Deals reportable to ICE Trade Vault.
4) Validation if the Counter Party is also reportable to the

regulation identified in step3
From the regulations identified in step 3 only those regulations for which
the Counter Party is also reportable (counter Party screen) or set up (for
EMIR, MAS, ASIC) are taken into consideration, other regulations are
ignored from processing. This validation is by passed for
Collateral/Collateral Link events reportable to ASIC regulation as the
Counter Party wouldn’t be available for these events.
At the end of step 4 for the identified Regulations and TRs the trade is
processed.
6.2.1 Ignore MiFID II only deals for TRs other an

Trax or Tradeweb
The rule is applicable if a Product is linked to the TR (other than Trax OR
Tradeweb) OR a blank value is coming from source system (mapped with
dummy product in case of Trax and Tradeweb)

Identifier
Page 28
LE & CP both Configured

SS Product ID
S. No. for Trax OR Tradeweb CMRS Action
Mapped
Reporting?
Report the Trade to
1 FX:Swap Yes all the selected
entities
Report the Trade to
all the selected
2 FX:Swap No
entities other than
Trax & Tradeweb
Ignore the deal for
entities other than
Trax and Tradeweb;
3 [Blank] Yes
Report the deal to
Trax OR Tradeweb, if
applicable
Fail the deal for
entities other than
4 [Blank] No
Trax and Tradeweb
6.3 JEDI Determination on Track &

Trace
The highlighted deal below is reportable to CFTC only since the LE is not
setup for EMIR and hence the deal is not reportable to EMIR.
Figure 6-7: Track & Trace Screen - JEDI Rule View

Identifier
Page 29
6.4 Ignore EOM_Snapshot event for all the

TRs except BOI
 If EOM_Snapshot event is sent from the Source System then it will

be ignored at the enrichment stage (Deal Processed) for all the TRs
except BOI.
 The Event Destination field for EOM_Snapshot will be configured as

‘IGNORE’ for all the TRs except BOI.

Identifier
Page 30
7RPD Rule
7.1 RPD Rule for DF
After a trade flows through the above rules, then RPD rule is applied to
identify the reporting party, that is, the one party in the trade, which will
be responsible for reporting the trade to SDR.
When does RPD Happens?

• When the Position Opener** event flows into CMRS RegReport for
the first time.
• RPD will not happen, if the position opener event flows into CMRS
RegReport for the subsequent times***.
• RPD will not happen, if any post trade event is flowing into CMRS
RegReport.
RPD is only executed once for a deal, for the subsequent events on that
deal, reporting party lookup will be performed
** CMRS RegReport considers the following events as Position openers:
• TRADE
• SNAPSHOT
• NOVATION_TRADE
• NOVATION_FEE
• POST_ALLOCATION_TRADE
• POST_COMPRESION_TRADE
• POST_EXERCISE_TRADE
• AFFILIATE_ POST_COMPRESION_TRADE
• AFFILIATE_TRADE
• AFFILIATE_SNAPSHOT
• AFFILIATE_NOVATION_TRADE
• AFFILIATE_NOVATION_FEE
• AFFILIATE_POST_ALLOCATION_TRADE
• AFFILIATE_POST_EXERCISE_TRADE
*** Listing a few examples to understand the difference between the

position openers and subsequent position openers:
a. When CMRS RegReport receives a TRADE event for a deal ‘TRADE101’

and later it receives a SNAPSHOT event for the same deal: Even
though, SNAPSHOT is a position opener event, but the RP once
determined for this deal, should not be determined again and would be
looked up to retrieve the previously determined RP.
Identifier
Page 31
b. Considering a sequencing issue, where SNAPSHOT is received before

TRADE event: As described above, the RP will be determined only once,
for the first position opener flowing into CMRS RegReport, and for the
subsequent position opener, the RP will not be determined again.
The complete workflow is attached –
USI Generation &

RPD Logic.pdf
7.1.1 Reporting Party Override Rule

The RPD by CMRS RegReport can be overridden, if the source system
provides the details of the reporting party.
‘Party1ReportingObligation’ is field, which contains the reporting party

value from the Source system. It can have the following values:
1. ’ReportingParty’ - CMRS RegReport assumes user as a Reporting

Party and reports the generated messages.
2. ‘NonReportingParty’ - CMRS RegReport assumes user as a non-
Reporting Party and ignores the event.
3. <<BLANK>> - CMRS RegReport applies the RPD Rule.
Prime Broker (Give-up)

As per CFTC, if a trade is traded between PB and Execution Broker (EB),
then EB always acts as a ‘Reporting Party’.
CMRS RegReport supports such trades using Reporting Party Override

logic. If a trade is booked between two parties, where one being a PB and
other being the EB, then source system will identify the EB and will use
the Party1ReportingObligation field to report it as a ‘ReportingParty’.
If Legal Entity is ‘PB’ and Counter party is ‘EB’ then source system will
send the ‘NonReportingParty’ in Party1ReportingObligation block and
CMRS RegReport will consider it as a non-Reporting Party.
If Legal Entity is ‘EB’ and Counter party is ‘PB’ then the source system will
send ‘ReportingParty’ in Party1ReportingObligation block and CMRS
RegReport will consider it as a Reporting Party.
** If both the PBs and EBs are non-US, then the Trade will be ignored and
Party1ReportingObligation will be ignored.

Identifier
Page 32
7.1.2 RPD Override from LE CP Configuration

Screen
If no override from source is available for RPD, then in the LE CP
Configuration screen is verified that for the Giving Legal Entity
combination if the Reporting Party is populated. If the Reporting Party
dropdown has LE set, then LE is Reporting Parting, if the drop down has CP
set, then CP is Reporting Party, if the reporting Party drop down has None
means no reporting party is set.
Figure 7-8: LE CP Configuration Screen - RPD Rule
7.1.3 RPD Based on Organization Type

Reporting Party can be determined based on the details of the parties like
organization type, financial status and country.
First check is performed based on the organization type. When the

organization type of both the parties is ‘Non- Swap Dealer (SD)/ Major
Swaps Participant (MSP)’, then CMRS RegReport checks for the country of
the parties, even then if the status is not determined, it then looks for its
financial status. Please refer to the following ‘Reporting Party’ flowchart as
defined by Depository Trust & Clearing Corporation (DTCC).

Identifier
Page 33
Figure 7-2: Reporting Party determination flowchart
Please refer to the following table for further reference.
Legal Entity Counter Party

EntityFinancial
Part
Reporting
Organizat
Organizat
PersonUS
Financial
ion Type
ion Type
Person
Entity
Name
Party
Party
y
Nam US
e
PartyA SD Party1 MSP Party A
PartyB SD Party2 non-SD/MSP Party B
PartyC MSP Party3 non-SD/MSP Party C
non-
PartyD SD/MSP TRUE Party4 non-SD/MSP FALSE Party D
non-
PartyE SD/MSP TRUE TRUE Party5 non-SD/MSP TRUE FALSE Party E
non- FALS
PartyF SD/MSP E TRUE Party6 non-SD/MSP FALSE FALSE Party F
PartyG MSP Party7 SD Party 7
non-
PartyH SD/MSP Party8 SD Party 8
non-
PartyI SD/MSP Party9 MSP Party 9
non- FALS
PartyJ SD/MSP E Party10 non-SD/MSP TRUE Party 10
non-
PartyK SD/MSP TRUE FALSE Party11 non-SD/MSP TRUE TRUE Party 11
non- FALS
PartyL SD/MSP E FALSE Party12 non-SD/MSP FALSE TRUE Party 12
PartyM SD Party13 SD
PartyN MSP Party14 MSP
non- Tie Breaker
PartyO SD/MSP TRUE TRUE Party15 non-SD/MSP TRUE TRUE
non- FALS
PartyP SD/MSP E FALSE Party16 non-SD/MSP FALSE FALSE

Identifier
Page 34
7.1.4 CMRS RegReport Setup

Below is an example of configuration settings for applying RPD rules in
CMRS RegReport:
Figure 7-9: Legal Entity Setup for RPD Rule
Similarly, these attributes should be configured for Counterparty also.
Figure 7-10: Counterparty Setup for RPD Rule

Identifier
Page 35

Based upon the static data configured in CMRS RegReport, CMRS
RegReport determines the reporting party. The screenshots of the trade
status on T&T for the scenarios, where CMRS RegReport is ‘Reporting
Party’ and CMRS RegReport is not ‘Reporting Party’ are presented below:
• When CMRS RegReport determines it to be the ‘Reporting Party’,

then it reports the message associated.

Identifier
Page 36
Figure 7-11: Track & Trace Screen - CMRS RegReport as Reporting Party
• When CMRS RegReport determines it to be the ‘Non-Reporting

Party’, then it ignores the trade.
Figure 7-12: Track & Trace Screen - CMRS RegReport as Non-Reporting Party

Identifier
Page 37
7.1.6 RPD on Tie Breaker

If CMRS RegReport is not able to identify the reporting party based on the
static configurations of the parties in the system, then Tie breaker rules
are applied.
The tie breaker rule depends on the following:
• Outcome of Buyer/Seller determination rule (covered in detail later).

• Asset Class
• Product
7.1.6.1 Interest Rate

The following table shows the Tie breaker rule for the various products
under the Interest Rate Asset Class:
Product Reporting Rule

Cap Floor <Buyer> is the RP
FRA, Swaption,
<Buyer> is the RP
Debt Option
Inflation Swap <Seller> is the RP
IRS Fix Float, XCCY
<Seller> is the RP
Fix Float, OIS
IRS Basis, IRS Fix-
Fix, XCCY Basis,
<Seller> is the RP
XCCY Fix-Fix,
Exotic
7.1.6.2 Foreign Exchange

under FX Asset Class (Table 6).

Swap <Seller> is RP
Forward <Seller> is RP
NDF <Seller> is RP
Options <Seller> is RP
NDO <Seller> is RP
Simple Exotic <Seller> is RP
Complex Exotic <Seller> is RP
7.1.6.3 Credit
under Credit Asset Class.

Identifier
Page 38

CDX Swaption and
<Seller> is RP
CDS Swaption
All Others <Buyer> is RP
7.1.6.4 Commodity
under Commodity Asset Class.

Fixed Floating
<Seller> is RP
Swap
Option/Swaption <Seller> is RP
Forward, Generic
and All other <Seller> is RP
products
7.1.6.5 Equity
under Equity Asset Class.

All <Seller> is RP
The above Tie-Breaker Logic is not applicable for ICE Trade

Vault. Any deal reportable to ICE reaching the tie-breaker will
NOTE be failed in CMRS RegReport.
7.1.7 RPD for ICE TR

Reporting Party Determination rule will run for each new deal flowing into
CMRS RegReport to determine which party needs to report the trade to
the TR. If counterparty is reporting party and the trade is double sided, the
deal will still flow to ICE with USSDRREPORTABLETRADE as ‘N’. CMRS
RegReport will not generate USI in this case and will send the trade to ICE
with blank USI. USI will be pass-through if this value is coming from SS.
CMRS RegReport will support RPD Override from Source System and UI for
ICE.
RPD on Tie breaker

Identifier
Page 39
will not be applied and the deal will be failed.
RPD
Result Single Sided Result
LE Y or blank Report
LE N Report
CP Y or blank Ignore
CP N Report
Tie
Breaker Y or blank Fail
Tie
Breaker N Fail
7.2 RPD Rule for Canadian Reporting

the TR. If RPD is counterparty, the deal gets ignored at the deal processing
stage.
DTCC CA. If No information is available from the Source System or the UI,
CMRS RegReport will use the below logic to determine the Reporting Party.
Refer to the following ‘Reporting Party’ flowchart as defined by Depository
Trust & Clearing Corporation (DTCC) for Canadian Regulation:

Identifier
Page 40
Figure 7-7: Canadian Reporting Party Determination Flowchart
Below are few examples:
Legal Entity Counterparty

D LE CFTC Pr CFI Lo D CP CFTC Pr CFI Loc
ea rep Organiz ovi ca ea rep Organiz ovi al Repor
le ort ation nc l le ort ation nc ting
r abl type e r abl type e Party
e to e to
CFT CFT
C C
Ye No N/A An N/A N/ Ye No N/A An N/A N/A Tie
s y A s y breaker
Ye No N/A An N/A N/ Ye Yes N/A An N/A N/A Tie

Identifier
Page 41
s y A s y breaker
Ye Yes N/A An N/A N/ Ye No N/A An N/A N/A Tie
s y A s y breaker
Ye Yes SD An N/A N/ Ye Yes SD An N/A N/A Tie
s y A s y breaker
Ye Yes SD An N/A N/ Ye Yes MSP An N/A N/A LE
s y A s y
Ye Yes SD An N/A N/ Ye Yes Non- An N/A N/A LE
s y A s SD/MSP y
Ye Yes MSP An N/A N/ Ye Yes MSP An N/A N/A Tie
s y A s y breaker
Ye Yes MSP An N/A N/ Ye Yes Non- An N/A N/A LE
s y A s SD/MSP y
Ye Yes MSP An N/A N/ Ye Yes SD An N/A N/A CP
s y A s y
Ye Yes Non- An N/A N/ Ye Yes Non- An N/A N/A Tie
s SD/MSP y A s SD/MSP y breaker
Ye Yes Non- An N/A N/ Ye Yes SD An N/A N/A CP
s SD/MSP y A s y
Ye Yes Non- An N/A N/ Ye Yes MSP An N/A N/A CP
s SD/MSP y A s y
Ye N/A N/A An N/A N/ No N/A N/A An N/A N/A LE
s y A y
No N/A N/A An N/A N/ Ye N/A N/A An N/A N/A CP
y A s y
No N/A N/A An N/A Ye No N/A N/A An N/A No LE
y s y
pro pro
vin vin
ce ce
exc exc
ept ept
AM AM
F/M F/M
SC SC
No N/A N/A An N/A Ye No N/A N/A An N/A Yes Tie
y s y breaker
pro pro
vin vin
ce ce
exc exc
ept ept
AM AM
F/M F/M
SC SC
No N/A N/A An N/A No No N/A N/A An N/A No Tie
y y breaker
pro pro
vin vin
ce ce
exc exc
ept ept
AM AM
F/M F/M
SC SC
No N/A N/A An N/A No No N/A N/A An N/A Yes CP
y y
pro pro
vin vin
ce ce
exc exc
ept ept
AM AM
F/M F/M
Identifier
Page 42
SC SC
No N/A N/A AM Yes N/ No N/A N/A AM No N/A LE
F/M A F/M
SC SC
No N/A N/A AM No N/ No N/A N/A AM Yes N/A CP
F/M A F/M
SC SC
No N/A N/A AM Yes Ye No N/A N/A AM Yes No LE
F/M s F/M
SC SC
No N/A N/A AM Yes Ye No N/A N/A AM Yes Yes Tie
F/M s F/M breaker
SC SC
No N/A N/A AM Yes No No N/A N/A AM Yes No Tie
F/M F/M breaker
SC SC
No N/A N/A AM Yes No No N/A N/A AM Yes Yes CP
F/M F/M
SC SC
No N/A N/A AM No Ye No N/A N/A AM No No LE
F/M s F/M
SC SC
No N/A N/A AM No Ye No N/A N/A AM No Yes Tie
F/M s F/M breaker
SC SC
No N/A N/A AM No No No N/A N/A AM No No Tie
F/M F/M breaker
SC SC
No N/A N/A AM No No No N/A N/A AM No Yes CP
F/M F/M
SC SC
RPD on Tie Breaker

will be applied to determine the reporting party which is in turn based on
determination of buyer/seller of a trade.(Section 8.1.6)
7.2.1 CMRS RegReport Setup

Below is an example of configuration settings for applying RPD rules in
CMRS RegReport:

Identifier
Page 43
Figure 7-8: Legal Entity Setup for Canada RPD Rule
Similarly, these attributes should be configured for Counterparty also.
Figure 7-9: Counterparty Setup for Canada RPD Rule

Identifier
Page 44
7.3 RPD Rule for PTT Reporting

the TR. If RPD is counterparty, the deal gets ignored at the deal processing
stage.
MiFID II PTT. If No information is available from the Source System or the
UI, CMRS RegReport will use the below logic to determine the Reporting
Party. Refer to the following steps:
Step 1. MiFID investment Firm:

i. If only one of the two firm is MiFID Investment firm-
MiFID Investment Firm to report
ii. Else – Decision would be on the basis of SI (move to
Step 2)
Step 2. Systematic Internalizer:
i. If only one of the two firm is Systematic Internalizer-
Systematic Internalizer to report
ii. Else – Decision would be on the basis of Seller (move to
Step 3)
Step 3. Seller in the trade will report
Systematic Internalizer: Y – LE is the SI; N- CP is the SI; Both – Both are

SIs OR Blank –None is SI
Is LE Is CP
S.N Is Systematic Buy Sell
Investment Investment Result
o. Internalizer Indicator
Firm? Firm?
1. Y/1/TRUE/YES <Blank> NA NA ReportingParty
Non_ReportingPart
2. <Blank> Y/1/TRUE/YES NA NA
y
Rp_Un_Determine
3. <Junk Value> <Blank> NA NA
d
Rp_Un_Determine
4. <Blank> <Junk Value> NA NA
d
Rp_Un_Determine
5. <Junk Value> <Junk Value> NA NA
d

Identifier
Page 45
6. <Blank> <Blank> Y/1/TRUE/YES NA ReportingParty
Non_ReportingPart
7. <Blank> <Blank> N/0/FALSE/NO NA
y
8. Y/1/TRUE/YES Y/1/TRUE/YES Y/1/TRUE/YES NA ReportingParty
Non_ReportingPart
9. Y/1/TRUE/YES Y/1/TRUE/YES N/0/FALSE/NO NA
y
Non_ReportingPart
10. Y/1/TRUE/YES Y/1/TRUE/YES <blank> B
y
11. Y/1/TRUE/YES Y/1/TRUE/YES <blank> S ReportingParty
Non_ReportingPart
12. Y/1/TRUE/YES Y/1/TRUE/YES Both B
y
13. Y/1/TRUE/YES Y/1/TRUE/YES Both S ReportingParty
Rp_Un_Determine
14. Y/1/TRUE/YES Y/1/TRUE/YES <Junk Value> NA
d
<Junk Rp_Un_Determine
15. Y/1/TRUE/YES Y/1/TRUE/YES <blank>/ both
Value> d
16. Y/1/TRUE/YES N/0/FALSE/NO NA NA ReportingParty
Non_ReportingPart
17. N/0/FALSE/NO Y/1/TRUE/YES NA NA
y
18. N/0/FALSE/NO N/0/FALSE/NO Y/1/TRUE/YES NA ReportingParty
Non_ReportingPart
19. N/0/FALSE/NO N/0/FALSE/NO N/0/FALSE/NO NA
y
<blank>/<both Non_ReportingPart
20. N/0/FALSE/NO N/0/FALSE/NO B
> y
<blank>/<both
21. N/0/FALSE/NO N/0/FALSE/NO S ReportingParty
>

Identifier
Page 46
8Rerun RPD RULE

Trades can be amended by changing its direction from buy to sell or vice
versa where the trade economics remains the same but the Buyer and
Seller of the transaction changes. CMRS RegReport can compute the
Reporting party by using the buyer/seller information of a trade and
currently, it only determines the reporting party once when the deal is
coming in CMRS RegReport for the first time. Once Reporting Party status
is determined, it cannot be changed or modified.
Since, the buy/sell direction can change anytime during the lifecycle of the
trade, CMRS RegReport should have provision to re-determine the
Reporting party every time this change happens.
This can be done in CMRS RegReport via Source System or from CMRS
RegReport UI.
From Source System
A new field is added to CMRS RegReport Interim and ScML called

“RerunRPD” such that
 This field will be used by CMRS RegReport to determine if Reporting

Party for a trade needs to be re-calculated.
 Valid Values – True / False / Blank – Blank being same as FALSE
 Invalid Values – deals will be failed.
 To be populated and sent from Source System
Scenarios:
Dea Event ReRu RPD Result Comm

l ID nRPD ? ents
SS
Flag
101 TRADE N/A RP CMRS RegReport will process the
trade
101 TRUE RP CMRS RegReport to continue
SNAPSH processing the trade
OT/TRAD
E
NRP CMRS RegReport will ignore the CMRS
trade* RegRep
ort will
not
auto
cancel
Identifier
Page 47

l ID nRPD ? ents
SS
Flag
the USI.
102 TRADE N/A NRP CMRS RegReport will ignore the
trade
102 SNAPSH TRUE NRP CMRS RegReport will ignore the
OT/TRAD trade
E
RP CMRS RegReport will start
reporting the trade and will
generate the USI if needed
103 TRADE N/A RP CMRS RegReport will process the
trade
103 AMEND TRUE RP CMRS RegReport will continue to
report the trade
NRP CMRS RegReport will ignore this
event and any subsequent event
that flows for this trade.
trade
104 AMEND TRUE NRP CMRS RegReport will continue to
ignore the trade
RP CMRS RegReport will report this
event if SS USI present. A NACK is
expected from TR as this position
is not open with the TR.
Subsequent Snapshot will open
position with the TR for this deal.
Nack will need to be marked
resolved manually in CMRS
RegReport. Any non PO received
after this Amend and before
Snapshot will continue to process
in CMRS RegReport with SS USI.
104 SNAPSH N/A RP CMRS RegReport will report the
OT trade with SS USI.
trade
105 AMEND TRUE NRP CMRS RegReport will continue to
ignore the trade
RP CMRS RegReport will fail this
event if SS USI not present due to
USI lookup failure. CMRS
RegReport will not generate USI if
it’s blank. Subsequent Snapshot
will open position and create USI
Identifier
Page 48

l ID nRPD ? ents
SS
Flag
for this deal in CMRS RegReport.
Failure will need to be marked
resolved manually in CMRS
RegReport. Any non PO received
after this Amend and before
Snapshot will fail in CMRS
RegReport due to USI look up
failure.
105 SNAPSH N/A RP CMRS RegReport will report the
OT trade with CMRS RegReport
generated USI.
 CMRS RegReport will support ReRunRPD flag only for Dodd Frank (DTCC
US and CME SDR) and Canadian regulations (DTCC CA).
 CMRS RegReport expects the information informing CMRS RegReport to
ReRunRPD to flow as part of “SNAPSHOT” , “TRADE” and “AMEND”
events only (along with their Affiliate events) and will be ignored for all
other events.
 Internal Trades will still be ignored for reporting and Re-run RPD will
have no impact on such trades.
From CMRS RegReport UI
 A button will be provided on the Deal UID Map screen which when
clicked after selecting a deal will change the RPD status for DF and
Canadian regulations for a deal as ReRun RPD.
 Any subsequent event/reprocessing will trigger CMRS RegReport to re-
compute the RPD status and process the trade as per the newly
determined RPD status.

Identifier
Page 49
9ERE Rule
What is meant by ERE?
ERE means the External Reporting Entities. A trade, which either involves
SEF or DCO, the reporting obligation lies with those entities and the
parties involved in the trade will not have to report the trade data.
The External Reporting Entities supported by CMRS RegReport are SEF/

Designated contract market (DCM’s) or DCO’s.
9.1 ERE Rule (DF and CSA Only)

If the trade is not Ignored and passes the above rules, then ERE Rules are
applied to identify, whether there is any external reporting entity involved
or not. The scenarios are presented in following table:
Originati Execution ClearingDCO REPORT/IGN

ng Event Venue value ORE for CSA
Any Event Off-Facility BLANK REPORT**
Position IGNORE
Opener
Other
than
Snapshot Off-Facility DCO
Position REPORT
Opener
Other
than
Snapshot SEF BLANK
Position IGNORE
Opener
Other
than
Snapshot SEF DCO
Snapshot Off-Facility DCO IGNORE
Snapshot SEF BLANK REPORT
Snapshot SEF DCO IGNORE
Valuation Off-Facility DCO REPORT**
Valuation SEF BLANK REPORT**
Valuation SEF DCO REPORT**
Other IGNORE
events Off-Facility DCO
Other
events SEF BLANK REPORT**
Identifier
Page 50
Originati Execution ClearingDCO REPORT/IGN

ng Event Venue value ORE for CSA
Other IGNORE
events SEF DCO
REPORT means all the messages associated with this event

will be reported by CMRS RegReport.
To refer to the events and messages association, please refer
NOTE to the Event Message mapping under Admin Data Setup.
ERE Rule for DF:
Originating Execution IntentToClear ClearingDCO REPORT/IGNORE for

Event Venue value DF
Any Event Off-Facility False/Blank BLANK REPORT
Position
Opener Other Off-Facility True DCO IGNORE
than Snapshot
Position
Opener Other SEF True BLANK IGNORE
than Snapshot
Position
Opener Other SEF True DCO IGNORE
than Snapshot
Position REPORT (CONFIRM

Opener Off- message should be
True BLANK
Other than Facility suppressed, if
Snapshot associated)
Snapshot Off-Facility True DCO IGNORE

Identifier
Page 51
Originating Execution IntentToClear ClearingDCO REPORT/IGNORE for

Event Venue value DF
Snapshot SEF False/Blank BLANK REPORT
Snapshot SEF True DCO IGNORE
REPORT (CONFIRM
Off- message should be
Snapshot True BLANK
Facility suppressed, if
associated)
Snapshot SEF True BLANK IGNORE
Other events Off-Facility True DCO IGNORE
Other events SEF False BLANK REPORT
Other events SEF True DCO IGNORE
Other events SEF True BLANK IGNORE
Other events Off-Facility True BLANK IGNORE

Identifier
Page 52
9.1.1 Source File Configurations

9.1.2 Scenarios and Ignore messages
9.1.2.1 Trade Executed on SEF and Not
Cleared
In order to indicate a deal to CMRS RegReport, which is executed on SEF
and not cleared, we need the following details in the input file:
‘TradeExecutionVenueType’ should contain ‘SEF’, & ‘ClearingDCOValue’

needs to be BLANK.
The snapshot for the input file indicating the execution facility as SEF and
Clearing DCO as BLANK is presented in Fig. 15.
Figure 9-13: Execution Facility - SEF and ClearingDCOValue - BLANK
When this trade flows into CMRS RegReport, the trade is Ignored and the
ignore message is displayed on T&T screen.
Figure 9-14: Track & Trace Screen - Message Ignored

Identifier
Page 53
9.1.2.2 Trade Executed on SEF and DCO

Cleared
In order to indicate a deal to CMRS RegReport, which executed on SEF and
DCO cleared, we need the following details in the input file:
‘TradeExecutionVenueType’ should contain ‘SEF’, & ‘ClearingDCOValue’

should contain ‘DCO’. The following figure displays the input file indicating
the execution facility as SEF and ClearingDCOValue as DCO.
Figure 9-15: Execution Facility - SEF & Clearing Value - DCO
When this trade flows into CMRS RegReport, the trade is ignored and the
Ignore message is displayed on T&T screen.
Figure 9-16: Track & Trace – Message Ignored

Identifier
Page 54
9.1.2.3 Trade Executed Off-Facility and Not

Cleared
In order to indicate a deal to CMRS RegReport, which is executed Off-
Facility and not cleared, we need the following details in the input file:
‘TradeExecutionVenueType’ should contain ‘Off-Facility’, &

‘ClearingDCOValue’ should be BLANK. Below specified is the snapshot for
the input file indicating the execution facility as Off-Facility and
ClearingDCOValue as BLANK.
Figure 9-17: Execution facility as Off-Facility and ClearingDCOValue as BLANK

Identifier
Page 55
When this trade flows into CMRS RegReport, the trade is successfully
processed and the associated messages are generated and sent to SDR.
This behavior can be viewed on T&T screen as presented.
Figure 9-18: Trade executed Off-Facility and not cleared

Identifier
Page 56
9.1.2.4 Trade executed Off-Facility and DCO

cleared
In order to indicate a deal to CMRS RegReport, which is executed Off-
Facility and DCO cleared, we need the following details in the input file:
‘TradeExecutionVenueType’ should contain ‘Off-Facility’, &

‘ClearingDCOValue’ should contain ‘DCO’.
Below mentioned is the snapshot for the input file indicating the execution
facility as Off-Facility and ClearingDCOValue as DCO:
Figure 9-19: Indicating execution facility as Off-Facility and ClearingDCOValue as DCO
When this trade flows into CMRS RegReport, the trade is Ignored and
ignore message is displayed on the T&T screen.
Figure 9-20: Track & Trace Screen; Deal View - Deal Processed

Identifier
Page 57
9.1.2.5 ERE for ICE-TR

If the trade is executed on a SEF, then CMRS RegReport ignores the
position opener event and reports any non-position opener/valuation
event including the snapshot event. If the trade is double sided, this
behavior will change for ICE and CMRS RegReport will now send the
position opener event to ICE with USSDRREPORTABLETRADE as ‘N’.CMRS
RegReport will not generate the USI in such scenario but will pass-through
the USI if coming from the source system.If the trade is cleared by a DCO,
then CMRS RegReport ignores all the events (position opener as well as
non-position opener events) excluding the valuation event. If the trade is
double sided, this behavior will change for ICE and CMRS RegReport will
now send the all events to ICE with USSDRREPORTABLETRADE as ‘N’.CMRS
RegReport will not generate the USI in such scenario but will pass-through
the USI if coming from the source system.
ERE Event Single Sided Result

SEF PO Y or blank Ignore
SEF NPO Y or blank Report
SEF PO N Report
SEF NPO N Report
DCO PO+NPO Y or blank Ignore
DCO Valuation Y or blank Report
DCO PO+NPO N Report
DCO Valuation N Report

Identifier
Page 58
9.2 ERE Rule (MiFD-II Post Trade

Transparency)
For MiFID II Post-trade reporting, if the trade has been executed on a
Trading venue, then Trading Venue should report the trade. CMRS will
ignore the Post trade reporting of such trades.
Originating Event Execution Venue REPORT/IGNORE for MiFID II

Any Event SEF/Trading Venue with a MIC IGNORE
code
Any Event OFF-Facility (XOFF/SINT) REPORT

Identifier
Page 59
10 Snapshot Event Switch Rule

• Snapshot event is used to report the EOD status of the trade.
• In REGIS and UnaVista, the new trade and the further updates on
the trade are reported via different messages. As the Snapshot
event can contain a new trade and as well as an existing trade,
CMRS RegReport needs to be enhanced to distinguish between
existing and new trades and report accordingly.
• SNAPSHOT/AFFILIATE_SNAPSHOT event will be changed to
SNAPSHOT_TRADE or SNAPSHOT_MODIFY depending upon the below
logic for REGIS and UnaVista:
Switch to
SNAPSHOT_TRADE
event
No
CMRS Checks if
Snapshot event
UTI/Interim UTI
received by CMRS
exists
Yes SWITCH TO
SNAPSHOT_MODIFY
Event
• Since ICE supports reporting for both Dodd Frank and EMIR, the
snapshot event switch rule execution in CMRS RegReport is as
follows:
Originati Reportabl
USI Exists UTI exists Output Event
ng Event e to?
SNAPSHO
BOTH N N SNAPSHOT_TRADE
T
SNAPSHO
BOTH Y N FAIL
T
SNAPSHO
BOTH N Y FAIL
T
SNAPSHO SNAPSHOT_MODIF
BOTH Y Y
T Y
SNAPSHO
DF N N/A SNAPSHOT_TRADE
T
DF Y N/A
T Y

Identifier
Page 60
Originati Reportabl
USI Exists UTI exists Output Event
ng Event e to?
SNAPSHO
EMIR N/A N SNAPSHOT_TRADE
T
EMIR N/A Y
T Y
• The Snapshot Event switch rule execution for DTCCEU and

DTCCEULITE is as below :
Action ACK/WACK
GTR Field
Type? Reprocessing
CMRSLook up in
gReprocessin
ReportedAction Type
TR Response
switched to
Trade ID
form SS
Event
Event
Comments
Name
10 N
N ACK
TRADE 1 N A NA NA
ACK/WACK is not
SNAPSH present, Snapshot
N ACK
10 N OT_TRAD Event switching take
SNAPSHOT 8 N A NA E place.
10 N
ACK
AMEND 1 M A NA NA M
CORPORATE 10 N
ACK
ACTION 5 O A NA NA O
COMPRESSIO 10 N
ACK
N 8 Z A NA NA Z
TERMINATIO 10 N
ACK
N 2 C A NA NA C
TRADE_CANC 10 N
ACK
EL 4 E A NA NA E
20 N
N ACK
TRADE 1 A N NA NA

Identifier
Page 61
Action ACK/WACK
GTR Field
Type? Reprocessing
gReprocessin
CMRSLook up in
ReportedAction Type
TR Response
switched to
Trade ID
form SS
Event
Event
Comments
Name
ACK/WACK is not
N ACK
SNAPSHOT 8 A N NA E place.
20 N
ACK
AMEND 1 A M NA NA M
CORPORATE 20 N
ACK
ACTION 5 A M NA NA M
COMPRESSIO 20 N
ACK
N 8 A Z NA NA Z
TERMINATIO 20 N
ACK
N 2 A C NA NA C
TRADE_CANC 20 N
ACK
EL 4 A E NA NA E
TR does not allow
NAC
10 N ACK/ N Action Type "N" to be
K
TRADE 1 N A WACK AMEND reported again
SNAPSH TR does not allow
NAC
10 N ACK/ OT_MODI N Action Type "N" to be
K
SNAPSHOT 8 N A WACK FY reported again
COMPRESSIO 10 N ACK/
ACK
N 8 Z A WACK NA Z
TERMINATIO 10 N ACK/
ACK
N 2 C A WACK NA C
TRADE_CANC 10 N ACK/
ACK
EL 4 E A WACK NA E
PARTIAL_TER 10 N ACK/
ACK
MINATION 3 O A WACK NA O
AMEND_CON 10 N ACK/
ACK
FIRM 1 M A WACK NA M
20 N ACK/ Event switched in
ACK
TRADE 1 A N WACK AMEND M reprocessing
SNAPSH
20 N ACK/ OT_MODI ACK Event switched in
SNAPSHOT 8 A N WACK FY M reprocessing
COMPRESSIO 20 N ACK/
ACK
N 8 A Z WACK NA Z
TERMINATIO 20 N ACK/
ACK
N 2 A C WACK NA C
TRADE_CANC 20 N ACK/
ACK
EL 4 A E WACK NA E
20 N ACK/
ACK
AMEND 1 A M WACK NA M
30 N
ACK
TRADE 1 N A NACK NA N
ACK/WACK is not
ACK
SNAPSHOT 8 A N NACK E N place.

Identifier
Page 62
Action ACK/WACK
GTR Field
Type? Reprocessing
gReprocessin
CMRSLook up in
ReportedAction Type
TR Response
switched to
Trade ID
form SS
Event
Event
Comments
Name
SNAPSH ACK/WACK is present,

30 N OT_MODI ACK Snapshot Event
SNAPSHOT 8 O A NACK FY O switching take place.
COMPRESSIO 30 N
ACK
N 8 Z A NACK NA Z
TERMINATIO 30 N
ACK
N 3 A C NACK NA C
TRADE_CANC 30 N
ACK
EL 4 A E NACK NA E
30 N
ACK
AMEND 1 A M NACK NA M

Identifier
11 ETD_POSITION_TRADE Rule
(EMIR Only)
• ETD_POSITION_TRADE event is used to report the position status of
a new or existing ETD trade.
• In REGIS and ICE, the new trade is reported with a particular
message and the further updates are reported with another
message. As this event can contain a new trade and as well as an
existing trade, CMRS RegReport needs to be enhanced to distinguish
between existing and new trades and report accordingly.
• ETD_POSITION_TRADE /AFFILIATE_ETD_POSITION_TRADE event will
be changed to ETD_POSITION_MODIFY or not depending upon the
below logic:-
12 Interim UTI Rule (EMIR Only)
• UNAVISTA requires parties to report New Trades using an interim
Trade ID should they do not have a UTI (Unique Trade ID) available
upon reporting. The UTI (unique trade ID) may later be reported at a
later stage. Once the UTI is reported, any other transactions and
messages reported over that trade will need to be referred to that
UTI.
• When CMRS RegReport does not receives the UTI from the source
system and CMRS RegReport is not to generate the UTI for the
trade, CMRS RegReport will generate an interim UTI and report to
UNAVISTA.
• CMRS RegReport will report UTI Namespace (look up UTI name

space) +Deal ID as Interim UTI.
• Any deal flowing to CMRS RegReport with any event will need to go
through the below check:
13 Buyer/Seller Identifier Rule
The purpose of Buyer/Seller determination rule is to determine the ‘Seller’
in the trade. The rule is based on ISDA guidelines and is dependent on the
asset class and product.
13.1 Interest Rate

under the Interest Rate Asset Class.
Party coming in <Buyer> is the buyer,
Cap Floor If <buyer> doesn’t have a value apply reverse
ASCII sort to identify the buyer
FRA, Swaption, Debt Party coming in <Buyer> is the buyer ,
Option If <Buyer> not found throw exception.
Inflation Swap <leg1payer> + <fixedRate_Initial_leg1>.
If fixedrate_initial_leg1 has value, then
leg1payer is the seller
If fixedrate_initial_leg1 is blank, and if
fixedrate_initial_leg2 has value, then
If payer is not identified from the above
steps, then apply Reverse ASCII sort to
identify the seller
IRS Fix Float, XCCY Fix
<leg1payer> + <fixedRate_Initial_leg1>.
Float, OIS
If fixedrate_initial_leg1 has value, then
If fixedrate_initial_leg1 is blank, and if
fixedrate_initial_leg2 has value, then
If payer is not identified from the above
steps, then throw an exception
IRS Basis, IRS Fix-Fix,
XCCY Basis, XCCY Fix- Reverse ASCII sort to identify the seller
Fix, Exotic
Swap (for Interim if (fixedRate_Initial_leg1 and fixedRate_Initial_leg2)
Taxonomy) are not blank then
Reverse ASCII
else if (fixedRate_Initial_leg1 and
fixedRate_Initial_leg2) are blank then
Reverse ASCII
else if (<leg1payer> + <fixedRate_Initial_leg1>
** If fixedrate_initial_leg1 has value, then take leg1payer
** If fixedrate_initial_leg1 is blank, then check if
fixedrate_initial_leg2 has value, then take leg2payer
If payer not identified from above steps, then throw an error
for ‘TIE Breaker failure’
13.2 Foreign Exchange

under FX Asset Class (Table 6

Swap Forward-Far Leg:
If <ExchangedCurrency1> comes first
alphabetically against <ExchangedCurrency2>
THEN the party coming in
<ExchangedCurrency1PayerValue> will be
seller.
ELSE the party coming in
seller.
Forward-Near Leg: (Reverse of Far Leg)
seller.
seller.
Forward THEN the party coming in
seller.
seller.
NDF THEN the party coming in
seller.
seller.
Options The party coming in OptnSellerValue will be
seller.
The party coming in OptnSellerValue will be
NDO
seller.
Simple Exotic
seller.
seller.
If OptnSellerValue is blank THEN
<ExchangedCurrency1> comes first
Complex Exotic
seller,
<ExchangedCurrency2PayerValue> will seller.
Spot If Swap Leg =’F’
seller.
seller.
If Swap Leg =’N’
seller.
seller.
13.3 Credit
under Credit Asset Class.

CDX Swaption and ‘UnderlyingFloatRatePayerSeller’ is the
CDS Swaption Seller.
All Others <BuyerLEIvalue> is buyer
13.4 Commodity
Fixed Floating Swap <FixLgFixRateReceiverSeller> is the seller
<OptnPrtyReceiverRefReceiverofthePremiu
Option/Swaption
m> is the seller
Forward, Generic and
ASCII sort in ASCENDING Order identifies the seller
All other products
13.5 Equity
The following table shows how to identify the seller for the various
products under Equity Asset Class.

All Party coming as <SellerValue> is seller.
14 Delegated Message
Suppression Rule (EMIR ,ASIC
and BOI Only)
As reporting obligations can be delegated from one party to another,
CMRS RegReport supports delegation as below
1. If No Delegation i.e. independent Reporting – both the parties report

their side of the trade
2. If Delegation is there i.e. the delegated party reports 2 messages, 1
reporting the party1 side of the trade and the other reporting the
party2 side of the trade.
This rule is applicable as follows:
• Unavista
• CME ETR
• ICE (only Collateral and Valuation)
As listed below are the delegation scenarios supported by CMRS

RegReport
• For all Counterparty categories, below delegation models are

applicable:
1. Full Delegation to Counterparty
2. No delegation
3. Full Delegation by Counterparty
• For all Additional Entities , below delegation models are applicable:
1. Full Delegation to ERE
2. No delegation
• The following scenarios are applicable for UnaVista and CME:
Scenario CMRS RegReport Messages to be

Action Filtered
Full Delegation By LE to Filter all reporting All messages
CP [CMRS RegReport is at
LE]
Full Delegation By CP to Reports both the None
LE [CMRS RegReport is at messages associated
LE] with the event. CMRS
RegReport reports 2
messages in this
delegation type one from
LE side and the other
Scenario CMRS RegReport Messages to be
Action Filtered
form CP side.
Independent [CMRS Reports only one Delegated
RegReport is at LE] message and ignore the messages i.e.
other delegated one. Trade_Delegated
and
Position_Delegate
d
Full Delegation By LE to Filter all reporting All messages
ERE [CMRS RegReport is
at LE]
Full Delegation by CP to Filter all reporting All messages
LE and further LE to ERE
Full Delegation by CP to Reports both the None
LE and further LE to ERE messages associated
[CMRS RegReport is at with the event. CMRS
ERE] RegReport reports 2
messages in this
delegation type one from
LE side and the other
form CP side.
• Below Scenarios are applicable for ICE Valuation Messages:
Messages To Be Sent
SUBMIT
Reportab
Originatin Reportabl Delegati VALUATI
le to
g Event e to DF on SUBMI SUBMITV ONEU_D
EMIR
TVALU ALUATIO ELEGAT
ATION NEU ED
VALUATIO
N Y N None Y N N
VALUATIO
N N Y None N Y N
VALUATIO
N N Y CP to LE N Y Y
VALUATIO
N N Y LE to CP N N N
VALUATIO
N Y Y None Y Y N
VALUATIO
N Y Y CP to LE Y Y Y
• Below Scenarios are applicable for ICE Collateral Messages:

Reporta Messages To Be Sent
Originating Delegati
ble to COLLATE
Event on
EMIR RAL COLLATERAL_DELEGATED
COLLATERA
L Y None Y N
COLLATERA
L Y CP to LE Y Y
COLLATERA
L Y LE to CP N N
14.1 Workflow
Based upon the ‘EMIRReportingDelegation’ flag, CMRS RegReport will
determine when to report 2 messages for a trade and when to report a
single message.
The flow works as described below
If (EMIRReportabilityStatus = ‘INDEPENDENT’)
Ignore the Delegated message i.e. Trade_Delegated and

Position_Delegated
Else if (EMIRReportabilityStatus = ‘FULL’)
Report both the messages associated with the event
Same workflow will be used for ‘ASICReportingDelegation’ flag.

CMRS RegReport will determine when to report 2 messages for a trade
and when to report a single message.
The flow works as described below
If (ASICReportabilityStatus = ‘INDEPENDENT’)
Ignore the Delegated message i.e. Trade_Delegated and

Position_Delegated
Else if (ASICReportabilityStatus = ‘FULL’)
}
15 USI/Prior USI Rule (DF, ASIC,
MAS, and CSA Only)
USI/Prior USI rule is responsible for the USI that is sent to the TRs. Every
trade sent to the TR and reporting under the CFTC jurisdiction needs to
send an USI which is essentially the identifier of the trade.
The USI can come in from the source system or CMRS RegReport can
generate the USI. In some special cases trade can be reported without an
USI and TR specific specifications are applied on the trade.
15.1 Workflow
The USI workflow is as follows:
1. If USI is coming from source system then the USI is used as is.
2. If USI is not coming from source system and ‘OurRef’ is present then
‘OurRef’ value is used as the USI.
‘OurRef’ is applicable only for FX asset class and when

Organization Type is non SD/MSP
NOTE
3. If USI is blank for above 2 scenarios and OriginatingTradeId is

present then the OriginatingTradeId is used to lookup the USI. If
lookup is successful then the looked USI is used otherwise the trade
is failed citing lookup failure
4. If USI is blank in the above 3 scenarios then CMRS RegReport
generates USI in the following case
a. CMRS RegReport has to report the trade
b. The originating event is a position opener
The following table depicts the normal workflow for USI scenarios. Special
case scenarios are not covered here and can be found in TR specific
documents
CMRS
Originati RPD Outp Report
Originati SS OurRe Trad to
ng Trade Resu ut ing
ng Event USI f e ID gener
ID lt USI Status
ate
SS
NA Y NA NA NA RP N Report
USI
SS
NA Y NA NA NA NRP N Ignore
USI
CMRS
ID lt USI Status
ate
OurR
NA N Y NA NA RP N Report
ef
OurR
NA N Y NA NA NRP N Ignore
ef
Y (lookup look
pass) ed
NA N N NA RP N Report
up
USI
Y (lookup look
pass) ed
NA N N NA NRP N Ignore
up
USI
Y (lookup blan
NA N N NA RP N Failed
failure) k
Y (lookup blan
NA N N NA NRP N Failed
failure) k
Y
look
(loo
ed
NA N N N kup RP N Report
up
pass
USI
)
Y
look
(loo
ed
NA N N N kup NRP N Ignore
up
pass
USI
)
Y
(loo
blan
NPO N N N kup RP N Failed
k
failu
re)
Y
(loo
blan
NPO N N N kup NRP N Failed
k
failu
re)
Y
gene
(loo
rate
PO N N N kup RP Y Report
d
failu
USI
re)
PO N N N Y NRP N blan Ignore
(loo k
kup
failu
CMRS
ID lt USI Status
ate
re)
* ‘OurRef’ is applicable only for FX asset class and when Organization Type
is non SD/MSP
16 Unique ID Creation by TR/APA
16.1 GTR Create Rule (DF Only)
When both parties to the trade are Non MSP/SD and LE is reportable per
RPD, DTCC expects to receive the text ‘GTRCREATE’ to come in as the USI.
DTCC then generates an USI and sends it back.
For ICE, in the above scenario, CMRS RegReport will create a USI and will
overwrite it with the USI created by ICE once it receives it.
16.2 Tradeweb TradeID Generated &

Shared by APA (MiFID-II PTT)
Trade ID will be unique for every trade and will be generated by Tradeweb
at the time of PO submission. Tradeweb will send the TradeID in the
Technical ACK of PO submission. CMRS is expected to persist the same
TradeID for future submission of PTE events such as Amend and Cancel.
Da De Event CMRS looking TradeID in TradeID in

y al up TradeID Message sent Message sent by
ID by CMRS TW
1 101 New Trade No NA TradeID1
2 101 Amend Yes TradeID1 TradeID1
3 101 Amend Yes TradeID1 TradeID1
4 101 Cancel Yes TradeID1 TradeID1
On CMRS screens, Tradeweb Trade ID would be represented under TIC

label.
17 TRN Generation for MiFID-II
Transaction Reporting
TRN (Transaction Reference Number) is an Identification number internal

to the executing firm that is unique for each transaction submitted by the
firm.
Position Opener Events–
If Value (sent by SS) in TransactionReferenceNumber field is blank

{
CMRS will generate a unique TRN using SQL sequence number function
}
Else
{
CMRS will extract the value sent by SS and use for reporting & future
event mapping purposes
}
Non Position Opener Events–
If TransactionReferenceNumber field is blank for Non Position Opener

Events
{
If combination of Deal ID, Asset Class and Source System of the
Trade exists in CMRS
{
CMRS will look up the related TRN and used the same for
reporting
}
Else
{
CMRS will fail the trade and not report it to Trax
}
}
Else
{
CMRS will pass-through this field.
}
Scenarios:
Deal ID, Asset

TRN
SS Class and
S. No. sent by CMRS Action
Event Source System
SS?
exists in CMRS?
Position
Openers
CMRS generates TRN
1 PO No N/A
for reporting
2 PO Yes N/A Use TRN for reporting
Non Position Openers
3 NPO Yes N/A Use TRN for reporting
CMRS will look up the
4 NPO No Yes related TRN and use
the same for reporting
5 NPO No No CMRS fails the trade
18 Mandatory Clearing Exemption
Rule (DF and CSA Only)
For certain OTC Derivatives, clearing of the trade is mandatory.
There are 2 exceptions to these
1. Exemption from Required Clearing for Inter-Affiliate Swaps

2. Exemption from Required Clearing for End Users
18.1 Exemption for Inter-Affiliate

Swaps
The Commodity Futures Trading Commission (CFTC) had issued a rule to
exempt swaps between certain affiliated entities within a corporate group
from the clearing requirement. The Commission permits affiliated
counterparties to elect not to clear a swap subject to the clearing
requirement if those counterparties are majority-owned affiliates whose
financial statements are included in the same consolidated financial
statements. In addition, both affiliated counterparties must elect not to
clear the swap. Each swap entered into by the affiliated counterparties
with unaffiliated counterparties must be cleared.
18.2 Exemption for End-Users

The Commodity Futures Trading Commission (CFTC) provides clearing
exemption for the swaps with End Users. Any Swap where either of the
party is End User, the swap is exempted from Clearing.
This information needs to flow from the source and accordingly this will be
incorporated in the FpML message being reported to be SDR.
18.3 Workflow
This is only applicable for RT, PET, CONFIRM, SNAPSHOT and hybrid
messages.
CMRS RegReport will compute if there is any Clearing Exemption based on

the Legal Entity and Counterparty configurations done in the system.
18.3.1.1 Exemption Computation

CMRS RegReport is able to identify if the deal is valid for an Exemption or
not. Each Legal Entity and Counterparty will be configured in system.
The attributes used in computing if exemption is valid or not are described

below
1. Mandatory Clearing Exemption for CP

2. Mandatory Clearing Exemption for LE
3. Is Affiliate result of CP
Scenarios
The possible scenarios around this requirement are as follows:
CP
LE
Mandat
Mandator
ory Is
Scenar y
LE Id CP Id Clearin Affilia Result
io No Clearing
g te
Exemptio
Exempti
n
on
1 LE10 False CP101 True True AFFILIATE EXEMPTION
1
2 LE10 False CP102 False True No exemption**
1
3 LE10 False CP103 True False END-USER
1 EXEMPTION on Party2
4 LE10 False CP104 False False No exemption**
1
5 LE10 True CP101 True True AFFILIATE EXEMPTION
2
6 LE10 True CP102 False True END-USER
7 LE10 True CP103 True False End User Exemption
2 on Party1 and End
User Exemption on
Party2
8 LE10 True CP104 False False END-USER
** When No Exemption, ClearingExceptionPartyPrefix and

ClearingExceptionPartyValue will be updated as <<BLANK>>
For Scenario No -7: Where both the exemptions are applicable, we need
to inform DTCC accordingly, so in this case we need to implement End
User Exemption for party1 and End User exemption for party2.
18.3.1.2 Exemption Override Rule
There is a field ‘ClearingExceptionPartyValue’ which can be used to

override the Exemption on the deal will indicate whether it is an Affiliate
exemption or End user exemption or No Exemption.
‘ClearingExceptionPartyValue’ can have following values
 For Affiliate Exemption – ‘AFFILIATEEXEMPTION’

 For End User Exemption – The values expected are:
o Valid trade party identifier (either ‘party1’ or ‘party2’)
 ‘NONE’ – This means that there is no exemption on the trade and
CMRS RegReport will not compute for exemption.
 ‘BOTH’ – This means that both the exemptions are applicable, here
we will implement End User exemption for party1 and Affiliate
exemption for party2.
 <<BLANK>> - If this field is blank, then CMRS RegReport will
compute the exemption as described above in section 15.3.1
If this field contains any value other than <<BLANK>>, CMRS RegReport
will assume there is an override of the exemption and CMRS RegReport
will not compute if this deal is valid for an exemption or not.
19 Suppress 43/45 (DF Only)
The requirement of this rule is to supress the part 43/part 45 reporting
based on the rules as defined for the different categories of parties. This
suppression can be identified on the counterparty level. The rule can be
understood as follows:
• If Counterparty has Suppress 43 checked, filter out RT message

(assumption: combo messages will not be filtered)
• If Counterparty has Suppress 45 checked, filter out everything other
than RT message (assumption: combo messages will be treated as
part 45 and filtered)
• If Counterparty has both Suppress 43 and Suppress 45 checked,
filter out everything except backload etc.
19.1 Workflow
If (Cpty has “Supp 43”) then {
Filter out RT message (assumption: hybrid messages will not be filtered)

}
If (Cpty has “Supp 45”) then {
Filter everything other than RT message (hybrid messages will be treated

as part 45 and filtered)}
If (Cpty has “Supp 43” & “Supp 45”) then {
Filter everything}
19.2 Counterparties Setup
20 RT Suppress for FX Forward (DF
Only)
FX forwards and FX Swap are not subject to real time reporting
requirements. As such DTCC accepts RT messages submitted for FX
forwards and FX Swaps.
20.1 Suppress Approach

 A message template with <Suppress> element is present.
 While message generation, FPML Processing service looks for the
value in Suppress.
 If Suppress element is available, the value is taken from the
element; else the value is defaulted to ‘False’.
 Message generation happens with suppress XSLT. Message delivery
is set to false.
 FPML Processing service posts a TNT message with Message
generation status as ‘Suppressed’.
 TNT Dashboard, Details View displays ‘<MessageName>-
Suppressed’ as the status.
20.2 Workflow
21 Originating Trade ID Scenario
This rule enables a lookup on the originating trade id for any non-position
opener event coming into CMRS RegReport with a new deal id and
previous deal id as originating trade id.
CMRS RegReport will look up first based on originating trade id if available

else on deal id.
Position opener events flowing to CMRS RegReport with originating trade

id will result in USI/UTI/ACER UTI/TRN/TIC look up based on originating
trade id and may result in failure.
22 UTI Generating Party
Determination Rule (EMIR, ASIC,
MAS and BOI Only)
UTI Generation Determination rule is responsible for the UTI that is sent to
the TRs. Every trade sent to the TR and reporting under the ESMA
jurisdiction needs to send an UTI which is essentially the identifier of the
trade.
The UTI can come in from the source system or CMRS RegReport can
generate the UTI. In some special cases trade can be reported without an
UTI and TR specific specifications are applied on the trade.
22.1 Workflow
There are 3 input fields which can be used in combination to override
UGD:
• ReportingDelegationModel
• MWexists
• UTIDelegation
Here is how the 3 fields work as part of the UGD rule:

ReportingD
MwExist UTIDelegatio
elegationM Result
s n
odel
CMRS RegReport to ignore
reporting and hence will
LE to CP/ERE N/A N/A skip UGD
CMRS RegReport to report
for both parties. UTI will
either come from source or
else CMRS RegReport to
CP to LE N N/A generate.
CMRS RegReport to report
for both parties. UTI will
either come from source or
else MW Exists rule is
CP to LE Y N/A applied (Section 21).
Run UGD to determine
which party needs to
generate UTI if not flowing
Independent N N from SS
ReportingD
MwExist UTIDelegatio
elegationM Result
s n
odel
LE To CMRS RegReport to
Independent N Generate generate UTI.
CP To CMRS RegReport to skip UTI
Independent N Generate generation.
CMRS RegReport to skip UTI
Independent Y N/A generation.
The UGD rule uses the Tie-Breaker logic to determine if CMRS RegReport
needs to generate the UTI; and in case CMRS RegReport needs to
generate the UTI, the UGD generates the UTI.
For ASIC and MAS, the generated UTI needs to be assigned to

USI as ASIC and MAS uses ‘USI’ and ‘USI Prefix’ fields to map
to unique transaction identifier.
NOTE
22.2 UGD Rule – DTCCEU

/DTCCEULITE
If no override is provided from Source System, then CMRS will
determine UTI Generating party on the basis of -
 Party Nature fields i.e. ‘TradeParty1Nature’ and

‘TradeParty2Nature’
Below table can be used to compute the UGD Rule on the basis of Party
Nature:
Party Nature UTI Generator

If either party is CCP CCP
Else If either party is FC FC
Else If either party is NFC NFC
Else If Seller info is available Seller
If the above conditions are not met for a deal, then CMRS will fail the deal.
22.3 UGD Rule – ICE
If no override is provided from Source System, then CMRS will

determine UTI Generating party on the basis of -
 Party Nature fields i.e. ‘TradeParty1Nature’ and
‘TradeParty2Nature’
Below table can be used to compute the UGD Rule on the basis of Party
Nature:
Party Nature UTI Generator

If either party is CCP CCP
Else If either party is FC FC
Else If either party is NFC NFC
If the above conditions are not met for a deal, CMRs will fail the deal.
22.4 UGD Rule – BOI

Seller will be the UTI Generating party. Following tie breaker logic will be
used to determine the seller. This rule is based on ISDA guidelines.

Swap Forward-Far Leg:
seller.
seller.
Forward-Near Leg: (Reverse of Far Leg)
seller.
seller.
Forward THEN the party coming in
seller.
seller.
NDF THEN the party coming in
seller.
seller.
Options
seller.
NDO
seller.
Simple Exotic
seller.
seller.
If OptnSellerValue is blank THEN
<ExchangedCurrency1> comes first
Complex Exotic
seller,
<ExchangedCurrency2PayerValue> will seller.
Spot If Swap Leg =’F’ OR Swap Leg = ‘’
seller.
seller.
If Swap Leg =’N’
seller.
seller.
23 UTI Delegation Rule (EMIR,
ASIC, ,MAS and BOI Only)
In EMIR, the UTI generation party is determined by the product tie breaker
logic defined by ISDA. But there is also a possibility that the two parties
involved in the trade report on their behalf but one party delegate the UTI
generation responsibility to other. This is UTI delegation. For Example,
suppose by UGD logic CP is the UTI generator but CP has delegated its UTI
generation to LE, LE will have to generate and report the UTI for this
trade.
CMRS RegReport has an input field – ‘UTIDelegation’ – which specifies the

generator of the UTI. The possible values for the field are:
• LE to generate
• CP to generate
• None
23.1 Workflow
For UTI delegation there is a flag which tells CMRS RegReport that the UTI
delegation is there from CP to LE or from LE to CP or No UTI Delegation.
The delegation indicator helps CMRS RegReport decide whether or not to
skip the UTI generation.
Here are the cases where this feature will be used
- UTI delegation is done by CP to LE.

a) UGD result, CP is the RP, but LE will generate UTI and report
b) MW Exists, in this case, UTI generation will get skipped
- UTI delegation from LE to CP
a) UTI generation by CP even if UGD says LE is the RP
UTI generation will be ignored by CMRS RegReport

24 Reporting on behalf of
Counterparty (MiFID-II PTT only)
The Submitting Party (SP) submits trade records for their counterparty
where their counterparty has the obligation to "report" the trade.
IF Party1ReportingObligation = ASSISTED_REPORTING
{
Report the Trade on behalf of Counterparty. I.e. Populate ‘D’ in Regulatory_Report_Type field.
ReportingPartyLEI = LEI of the Party obligated to report

CounterpartyLEI = LEI of the Counterparty
SubmittingPartyLEI = LEI of the submitting party
}
ELSE
{
Run Subsequent rules of CMRS, if any.
}
On LE-CP Configuration screen, under MiFID II PTT, Reporting Party label

and dropdown with values- LE, CP, Assisted and None similar to related
regulations. User should be able select one only value from the dropdown.
Assisted value in the dropdown when selected will be used for reporting
the trade on behalf of counterparty.
SS:Party1ReportingObligation Reporting Party? Reporting Outcome

Or RPD rule outcome
UI:Look up from UI
[blank] LE Report the trade

[blank] CP Ignore the trade
REPORTINGPARTY_PTT NA Report the trade
NONREPORTINGPARTY_PTT NA Ignore the trade
ASSISTED_REPORTING NA Report Trade on behalf of

counterparty
25 MW Exists (EMIR, ASIC, and
MAS Only)
If there is a middleware involved in the trade, the reporting parties will get
the UTI from the middleware (MW) and hence CMRS RegReport does not
generate the UTI. If UTI is coming from the source system then it is used;
otherwise CMRS RegReport functions as per the TR specifications.
There are 3 possible outcomes when MW exists and no UTI is sent from
the source system:
 CMRS RegReport fails the trade (e.g. DTCC, ICE)

 Trade is reported with an interim/dummy UTI (e.g. UnaVista)
CMRS RegReport identifies the presence of MW from an input field

‘MWExists’ – if it is true then there is a MW and if it is false then there is
no MW.
26 Reportable Product Rule for ICE-
TR
ICE eConfirm is a confirmation platform and can accept trades which may
not be reportable for any regulation. Since CMRS RegReport is only
supporting both confirmation and reporting workflow for ICE, CMRS
RegReport will need to identify when it needs to send trades to ICE for
reporting vas for confirmation only.
The rule will identify whether a trade flowing into CMRS RegReport is sent
for confirmation only or confirmation and reprting both. The trades which
have Reportable Product marked as ‘N’ and are double sided gets sent to
ICE with USSDRReportableTrade and EMIRReportableTrade Field as ‘N’.
CMRS RegReport will not generate USI or UTI in this case and will send the
trade to ICE with blank USI/UTI. USI/UTI will be pass-through if this value is
coming from SS.
Reportable Single
Product Sided Result
Y Y or blank Report
Y N Report
N N Report
N Y or blank Ignore
27 Additional Repository 3 Lookup
Override (CSA Only)
Additional Repository 3 fields are to be used to by DTCC to indicate the
Canadian jurisdictions where the parties are local.
This is an interim solution until new fields for representing local

counterparty information are created and ready for use on March 31,
2015. The following is how the Additional Repository 3 fields should be
used for Canada Local Counterparty Reporting:
• Additional Repository 3 Prefix – “Internal”

• Additional Repository 3 Party ID Value – the schema as outlined in
scenarios below
• Additional Repository 3 Trade ID – Blank
Description CSV Submission FpML Submission

If both Reporting Party Additional <party
and Non Reporting Repository 3 Party id=”AdditionalRepository3”>
Party fall under local ID Value = <partyId
counterparty RP:CA.MB.MSC:NRP: partyIdScheme=”http://www.
jurisdiction, RP in CA.ON.OSC;CA.QC.A dtcc.com/participant-internal-
Manitoba and NRP in MF identifier”>
Ontario and Quebec. RP:CA.MB.MSC:NRP:CA.ON.OS
C;CA.QC.AMF </partyId>
</party>
If Non Reporting Party Additional <party
does not fall under Repository 3 Party id="AdditionalRepository3">
local counterparty ID Value = <partyId
jurisdiction and only RP:CA.MB.MSC;CA.O partyIdScheme="http://www.
Reporting Party fall N.OSC dtcc.com/participant-internal-
under local identifier">
counterparty RP:CA.MB.MSC;CA.ON.OSC
jurisdiction, Manitoba </partyId>
and Ontario. </party>
If Reporting Party Additional <party
does not fall under Repository 3 Party id="AdditionalRepository3">
local counterparty ID Value = <partyId
jurisdiction and only NRP:CA.QC.AMF partyIdScheme="http://www.
Non Reporting Party dtcc.com/participant-internal-
falls under local identifier"> NRP:CA.QC.AMF
counterparty </partyId>
jurisdiction </party>
28 Identification of Single-
Side/Double-Side Trade for ICE-
TR
There is a field named SingleSidedTrade in the interim for each asset
class which will be used to determine if a Trade is single sided or double
sided. If this field indicates a ‘Y’, then the trade is considered as single
sided else if it indicates an ‘N’, it’s considered as double sided. If it’s
blank, the deal will be considered as single sided. Any invalid value in this
field will result in a failure at deal processing stage.
29 Sovereign Entities Rule (MAS
Only)
The trades booked between the sovereign entities are reportable under
MAS regulation.
There will be a checkbox on Legal Entity and Counterparty screen to will

be used to determine if the entities are sovereign entities i.e.
If checked, mean the entity is Sovereign Entity and if un-checked means

the entity is not a sovereign entity.
If both are checked the Trade is to be ignored. A new reportability status

needs to represent the Trades between the sovereign entities.
30 Auto Resolve Rule
This rule enables failed deals in CMRS RegReport to be marked as resolved
automatically if a subsequent event flows into CMRS RegReport to correct
the previously failed event.
There is a field called ‘EventTieOutID’ in all the Interims which in

conjunction with Deal ID, Asset Class and Source System will be used to
determine if there are failures in CMRS RegReport for this combination and
accordingly will be marked as Resolved, when a subsequent event with
the same combination flows into CMRS RegReport again.
31 OTC Cleared Trade Switch Rule
• In REGIS, for OTC cleared trade, when field “CompressedTrade” will
be filled with value “Y” to indicate that the position being reported is
the result of the netting of various trades, then it will switch to
netted OTC cleared Trade.
• If CompressedTrade = Y and isCleared = true, then CMRS RegReport
will send ME or EX or TE message otherwise send MX or XT or TT
message. The logic behind it is –
• As per the logic, the event switch rule execution in CMRS RegReport
is as follows:
Event
Events switched from To New events
Message
AFFILIATE_NOVATION_TRADE
AFFILIATE_POST_ALLOCATION_TRADE
AFFILIATE_POST_COMPRESSION_TRADE
AFFILIATE_POST_EXERCISE_TRADE
AFFILIATE_TRADE
NOVATION_TRADE
TRADE_NETTED_OTC_C
POST_ALLOCATION_TRADE EX
LEARED
POST_COMPRESSION_TRADE
POST_EXERCISE_TRADE
SNAPSHOT_TRADE
TRADE
AFFILIATE_EXIT
EXIT
AFFILIATE_AMEND MODIFY_NETTED_OTC_ ME
AFFILIATE_AMEND_CONFIRM CLEARED
AFFILIATE_INCREASE
AFFILIATE_INCREASE_CONFIRM
AFFILIATE_NOVATION_TRADE_CONFIRM
AFFILIATE_PARTIAL_COMPRESSION
AFFILIATE_PARTIAL_NOVATION
AFFILIATE_PARTIAL_NOVATION_CONFIRM
AFFILIATE_PARTIAL_TERMINATION
AFFILIATE_PARTIAL_TERMINATION_CONFIR
Event
Events switched from To New events
Message
M
AFFILIATE_POST_ALLOCATION_TRADE_CON
FIRM
AFFILIATE_POST_COMPRESSION_TRADE_C
ONFIRM
AFFILIATE_POST_EXERCISE_TRADE_CONFI
RM
AFFILIATE_TRADE_CONFIRM
AMEND
AMEND_CONFIRM
INCREASE
INCREASE_CONFIRM
NOVATION_TRADE_CONFIRM
PARTIAL_COMPRESSION
PARTIAL_NOVATION
PARTIAL_NOVATION_CONFIRM
PARTIAL_TERMINATION
PARTIAL_TERMINATION_CONFIRM
POST_ALLOCATION_TRADE_CONFIRM
POST_COMPRESSION_TRADE_CONFIRM
POST_EXERCISE_TRADE_CONFIRM
SNAPSHOT_MODIFY
TRADE_CONFIRM
UPDATE_UTI_MODIFY UPDATE_NETTED_OTC_ ME +
CLEARED_UTI_MODIFY UPDATE_UTI
AFFILIATE_ALLOCATION
AFFILIATE_EXERCISE TERMINATION_NETTED_
AFFILIATE_NOVATION OTC_CLEARED(Action
AFFILIATE_TERMINATION Type = C)
ALLOCATION
EXERCISE
NOVATION
TE
TERMINATION
AFFILIATE_TRADE_CANCEL CANCELLATION_NETTE
TRADE_CANCEL D_OTC_CLEARED(Actio
n Type = E)
AFFILIATE_COMPRESSION COMPRESSION_NETTED
COMPRESSION _OTC_CLEARED(Action
Type = Z)
32 Action Switching Rule
 Action switching rule is used to switch the value of Action Type to
“V” from “M” for few CMRS RegReport events.
 In Regis, user has to send a modification message along with Action
type = “V” to update the value of 3 specific fields: Collateralization,
Collateral Portfolio and Collateral Portfolio Code.
 In Regis, a new interim field - ExposureDetailsModify - is added
for all asset classes through which user can intimate the CMRS
RegReport about the changes in the above 3 fields.
 Working of Event switching rule.
If (ExposureDetailsModify = True)
Then Action Type will be switched to “V”
Else process the events with Action type = “M”
 Impacted events are as followed:-

Impacted Events Event Message
AFFILIATE_AMEND 6. MX
AFFILIATE_AMEND_CONFIRM (Action Type switched to “V”
AFFILIATE_INCREASE from “M”)
AFFILIATE_INCREASE_CONFIRM
AFFILIATE_NOVATION_TRADE_CONFIRM
AFFILIATE_PARTIAL_COMPRESSION
AFFILIATE_PARTIAL_NOVATION
AFFILIATE_PARTIAL_NOVATION_CONFIRM
AFFILIATE_PARTIAL_TERMINATION
AFFILIATE_PARTIAL_TERMINATION_CONFIRM
AFFILIATE_POST_ALLOCATION_TRADE_CONFIRM
AFFILIATE_POST_COMPRESSION_TRADE_CONFIR
M
AFFILIATE_POST_EXERCISE_TRADE_CONFIRM
AFFILIATE_TRADE_CONFIRM
AMEND
AMEND_CONFIRM
INCREASE
INCREASE_CONFIRM
NOVATION_TRADE_CONFIRM
PARTIAL_COMPRESSION
PARTIAL_NOVATION
PARTIAL_NOVATION_CONFIRM
PARTIAL_TERMINATION
PARTIAL_TERMINATION_CONFIRM
POST_ALLOCATION_TRADE_CONFIRM
POST_COMPRESSION_TRADE_CONFIRM
POST_EXERCISE_TRADE_CONFIRM
SNAPSHOT_MODIFY
1. TRADE_CONFIRM
2. CORPORATEACTION
3. CORPORATEACTION_CONFIRM
4. MODIFY_NETTED_OTC_CLEARED
5. ETD_POSITION_MODIFY
33 Destination Event Switching

Rule
 Destination event switching rule is used to switch the destination
event for Exercise and Partial_Exercise events
 This rule is applicable only for DTCC GTR for asset classes, CR, EQ
anf FX
o Destination event, Exercise will be applicable in case of asset
classes, CR and EQ for PET and CONFIRM messages
o Destination event, Partial_Exercise will be applicable in case of
asset class, FX for PET and CONFIRM messages
34 Report Updated USI/UTI/Party
Identifier
Report updated USI/UTI/Party Identifier workflow is used to modify the key
attributes of trade such as USI, UTI or LEI, UCID at TR end. CMRS
RegReport initiate the workflow by triggering 2 internal events AUTO_EXIT
and AUTO_UPDATE.
The events are different for ETD asset class and OTC netted products. For
ETD, CMRS RegReport trigger ETD_AUTO_EXIT & ETD_AUTO_UPDATE. For
OTC netted products, CMRS RegReport trigger
AUTO_EXIT_NETTED_OTC_CLEARED &
AUTO_UPDATE_NETTED_OTC_CLEARED.
The workflow is dependent on TRs
34.1 DTCC TRs except OTCLITE:

 CMRS RegReport will trigger a new event AUTO_EXIT containing the
latest ACK deal details in CMRS RegReport. The new event will send
a snapshot message that will exit the trade containing old Party
Identifier (Legal Entity ID and Counter Party ID) and Trade Identifier
(USI or UTI, whichever is applicable for that regulator) at DTCC end.
Any subsequent events for this deal will be put ON HOLD state at
Deal Process stage in CMRS RegReport.
 CMRS RegReport will trigger a new AUTO_UPDATE event and resume

all ON HOLD events after receiving ACK for the AUTO_EXIT event.
The AUTO_UPDATE event will send a snapshot message that will be
created from last ACK existing deal details in CMRS RegReport and
contain the changed Party Identifier (Legal Entity ID and Counter
Party ID) or Trade Identifier (USI or UTI, whichever is applicable for
that regulator).
34.2 OTCLITE TR:

 The workflow for OTCLITE will be the same as that of all other DTCC
TR’s with one difference, POSITION message will be sent out instead
of SNAPSHOT message as SNAPSHOT message is not applicable for
OTCLITE.
34.3 Regis TR:
 CMRS RegReport will trigger a new event AUTO_EXIT. The new event
will send a TT message that will be created from last existing ACK
deal details in CMRS RegReport and will contain old Party Identifier
(Legal Entity ID and Counter Party ID) and Trade Identifier (USI or
UTI, whichever is applicable for that regulator). This event will
cancel the existing position at DTCC end for a deal. Any subsequent
events for this deal will be put ON HOLD state at Deal Process stage
in CMRS RegReport.

The AUTO_UPDATE event will send a XT message that will be
created from last existing ACK deal details in CMRS RegReport and
will contain the changed Party Identifier (Legal Entity ID and Counter
Party ID) or Trade Identifier (USI or UTI, whichever is applicable for
that regulator).
34.4 ICE Trade Vault - EMIR

 In case of ICE, no exit event is needed to be triggered in case of UTI
change. Reporting the new UTI with the same SenderTradeRefId field
will update the UTI for the deal at ICE’s end. In case of partyID
(Legalentity Id or CounterPartyID) update, ICE mandates submitting
the new partyID along with a new UTI. Submitting the modified
partyID along with a new UTI from Sourcesystem will update both
the UTI and the partyID. In case no UTI is provided from the
Sourcesystem then CMRS provides and option to generate one. No
Exit event is needed to be triggered in this scenario as well.
34.5 ICE Trade Vault – REMIT

 CMRS RegReport will trigger a new event AUTO_EXIT containing the
latest ACK deal details in CMRS RegReport. The new event will send
a message that will exit the trade containing old Party Identifier
(Legal Entity ID and Counter Party ID) and Trade Identifier ( ACER
UTI) at ICE TV RRM’s end. Any subsequent events for this deal will
be put ON HOLD state at Deal Process stage in CMRS RegReport.

The AUTO_UPDATE event will send a message that will be created
from last ACK existing deal details in CMRS RegReport and contain
the changed Party Identifier (Legal Entity ID and Counter Party ID) or
Trade Identifier (ACER UTI).
35 HKMA Reportable Rule
The HKMA Reportable Rule is implemented in CMRS RegReport to
determine the HKMA reporting for a trade.
35.1 System Config

If Legal Entity is a Hong Kong incorporated Entity, then the “HK Entity”
flag on the Legal Entity Set up screen should be checked.
Similarly, if Counterparty is a Hong Kong incorporated Entity, then the “HK

Entity” flag on the Counterparty Set up screen should be checked.
CMRS RegReport identifies if a trade is booked in Hong Kong from an input

field “BookedInHK”. If it is True, then trade is booked in Hong Kong by
Legal Entity, else trade is not booked in Hong Kong.
35.2 Scenarios
Below are the scenarios which determine the reportability of a trade to
HKMA. The check is based on whether the Legal Entity is a Hong Kong
incorporated entity (based on “HK Entity” flag on the LE Setup screen) or
the Counterparty is a Hong Kong incorporated entity (based on “HK Entity”
flag on the CP Setup screen) or the trade is booked in Hong Kong by the
Legal Entity (based on “BookedInHK” flag).
Result - Trade
Is LE a HK Is CP a HK
BookedInHK? reportable to
Entity? entity?
HKMA?
Y Y Y Y
Y N N Y
N Y Y Y
N N N N
Y Y N Y
Y N Y Y
N Y N Y
N N Y Y
35.3 Workflow
If (“HK Entity” Flag for LE OR “HK Entity” flag for CP = True)
{Report the Trade for HKMA }
Else
If (“BookedInHK” = True)
{Report the Trade for HKMA }
Else
{Ignore Reporting for HKMA}
36 ASIC Reportable Rule
The ASIC Reportable Rule is implemented in CMRS RegReport to determine
the ASIC reporting for a trade.
36.1 System Config

If Legal Entity is an Australia incorporated Entity, then the “Is AU Entity”
Similarly, if Counterparty is an Australia incorporated Entity, then the “Is

AU Entity” flag on the Counterparty Set up screen should be checked.
CMRS RegReport identifies if an Australian trader is involved in the trade

using an input field “BookedInAU”. If it is True, an Australian trader is
involved in trade, else Australian trader is not involved in trade.
36.2 Scenarios
ASIC. The check is based on whether the Legal Entity is a Australia
incorporated entity (based on “Is AU Entity” flag on the LE Setup screen)
or the Counterparty is a Australia incorporated entity (based on “Is AU
Entity” flag on the CP Setup screen) or if an Australian trader is involved in
the trade (based on “BookedInAU” flag).
Result - Trade
Is LE a AU Is CP a AU reportable to
BookedInAU?
Entity? entity? ASIC from LE
perspective
Y Y Y Y
Y N N Y
N Y Y Y
N N N N
Y Y N Y
Y N Y Y
N Y N Y
N N Y Y
36.3 Workflow
If (“Is AU Entity” Flag for LE OR “Is AU Entity” flag for CP = True)
{Report the Trade for ASIC }
Else
If (“BookedInAU” = True)
{Report the Trade for ASIC }
Else
{Ignore Reporting for ASIC}
37 MAS Reportable Rule
The MAS Reportable Rule is implemented in CMRS RegReport to determine
the MAS reporting for a trade.
37.1 System Config

If Legal Entity is a Merchant or Licensed Bank, then “Merchant / Licensed
Bank” flag on LE screen should be checked. If the Legal Entity is not a
Merchant/Licensed Bank, then “Others” flag should be checked.
If Legal Entity is a Singapore incorporated Entity, then the “Is AU Entity”

Similarly, if Counterparty is a Singapore incorporated Entity, then the “Is

SG Entity” flag on the Counterparty Set up screen should be checked.
CMRS RegReport identifies if a Singapore based trader is involved in the

trade using an input field “BookedInSG”. If it is True, a Singapore based
trader is involved in trade, else Singapore based trader is not involved in
trade.
37.2 Scenarios
MAS. The check is based on whether the Legal Entity is a Singapore
incorporated entity (based on “Is SG Entity” flag on the LE Setup screen)
or the Counterparty is a Singapore incorporated entity (based on “Is SG
Entity” flag on the CP Setup screen) or if a Singapore based trader is
involved in the trade (based on “BookedInSG” flag).
Licensed Other Is SG Is SG BookedIn Trade

/Mercha Entities Entity Counte SG Reportable to
nt Flag Flag rparty MAS
(LE
Bank
perspective)
Flag
IR & FX
CR
Y N/A Y Y Y Y Y
Y N/A Y Y N Y Y
Y N/A Y N Y Y Y
Y N/A Y N N Y Y
Y N/A N Y Y Y Y
Y N/A N Y N Y Y
Y N/A N N Y Y Y
Y N/A N N N N N
N Y Y Y Y Y N
N Y Y Y N Y N
N Y Y N Y Y N
N Y Y N N Y N
N Y N Y Y Y N
N Y N Y N Y N
N Y N N Y N N
N Y N N N N N
N N N Y Y N N
N N N Y N N N
N N N N Y N N
N N N N N N N
37.3 Workflow
38 Party 1 Snapshot Message
Suppression Rule (EMIR Only)
As reporting obligations can be delegated from one party to another,
CMRS RegReport supports delegation as below
1. If No Delegation i.e. independent Reporting – both the parties report

their side of the trade
2. If Delegation is there and both parties are supposed to report then
the delegated party reports 2 messages, 1 reporting the party1 side
of the trade and the other reporting the party2 side of the trade.
3. If Delegation is there, and only the party delegating the reporting
has the obligation to report, then the delegated party reports 1
message, on behalf of the party obligated to report. To support this
scenario, a new Reportability status is created – "Party2Only”
This rule is applicable as follows:
• DTCC EU – When reporting via FPML format and DTCC Counterparty

Data enrichment flag is True.
If (EMIRReportabilityStatus = ‘Party2Only’)
Send Snapshot_Delegated for Party 2 AND Suppress the Snapshot

Message for Party 1
Else if (EMIRReportabilityStatus = ‘FULL’)
}
39 Counterparty Masking (CFTC,
CSA, MAS, ASIC, HKMA)
Certain regulations – CFTC, CSA, MAS, ASIC, HKMA allow to mask
counterparty details while reporting a trade to the regulator. EMIR does
not support counterparty masking.
Based on the regulations specified in “MaskCounterparty” field from

Source system, and below masking details provided CMRS will send out
masked counterparty information to the TR -
 MaskedCounterpartyID
 MaskedCounterpartyConvention
 MaskedCounterpartyName
 MaskedCounterpartyStreetLine
 MaskedCounterpartyCity
 MaskedCounterpartyState
 MaskedCounterpartyPostalCode
 MaskedCounterpartyCountry
Precondition – The system configuration flag “Enable_CP_Masking” should

be turned on for masking to happen.
40 Shekel Yield Rule (BOI)
As per BOI regulation requirements, reporting requirement for BOI will only
apply to transactions that involves Israeli Currency or a Shekel Yield (a
yield on a shekel asset or shekel index, including the Telebor interest rate
or the Bank of Israel Interest Rate).
BOI identifies financial entities as one of the following:-
 Banking Corporation
 Foreign banks(branches in Israel)
 Portfolio Manager.
 Tel Aviv Stock Exchange member
 Non-Resident Entity
 Foreign Banks (for branches outside Israel).
BOI mandates its reporting requirement for the first two entities. The
reporting requirement applies to the other entities only if they have either
on own or other’s behalf have done transaction of average daily amount
of 15 million US dollars (gross total amount of transactions in any 12
preceding months divided by 250)
40.1 Workflow
Scenarios –
Floating RateIndex1 Floating RateIndex2 Output

ILS-CPI LIBOR REPORT
LIBOR ILS-CPI REPORT
LIBOR LIBOR IGNORE
As BOI supports reporting of only Interest Rates and Foreign Exchange
based derivatives, the workflow for the 2 will be as follows :-
S.No. Shekel Based Indexes

1 ILS-CPI
2 ILS-OIS-COMPOUND
3 ILS-TELBOR01-Reuters
4 ILS-TELBOR-Reference Banks
S.No AssetClass Field

1 Foreign Exchange ExchangedCurrency1
2 Foreign Exchange ExchangedCurrency2
3 Interest Rates FloatingRateIndexleg1
4 Interest Rates FloatingRateIndexleg2
40.2 Override
If ‘ShekelOverride’ from Source System is sent as true then the deal
should not be ignored and must be reported even if
ExchangedCurrency1 or ExchangedCurrency2 is not ILS for FX and
FloatingRateIndexleg1 is not one of the following for IR:
 ILS-CPI
 ILS-OIS-COMPOUND
 ILS-TELBOR01-Reuters
 ILS-TELBOR-Reference Banks
41 FX Spot Reportability Rule
 Reporting of Foreign Exchange: Spot trades is out-of-scope for
reporting to various jurisdictions except if it is part of a FX Swap
transaction. However for BOI, Spot trades must be reported even if
it is not part of a FX Swap transaction.
 For CFTC/CSA, CMRS will identify the product Foreign Exchange: Spot
that is part of a FX Swap transaction and apply RPD logic applicable
to near leg and far leg of FX Swap for CFTC/CSA.
 For EMIR/ASIC/MAS/HKMA, CMRS will identify the product Foreign

Exchange: Spot that is part of a FX Swap transaction and report
accordingly.
Rule Implementation
 The interim field “SwapLeg” will be used to identify FX Spot

transactions which are part of a FX Swap
 If the value present in the field <SwapLeg> is ='N' then the

trade can be identified as the 'Near Leg' of a FXSwap.
 If the value present in the field <SwapLeg> is ='F' then the

trade can be identified as the 'Far Leg' of a FXSwap.
 If no value is present in the field <SwapLeg> then the trade

can be identified as FXSpot that is not part of any FXSwap
 The hierarchy for determining FX Spot reporting for CFTC/CSA will be

as below –
 For CFTC/CSA -
1. Source system override in “Party 1 Reporting
Obligation”field.
2. Check for “Swap Leg” field – if blank, then ignore trade

from reporting, else move to step 3.
3. “Reporting Party” setup on LECP Configuration screen
4. Normal RPD/lookup workflow
 For EMIR/MAS/ASIC/HKMA –
 CMRS will check the “Swap Leg” field. If “Swap Leg” is

blank, then trade will not be reported.
 For BOI –
 Even if “Swap Leg” is blank the trade should still be

reported.
 For NPOs and Valuation, the reporting will be looked up from PO. If
PO has been reported, then NPO/Valuation will be reported, else will
be ignored irrespective of “Swap Leg” value.
42 RT Message Suppression Rule
(CFTC Only)
If the incoming trade is reported by a Prime Broker or is a Non-Price
forming amend or correction then the RT message associated with the
event must be ignored at Message Generated stage.
42.1 RT Suppression for Prime Broker

Deal
 ISDA Best Practice dictates that in the case of a Prime Broker Deal
RT message need not be reported.
 For CFTC, a new interim field - Suppress_RT_For_PB_Trade - is added

for FX asset class through which user can intimate the CMRS
RegReport if the deal is a Prime Broker deal.
 If “Suppress_RT_For_PB_Trade” is true then the RT message

associated with the event should get ignored at Message Generated
stage.
42.2 RT Suppression for Non-Price

forming Amend/Correction
 As per CFTC Specifications, if the deal contains a non-price forming
amend/change then the RT message need not be reported.
 For CFTC, a new interim field – Non_Price_Forming - is added for all

OTC asset classes through which user can intimate the CMRS
RegReport if the deal is a Non-Price forming amend or correction.
 If “Non_Price_Forming” is true then the RT message associated with

the event should get ignored at Message Generated stage.
43 Clearing Threshold Lookup
Logic (ESMA Only)
This field indicates whether the party is above the Clearing threshold or
not. It is determined on the basis of Financial Nature of party. Clearing
Threshold only needs to be computed for the Non-Financial Counterparties
and is irrelevant for the other parties’ and will be left BLANK. This needs to
be computed for both the trade parties i.e. ‘ClearingThresholdParty1’ and
‘ClearingThresholdParty2’.
Below table can be used to compute the Clearing Thresholds:
Organization Type Clearing Threshold

FC BLANK Not Applicable for
the Financial
Counterparties
NFC+ TRUE
NFC FALSE
CCP BLANK Not Applicable for
the Central Clearing
Counterparties
Other BLANK Not Applicable for
the Other
Counterparties
44 Rule for Determining Level
(ESMA Only)
The Level field will represent distinction between transaction reporting

and position reporting.
For OTC trades, reporting is done at transaction level only, hence, CMRS
computes this field as ‘T’. Whereas, for the ETD trades, there is a clear
distinction between the Transactions and Positions; hence, this will be
computed depending upon the submission made i.e. ‘T’ for transaction
messages and ‘P’ for position messages.
Determination of ETD transaction messages will be done using the Event

Name as follows:
Event Name Level

For any OTC reporting T
ETD_TRADE T
ETD_AFFILIATE T
ETD_TRADE_MODIFY T
For all other ETD events P
45 Rule for Filtering Non-
Reportable Amend (MiFID-II
Transaction & PTT only)
Under MiFID II, the regulatory bodies require reporting system to avoid
duplicate reporting. In case APA/ARM reportable fields (Mandatory /
Conditional), as part of any event from SS, are not changed/ modified,
CMRS should not report the related messages and ignore the same
event/deal with the error message – “No change in any of the <variable>
reportable field.” <variable> can be Tradeweb, Trax etc.
CMRS comparator will compare two data sets and identify whether the
recent event is eligible for reporting
IF any event flows into CMRS with an existing event present in the
system
{
CMRS will run the Comparator on two data sets
- Last event that just entered CMRS
- Event with Event Execution Time less than or equal to the Event Execution
Time of the received event (exist in CMRS).
CMRS Comparator will compare values of all the configured fields in the
System.
IF Value changed in at least one of the field

{
CMRS reports to APA/ARM
}
ELSE
{
CMRS ignores the trade and not report to APA/ARM. Related
message - “No change in any of the <variable> reportable field.”
<variable> can be Tradeweb, etc.
}
}
ELSE
{
CMRS will run subsequent rules, if any
}
Note :
 CMRS application will provide a way to configure all fields on which
the Comparator will run and the configuration will be for both APA
and ARM
 This rule will run in case of reprocessing only if reprocessing is done
for a failure which occurred before this rule got applied.
In case an event failed at Deal Received OR Deal Processed stage and

user sends the same event again, CMRS will report the trade. Otherwise, if
an event failed in another stage stage and user sends the same event
again, CMRS will ignore the trade.
Event Same
exists in event(s)
CMRS? that is Event
present in Executi
De CMRS on
Scena al failed at DateTi Outcome
rios ID Event DR OR DP? me ?
ACK 101 Trade N NA 12:01 Report
Receiv 101 Amend N NA 12:02 Report
ed 101 Amend N NA 12:03 Report
N NA
101 Amend 12:02 Ignore
NACK 101 Trade N NA 12:01 Report

Receiv 101 Amend N NA 12:02 Report
ed 101 Amend N NA 12:03 Report
Y NA
101 Trade N NA 12:01 Report
N NA
CMRS
failures CMRS
101 Amend 12:02 Failure
101 Amend N NA 12:03 Report
101 Amend Y N 12:02 Ignore
In 101 Trade N NA 12:00 Report

betwe CMRS
N NA
en 101 Amend 12:02 Failure
event 101 Amend N NA 12:03 Report
came 101 Amend Y Y 12:01 Report
from
Same 101 Trade N NA 12:00 Report
event 101 Amend N NA 12:02 Report
came CMRS
multipl Y Y
101 Amend 12:02 Failure
e
times
Y N
CMRS user can reprocess the events that were failed in CMRS and send
the same to APA/ARM.
Reprocess Scenarios:
CMRS
failure
before
Non-
Failed User Reportabl
in Reprocess e amend Rule
Deal ID Event CMRS? ed Rule? Outcome?
CMRS will
not run the
run in case
Y Y N
of
reprocessin
101 Trade g
CMRS will
not run the
run in case
Y Y Y
of
reprocessin
101 Trade g
46 Filtering Non-reportable events
(MiFID-II Transaction & PTT only)
ESMA has provided waiver on certain events and these events will be
ignored by CMRS application. The related events need to be mapped in
CMRS (to ignore reporting) and therefore, no reporting would be done to
Trax OR Tradeweb on the following non-eligible events:
Non-reportable events
ALLOCATION ETD_POSITION_BACKLOAD TRADE_MATURED
ALLOCATION_CONFIRM ETD_POSITION_CANCEL VALUATION
AUTO_EXIT ETD_POSITION_EXIT AUTO_EXIT_NETTED_OTC_CLEAR
ED
AUTO_UPDATE ETD_POSITION_HISTORICA AUTO_UPDATE_NETTED_OTC_CL
L EARED
BACKLOAD ETD_POSITION_MODIFY CANCELLATION_NETTED_OTC_CL
EARED
CLEARED_EXIT ETD_POSITION_TRADE CLEARED_EXIT_CONFIRM
COLLATERAL EXERCISE COMPRESSION_NETTED_OTC_CL
EARED
COLLATERAL_CANCEL EXERCISE_CONFIRM HISTORICAL_COLLATERAL
COLLATERAL_LINK HISTORICAL HISTORICAL_VALUATION
COLLATERAL_LINK_CAN HISTORICAL_EXPIRED MODIFY_NETTED_OTC_CLEARED
CEL
COMPRESSION NOVATION SNAPSHOT_SHORT
COMPRESSION_CONFIR NOVATION_CONFIRM TERMINATION_NETTED_OTC_CLE
M ARED
ETD_AUTO_EXIT SNAPSHOT TRADE_NETTED_OTC_CLEARED
ETD_AUTO_UPDATE TRADE_DOCUMENT_CONFI UPDATE_UTI_MODIFY
RM
Refer Admin Data setup sheet for further details on exhaustive and
updated list of events.
As per ESMA guidelines, pre-determined events are not reportable. CMRS

will not report the above mentioned events OR an event in which
Pre_Determined_Event flag is ON. These events will be ignored by
CMRS and later, not reported.
Note: if any of the event (PO/NPO) can be pre-determined at the time of

trade execution, CMRS will not report the same trade to the TR. E.g.
Amortization on a trade will reduce notional over time in a defined way
(related events will be sent by SS). Thus, these events are meant to be
ignored by CMRS. CMRS expects SS to send a flag indicating whether an
event is a pre-determined.
When a trade is ignored by CMRS, the following error message will be

displayed – “The <Name of the event> event is not eligible for Reporting
under MiFID II” in Deal Processed stage. In case user clicks on the
respective deal (ignored), the same error will be displayed on Deal
Processed Details screen.
47 Events on Trades executed
before MiFID II live date (MiFID-II
As per MiFID-II regulatory requirements, historical/backloaded trades are
not required to be reported. CMRS will ignore Events on Trades executed
before MiFID live date
Rule:
IF event is a Position Opener AND TradeExecutionTimestamp is before

MiFID II live date
{
CMRS will ignore the deal and display error message – “Trade is not
required to be reported as Trade Date Time is before MiFID II live
date”
}
ELSE IF event is a Non Position Opener AND

TradeExecutionTimestamp (Original Trade time) is before MiFID II live
date AND EventExecutionDtTime is after MiFID II live date
{
CMRS will not report any lifecycle event other than Incr/Decr. Non-
reported trades will be ignored by CMRS. CMRS will report the
lifecycle event for which change in Notional is TRUE/ON as a Position
Opener.
}
ELSE IF TradeExecutionTimestamp is after MiFID II live date AND

EventExecutionDtTime is after MiFID II live date
{
CMRS will run subsequent rules of MiFID II, if applicable
}
Scenarios:
PO Date NPO Date

S.
before MiFID before MiFID CMRS Action
No.
II Live? II Live?
1 Yes Yes Ignores the Trade
2 Yes No CMRS will not report any

lifecycle event other than
NPO with
Change_In_Notional flag as
True. Non-reported trades
will be ignored by CMRS;
CMRS will report the trade to
Trax and TW as a Position
Opener
Not Applicable as SS is
expected to share correct
3 No Yes
and logical Date time for
POs and NPOs
4 No No CMRS will process
48 Reporting Increase/Decrease
Events (MiFID-II Transaction
Reporting only)
In case of Transaction Reporting, Reporting of Increase/decrease event
requires us to send the delta values (only change) of Notional Amount and
Up-front payment fees. For e.g. after submitting the trade, parties agree
to increase notional amount from EUR 1 million to EUR 3 million and up-
front payment from EUR 50k to EUR 125k at the same price. The following
fields should be sent as part of Increase event in transaction reporting:
Field PO Event Lifecycle Event Compute Values

and Generate new
TRN
Trading date time ‘2018-10- ‘2018-11- ‘2018-11-
25T10:52:03Z’ 25T10:52:03Z’ 25T10:53:03Z’
TRN 817181919912 [blank]/Value 922028272621
Quantity ‘1000000’ ‘3000000’ ‘2000000’
Derivative notional [blank] [blank] ‘INCR’
increase/decrease
Up-front payment ‘50000’ ‘125000’ ‘75000’
*Report the Trade as a Position Opener
CMRS expects source system to send Change_in_Notional flag to

determine whether CMRS needs to run Increase/Decrease in notional and
payment rule.
Rule: CMRS receives delta values from SS
In case SS sends delta values in Change in notional and Change in up-

front payment fees fields for NPO events, CMRS will use the values to
identify INCR/DECR event type and generate new TRN for reporting
purpose.
IF Change_in_Notional flag is TRUE value exists in Delta in Notional

Amount field and Delta in up-front payment fees field
{
CMRS will generate new TRN (if TRN not sent by SS in INCR_DECR_TRN
field for INCR/DECR reporting).
Report the trade as a position Opener
IF value in Delta in Notional Amount field > 0

{
CMRS will report increase in notional
}
ELSE IF value in Delta in Notional Amount field < 0

{
CMRS will report decrease in notional
}
ELSE IF value in Delta in Notional Amount field = 0

{
CMRS will ignore the trade with error message – “Trade event can’t
be reported as Change in Notional is zero”.
}
ELSE
{
CMRS will compute delta (refer below Rule - CMRS compute delta)
}
}
ELSE
{
CMRS will run subsequent rules, if any.
}
Rule: CMRS compute Increase/Decrease in Notional
IF an event is a Position Opener

{
CMRS will run subsequent rules, if any.
}
ELSE IF an event is a Non-position Opener and Change_in_Notional flag is

FALSE OR Blank
{
No computation is required for Increase/Decrease in Notional Amount
}
ELSE
{
CMRS will run Delta Computation Rule
IF Delta in Notional Amount is zero
{
CMRS will ignore the trade with error message – “Trade event can’t
be reported as Change in Notional is zero”.
}
ELSE
{
CMRS will Generate new TRN (if TRN not sent by SS in
INCR_DECR_TRN field for INCR/DECR reporting) and use values
calculated in Delta Computation rule for reporting purpose.
}
}
Delta Computation Rule

- CMRS will pick the trade data that exists in CMRS records
- Compute difference in Outstanding Notional Amount and Up-front payment fees
between the two event in CMRS
- Only absolute values of the following fields to be reported:
• Quantity = Change in Notional Amount
• Up-front payment = Change in Up-front payment fees
• Trading Time = Event Execution Time of the received event
- Report the trade as a position Opener
- Derivative notional increase/decrease:
• INCR – Increase in Notional
• DECR – Decrease in Notional
49 Reporting multiple values for
common fields (MiFID-II
For meeting the regulatory reporting compliance with respect to specific
fields, CMRS is required to have the capability of sending different values
for a common field reportable to both Tradeweb and TRAX under
regulations MIFID II PTT & MIFID-II Transaction respectively. In order to be
able to do this CMRS will provide a configurable key and a rule which can
be turned On/Off using the key.
When this configurable key is set to true, which means that the given rule
is to be applied on an incoming message, CMRS will copy the values
coming in Tradeweb & TRAX specific fields to the common field mapped to
the TR fields at the Deal Processed stage. An example of how this rule will
work has been illustrated below.
PS: This rule will be applied at Deal Processed stage before applying
Enumeration and Message Validations.
Below table defines mapping between interim fields and SCML fields when
the rule is turned-on:
IR Interim SCML Mapping Copy To SCML (As per

Rule)
PriceNotationPriceType1_T PriceNotationPriceType1_T PriceNotationPriceType1
W W
PriceNotationPrice1_TW PriceNotationPrice1_TW PriceNotationPrice1
NotionalCurrencyleg1_TW NotionalCurrencyleg1_TW NotionalCurrencyleg1
QuantityUnit_TW QuantityUnit_TW QuantityUnit
Quantity_TW Quantity_TW Quantity
NotionalAmt_TW NotionalAmt_TW InitialNotionalleg1orNotionalAmou
nt_FRA
IntentToClear_TW IntentToClear_TW IntentToClear
PriceNotationPriceType1_T PriceNotationPriceType1_T PriceNotationPriceType1
RAX RAX
PriceNotationPrice1_TRAX PriceNotationPrice1_TRAX PriceNotationPrice1
NotionalCurrencyleg1_TRA NotionalCurrencyleg1_TRA NotionalCurrencyleg1
X X
QuantityUnit_TRAX QuantityUnit_TRAX QuantityUnit
Quantity_TRAX Quantity_TRAX Quantity
TradeExecutionTimestamp_ TradeExecutionTimestamp_ TradeExecutionTimestamp
TRAX TRAX
EventExecutionDtTime_TRA EventExecutionDtTime_TRA EventExecutionDtTime
X X
AdditionalPmntAmount_TR AdditionalPmntAmount_TR AdditionalPmntAmount
AX AX
AdditionalPmntCurrency_TR AdditionalPmntCurrency_TR AdditionalPmntCurrency
AX AX
ExpirationDate _TRAX ExpirationDate _TRAX ExpirationDate
ExecutionVenueID_TRAX ExecutionVenueID_TRAX ExecutionVenueID
OptnStrikePrice_TRAX OptnStrikePrice_TRAX OptnStrikePrice

OptnType_TRAX OptnType_TRAX OptnType
ExercisestyleTRAX ExercisestyleTRAX Exercisestyle
CFICode_TRAX CFICode_TRAX CFICode
FX Interim SCML Mapping Copy To SCML (As per

Rule)
PriceNotationPriceType_TW PriceNotationPriceType_TW PriceNotationPriceType
PriceNotationPrice_TW PriceNotationPrice_TW PriceNotationPrice
NotionalCurrency_TW NotionalCurrency_TW ExchangedCurrency1
QuantityUnit_TW QuantityUnit_TW QuantityUnit
Quantity_TW Quantity_TW Quantity
NotionalAmt_TW NotionalAmt_TW PutNotionalAmount
IntentToClear_TW IntentToClear_TW IntentToClear
PriceNotationPriceType_TR PriceNotationPriceType_TR PriceNotationPriceType
AX AX
PriceNotationPrice_TRAX PriceNotationPrice_TRAX PriceNotationPrice
NotionalCurrency_TRAX NotionalCurrency_TRAX ExchangedCurrency1
QuantityUnit_TRAX QuantityUnit_TRAX QuantityUnit
Quantity_TRAX Quantity_TRAX Quantity
TradeExecutionTimestamp_ TradeExecutionTimestamp_ TradeExecutionTimestamp
TRAX TRAX
EventExecutionDtTime_TRA EventExecutionDtTime_TRA EventExecutionDtTime
X X
ExecutionVenueID_TRAX ExecutionVenueID_TRAX ExecutionVenueID
CFICode_TRAX CFICode_TRAX CFICode

50 Processing the NPO event as new
trade if position has not been registered
with TR (DTCC-EU, Trax)
As per the existing CMRS behavior, CMRS reports any lifecycle event on a
deal to the Trade Repositories without considering whether the position is
opened at the TR's end or not. Due to this behavior TR's send multiple
NACK's in the following 2 scenarios:-
1. CMRS Reports an Amendment (Any Non Position Opener Event) to a

deal when the position is not yet opened at the TR's end. This result
in the TR sending back a Negative Acknowledgement mentioning
“No Position Exists to Amend".
2. CMRS Reports a Trade (Any Position Opener Event) for a deal when
the position is already opened at the TR's end. This result in the TR
sending back a Negative Acknowledgement mentioning "Position
Already Existing for the Deal".
In order to be able to avoid the above 2 exception scenarios CMRS will

send an event to TR (Position Opener/Non Position Opener) based on
whether a position for the reported deal exists at the TR's end or not.
Further this switching of event from a Position Opener to Non-Position
Open and vice versa will be supported at the instance level (configurable
through a flag in system configurations) and at the deal level as well.
Below System Configuration key/ Source System field can be utilized to

configure the rule at Instance/Deal level respectively.
 Instance Level Configuration> KeyName =

IsEventSwitchingRequired (TRUE/FALSE)
 Deal Level Configuration> Field Name = IsEventSwitchingRequired
(TRUE/FALSE)
Below table depicts when this rule will be turned-off/on based on the
above 2 Key’s values.
Instance Deal Level

Outcome
Configuration Configuration
Yes No Feature turned off.
Yes Yes Feature turned on.

No Yes Feature turned off.
No No Feature turned off.
The scenario sheet explaining the expected behavior is attached here for
reference.
RBS
CR-Scenarios.xlsx
All applicable* events will switch to only TRADE & AMEND events.
*This rule is not applicable for Termination, Val/Col events and the events
covered under existing Snapshot Event Switch Rule.
51 CFI Generation Rule (DTCC-EU,
DTCC-EULITE & Trax)
As part of ESMA RTS 2.0 reporting, Product classifier needs to be reported

in all the submissions. As ISDA has mapped with Products with the CFI
code and CMRS will extend the existing product setup for ESMA and will
support lookup and Generation of CFI Code.
To handle this regulatory requirement, the following fields have been

added in CMRS RegReport :
Field Data Type
GenerateCFI Boolean
CFI_Attribut String
e1
CFI_Attribut String
e2
CFI_Attribut String
e3
CFI_Attribut String
e4
CFI_Attribut String
e5
CFI_Attribut String
e6
CFI Workflow –
If If 'CFICode' is coming from source, then this will take precedence
Else If 'GenerateCFI' flag is TRUE,

then (after Enumeration are applied) concatenate the value present in the CFI
attributes
‘CFICode’ =
Concatenate(CFI_Attribute1,CFI_Attribute2,CFI_Attribute3,CFI_Attribute4,CFI_Attribut
e5,CFI_Attribute6)
Else Lookup ‘CFICode’ from Product Screen.
If ‘CFICode’ is missing an attribute?
then use the corresponding Source System attribute
merge and create ‘CFICode’
Else use the lookup value.
Refer to the below scenarios -
Produc CFICo Gene Look CFI_A CFI_ CFI_ CFI_ CFI_ CFI_ CFIC Comments
t de rateC up ttr1 Attr Attr Attr Attr Attr ode
from FI CFI 2 3 4 5 6
sourc flag from
e Prod
uct
Scre
en
Interest JRIXFC N/A N/A N/A N/A N/A N/A N/A N/A JRIXF Passed through
Rate:FR C the SS value
A
Interest BLANK Yes N/A S R A C S C SRAC Concatenate

Rate:IR SC the source
Swap:B system
asis attributes
Interest BLANK No JRIXF N/A N/A N/A N/A N/A N/A JRIXF Looked up from
Rate:FR C C Product Screen
A
Interest BLANK No HRO* N/A N/A N/A R N/A N/A HRO Fetched the
Rate:Ca VC RVC missing
pFloor attribute from
source system
Interest BLANK No HRO* N/A N/A N/A BLAN N/A N/A HRO*
Rate:Ca VC K VC
pFloor
52 Collateralization Lookup Rule
(DTCC-EU, ICE-TV EMIR)
As per ESMA RTS 2.0, Collateralization Type now needs to be reported with Collateral messages too.
In CMRS the Collateralization setup is at Asset Class level; in order to cater to the above requirement, CMRS will
be extended to support collateralization setup on Portfolio level.
A dropdown has been added to the Counterparties Screen to enable clients to setup the Collateralization Type
on a Portfolio Level.
Source system override will be supported i.e. if the value is coming from source in the field
‘TradeCollateralizationType’, then it will take precedence over the type configured in CMRS.
53 Suppress Collateralization
Rule (DTCC-EU, DTCC-EULite ICE-TV
EMIR)
As part of ESMA L3 requirements, when reporting an event with the following Action
Types, then all the related Collateral fields needs to be BLANK, else if populated, the
trade will be rejected by TR:
 M
 C
 Z
 E
 R
If ActionType(Party2 side field) is NOT IN

('N','V','P')
Then below fields needs to be BLANK
 TradeCollateralizationType
 CollateralPortfolio
 CollateralPortfolioCodeParty1
If ActionType(Party2 side field) is NOT IN

('N','V','P')
Then below fields needs to be BLANK
 CollateralizedParty2
 CollateralPortfolio2
 CollateralPortfolioCodeParty2
54 ISIN Validation Workflow (Trax
& Tradeweb)
MiFIR requires entities to report the trade that are Traded on Trading
Venue (TOTV). ESMA will publish the list of ISINs, which are TOTV, via its
Financial Instrument Reference Data System (FIRDS). Post ISIN list
extraction from ESMA, CMRS will check whether ISIN (of a trade) is present
in the list and report the trade accordingly.
Depending on the user choice, CMRS can trigger this rule at following
levels-
1. Entity Level: Option would be available at LE-CP screen

2. Deal level: Value in Validate_ISIN is True
This rule will validate the presence of trade’s ISIN in the ESMA list (XML) in
the following manner:
Step 1. Extract/download latest ISIN list from ESMA

Step 2. Set T=0
Step 3. Check ISIN availability in the ESMA List
Step 4. If (ISIN is available in the ESMA list and T<=6)
{
Report related trade to TR;

Set Trade Status = Processed;
}
Else if (ISIN is not available in the ESMA list and T<=6)

{
Set Trade Status = On-hold and T=T+1;
Error message = Deal is put On-Hold as the ISIN validation
workflow is in progress.
Rerun Validate ISIN against ESMA List Rule on the subsequent
day i.e. move to Step 3.
}
Else
{
Trade fails in CMRS
}
On Exception View screen, user can skip the deals which are On-Hold due
to ISIN validation. If user selects In-Process dropdown of Message Status,
multiple deals can be selected and marked for skipping ISIN work flow
under dropdown.
CMRS user can configure days when ISIN lists (Full File and/or Delta File)
will be downloaded and consumed. User can select days on the basis of its
requirements.
Example:
Mond Tuesda Wednes Thursda Saturda Sunda

Day ay y day y Friday y y
Delta Delta Delta File Delta Delta Delta Full
File Type File File File File File File
Files would be available on ESMA website. CMRS will download the files via
Machine to Machine Interface.
Scenarios:
Microsoft Excel
Worksheet
55 Suppress Rule for Commercial
Activity Fields (DTCC-EU, DTCC-EULite
ICE-TV EMIR)
As part of ESMA RTS 2.0 requirements, when reporting an event, 'Directly linked to
commercial activity or treasury financing' field needs to be populated when
'TradeParty1Nature' is Non-Financial Counterparty(N).
Rule for 'Directly linked to commercial activity or treasury financing' field:

If the ”TradeParty1Nature” = "F","C","O"
then 'Blank'
Else ”TradeParty1Nature” = "N"
then Pass-Through
56 Reporting Trades with only
the Key Identifier (DTCC all TRs)
In order to resolve the USI UTI conflicting scenarios at DTCCs’ end, CMRS will send
only the key identifier to the regulator as defined in CMRS even if both the Identifiers
are coming from Upstream.
By sending only one identifier, CMRS is ensuring that the position is getting created
with only 1 identifier.
Valuation messages will also be reported with the key identifier only and will no
longer be reported with both identifiers.
The Key Identifier mapping defined in CMRS is as follows:
Regulatio CMRS Reports

n
ASIC Unique Swap Identifier
CANADA Unique Swap Identifier
HKMA Unique Swap Identifier
MAS Unique Swap Identifier
EU Unique Transaction Identifier
CFTC Unique Swap Identifier

57 Balancing Services Rule
(REMIT only)
Balancing Service in the context of Natural Gas is a service provided to a
TSO via a contract for gas required to meet short-term fluctuations in gas
demand or supply. Such contracts if executed outside the Exchange are to
be reported only on ACER’s request.
57.1 Scenarios
To determine if the trade is for Balancing Service or not a flag
‘IsBalancingServiceTrade’ has been added in the interim. ‘TRUE’ in this
field means the trade is for Balancing Service, ‘FALSE’ means the trade is
not for Balancing Service. To check if the trade is Exchange Traded or not
the check will be applied on the Asset Class. If the Asset Class of the
reported trade is not ETD and ‘IsBalancingServiceTrade’ is ‘TRUE’ then the
trade will be ignored in the CMRS.
Report to
Trade ID IsBalancingServiceTrade? Asset Class
ACER
TRADE101 TRUE Commodity N
TRADE102 TRUE ETD Y
TRADE102 FALSE ETD Y
TRADE103 Blank Commodity Y
TRADE104 FALSE Commodity Y
A trade ignored due to Balancing Service Rule can be reported

on ad-hoc basis. This functionality has been provided on
Exception View Screen.
NOTE
58 Physical Delivery Threshold
Rule (REMIT only)
If the contract is for Physical Delivery with capacity below certain
threshold (less than or equal to 20 MW of natural gas) then the Trade is
not reportable if executed outside the Exchange. Such trades are to be
reported only on ACER’s request.
58.1 Scenarios
To determine if the capacity is below Physical Delivery Threshold or not a
flag ‘IsDeliveryBelowThreshold’ has been added in the interim. ‘TRUE’ in
this field means the capacity is below Physical Delivery Threshold, ‘FALSE’
means the capacity is above Physical Delivery Threshold. To check if the
trade is Exchange Traded or not the check will be applied on the Asset
Class. If the Asset Class of the reported trade is not ETD and
‘IsDeliveryBelowThreshold’ is ‘TRUE’ then the trade will be ignored in the
CMRS.
IsDeliveryBelowThreshold Report to
Trade ID Asset Class
? ACER
TRADE101 TRUE Commodity N
TRADE102 TRUE ETD Y
TRADE102 FALSE ETD Y
TRADE103 Blank Commodity Y
TRADE104 FALSE Commodity Y
A trade ignored due to Physical Delivery Threshold Rule can be

reported on ad-hoc basis. This functionality has been provided
on Exception View Screen.
NOTE
59 BOI Currency Swap Rule (BOI
only)
As per BOI requirements Currency1 needs to be ILS for asset class ‘FX’. In
case only Currency2 is ILS , swap logic gets applied swapping both
notional amounts and currencies. Also Buyer field gets changed.
59.1 Scenarios
Source System Source System Logic

Currency1 Currency2
ILS EUR This is as per regulatory requirement and no swap logic is
required
EUR ILS Swap logic needs to be applied and the BOI Notional and
the Currency fields need to be swapped.
The Buyer field will be computed as shown below -
If TradeParty1Side = "B" or "Buyer" or "Buy"
Then <Buyer> = S
else if TradeParty1Side = "S" or "Seller" or "Sell"
Then <Buyer> = B
USD EUR This trade will get ignored by the Shekel Reportability rule
Rules Summary
The below document contains the list of all the rules along with each
TR/Jurisdiction it is applicable for.
CMRS_Rules_Table.x
lsx

CMRS RegReport Rules

Uploaded by

Copyright:

Available Formats

CMRS RegReport Rules

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CMRS RegReport Rules

Uploaded by

Copyright:

Available Formats

What are the main rules discussed in the document?

What are the main rules discussed in the document?

What are some examples of how different rules would apply to trades?

What are some examples of how different rules would apply to trades?

uto

Disclaimer and Copyright

This document, the

Sapient may have patents, patent

2 INTERNAL TRADE RULE............................10

3 TRADE BETWEEN NON-US PARTIES (DF ONLY) 14

3.1 SYSTEM CONFIGURATION.........................14

4 DELEGATION RULE (EMIR, ASIC, MAS AND BOI ONLY) 15

5 INTER-AFFILIATE TRADES (DF, EMIR, REMIT AND CSA ONLY) 17

5.1 SETUP REQUIRED....................................18

6 JURISDICTION DETERMINATION (JEDI).....21

7.1 RPD RULE FOR DF.................................24

8 RERUN RPD RULE.....................................38

9.1 ERE RULE (DF AND CSA ONLY)...............41

11 ETD_POSITION_TRADE RULE (EMIR ONLY)53

12 INTERIM UTI RULE (EMIR ONLY)...............54

13 BUYER/SELLER IDENTIFIER RULE...............56

13.1 INTEREST RATE.......................................56

14 DELEGATED MESSAGE SUPPRESSION RULE (EMIR ,ASIC AND BOI ONLY) 60

15 USI/PRIOR USI RULE (DF, ASIC, MAS, AND CSA ONLY) 63

16 UNIQUE ID CREATION BY TR/APA.............65

16.1 GTR CREATE RULE (DF ONLY).................65

17 TRN GENERATION FOR MIFID-II TRANSACTION REPORTING 66

18 MANDATORY CLEARING EXEMPTION RULE (DF AND CSA ONLY) 68

18.1 EXEMPTION FOR INTER-AFFILIATE SWAPS. . .68

19 SUPPRESS 43/45 (DF ONLY)......................71

20 RT SUPPRESS FOR FX FORWARD (DF ONLY)72

20.1 SUPPRESS APPROACH..............................72

21 ORIGINATING TRADE ID SCENARIO...........73

23 UTI DELEGATION RULE (EMIR, ASIC, ,MAS AND BOI ONLY) 80

24 REPORTING ON BEHALF OF COUNTERPARTY (MIFID-II PTT ONLY) 81

25 MW EXISTS (EMIR, ASIC, AND MAS ONLY) 82

26 REPORTABLE PRODUCT RULE FOR ICE-TR..83

28 IDENTIFICATION OF SINGLE-SIDE/DOUBLE-SIDE TRADE FOR ICE-TR 85

29 SOVEREIGN ENTITIES RULE (MAS ONLY). . .86

30 AUTO RESOLVE RULE................................87

31 OTC CLEARED TRADE SWITCH RULE..........88

32 ACTION SWITCHING RULE........................90

33 DESTINATION EVENT SWITCHING RULE....92

34 REPORT UPDATED USI/UTI/PARTY IDENTIFIER 93

34.1 DTCC TRS EXCEPT OTCLITE:..................93

35 HKMA REPORTABLE RULE.........................95

35.1 SYSTEM CONFIG.....................................95

36 ASIC REPORTABLE RULE...........................97

36.1 SYSTEM CONFIG.....................................97

37 MAS REPORTABLE RULE...........................99

37.1 SYSTEM CONFIG.....................................99

38 PARTY 1 SNAPSHOT MESSAGE SUPPRESSION RULE (EMIR ONLY) 102

39 COUNTERPARTY MASKING (CFTC, CSA, MAS, ASIC, HKMA) 103

40 SHEKEL YIELD RULE (BOI)........................104

41 FX SPOT REPORTABILITY RULE................107

42 RT MESSAGE SUPPRESSION RULE (CFTC ONLY) 108

42.1 RT SUPPRESSION FOR PRIME BROKER DEAL108

43 CLEARING THRESHOLD LOOKUP LOGIC (ESMA ONLY) 109

44 RULE FOR DETERMINING LEVEL (ESMA ONLY) 110

46 FILTERING NON-REPORTABLE EVENTS (MIFID-II TRANSACTION & PTT ONLY) 114