DTCC GTR OTC Lite Guide (Manuel) de l’utilisateur/media/Files/Downloads/Data-and...d’ESMA . Ce document concerne la proposition d’implémentation de la part de DTCC GTR concernant

DTCC Product Management GTR OTC Lite User Guide

DTCC GTR OTC Lite User Guide French.docx6

Copyright © 2010-2013 by DTCC Deriv/SERV LLC Page 1 of 68

DTCC GTR "OTC Lite" Guide (Manuel) de l’utilisateur

Février 2014

L’ Autorité Europeenne des Marchés Financiers (ESMA) bien qu’il n’a pas donné son accord concernant ce document, les informations cités dans ce guide , ne sont pas sous peine de sanction de la part d’ESMA . Ce document concerne la proposition d’implémentation de la part de DTCC GTR concernant la déclaration des transactions des entreprises , en accord avec les règles (exigences) imposées par l’EMIR. Les utilisateurs de ce guide doivent être conscient qu’ils ne recevront pas l’aval d’ESMA par rapport à ce document. Ce document devrait être consulté en s’aidant du OTC-LITE Business Requirements document.

https://dtcc.com/




1 Overview – Vue d’ ensemble .................................................................................................... 6

1.1 Introduction ..................................................................................................................... 6

1.2 Page d’ accueil de GTR ....................................................................................................... 6

1.3 Global Processing Overview ............................................................................................... 8

1.3.1 Saisie du fichier .......................................................................................................... 9

1.4 GTR Connectivité ............................................................................................................. 9

1.4.1 L’ Accès aux Centre des Données et Sécurité ................................................................... 9

1.5 GTR Prérogatives..............................................................................................................10

1.5.1 Web GUI Prérogatives ...............................................................................................10

1.5.2 Secure FTP Prérogatives ..............................................................................................11

1.6 Procédure de connéxion dans le GTR ..................................................................................11

2 . Soumissions de marchés ........................................................................................................13

2.1 Procédure de chargement dans le GTR ................................................................................13

2.2 “OTC Lite” Cross Asset Messaging.......................................................................................15

2.2.1 “OTC Lite” Message Template......................................................................................16

2.2.2 Valuation et Collatéral Compte-rendu ...........................................................................16

2.2.3 GTR CSV Message Pied de page (Footer) Fichier .......................................................16

2.4 Utilisation du Message.................................................................................................18

2.4.1 Compte-rendu d’ une nouvelle transaction ...................................................................18

2.4.2 Compte-rendu d’ un Evénement post-marché ...............................................................19

2.4.3 Compte-rendu d’un exit de la transaction .....................................................................19

2.5 Lifecycle Event Reporting (Compte-rendu des événements pendant la durée du contrat) Lifecycle Event Reporting ....................................................................................................................20

2.5.1 Correcting Life Cycle Events (Correction des événements pendant la durée du contrat).......20

Le tableau au-dessous récapitule des événements supportes (permis) par le GTR. ......................21

2.6 Flux des Messages ..........................................................................................................22

2.6.1 DIAGRAMME 1 .........................................................................................................23

2.6.2 DIAGRAMME 2 .........................................................................................................24

2.6.3 DIAGRAMME 3..........................................................................................................25




2.6.4 DIAGRAMME 4 .........................................................................................................26

2.6.5 DIAGRAMME 5..........................................................................................................27

2.6.6 DIAGRAMME 6 .........................................................................................................28

3 Message Validation ............................................................................................................29

3.1 Etapes de la validation ...................................................................................................29

3.2 Business validation ...........................................................................................................29

3.3 Validation de l’ESMA Régulateur........................................................................................29

3.4 Réponse des Messages ...................................................................................................30

3.4.1 CSV-Batch Download Rapport (Spreadsheet Download Rapport) ......................................30

3.5 Warning Report disponible fin de journée ...........................................................................30

3.5.1 Des Règles de Génération ..........................................................................................31

4. Dual-sided reporting (Des Rapports de deux parties) ..................................................................31

4.1 Introduction ......................................................................................................................31

4.2.1 Règles pour un compte-rendu Independent.................................................................33

4.2.2 Règles pour un compte-rendu Full Délégation ...............................................................33

4.2.3 Delegated Reporting Functionality Matrix......................................................................35

5. Identification du marché .......................................................................................................36

5.1 Introduction de l’UTI & Principes appliqués par le GTR pour “OTC Lite” .................................36

5.2 Le Flux en amount ...........................................................................................................37

5.3 Blocage de l UTI .............................................................................................................37

5.3.1 Exceptions de Blocage de l’ UTI: ..................................................................................38

6 Inter-TR Reconciliation ..........................................................................................................39

6.1 Trade Pairing ...................................................................................................................39

6.2 Trade Matching ...............................................................................................................40

6.2.1 Champs et Règles ......................................................................................................41

7 Compte-Rendu du Participant.................................................................................................45

7.1 Télécharger les Rapports à travers le Portal..........................................................................45

7.2 Des Rapports disponibles pour tous les Types d’Actifs...........................................................46

7.2.1 ACK/NACK.................................................................................................................47

7.2.2 Warning Report .........................................................................................................49




7.2.3GTR ESMA OTC Position Report.....................................................................................51

7.2.4GTR ESMA OTC Activity Report .....................................................................................54

7.2.5 ESMA Match Status Report .........................................................................................55

7.2.6 ESMA UTI Conflict or Pair LEI Break Report ..............................................................57

8 Appendix A – Des Liens Pratiques ..........................................................................................58

8.1 Contexte réglementaire...................................................................................................58

8.1.1 ESMA Définitif Projet de normes techniques.................................................................58

8.1.2 Résumé des normes techniques d ‘ ESMA ....................................................................58

8.1.3 EMIR vs. DFA Comparaison .......................................................................................58

8.1.4 ESMA Questions et Réponses ..................................................................................58

8.1.5 ISDA matériel sur la cotation des prix ..........................................................................58

8.2 Business Requirements Document ....................................................................................58

8.3 CSV Chargement du Template.........................................................................................58

8.4 OTC Lite Presentations et Videos ....................................................................................58

8.5 ISDA Taxonomie..........................................................................................................59

8.6 International sFTP Transmission Guide v1.0 ....................................................................59

8.7 Contact List pour OTC Lite ...........................................................................................59

9 Appendix B – Questions les plus fréquentes (FAQs) ....................................................................60

9.1 Sur quel plan géographique et juridictionnel s’ applique OTC Lite? ....................................60

9.2 Qui peut utiliser OTC Lite service?......................................................................................60

9.3 Est-ce qu‘on peut envoyer plusieurs fichiers dans la journée? ...........................................61

9.4 Quels sont les champs optionnels qui doivent être saisies? ...............................................61

9.5 Est-ce que le champ “Trade Party 2 « doit être rempli, quand le modèle de soumission est Indépendant ? ......................................................................................................................62

9.6 Comment je peux soumettre des produits exotiques et structurés? ............................62

9.7 Quel est l horaire du système opérationnel DTCC? ..........................................................62

