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

Transcription

DTCC Product Management
GTR OTC Lite User Guide
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.
DTCC GTR OTC Lite User
Guide French.docx6
Copyright © 2010-2013 by DTCC Deriv/SERV LLC
Page 1 of 68
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
2.4
GTR CSV Message Pied de page (Footer) Fichier .......................................................16
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
Guide French.docx6
Page 2 of 68
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
Guide French.docx6
Page 3 of 68
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
8
ESMA UTI Conflict or Pair LEI Break Report ..............................................................57
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
Guide French.docx6
Page 4 of 68
10.5 Commodities................................................................................................................66
10.6 Foreign Exchange (Taux de change)..................................................................................66
Revision History
Version
V0.1
V0.2
V0.3
V0.4
V0.5
Date
October 30, 2013
November 30,
2013
December 11, 2013
December 12, 2013
January 14, 2014
Guide French.docx6
Revision
Initial Draft
Revisions
New Screenshots
Revised Position Report Table
Revised Q and A section
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
Page 5 of 68
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.
Guide French.docx6
Page 6 of 68
Guide French.docx6
Page 7 of 68
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.
Guide French.docx6
Page 8 of 68
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.
Guide French.docx6
Page 9 of 68
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
Guide French.docx6
Page 10 of 68
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’
autorisation de l Entity, 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.
Guide French.docx6
Page 11 of 68
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).
Guide French.docx6
Page 12 of 68
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/gtreurope/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.
Guide French.docx6
Page 13 of 68
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.
Guide French.docx6
Page 14 of 68
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 liés a des transactions
individuels.
*Have a compliance date of August 11th 2014 Date de conformité 11 août 2014.
Guide French.docx6
Page 15 of 68
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
Constant1
Originator
GTR Value
Length
* Il doit contenir astérisque (ce champ est constant).
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)
1
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
Guide French.docx6
Page 16 of 68
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
*DTC0-END00000004
By
Par exemple quand vous préparez votre SFTP fichier vous devez suivre ce format :
DataTrak Header
Application Header
*Comment Line
*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
Guide French.docx6
Page 17 of 68
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
Monday
Tuesday
Wednesday
Thursday
Friday
2.4
EUDC Submission Cut-off
23:45 UTC Monday
23:45 UTC Tuesday
23:45 UTC Wednesday
23:45 UTC Thursday
23:45 UTC Friday
EUDC Batch Run
00:00 UTC Tuesday
00:00 UTC Wednesday
00:00 UTC Thursday
00:00 UTC Friday
00:00 UTC Saturday
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
All
Message Type
Any*
Action
New
Transaction
Type
PositionCancel
*Any refers to any message type and transaction type where Cancel applies
Lifecycle
Event
N/A
ESMA
Action
Error
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*
New Trade
Backload
Message
Type
Position
Position
Novation Trade (a New Trade as Position
a result of a novation)
Action
Transaction Type**
Lifecycle Event
New
New
Trade
Backload or Trade
New
Trade
Trade or New
N/A or
Backload
NovationTrade
ESMA
Action
New
New
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.
Guide French.docx6
Page 18 of 68
2.4.2 Compte-rendu d’ un Evénement post-marché
rapporter Trade events.
Trade Event
Amendment
Modification
Increase
Partial Novation
Termination
Partial Termination (FX and
Credits only)
Fee Amendment
Compression* (original
trade part-terminated)
Succession (Credit only)
Credit Event (Credit only)
Partial Exercise (FX only)
Exercise
Corporate Action
Message
Type
Position
Position
Position
Position
Position
Position
Action
Lifecycle Event
ESMA Action
New
New
New
New
New
New
Transaction
Type
Trade
Trade
Trade
Trade
Trade
Trade
Amendment
Modify
Increase
Novation
Termination
PartialTermination
New
Modify
New
Cancel
Cancel
Cancel
Position
Position
New
New
Trade
Trade
Amendment
Compression
New
Compression
Position
Position
Position
Position
Position
New
New
New
New
New
Trade
Trade
Trade
Trade
Trade
CreditEvent
CreditEvent
PartialExercise
Exercise
CorporateAction
New
New
Cancel
Cancel
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
supprimer un contrat qui déjà existe.
Trade Event
Full Termination
Full Novation
Compression (original
trade terminated)
Exercise
Partial Exercise
(FX Only)
Exit
Position Cancel
Message
Type
Position
Position
Position
Action
Lifecycle Event
ESMA Action
New
New
New
Transaction
Type
Exit or Trade
Exit or Trade
Exit
Termination
Novation
Compression
Cancel
Cancel
Compression
Position
Position
New
New
Exit
Exit or Trade
Exercise
Partial Exercise
Cancel
Cancel
Position
Position
New
New
Exit
PositionCancel
Exit
N/A
Cancel
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.
Guide French.docx6
Page 19 of 68
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.
1
1
2
3
Event
New Purchase
Partial Unwind
Partial Unwind
Partial Unwind
Lifecycle
Event Field
Trade
Termination
Termination
Termination
Trade Notional
Amount
10M
10M
2M
8M
2M
6M
2M
4M
As of Date Time
Comment
01-May-2014 T09:00
01-May-2014 T14:00
02-May-2014 T10:00
03-May-2014 T10:02
Logging in position
Termination 1
Termination 2
Termination 3
Termination 1 dans le fichier 1 doit-être cancellé :
File
No.
4
Event
Lifecycle
Event Field
Error
Trade Notional
Amount
8M
As of Date Time
Comment
01-May-2014 T14:00
Telling DTCC the 1st partial unwind
should be cancelled
Bringing the remaining notional back
to 8M as the 1st unwind is cancelled
Bringing the remaining notional back
to 6M as the 1st unwind is cancelled
To make sure the latest position is
updated
5
Modify
8M
02-May-2014 T10:00
6
Modify
6M
03-May-2014 T10:02
6M
Current Time
7
Guide French.docx6
Page 20 of 68
Le tableau au-dessous récapitule des événements supportes (permis) par le GTR.
Business Event
Lifecycle Event
Trade
New
Amendment
New Trade
Amendment
Backload
Termination resulting from compression
Exercise (Full)~
Exercise (Partial)
Increase
Novation Full (Stepping out & remaining parties)~
Novation Partial (Stepping out & remaining parties)
Novation (Stepping in & remaining parties)
Termination Full~
Termination Partial
Valuation Update
Global Cancel (Withdrawing the trade)
Exit or AutoExit
Corporate Action
Fee Amendment
Credit Event
Backload
Compression
Termination (for all asset class)
PartialTermination (Credit)
(with compressed flag indicator true)
Amendment (Rates and Commodity)
(with compressed flag indicator true)
Exercise
PartialExercise (FX)
Increase
Amendment (Rates)
Novation
Termination (Rates)
Novation
Termination (Rates)
Novation-Trade
NovationTrade
PartialTermination (Credit)
Termination
PartialTermination (Credit and FX)
Termination (Rates, Equity, Commodity)
N/A
Cancel
Error
Exit
CorporateAction (Equity)
Amendment
Termination
Exit
Modify
Cancel
Error
Guide French.docx6
Page 21 of 68
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.
Reporting Model
independent
Full Delegation
Guide French.docx6
Bi-lateral
On-facility
Non-cleared
Cleared
Non-cleared
Cleared
Paper Confirm M/ware Conf/Aff M/ware Conf/Aff
1
4
6
3
2
5
Page 22 of 68
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.
Party A
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.
2,3
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
4,7,9
6,8,10
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
1
Party B
2,3
Middleware
6,12,14
5,11,13
TR
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).
Guide French.docx6
Page 23 of 68
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)
1
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.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
GTR renvoie un ACK à Party A
Intra-day parties sont d’accord de faire un amendement du contrat
Parties envoient amendement á la 3eme partie
Party A soumis Position message pour indiquer un Amendement au GTR
Party A envoie un Valuation message
GTR envoie un ACK à Party A
Party A envoie un Collateral message
Party B envoie un Valuation message
GTR envoie un ACK à Party B
Party B envoie un Collateral message
GTR renvoie un ACK à Party B
Guide French.docx6
Party B
Party A
6
2,3
2,3
5,9,11,13
7
Middleware
4,8,10,12
15,17
14,16
TR
Page 24 of 68
7
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
4. Party A envoie un EOD Position message en récapitulant les positions ouvertes, et en incluant les évaluations
6. Party A envoie un Collateral et Valuation message au GTR
7. GTR renvoie un ACK à Party A
1
Party B
Party A
2, 4, 6
3, 5, 7
TR
Guide French.docx6
Page 25 of 68
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.
2.
3.
4.
5.
6.
7.
8.
Le contrat est registré à la plateforme de léxécution et envoyé aux Parties A & B.
La plateforme de léxécution générera un UTI et il sera envoyé aux Parties A & B.
Party A envoie un Position message au TR pour lui- même.
Party B envoie un Position message au TR pour lui- même.
GTR envoie un ACK à Party B
Party A rapporte un Valuation message et Collateral message a partir de la base qui est en cours
Party B rapporte Valuation message et Collateral message a partir de la base qui est en cours
1, 2
Party A
1, 2
Execution Platform
3, 4, 7
Party B
5, 6, 8
TR
Guide French.docx6
Page 26 of 68
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.
2.
3.
4.
5.
6.
Le contrat est registr é à la plateforme de léxécution et envoyé aux Parties A & B.
La plateforme de léxécution générera un UTI et il sera envoyé aux Parties A & B .
Party A envoie un Position message au TR au nom des deux parties.
Party A rapporte un Valuation message et Collateral message a partir de la base qui est en cours.
Party B rapporte un Valuation message and Collateral message a partir de la base qui est en cours.
1, 2
Party A
1, 2
Execution Platform
3, 4, 5
Party B
6
TR
Guide French.docx6
Page 27 of 68
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 il 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
Guide French.docx6
Page 28 of 68
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
Schema Syntax
Validation
GTR Core Validation
Permission, UTI lock,
transaction & action type
consistency validation.
Is CSV valid? Are fields
formatted correctly?
GTR Business
Validation
e.g. Does the post-trade
CCY = the position CCY?
3.2 Business validation
Le cadre de Business Validation couvrira :

 GTR Control Fields (Champs)

 D‘
autres champs juridictionnel obligatoi
res. 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
Guide French.docx6
Page 29 of 68
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
ACCEPT
REJECT
Description
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.
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
Page 30 of 68
Guide French.docx6
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 contiendra seulement les avertissements ouverts pour cet
te journée

 Il ne contiendra pas des avertissements sur position message qui ont été corrigés pendant la
journée

 L’
actuel GTR reporting 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).
Guide French.docx6
Page 31 of 68
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:

 Contrepartie 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 partie 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 contreparties peuvent déléguer la responsabilité de reporting a une 3 partie.

 Pour cleared trades les contreparties peuvent déléguer le reporting à CCP

 Dans tous les cas contrepartie/CCP
le
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 partie ce champ doit contenir la valeur “
Independen
t”.

 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.
Page 32 of 68
Guide French.docx6
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 attendra de
recevoir contrepartie data et common data soumis au nom seulement de la Partie 1.

 Le champ Reporting Delegation 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 Reporting Delegation Model doit contenir la value “
Full”
ou rester vide.

 Si une partie ou la totalité du data de contrepartie 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 mettre à 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:
Submitted
By
Submitted
For
Delegation
Model
Commo
n
Bank A
Bank A
Independent
Y
Y
N
Client B
Client B
Independent
Y
Y
N
Third Party
Bank A
Independent
Y
Y
N
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
Scenario
Independent
Reporting
Independent
Reporting
Independent
Reporting
Independent
Reporting
Guide French.docx6
Trade Party 1
fields
Trade Party 2
fields
Page 33 of 68
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.
Guide French.docx6
Page 34 of 68
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
Independent
Reporting
1
2
Resp. per
party
Common
CP1
CP2
Ctpy 1