10.1 Cross Asset Guidance ((Matériel sur les actifs) ...............................................................63

10.2 Technical Guidance(Matériel Technique) .........................................................................64

10.3 Technical Guidance(Matériel Technique) Valid Values ......................................................64

10.4 Interest Rates (Taux d interet) .........................................................................................65




10.5 Commodities................................................................................................................66

10.6 Foreign Exchange (Taux de change) ..................................................................................66

Revision History Version Date Revision V0.1 October 30, 2013 Initial Draft V0.2 November 30,

2013 Revisions New Screenshots

V0.3 December 11, 2013 Revised Position Report Table V0.4 December 12, 2013 Revised Q and A section V0.5 January 14, 2014 Updated 2.1 GTR Upload Process with new screen shots

Added 2.2.1 GTR CSV File Footer Message Added 2.5.1 Correcting Life Cycle Events Updated 3.5 EOD Warning Report Added 6 Inter-TR Reconciliation (Includes Trade Pairing and Trade Matching) Updated 7.2.2 with Warning Error Codes Added 7.2.5 ESMA Match Status Report Added 7.2.6 ESMA UTI Conflict or Pair LEI Break Report Added 8.1.4 ESMA Q&A Link Added 8.1.5 ISDA Guidance on Price Notation Added 8.6 International sFTP Transmission Guide v1.0 Added additional Q&As in Section 8 Added 10 DTCC Best Practice for Uploading




1 Overview – Vue d’ ensemble

1.1 Introduction

La chambre de compensation et dépositaire américaine central / Depository Trust & Clearing Corporation (DTCC) fournit a l’industrie un point central de communication et de stockage pour les OTC Lite dérivatives parmi ces classes d’ actifs (Crédit, Capitaux (Fondes) propres, taux d'intérêt, commodités et taux d’échange et puis des dérivatives des marchées d’échange qui peuvent être reportés a EMIR. GTR accepte tous les marchées de chaque entité de marché dans tout le monde (ou ses agents) pour toutes les transactions globales qui peuvent être reportées aux régulateurs.

Pour compléter l’offre de GTR de “OTC Lite” service il y a aura un autre service de rapports qui permettra aux entreprises de reporter leurs OTC transactions dérivatives qui doivent être soumisses à EMIR. La solution, permet de rapporter des positions, des évènements de marché et des données d’évaluation pour chaque position et engagement financier. Ce service est basé sous une seule juridiction, ayant comme seule fonction celle de rapporter à l’ESMA. Toutes les transactions concernant les produits dérivatives pour toutes les classes d’actifs peuvent être reportées en utilisant un simple Template. Chaque partie engagée dans une transaction est dans l’obligation de reporter à l’ESMA. Une partie peut déléguer la responsabilité de rapporter à une 2ième ou 3ième partie. “OTC Lite” offre des soumissions indépendantes (des rapports pour seulement une partie) ou délégués (des rapports dans lesquels la déclaration est faite pour les deux parties). Cela sera expliqué plus en détail à la suite de ce guide.

1.2 Page d’ accueil de GTR

Des informations additionnelles et utiles pour la compréhension de ce guide peuvent être trouvées dans les documents disponibles dans le portal GTR. Ce GTR document abrite les derniers documents techniques et commerciaux qui sont conçu pour aider les utilisateurs à comprendre les exigences du système. Le portal est divisée en sept sections qui sont décrites ci-dessous. http://dtcc.com/data-and-repository-services/global-trade-repository/gtr-europe/client-center.aspx Login information Contactez s’ il vous plait, votre responsable de relations d’affaires , pour obtenir votre numéro de compte et password.

http://dtcc.com/data-and-repository-services/global-trade-repository/gtr-europe/client-center.aspx







The GTR Release Notes dropdown contient des notes qui sont mises à jour une fois par semaine détaillant les modifications de code qui ont été faites et qui seront mises en place dans le Testing (UAT) et Production. En plus, une section qui s’appelle Release Notes fournit des informations concernant les mises à jour de GTR. Le Product Training and Support dropdown contient des documents décrivant les différentes fonctions, business FAQ’s (questions les plus posés) et le comportement et pratiques recommandés (best practices) pour utiliser le GTR. Cette section est sous-divisée en classes d’actifs et chaque document est catégorisé selon son appartenance à tel actif. Le Business Requirement Documentation dropdown menu contient des documents qui décrivent les règles à suivre.

The UAT Documentation dropdown contient des documents qui sont pertinents et actuel pour Testing. The Supported - Spreadsheet and Messaging Specs dropdown contient des templates et des documents techniques qui décrivent la fonctionnalité de GTR qui est actuellement disponible dans le Testing environnement et Production. The Future - Spreadsheet and Messaging Specs dropdown contient des templates et des documents qui décrivent les fonctionnalités à venir et ne sont pas encore disponible ni dans le Testing ni dans l’environnement de Production. Les Documents de cette section sont toujours sous discussion dans des groupes de travail de DTCC ils sont prévus d’être implémentés dans l’environnement du Testing et de Production. Global Repository On-Boarding section contient GTR onboarding documentation. Connectivity section contient des guides qui décrivent des méthodes qui sont disponibles pour pouvoir se connecter à GTR.

1.3 Global Processing Overview

Le service de “OTC Lite” ne rend compte qu‘ au centre des données européennes (EU datacenter -“EUDC”). Cela signifie que sFTP et web-upload devront être transmis à EUDC pour le traitement des données. Les entreprises peuvent se connecter directement a EUDC ou utiliser la connectivité qu’ils possèdent déjà pour USDC mais avec l’exception que chaque dossier envoyé par via sFTP sera acheminé à EUDC en conséquence du GTR Product ID signale. Les diagrammes ci-dessous montrent les options de connectivité pour l’ensemble de GTR. A signaler ,s’il vous plait , que le CSV fichier reçu via sFTP pour “OTC Lite” sera soumis seulement à la connectivité européenne.




1.3.1 Saisie du fichier

Soumissions des CSV fichier via FTP ou Web Upload sera fait selon GTR Produit ID pour soumissions des fichiers. CDTS recherchera le fichier dans le système des fichiers et selon son GTR Produit ID le fichier sera envoyé à l’EUDC pour le traitement.

1.4 GTR Connectivité Les participants qui s’abonnent a “OTC Lite” service peuvent soumettre des informations concernant les marchés OTC à travers ces différents canaux:

• Web GUI, en utilisant des fichiers CSV (comma separated values) upload • SFTP, en utilisant des fichiers CSV

1.4.1 L’ Accès aux Centre des Données et Sécurité

L’Accès à EUDC est séparé et différent des autres, et sera fourni par un nouvel URL. Pour que les utilisateurs puissent accéder a EUDC URL, ils auront besoin du nouveau Global Login ID qui est différent du Web ID. Tous les utilisateurs enregistrés qui souhaitent obtenir l’accès a Global URL’s, doivent obtenir un 2ième Global Login ID en plus, de leur Web ID. Le Web ID que vous possédez déjà ne vous donnera pas l ‘accès au Global URL’s, de même, le Global Login ID’s ,ne vous permettra pas d ‘ accéder dans le système des Etats Unis US URL. les utilisateurs déjà enregistrés , seront obligés de demander l’accès au nouveau Global Login ID a leur Super Access Coordinator (SAC). Le SAC sera capable de leur fournir leur nouveau Global Login ID’s. Global ID’s suivra l’actuel format du Web ID.




1.4.1.1 Restrictions SAC – CRS peut être accédé seulement à travers les URL américains. Les fonctionnalités des SAC

déjà existants continueront à être supportées par US URL Global Login ID – ne peut pas être autorisé comme un SAC ou AC comme tous les deux

fonctions ne sont accessible que à travers US URL. UAT –Les nouveaux utilisateurs et ceux qui sont déjà enregistrés doivent s’enregistrer dans

l’URL de l’UE pour avoir accès au Testing.

1.5 GTR Prérogatives

1.5.1 Web GUI Prérogatives

Le GTR web système est accessible , via les liens utilisés pour accéder à DTCC Customer Portal. Tous les nouveaux utilisateurs ont été fournis avec des login ID’s, mots-de-passé afin de pouvoir accéder au système de Global Trade Repository. Des portales régionaux séparés sont disponibles via chaque centre des données pour accéder au GTR web system. Des sign-on séparés et des mots-de-passe sont demandés pour accéder à chaque portal.

Chaque login ID est associé avec un GTR Entity/Participant Grouping code (O-Code), quatre digits code utilisé pour identifier l’organisation de l’utilisateur. Un participant recevra des O-Codes pour chaque service demandé .Les positions rapports sont créés au niveau des O-Codes; donc tous les entités qui sont groupés sous les mêmes O-Codes apparaitront dans le même position rapport.

Les utilisateurs déjà enregistres en DTCC peuvent utiliser leur actuel login ID’s et mots-de-passe pour accéder a GTR Submission and Reporting systeme; néanmoins chaque utilisateur devra avoir un des rôles cités auparavant définit par leur actuel login ID’s, et le mapping réalisé par rapport à leur nouveau Entity/Participant Grouping Code (OCode).

Les entreprises qui sont déjà enregistrés à DTCC et qui ont assigné au moins deux ‘access coordinators’ peuvent designer au sein de leur entreprise les utilisateurs pour les DTCC web produits. Le système de GTR est configuré pour permettre à chaque accès coordinateur d’une entreprise de donner les droits d’accès pour la web GUI a d’autres utilisateurs de son entreprise. Les rôles de l’utilisateur et régulateur sont bien définis dans le GTR.

1.5.1.1 Participant (utilisateurs}

• Les Utilisateurs au nom de leur compagnie ont la possibilité d’envoyer les données à GTR en utilisant le portlet, sous forme de chargement de CSV fichiers Cette option de upload est présente dans le GTR tableau de bord . Les utilisateurs peuvent vérifier le statu de leurs soumissions en déchargeant sous forme de fichiers les rapports, dans lesquels, ils peuvent voir leurs batches uploaded. Cela s’applique aux CSV soumissions qui ont été chargés via Web GUI ou Secure FTP. Uniquement les “OTC Lite” soumissions seront




indiquées sur les batch rapports (connus également comme les ACK et NACK batch output rapports)

� Les utilisateurs ont la possibilité de voir les rapports sur les entités, à condition que celles-ci leur a donné l’autorisation. � Tous les marchées qui ont été soumis dans “OTC Lite” service dans EUDC seront inclus dans les rapports utilisateur générés dans le centre des données.

1.5.1.2 Regulateur

Les régulateurs peuvent consulter les rapports GTR à travers le portlet. Les rapports par classe d ‘ actif sont disponibles dans le tableau de bord.

Les régulateurs en obtenant l’autorisat ion de l Ent ity, Regulator Type et Regulator Mapping qui a été soumisse en SDO peuvent consulter donc les rapports Regulators Seulement les transactions qui ont été définies comme étant dans l’obligation d’être reportées, seront inclues dans le rapport régulateur qui leur correspond .Par exemple toutes les transactions ouvertes en EUDC seront inclues dans le rapport de l’utilisateur généré par EUDC, par contre, seules les opérations ayant l’obligation d’être reportées a ESMA seront inclues dans le Régulateur rapport généré par EUDC.

DTCC supporte ces services à travers SMART network, ainsi que SWIFT et BT Radianz networks. Pour plus d’information sur DATATRAK et Autoroute vous pouvez consulter GTR Client Center (Section 1.2) , puis vous devez sélectionner connectivity dans la liste déroulante pour obtenir l’information.

1.5.2 Secure FTP Prérogatives

Les utilisateurs qui donnent des informations concernant leurs transactions à GTR, recevront un Secure FTP pour leurs fichiers CSV. Pour soumettre à travers Secure FTP, il faut passer par DATATRAK et Autoroute qui sont des file input and output management sous-systèmes de DTCC. Ils permettent à DTCC et à leur utilisateurs une ligne sécurisé et fiable d’échange de fichiers à travers le network.

DTCC supporte ces services à travers SMART network, ainsi que SWIFT et BT Radianz networks. Pour plus d’information sur DATATRAK et Autoroute vous pouvez consulter GTR Client Center (Section 1.2) , puis vous devez sélectionner connectivity dans la liste déroulante pour obtenir l’information.

1.6 Procédure de connéxion dans le GTR

Ci-dessous des captures d’écran qui vous montrent comment se connecter a OTC Lite.




1. Cliquez sur ce lien: https://gtr.eu.dtcc.com

2. Demande de votre Login et Mot de passé. Rentrez votre user ID et mot-de-passé et cliquez sur Login.

3. Sélectionnez OTC lite à partir du DTCC page d’accueil. Cela ressemble au lien ci-dessous concernant le GTR (Global Trade Repository).

https://gtr.eu.dtcc.com/




2 . Soumissions de marchés

2.1 Procédure de chargement dans le GTR

Les screenshots ci-dessous décrivent comment télécharger manuellement les fichiers CSV dans le système.

1. Cliquez sur: http://dtcc.com/data-and-repository-services/global-trade-repository/gtr-europe/client-center/client-center.aspx?gated=customers

Contactez [email protected] pour des renseignements concernant le login.

L’équipe de service clientèle GTR met à votre disposition la documentations, le support technique, l’éducation et working-group, des informations pour les participants, régulateurs et fournisseurs de l'industrie.

2. Quand vous vous connectez, choisissez Supported - Spreadsheets and Messaging Specs. Tous les messages templates qui sont disponibles sous Supported - Spreadsheets and Messaging.Specs. Tous les messages templates qui se trouvent en UAT sont disponibles à Future - Spreadsheets and Messaging.Specs.

http://dtcc.com/data-and-repository-services/global-trade-repository/gtr-europe/client-center/client-center.aspx?gated=customers

http://dtcc.com/data-and-repository-services/global-trade-repository/gtr-europe/client-center/client-center.aspx?gated=customers

mailto:[email protected]




3. Cliquez sur le spreadsheet(Template) que vous souhaitez telécharger (par exemple OTC Lite Upload Spreadsheet).

4. Connectez-vous au portail pour accéder à OTC Lite. Sélectionnez l’option participant dans le drop down menu. Saisissez votre Code participant, puis sélectionnez votre O-Code dans le drop down menu.

5. Le tableau de bord affiché vous donne la liste la plus récente, des batch concernant les soumissions que vous avez effectué au- près de GTR. Cliquez sur upload. La page que vous voulez chargez apparaitra.




6. Cliquez sur upload, utilisez les moyens de navigation disponibles pour localiser et sélectionner le spreadsheet que vous souhaitez upload (Charger) vers le système.

7. Cliquez sur Upload

2.2 “OTC Lite” Cross Asset Messaging

Les différents types de message qui vont suivre, et qui sont supportés en “OTC Lite” service concernent les actifs.

Message Type Description

Position Le message est utilisé pour reporter “point-in-time” la date de mise à jour du contrat ou quand la transaction a été ouverte. Point-in-time montre l’état du contrat, cela comprend les changements ou les mises à jour de la transaction. Ce type de message est similaire à celui du principal GTR service qui supporte le type de message “Snapshot”.

Valuation* Le message est utilisé pour rapporter l ’évaluation actuel du contrat dans le marché. L´ évaluation est soumise quotidiennement pour les transactions qui doivent être reportes.

Collateral Valuation*

Le message est utilisé pour reporter les portfolios collatéraux qui sont l iés a des transactions individuels.

*Have a compliance date of August 11th 2014 Date de conformité 11 août 2014.




2.2.1 “OTC Lite” Message Template Le message template est désigné pour remplir les conditions requises par l’EMIR, celui contient des champs qui sont spécifiques seulement pour EMIR RTS. Ce template possède également des champs qui doivent être obligatoirement remplis pour que la soumission au près du GTR soit acceptée et que la transaction soit correctement traitée. Le Template est un simple CSV format fichier qui contient 28 control fields (la plus part de ces champs sont obligatoires pour chaque message) et 128 EMIR champs spécifiques (avec des champs concernant la délégation a trade party 2 pour faire la soumission). Chaque type de message peut être soumis sur le même template pour les champs N/A ou Optional nous pouvons les laisser vides (comma-separated) et GTR acceptera, comme même, le message. A signaler : Les reportings parties ont la responsabilité de s’ assurer que tous les champs concernant l’ EMIR sont saisies avec des informations précises et complètes .GTR impose beaucoup de champs qui sont obligatoires à remplir ,mais il y a également des champs qui sont optionnels , qui ne demandent que des informations(Common data) concernant la nature de la transaction ( détails économiques de la transaction) .La partie en charge de la soumission , peut la rapporter dans un délai de T+1 UTC a un TR (Trade Repository ) qui suit les règles de l ESMA . Cependant il existe des cas dans lesquels il manque des informations (Data) . Dès que le data est disponible la partie qui reporte doit faire la mise à jour de la transaction dans le GTR. Tout champ se référant à EMIR dans le message template devrait être saisie, si disponible ou applicable.

2.2.2 Valuation et Collatéral Compte-rendu La soumission concernant les messages de valuation et collateral seront mis en place dans 180 jours après la date de début des déclarations des transactions. La description et détails des soumissions concernant la valuation et collateral seront inclus ultérieurement.

2.2.3 GTR CSV Message Pied de page (Footer) Fichier *OCOD-ENDnnnnnnnn Example: *DTC0-END00054321 GTR Footer (Trailer) Field

GTR Value Length

Constant1 * Il doit contenir astérisque (ce champ est constant). 1 Originator Il contient 4 caractère ORIGINATOR ID qui est assigné à votre

compte comme une partie de GTR onboarding processus. DTC0 est utilise dans notre exemple au-dessus. Champ Constant2: - END (c’est constant)

4

Constant2 - END (c’est constant)

4

Record Count Ce champ compte des lignes (marches) dans le fichier excluant des lignes de comment. Celui-ci doit être capitonnée avec nulles. Dans

8




l’exemple au-dessus nous utilisons 00054321. Sample File (example for information purposes only) Chaque CSV fichier doit contenir un footer message. Le fichier footer (trailer) contient les informations nécessaires pour que le GTR puisse procéder. Le footer message ci-dessous doit être présent dans tous les fichiers CSV qui seront soumis au GTR via SFTP ou Web .Pour les soumissions via SFTP d’ autres entêtes (Headers) et trailers sont requis mais ce footer message doit être également inclus. L’exemple ci-dessous doit contenir un fichier de 4 lignes avec des datas. La ligne commentaire et le fichier footer ne sont pas pris en compte dans le calcul de lignes. A remarquer : Le fichier footer est une valeur. Par exemple quand vous préparez votre SFTP fichier vous devez suivre ce format : DataTrak Header Application Header Le format du footer message ci-dessous : *Comment Line ,Data,Data,Data,Data

,Data,Data,Data,Data



*DTC0-END00000004 By Par exemple quand vous préparez votre SFTP fichier vous devez suivre ce format : DataTrak Header Application Header *Comment Line ,Data,Data,Data,Data ,Data,Data,Data,Data ,Data,Data,Data,Data ,Data,Data,Data,Data *DTC0-END00000004 DataTrak Trailer

2.3 GTR Information sur le temps d’ intérruption des Batch Les transactions qui doivent être rapportées a ESMA doivent être soumise dans un Trade Repository, au plus tard ,T+1 après conclusion , modification ou terminaison de la transaction. Pour tous les actifs la




limite pour le Batch Reporting dans EUDC est 23 :45 Coordinated Universal Time (UTC) .Cinq cycles de Batch Reporting s’effectueront tout au long de la semaine aux heures indiquées ci-dessous.

Business Day EUDC Submission Cut-off EUDC Batch Run Monday 23:45 UTC Monday 00:00 UTC Tuesday Tuesday 23:45 UTC Tuesday 00:00 UTC Wednesday

Wednesday 23:45 UTC Wednesday 00:00 UTC Thursday Thursday 23:45 UTC Thursday 00:00 UTC Friday

Friday 23:45 UTC Friday 00:00 UTC Saturday

2.4 Utilisation du Message

La partie ci-dessous décrit comment on doit rapporter une nouvelle transaction, ses changements et comment utiliser l’action exit. Trade Event colonne définit les évènements qui se sont produits dans le contrat. Types de messages : Action, Transaction Type et Lifecycle Event colonnes se référent aux champs que vous allez soumettre lors du message entrant. ESMA Action se réfère de quelle manière le message sera rapportée à ESMA. OTC Lite message template peut être utilisée pour rapporter Interest Rate, Credit, Foreign Exchange, Equities et Commodity OTC produits dérivés. Les tableaux ci-dessous sont applicables pour toutes les classes d’actifs á moins que dans le message entrant on choisit la valeur cancel, qui sera rapporté comme erreur a l’ESMA.

Asset Class Message Type Action Transaction Type

Lifecycle Event

ESMA Action

All Any* New PositionCancel N/A Error *Any refers to any message type and transaction type where Cancel applies

2.4.1 Compte-rendu d’ une nouvelle transaction Les combinaisons de type de message, types d’activités et transactions peuvent être utilisés pour rapporter un nouveau contrat.

Trade Event* Message Type

Action Transaction Type** Lifecycle Event ESMA Action

New Trade Position New Trade Trade or New New Backload Position

New Backload or Trade N/A or

Backload New

Novation Trade (a New Trade as a result of a novation)

Position New Trade Novation-Trade

New

* Allocated, Cleared et Unallocated Block contrats seront rapportés comme une nouvelle Transaction.

** Multiple Transaction Types donnent la possibilité aux utilisateurs de décider qu’elle est la meilleure option selon leur système flow.




2.4.2 Compte-rendu d’ un Evénement post-marché Les combinaisons de type de message, types d’activités et transactions peuvent être utilisés pour rapporter Trade events.

Trade Event Message Type

Action Transaction Type

Lifecycle Event ESMA Action

Amendment Position New Trade Amendment New Modification Position New Trade Modify Modify Increase Position New Trade Increase New Partial Novation Position New Trade Novation Cancel Termination Position New Trade Termination Cancel Partial Termination (FX and Credits only)

Position New Trade PartialTermination Cancel

Fee Amendment Position New Trade Amendment New Compression* (original trade part-terminated)

Position New Trade Compression Compression

Succession (Credit only) Position New Trade CreditEvent New Credit Event (Credit only) Position New Trade CreditEvent New Partial Exercise (FX only) Position New Trade PartialExercise Cancel Exercise Position New Trade Exercise Cancel Corporate Action Position New Trade CorporateAction New * Un nouveau contrat créé par le résultat d’une compression devrait avoir le champs “Compression” saisie avec la valeur true

2.4.3 Compte-rendu d’un exit de la transaction Les combinaisons de type de message, types d’activités et transactions peuvent être utilisés pour supprimer un contrat qui déjà existe.

Trade Event Message Type

Action Transaction Type

Lifecycle Event ESMA Action

Full Termination Position New Exit or Trade Termination Cancel Full Novation Position New Exit or Trade Novation Cancel Compression (original trade terminated)

Position New Exit Compression Compression

Exercise Position New Exit Exercise Cancel Partial Exercise (FX Only)

Position New Exit or Trade Partial Exercise Cancel

Exit Position New Exit Exit Cancel Position Cancel Position New PositionCancel N/A Error A noter que la Position Cancel supprimera la position comme si elle n’avait jamais existé. Le UTI peut être encore utilisé si il n’a pas été bloqué par la soumission de la 2ième partie. Le Exit message est quand le contrat n est plus dans une live position(il n’y a pas besoin d’effectuer un exit quand le contrat arrive á maturité). Quand un changement se produit dans le life cycle event, cela nous conduit à un exit message. La soumission d’un exit message est suffisant pour rapporter ces objectifs.




2.5 Lifecycle Event Reporting (Compte-rendu des événements pendant la durée du contrat) Lifecycle Event Reporting

Life-cycle events sont des changements effectués sur le contrat d’ origine qui ont été réalisés dans la durée du contrat .Pour les Contrats qui sont sous la juridiction dÉMIR, il est nécessaire de sássurer que les rapports soient chargés non seulement a end-of-day state of trades, mais que le champ event log soit saisie pour déclarer les changements qui ont été opérés dans la journée. Cela peut être achevé en reportant une série de interim trade ayant comme position snapshots.

2.5.1 Correcting Life Cycle Events (Correction des événements pendant la durée du contrat)

Pour certains produits OTC, il peut avoir des changements dans leurs lifecycle events.Il se peut qu‘une partie puisse soumettre un lifecycle event par erreur. Le tableau ci-dessous a pour but de vous montrer comment corriger un lifecycler event rapporté par erreur.

Premiers fichiers envoyés au GTR: File No.

Event Lifecycle Event Field

Trade Amount

Notional As of Date Time Comment

1 New Purchase Trade 10M 10M 01-May-2014 T09:00 Logging in position 1 Partial Unwind Termination 2M 8M 01-May-2014 T14:00 Termination 1 2 Partial Unwind Termination 2M 6M 02-May-2014 T10:00 Termination 2 3 Partial Unwind Termination 2M 4M 03-May-2014 T10:02 Termination 3

Termination 1 dans le fichier 1 doit-être cancellé : File No.

Event Lifecycle Event Field

Trade Amount

Notional As of Date Time Comment

4 Error 8M 01-May-2014 T14:00 Tell ing DTCC the 1st partial unwind should be cancelled

5 Modify 8M 02-May-2014 T10:00 Bringing the remaining notional back to 8M as the 1st unwind is cancelled

6 Modify 6M 03-May-2014 T10:02 Bringing the remaining notional back to 6M as the 1st unwind is cancelled

7 6M Current Time To make sure the latest position is updated




Le tableau au-dessous récapitule des événements supportes (permis) par le GTR. Business Event Lifecycle Event

New Trade Trade New

Amendment Amendment Backload Backload

Termination resulting from compression

Compression Termination (for all asset class) PartialTermination (Credit) (with compressed flag indicator true) Amendment (Rates and Commodity) (with compressed flag indicator true)

Exercise (Full)~ Exercise Exercise (Partial) PartialExercise (FX)

Increase Increase Amendment (Rates)

Novation Full (Stepping out & remaining parties)~ Novation Termination (Rates)

Novation Partial (Stepping out & remaining parties) Novation Termination (Rates)

Novation (Stepping in & remaining parties) Novation-Trade NovationTrade

Termination Full~ PartialTermination (Credit) Termination

Termination Partial PartialTermination (Credit and FX) Termination (Rates, Equity, Commodity)

Valuation Update N/A

Global Cancel (Withdrawing the trade) Cancel Error

Exit or AutoExit Exit Corporate Action CorporateAction (Equity) Fee Amendment Amendment

Credit Event Termination Exit

Modify Cancel Error




2.6 Flux des Messages

Le flux du message, dans les sections à suivre, est basé á partir des conditions citées ci-dessous : • Les deux parties de la transaction sont dans l’obligation de rapporter sous l’EMIR.il y aura des

variations pour chaque flux de travaux dans les situations dans lesquelles une partie n’a pas l óbligation de rapporter ou elle doit rapporter dans une autre juridiction.

• Quand la transaction est déclarée par une 3ème partie, celle-ci génèrera et avisera les deux parties au sujet du UTI.

• Quand il y a une confirmation que la transaction sera rapportée par une 3ème partie, celle-ci génèrera et avisera les deux parties au sujet du UTI ou elle peut également négocier avec les deux autres parties au sujet de l UTI.

• Quand une transaction bilatéral ,qui a déjà été exécuté , doit être traitée par un CCP, celui-ci créera deux nouvelles transactions , sera en charge de les rapporter en utilisant des UTI différents mais il créera un lien entre ces nouvelles transactions et l’ original ,en utilisant the Prior _UTI champ .

• Quand il y a un accord de clarification avant l’exécution de la transaction, le CCP génèrera et rapportera deux différents UTI

• Pour utiliser OTC Lite service, L’UTI est indispensable pour faire les soumissions . Si l’ UTI doit être corrigé ou changé , alors le message en cours doit être mis en position Exit , et un nouveau message devra être soumis .(Signalez dans le champ Prior UTI , l’ancien UTI utilisé dans le message sur lequel on a fait exit .)

• D’autres parties (CCP et autres parties) peuvent être en charge de la soumission au nom de l’entité, mais pour cela ils ont besoin d’avoir les accès et les permissions pour faire la soumission. Quand c’est seulement les parties A et B qui sont responsables de la soumission, seule la partie qui fait la soumission recevra les rapports ACK. Celui qui rapporte , recevra toujours les ACK quelle que soit sa situation dans la transaction .

• Si les deux CP sont des utilisateurs en GTR ils pourront recevoir leur EOD rapports dans lesquels ils pourront vérifier par le UTI dans quelles transactions ils ont été citées comme contrepartie.

Bi-lateral On-facility

Non-cleared Cleared Non-cleared Cleared

Reporting Model Paper Confirm M/ware Conf/Aff M/ware Conf/Aff independent 1 4 6 Full Delegation 3 2 5




2.6.1 DIAGRAMME 1 Exécution Bilatéral ; confirmé par la 3eme Partie; Mais pas déclaré; Les deux parties rapportent indépendamment (no delegation)

• A signaler : Seul le Message Template, sous forme csv sera accepté, pour toutes les parties, même la 3ème, si elle doit rapporter pour les deux parties, elle doit utiliser le format CSV et les conditions expliquées au paravent au sujet des méthodes de soumission.

Etapes du procès: 1. Parties A& B accord bilatéral de la transaction. 2. Les parties envoient la transaction à la plateforme de la 3eme partie. 3. La 3eme partie crée un UTI et le propose aux contreparties. 4. Party A soumis un Position message au GTR pour lui- même. 5. Party B soumis un Position message au GTR pour lui-même. 6. GTR renvoi un ACK a Party A et Party B respectivement. 7. Party A envoie un Valuation message 8. GTR envoie un ACK à Party A 9. Party A envoie un Collateral message 10. GTR renvoie un ACK à Party A 11. Party B envoie un Valuation message 12. GTR renvoie un ACK a Party B 13. Party B envoie un Collateral message 14. GTR renvoie un ACK a Party B

Dans l ‘exemple ci –dessus si la 3eme partie est capable de soumettre le CSV fichier, alors la 3ème partie peut rapporter la position message pour les deux parties in step 4 & 5(et la 3eme partie recevra le rapport ACK a la place des parties A et B step 6).

1 Party A

Party B

Middleware

2,3 2,3

TR

5,11,13 4,7,9 6,8,10

6,12,14




2.6.2 DIAGRAMME 2 Exécution Bilatéral ; confirmé par la 3eme Partie ; Mais pas déclaré ; Party A soumis au nom des deux parties (full delegation)

Flow Steps : 1. Parties A& B signe un accord bilatéral de la transaction. 2. Les parties envoient la transaction à la plateforme de la 3eme partie. 3. La 3eme partie crée un UTI et le propose aux contreparties. 4. Party A soumis un Position message au GTR au nom des deux parties 5. GTR renvoie un ACK à Party A 6. Intra-day parties sont d’accord de faire un amendement du contrat 7. Parties envoient amendement á la 3eme partie 8. Party A soumis Position message pour indiquer un Amendement au GTR 9. GTR renvoie un ACK à Party A 10. Party A envoie un Valuation message 11. GTR envoie un ACK à Party A 12. Party A envoie un Collateral message 13. GTR renvoie un ACK à Party A 14. Party B envoie un Valuation message 15. GTR envoie un ACK à Party B 16. Party B envoie un Collateral message 17. GTR renvoie un ACK à Party B

Party A

Party B

Middleware

2,3 2,3

TR

15,17

4,8,10,12 14,16

6

7 7 5,9,11,13

1




2.6.3 DIAGRAMME 3 Exécution Bilatéral; confirmation par papier ; Mais pas déclaré; Une Partie rapporte tout le data (full delegation)

Etapes du procès :

1. Parties A& B signe un accord bilatéral de la transaction. 2. Party A envoie un Position message au GTR en incluant le common et counterparty specific data des deux parties 3. GTR envoie un ACK à Party A 4. Party A envoie un EOD Position message en récapitulant les positions ouvertes, et en incluant les évaluations 5. GTR envoie un ACK à Party A 6. Party A envoie un Collateral et Valuation message au GTR 7. GTR renvoie un ACK à Party A

Party A

Party B

1

TR

2, 4, 6

3, 5, 7




2.6.4 DIAGRAMME 4 On-Facility exécution; pas déclaré ; Les deux parties font leur rapport (indépendamment)

Etapes du procès :

1. Le contrat est registré à la plateforme de léxécution et envoyé aux Parties A & B. 2. La plateforme de léxécution générera un UTI et i l sera envoyé aux Parties A & B. 3. Party A envoie un Position message au TR pour lui- même. 4. GTR envoie un ACK à Party A 5. Party B envoie un Position message au TR pour lui- même. 6. GTR envoie un ACK à Party B 7. Party A rapporte un Valuation message et Collateral message a partir de la base qui est en cours 8. Party B rapporte Valuation message et Collateral message a partir de la base qui est en cours

Party A

Execution Platform

TR

Party B

1, 2 1, 2

3, 4, 7 5, 6, 8




2.6.5 DIAGRAMME 5 On-Facility exécution; pas déclaré ; une partie rapporte tout le data (full delegation)

Etapes du procès :

1. Le contrat est registré à la plateforme de léxécution et envoyé aux Parties A & B. 2. La plateforme de léxécution générera un UTI et i l sera envoyé aux Parties A & B . 3. Party A envoie un Position message au TR au nom des deux parties. 4. GTR envoie un ACK à Party A 5. Party A rapporte un Valuation message et Collateral message a partir de la base qui est en cours. 6. Party B rapporte un Valuation message and Collateral message a partir de la base qui est en cours.

Party A

Execution Platform

TR

Party B

1, 2 1, 2

3, 4, 5 6




2.6.6 DIAGRAMME 6 On-Facility exécution; déclaré; Les deux counterparties rapportent ( indépendamment ) ; CCP rapporte les transactions mises a jour. Etapes du procès:

1. Le contrat est registré à la plateforme de léxécution et envoyé aux Parties A & B avec un UTI généré.

2. Party A & Party B allègent et confirment le contrat avec la 3ieme partie . 3. 3eme partie reconnait le contrat et l UTI correspondant aux Parties A & B. 4. Party A déclare sa partie et envoie le Position message au TR. 5. Party B déclare sa partie et envoie le Position message au TR. 6. 3ieme partie envoie le contrat à un CCP. 7. CCP met a jour le contrat bilatérale, ben créant deux contrats, CCP se dirige a chaque partie

et i l assigne un UTI pour chacune d’elles. 8. CCP déclare deux nouveaux contrats a la 3ieme partie. 9. CCP envoie Position message pour deux nouveaux contrats au TR en incluant la référence Prior

UTI (X) 10. Party A change le Position message en Exit contrat initial X 11. Party B change le Position message en Exit original trade X




3 Message Validation Le GTR Message Validation a pour fonction de soumettre les messages envoyés à GTR, a des étapes de validation. Si le message ne passe pas une de ces étapes le résultat sera la réception d’ un NACK, le message retournera au rapporteur. Dans le cas contraire si après vérification tous est correct, le rapporteur recevra un ACK.

3.1 Etapes de la validation

3.2 Business validation

Le cadre de Business Validation couvrira : GTR Control Fields (Champs) D ‘autres champs juridict ionnel obligatoires. Ces champs doivent être remplis pour remplir la régulation juridique demandée, ce ne sont pas des GTR Control Fields. Dans le cas où une des étapes n’est pas conforme aux demandes exigées, le message sera refusé lors de la soumission et un NACK sera généré.

3.3 Validation de l’ESMA Régulateur

Si un message remplit le schéma de syntaxe validation, GTR Core validation et business validation l’accepteront dans le GTR .La soumission sera alors validée dans la juridiction listée dans Reporting Obligation party 1 et Reporting Obligation party 2 . En cas de non-conformité avec la régulation de validation, ou une obligation a été délaissé, cela déclenchera un warning, présent dans le warning report que l’utilisateur peut consulter. A signaler, que le message, pourrait être accepté dans le GTR, même si un champ, obligatoire pour la régulation, n’a pas été saisie. Cela est dû, car tous les champs

Schema Syntax Validation GTR Core Validation GTR Business

Validation

Is CSV valid? Are fields formatted correctly?

Permission, UTI lock, transaction & action type

consistency validation.

e.g. Does the post-trade CCY = the position CCY?




obligatoires pour la régulation n’ont pas besoin d’être remplis, cela dépend du scenario de la transaction (par exemple le delegated reporting ou certain champs ne sont pas applicables aux produits qui sont rapportés). Les utilisateurs peuvent vérifier leur warning rapport et soumettre un Position message avec toutes les informations nécessaires pour être en accord avec ESMA (Warning Rapport est disponible tous le jours avec les EOD rapports).

3.4 Réponse des Messages

Des messages de notification (ACK ou NACK rapports) seront génères immédiatement, en réponse à la soumission du fichier CSV.

3.4.1 CSV-Batch Download Rapport (Spreadsheet Download Rapport)

Chaque CSV soumission créera un ACK ou NACK rapport (Spreadsheet download report) ou tous les deux,(cela dépendra du statut de chaque message du fichier) cela prend en compte toutes les soumissions via Web ou SFTP, qui ont été faites au près du GTR et qui ont été rejetées ou acceptées. Le rapporteur peut consulter ce rapport dans le Spreadsheet Download tab situe dans le Web GUI ACCEPT . Cela signifie que le GTR Core Validation, GTR business validations ainsi que la saisie des champs obligatoires, ont validé la soumission entrante, celle-ci a été vérifiée et accepté dans le GTR système. REJECT Cela signifie que le GTR Core Validation, GTR business validations ainsi que la saisie des champs obligatoires ont refusé la soumission entrante, si elle ne remplit pas les conditions, le GTR système la rejette.

Submission Status Description

ACCEPT This status indicates that the GTR Core validation, GTR business validations as well as all the other mandatory fields have passed, indicating that the inbound submission was validated, verified and has been accepted in the GTR system.

REJECT This status indicates that the GTR Core validation and GTR reduced business validations failed, indicating that the inbound submission was not as per the required validation and has been rejected by the GTR system.

3.5 Warning Report disponible fin de journée

Le EOD warning report contient des niveaux d’avertissement concernant les transactions qui n‘ont pas rempli les obligations juridiques. La Position message possède des champs de validation ayant comme mission celle de remplir les demandes exigées. Le warning report inclus également les avertissements




des positions messages qui ont été modifiés ou mis à jour et soumis dans la journée. Des avertissements seront générés pour tous les champs qui sont requis par ESMA et qui resteront vides. Bien que pour GTR le champ est optionnel, pour ESMA il peut être obligatoire. La responsabilité que tout a été bien rapporté à ESMA revient exclusivement aux parties.

3.5.1 Des Règles de Génération Généré une fois par jour durant les batchs running à 00:00 minuit UTC dans EUDC Toute soumission entrante, reçue le jour suivant le warning rapport , sera validé pour toutes les

exceptions et rapporté dans le prochain warning report de la journée. Le rapport cont iendra seulement les avert issements ouverts pour cette journée Il ne cont iendra pas des avert issements sur posit ion message qui ont été corrigés pendant la

journée L’actuel GTR report ing portal peut sauvegarder pendant 7 jours les warnings reports. Concernant le format du warning report consultez Participant report ci-dessous.

4. Dual-sided reporting (Des Rapports de deux parties)

4.1 Introduction IMPORTANT: IF REPORTING ON BEHALF OF BOTH OR ONE PARTY TO THE TRADE THEN ALL SUBSEQUENT MESSAGES ON THAT UTI MUST BE MADE TO THE SAME SERVICE (“OTC Lite” or “OTC Core”). The GTR cannot process UTI’s that are partially submitted in a service. For example, if a Middleware uses “OTC Core” to submit on behalf of Party A and Party A is an “OTC Lite” user, the valuation message will not be accepted by OTC Lite. IMPORTANT: EN RAPPORTANT AU NOM DE UN OU DEUX PARTIES DU MARCHE TOUS LES MESSAGES SUIVANTS UTILISANT CE UTI DOIVENT ETRE SOUMIS DANS LE MEME SERVICE (“OTC Lite” or “OTC Core”). Le GTR ne peut pas traiter des UTI’s qui sont partialement soumis dans un service. Par exemple, si la 3ième partie utilise “OTC Core” pour soumettre au nom de Partie A et Partie A est un utilisateur du service “OTC Lite”, le valuation message ne sera pas accepté par OTC Lite.

L’actuel GTR infrastructure supporte le reporting des données du marché soit par les deux parties directement ou à travers une 3ième partie autorisé à reporter à leur nom. Les soumissions peuvent être faites indépendamment de deux côtés de la transaction, ou via une 3ième partie utilisant une central matching platform (tant qu’elles suivent le CSV format demandée).




Sous ESMA régulations, les deux parties ont une obligation de rapporter leurs transactions. Par ailleurs, les technical standards ESMA distinguent clairement la différence entre common data and contrepartie data: Contrepart ie data – Ce sont les détails concernant les contreparties du contrat. (Annex Table 1 de l’ESMA Technical Standards Document). data – the details relating to the counterparties to a contract.(Annex Table 1 of the ESMA Technical Standards Document)

Common data – ce sont les détails concernant les produits dérivés du contrat entre les deux parties. (Annex Table 2 de l’ESMA Technical Standards Document) Cette distinction de data, plus l’obligation des deux contreparties de rapporter leur transaction, soulève les différents scenarios de reporting et délégation model.

• � Les deux contreparties peuvent indépendamment rapporter les deux types de data common et contrepartie.

• Une part ie peut rapporter les deux types de data common and contrepartie, concernant les deux parties (full delegated reporting model).

• Sous ce modèle c’est également possible que la 2ième partie fournisse leur contrepartie data par une soumission en utilisant le modèle indépendant report dans la Position message (à signaler que full Position message est demandé et le dernier Position message qui a été soumis est celui qu’on prend en compte)

• Une ou les deux contrepart ies peuvent déléguer la responsabilité de report ing a une 3 part ie. • Pour cleared t rades les contrepart ies peuvent déléguer le report ing à CCP • Dans tous les cas le contrepartie/CCP est responsable de s’assurer que les contrats sont

rapportés et enregistrés dans le TR sans duplicatas. Des champs ont été ajoutés Dans le message template pour résoudre ces circulations de rapports. A noter que si un counterpartie (Party A) soumis un message a OTC Core sous le full delegated model et la 2ième partie (Party B) soumis à OTC Lite indépendamment en utilisant la même UTI celui-ci sera perçu comme une duperie par les régulateurs.

4.2 Identifying reporting model ( Identifier le Modèle pour le compte-rendu) The Les champs de control de GTR Submitted For Prefix et Submitted For Value identifiera si la soumission est fait au nom de vous, de votre contrepartie ou des deux parties. Le champ Reporting Delegation Model est inclus dans le but d’identifier le reporting model qui peut être utilise pour chaque soumission. Malgré le fait que ce champ n’est pas un champ obligatoire, le champ Reporting Delegation Model est inclus pour un usage ultérieur. Dans ce moment il ne influence pas les possibilités de traitement (processing options) comme ils sont base sur la valeur qui est soumise dans les champs Submitted For Prefix et Submitted For Value. Si vous soumettez au nom d’une part ie ce champ doit contenir la valeur “Independent”. Si vous soumettez-vous au nom de les deux parties ce champs doit contenir la value “Full”. Dans le cas des soumissions délégués, GTR assurera que la personne qui assure la soumission (submitter) a une permission pour soumettre pour l’autre partie.




4.2.1 Règles pour un compte-rendu Independent Si Submitted For Prefix et Submitted For Value identifie celui qui effectue la soumission , par exemple, Party 1, la soumission sera considérée comme indépendante. Dans ce scenario GTR at tendra de recevoir contrepartie data et common data soumis au nom seulement de la Partie 1. Le champ Report ing Delegat ion Model doit contenir la valeur Independent” ou on la laisse vide. Des données seulement de Trade Party 2 seront demandées dans ce rapport comme une identification de contrepartie. Toutes les autres données de Party 2 dans la soumission ne seront pas prises en considération, néanmoins les données de Party 1 seront traitées. Sous ce scenario l’autre partie du marché rapportera leurs données, indépendamment. Cette soumission peut aller à GTR ou dans un autre TR.

4.2.2 Règles pour un compte-rendu Full Délégation Party1 (ou la 3ième partie à qui on a donné la responsabilité de rapporter) soumis tout le common et contrepartie data de Party1 et Party2. Notez que sous le full délégation model le reporting party peut soumettre valuation et collateral messages au nom d’une ou des deux parties. Alternativement, chaque partie peut soumettre leur propre valuation et collateral messages. Si Submitted For Value identifie la soumission comme étant au nom des deux parties alors la soumission devra contenir Party 1 contrepartie data, Party 2 contrepartie data et common data. Sous ce scenario: Le champ Report ing Delegat ion Model doit contenir la value “Full” ou rester vide. Si une part ie ou la totalité du data de contrepart ie Party 2 N’EST PAS rempli, mais la soumission est accepté dans le GTR, lors de la validation il y aura un avertissement dans le Warning report qui identifiera les informations manquantes pour être en règle avec l’EMIR. Le warning report sera disponible aux parties du marché, s’ils sont enregistrés comme GTR participants. Si une Party du marché veut met t re à jour leur UTI (le scenario possible serait celui d’ajouter d’autres contrepartie data) puis le Party devra soumettre un Position message pour soi-même (qui est indiqué sous Submitted For Value) et respecter la validation du Position message. Comme mentionné au-dessus notez que tous les Contrepartie data et Common data doivent être soumis par cette partie pour que le UTI soit précisément enregistré dans le GTR. Tout common data qui n’a pas été fournie et qui avait déjà été soumis sera vide dans le GTR.

Le tableau au-dessous montre des règles:

Scenario Submitted

By Submitted

For Delegation

Model Commo

n Trade Party 1 fields

Trade Party 2 fields

Independent Reporting

Bank A Bank A Independent Y Y N


Client B Client B Independent Y Y N


Third Party Bank A Independent Y Y N

Independent Reporting Third Party Client B Independent Y Y N

Full Delegation Bank A Both Full Y Y Y Full Delegation Client B Both Full Y Y Y




Full Delegation Third Party Both Full Y Y Y

Only Identifier/region of CP will be processed all other information will not be processed if submitted

4.2.2.1 Reporting limitation La soumission des messages, en position full, en cas de changement life cycle ou en fin de journée sous le modèle de full délégation et au nom des deux parties prendront le dessus sur les autres soumissions. Cela provoquera que le data soumis à l’origine ne sera plus pris en compte .Encore une fois le data de party 2 sera incomplet pour l’EMIR et cela nous donnera un warning rapport.




4.2.3 Delegated Reporting Functionality Matrix Le tableau ci –dessous nous montre les différentes façons et possibilités de rapporter un message. On assume dans ce tableau que Ctpy2 n’a pas le droit de rapporter pour l’autre partie, il n’a pas la fonction de délégué et ne peut que donner son propre data.

OTC Lite

Scenario Resp. per party Common CP1 CP2

1 Independent Reporting

Ctpy 1 X

Ctpy 2 X

2 Full Delegation Ctpy 1

Ctpy 2 X X X

X : Indique que cela n’est pas censé être dans le modèle de reporting .Mais la soumission peut comme même être effectuée

(i.e. if cpty2 a délégué l’obligation de rapporter à cpty1, il ne devrait pas soumettre un position message)

X dans la case rouge, indique que le GTR ne permet pas cette soumission dans les différents scenarios




5. Identification du marché La capacité d’identifier des marches individuelles utilisant un Unique Trade Identifier (UTI) est une composante clés d’EMIR. Dans tous les cas les contreparties du marché, ainsi que iles CCP dans le cas de cleared trades, sont responsables de s’ assurer que les contrats sont rapportés au registre dépositoire sans duplicatas . Cela veut dire que les deux parties et leurs agents doivent rapporter chaque marché en utilisant un UTI unique qui a été approuvé entre les parties citées auparavant. Les techniques standards d’EMIR ne spécifient aucun règle pour générer les UTI ainsi que leur structure. La seule exigence est que celui –ci ne peut contenir que 52 signes alphanumériques. Mais vue la demande de la part des entreprises OTC_LITE accepte maintenant l’utilisation de ces signes `~!@#$%^&*()_-+=|\;:/. pour l UTI.

5.1 Introduction de l’UTI & Principes appliqués par le GTR pour “OTC Lite”

The GTR simplifiera the pairing of trades et positions en adoptant l’approche ci-dessous. 1. The Le UTI sera universel, sans aucune structure exigée Son format sera limité à 52 caractères

Alphanumériques (Actuellement ce format est revue au niveau industriel – voir le message template, bien que celui-ci accepte un UTI Prefix de 40 caractères et un UTI Value de 200 caractères , le format exigée par ESMA devra être respecté pour être en accord avec la règle

a. Quand la somme de UTI Prefix et du UTI Value dépasse 52 caractères un warning apparaitra dans le warning report.

2. Quand les deux parties se sont mis d’accord par rapport à l’UTI, ils peuvent soumettre ce UTI au GTR.

3. Dès qu’on a assigne un UTI pour une position , sa valeur ne peut être change . 4. Une fois qu’on a assigne un UTI , celui-ci devra être utilisé pour toute référence ultérieure

apportée à la transaction.

5. Si L’UTI doit être corrigé ou modifié alors le message doit être cancellé (Par l’action Exit ou Position Cancel), et on doit refaire une nouvelle soumission en utilisant le bon UTI ( L’UTI qui a été saisie lors d’une soumission ne peut être modifié). La meilleure façon de procéder c’est en utilisant l’action Exit dans la soumission initial, puis créer un nouveau Position Message et refaire la soumission. ( Indiquez L UTI que vous avez utilisé précédemment dans le champ “Prior UTI Value ).

6. L’unicité de L’ UTI sera déterminé par la combinaison des valeurs saisies dans les champs UTI Prefix et UTI Value.




5.2 Le Flux en amount

Ce document définie les spécifiques améliorations, qui sont nécessaires, pour respecter les régulations demandées par l’ EMIR , dans la simple GTR soumission, paradigme (“soumis une fois, rapportez plus”). L’implémentation proposée de l’industrie pour UTI génération et échange n’est pas couvert dans ce User Guide. Quand le flux amont du processus nécessaire pour intégrer et soumettre des données à GTR est au-delà de ce document, les principes clés concernant le flux amont du processus de l UTI sont complémentaires au core GTR trade, les principes d’identification mentionnés au-dessus sont inclus ici comme référence: 1. Des que c’est possible, les parties qui font la soumission échangeront le UTI flux amont de GTR en rapportant que quand les deux parties soumettent leur part de la transaction, le UTI sera le même. Concernant le temps de délai que les industries possèdent pour se mettre d’accord, cela peut s’avérer nécessaires de forcer les préliminaires jusqu’à une solution plus souple soit implémenté.

1. Si l’UTI est validé il doit être soumis au GTR 2. Une valeur doit être toujours saisie, dans les champs concernant l’UTI, pour chaque message. A

value must always be submitted in the UTI fields for each message 3. Si on décide de changer L UTI après la 1ere soumission, celle-ci devra être annulée en utilisant

l’action Exit puis une nouvelle soumission devra être effectuée, avec le nouveau UTI validé, dans le GTR.

a. Si on ne se met pas d’accord au sujet de l’UTI avant de faire la soumission on peut utiliser un UTI interim dans le champ UTI de la position message. Quand on valide l’UTI qu’on va utiliser on doit actionner Exit dans la position et la resoumettre en remplissant le champ “Prior UTI” avec la valeur de l’intérim UTI qu’on a utilisé avant.

4. L’UTI doit être unique pour les deux parties de la transaction ayant la même classe d’actif. Si le même UTI est soumis pour une autre “Primary Asset Class” avec la même trade contrepartie pair il sera rejeté.

5.3 Blocage de l UTI

1. 1. Quand on effectue une new soumission pour un UTI (‘Position’ ou ‘Valuation’), le système réalisera les validations suivantes. Ci-dessous, ce sont les règles générales pour les deux parties de la transaction qui sont connues comme utilisateurs (participant) du GTR système.




a .Le système vérifiera si l’UTI soumis est unique dans le “OTC Lite” service. Si l’UTI n’est pas présent dans le service, le système considèrera cet UTI comme valide. Quand l’UTI est accepté, le Trade Repository assigne l’UTI a la Party, Contrepartie, Message Type et Asset Class.

b. Les soumissions suivantes ayant le même UTI ne peuvent pas modifier le Party ID et le Asset Class. Le système permettra la modification de Contrepartie ID jusqu’ à que la Contrepartie soumission soit reçu.

2. Une fois que le LOCK a été applique, même si la Party/Contrepartie ‘Cancel’ / Exit’ la soumission initiale ayant un UTI donné et soumis un nouveau message avec le même UTI mais avec une contrepartie ID différente, le système rejettera le message en le déclarant ‘Invalid Submission – UTI existe pour un autre Party/Contrepartie’. Pour un UTI donné, le Party-Contrepartie-Asset Class LOCK restera le même tout au long de la durée du contrat dans “OTC Lite”

3. Le LOCK sera applique dans le cas où la transaction possède deux soumissions .L ‘une est effectué par le Party et l’autre par le contrepartie. Une fois que les données de la Party et contrepartie sont reçus dans le Trade Repository, le système bloquera le UTI.

5.3.1 Exceptions de Blocage de l’ UTI: Le Trade Repository système bloquera l UTI proportionné par le Party-Contrepartie-Asset Class. Une fois que les deux parties ont fait leur soumission, et le TR les a reçues et le LOCK a été appliqué, le système ne permettra à l’utilisateur de modifier Party ID, Contrepartie ID et Asset Class. Ci – dessous quelques exceptions concernant le UTI LOCK .

1. TR permettra la modification de Party ID et Contrepartie ID si la Party et Contrepartie modifiée appartiennent au même Ultimate parent.

a. Par exemple, si Party ID est Bank A-NY, son ultimate parent est Bank

b. Le TR permettra à la Partie /Contrepartie de modifier le Party ID pour un autre utilisateur ID Bank A-Asia dont son ultime parent est le même que Bank A –NY c’est-à-dire BANK A

c. En cas d’une réorganisation de la compagnie, le TR permet la soumission de Party ID et Conterparty ID, si le Party ID et Conterparty ID d’origine étaient sous un autre Ultimate parent ou parent structure, et ont changé de ultimate parent

d. Par exemple si Party ID est Bank A-NY appartenant au ultimate parent ID Bank A . Le TR permettra Party/Contrepartie soumission si Party ID BANK A_NY change pour un autre Ultimate parent ID BANK A NEW.




e. c) Si la soumission initial a été rapportée comme INTERNAL ou UNKNOW ID vous pouvez modifier et ajouter le LEI.

6 Inter-TR Reconciliation L’obligation qui exige ESMA, de devoir rapporter les deux côtés de la transaction, en ajoutant, le libre choix des participants de choisir leur TR , provoquera des scenarios dans lesquels les deux parties du marché utilisent des différents TR , pour rapporter leurs obligations au- près de ESMA . Dans le cas où , GTR possède seulement une position avec obligation de déclarer a ESMA , ESMA impose l’ obligation au TR de réconcilier le data avec l’autre TR. Une Inter -TR interopérabilité solution a été proposée par un certain nombre de compagnies DTCC inclus, qui ont offert leur services comme TR .Cette proposition va être examiné par l’ESMA et sera pleinement documenté dans l’Inter -TR Reconciliation and Interoperability BRD.

6.1 Trade Pairing Pairing ne peut être fait que dans le cas un UTI a été donné. Si un UTI n’est pas fourni par les deux parties du marché, les parties du marché ne peuvent être jumelés. Le jumelage ou Pairing peut- être fait seulement avec un autre TR ou les deux contreparties ont rapporté en utilisant leur LEI ou PRE LEI. Si le ID de l’autre contrepartie a été saisie avec une autre valeur outre que le LEI ou PRE LEI, le rapport ne peut en aucun cas être jumelé avec l’autre contrepartie, parce que ils auraient utilisé un LEI ou PRE LEI, le TR ne peut pas les jumelés et comparer le marché. Quand les deux parties du marché sont rapportés au GTR, pour le pairing on cherchera par l’ UTI , Contrepartie ID et ID du contrepartie, sans prendre en compte quel genre de identificateur on utilise. (cela n’est pas limité seulement au LEI ). Le GTR enregistrera le statu de chaque position. Le remplissage de trade pairing status values est expliqué dans le tableau suivant. Trade Pairing Status Trade Pairing Status Description Exempt The position will not require pairing as the Counterparty Region is non-EEA. N/A The positions will not require pairing as the Reporting Obligation does not include ESMA. Unpaired Pairing has either yet to be attempted or that no pair has been located thus far. Unpairable The position does meet the ESMA reconciliation criteria but does not have mandatory

fields required for the Pairing process (such as UTI and LEI’s). Paired The Position has been successfully paired either within the GTR or with another TR. Pairing Error When a position has had external Pairing attempted but more than one TR has responded

with the same positions details. Pair LEI Break When a position pair has been found where the UTI and one LEI match but the other LEI

does not match.




Exempt La position ne requiert pas un pairing car la Région de la Contrepartie est en dehors de l’Espace économique européen (EEA).). N/A – Les positions ne requièrent pas un pairing car il n’y a pas d’ Obligation de rapporter au près de l’ESMA. Unpaired – Pairing est toujours en suspens , ou l’autre pair n’a toujours pas été localisé. Unpairable – La position répond aux exigences de réconciliation de l’ESMA mais des champs qui sont obligatoires pour le pairing processus (comme l’UTI et LEI’s) ne sont pas remplis . Paired – La position a bien été jumelle (couple) dans le GTR ou dans un autre TR. Pairing Error – Quand une position a eu un pairing externe, et plus d’ un TR a répondu avec les mêmes détails de la position. Pair LEI Break – Quand une position a été trouvé avec un UTI et un LEI qui concordent mais l’autre LEI ne correspond pas

6.2 Trade Matching

Le GTR système recevra Trade messages et maintient un Paired Status, un Paired Source et un Matched Status pour tous les marchés avec une Trade Position. Une fois que le marché a été jumelé, une comparaison de deux parties du marché, sera mis en place puis le statut de cette comparaison sera stocké. Le possible match statu de chaque marché est expliqué (décris) dans le tableau suivant. les champs sur lesquelles la comparaison est basé, sont cités au-dessous de cette section. Notez que ce matching procédé n’est pas pertinent et il ne remplace pas la confirmation des participants dans le matching procédé. Exempt- La position ne requiert pas un pairing car la Région de la Contrepartie est en dehors de l’Espace économique européen (EEA). N/A – Les positions ne requièrent pas un pairing car il n’y a pas d’ Obligation de rapporter au près de l’ESMA. Unpaired – Pairing est toujours en suspens , ou l’autre pair n’a toujours pas été localisé. Unpairable – La position répond aux exigences de réconciliation de l’ESMA mais des champs qui sont obligatoires pour le pairing processus (comme l’UTI et LEI’s) ne sont pas remplis . Paired – La position a bien été jumelle (couple) dans le GTR ou dans un autre TR. Pairing Error – Quand une position a eu un pairing externe, et plus d’ un TR a répondu avec les mêmes détails de la position. Pair LEI Break – Quand une position a été trouvé avec un UTI et un LEI qui concordent mais l’autre LEI ne correspond pas Trade Match Status Trade Match Status Description Exempt The position will not require matching as Counterparty Region is non-EEA. N/A The position will not require matching as Reporting Obligation does not include ESMA. Pending The position has not been paired yet or has been paired but the matching process is yet to

take place. Cancel The position was previously eligible for matching but a cancellation or exit message has

been received. Matched The position has been reconciled and the key category 1 and category 2 fields match

within the prescribed tolerance. Unmatched1 The position has been reconciled and one or more category 1 fields do not match within




the prescribed tolerance but all the category 2 fields do match within the prescribed tolerance.

Unmatched2 The position has been reconciled and one or more category 2 fields do not match within the prescribed tolerance but all the category 1 fields do match within the prescribed tolerance.

Unmatched The position has been reconciled and one or more category 1 fields do not match within the prescribed tolerance and one or more category 2 fields do not match within the prescribed tolerance.

6.2.1 Champs et Règles Les champs de données suivants sont inclus dans le trade matching

Table 1 Contrepartie Data Notez que le champ 8 – Unique Trade ID est perçu comme un lien commun entre common data champs et contrepartie data champs.

Field number

Field Name ESMA Format Match / Tolerance Rule to other trade

2 Counterparty Id LEI Must match id of the other counterparty 3 ID of the other counterparty LEI Must match id of the counterparty

13 Counterparty side ‘B’ = buyer, or ‘S’ = seller

Must be ‘S’ if ‘B’ and ‘B’ if ‘S’

Table 2 Common Data Les champs dans ce tableau ont été classifié comme:

1. Ce champ sera réconcilié mais si les données dans ce champ ne correspondent pas entre les deux parties (dans le cadre des limites spécifiques) le marché sera exclut des rapports globaux, produits par DTCC public reporting team.

2. Ce champ sera réconcilié même-si le champ ne correspond pas aux soumissions des parties (dans le cadre des limites spécifiques) le marché sera inclus dans les rapports agrégés. Pour des raisons de réconciliation il ne sera pas applicable le champ N/A –

3. En outre, les tolérances check types suivants seront utilisées dans la comparaison de certains champs:

4. Le montant des marchés dans lesquels on fait la comparaison ne doit pas excéder 1 pourcent de différence.

5. Comparaison entre le montant 1 et 2 pour établir le montant le plus élevé. 6. Soustract ion du montant le plus pet it avec le montant plus élevé pour obtenir la différence

7. Divise, la différence avec le plus montant le plus élevé, puis on multiplie le résultat x 100 8. Si le résultat est supérieur a 1, les montants ne concordent pas.




9. 2. Les montants des marchés qu’on compare , doivent correspondre a gauche du point décimal 10. 3.Datetime des marchés qu’on compare doit correspondre à la date de ce champ 11.

No. Name ESMA Format Match/ Tolerance Rule

to other trade Category

1 Taxonomy used Identify the taxonomy used: U=Product Identifier [endorsed in Europe] I=ISIN/AII + CFI E=Interim taxonomy

Must match 1

2 Product id 1 For taxonomy = U: Product Identifier (UPI), to be defined For taxonomy = I: ISIN or AII, 12 digits alphanumerical code For taxonomy = E: Derivative class: CO=Commodity CR=Credit CU=Currency EQ=Equity IR=Interest Rate OT= Other

Must match 1

3 Product id 2 For taxonomy = U: Blank For taxonomy = I: CFI, 6 characters alphabetical code For taxonomy = E: Derivative type: CD= Contracts for difference FR= Forward rate agreements FU= Futures FW=Forwards OP=Option SW=Swap OT= Other

Must match 1

4 Underlying ISIN (12 alphanumerical digits); LEI (20 alphanumerical digits); Interim entity identifier (20 alphanumerical digits); UPI (to be defined); B= Basket; I=Index.

Must match 2

5 Notional currency 1

ISO 4217 Currency Code, 3 alphabetical digits. Must match 1

6 Notional currency 2

ISO 4217 Currency Code, 3 alphabetical digits. Must match 1

7 Deliverable currency

ISO 4217 Currency Code, 3 alphabetical digits. May not match 3

8 Trade id Up to 52 alphanumerical digits. Must match 1 9 Transaction

reference number An alphanumeric field up to 40 characters Will never match 3

10 Venue of execution

ISO 10383 Market Identifier Code (MIC), 4 digits alphabetical. Where relevant, XOFF for l isted derivatives that are traded off-exchange or XXXX for OTC derivatives.

Should match 2

11 Compression Y = if the contract results from compression; N= if the contract does not result from compression.

Should match 2

12 Price/rate Up to 20 numerical digits in the format xxxx,yyyyy.

Apply tolerance check 1 2

13 Price notation E.g. ISO 4217 Currency Code, 3 alphabetical digits, percentage.

Must match 2




No. Name ESMA Format Match/ Tolerance Rule to other trade

Category

14 Notional amount Up to 20 numerical digits in the format xxxx,yyyyy.


15 Price multiplier Up to 10 numerical digits. Must match 1 16 Quantity Up to 10 numerical digits. Must match 1 17 Up-front payment Up to 10 numerical digits in the format

xxxx,yyyyy for payments made by the reporting counterparty and in the format xxxx,yyyyy for payments received by the reporting counterparty.


18 Delivery type C=Cash, P=Physical, O=Optional for counterparty.

Must match 2

19 Execution timestamp

ISO 8601 date format / UTC time format. Apply tolerance check 3 for OTC.

2

20 Effective date ISO 8601 date format. Must match 2 21 Maturity date ISO 8601 date format. Must match 1 22 Termination date ISO 8601 date format. Must match 2 23 Date of

settlement ISO 8601 date format. Cannot match 3

24 Master agreement type

Free Text, field of up to 50 characters, identifying the name of the Master Agreement used, if any.

Cannot match 3

25 Master agreement version

Year, xxxx. Cannot match 3

26 Confirmation timestamp

ISO 8601 date format, UTC time format. Apply tolerance check 3 2

27 Confirmation means

Y=Non-electronically confirmed, N=Non-confirmed, E=Electronically confirmed.

Should match 2

28 Clearing obligation

Y=Yes, N=No. Must match 2

29 Cleared Y=Yes, N=No. Must match 1 30 Clearing

timestamp ISO 8601 date format, UTC time format. Apply tolerance check 3 2

31 CCP Legal Entity Identifier (LEI) (20 alphanumerical digits) or, if not available, interim entity identifier (20 alphanumerical digits) or, if not available, BIC (11 alphanumerical digits).

Must match 2

32 Intragroup Y=Yes, N=No. Should match 2 33 Fixed rate leg 1

(tolerance tba) Numerical digits in the format xxxx,yyyyy. Apply tolerance check 1 2

34 Fixed rate leg 2 (tolerance tba)

Numerical digits in the format xxxx,yyyyy. Apply tolerance check 1 2

35 Fixed rate day count

Actual/365, 30B/360 or Other. Cannot match 3

36 Fixed leg payment frequency

An integer multiplier of a time period describing how often the counterparties exchange payments, e.g. 10D, 3M, 5Y.

Cannot match 3





Category

37 Floating leg payment frequency


Cannot match 3

38 Floating leg reset frequency


Cannot match 3

39 Floating rate of leg 1

The name of the floating rate index, e.g. 3M Euribor.

Cannot match 3

40 Floating rate of leg 2

The name of the floating rate index, e.g. 3M Euribor.

Cannot match 3

41 Currency 2 ISO 4217 Currency Code, 3 alphabetical digits. Must match 2 42 Exchange rate 1 Up to 10 numerical digits in the format

xxxx,yyyyy. Must match Tolerance check 1 will be applied

2

43 Forward exchange rate

Up to 10 numerical digits in the format xxxx,yyyyy.

Must match Tolerance check 1 will be applied

2

44 Exchange rate basis

E.g. EUR/USD or USD/EUR. 2 X ISO 4217 Currency Code, 3 alphabetical digits separated by a slash.

Must match 2

45 Commodity Base AG=Agricultural EN=Energy FR=Freights ME=Metals IN= Index EV= Environmental EX= Exotic

Should match 2

46 Commodity Details

AG=Agricultural EN=Energy FR=Freights ME=Metals IN= Index EV= Environmental EX= Exotic

Should match 2

47 Delivery Point or zone (energy)

EIC code, 16 character alphanumeric code. Must match 2

48 Interconnection point (energy)

Free text, field of up to 50 characters. Cannot match 3

49 Load Type (energy)

Repeatable section of fields 50-54 to identify the product delivery profile; BL=Base Load PL=Peak Load OP=Off-Peak BH= Block Hours OT=Other

Must match 2

50 Delivery start date time (energy)

ISO 8601 date format. Must match 2





Category

51 Delivery end date time (energy)

ISO 8601 date format. Must match 2

52 Contract Capacity (energy)

Free text, field of up to 50 characters. Cannot match 3

53 Quantity Unit (energy)

10 numerical digits in the format xxxx,yyyyy. Apply tolerance check 1 1

54 Price/time interval quantities (energy)

10 numerical digits in the format xxxx,yyyyy. Apply tolerance check 1 2

55 Option type P=Put, C=Call. Must match 2 56 Option style A=American, B=Bermudan, E=European,

S=Asian. Must match 2

57 Strike price Up to 10 Numerical digits in the format xxxx,yyyyy.


58

Action type and details of action type

3

7 Compte-Rendu du Participant Les GTR rapports, détaillés ci-dessous, fournissent , l’information sur le statut des soumissions des marchés et tous les détails du marché. Le “OTC Lite” service a une limite concernant les rapports délivrés aux participants . Si un participant a rempli toutes les conditions, lors de l’enregistrement, a travers le manual onboarding process , tous les rapports seront automatiquement générés et disponibles dans le GUI(Si un participant a été enregistré via internet onboarding process alors le data dans ESMA Activity et Position rapport seront disponibles dans le portal via recherche et téléchargement. Tous les rapports sont disponibles en CSV format via le Report Download fonction dans le GTR System ou via Secure FTP. Les rapports sont automatiquement générés de Lundi à Vendredi a minuit ’UTC dans l’ EUDC, et seront disponibles pendant 7 jours dans le web GUI . Veuillez noter que les GTR participant position rapports reflètent la position actuel des marchés rapportés par eux-mêmes , ou a leur nom. Ils ne reflètent pas des positions agrégées au travers de multiple positions des marches. Tous nos rapports ont un entêté qui contient aussi bien le business date , le moment ou le rapport a été généré , et la date dans laquelle le rapport a été ouvert . Cette information est disponible dans tous les rapports des clients, cela donne aux clients l’information nécessaire pour être sur qu’ils sont bien entrain de consulter le dernier rapport . 7.1 Télécharger les Rapports à travers le Portal

Les screenshots ci-dessous montrent comment télécharger les rapports a partir du portal. Les utilisateurs doivent se connecter au portal (Section 1.6) et puis téléchargez un CSV spreadsheet (Section 2.1) pour pouvoir charger les rapports.

Pour accéder aux ACK/NACK Rapports




1. Quand vous entrez dans le OTC Lite Portal, cliquez sur Download

2. Quand vous cliquez sur le bouton Download, l’écran sous-dessous s’ ouvrira avec les actuels ACK Reports

3. Pour obtenir des NACK Reports cliquez sur le OTC-NACK tab

4. Après, vous pouvez sélectionner des rapports, pour télécharger, et puis cliquer sur le bouton Download pour télécharger un ZIP fichier

7.2 Des Rapports disponibles pour tous les Types d’Actifs La liste des rapports ci-dessous est valable pour tous les classes d’actifs .

No. Report Report Description




No. Report Report Description

1 ACK/NACK Report /Spreadsheet Download Report (Upload Status Report)

The ACK or NACK output report will be a real-time report indicating status of each message submitted. ACK report will include all accepted messages and NACK report will include all rejected messages.

2 Warning Report The warning report highlights warnings of issues that may indicate the message is not compliant for regulator reporting even if the GTR accepted the message.

3 GTR ESMA OTC Position Report

Includes the latest Position for all open UTI’s that are reported to ESMA. The report will contain only the ESMA reportable fields from Counterparty Data (Table 1) and Common Data (Table 2). All al leges will be included regardless of what service the UTI was reported through.

4 GTR ESMA OTC Activity Report

Includes all successfully processed submissions into the GTR since the last report generation for all UTI’s that are reported to ESMA. The report will contain only the ESMA reportable fields from Counterparty Data (Table 1) and Common Data (Table 2). All al leges will be included regardless of what service the UTI was reported through.

5 ESMA Match Status Report Reports of the pairing and match status by UTI. Any unmatched fields are l isted.

6 UTI Conflict and Pair Break LEI Report

List of all trades where the LEI pair submitted is different for each trade submission for the same UTI.

7.2.1 ACK/NACK Un ACK ou NACK Rapport (Spreadsheet download report) contiendra toutes les soumissions faites a travers la Web GUI ou Secure FTP, qui ont été traité avec succès dans le Trade Repository, ou qui ont été rejetées. Ci-dessous vous pouvez trouver une liste de ACK output rapport: No. Field Name Sample Data Description

1 Action New Action will indicate if the incoming message is 'New', 'Modify' or 'Cancel'

2 Transaction Type Trade Transaction Type as defined in the upload template 3 Message Type Position Message Type on the submissions 4 UTI Prefix IssuerA Prefix for UTI 5 UTI Value UTI123 Unique Trade Identifier;

UTI Value of the Submission 6 Asset Class Equity The Primary Asset Class 7 Product ID Prefix 1 ISDA The First Product Identifier prefix 8 Product ID Value 1 Equity:Swap:Pri

ceReturnBasicPThe First Product Identifier value




No. Field Name Sample Data Description

erformance:SingleName

9 Product ID Prefix 2 The Second Product Identifier prefix 10 Product ID Value 2 The Second Product Identifier value 11 Execution Timestamp 2012-02-

09T15:25:00Z The time and date of execution of the transaction in Coordinated Universal Time (UTC). (YYYY-MM-DDTHH:MM:SSZ)

12 Data Submitter Prefix LEI Submitting Party ID Prefix

13 Data Submitter Value 5678 Submitting Party ID Value 14 Trade Party 1 Prefix LEI The First Counterparty prefix 15 Trade Party 1

Value 5678 The First Counterparty Value

16 Trade Party 2 Prefix LEI The Second Counterparty prefix 17 Trade Party 2

Value 3214 The Second Counterparty Value

18 Transaction Reference

Number 123456 EMIR Specific field

19 Internal Trade Reference Adft56687 Internal Trade Reference Number of either party 20 Reporting Obligation

Party 1 ESMA Jurisdictions where trade is reportable

21 Reporting Obligation Party 2

ESMA Jurisdictions where trade is reportable

22 Data Submitter Message ID

CSV123 Reference provided by the submitting firm on each message within the CSV fi le

23 Submission Date & Time 2012-03-27T11:25:00Z

Submission Date and Time in UTC format. This is the time the submission was received by GTR. ( YYYY-MM-DDTHH:MM:SSZ )

24 Status ACCEPTED The Status of the message in GTR.

Un NACK output rapport contiendra tous des champs de données soumis dans la CSV soumission ET ajoutera devant chaque ligne 3 champs additionnels:

Submission Date & Time (la date et du temps de soumission)

Status (statu)

Error Code / Reason (le code d’erreur)/ la raison




7.2.2 Warning Report L’ objectif de ce rapport est d’alerter l’ utilisateur que dans la soumission il se peut qu’il manque des informations nécessaires pour la réconciliation avec ESMA. (La soumission peut-être parfaitement accepté par le GTR) par ex. une soumission dans laquelle on rapporte pour les deux parties, mais le champ Trade Party 2 Domicile est vide. Toutes les positions sur le Warning Report seront rapportées à l’ESMA. . Field List: No. Field Name Sample Data Description

1 UTI Prefix XXX Identify a prefix for the UTI (placeholder) 2 UTI Value 123 UTI assigned to the submission 3 Primary Asset Class Equity Asset class for the submission 4 Product ID Prefix 1 ISDA Indicates the taxonomy of the product used (ISDA preferred) 5 Product ID Value 1 Equity:Swap:Pri

ceReturnBasicPerformance:SingleName

Product Value as specified by ISDA taxonomy

6 Product ID Prefix 2 7 Product ID Value 2 8 Data Submitter Prefix LEI Prefix of identifier of party submitting the trade 9 Data Submitter Value 5678 Value of identifier of party submitting the trade

10 Submitted For Prefix LEI Prefix of identifier of party on behalf of which the submission is made

11 Submitted For Value 5678 Value of identifier of party on behalf of which the submission is made

12 Submission Date/Time 2012-03-26T09:10:10Z

When the submission to the GTR was processed

13 Trade Party 1 Prefix LEI Prefix of identifier for the first party named as a counterparty on the trade

14 Trade Party 1 Value 5678 Prefix of identifier for the first party named as a counterparty on the trade

15 Trade Party 1 Name Bank A Derived from Prefix/Value combination 16 Trade Party 1 Notional 100000 Notional reported by party 1 17 Trade Party 1 Notional

Currency/Units USD Currency for the notional reported by party 1

18 Trade Party 2 Prefix LEI Prefix of identifier for the second party named as a counterparty on the trade

19 Trade Party 2 Value 3214 Prefix of identifier for the second party names as a counterparty on the trade

20 Trade Party 2 Name Bank B Derived from Prefix/Value combination 21 Trade Party 2 Notional 100000 Notional reported by party 2 22 Trade Party 2 Notional

Currency/Units USD Currency for the notional reported by party 2

23 Transaction Reference Number

1323423 EMIR specific field

24 Internal Trade Reference T98765





25 Data Submitter Message ID

CSV789 Reference provided by the submitting firm on each message within the CSV fi le

26 Warning Reason Code 12 Reason code for the warning 27 Warning Description Unknown

Counterparty Reason description for the warning

Ci-dessous il y a une liste des avertissements et leur descriptions: Error Code Error Description OTLW1001 Reporting Obligation Party 2 is required when reporting on behalf of both counterparties OTLW1002 Trade Party 2 Domicile is required when reporting on behalf of both counterparties OTLW1003 Trading capacity Party 2 is required when reporting on behalf of both counterparties OTLW1004 Buyer Value Party 2 is required when reporting on behalf of both counterparties OTLW1005 Trade Party 2 Financial Entity Jurisdiction or Trade Party 2 Non-financial Entity Jurisdiction is required

when reporting on behalf of both counterparties OTLW1006 MTM Currency Party 2 is required when reporting on behalf of both counterparties OTLW1007 Valuation Datetime Party 2 is required when reporting on behalf of both counterparties OTLW1008 Valuation Type Party 2 is required when reporting on behalf of both counterparties OTLW1009 Trade Party 2 Corporate Sector is required when Trade Party 2 Financial Entity Jurisdiction is blank and

Trade Party 2 Non-financial Entity Jurisdiction is blank OTLW1010 Trade Party 2 Corporate Sector is required when Trade Party 2 Financial Entity Jurisdiction is "ESMA" OTLW1011 The Directly linked to commercial activity or treasury financing Party 2 is required to be populated if

Party 2 is a non-financial entity OTLW1012 Clearing Broker Party 2 Value is required when the trade is cleared OTLW1013 Beneficiary ID Party 2 Value is required for Trade Party 2 when reporting on behalf of both

counterparties and trading capacity is Agent OTLW1014 Clearing Threshold Party 2 is required when Trade Party 2 Non-financial Entity Jurisdiction is "ESMA" OTLW1015 UTI is greater than 52 characters OTLW1016 Counterparty Region is required for ESMA reporting (Trade with non-EEA counterparty) OTLW1017 Clearing Broker Party 1 is required when the trade is cleared OTLW1018 Settlement Currency is required for ESMA reporting OTLW1019 Execution Venue Value is required for ESMA reporting OTLW1020 Price Notation - Price is required for ESMA reporting OTLW1021 Price Notation - Price Type is required for ESMA reporting OTLW1022 Delivery type is required for ESMA reporting OTLW1023 Execution Timestamp is required for ESMA reporting OTLW1024 Effective Date is required field for ESMA reporting OTLW1025 Date of Settlement is required for ESMA reporting OTLW1026 Clearing Timestamp is required for ESMA reporting OTLW1027 Clearing DCO Value is required for ESMA reporting OTLW1028 Clearing Threshold Party 1 is required for ESMA reporting OTLW1029 MTM Currency CCP is required OTLW1030 Valuation Datetime CCP is required OTLW1031 Valuation Type CCP is required




7.2.3GTR ESMA OTC Position Report Le rapport reflètera tous les positions ouvertes pour tous les participants qui ont rapporté à l’ESMA. Le format du rapport indiquera les champs d’ESMA et les données qui ont été rapportées dans ces champs. Toutes allégations seront reflétées dans le rapport (ou le participant est nommé comme partie du marche avec un l’UTI rapporté par autre partie). Aucune information additionnelle ne sera donné dans ce rapport. Le ESMA Position Report contiendra ces marchés dans lesquelles le destinataire du rapport est nommé comme la 2ième partie ou nommé comme l’agent d’exécution (réalisation). Field List:

ESMA Table #

EMIR Field ESMA Table reference GTR FIELD MAPPING

1 Reporting timestamp Table 1 - Counterparty Data Derived Trade Party 1 Prefix GTR Control field Trade Party 1 Value GTR Control field 2 Counterparty ID Table 1 - Counterparty Data Trade Party 1 Prefix,

Trade Party 1 Value 4 Name of the counterparty Table 1 - Counterparty Data Derived or Provided - Name of Trade Party 1 Trade Party 1 Prefix GTR Control field Trade Party 1 Value GTR Control field 3 ID of the other Counterparty Table 1 - Counterparty Data Trade Party 2 Prefix,

Trade Party 2 Value 4b Name of the other counterparty Table 1 - Counterparty Data Derived or Provided - Name of Trade Party 2 Trade Party 1 Branch Location GTR Control field Trade Party 2 Branch Location GTR Control field 5 Domicile of the counterparty Table 1 - Counterparty Data Trade Party 1 Domicile 6 Corporate sector of the counterparty Table 1 - Counterparty Data Trade Party 1 Corporate Sector 7 Financial or non-financial nature of

the counterparty Table 1 - Counterparty Data Trade Party 1 Financial Entity Jurisdiction,

Trade Party 1 Non-financial Entity Jurisdiction Broker Id Party 1 Prefix GTR Control field Broker Id Party 2 Prefix GTR Control field 8 Broker ID Table 1 - Counterparty Data Broker Id Party 1 Prefix,

Broker Id Party 1 Value Party 1 Reporting Obligation GTR Control field Reporting Jurisdiction GTR Control field Data Submitter Prefix GTR Control field Data Submitter Value GTR Control field 9 Reporting entity ID Table 1 - Counterparty Data Data Submitter Prefix,

Data Submitter Value Clearing Broker Party 1 Prefix GTR Control field Clearing Broker Party 1 Value GTR Control field 10 Clearing member ID Table 1 - Counterparty Data Clearing Broker Party 1 Prefix,

Clearing Broker Party 1 Value, Beneficiary ID Party 1 Prefix GTR Control field Beneficiary ID Party 1 Value GTR Control field 11 Beneficiary ID Table 1 - Counterparty Data Beneficiary ID Party 1 Prefix,

Beneficiary ID Party 1 Value Execution Agent Party 1 Prefix GTR Control field




ESMA Table #


Execution Agent Party 1 Value GTR Control field 12 Trading capacity Table 1 - Counterparty Data Trading capacity Party 1 13 Counterparty side Table 1 - Counterparty Data Buyer Prefix (Party 1), Buyer Value (Party 1) 14 Trade with non-EEA counterparty Table 1 - Counterparty Data Counterparty Region 15 Directly l inked to commercial activity

or treasury financing Table 1 - Counterparty Data Directly l inked to commercial activity or

treasury financing Party 1 16 Clearing threshold Table 1 - Counterparty Data Clearing Threshold Party 1 17 Mark to market value of contract Table 1 - Counterparty Data MTM Value Party 1

MTM Value CCP 18 Currency of mark to market value of

the contract Table 1 - Counterparty Data MTM Currency party 1

MTM Currency CCP 19 Valuation date Table 1 - Counterparty Data Valuation Datetime Party 1

Valuation Datetime CCP 20 Valuation time Table 1 - Counterparty Data Valuation Datetime Party 1

Valuation Datetime CCP 21 Valuation type Table 1 - Counterparty Data Valuation Type

Valuation Type CCP 22 Collateralisation Table 1 - Counterparty Data Collateralized Party 1 23 Collateral portfolio Table 1 - Counterparty Data Collateral portfolio code Party 1 24 Collateral portfolio code Table 1 - Counterparty Data Collateral portfolio code Party 1 25 Value of the collateral Table 1 - Counterparty Data Value of the collateral Party 1 26 Currency of the collateral value Table 1 - Counterparty Data Currency of the collateral value Party 1 Primary Asset Class GTR Control field Secondary Asset Class GTR Control field Product ID Prefix GTR Control field Product ID Value GTR Control field 1 Taxonomy used Table 2 - Common Data Product ID Prefix 2 Product ID 1 Table 2 - Common Data Product ID value 1 3 Product ID 2 Table 2 - Common Data Product ID Value 2 4 Underlying leg 1 Table 2 - Common Data Underlying Asset leg 1 4a Underlying leg 2 Table 2 - Common Data Underlying Asset leg 2 5 Notional currency 1 Table 2 - Common Data Notional Currency 6 Notional currency 2 Table 2 - Common Data Notional Currency 7 Deliverable currency 1 Table 2 - Common Data Settlement Currency 7a Deliverable currency 2 Table 2 - Common Data Settlement Currency UTI Prefix GTR Control field UTI Value GTR Control field USI Prefix GTR Control field USI Value GTR Control field Trade Party 1 Transaction Id GTR Control field 8 Trade ID Table 2 - Common Data UTI Prefix, UTI Value Prior UTI Prefix GTR Control field Prior UTI Value GTR Control field Trade Link ID GTR Control field Exchange Traded Derivative

indicator GTR Control field




ESMA Table #


Execution Venue Prefix GTR Control field 10 Venue of execution Table 2 - Common Data Execution Venue Value 11 Compression Table 2 - Common Data Compression 12 Price / rate Table 2 - Common Data Price Notation - Price 13 Price notation Table 2 - Common Data Price Notation - Price Type 14 Notional amount leg 1 Table 2 - Common Data Notional Amount 14a Notional amount leg 2 Table 2 - Common Data Notional Amount 15 Price multiplier Table 2 - Common Data Price Multiplier 16 Quantity Table 2 - Common Data Quantity 17 Up-front payment Table 2 - Common Data Upfront payment 17a Up-front currency 1 Table 2 - Common Data Upfront payment CCY 17b Up-front payment 2 Table 2 - Common Data Upfront payment 17c Up-front currency 2 Table 2 - Common Data Upfront payment CCY 17d Up-front payment 3 Table 2 - Common Data Upfront payment 17e Up-front currency 3 Table 2 - Common Data Upfront payment CCY 17f Up-front payment 4 Table 2 - Common Data Upfront payment 17g Up-front currency 4 Table 2 - Common Data Upfront payment CCY 17h Up-front payment 5 Table 2 - Common Data Upfront payment 17i Up-front currency 5 Table 2 - Common Data Upfront payment CCY 17j Up-front payment 6 Table 2 - Common Data Upfront payment 17k Up-front currency 6 Table 2 - Common Data Upfront payment CCY 18 Delivery type Table 2 - Common Data Delivery type 19 Execution timestamp Table 2 - Common Data Execution Timestamp 20 Effective date leg 1 Table 2 - Common Data Effective date 20a Effective date leg 2 Table 2 - Common Data Effective date 21 Maturity date Table 2 - Common Data Scheduled Termination Date 22 Termination date Table 2 - Common Data Termination date 23 Settlement date 1 Table 2 - Common Data Date of Settlement 24 Master Agreement type Table 2 - Common Data Master Agreement type 25 Master Agreement version Table 2 - Common Data Master Agreement version 26 Confirmation timestamp Table 2 - Common Data Confirmation Date Time 27 Confirmation means Table 2 - Common Data Confirmation Type 28 Clearing obligation Table 2 - Common Data Mandatory Clearing Indicator 29 Cleared Table 2 - Common Data Cleared 30 Clearing timestamp Table 2 - Common Data Clearing Timestamp Clearing DCO Prefix GTR Control Field 31 CCP ID Table 2 - Common Data Clearing DCO Prefix

Clearing DCO Value 32 Intragroup Table 2 - Common Data Intragroup 33 Fixed rate of leg 1 Table 2 - Common Data Fixed rate of leg 1 34 Fixed rate of leg 2 Table 2 - Common Data Fixed rate of leg 2 35 Fixed rate day count 1 Table 2 - Common Data Fixed rate day count 35b Fixed rate day count 2 Table 2 - Common Data Fixed rate day count 36 Fixed leg payment frequency 1 Table 2 - Common Data Fixed leg payment frequency 36b Fixed leg payment frequency 2 Table 2 - Common Data Fixed leg payment frequency 37 Floating rate payment frequency 1 Table 2 - Common Data Floating rate payment frequency




ESMA Table #


37b Floating rate payment frequency 2 Table 2 - Common Data Floating rate payment frequency 38 Floating rate reset frequency 1 Table 2 - Common Data Floating rate reset frequency 38b Floating rate reset frequency 2 Table 2 - Common Data Floating rate reset frequency 39 Floating rate of leg 1 Table 2 - Common Data Floating rate of leg 1 39b Floating rate spread of leg 1 Table 2 - Common Data Floating rate spread of leg 1 40 Floating rate of leg 2 Table 2 - Common Data Floating rate of leg 2 40b Floating rate spread of leg 2 Table 2 - Common Data Floating rate spread of leg 2 40c Leg 1 Payer Table 2 - Common Data Leg 1 Payer 40d Leg 2 Payer Table 2 - Common Data Leg 2 Payer 41 Currency 2 Table 2 - Common Data Currency 2 42 Exchange rate 1 Table 2 - Common Data Exchange rate 1 43 Forward exchange rate Table 2 - Common Data Forward exchange rate 44 Exchange rate basis Table 2 - Common Data Exchange rate basis 45 Commodity base Table 2 - Common Data Commodity base 46 Commodity details Table 2 - Common Data Commodity details 47 Delivery point or zone Table 2 - Common Data Delivery point or zone 48 Interconnection Point Table 2 - Common Data Interconnection Point 49 Load type Table 2 - Common Data Load type 50 Delivery start date and time Table 2 - Common Data Delivery start date and time 51 Delivery end date and time Table 2 - Common Data Delivery end date and time 52 Contract capacity Table 2 - Common Data Contract capacity 53 Quantity Unit Table 2 - Common Data Quantity Unit 54 Price/time interval quantities Table 2 - Common Data Price/time interval quantities 55 Option type Table 2 - Common Data Option Type 56 Option style (exercise) Table 2 - Common Data Option Style 57 Strike price (cap/floor rate) Table 2 - Common Data Option Strike Price

Option Strike Price CCY 57b Option Strike Price Type Table 2 - Common Data Option Strike Price Type 57c Option Strike Price CCY Table 2 - Common Data Option Strike Price CCY Lifecycle Event GTR Control Field Lifecycle Event Effective Date GTR Control Field 58 Action type Table 2 - Common Data Lifecycle Event

Action 59 Details of action type Table 2 - Common Data Lifecycle Event

Action Notez que les GTR Control Fields sont utilisés autant dans les champs de la Table 1 ou Table 2 champ mais ils ne sont pas inclus dans les rapports de régulation.

7.2.4GTR ESMA OTC Activity Report Le rapport reflètera tous les activités, faites, depuis le dernier rapport, par le participant, et qui ont été rapportées à l’ESMA. Le format du rapport indiquera les champs d’ESMA et les données qui ont été rapportées dans ces champs. Le format et la liste des champs est le même que celui-ci du Position Report. Toutes allégations seront reflétées dans le rapport (ou le participant est nommé comme partie




du marché avec un l’UTI rapporté par autre partie). Les champs Lifecycle Event, Lifecycle Event Effective Date, Action type et Details of action type seront inclus dans le activity report mais n’apparaitront pas dans le position report.

7.2.5 ESMA Match Status Report Le nouveau Matching Status rapport fournira aux participants les ruptures, les différences, classées en catégorie 1 et catégorie 2 dans le but d’aider a résoudre ces ruptures. Voyez la section au-dessus sur Inter-TR réconciliation pour la définition de différentiation catégorie. Le Matching Status report détaillera la liste des champs qui ne correspondent pas. Il donnera une information sur le nom d’un champ mais il ne donnera pas son contenu. Le rapport contiendra les champs suivants: UTI Party 1 LEI Part 2 LEI (ou par une autre ident ifier) Trade Reconciliation Status Unmatched fields Party 1 Transaction ID Le unmatched field names montrera horizontalement et par des points-virgules séparés

UTI Party 1 LEI Party 2 LEI Trade Reconciliation Status Unmatched Fields

Party 1 Transaction ID

ABC123 SAMPLE98765LEI7ABCD SAMPLE123LEI456ABCD Single-sided, unpaired, non EEA OUR123REF ABC124 SAMPLE98765LEI7ABCD SAMPLE123LEI456ABCD Single-sided, unpaired, EEA OUR124REF

ABC125 SAMPLE98765LEI7ABCD SAMPLE123LEI456ABCD Dual-sided, unmatched category 1

Notional Amount Leg 1 - 1; Notional Currency 1 - 1; Confirmation Timestamp - 2 OUR125REF

ABC126 SAMPLE98765LEI7ABCD SAMPLE789LEI456EFGH Dual-sided, unmatched category 2 Effective Date - 2 OUR126REF

ABC127 SAMPLE98765LEI7ABCD SAMPLE789LEI456EFGH Dual-sided matched OUR127REF

ABC128 SAMPLE98765LEI7ABCD SAMPLE789LEI456EFGH Single-sided, paired, unmatched category 1 Cleared - 1 OUR128REF

ABC129 SAMPLE98765LEI7ABCD SAMPLE123LEI456ABCD Single-sided, paired, unmatched category 2

Exchange Rate - 2; Execution Timestamp - 2 OUR129REF

ABC130 SAMPLE98765LEI7ABCD SAMPLE123LEI456ABCD Single-sided, paired, match pending OUR130REF

ABC131 SAMPLE98765LEI7ABCD SAMPLE789LEI456EFGH Single-sided, paired, matched OUR131REF




For reference, below are the Trade Reconciliation Status descriptions:

Trade Reconciliation Status Trade Reconciliation Status description

Single-sided, unpaired, non EEA The trade is ESMA reportable but the other side of the trade is not ESMA reportable and therefore there is no reconciliation requirement.

Single-sided, unpaired, EEA

The GTR has one side of the trade, knows that the other side is EEA based upon the value of the Contract with non-EEA counterparty flag for Table 1 – Counterparty Data being set to ‘Y’ and does not know which TR holds the other side of the trade is.

Dual-sided, unmatched category 1

The GTR has both sides of the trade and category 1 fields do not match within the tolerances defined in Appendix A. The fields which do not match will be l isted on the TR reconciliation Differences Report.

Dual-sided, unmatched category 2

The GTR has both sides of the trade and category 2 fields do not match within the tolerances defined in Appendix A. The fields which do not match will be l isted on the TR reconciliation Differences Report.

Dual-sided matched The GTR has both sides of the trade and all fields match within the tolerances defined in Appendix A.

Single-sided, paired, unmatched category 1

The GTR has one side of the trade and the details of the other side of the trade have been obtained from the TR with the other side of the trade. The reconciliation has taken place and not all fields match within the tolerances defined in Appendix A. The fields which do not match will be l isted on the TR reconciliation Differences Report.

Single-sided, paired, unmatched category 2

The GTR has one side of the trade and the details of the other side of the trade have been obtained from the TR with the other side of the trade. The reconciliation has taken place and not all fields match within the tolerances defined in Appendix A. The fields which do not match will be l isted on the TR reconciliation Differences Report.

Single-sided, paired, match pending

The GTR has one side of the trade and the details of the other side of the trade have been obtained from the TR with the other side of the trade. Match processing has not taken place yet.

Single-sided, paired, matched

The GTR has one side of the trade and the details of the other side of the trade have been obtained from the TR with the other side of the trade. The reconciliation has taken place and all fields match within the tolerances defined in Appendix A.




7.2.6 ESMA UTI Conflict or Pair LEI Break Report Ce rapport est fourni à une contrepartie de la Transaction selon les résultats de l’Inter-TR réconciliation. Un rapport additionnel pourrait aussi contenir des détails, de quelconque UTI Conflits ou Pair Break LEI’s enregistré, pour informer les participants et ceux qui font la soumission au sujet de problèmes spécifiques. Donc si on se situe dans la perspective de Party A qui expérience un UTI Conflict & Pair Break LEI Report pourrait avoir quatre colonnes: 1. Colonne A = UTI 2. Colonne B = Party A LEI (comme soumis par Party A) 3. Colonne C = Party B LEI (comme soumis Party A) 4. Colonne D = Error Code [“UTI reported by other parties”, “UTI reported to GTR in error” ou “Mismatched LEI”]


1 UTI ABC123 2 Party 1 LEI SAMPLE98765LEI7ABCD 3 Party 2 LEI SAMPLE123LEI456ABCD 4 Error Code UTI reported by other parties

"UTI reported by other parties” error will occur when: • Party A vs. Party B reports UTI 123 • Party C vs. Party D reports UTI 123

“Mismatched LEI” error will occur when: • Party A vs. Party B reports UTI 456 • Party B vs. Party C reports UTI 456




8 Appendix A – Des Liens Pratiques

8.1 Contexte réglementaire

8.1.1 ESMA Définitif Projet de normes techniques http://www.esma.europa.eu/system/files/2012-600_0.pdf

8.1.2 Résumé des normes techniques d ‘ ESMA http://dtcc.com/~/media/Files/Downloads/Data-and-Repository-Services/GTR/GTR-Europe/Summary_ESMA_Technical_Standards.ashx

8.1.3 EMIR vs. DFA Comparaison http://dtcc.com/~/media/Files/Downloads/Data-and-Repository-Services/GTR/GTR-Europe/EMIRvDFA-QandA.ashx

8.1.4 ESMA Questions et Réponses http://www.esma.europa.eu/documents/overview/10?title=&doc_reference=&section=All&doc_type=266&x=40&y=8

A noter Assurez-vous que vous téléchargez la dernière version de EMIR Q&A

8.1.5 ISDA matériel sur la cotation des prix http://www2.isda.org/attachment/NTQxMA==/ISDA%20PN-APN%20Approach%20Document%20v1.0%202013_03_15.xlsx

8.2 Business Requirements Document

Pour obtenir le document Business Requirement Documentation" Allez à GTR Clients’ Center (voir section 1.2) ) et choisissez le dans la liste déroulante.

8.3 CSV Chargement du Template

9. Allez au GTR Clients’ Center (des contours sont dans la section 1.2) et choisissez “Supported – Spreadsheets and Messaging Specs” dans liste déroulante (dropdown menu. Si l’OTC Lite n’est toujours pas en production, le template sera accessible sous “Future – Spreadsheets and Messaging Specs” dans la liste déroulante

8.4 OTC Lite Presentations et Videos

http://www.esma.europa.eu/system/files/2012-600_0.pdf

http://dtcc.com/~/media/Files/Downloads/Data-and-Repository-Services/GTR/GTR-Europe/Summary_ESMA_Technical_Standards.ashx

http://dtcc.com/~/media/Files/Downloads/Data-and-Repository-Services/GTR/GTR-Europe/Summary_ESMA_Technical_Standards.ashx

http://dtcc.com/~/media/Files/Downloads/Data-and-Repository-Services/GTR/GTR-Europe/EMIRvDFA-QandA.ashx

http://dtcc.com/~/media/Files/Downloads/Data-and-Repository-Services/GTR/GTR-Europe/EMIRvDFA-QandA.ashx

http://www.esma.europa.eu/documents/overview/10?title=&doc_reference=&section=All&doc_type=266&x=40&y=8

http://www.esma.europa.eu/documents/overview/10?title=&doc_reference=&section=All&doc_type=266&x=40&y=8

http://www2.isda.org/attachment/NTQxMA==/ISDA%20PN-APN%20Approach%20Document%20v1.0%202013_03_15.xlsx





https://event.on24.com/eventRegistration/EventLobbyServlet?target=registration.jsp&eventid=700397&sessionid=1&key=6397B17393EE25A7AA48715C8C732BD9&sourcepage=register

https://event.on24.com/eventRegistration/EventLobbyServlet?target=registration.jsp&eventid=712067&sessionid=1&key=60143008A0D90C7B22FF0E0CF2BC4E2A&sourcepage=register

8.5 ISDA Taxonomie

http://www2.isda.org/identifiers-and-otc-taxonomies/

8.6 International sFTP Transmission Guide v1.0

http://www.dtcc.com/~/media/Download-Center/GTR/Connectivity/International_sFTP_Transmission_Guide_v1_0.ashx

8.7 Contact List pour OTC Lite

1. OTC Lite UAT [email protected]

2. OTC Lite Questions [email protected]

3. Onboarding [email protected]

4. Counterparty Data Enrichment [email protected]

5. Connectivity Group [email protected]

6. Customer Support Center [email protected]





http://www2.isda.org/identifiers-and-otc-taxonomies/












9 Appendix B – Questions les plus fréquentes (FAQs)

9.1 Sur quel plan géographique et juridictionnel s’ applique OTC Lite?

OTC Lite service , couvre les OTC transactions , concernant les produits dérivatifs, qui doivent être rapportées au GTR , pour être en accord avec L’ European Market Infrastructure Regulation (“EMIR”). Des que l’ EC et ACER ajouteront de nouvelles demandes ,une mise a jour sera faite pour pouvoir satisfaire aux nouvelles exigences.

9.2 Qui peut utiliser OTC Lite service?

Ci-dessous, un tableau ,offrant les différents scenarios d’ utilisateurs utilisant ce service.

Scenarios CFTC JFSA MAS ASIC HKMA

Reporting Obligation

: ESMA (EMIR)

Can User Onboard to OTC Lite?

Scenario 1 Onboarded for one or all of the following already (jurisdiction level)

Yes Yes Yes Yes Yes Yes Yes

Scenario 2

Onboarded for all asset-classes for each jurisdiction but want to report to ESMA on Lite template (Lite template can cater for all asset-classes)

Credit, Interest Rates,

Equity, FX, Commodit

y



y



y



y



y

Yes Yes

Scenario 3

Onboarded for combination of asset-classes for each jurisdiction but not all and want to report to ESMA on Lite template for remaining asset-class/es



y


Equity, FX



y



y

FX, Interest Rates

Yes Yes, no specific limit on reporting any other asset-class

Scenario 4 New user - European reporting obligation only No No No No No Yes Yes

Scenario 5 Existing or New user wants to use Lite template for multi-jurisdictional reporting No No No No No Yes No




Scenario 6

Existing or New user - wants to split their reporting within an asset-class for reporting purposes (i.e. some Rates products submitted on OTC Core solution and others on OTC Lite service)

Yes No - reporting is different, submission is different

Scenario 7 Existing or New user - no European reporting obligation

No No

Scenario 8 Middle Market onboarded through internet No No No No No Yes Yes - search & download only

Scenario 9 Middleware provider reporting data

Yes Yes - but CSV upload only

Scenario 10

Larger new user or user wants to report on behalf of clients - full onboarding direct with GTR Onboarding

Yes Yes - submission & search & download available

9.3 Est-ce qu‘on peut envoyer plusieurs fichiers dans la journée?

Cést possible dénvoyer plusieurs fichiers le même jour, la position message est nécessaire pour déclarer les lifecycle events de la transaction.. La raison du changement de la transaction (Lifecycle event reason ) ainsi que les détails du changement sont ajoutées dans la soumission position .Le dernier Position message reçu représente la situation dans laquelle se trouve la transaction a la fin de la journée, des multiples position messages peuvent être soumis , pour des jours précis, et cela peut être effectué en utilisant as a date / time dans chaque message.

9.4 Quels sont les champs optionnels qui doivent être saisies?

Les entreprises doivent sélectionner quels sont les champs qui doivent remplir, lors de la soumission, cela dépend de la nature de leur transaction . Il y a des champs qui sont obligatoires (Required) ‘ d autres optionnels et facultatifs(Conditional ) .

A signaler , la colonne J du template ( EMIR FIELD) doit être contrôlée pour savoir si on doit saisir ces champs, car ils peuvent s’avérer obligatoires pour être en accord avec EMIR , et nécessaires pour que le rapport envoyé a ESMA soit accepté.




9.5 Est-ce que le champ “Trade Party 2 « doit être rempli, quand le modèle de soumission est Indépendant ?

Une partie qui fait la soumission doit soumettre au moins le Trade Party 2 Prefix & Value (Nom de la contrepartie ou SWIFTBIC, Internal ou Freeformattext). Cela est obligatoire pour transmettre correctement le message ,et pour être en accord avec l EMIR .Le champ Counterparty Region (Pour identifier si la counterpartie est bien en EEA ou non ) est obligatoire pour remplir les demandes de l’EMIR même si il apparait comme optionnel. La raison pour laquelle ce champ est optionnel, est du, car les entreprises n’ont pas toujours l information au moment de la transaction. Un avertissement apparaitra dans le warning report, signalant que ce champ est vide , l entreprise devra soumettre le position message en ajoutant l information manquante pour être en règle .

9.6 Comment je peux soumettre des produits exotiques et structurés?

Ce sont des produits qui ne sont pas standard, et il se peut, qu’il n’existe aucun accord

de comment les soumettre. GTR fournit les champs demandés par ESMA ,les entreprises devront décider par eux-mêmes comment saisir le template .

9.7 Quel est l horaire du système opérationnel DTCC?

DTCC procède le data des rapports de Dimanche a minuit a Vendredi a minuit.

La maintenance du système est faite une fois par semaine, du Samedi 10pm a Dimanche 6am EST




10 Appendix C – DTCC Le meilleur procédé pour télécharger Ci-dessous DTCC Best Practice pour charger les templates .Cela n’a pas l’attention d’être la forme exacte et légal de procéder.

Consultez vos départements internes, la juridiction et le business pour assurer que votre rapport a rempli tous les exigences .

10.1 Cross Asset Guidance ((Matériel sur les actifs)

10 Les participants devront soumettre les messages , en utilisant le même UTI , seulement a une application (Core ou OTCLite) Si la transaction a été soumis dans le Core et dans le OTC Lite, avec le même UTI ..cela va être considéré comme un duplicata par les régulateurs

Message Template Guidance (Guide pour Message Template)

• • Des rapports montrant l’ISDA OTC Taxonomie • • Utilisez ISDA instructions au sujet des notations des prix • • http://www2.isda.org/attachment/NTQxMA==/ISDA%20PNAPN% • 20Approach%20Document%20v1.0%202013_03_15.xlsx • • • Le champ ‘Underlying Asset’ n’est pas applicable pour tous les FX et Commodity produits ainsi

que pour la plupart des Produits Taux d’ Intérêt (Interest Rates) • • Si disponible ISIN pourra être rapporté. • • Le champ ‘Price Multiplier’ est applicable seulement pour les produits des Fondes (Capitaux)

propres • • ‘Quantité ’ sera ‘1’ pour Crédit , Taux d’intérêt et FX produits, mais quand il s’agira des

produits Comodiy et equity ce numéro correspondra au nombre des contrats rapportés . • • Multiple Values seront alignées et jumelés pour le reporting (par ex.: Notional Amount = 110;

120; 130; Notional Currency = USD; GBP; EUR sera rapporté comme 110 USD; 120 GBP; 130 EUR)

• • Les valeurs ,les textes , saisies dans les champs, peuvent contenir des virgules (“,”) si la saisie est entre guillemets “”. Exemple: Beneficiary ID Party 1 Value est un champ qui demande une saisie sous forme de texte , une valeur valide peut être inclus ,mais la valeur soumise dois être entre guillemets pour être acceptée “Fund A LTD.”

• • Les valeurs énumérés dans des Valeurs Valides colonnes sont sensibles. • • Toutes les dates doivent être soumises dans le format YYYY-MM-DD (année-mois-jour). Les

champs de date et de l’heure doivent être soumis sous cette forme YYYY-MM-DDTHH:MM:SSZ et en utilisant l’UTC horaire .

• • DTCC ne donne pas des conseils ou des guides de comment rapporter les produits exotiques, cela est sous la responsabilité de l’entreprise . .




• • Des stratégies de reporting pourraient confirmer l’enregistrement ,si dcela n’est pas fait par des moyens électroniques, la responsabilite du reporting sera laissé a l’entreprise.

• Lifecycle Event Guidance

• Si report ing ‘Notional Amount’ pour un lifecycle event , la valeur pourra toujours êt re la

resulting position • o Au-dessous vous trouvera un exemple:

UTI Lifecycle Event Notional Amount Notional Currency Notes UTI123 Trade 1,000,000.00 EUR UTI123 Increase 1,500,000.00 EUR Increase was for 500,000.00, user reports

outstanding notional

10.2 Technical Guidance(Matériel Technique)

• Des lignes qui ne sont pas désignés pour le traitement pourraient avoir un “*” signe au debut de ligne

• • Des pied de page (Footers) doivent etre inclus a la derniere ligne dans le format suivant: *<4 CHAR OCODE>-END<8 CHIFFRES # DES LIGNES DE MARCHE>

• • i.e.: *8TY6-END00000280 • • Tous les fichiers de télécharger (upload files) doit être en CSV format • • Tous les valeurs énumèrées sont sensibles, à la différence( minuscules-majuscules),

“TRUE” et “true” n est pas la même dans le system • Des valeurs ou des champs de texte peuvent contenir des symboles comme virgules (“,”)

a la condition que une valeur ou des valeurs soit a l’ intérieur de signes de citation “”. • • Par exemple: Beneficiary ID Party 1 Value est un champ de texte par conséquence une

valeur valide peut inclure un symbole mais la valeur soumise doit être dans des signes de citation pour être accepté “Fund A, LTD.”

• • Toutes les dates doit être soumis dans le format de YYYY-MM-DD. Champs de date et temps seront soumise dans le format YYYY-MM-DDTHH:MM:SSZ et dans l’UTC temps.

10.3 Technical Guidance(Matériel Technique) Valid Values

Même-ci OTCLite ne supporte pas le format FpML, ci-dessous vous pouvez trouver des liens indiquant les valeurs valides qui sont dérivés de l’ISDA terminologie, les utilisateurs devront utiliser ces valeurs lors de la saisie des champs .




11 FpML Plans (Schemes) • • Day count fraction http://www.fpml.org/coding-scheme/day-count-fraction • • Floating Rate Index http://www.fpml.org/coding-scheme/floating-rate-index • • Price Quote Unites (Commodities) http://www.fpml.org/coding-scheme/price-quote-units • • ISDA Product ID http://www.fpml.org/coding-scheme/product-taxonomy

Frequency

• M = Month (mois), D = Day (jour), Y =Year (année), W= Week (semaine), T=Term (période) • • Les utilisateurs pourront fournir la fréquence en utilisant ce format chiffres + fréquence (par

ex.: 3M, 4Y, 3W, 1T)

10.4 Interest Rates (Taux d interet)

Spécifications du Produit • Debt Option Strike Price type devrait être soumis comme un pourcentage de pair • • Amortizing notionals et step schedules devront être rapportés dans la position. Les

utilisateurs rapportent un resulting notional, il n’y a pas de lifecycle event rapporté, ceci est un contrat intrinsèque.

• • Floating rate sera le tenor + floating rate • • Les entreprises devraient saisir les champs Leg 1/Leg 2 Payer • • Pour cap floor, le Option Strike Price Type devrait être Cap:basis • • La date de maturité du FRA est (effective date) • • Par exemple: • • Si la date d’ouverture est 2014-01-07 cette date sera pris comme ‘Execution • Timestamp’ • • Si la valeur de la date est 2014-03-19 cette date sera pris comme le ‘Effective Date’ • • Si la date de maturité est 2014-06-18 il sera pris comme ‘Scheduled Termination Date’ • • Collar Trades est une stratégie de marché , dans laquelle, le client peut rapporter la

transaction , en deux (1 Cap et 1 Floor) en utilisant des différents UTI’ s le client peut rapporter ce marche comme un Exotic.

• • Pour les soumissions Rate Resets, les underlying rates, seront jumelés comme une part de l’Inter/Intra TR processus Avec l’accord de votre contrepartie.

(Determination de l’ acheteur)

• • Pour les produits option, l’acheteur de l’ option est perçu comme l’ acheteur • • Pour les produits avec un taux fixe, l’acheteur du taux fixe est perçu comme l’ acheteur • • Pour tous des autres produits il n’y a pas de règle définie




10.5 Commodities

Product Specific • Load Type is only applicable for Electric taxonomies • Delivery End and Start dates do not apply to “Cash” taxonomies • Delivery Point and Interconnection point only apply to Eng:Elec taxonomies • Price/Time field only applicable for Elec. Rates will be in sequence of hours (i.e.: 14;15;16 = Rate

for hour 1 =14, Rate for hour 2 =15, Rate for hour 3 =16)

10.6 Foreign Exchange (Taux de change)

10 Spécifications du Produit • Load Type est seulement applicable pour Electric taxonomies • • Delivery End et Start dates ne s’appliquent pas aux “Cash” taxonomies • • Delivery Point et Interconnection point sont seulement appliqué s aux Eng:Elec taxonomies • • Price/Time champ est seulement applicable Elec. Les taux auront une séquence en heures

(ex.: 14;15;16 = Rate for hour 1 =14, Rate for hour 2 =15, Rate for hour 3 =16)

• Si vous rapportez un FX swap, les utilisateurs pourraient l’envoyer dans deux soumissions, une, comme un FX Spot et la 2ieme comme un FX Forward , avec deux UTI’s différents . Le link ID ,champ pourra être utilisé pour connecter ces deux soumissions.

• • Link ID’s doit être unique et partagé entre les parties. • • Les Utilisateurs peuvent rapporter un FX Swap avec deux FX Spot marchés ou deux FX Forward

marchés. • • Concernant les FX Forwards, la valeur dans le champ ‘Exchange rate 1 (Foreign exchange

only)’ devra être la même que la valeur dans le champ ‘Forward exchange rate (Foreign exchange only)

• • Currency 1 pour la quote de base (quote basis) devrait être rempli dans le champ ‘Notional Currency/Units

• • Currency 2 pour la quote de base (quote basis) devrait être rempli dans le champ ‘Currency 2’ field

• • Pour FX Swaps, le Effective Date est la date d effet du Swap. Pour FX Forwards, le Effective Date est la date du marche.

• • NDF’s sont mis en place dans une date différente a leur maturité. Tous des autres produits sont ont une date maturité.




Buyer determination • Pour les produits option, l’acheteur de l’ option est perçu comme l’ acheteur • • Pour les non-option produits il n’ y a pas de comportement et de pratique a suivre

concernant l acheteur,. Example of an FX Forward Exemple d’ un FX Forward Party 1 achète EUR 1,000 de Party 2 at .80 = £800 on 2014-06-20 * Au- dessous vous pouvez trouver une version du template avec le but d’ illustrer le scenario au-dessus.Consultez le template pour s’assurer que tous les champs sont soumis.

GTR Field Name Sample Value Notes

Version Lite1.0 Message Type Position Action New Transaction Type Trade UTI Prefix UTIPREFIX UTI Value TRANSACTID007 Primary Asset Class ForeignExchange Product ID Prefix 1 ISDA Product ID Value 1 ForeignExchange:Forward Underlying Asset (repeatable up to 2 times semi-colon separated) N/A for FX Notional Currency/Units (repeatable up to 2 times semi-colon separated) EUR

La première dévise devrait être saisie dans le champ exchange rate quote basis (e.g. EUR/GBP)

Settlement Currency (repeatable up to 2 times semi-colon separated)

Applicable seulement pour les Non Deliverable Forwards et les Non Deliverable Options. Sinon on le laisse vide..

Price Notation - Price 0.8 As per the best practice here

Price Notation - Price Type Rate

Notional Amount (repeatable up to 2 times semi-colon separated)

1000;800

Notional 1 s’applique a la première dévise dans le "Notional Currency/Units (repeatable up to 2 times semi-colon separated)" field, le second Notional Amount s’applique a la deuxième dévise

Delivery type C Execution Timestamp 2014-06-20T15:25:00Z Effective Date (repeatable up to 2 times semi-colon separated) 2014-06-24 Une date applicable Scheduled Termination Date 2014-06-24 Date of Settlement (repeatable up to 2 times semi-colon separated)

Applicable pour les Non Deliverable Options et Non Deliverable Forwards

Lifecycle Event New

Currency 2 (Foreign exchange only) GBP

Le champ “devise 2 (Foreign exchange only)” la valeur devrait toujours refleter le payeur de la deuxième dévise signalé dans le champ exchange rate quote basis

Exchange rate 1 (Foreign exchange 0.8 Pour Forwards, le champ “Exchange rate 1 (Foreign





only) exchange only)” devrait être le même que celui de “Forward exchange rate (Foreign exchange only)

Forward exchange rate (Foreign exchange only)

0.8

Pour Forwards, le champ “Exchange rate 1 (Foreign exchange only)” devrait être le même que celui de “Forward exchange rate (Foreign exchange only)

Exchange rate basis (Foreign exchange only)

EUR/GBP

Exchange rate basis (Foreign exchange only) suivra cette succession logique • Notional Currency/Units • Notional Amount (repeatable up to 2 times semi-colon

separated) • Currency 2 (Foreign exchange only) • Leg/Currency 1 Payer • Leg/Currency 2 Payer

Leg/Currency 1 Payer

Trade Party 2

Leg/Currency 1 Payer champ est en relation avec Notional Currency et Notional Amount 1. Pour FX, Leg 1 s devrait toujours refleter le payeur de la première dévise saisie dans le champ exchange rate quote basis

Leg/Currency 2 Payer

Trade Party 1

Leg/Currency 2 Payer champ est en relation avec Notional Currency et Notional Amount 1. Pour FX, Leg 2 s devrait toujours refleter le payeur de la deuxième dévise saisie dans le champ exchange rate quote basis.