X
Ctpy 2

X

Ctpy 1



Ctpy 2
X
X
X
Full Delegation
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
Guide French.docx6
Page 35 of 68
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.
Guide French.docx6
Page 36 of 68
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.
Guide French.docx6
Page 37 of 68
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.
Guide French.docx6
Page 38 of 68
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
Exempt
N/A
Unpaired
Unpairable
Paired
Pairing Error
Pair LEI Break
Guide French.docx6
Trade Pairing Status Description
The position will not require pairing as the Counterparty Region is non-EEA.
The positions will not require pairing as the Reporting Obligation does not include ESMA.
Pairing has either yet to be attempted or that no pair has been located thus far.
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).
The Position has been successfully paired either within the GTR or with another TR.
When a position has had external Pairing attempted but more than one TR has responded
with the same positions details.
When a position pair has been found where the UTI and one LEI match but the other LEI
does not match.
Page 39 of 68
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
Exempt
N/A
Pending
Cancel
Matched
Unmatched1
Guide French.docx6
Trade Match Status Description
The position will not require matching as Counterparty Region is non-EEA.
The position will not require matching as Reporting Obligation does not include ESMA.
The position has not been paired yet or has been paired but the matching process is yet to
take place.
The position was previously eligible for matching but a cancellation or exit message has
been received.
The position has been reconciled and the key category 1 and category 2 fields match
within the prescribed tolerance.
The position has been reconciled and one or more category 1 fields do not match within
Page 40 of 68
Unmatched2
Unmatched
the prescribed tolerance but all the category 2 fields do match within the prescribed
tolerance.
the prescribed tolerance but all the category 1 fields do match within the prescribed
tolerance.
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
2
3
13
Field Name
Counterparty Id
ID of the other counterparty
Counterparty side
ESMA Format
LEI
LEI
‘B’ = buyer, or
‘S’ = seller
Match / Tolerance Rule to other trade
Must match id of the other counterparty
Must match id of the counterparty
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 éle
vé.
6. 
 Soustraction du montant le plus petit 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 ncordent
co
pas.
Guide French.docx6
Page 41 of 68
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
1
Taxonomy used
2
Product id 1
3
Product id 2
4
Underlying
5
Notional currency
1
Notional currency
2
Deliverable
currency
Trade id
Transaction
reference number
Venue of
execution
Identify the taxonomy used:
U=Product Identifier [endorsed in Europe]
I=ISIN/AII + CFI
E=Interim taxonomy
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
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
ISIN (12 alphanumerical digits); LEI (20
alphanumerical digits); Interim entity identifier
(20 alphanumerical digits); UPI (to be defined);
B= Basket; I=Index.
ISO 4217 Currency Code, 3 alphabetical digits.
6
7
8
9
10
11
Compression
12
Price/rate
13
Price notation
Guide French.docx6
Match/ Tolerance Rule
to other trade
Must match
Category
1
Must match
1
Must match
1
Must match
2
Must match
1
Must match
1
May not match
3
Up to 52 alphanumerical digits.
An alphanumeric field up to 40 characters
Must match
Will never match
1
3
ISO 10383 Market Identifier Code (MIC), 4 digits Should match
alphabetical.
Where relevant, XOFF for listed derivatives that
are traded off-exchange or XXXX for OTC
derivatives.
Y = if the contract results from compression; N= Should match
if the contract does not result from
compression.
Up to 20 numerical digits in the format
Apply tolerance check 1
xxxx,yyyyy.
2
E.g. ISO 4217 Currency Code, 3 alphabetical
digits, percentage.
2
Must match
2
2
Page 42 of 68
No.
Name
14
Notional amount
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
ESMA Format
xxxx,yyyyy.
Price multiplier
Up to 10 numerical digits.
Quantity
Up to 10 numerical digits.
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.
Delivery type
C=Cash, P=Physical, O=Optional for
counterparty.
Execution
ISO 8601 date format / UTC time format.
timestamp
Effective date
ISO 8601 date format.
Maturity date
Termination date ISO 8601 date format.
Date of
settlement
Master
Free Text, field of up to 50 characters,
agreement type
identifying the name of the Master Agreement
used, if any.
Master
Year, xxxx.
agreement
version
Confirmation
ISO 8601 date format, UTC time format.
timestamp
Confirmation
Y=Non-electronically confirmed, N=Nonmeans
confirmed, E=Electronically confirmed.
Clearing
Y=Yes, N=No.
obligation
Cleared
Y=Yes, N=No.
Clearing
ISO 8601 date format, UTC time format.
timestamp
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).
Intragroup
Y=Yes, N=No.
Fixed rate leg 1
Numerical digits in the format xxxx,yyyyy.
(tolerance tba)
Fixed rate leg 2
Numerical digits in the format xxxx,yyyyy.
(tolerance tba)
Fixed rate day
Actual/365, 30B/360 or Other.
count
Fixed leg payment An integer multiplier of a time period describing
frequency
how often the counterparties exchange
payments, e.g. 10D, 3M, 5Y.
Guide French.docx6
to other trade
Category
Must match
Must match
1
1
2
Must match
2
for OTC.
Must match
Must match
Must match
Cannot match
2
Cannot match
3
Cannot match
3
2
Should match
2
Must match
2
Must match
1
2
Must match
2
Should match
2
2
2
Cannot match
3
Cannot match
3
1
2
1
2
3
Page 43 of 68
No.
Name
37
Floating leg
payment
frequency
Floating leg reset
frequency
38
39
40
41
42
Floating rate of
leg 1
Floating rate of
leg 2
Currency 2
Exchange rate 1
43
Forward
exchange rate
44
Exchange rate
basis
45
Commodity Base
46
Commodity
Details
47
Delivery Point or
zone (energy)
Interconnection
point (energy)
Load Type
(energy)
48
49
50
Delivery start
date time
(energy)
Guide French.docx6
ESMA Format
to other trade
An integer multiplier of a time period describing Cannot match
An integer multiplier of a time period describing Cannot match
The name of the floating rate index, e.g. 3M
Cannot match
Euribor.
The name of the floating rate index, e.g. 3M
Cannot match
Euribor.
Must match
Must match
xxxx,yyyyy.
Tolerance check 1 will
be applied
Must match
xxxx,yyyyy.
Tolerance check 1 will
be applied
E.g. EUR/USD or USD/EUR. 2 X ISO 4217
Must match
Currency Code, 3 alphabetical digits separated
by a slash.
AG=Agricultural
Should match
EN=Energy
FR=Freights
ME=Metals
IN= Index
EV= Environmental
EX= Exotic
AG=Agricultural
Should match
EN=Energy
FR=Freights
ME=Metals
IN= Index
EV= Environmental
EX= Exotic
EIC code, 16 character alphanumeric code.
Must match
Category
3
3
3
3
2
2
2
2
2
2
2
Free text, field of up to 50 characters.
Cannot match
3
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
Must match
2
Page 44 of 68
No.
Name
ESMA Format
51
Free text, field of up to 50 characters.
Cannot match
3
10 numerical digits in the format xxxx,yyyyy.
1
10 numerical digits in the format xxxx,yyyyy.
2
55
56
Delivery end date
time (energy)
Contract Capacity
(energy)
Quantity Unit
(energy)
Price/time
interval quantities
(energy)
Option type
Option style
to other trade
Must match
Must match
Must match
2
2
57
Strike price
2
58
Action type and
details of action
type
P=Put, C=Call.
A=American, B=Bermudan, E=European,
S=Asian.
Up to 10 Numerical digits in the format
xxxx,yyyyy.
52
53
54
Category
2
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
Guide French.docx6
Page 45 of 68
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.
Guide French.docx6
Report
Report Description
Page 46 of 68
No.
Report
Report Description
1
ACK/NACK Report
/Spreadsheet Download Report
(Upload Status Report)
2
Warning Report
3
GTR ESMA OTC Position Report
4
GTR ESMA OTC Activity Report
5
ESMA Match Status Report
6
UTI Conflict and Pair Break LEI
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.
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.
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
alleges will be included regardless of what service the UTI was
reported through.
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
alleges will be included regardless of what service the UTI was
reported through.
Reports of the pairing and match status by UTI. Any unmatched
fields are listed.
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
2
3
4
5
Transaction Type
Message Type
UTI Prefix
UTI Value
Trade
Position
IssuerA
UTI123
6
7
8
Asset Class
Product ID Prefix 1
Product ID Value 1
Equity
ISDA
Equity:Swap:Pri
ceReturnBasicP
Action will indicate if the incoming message is 'New', 'Modify'
or 'Cancel'
Transaction Type as defined in the upload template
Message Type on the submissions
Prefix for UTI
Unique Trade Identifier;
UTI Value of the Submission
The Primary Asset Class
The First Product Identifier prefix
The First Product Identifier value
Guide French.docx6
Page 47 of 68
No.
Field Name
Sample Data
erformance:Sin
gleName
Description
9
10
11
Product ID Prefix 2
Product ID Value 2
Execution Timestamp
12
Data Submitter Prefix
13
14
15
5678
LEI
5678
Submitting Party ID Value
The First Counterparty prefix
The First Counterparty Value
LEI
3214
The Second Counterparty prefix
The Second Counterparty Value
123456
EMIR Specific field
Adft56687
ESMA
Internal Trade Reference Number of either party
Jurisdictions where trade is reportable
ESMA
Jurisdictions where trade is reportable
CSV123
23
Data Submitter Value
Trade Party 1 Prefix
Trade Party 1
Value
Trade Party 2
Value
Transaction Reference
Number
Internal Trade Reference
Reporting Obligation
Party 1
Reporting Obligation
Party 2
Data Submitter Message
ID
Submission Date & Time
24
Status
ACCEPTED
Reference provided by the submitting firm on each message
within the CSV file
Submission Date and Time in UTC format. This is the time the
submission was received by GTR.
( YYYY-MM-DDTHH:MM:SSZ )
The Status of the message in GTR.
16
17
18
19
20
21
22
2012-0209T15:25:00Z
LEI
2012-0327T11:25:00Z
The Second Product Identifier prefix
The Second Product Identifier value
The time and date of execution of the transaction in
Coordinated Universal Time (UTC).
(YYYY-MM-DDTHH:MM:SSZ)
Submitting Party ID Prefix
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
Guide French.docx6
Page 48 of 68
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.
1
2
3
4
5
Field Name
Sample Data
Description
UTI Prefix
UTI Value
Primary Asset Class
Product ID Prefix 1
Product ID Value 1
XXX
123
Equity
ISDA
Equity:Swap:Pri
ceReturnBasicP
erformance:Sin
gleName
Identify a prefix for the UTI (placeholder)
UTI assigned to the submission
Asset class for the submission
Indicates the taxonomy of the product used (ISDA preferred)
Product Value as specified by ISDA taxonomy
LEI
5678
LEI
Prefix of identifier of party submitting the trade
Value of identifier of party submitting the trade
Prefix of identifier of party on behalf of which the submission
is made
Value of identifier of party on behalf of which the submission
is made
When the submission to the GTR was processed
6
7
8
9
10
Product ID Prefix 2
Product ID Value 2
Submitted For Prefix
11
Submitted For Value
5678
12
Submission Date/Time
13
2012-0326T09:10:10Z
LEI
14
Trade Party 1 Value
5678
15
16
17
Bank A
100000
USD
18
Trade Party 1 Name
Trade Party 1 Notional
Currency/Units
19
Trade Party 2 Value
3214
20
21
22
Trade Party 2 Name
Currency/Units
Transaction Reference
Number
Internal Trade Reference
Bank B
100000
USD
Prefix of identifier for the second party named as a
counterparty on the trade
Prefix of identifier for the second party names as a
counterparty on the trade
Derived from Prefix/Value combination
Notional reported by party 2
Currency for the notional reported by party 2
1323423
EMIR specific field
23
24
Guide French.docx6
LEI
T98765
Prefix of identifier for the first party named as a counterparty
on the trade
Prefix of identifier for the first party named as a counterparty
on the trade
Derived from Prefix/Value combination
Notional reported by party 1
Currency for the notional reported by party 1
Page 49 of 68
No.
25
26
27
Field Name
Sample Data
Description
Data Submitter Message
ID
Warning Reason Code
Warning Description
CSV789
Reference provided by the submitting firm on each message
within the CSV file
Reason code for the warning
Reason description for the warning
12
Unknown
Counterparty
Ci-dessous il y a une liste des avertissements et leur descriptions:
Error Code
OTLW1001
OTLW1002
OTLW1003
OTLW1004
OTLW1005
OTLW1006
OTLW1007
OTLW1008
OTLW1009
OTLW1010
OTLW1011
OTLW1012
OTLW1013
OTLW1014
OTLW1015
OTLW1016
OTLW1017
OTLW1018
OTLW1019
OTLW1020
OTLW1021
OTLW1022
OTLW1023
OTLW1024
OTLW1025
OTLW1026
OTLW1027
OTLW1028
OTLW1029
OTLW1030
OTLW1031
Error Description
Reporting Obligation Party 2 is required when reporting on behalf of both counterparties
Trade Party 2 Domicile is required when reporting on behalf of both counterparties
Trading capacity Party 2 is required when reporting on behalf of both counterparties
Buyer Value Party 2 is required when reporting on behalf of both counterparties
Trade Party 2 Financial Entity Jurisdiction or Trade Party 2 Non-financial Entity Jurisdiction is required
when reporting on behalf of both counterparties
MTM Currency Party 2 is required when reporting on behalf of both counterparties
Valuation Datetime Party 2 is required when reporting on behalf of both counterparties
Valuation Type Party 2 is required when reporting on behalf of both counterparties
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
Trade Party 2 Corporate Sector is required when Trade Party 2 Financial Entity Jurisdiction is "ESMA"
The Directly linked to commercial activity or treasury financing Party 2 is required to be populated if
Party 2 is a non-financial entity
Clearing Broker Party 2 Value is required when the trade is cleared
Beneficiary ID Party 2 Value is required for Trade Party 2 when reporting on behalf of both
counterparties and trading capacity is Agent
Clearing Threshold Party 2 is required when Trade Party 2 Non-financial Entity Jurisdiction is "ESMA"
UTI is greater than 52 characters
Counterparty Region is required for ESMA reporting (Trade with non-EEA counterparty)
Clearing Broker Party 1 is required when the trade is cleared
Settlement Currency is required for ESMA reporting
Execution Venue Value is required for ESMA reporting
Price Notation - Price is required for ESMA reporting
Price Notation - Price Type is required for ESMA reporting
Delivery type is required for ESMA reporting
Execution Timestamp is required for ESMA reporting
Effective Date is required field for ESMA reporting
Date of Settlement is required for ESMA reporting
Clearing Timestamp is required for ESMA reporting
Clearing DCO Value is required for ESMA reporting
Clearing Threshold Party 1 is required for ESMA reporting
MTM Currency CCP is required
Valuation Datetime CCP is required
Valuation Type CCP is required
Guide French.docx6
Page 50 of 68
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 #
1
EMIR Field
ESMA Table reference
GTR FIELD MAPPING
Reporting timestamp
Trade Party 1 Value
Counterparty ID
Table 1 - Counterparty Data
GTR Control field
GTR Control field
Derived
Name of the counterparty
Trade Party 1 Value
ID of the other Counterparty
GTR Control field
GTR Control field
GTR Control field
GTR Control field
8
Name of the other counterparty
Trade Party 1 Branch Location
Trade Party 2 Branch Location
Domicile of the counterparty
Corporate sector of the counterparty
Financial or non-financial nature of
the counterparty
Broker Id Party 1 Prefix
Broker Id Party 2 Prefix
Broker ID
9
Party 1 Reporting Obligation
Reporting Jurisdiction
Reporting entity ID
GTR Control field
GTR Control field
GTR Control field
GTR Control field
10
Clearing Broker Party 1 Prefix
Clearing Broker Party 1 Value
Clearing member ID
GTR Control field
GTR Control field
11
Beneficiary ID Party 1 Prefix
Beneficiary ID Party 1 Value
Beneficiary ID
GTR Control field
GTR Control field
Execution Agent Party 1 Prefix
GTR Control field
2
4
3
4b
5
6
7
Guide French.docx6
GTR Control field
GTR Control field
Trade Party 1 Prefix,
Trade Party 1 Value
Derived or Provided - Name of Trade Party 1
Trade Party 2 Prefix,
Trade Party 2 Value
Derived or Provided - Name of Trade Party 2
Trade Party 1 Domicile
Trade Party 1 Corporate Sector
Trade Party 1 Financial Entity Jurisdiction,
Trade Party 1 Non-financial Entity Jurisdiction
Broker Id Party 1 Prefix,
Broker Id Party 1 Value
Data Submitter Prefix,
Clearing Broker Party 1 Prefix,
Clearing Broker Party 1 Value,
Beneficiary ID Party 1 Prefix,
Beneficiary ID Party 1 Value
Page 51 of 68
ESMA
Table #
EMIR Field
Execution Agent Party 1 Value
Trading capacity
Counterparty side
Trade with non-EEA counterparty
Directly linked to commercial activity
or treasury financing
Clearing threshold
Mark to market value of contract
GTR Control field
19
Currency of mark to market value of
the contract
Valuation date
20
Valuation time
21
Valuation type
22
23
24
25
26
Collateralisation
Collateral portfolio
Collateral portfolio code
Value of the collateral
Currency of the collateral value
Primary Asset Class
Secondary Asset Class
Product ID Prefix
Product ID Value
Taxonomy used
Product ID 1
Product ID 2
Underlying leg 1
Underlying leg 2
Notional currency 1
Notional currency 2
Deliverable currency 1
Deliverable currency 2
UTI Prefix
UTI Value
USI Prefix
USI Value
Trade Party 1 Transaction Id
Trade ID
Prior UTI Prefix
Prior UTI Value
Trade Link ID
Exchange Traded Derivative
indicator
GTR Control field
GTR Control field
GTR Control field
GTR Control field
Table 2 - Common Data
GTR Control field
GTR Control field
GTR Control field
GTR Control field
GTR Control field
GTR Control field
GTR Control field
GTR Control field
GTR Control field
12
13
14
15
16
17
18
1
2
3
4
4a
5
6
7
7a
8
Guide French.docx6
GTR FIELD MAPPING
Trading capacity Party 1
Buyer Prefix (Party 1), Buyer Value (Party 1)
Counterparty Region
Directly linked to commercial activity or
treasury financing Party 1
Clearing Threshold Party 1
MTM Value Party 1
MTM Value CCP
MTM Currency party 1
MTM Currency CCP
Valuation Datetime Party 1
Valuation Datetime CCP
Valuation Datetime Party 1
Valuation Datetime CCP
Valuation Type
Valuation Type CCP
Collateralized Party 1
Collateral portfolio code Party 1
Collateral portfolio code Party 1
Value of the collateral Party 1
Currency of the collateral value Party 1
Product ID Prefix
Product ID value 1
Product ID Value 2
Underlying Asset leg 1
Underlying Asset leg 2
Notional Currency
Notional Currency
Settlement Currency
Settlement Currency
UTI Prefix, UTI Value
Page 52 of 68
ESMA
Table #
EMIR Field
31
Execution Venue Prefix
Venue of execution
Compression
Price / rate
Price notation
Notional amount leg 1
Notional amount leg 2
Price multiplier
Quantity
Up-front payment
Up-front currency 1
Up-front payment 2
Up-front currency 2
Up-front payment 3
Up-front currency 3
Up-front payment 4
Up-front currency 4
Up-front payment 5
Up-front currency 5
Up-front payment 6
Up-front currency 6
Delivery type
Execution timestamp
Effective date leg 1
Effective date leg 2
Maturity date
Termination date
Settlement date 1
Master Agreement type
Master Agreement version
Confirmation timestamp
Confirmation means
Clearing obligation
Cleared
Clearing timestamp
Clearing DCO Prefix
CCP ID
GTR Control field
GTR Control Field
32
33
34
35
35b
36
36b
37
Intragroup
Fixed rate of leg 1
Fixed rate of leg 2
Fixed rate day count 1
Fixed rate day count 2
Fixed leg payment frequency 1
Fixed leg payment frequency 2
Floating rate payment frequency 1
10
11
12
13
14
14a
15
16
17
17a
17b
17c
17d
17e
17f
17g
17h
17i
17j
17k
18
19
20
20a
21
22
23
24
25
26
27
28
29
30
Guide French.docx6
GTR FIELD MAPPING
Execution Venue Value
Compression
Price Notation - Price
Price Notation - Price Type
Notional Amount
Notional Amount
Price Multiplier
Quantity
Upfront payment
Upfront payment CCY
Upfront payment
Upfront payment CCY
Upfront payment
Upfront payment CCY
Upfront payment
Upfront payment CCY
Upfront payment
Upfront payment CCY
Upfront payment
Upfront payment CCY
Delivery type
Execution Timestamp
Effective date
Effective date
Scheduled Termination Date
Termination date
Date of Settlement
Master Agreement type
Master Agreement version
Confirmation Date Time
Confirmation Type
Mandatory Clearing Indicator
Cleared
Clearing Timestamp
Clearing DCO Prefix
Clearing DCO Value
Intragroup
Fixed rate of leg 1
Fixed rate of leg 2
Fixed rate day count
Fixed rate day count
Fixed leg payment frequency
Fixed leg payment frequency
Floating rate payment frequency
Page 53 of 68
ESMA
Table #
37b
38
38b
39
39b
40
40b
40c
40d
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
EMIR Field
GTR FIELD MAPPING
Floating rate payment frequency 2
Floating rate reset frequency 1
Floating rate reset frequency 2
Floating rate of leg 1
Floating rate spread of leg 1
Leg 1 Payer
Leg 2 Payer
Currency 2
Exchange rate 1
Forward exchange rate
Exchange rate basis
Commodity base
Commodity details
Delivery point or zone
Interconnection Point
Load type
Delivery start date and time
Delivery end date and time
Contract capacity
Quantity Unit
Price/time interval quantities
Option type
Option style (exercise)
Strike price (cap/floor rate)
57b
57c
58
Option Strike Price Type
Option Strike Price CCY
Lifecycle Event
Lifecycle Event Effective Date
Action type
GTR Control Field
GTR Control Field
Floating rate payment frequency
Floating rate reset frequency
Floating rate reset frequency
Leg 1 Payer
Leg 2 Payer
Currency 2
Exchange rate 1
Forward exchange rate
Exchange rate basis
Commodity base
Commodity details
Delivery point or zone
Interconnection Point
Load type
Delivery start date and time
Delivery end date and time
Contract capacity
Quantity Unit
Price/time interval quantities
Option Type
Option Style
Option Strike Price
Option Strike Price Type
59
Details of action type
Lifecycle Event
Action
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
Guide French.docx6
Page 54 of 68
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 identifier)

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
ABC123
ABC124
SAMPLE98765LEI7ABCD
SAMPLE98765LEI7ABCD
SAMPLE123LEI456ABCD
SAMPLE123LEI456ABCD
ABC125
SAMPLE98765LEI7ABCD
SAMPLE123LEI456ABCD
ABC126
ABC127
SAMPLE98765LEI7ABCD
SAMPLE98765LEI7ABCD
SAMPLE789LEI456EFGH
SAMPLE789LEI456EFGH
ABC128
SAMPLE98765LEI7ABCD
SAMPLE789LEI456EFGH
ABC129
SAMPLE98765LEI7ABCD
SAMPLE123LEI456ABCD
ABC130
ABC131
SAMPLE98765LEI7ABCD
SAMPLE98765LEI7ABCD
SAMPLE123LEI456ABCD
SAMPLE789LEI456EFGH
Guide French.docx6
Trade Reconciliation Status
Single-sided, unpaired, non EEA
Single-sided, unpaired, EEA
Dual-sided, unmatched category
1
Dual-sided, unmatched category
2
Dual-sided matched
Single-sided, paired, unmatched
category 1
Single-sided, paired, unmatched
category 2
Single-sided, paired, match
pending
Single-sided, paired, matched
Unmatched Fields
Notional Amount Leg
1 - 1; Notional
Currency 1 - 1;
Confirmation
Timestamp - 2
Party 1
Transaction ID
OUR123REF
OUR124REF
OUR125REF
Effective Date - 2
OUR126REF
OUR127REF
Cleared - 1
Exchange Rate - 2;
Execution Timestamp 2
OUR128REF
OUR129REF
OUR130REF
OUR131REF
Page 55 of 68
For reference, below are the Trade Reconciliation Status descriptions:
Trade Reconciliation Status
Single-sided, unpaired, non EEA
Single-sided, unpaired, EEA
Dual-sided, unmatched
category 1
Dual-sided, unmatched
category 2
Dual-sided matched
Single-sided, paired,
unmatched category 1
Single-sided, paired,
unmatched category 2
Single-sided, paired, match
pending
Single-sided, paired, matched
Guide French.docx6
Trade Reconciliation Status description
The trade is ESMA reportable but the other side of the trade is not ESMA reportable and
therefore there is no reconciliation requirement.
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.
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 listed on the TR reconciliation
Differences Report.
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 listed on the TR reconciliation
Differences Report.
The GTR has both sides of the trade and all fields match within the tolerances defined in
Appendix A.
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 listed on the TR reconciliation Differences Report.
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 listed on the TR reconciliation Differences Report.
obtained from the TR with the other side of the trade. Match processing has not taken place
yet.
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.
Page 56 of 68
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”]
No.
1
2
3
4
Field Name
UTI
Party 1 LEI
Party 2 LEI
Error Code
Sample Data
ABC123
SAMPLE98765LEI7ABCD
SAMPLE123LEI456ABCD
UTI reported by other parties
Description
"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
Guide French.docx6
Page 57 of 68
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/GTREurope/Summary_ESMA_Technical_Standards.ashx
8.1.3 EMIR vs. DFA Comparaison
http://dtcc.com/~/media/Files/Downloads/Data-and-Repository-Services/GTR/GTREurope/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%20PNAPN%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
Guide French.docx6
Page 58 of 68
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/DownloadCenter/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]
Guide French.docx6
Page 59 of 68
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)
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 assetclasses)
Credit,
Interest
Rates,
Equity, FX,
Commodit
y
Yes
FX, Interest
Rates
Yes
Yes, no specific limit on
reporting any other
asset-class
Scenario 4
New user - European reporting obligation only
No
Credit,
Interest
Rates,
Equity, FX,
Commodit
y
Credit,
Interest
Rates,
Equity, FX,
Commodit
y
No
Yes
Scenario 3
Credit,
Interest
Rates,
Equity, FX,
Commodit
y
Credit,
Interest
Rates,
Equity, FX,
Commodit
y
No
Credit,
Interest
Rates,
Equity, FX,
Commodit
y
Onboarded for combination of asset-classes for
each jurisdiction but not all and want to report
to ESMA on Lite template for remaining assetclass/es
Credit,
Interest
Rates,
Equity, FX,
Commodit
y
Credit,
Interest
Rates,
Equity, FX,
Commodit
y
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
Guide French.docx6
Credit,
Interest
Rates,
Equity, FX
Page 60 of 68
Can User Onboard to
OTC Lite?
Scenario 6
Scenario 7
Scenario 8
Scenario 9
Scenario
10
9.3
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)
Existing or New user - no European reporting
obligation
Middle Market onboarded through internet
No
No
No
No
No
Yes
No - reporting is
different, submission is
different
No
No
Yes
Yes
Middleware provider reporting data
Larger new user or user wants to report on
behalf of clients - full onboarding direct with
GTR Onboarding
Yes
Yes - search & download
only
Yes - but CSV upload
only
Yes - submission &
search & download
available
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é.
Guide French.docx6
Page 61 of 68
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
Guide French.docx6
Page 62 of 68
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 . .
Guide French.docx6
Page 63 of 68
•
•
•
•
• 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 reporting ‘
Notional Amount’
pour un lifecycle event, la valeur pourra toujours être la
resulting position
o Au-dessous vous trouvera un exemple:
UTI
Lifecycle Event
Notional Amount
Notional Currency
UTI123
UTI123
Trade
Increase
1,000,000.00
1,500,000.00
EUR
EUR
Notes
Increase was for 500,000.00, user reports
outstanding notional
10.2 Technical Guidance(Matériel Technique)
•
•
•
•
•
•
•
•
10.3
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.
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 .
Guide French.docx6
Page 64 of 68
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
Guide French.docx6
Page 65 of 68
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é.
Guide French.docx6
Page 66 of 68
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 audessus.Consultez le template pour s’assurer que tous les champs sont soumis.
GTR Field Name
Sample Value
Version
Message Type
Lite1.0
Position
Action
Transaction Type
New
Trade
UTI Prefix
UTI Value
Primary Asset Class
UTIPREFIX
TRANSACTID007
ForeignExchange
Product ID Prefix 1
Product ID Value 1
ISDA
ForeignExchange:Forward
Underlying Asset (repeatable up to 2
times semi-colon separated)
Notional Currency/Units (repeatable
up to 2 times semi-colon separated)
Settlement Currency (repeatable up
to 2 times semi-colon separated)
Price Notation - Price
Price Notation - Price Type
N/A for FX
EUR
0.8
1000;800
Effective Date (repeatable up to 2
Scheduled Termination Date
Date of Settlement (repeatable up to
2 times semi-colon separated)
Lifecycle Event
Guide French.docx6
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
C
2014-06-20T15:25:00Z
2014-06-24
2014-06-24
Une date applicable
Applicable pour les Non Deliverable Options et Non
Deliverable Forwards
New
Currency 2 (Foreign exchange only)
Exchange rate 1 (Foreign exchange
La première dévise devrait être saisie dans le champ
exchange rate quote basis (e.g. EUR/GBP)
Applicable seulement pour les Non Deliverable Forwards et
les Non Deliverable Options. Sinon on le laisse vide..
As per the best practice here
Rate
Notional Amount (repeatable up to 2
Delivery type
Execution Timestamp
Notes
GBP
0.8
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
Pour Forwards, le champ “Exchange rate 1 (Foreign
Page 67 of 68
only)
Forward exchange rate (Foreign
exchange only)
0.8
•
•
Trade Party 2
Notional Currency/Units
Notional Amount (repeatable up to 2 times semi-colon
separated)
•
Currency 2 (Foreign exchange only)
•
Leg/Currency 1 Payer
•
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
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.
Exchange rate basis (Foreign
exchange only)
EUR/GBP
Guide French.docx6
exchange only)” devrait être le même que celui de
“Forward exchange rate (Foreign exchange only)
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) suivra cette
succession logique
Page 68 of 68

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

Transcription

Documents pareils

PATCH CABANA SON`

Le PARTY De NOËL DU CASTEL 2e édition

bachelorette party

obtenir plus d`informations sur l`importation de véhicules

dj aklix ,votre dj eclectique

Sacoche ds lite blanche

Lush Strasbourg vous invite le 15 janvier de 10h à 19h à sa party

Sacoche ds lite rose

Fiche technique son

RÈGLEMENT DE LA LAN-PARTY DU 6 juin 2009 À BELMONT DE