Guı́a de usuario. DTCC GTR “OTC Lite”

DTCC Product Management Guía de usuario: GTR OTC Lite

Guía de usuario OTC Lite User Guide Spanish 0.6.docx6

Copyright © 2010-2013 by DTCC Deriv/SERV LLC Página 1 de 71

Guı́a de usuario. DTCC GTR “OTC Lite” Febrero 2014

ESMA (European Securities and Markets Authority) no ha aprobado ni sancionado la información contenida en este documento. Los requerimientos de la normativa EMIR que aquí se detallan representan la implementación propuesta por DTCC GTR para permitir a las empresas ajustarse y cumplir con dicha normativa. Los lectores no deben deducir los contenidos aprobados por ESMA a través de este documento. Este documento debe leerse conjuntamente con “Business Requirements for OTC Lite”.

https://dtcc.com/




1. Información General ........................................................................................................... 7

Introducción................................................................................................................ 7 1.1

GTR Document Portal ................................................................................................... 7 1.2

Información general. Global Processing ..........................................................................10 1.3

Envío de los archivos ............................................................................................10 1.3.1

Conectividad GTR........................................................................................................10 1.4

Acceso a la base de datos y Seguridad .....................................................................11 1.4.1

Recursos de GTR .........................................................................................................11 1.5

Recursos de Web GUI ...........................................................................................11 1.5.1

Secure FTP ..........................................................................................................13 1.5.2

Registro en GTR ..........................................................................................................13 1.6

2. Envío de acuerdos..............................................................................................................14

Proceso de envío GTR ..................................................................................................14 2.1

Mensajes de activos cruzados “OTC Lite”........................................................................16 2.2

La plantilla de mensaje “OTC Lite” ..........................................................................16 2.2.1

Informes Valuation y Collateral ..............................................................................17 2.2.2

Footer en CSV......................................................................................................17 2.2.1

Corte del servicio en el Batch de GTR .............................................................................18 2.3

Uso de los diferentes “Message” ...................................................................................18 2.4

Notificando un Nuevo Acuerdo ..............................................................................19 2.4.1

Notificando un Evento Posterior.............................................................................19 2.4.2

Notificando el cierre de un Acuerdo........................................................................20 2.4.3

Notificando un Evento LifeCycle ....................................................................................20 2.5

Corrigiendo Eventos LifeCycle ................................................................................20 2.5.1

La siguiente tabla muestra los eventos posteriores soportados por GTR.....................................21

Message Workflows ....................................................................................................23 2.6

DIAGRAMA 1 .......................................................................................................24 2.6.1

DIAGRAMA 2 .......................................................................................................25 2.6.2

DIAGRAMA 3 .......................................................................................................26 2.6.3

DIAGRAMA 4 .......................................................................................................27 2.6.4




DIAGRAMA 5 .......................................................................................................28 2.6.5

DIAGRAMA 6 .......................................................................................................29 2.6.6

3. Validación de los mensajes..................................................................................................30

Pasos de la Validación..................................................................................................30 3.1

Validación “Business” ..................................................................................................30 3.2

Validación “ESMA Regulatory” ......................................................................................30 3.3

Mensajes en respuesta ................................................................................................31 3.4

CSV-Batch Download Report (Hoja de cálculo descargable) ........................................31 3.4.1

End-of-Day Warning Report ..........................................................................................31 3.5

Generación del Warning Report .............................................................................32 3.5.1

4. Informes de ambas contrapartes..........................................................................................33

Introducción...............................................................................................................33 4.1

Identificando el modelo de envío ..................................................................................34 4.2

Reglas del modelo independiente...........................................................................34 4.2.1

Reglas del modelo de Delegación Completa .............................................................35 4.2.2

Matriz funcional del modelo Delegado ....................................................................36 4.2.3

5. Identificación del acuerdo ...................................................................................................37

Introducción del UTI y los principios aplicados por GTR para “OTC Lite” ..............................37 5.1

Flujo de trabajo del UTI ................................................................................................38 5.2

Bloqueo del UTI ..........................................................................................................38 5.3

Excepciones al bloqueo del UTI: .............................................................................39 5.3.1

6. Reconciliación Inter-TR .......................................................................................................40

Trade Pairing ..............................................................................................................40 6.1

Trade Matching ..........................................................................................................41 6.2

Campos y reglas ...................................................................................................41 6.2.1

7. Notificaciones a disposición de los participantes ....................................................................46

Descargando las notificaciones desde el Portal ................................................................47 7.1

Notificaciones disponibles para todas las clases de activos ................................................48 7.2

ACK/NACK...........................................................................................................48 7.2.1

Warning Report ...................................................................................................50 7.2.2




GTR ESMA OTC Position Report ..............................................................................52 7.2.3

GTR ESMA OTC Activity Report...............................................................................56 7.2.4

ESMA Match Status Report....................................................................................56 7.2.5

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

8. Apéndice A – Enlaces útiles .................................................................................................60

Trasfondo de Regulaciones ...........................................................................................60 8.1

Proyecto Final de Normas Técnicas de ESMA............................................................60 8.1.1

Extracto Final de Normas Técnicas de ESMA ............................................................60 8.1.2

Comparación entre EMIR y DFA..............................................................................60 8.1.3

Preguntas y Respuestas sobre ESMA .......................................................................60 8.1.4

Guía sobre Price Notation de ISDA ..........................................................................60 8.1.5

Business Requirements Document.................................................................................60 8.2

CSV Upload Template ..................................................................................................60 8.3

Vídeos y presentaciones de OTC Lite ..............................................................................61 8.4

Taxonomía de ISDA .....................................................................................................61 8.5

Guía Internacional de Transmisión de sFTP v1.0...............................................................61 8.6

Lista de contactos de OTC Lite.......................................................................................61 8.7

9. Apéndice B – Preguntas más frecuentes (FAQs) ......................................................................62

¿Cuál es el alcance geográfico y jurisdiccional de OTCLite? ................................................62 9.1

¿Quién es capaz de usar el servicio OTCLite? ...................................................................62 9.2

¿Es posible enviar múltiples archivos durante un día con una línea para cada uno de los 9.3acuerdo?..............................................................................................................................63

¿Cuáles campos opcionales necesitan estar rellenados? ...................................................64 9.4

¿Es necesario rellenar el campo ‘Trade Party 2’ si una parte envía informes de manera de 9.5delegación independiente?.....................................................................................................65

¿Cómo puedo enviar productos estructurados o exóticos?................................................65 9.6

¿Cuál es el horario de funcionamiento del sistema de DTCC?.............................................65 9.7

10. Apéndice C – Mejores prácticas para el envío de archivos.....................................................66

Guía de activos cruzados ..............................................................................................66 10.1

Guía técnica ...............................................................................................................67 10.2




Valid Values ...............................................................................................................67 10.3

Interest Rates .............................................................................................................68 10.4

Commodities ..............................................................................................................68 10.5

Foreign Exchange ........................................................................................................69 10.6

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

2013 Revisions New Screenshots

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

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

V0.51 March, 2014 Spanish version V0.61 May, 2014 Updated 1.5.1 Web GUI Entitlement

Updated 2.4 Message Usage Updated 3.3 ESMA Regulatory Validation Updated 4.2.3 Delegated Reporting Functionality Matrix Updated 5 Trade Identification Updated 5.2 Upstream Workflow Updated 7.2.2 Warning Report Updated 7.2.3 GTR ESMA OTC Position Report Updated 7.2.5 ESMA Match Status Report Updated 7.2.6 ESMA UTI Conflict or Pair Break Report Updated 8.7 Contact List for OTC Lite




1. Información General

Introducción 1.1

El Repositorio Global de Datos (Global Trade Repository, GTR) de activos cruzados de DTCC proporciona la infraestructura central necesaria relacionada con el procesamiento y depósito de derivados OTC. Clases de activos: Commodities, Credit, Equities, tipos de interés y FX y derivados negociados en bolsa notificables. TR acepta todos los acuerdos de cualquier entidad comercial (o de sus agentes) para todas las transacciones globales que son notificables a los reguladores. Para complementar el GTR ofreciendo el servicio “OTC Lite” habrá un servicio adicional de notificaciones que les permitirá a las empresas notificar sus transacciones de derivados OTC bajo el Reglamento sobre la infraestructura del mercado europeo (European Market Infrastructure Regulation: “EMIR”) al GTR. El servicio permite informar de posiciones, eventos comerciales y datos de valoración de cada posición y garantías. El servicio aborda una sola jurisdicción, debido a que es la única manera apropiada de notificar acuerdos a ESMA. Todas las transacciones de derivados OTC para todas las clases de activos pueden ser notificadas utilizando una única plantilla. Bajo EMIR, cada contraparte de la transacción se ve obligada a notificar el acuerdo, o una contraparte puede delegar la responsabilidad de notificar a la otra contraparte o a una Third Party. El servicio “OTC Lite” ofrece envíos independientes (notificar solo por una contraparte) o una delegación completa (notificar por las dos contrapartes). Eso se explicará más adelante en esta guía de usuario.

GTR Document Portal 1.2

Se puede encontrar más información en el portal GTR. En esta guía se podrá hacer referencia a dichos documentos. En el portal “GTR document” se pueden encontrar diversos documentos, de carácter técnico y comercial, diseñados específicamente para ayudar a los usuarios a entender los requisitos del sistema. GTR document se divide en siete secciones que se describen a continuación. http://dtcc.com/data-and-repository-services/global-trade-repository/gtr-europe/client-center.aspx Su Manager le facilitará los datos de acceso en el Portal.

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




La opción del menú desplegable “GTR Release Notes” detalla semanalmente los cambios de código que se han hecho y se harán en los entornos UAT y Producción. Adicionalmente, esta sección proporcionará información sobre el horario programado de los tiempos de parada del servicio.

La sección del menú desplegable “Product Training and Support” contiene documentos de descripción funcional, preguntas frecuentes de negocio y las mejores prácticas para el uso del servicio GTR. Esta sección se subdivide en las clases de activos y cada documento se clasifica según su categoría de activo.

“Business Requirement Documentation” contiene los documentos que describen los requisitos legales bajo el programa de GTR.

La sección “UAT Documentation” contiene documentos que se refieren a los UATs actuales en proceso.

En la sección “The Supported - Spreadsheet and Messaging Specs” se encuentran las plantillas y otros documentos técnicos que describen las funcionalidades del programa GTR soportadas actualmente en los entornos de UAT y de producción.

“The Future - Spreadsheet and Messaging Specs” contiene las plantillas y otros documentos técnicos que están en desarrollo y no están aún en los entornos UAT o producción. Los documentos en esta sección o están en desarrollo por los grupos de trabajo de DTCC o está prevista su migración al entorno UAT o de producción.

En la sección “The Global Repository On-Boarding” se encuentra la documentación necesaria para el proceso de onboarding.

La sección “Connectivity” contiene guías que describen los métodos disponibles para acceder a GTR.




Información general. Global Processing 1.3

El servicio “OTC Lite” se alojará únicamente en el centro de datos Europeo (“EUDC”). Esto significa que el protocolo sFTP y los envíos desde la página web necesitarán ser dirigidos a “EUDC” para su procesamiento. Las empresas pueden o bien realizar una conexión directa con EUDC o usar su conexión actual al centro de datos Estadounidense (USDC), con la excepción de que cada envío realizado vía sFTP será enlazado a EUDC, dependiendo del GTR “Product ID asignado”

El diagrama inferior muestra las diferentes opciones de conectividad para todo el entorno GTR. Debe tenerse en cuenta que los archivos .CSV recibidos vía sFTP usando “OTC Lite” únicamente seguirá la conectividad dedicada para EU.

Envío de los archivos 1.3.1

Cada uno de los envíos CSV a través de sFTP o desde la página web se englobarán dentro de GTR Product ID. CDTS recuperará el archivo del sistema y basándose en el ID del producto de GTR se enviará a EUDC para procesarlo.

Conectividad GTR 1.4

Los participantes del servicio “OTC Lite” pueden subir la información relativa a los acuerdos OTC a través de los siguientes medios:

• WEB GUI, usando el archivo en formato CSV (comma separated values) • sFTP, usando archivos en CSV




Acceso a la base de datos y Seguridad 1.4.1

El acceso a la base de datos europea es independiente y distinto de los demás. Utilizará una URL diferente. Para acceder a la plataforma los usuarios necesitaran un “Global login ID”. Es un ID separado y distinto de los WEB ID. Los usuarios que deseen acceder a Global URLs necesitarán un segundo Global Login ID además de su actual Web ID. Con los Web IDs actuales no es posible acceder a Global URLs, y de igual manera con el Global Login ID no es posible acceder al portal Estadounidense. Estos usuarios ya existentes necesitarán para acceder a la plataforma Europea un nuevo Global ID en sus cuentas de Super Access Coordinator (SAC).

Los usuarios SAC serán capaces de proporcionar nuevos Global Login ID para los usuarios. Los Global IDs tendrán el mismo formato que los Web ID.

1.4.1.1 Restricciones • SAC – La URL del portal estadounidense es la única forma de acceso para CRS. Las

funcionalidades de los nuevos y antiguos usuarios SAC, seguirán siendo gestionadas desde el enlace EE.UU.

• Global Login ID – No tiene los derechos de un SAC o AC, ya que ambas funcionalidades son únicamente accesibles desde la URL estadounidense.

• UAT – Los usuarios nuevos y antiguos tendrán que acceder desde el portal Europeo para acceder al entorno UAT.

Recursos de GTR 1.5

Recursos de Web GUI 1.5.1

Al sistema web de GTR se puede acceder a través del enlace del Portal del Cliente de DTCC. A todos los nuevos usuarios se les ha proporcionado los IDs y contraseñas para poder acceder al sistema GTR. Los portales regionales separados están disponibles a través de cada centro de datos para acceder al sistema web de GTR. Se requiere distintas identificaciones de acceso y contraseñas para acceder a cada uno de los portales.

Cada una de las identificaciones de acceso está asociada con un código de entidad de GTR/Grupo de participantes (O-Code): un código de cuatro caracteres utilizado para identificar la organización del usuario. El participante recibirá distintos O-Codes para diferentes servicios. Además, los “Position Report” están creados basándose en los distntos O-Codes; debido a eso, todas las entidades agrupadas bajo el mismo conjunto de O-Codes aparecerán en el mismo “Position Report”.

Los participantes actuales de DTCC serán capaces de utilizar sus datos de acceso y contraseñas ya existentes para acceder al sistema de envío y notificaciones de GTR; no obstante, cada uno de los participantes debería tener una de las funciones definidas más arriba para sus actuales IDs, junto con la asignación para su código de la entidad nueva/de grupo de participantes (O-Code).




Las empresas que usan el servicio proporcionado por DTCC tienen dos o más “access coordinators”, quienes pueden dar de alta a diversos usuarios (dentro de su empresa) a los productos de la web de DTCC. El sistema de GTR está configurado para permitir a cada “access coordinator” en una empresa asignar derechos de acceso a la página web GUI a los distintos usuarios que necesiten acceder a DTCC.

Las funciones de participantes y reguladores vienen definidas en el GTR.

1.5.1.1 Participantes • Los participantes son capaces de notificar a GTR enviando archivos en formato CSV por

su entidad autorizada a través del portlet de envíos. El portlet está disponible en el panel de GTR.

• Los participantes pueden ver el estado de sus archivos enviados gracias a las notificaciones que se pueden descargar como hojas de cálculo. Esto se aplica a los archivos CSV enviados a través de Web GUI o usando el protocolo sFTP (secure File Transfer Protocol). Solo los envíos a "OTC Lite" aparecerán en las notificaciones conocidas como ACK y NACK.

• Los participantes son capaces de ver los informes de aquellas entidades de las que han recibido autorización.

• Todos los acuerdos enviados al servicio “OTC Lite” al EUDC (Centro de datos europeo) serán incluidos en las notificaciones que reciben los participantes generadas en ese centro de datos.

1.5.1.2 Reguladores • Los reguladores son capaces de ver los archivos enviados al portlet. Los archivos están

disponibles según la clase de activos en el panel de GTR. • Los reguladores son capaces de ver los archivos basándose en la entidad autorizada, el

tipo de regulador y la configuración que poseen los reguladores en SDO. • Solamente los acuerdos designados como obligatorios de ser notificados serán incluidos

en las notificaciones respectivas de los reguladores. Por ejemplo, todas las transacciones abiertas en EUDC serán incluidas en las notificaciones para los participantes generadas en EUDC, pero solo aquellos acuerdos con la obligación de ser notificados a ESMA serán incluidos en las notificaciones de reguladores generadas en EUDC.

.




Secure FTP 1.5.2Los participantes que envían información de acuerdos a GTR tendrán la posibilidad de enviar los archivos CSV a través del protocolo sFTP. DTTC proveerá dicho recurso.

La manera de enviar vía sFTP es a través de DATATRAK y AutoRoute, que son subsistemas de gestión del envío y recibo de archivos propiedad de DTCC. Estos subsistemas facilitan a DTCC y a sus participantes automatizar el intercambio de archivos a través de la red de manera fiable y segura. DTCC apoya estos servicios a través de la red en propiedad SMART, tanto como a través de las redes SWIFT y BT Radianz.

Para más información sobre DATATRAK y AutoRoute visiten el Centro del Cliente de GTR (esbozado en el capítulo 1.2) y para obtener la documentación seleccionen “Connectivity” en el menú desplegable.

Registro en GTR 1.6

Las imágenes que aparecen a continuación muestran cómo entrar a OTC Lite

1. Hacer click en el siguiente enlace https://gtr.eu.dtcc.com 2. Aquí se les pedirá su user ID y la contraseña. Escriba su user ID y la contraseña y hagan

click en “Login”

3. Escojan OTC Lite en el menú del portal DTCC. Será similar al enlace que aparece a

continuación en el “Global Trade Repository”.

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




2. Envío de acuerdos

Proceso de envío GTR 2.1

Las imágenes que aparecen a continuación muestran cómo cargar manualmente los archivos CSV en el sistema.

1. Ir a la siguiente dirección: http://dtcc.com/data-and-repository-services/global-trade-repository/gtr-europe/clientcenter/client-center.aspx?gated=customers

Contactar con [email protected] para los datos de acceso.

2. Una vez se encuentre dentro del sistema, debe seleccionar “Supported - Spreadsheets and Messaging Specs.” Todas las plantillas del entorno de Producción están disponibles en “Supported - Spreadsheets and Messaging Specs”. Todas las plantillas del entorno UAT están disponibles en Future - Spreadsheets and Messaging Specs.

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

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

mailto:[email protected]




3. Haga click en la hoja de cálculo que quiera descargar (por ejemplo, OTC Lite Upload Spreadsheet)

4. Inicie sesión en el portal para acceder a OTC Lite. Seleccione “Participant” en la pestaña. Introduzca su Participant Code y después seleccione su O-Code

5. Un panel le mostrará una lista con los últimos envíos realizados a GTR, identificados por el Batch ID. Haga click en “Upload”.

6. Use las herramientas proporcionadas por su navegador para seleccionar la hoja de cálculo que quiera enviar a GTR. 7. Haga click en “Upload”




Mensajes de activos cruzados “OTC Lite” 2.2

Existen 3 tipos de mensajes soportados en “OTC Lite”, independientemente de la clase de activo.

Message Type Descripción

Position Se util iza para informar de la situación de una posición abierta. Tanto acuerdos nuevos, como modificaciones en acuerdos abiertos anteriormente. La metodología seguida es similar a la utilizada en el servicio principal de GTR, es decir “Snapshot”

Valuation* Usado para informar la actual valoración (market value) de la transacción. Esta valoración será enviada diariamente para los acuerdos pertinentes.

Collateral Valuation*

Usado para informar de carteras de garantías que pueden ser enlazadas con transacciones individuales

* Disponibles a partir del 11 de agosto del 2014

La plantilla de mensaje “OTC Lite” 2.2.1La plantilla utilizada para enviar la información está diseñada específicamente para permitir el pleno cumplimiento de los requisitos de EMIR, y por lo tanto contiene todos los campos que se especifican en EMIR RTS. Además de estos campos, existen una serie de campos de control que son utilizados para el correcto envió a GTR y procesamiento de los datos.

La plantilla tiene el formato CSV y contiene 28 campos de control (la mayoría de ellos son obligatorios) y 128 campos específicos de EMIR (incluyendo los campos relacionados con la contraparte para permitir los informes delegados). Cada tipo de mensaje soportado puede ser enviado en la misma plantilla. Los campos marcados como N/A y Optional pueden ser dejados en blanco (separados por comas en el formato csv) y GTR aceptará el mensaje.

Es importante señalar que es responsabilidad de los participantes asegurar que todos los campos requeridos específicamente por EMIR sean rellenados de forma precisa y completa. Existen muchos campos que para GTR son obligatorios, pero hay otros campos (la mayoría de carácter económico) que están catalogados como Opcionales en la plantilla. Las partes informantes tienen hasta el final de T+1 (UTC) para informar del acuerdo y registrar la operación en un “Trade Repository” bajo las directivas de EMIR. Sin embargo, puede existir la posibilidad de que algunos de los datos requeridos no estén disponibles. En este escenario, tan pronto como dicha información esté disponible, la entidad debe actualizar su acuerdo en GTR. Cada uno de los campos de EMIR indicados en la plantilla tienen que ser rellenados tan pronto como estén disponibles o sean aplicables.




Informes Valuation y Collateral 2.2.2Estos tipos de mensaje se encontrarán disponibles en 180 días desde la fecha de inicio de la producción. La descripción y los detalles de estos tipos de mensajes serán incluidos en una fase posterior de la aplicación.

Footer en CSV 2.2.1Cada archivo CSV debe contener un “footer message”. Este “footer” contiene información necesaria por GTR para procesar el archivo CSV apropiadamente. El cuadro que aparece a continuación muestra el formato adecuado que deberá incluirse en todos los envíos del archivo CSV. Existen también encabezados (“headers”) y otros valores adicionales que puede incluir en su envío, sin embargo el “footer” es siempre obligatorio A continuación se encuentra el formato del footer:

*OCOD-ENDnnnnnnnn Ejemplo: *DTC0-END00054321 GTR Footer (Trailer) Field

GTR Value N. de caracteres

Constant1 * (Es una constante) 1 Originator Esto es el “Originator ID” que consiste en 4 caracteres, asignado a

su cuenta durante el proceso de onboarding. En nuestro ejemplo, el O-Code que utilizamos es "DTC0".

4

Constant2 -END (Es una constante) 4 Record Count El número de las líneas incluidas en el archivo excluyendo la línea

del comentario. 00054321 es el número usado en el ejemplo

8

Ejemplo práctico: El Ejemplo a continuación consiste en 4 líneas con datos (la línea del comentario y la del footer se excluyen del número total de las líneas dentro de un archivo). Es importante notar que el footer es un único valor. *Comment Line ,Data,Data,Data,Data

,Data,Data,Data,Data



*DTC0-END00000004 A modo de ejemplo, cuando preparen su archivo tienen que seguir el siguiente formato.




DataTrak Header Application Header *Comment Line ,Data,Data,Data,Data ,Data,Data,Data,Data ,Data,Data,Data,Data ,Data,Data,Data,Data *DTC0-END00000004 DataTrak Trailer

Corte del servicio en el Batch de GTR 2.3

Los acuerdos enviados bajo los requisitos de EMIR tienen que ser enviados al repositorio a más tardar T+1 (el día de la transacción + 24 horas) después de la firma del acuerdo, la modificación o la terminación de la transacción. Independientemente de la clase de activo, la hora límite para enviar el archivo al Centro de Datos Europeo (EUDC) es a las 23:45 del Tiempo Universal Coordinado (UTC). Cada semana se generarán diferentes “batchs” y están programados de la siguiente forma.

Día Hábil Hora límite de envío Comienzo de Batch en el EUDC Lunes 23:45 UTC Lunes 00:00 UTC Martes

Martes 23:45 UTC Martes 00:00 UTC Miércoles Miércoles 23:45 UTC Miércoles 00:00 UTC Jueves

Jueves 23:45 UTC Jueves 00:00 UTC Viernes Viernes 23:45 UTC Viernes 00:00 UTC Sábado

Uso de los diferentes “Message” 2.4

Esta sección muestra como notificar un acuerdo nuevo, un evento posterior en el acuerdo y la terminación (“Exit”) de la transacción. La columna “Trade Event” se refiere a los diversos cambios que ha sufrido el acuerdo. Las columnas “Message Type”, “Action”, “Transaction Type” y “Lifecycle Event” se refieren a los campos que necesitará rellenar en la plantilla. “ESMA ACTION” identifica como el mensaje será notificado a ESMA.

La plantilla OTC Lite puede usarse para notificar a ESMA Commodities, Credit, Equities, tipos de interés y FX. Las tablas que aparecen a continuación son aplicables a todo tipo de activos, a no ser que se indique lo contrario.




El valor “PositionCancel” en el campo “Transaction type” siempre será notificado como “Error” a ESMA

Asset Class Message Type Action Transaction Type

Lifecycle Event

ESMA Action

Todos Cualquiera* New PositionCancel N/A Error *”Cualquiera” se refiere a cualquier “message type” o “transaction type” donde se aplica el “Cancel”

Notificando un Nuevo Acuerdo 2.4.1Las combinaciones de “message type”, “activity type” y “transaction type” que se muestran a continuación se pueden usar para notificar un acuerdo nuevo.

Trade Event* Message Type

Action Transaction Type** Lifecycle Event ESMA Action

New Trade Position New Trade Trade or New New Backload Position

New Backload or Trade N/A or

Backload New

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

Position New Trade Novation-Trade

New

*Los acuerdos bloqueados asignados, compensados o los no-asignados, serán notificados bajo “New Trade” **Los usuarios tienen a su disposición diferentes tipos de transacciones, y tendrán que decidir cuál es la más apropiada dependiendo de sus necesidades

Notificando un Evento Posterior 2.4.2Las combinaciones de “message type”, “activity type” y “transaction type” que se muestran a continuación se pueden usar para notificar un evento posterior en el acuerdo

Trade Event Message Type

Action Transaction Type

Lifecycle Event ESMA Action

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

Position New Trade PartialTermination Cancel

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

Position New Trade Compression Compression

Succession (Credit only) Position New Trade CreditEvent New Credit Event (Credit only) Position New Trade CreditEvent New Partial Exercise (FX only) Position New Trade PartialExercise Cancel Exercise Position New Trade Exercise Cancel Corporate Action Position New Trade CorporateAction New *Los acuerdos nuevos como consecuencia de una compresión deberían siempre estar marcados en el campo “Compression” con el valor “true”




Notificando el cierre de un Acuerdo 2.4.3Las combinaciones de “message type”, “activity type” y “transaction type” que se muestran a continuación se pueden usar para cerrar un acuerdo existente.

Trade Event Message Type

Action Transaction Type

Lifecycle Event ESMA Action

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

Position New Exit Compression Compression

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

Position New Exit or Trade Partial Exercise Cancel

Exit Position New Exit Exit Cancel Position Cancel Position New PositionCancel N/A Error Hay que tener en cuenta que “PositionCancel” eliminará toda la posición como si el acuerdo nunca hubiera existido. El “UTI” (Unique trade identifier) puede ser reutilizado si no está bloqueado por algún otro envío de la contraparte. El mensaje “Exit” se utiliza cuando la posición está cerrada (no hay necesidad de enviar un mensaje “Exit” cuando un acuerdo vence). Además, cuando sucede un evento que causa la terminación del acuerdo, será suficiente subir un mensaje “Exit” para cumplir con las necesidades de ESMA

Notificando un Evento LifeCycle 2.5

En el caso de los acuerdos bajo la normativa EMIR también es necesario informar no solamente del estado final del acuerdo al final del día, sino también de todos los eventos que le han ocurrido al acuerdo durante el período de tiempo que ha pasado desde el último informe, incluidas las razones de estos cambios. Esto se puede lograr enviando toda la serie de posiciones del acuerdo cada vez que haya habido una modificación.

Corrigiendo Eventos LifeCycle 2.5.1Dependiendo del tipo de producto en OTC Lite, puede haber diferentes eventos “LifeCycle”. Puede ocurrir que una de las partes envíe un evento LifeCycle de forma errónea. La tabla que aparece a continuación muestra como corregir un evento LifeCycle que se ha notificado de forma incorrecta. Primer conjunto de archivos enviados a GTR File No.

Event Lifecycle Event Field

Trade Amount

Notional As of Date Time Comment

1 New Purchase Trade 10M 10M 01-May-2014 T09:00 Creando la posición 1 Partial Unwind Termination 2M 8M 01-May-2014 T14:00 Terminación 1 2 Partial Unwind Termination 2M 6M 02-May-2014 T10:00 Terminación 2 3 Partial Unwind Termination 2M 4M 03-May-2014 T10:02 Terminación 3




“Termination 1” en el archivo 1 necesita ser cancelado: File No.

Event Lifecycle Event Field

Trade Amount

Notional As of Date Time Comment

4 Error 8M 01-May-2014 T14:00 Esto informa a DTCC que el “1st partial unwind” debería ser eliminado

5 Modify 8M 02-May-2014 T10:00 Reajustar “notional” otra vez a 8 millones porque el “1st partial unwind” se ha eliminado

6 Modify 6M 03-May-2014 T10:02 Reajustar “notional” otra vez a 6 millones porque el “1st partial unwind” se ha eliminado

7 6M Current Time Para asegurar que la última posición es actualizada.

La siguiente tabla muestra los eventos posteriores soportados por GTR. Business Event Lifecycle Event

New Trade Trade New

Amendment Amendment Backload Backload

Termination resulting from compression

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

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

Increase Increase Amendment (Rates)

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

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

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

Termination Full~ PartialTermination (Credit) Termination

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

Valuation Update N/A

Global Cancel (Withdrawing the trade) Cancel Error

Exit or AutoExit Exit




Corporate Action CorporateAction (Equity) Fee Amendment Amendment

Credit Event Termination Exit

Modify Cancel Error




Message Workflows 2.6

El “Message Type” que vamos a describir a continuación se basa en las siguientes hipótesis:

• Ambas contrapartes están obligadas a notificar bajo la normativa EMIR. Habrá diferencias en el flujo de trabajo en el caso de que una de las partes no tenga obligación de notificar o una tenga obligación con otra jurisdicción.

• Cuando un acuerdo se ejecuta, el sistema generará un UTI y avisará a ambas contrapartes.

• Cuando un acuerdo es confirmado usando una plataforma intermedia, esta plataforma generará una UTI y avisará a ambas contrapartes, o arbitrará entre las contrapartes y notificará el UTI acordado.

• Cuando en un acuerdo se utiliza una Cámara de Compensación, dicha Cámara generará dos nuevos acuerdos novados, informando de estos acuerdos bajo dos UTI diferentes pero unidas con los acuerdos bilaterales originales a través del campo anterior de la UTI.

• Cuando se acuerda que la transacción se compense en la cámara antes de su ejecución, la Cámara de Compensación generará y notificará dos UTIs diferentes.

• Para enviar un acuerdo en el sistema “OTC Lite”, será siempre requerido un código “UTI”. Si el UTI necesita ser modificado o corregido, entonces la posición existente necesita ser cerrada (“Exit”) y una nueva posición deberá ser enviada (indicando en el campo correspondiente el UTI anterior que fue cerrado)

• Varias compañías (como por ejemplo Cámaras de Compensación y otras) serán capaces de notificar en nombre de otra entidad, pero necesitarán tener acceso/permiso para hacerlo.

• Cuando solo están involucradas Party A y Party B, la parte que envía los datos será la única que recibirá las notificaciones ACK. Esta entidad será la única que recibirá los ACKs independiente del rol que tiene en el acuerdo.

• Si las dos contrapartes son participantes en GTR, ambas recibirán los “EOD Reports” (notificaciones generadas al final del día). En el caso de que nuestra contraparte nos haya nombrado en sus informes, en esta notificación aparecerán dichos UTIs (aplicable solo para acuerdos OTC en GTR)

Bi-lateral On-facility

Non-cleared Cleared Non-cleared Cleared

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




DIAGRAMA 1 2.6.1Ejecución bilateral; uti lizando un intermediario; sin compensación; ambas partes notifican (no delegado)

Importante notar que la plantilla solo admite el formato CSV y si un proveedor intermediario acuerda enviar por una o ambas contrapartes entonces dicho proveedor deberá cumplir con los métodos descritos en este documento. Flujo de pasos:

1. Transacción bilateral acordada entre Party A y Party B 2. Las entidades envían el acuerdo a la plataforma del intermediario. 3. La parte intermediaria genera un UTI y confirma dicho UTI

con las contrapartes. 4. Party A envía un mensaje de posición a GTR en su propio nombre. 5. Party B envía un mensaje de posición a GTR en su propio nombre. 6. GTR envía un ACK a Party A y Party B respectivamente. 7. Party A envía un mensaje de “Valuation” 8. GTR sends an ACK to Party A 9. Party A envía un mensaje de “Collateral” 10. GTR devuelve un ACK a Party A 11. Party B envía un mensaje de “Valuation” 12. GTR devuelve un ACK a Party B 13. Party B envía in mensaje de “Collateral” 14. GTR devuelve un ACK back a Party B

En el ejemplo mostrado, si el intermediario envía el archivo CSV entonces puede enviar un mensaje de posición para ambas contrapartes en los pasos 4 y 5 (y el intermediario recibirá las notificaciones ACK en vez de Party A y Party B en desde el paso 6)

1 Party A

Party B

Intermediario

2,3 2,3

TR

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




DIAGRAMA 2 2.6.2 Ejecución bilateral; uti lizando un intermediario; sin compensación; Party A informa a ESMA en nombre de ambas entidades (delegación completa)

Flujo de pasos: 1. Transacción bilateral acordada entre Party A y Party B. 2. Las entidades envían el acuerdo a la plataforma del intermediario. 3. El intermediario genera el UTI y lo relaciona el acuerdo con dicho UTI. 4. Party A envía un mensaje de posición a TR en nombre de ambas entidades 5. GTR devuelve un ACK a Party A 6. Las entidades acuerdan modificar el contrato el mismo día 7. Las entidades envían las modificaciones al intermediario 8. Party A envía un mensaje de “Posición” con la modificación incluida a GTR 9. GTR devuelve un ACK a Party A 10. Party A envía un mensaje de “Valuation” 11. GTR devuelve un ACK a Party A 12. Party A envía un mensaje de “Collateral” 13. GTR devuelve un ACK a Party A 14. Party B envía un mensaje de “Valuation” 15. GTR devuelve un ACK back a Party B 16. Party B envía in mensaje de “Collateral” 17. GTR devuelve un ACK back a Party B

Party A

Party B

Intermediario

2,3 2,3

TR

15,17

4,8,10,12 14,16

6

7 7 5,9,11,13

1




DIAGRAMA 3 2.6.3Acuerdo bilateral; confirmación de documentos; sin compensación; Party A informa a ESMA en nombre de ambas entidades (delegación completa) Flujo de pasos:

1. Transacción bilateral acordada entre Party A y Party B. 2. Party A envía un mensaje de “Posición” a GTR, incluyendo los datos comunes y los específicos de las contrapartes en nombre de ambas

entidades 3. GTR devuelve un ACK a party A 4. Party A envía un mensaje de “Posición” intra-día reinformando de las posiciones abiertas incluyendo de las valoraciones 5. GTR devuelve un ACK a Party A 6. Party A envía un mensaje de “Collateral” y “Valluation” a GTR 7. GTR devuelve un ACK a Party A

Party A

Party B

1

TR

2, 4, 6

3, 5, 7




DIAGRAMA 4 2.6.4On-Facility execution; sin compensación; ambas entidades informan de forma independiente) Flujo de pasos:

1. La transacción se ha cruzado en el sistema y es enviada a las entidades A y B. 2. La plataforma de ejecución genera las UTIs y son enviadas a las entidades A y B. 3. Party A envía un mensaje de de “Posición” a TR (Trade Repository) en su nombre. 4. GTR devuelve un ACK a Party A 5. Party B envía un mensaje de “Posición” a TR en su nombre. 6. GTR devuelve un ACK a Party B 7. Party A envía un mensaje de “Valuation” y “Collateral”. 8. Party B envía un mensaje de “Valuation” y “Collateral”.

Party A

La plataforma de ejecución

TR

Party B

1, 2 1, 2

3, 4, 7 5, 6, 8




DIAGRAMA 5 2.6.5On-Facility execution; sin compensación; una entidad informa de todos los datos (delegación completa) Flujo de pasos:

1. La transacción se ha cruzado en el sistema de la plataforma de ejecución y es enviada a las entidades A y B. 2. La plataforma de ejecución genera las UTIs y son enviadas a las entidades A y B. 3. Party A envía un mensaje de de “Posición” a TR en nombre de ambas entidades. 4. GTR devuelve un ACK a Party A 5. Party A envía un mensaje de “Valuation” y “Collateral”. 6. Party B envía un mensaje de “Valuation” y “Collateral”.

Party A La plataforma de

ejecución

TR

Party B

1, 2 1, 2

3, 4, 5 6




DIAGRAMA 6 2.6.6On-Facility execution; compensado; ambas entidades informan (independiente);

la Cámara de Compensación informa de los acuerdos novados Flujo de pasos:

1. El acuerdo se cruza en el sistema de la plataforma de ejecución y es enviado a ambas compañías, con el UTI que se ha generado.

2. Party A y Party B confirman el acuerdo con el intermediario. 3. El intermediario reconoce el acuerdo y devuelve el UTI generado a ambas entidades. 4. Party A envía un mensaje de “Posición” a TR en su nombre. 5. Party B envía un mensaje de “Posición” a TR en su nombre. 6. El intermediario envía el acuerdo a la Cámara de Compensación 7. La Cámara de Compensación nova el acuerdo bilateral en dos transacciones, siendo enfrentadas

ambas posiciones en la Cámara con dos UTIs diferentes. 8. La Cámara reconoce dos nuevos acuerdos con el intermediario. 9. La Cámara envía un mensaje de “Posicion” para los dos nuevos acuerdos a TR, incluyendo la

referencia al anterior UTI (X) 10. Party A envía un mensaje de “Posición” para cerrar la posición del acuerdo original X 11. Party B envía un mensaje de “Posición” para cerrar la posición del acuerdo original X




3. Validación de los mensajes Cada mensaje enviado a GTR es sometido a un proceso de validación. Este proceso se tratará a fondo en el siguiente capitulo.

No superar cualquiera de estos controles resultará en un mensaje de confirmación negativa (negative acknowledgment, NACK) y el envío será devuelto a la empresa. El cumplimiento de todos los controles resultará en una confirmación positiva (acknowledgment, ACK), también enviado a la compañía.

Pasos de la Validación 3.1

Validación “Business” 3.2

El alcance de “Business Validation” abarcará

• Campos de control de GTR • Otros campos jurisdiccionales mandatorios. Es decir, campos que se requieren para jurisdicción

regulatoria que no son campos de control de GTR

El incumplimiento de cualquier paso resultará en el rechazo del envío y será generado un NACK.

Validación “ESMA Regulatory” 3.3

Si el informe ha cumplido con Schema Syntax Validation, con “GTR Core Validation” y con “Business Validation”, este será aceptado por GTR. El envío se validará para la jurisdicción mencionada según los campos “Reporting Obligation Party 1” y “Reporting Obligation Party 2”.

Validación Schema Syntax Validación GTR Core Validación GTR

Business

¿Es un CSV válido? ¿Los campos tienen el

formato correcto?

Autorizaciones, UTI lock, transaction & action type

consistency validation.

Ejemplo. ¿post-trade CCY = the position CCY?




El incumplimiento del informe con la normativa legislada por los reguladores, tendrá como resultado un Warning Report, que recibirán los distintos participantes. Hay que acentuar que el informe puede ser aceptado por GTR aunque un campo requerido por los regulares no haya sido rellenado. La razón de este hecho se basa en que no todos los campos requeridos por EMIR son obligatorios dependiendo del método (independiente o delegada), o simplemente que ciertos campos no corresponden con el producto que se está notificando.

Los participantes tienen que revisar sus Warning reports y enviar el informe con todos los datos pertinentes para garantizar que el informe cumple con los requisitos de ESMA (el Warning Report se proporciona con el resto de notificaciones al final del día).

Mensajes en respuesta 3.4

Las notificaciones ACK y NACK se generarán en tiempo real después del envío del archivo CSV.

CSV-Batch Download Report (Hoja de cálculo descargable) 3.4.1Cada envío de un archivo CSV a través de Web GUI o sFTP generará una notificación ACK y una NACK (en forma de hoja de cálculo descargable) que incluirán todos aquellos envíos correctamente procesados, y todos aquellos rechazados. Estas notificaciones están disponibles de forma automática en la página personal del participante.

Submission Status Descripción

ACCEPT Este estado indica que las validaciones de GTR Core, GTR business así como todos los campos requeridos han sido superadas, indicando que el envío ha sido validado, verificado y ha sido aceptado en el sistema GTR.

REJECT Este estado indica que las validaciones de GTR Core y GTR business no han sido superadas, indicando que el envío no ha cumplido con los requisitos mínimos y ha sido rechaza por el sistema GTR.

End-of-Day Warning Report 3.5

La notificación EOD (al final del día) “Warning Report” contiene advertencias sobre las transacciones, avisando de aquellos posibles fallos relacionados con el cumplimiento jurisdiccional de ESMA. Sobre el mensaje de “Posición” se examinarán diferentes campos de la plantilla para comprobar el cumplimiento de la normativa.

El Warning Report solo se generará aquellos días en los que se envía un acuerdo a GTR utilizando un mensaje de “Position”, bien sea una nueva transacción o una modificación de una posición abierta anteriormente.




Los avisos que aparecen en esta notificación se generarán por cada uno de los campos requeridos por ESMA que se encuentren en blanco. Hay campos que son opcionales para GTR pero obligatorios según la normativa de ESMA. Es una responsabilidad de las entidades asegurarse que cumplen completamente con las obligaciones de información de ESMA.

Generación del Warning Report 3.5.1• Se genera una vez al día. El batch de la base de datos Europea empieza a las 00:00 UTC.

• El sistema comprobará si ha habido cambios en las posiciones, y aparecerán en los

Warning Reports del día siguiente

• Esta notificación solo contendrá avisos de las posiciones abiertas el día anterior

• No contiene avisos de aquellas posiciones que han sido corregidas durante el día

• El portal de GTR muestra los Warning Reports de los últimos 7 días.

Para ver el formato del Warning Report se puede consultar la sección “Participant Report” que aparece a continuación de este documento.




4. Informes de ambas contrapartes

Introducción 4.1

IMPORTANTE: EN CASO DE REALIZAR ENVÍOS EN NOMBRE PROPIO O DE LAS DOS ENTIDADES, TODAS LAS ACTUALIZACIONES Y MENSAJES POSTERIORES TIENEN QUE SER REALIZADOS CON EL MISMO UTI, Y EL MISMO SERVICIO (“OTC Lite” o “OTC Core”). GTR no puede procesar los UTIs que han enviado parcialmente a un servicio. Por ejemplo, si un intermediario usa “OTC Core” para enviar el informe en nombre de Party A y la Party A es un usuario de “OTC Lite”, el informe no será aceptado por OTC Lite.

La infraestructura actual de GTR soporta el envío de los datos de acuerdos tanto en nombre de las dos partes de la transacción o de forma directa, a través de una delegación completa o vía proveedores de servicio autorizados (Third Party). Los envíos se pueden realizar de forma independiente por ambas partes de la transacción o a través de una plataforma central, tanto como a través de una tercera parte que provee el servicio de confirmación (siempre que sea en un archivo en formato CSV cómo se ha descrito más arriba).

Bajo las normativas de ESMA, las dos contrapartes de cualquier transacción que aparece descrita en dicha normativa, tienen la obligación de notificarla. Además, los estándares técnicos de ESMA distinguen claramente entre los datos comunes (Common data) y los datos de la contraparte (Counterparty data):

• Datos de las contrapartes: los detalles relacionados con las contrapartes de un acuerdo (Anexo Tabla 1 del documento de ESMA Technical Standards)

• Datos comunes: los detalles relativos al contrato de derivados realizado entre dos contrapartes (Anexo Tabla 2 del documento ESMA Technical Standards)

De esta distinción entre los datos, junto con la obligación de las contrapartes de notificar un acuerdo surgen los escenarios de notificaciones y los modelos de delegación siguientes:

• Las dos contrapartes pueden independientemente hacer notificaciones tanto de los datos comunes como de los de las contrapartes.

• Una parte puede notificar los datos comunes y los de ambas contrapartes en nombre de las dos (el modelo de la delegación completa).

o Bajo este modelo es también posible que la otra contraparte proporcione los datos de su contraparte a través del envió de un informe independiente usando el mensaje “Position” (nótese que se requiere un mensaje “Position” completo. El último mensaje “Position” enviado tendrá prioridad en este lado del UTI)

• Una o ambas contrapartes pueden delegar la responsabilidad de notificar a una o más Third Parties

• En caso de transacciones compensadas por una cámara, las contrapartes pueden delegar la obligación de notificar a la Cámara de Compensación




• En todos los casos las contrapartes/cámaras de compensación quedan responsables por garantizar que los acuerdos están notificados sin duplicación a un Repositorio de datos registrado

Han sido añadidos diversos campos a la plantilla para adaptarla a dichos procedimientos de notificación.

Nótese que si una contraparte (Party A) envía el informe a OTC Core bajo el modelo de delegación completa y la otra parte (Party B) envía el informe independientemente a OTC Lite usando el mismo UTI, se creará un duplicado a las autoridades reguladoras, perjudicando a la veracidad de la información que los reguladores poseen.

Identificando el modelo de envío 4.2

Los Campos obligatorios “Submitted For Prefix” y “Submitted For Value” indicarán si el informe es enviado en nombre de la empresa, en el nombre de su contraparte o por ambas. El campo “Reporting Delegation Model” se ha añadido para identificar el modelo de informe de cada acuerdo. Este campo no es obligatorio pero se ha incluido para un posible uso futuro. La forma de procesar el archivo se basará en los valores de los campos “Submitted For Prefix” y “Submitted For Value”.

• Si usted envía el informe solo en su nombre, este campo tiene que estar rellenado con el valor “Independent”.

• Si usted envía el informe en nombre de ambas partes, este campo tiene que estar rellenado con el valor “Full”.

En el caso de Informe Delegado, GTR se asegurará de que la parte que envía los informes tiene los permisos necesarios para informar en el nombre de ambas.

Reglas del modelo independiente 4.2.1Los campos “Submitted For Prefix” y “Submitted For Value” identifican que el envío se realiza en nombre de la entidad que está enviando el informe, es decir, “Party 1” en el acuerdo. Este envío se considera como un informe independiente. En este escenario:

• GTR recogerá solamente los datos de la contraparte y los datos comunes de la Party 1 del acuerdo.

• El campo “Reporting Delegation Model” debe contener el valor “Independent” o estar en blanco. Solamente se requerirán los datos necesarios para identificar quién es su contraparte, el resto de los datos de la Party 2 en el envío se ignorarán. Sin embargo, los datos de la Party 1 serán procesados. En este caso la otra entidad tendrá que enviar su informe de forma independiente (si está bajo la obligación de EMIR). Este informe se puede enviar tanto a GTR como a cualquier otro repositorio.




Reglas del modelo de Delegación Completa 4.2.2Party 1 (o la Third Party a quien han delegado la responsabilidad de informar) enviará todos los datos comunes así como los datos específicos de Party 1 y los datos de la contraparte (Party 2). Importante notar que bajo el modelo de “Delegación completa”, la entidad que envía la información puede también subir mensajes de “Valuation” y “Collateral” en su nombre, o en nombre de ambas entidades. De la misma forma cada compañía podrá enviar sus propios mensajes de “Valuation” y “Collateral”.

Si el campo “Submitted For Value” identifica que el informe se realiza en nombre de ambas partes, los valores esperados en la plantilla son los pertenecientes a Party 1, Party 2 y datos comunes. Bajo este escenario:

• El campo “Reporting Delegation Model” debe contener el valor “full” o ser dejado en blanco. • Si algunos, o todos los datos de la Party 2 no están completados, el archivo será procesado y

será enviado a GTR, pero en el Warning Report se detallarán todos los campos requeridos bajo la normativa EMIR que faltan en el informe. El Warning Report estará disponible para todos los participantes del acuerdo, siempre que se encuentren en la posición de “OnBoarded” en GTR.

• Si una entidad quiere actualizar por su cuenta el informe (en este posible escenario se añadiría información adicional de una contraparte), entonces esa entidad necesitará subir un mensaje de “Position” por ella misma (indicando este hecho en el campo “Submitted For Value”), debiendo cumplir dicho mensaje de “Posición” todos los procesos de validación correspondientes.

o Como se menciona anteriormente, es importante señalar que todos los datos pertenecientes a las contrapartes, así como todos los datos comunes, deben ser rellenados por esa entidad, de forma que el UTI de su lado de la operación quede registrado de forma apropiada en GTR. Todos los campos comunes que no sean rellenados en el envío, pero hayan sido proporcionados en un informe anterior, pasarán a estar en blanco en GTR.

La tabla que aparece a continuación detalla las reglas básicas:

Escenario Submitted By

Submitted For

Delegation Model

Common Trade Party 1 fields

Trade Party 2 fields

Independent Reporting

Bank A Bank A Independent Y Y N


Client B Client B Independent Y Y N

Independent Reporting 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

Full Delegation Third Party Both Full Y Y Y

Se procesará solo información proveniente de la Cámara de Compensación, otra información no será procesada aunque sea enviada.




4.2.2.1 Limitaciones de los envíos El envío de una concatenación de posiciones finales, así como los diferentes eventos “Life-Cycle” o las diferentes notificaciones que aparecen al final del día bajo el modelo de delegación completa (en nombre de ambas entidades) sobrescribirán las posiciones causando que los datos de la Party 2 desaparezcan del envío original, siendo eliminados. Una vez que la transacción correspondiente al lado Party 2 esté incompleta para EMIR, en el WARNING REPORT aparecerán las correspondientes advertencias, avisando de este hecho.

Matriz funcional del modelo Delegado 4.2.3La tabla que aparece a continuación muestra algunos ejemplos cómo los informes pueden ser enviados. La matriz supone que la contraparte 2 no tiene el permiso de enviar los informes delegados y solamente puede actualizar sus propios datos.

OTC Lite

Scenario Resp. per party Common CP1 CP2

1 Independent Reporting

Ctpy 1 X

Cpty 2 X

2 Full Delegation Ctpy 1

Cpty 2 X X X

El signo X en el cuadro rojo significa que GTR no permite enviar este informe bajo este escenario.




5. Identificación del acuerdo La capacidad de identificar los acuerdos particulares utilizando el “Unique Trade Identifier” (UTI) es un componente clave de la normativa EMIR. Todos los participantes de la transacción, incluidas las cámaras de compensación en el caso de un acuerdo compensado, son responsables de garantizar que todos los contratos serán notificados a un repositorio de datos registrado sin duplicación. Esto significa que las dos partes del acuerdo y también sus agentes tienen que notificar el acuerdo usando un UTI único acordado entre todos ellos.

Los criterios técnicos de la normativa EMIR no especifican ninguna regla para la creación del “UTI” excepto que debería contener un máximo de 52 caracteres. GTR acepta cualquier carácter alfanumérico y los siguientes signos especiales: `~!@#$%^&*()_-+=|\;:./ .

Introducción del UTI y los principios aplicados por GTR para “OTC Lite” 5.1

GTR facilitará la vinculación de los acuerdos y posiciones aplicando el siguiente planteamiento:

1. El “UTI” será universal sin una estructura obligatoria. El formato estará limitado a máximo 52 caracteres incluyendo los caracteres especiales mencionados arriba (-ver plantilla- y aunque dicha plantilla soporta un “UTI Prefix” de 40 caracteres y un “UTI Value” de 200 caracteres, el formato definido por ESMA deberá ser respetado en orden de cumplir la normativa actual).

a. Si la combinación de los valores “UTI Prefix” y “UTI Value” superará los 52 caracteres, se generará una advertencia en el “Warning report”.

2. Después de acordar el “UTI”, las contrapartes deberán enviar dicho UTI a GTR.

3. Después de que el UTI es asignado a una posición, este valor no puede ser cambiado a posteriori.

4. Una vez el UTI esté asignado, debe ser usado para cualquier referencia posterior a dicho acuerdo.

5. Si es necesario corregir o modificar el UTI, se deberá cerrar la posición (usando “Exit” o “PositionCancel”) y reenviar el archivo con el UTI correcto (ya que el UTI actual no se puede modificar en una posición abierta anteriormente). La mejor práctica es usar “Exit” a la posición anterior y enviar el nuevo UTI como una nueva posición en un nuevo “Position message” (indicando el UTI anterior en el campo “Prior UTI Value”).

6. El valor único del UTI se garantizará gracias a la combinación de los valores “UTI Prefix” y “UTI Value”.




Flujo de trabajo del UTI 5.2

Este documento define los procedimientos específicos necesarios para ayudar a cumplir con las normativas de EMIR a través del paradigma actual de GTR del envío único (“enviar una vez, notificar más acuerdos”). Las mejores prácticas de cómo generar e intercambiar el UTI no están incluidas en esta Guía de usuario. El flujo de trabajo necesario para componer y enviar los datos a GTR no es el objetivo de este documento, pero los principios fundamentales relacionados con el flujo de trabajo en los UTIs son complementarios a los principios de identificación de acuerdos en GTR mencionados más arriba y vienen incluidos aquí como referencia:

1. Siempre que sea posible, las contrapartes de un acuerdo intercambiarán un UTI a través de GTR. Cuando las dos partes notifican su lado del acuerdo, el UTI deberá ser idéntico.

Antes de que se implemente una solución plenamente flexible, puede ser necesario imponer las reglas preliminares siguientes:

1. Si se conoce el UTI, este valor tiene que formar parte del envío a GTR. En caso contrario, se tendrá que proporcionar un UTI provisional y corregirlo por el procedimiento adecuado una vez que el UTI sea conocido.

2. Si se cambia el UTI posteriormente, hay que cerrar el acuerdo (“Exit”) y reenviar el informe con el UTI acordado en GTR

a. Cuando no es posible acordar un UTI antes de notificar el acuerdo, se puede utilizar un UTI provisional. En cuanto el UTI final está acordado, es necesario cerrar la posición y enviarla de nuevo con el “Prior UTI” mencionado, indicando en este campo el valor del UTI provisional originariamente enviado.

3. El UTI tiene que ser idéntico por las dos contrapartes del acuerdo y por la clase de activo. Si se envía posteriormente el mismo UTI para una “Primary Asset Class” distinta con la misma contraparte, el informe será rechazado.

Bloqueo del UTI 5.3

1. Cuando el primer envío “New” está hecho con el UTI (‘Position’ o ‘Valuation’), el sistema realizará las siguientes comprobaciones. Las reglas más abajo se aplican a la situación cuando las dos partes del acuerdo tienen los IDs de participantes CONOCIDOS en el sistema de GTR.

a. El sistema revisará si el UTI enviado es único dentro del servicio de “OTC Lite”. Si el UTI todavía NO ESTÁ presente en el servicio, el sistema aceptará el UTI como válido. Una vez aceptado el UTI, el Repositorio de datos asignará el UTI a la Parte, Contraparte, Message Type y Asset Class

b. En los envíos posteriores para el mismo UTI no es posible modificar el ID de la Parte y la clase de activos (Asset Class). El sistema no permitirá la modificación del ID de la contraparte hasta cuando se reciba el informe de la contraparte




2. Una vez sea aplicado el bloqueo (LOCK), incluso en casos que la Parte/Contraparte anula (“Cancel”) o cierra (“Exit”) envíos anteriores del UTI ya registrado y envía informes nuevos (“New”) para el mismo UTI con el mismo ID de la Contraparte, el sistema rechazará el envío, declarando ‘Invalid Submission – UTI exists for another Party/Counterparty’ (Envío no válido – UTI existe para otra Parte/Contraparte). Para un UTI registrado, el bloqueo de la Parte-Contraparte-Clase de activos permanecerá idéntico durante toda la existencia del servicio “OTC Lite”.

3. El bloqueo se aplicará para un UTI cuando el contrato tiene envíos duplicados: los envíos realizados tanto por la Parte como por la Contraparte. Después de que el Repositorio de datos reciba los informes de la parte y de la contraparte, el sistema bloqueará el UTI.

Excepciones al bloqueo del UTI: 5.3.11. El Repositorio de datos bloqueará el UTI una vez que se hayan dado las variables “Empresa-

Contraparte-Clase de activo”. Después de que el repositorio reciba los datos de las dos partes (y el bloqueo haya sido aplicado), el sistema NO permitirá al usuario modificar el ID de la parte, de la contraparte o la clase de activo. Más abajo vienen algunas excepciones de las reglas del bloqueo de UTI.

a. El Repositorio de datos permitirá la modificación del ID de la Parte y de la contraparte en el caso de que el ID de la parte y el ID de la contraparte modificados pertenezcan a la misma empresa madre del grupo.

i. Para un UTI bloqueado, el GTR permitirá a los participantes modificar el ID de empresa/contraparte, si la modificación está dentro de la estructura de la misma empresa madre.

ii. Por ejemplo, el ID de “Banco A-Europa” esta dentro del ID de la sociedad madre, “Banco A”: TR permite modificar el ID de otro participante que pertenece al mismo grupo empresarial, por ejemplo, “Banco A-Asia”

b. El Repositorio de datos permitirá el envío del ID de la parte/contraparte si el ID de la parte/contraparte fue creado originariamente bajo una empresa matriz/estructura matriz y ha pasado a una empresa matriz/estructura matriz diferente. Esto puede pasar en casos de reorganización de empresa.

i. Por ejemplo, el ID de la parte es Banco A-Europa y pertenece al ID de la empresa madre Banco A. El Repositorio permitirá los envíos de la parte/contraparte si el ID de la parte Banco A-Europa ha pasado a otro ID de la empresa madre ‘Banco A Nuevo’.

c. Si el ID ha sido enviado inicialmente como “internal” o “desconocido”, podrá modificarlo añadiendo el LEI.




6. Reconciliación Inter-TR La obligación de las compañías de enviar los informes a ESMA, junto con la posibilidad que tienen los participantes de elegir un repositorio, dará lugar a situaciones en las que las contrapartes usan repositorios diferentes con la finalidad de cumplir con su obligación con ESMA. En el escenario donde GTR mantiene una posición de una única contraparte bajo la directiva de ESMA, esta institución impone la obligación de reconciliar los datos con otros repositorios. La armonización entre los distintos repositorios (Reconciliación Inter-TR) ha sido propuesta por diversas compañías entre las que se encuentra DTCC, que han solicitado ser un repositorio de datos. Esta propuesta ha sido revisada por ESMA y comunicada en el documento “Inter-TR Reconciliation and Interoperability BRD”.

Trade Pairing 6.1La sincronización entre los acuerdos solo se puede realizar si ambas entidades han proporcionado el UTI. En caso contrario dichos acuerdos no se pueden sincronizar. La sincronización con otros repositorios solo tiene lugar si ambas contrapartes han informado con un LEI o un pre-LEI. Si el campo “ID de la contraparte” ha sido rellenado con otro dato que no sea un LEI o un Pre-LEI dicha sincronización nunca se podrá llevar a cabo, porque ellos habrán usado su LEI o pre-LEI en su campo de “ID de la contraparte”. Cuando las dos partes del acuerdo envían sus informes a GTR, la sincronización se realizará usando el UTI, ID de la contraparte e ID de la otra contraparte. Todo esto independientemente del tipo de identificación utilizado (es decir, esto no está limitado únicamente al uso de LEIs). El GTR registrará el estado de cada posición. La generación de los valores de estado de la sincronización de los acuerdos se describe en la tabla que aparece a continuación: Estado Descripción del estado de la vinculación del acuerdo Exempt La posición no se sincronizará porque la región de la contraparte es “no-EEA” (Espacio

Económico Europeo) N/A La posición no se sincronizará porque la obligación de informar no incluye a ESMA Unpaired La sincronización no se ha realizado aún al no haberse localizado ninguna pareja hasta el

momento. Unpairable La posición cumple los criterios de reconciliación de ESMA pero no tiene los campos

obligatorios requeridos para la sincronización (como los UTI y LEIs) Paired La posición se ha sincronizado con éxito, dentro de GTR o con otro repositorio. Pairing Error Cuando una posición ha realizado una sincronización externa, pero más de un TR ha

respondido con los mismos detalles de la posición Pair LEI Break Cuando se ha encontrado una posibilidad de sincronización. El UTI y uno de los LEI

coinciden, pero el otro LEI no coincide.




Trade Matching 6.2

El GTR recibe los datos referentes a los distintos acuerdos, pudiendo mantener 3 estados diferentes: “Paired Status”, “Paired Source” y “Matched Status”. Una vez el acuerdo esté armonizado, se realizará una comparación de los dos lados del acuerdo y se registrará el estado de esta comparación. Los posibles “match status” de cada acuerdo se muestran en la tabla que aparece a continuación. Los campos en los que se basa la comparación se enumeran más adelante en esta sección. Importante notar que este proceso de armonización no sustituye en ningún caso el proceso “Confirmation Matching”. Trade Match Status Descripción Trade Match Status Exempt La armonización de la posición no es obligatoria para contrapartes fuera el espacio

económico europeo. N/A La armonización de la posición no es obligatoria porque la jurisdicción no incluye a ESMA. Pending La posición no está sincronizada aún, o sí se ha sincronizado pero no se ha realizado aún el

“matching process”. Cancel La posición ha sido preparada para la armonización, pero se ha recibido un mensaje de

“exit” o “cancel” y se ha detenido el proceso. Matched La posición se ha reconciliado y las categorías 1 y 2 coinciden dentro de los l ímites de la

tolerancia prescrita. Unmatched1 La posición se ha reconciliado y uno o más campos de la categoría 1 no coinciden, pero

todos los campos de categoría 2 coinciden dentro de los l ímites de la tolerancia prescrita. Unmatched2 La posición se ha reconciliado y uno o más campos de la categoría 2 no coinciden, pero

todos los campos de categoría 1 coinciden dentro de los l ímites de la tolerancia prescrita. Unmatched La posición se ha reconciliado con el resultado de que uno o más campos de la categoría 1

no coinciden y uno o más campos de categoría 2 tampoco coinciden dentro de los l ímites de la tolerancia prescrita.

Campos y reglas 6.2.1Los campos que se muestran a continuación son los incluidos en el “trade matching”:

Tabla de los datos de la contraparte 1 Se debe notar que el campo 8 “Unique Trade Id” se considera como un vínculo común entre los campos de datos comunes y los campos de la contraparte. Número

del campo Nombre del Campo Formato ESMA La regla de armonización/tolerancia con

el otro acuerdo 2 Counterparty Id LEI Tiene que estar armonizado con el ID de

la otra contraparte 3 ID of the other counterparty LEI Tiene que estar armonizado con el ID de

la contraparte 13 Counterparty side ‘B’ = buyer, or

‘S’ = seller Tiene que tener el valor de “S” si “B” y “B” si “S”




Tabla 2: Datos Comunes Los campos en esta tabla se han categorizado como:

1. El campo va a ser reconciliado, pero si el campo no encuentra coincidencias para ambas partes del acuerdo (con la tolerancia especificada) el acuerdo será excluido de los informes agregados producidos por DTCC en su Informes Públicos.

2. El campo será reconciliado pero incluso si el campo no encuentra coincidencias en ambas partes del acuerdo (con la tolerancia especificada) el acuerdo será incluido en los informes agregados.

3. No tiene sentido práctico reconciliar estos campos N/A – este campo no es aplicable para los propósitos de la reconciliación Los siguientes niveles de tolerancia serán usados para la comparación de los campos:

1. La diferencia entre las cantidades de los acuerdos deberá ser menor del 1%. • Hay que comparar la primera cantidad y la segunda cantidad para establecer la cantidad

mayor • Hay que sustraer la cantidad más pequeña de la cantidad más grande para calcular la

diferencia • La diferencia de las cantidades se dividirá con el valor de la cantidad mayor y el resultado

después se multiplicará por 100 • Si el resultado es mayor que 1, la cantidad no coincide

2. Las cantidades de los acuerdos comprobados tienen que coincidir a la izquierda de la coma decimal.

3. La fecha de los acuerdos a comparar tiene que coincidir con la fecha del campo. No. Nombre ESMA Formato La regla de

armonización/tolerancia con el otro acuerdo

Categoría

1 Taxonomy used Identifica la taxonomía usada: U=Product Identifier [aprobado en Europa] I=ISIN/AII + CFI E=Interim taxonomy

Tiene que coincidir 1

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


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


4 Underlying ISIN (12 alphanumerical digits); LEI (20 alphanumerical digits); Interim entity identifier (20 alphanumerical digits); UPI (to be defined);





No. Nombre ESMA Formato La regla de armonización/tolerancia con el otro acuerdo

Categoría

B= Basket; I=Index. 5 Notional currency

1 ISO 4217 Currency Code, 3 caracteres alfanuméricos


6 Notional currency 2

ISO 4217 Currency Code, 3 caracteres alfanuméricos


7 Deliverable currency

ISO 4217 Currency Code, 3 alphabetical digits. 3 caracteres alfanuméricos

No tiene que coincidir 3

8 Trade id Máximo 52 caracteres alfanuméricos. Tiene que coincidir 1 9 Transaction

reference number Un campo alfanumérico con el máximo de 40 caracteres

Nunca coincidirá 3

10 Venue of execution

ISO 10383 Market Identifier Code (MIC), 4 caracteres alfabéticos. Cuando es relevante, XOFF para los derivados específicos que son “off-exchange” o XXXX para los derivados OTC

Debería coincidir 2

11 Compression Y = Cuando el acuerdo resulta de una compresión N = Si el acuerdo no resulta de una compresión


12 Price/rate Máximo 20 caracteres numéricos en el formato xxxx,yyyyy.

Se aplica el nivel de tolerancia 1

2

13 Price notation E.g. ISO 4217 Currency Code, 3 caracteres numéricos, porcentaje


14 Notional amount Máximo 20 caracteres numéricos en el formato xxxx,yyyyy.

Apply tolerance check 2

1

15 Price multiplier Máximo 10 caracteres Tiene que coincidir 1 16 Quantity Máximo 10 caracteres Tiene que coincidir 1 17 Up-front

payment Máximo 10 caracteres numéricos en el formato xxxx,yyyyy para los pagos realizados por la contraparte que está informando y en el formato xxxx,yyyyy para los pagos recibidos por la contraparte que está informando


2

18 Delivery type C=Efectivo, P=Físico, O=Opcional para la contraparte


19 Execution timestamp

ISO 8601 formato de la fecha / Formato de hora UTC.

Se aplica el nivel de tolerancia 3 para OTC

2

20 Effective date ISO 8601 formato de la fecha Tiene que coincidir 2 21 Maturity date ISO 8601 formato de la fecha Tiene que coincidir 1 22 Termination date ISO 8601 formato de la fecha Tiene que coincidir 2 23 Date of

settlement ISO 8601 formato de la fecha No puede coincidir 3

24 Master agreement type

Texto l ibre. Máximo 50 caracteres, identificando el nombre del “Master Agreement”, donde sea

No puede coincidir 3





Categoría

usado. 25 Master

agreement version

Año, xxxx. No puede coincidir 3

26 Confirmation timestamp

ISO 8601. Formato de la fecha / Formato de hora UTC.


2

27 Confirmation means

Y=Non-electronically confirmed, N=Non- confirmed, E=Electronically confirmed. Y=confirmado no-electrónicamente, N= no confirmado, E =confirmado electrónicamente


28 Clearing obligation

Y=Sí, N=No. Tiene que coincidir 2

29 Cleared Y=Sí, N=No. Tiene que coincidir 1 30 Clearing

timestamp ISO 8601 formato de la fecha / Formato de hora UTC.


2

31 CCP Legal Entity Identifier (LEI) (20 caracteres alfanuméricos) o, si no está disponible, “interim entity identifier” 20 caracteres alfanuméricos) o, si no está disponible BIC (11 caracteres alfanuméricos).


32 Intragroup Y=Si, N=No. Debería coincidir 2 33 Fixed rate leg 1

(tolerance tba) Caracteres numéricos en el formato xxxx,yyyyy.


2

34 Fixed rate leg 2 (tolerance tba)

Caracteres numéricos en el formato xxxx,yyyyy.


2

35 Fixed rate day count

Actual/365, 30B/360 u otro. No puede coincidir 3

36 Fixed leg payment frequency

Un múltiplo entero de un período de tiempo describiendo cuantas veces las contrapartes van a intercambiar los pagos, p.e. 10D, 3M, 5ª.


37 Floating leg payment frequency



38 Floating leg reset frequency



39 Floating rate of leg 1

El nombre de “floating rate index, e.g. 3M Euribor”.


40 Floating rate of leg 2

El nombre de “floating rate index, e.g. 3M Euribor”.


41 Currency 2 ISO 4217 Currency Code, 3 caracteres alfanuméricos.


42 Exchange rate 1 Máximo de 10 caracteres numéricos en el formato xxxx,yyyyy.

Tiene que coincidir

2





Categoría


43 Forward exchange rate

Máximo de 10 caracteres numéricos en el formato xxxx,yyyyy.

Tiene que coincidir Se aplica el nivel de tolerancia 1

2

44 Exchange rate basis

E.g. EUR/USD or USD/EUR. 2 X ISO 4217 Código de divisa, 3 caracteres alfanuméricos separados por una barra


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


46 Commodity Details

AG=Agricultural Debería coincidir 2

47 Delivery Point or zone (energy)

EIC code, Un código de 16 caracteres alfanuméricos


48 Interconnection point (energy)

Texto de forma libre con el máximo de 50 caracteres


49 Load Type (energy)

Sección repetible de los campos 50-54 para identificar el perfil de suministro del producto; BL=Base Load PL=Peak Load OP=Off-Peak BH= Block Hours OT=Other


50 Delivery start date time (energy)

ISO 8601 formato de la fecha Tiene que coincidir 2

51 Delivery end date time (energy)

ISO 8601 formato de la fecha Tiene que coincidir 2

52 Contract Capacity (energy)

Texto de forma libre con el máximo de 50 caracteres


53 Quantity Unit (energy)

Máximo 10 caracteres numéricos en el formato xxxx,yyyyy.


1

54 Price/time interval quantities (energy)

Máximo 10 caracteres numéricos en el formato xxxx,yyyyy.


2

55 Option type P=Put, C=Call. Tiene que coincidir 2 56 Option style A=American, B=Bermudan,

E=European, S=Asian. Tiene que coincidir 2

57 Strike price El máximo de 10 caracteres numéricos en el formato xxxx,yyyyy.


2

58 59

Action type and details of action type

3




7. Notificaciones a disposición de los participantes Las distintas notificaciones que se detallan a continuación proporcionan información sobre el estado de los diferentes envíos de los acuerdos, además de diversos detalles. El servicio OTC Lite tiene un número determinado de notificaciones que ayudan de manera global a los participantes.

Los participantes registrados en OTC Lite de forma “manual” tendrán acceso de forma directa a las distintas notificaciones, disponibles en GUI. Aquellos incorporados por el procedimiento “online”, podrán acceder a dichas notificaciones (ESMA Activity y Position Report) a través de la opción “búsqueda y descarga” del Portal. Salvo que se indique lo contrario, todas las notificaciones son descargables en formato CSV a través de la funcionalidad “Report Download” en el sistema GTR o vía sFTP. Estas notificaciones son generadas de forma automática de lunes a viernes, empezando el batch a medianoche UTC (Base de datos Europea) y estará disponible a través de Web GUI los siguientes 7 días naturales.

Importante señalar que los Position Reports de los participantes reflejan el estado actual de los acuerdos que han enviado ellos mismos, en su nombre o cuando ellos son la contraparte. No se reflejan posiciones agregadas a través de múltiples posiciones. Todos los encabezados de las diferentes notificaciones contienen tanto la fecha de su generación, como la fecha de ejecución. Esta información es útil para asegurarse de que se están descargando las últimas notificaciones disponibles.




Descargando las notificaciones desde el Portal 7.1

Las imágenes siguientes muestran como descargar las notificaciones desde el portal. Los usuarios deberán registrarse en el portal (sección 1.6) y subir la hoja de cálculo CSV (sección 2.1) para ser capaz de descargar dichas notificaciones.

Para acceder a las notificaciones ACK/NACK

1. Una vez haya entrado en el portal OTC Lite, hacer click en “Download”

2. Aparecerá un panel con las últimas notificaciones ACK

3. Para acceder a las notificaciones NACK, se deberá hacer click en el recuadro “OTC-NACK”

4. Luego deberá marcar el informe que desee descargar. Por último, haga click en el botón “Download”. Se descargará automáticamente un archivo en formato ZIP con la notificación en su interior.




Notificaciones disponibles para todas las clases de activos 7.2

La siguiente lista de notificaciones es producida por todas las clases de activo.

Nº Notificación Descripción

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

La notificación ACK o NACK es una notificación en tiempo real, e indica el estado de cada mensaje enviado. La notificación ACK incluirá todos los mensajes aceptados y la notificación NACK contendrá todos los mensajes rechazados.

2 Warning Report El Warning report nos avisará de cuestiones relacionadas con el posible incumplimiento de la normativa regulatoria, aunque el GTR haya aceptado el mensaje.

3 GTR ESMA OTC Position Report

Incluye la última posición de todos los acuerdos abiertos notificados a ESMA. La notificación contendrá solamente los campos notificables a ESMA de los datos de las contrapartes (tabla 1) y de los datos comunes (tabla 2). Todos los datos serán incluidos independientemente del servicio por el que el informe ha sido enviado.

4 GTR ESMA OTC Activity Report

Incluye todos los envíos procesados con éxito en GTR desde la última generación de las notificaciones para todos los UTIs notificados a ESMA. La notificación contendrá solamente los campos notificables a ESMA de los datos de contrapartes (tabla 1) y de los datos comunes (tabla 2). Todos los datos serán incluidos independientemente del servicio por el que el informe ha sido enviado.

5 ESMA Match Status Report Notificaciones de Pairing status y Match status por UTI. Se enumeran todos los campos no coincidentes

6 UTI Conflict and Pair Break LEI Report

Listado de todos los acuerdos en los que cada pareja de LEIs enviados es diferente para cada uno de los envíos con el mismo UTI.

ACK/NACK 7.2.1Las notificaciones ACK y NACK (descargables en formato de Hoja De Cálculo) incluirán todos los envíos que se han realizado al Repositorio, que han sido o bien correctamente procesados o bien rechazados. A continuación se muestra una notificación ACK, analizada campo por campo: No. Nombre del campo Ejemplo Descripción

1 Action New Indicará si el mensaje es “New”, “Modify” o “Cancel” 2 Transaction Type Trade La transacción definida en la plantilla




No. Nombre del campo Ejemplo Descripción

3 Message Type Position El tipo de mensaje 4 UTI Prefix IssuerA Prefijo del UTI 5 UTI Value UTI123 Unique Trade Identifier;

UTI Value del envío 6 Asset Class Equity El tipo de activo 7 Product ID Prefix 1 ISDA El prefijo que identifica el primer producto 8 Product ID Value 1 Equity:Swap:Pri

ceReturnBasicPerformance:SingleName

El valor identificador del primer producto

9 Product ID Prefix 2 El prefijo que identifica el segundo producto 10 Product ID Value 2 El valor identificador del segundo producto 11 Execution Timestamp 2012-02-

09T15:25:00Z El tiempo de ejecución de la transacción. Tiempo Universal Coordinado (UTC). (YYYY-MM-DDTHH:MM:SSZ)

12 Data Submitter Prefix LEI Prefijo de la entidad que sube el archivo 13 Data Submitter Value 5678 Valor identificativo de la entidad que sube el archivo 14 Trade Party 1 Prefix LEI Prefijo de la primera contraparte 15 Trade Party 1

Value 5678 Valor identificativo de la primera contraparte

16 Trade Party 2 Prefix LEI Prefijo de la segunda contraparte 17 Trade Party 2

Value 3214 Valor identificativo de la segunda contraparte

18 Transaction Reference Number

123456 Valor específico de EMIR

19 Internal Trade Reference Adft56687 Referencia interna del número de acuerdo de cada entidad 20 Reporting Obligation

Party 1 ESMA Jurisdicción a la que se envía el acuerdo.

21 Reporting Obligation Party 2

ESMA Jurisdicción a la que se envía el acuerdo.

22 Data Submitter Message ID

CSV123 Referencia proporcionada por la entidad que envía el informe. Único por cada acuerdo del archivo CSV

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

Fecha y hora del envío. Formato UTC Es la fecha que nos indica cuando ha llegado el envío a GTR. ( YYYY-MM-DDTHH:MM:SSZ )

24 Status ACCEPTED El estado del mensaje en GTR.

La notificación NACK incluirá todos los campos que aparecen en el envío CSV, además de los siguientes 3 campos adicionales:

Submission Date & Time Status Error Code / Reason




Warning Report 7.2.2El objetivo de este informe será destacar las posibles incidencias de la plantilla relacionadas con carencias de información en algunos valores en GTR de aquellos envíos que han sido aceptados correctamente. Por ejemplo, cuando se reporta en nombre de ambas entidades (delegación completa) pero no se ha completado el campo “Trade Party 2 Domicile”. Recordar que todas las posiciones que aparecen en el Warning Report serán comunicadas a ESMA. El Warning Report estará disponible para las dos partes del acuerdo si “Submitted for Value” = “Both”. Lista de campos: No. Nombre del campo Ejemplo Descripción

1 UTI Prefix XXX Identifica el prefijo del UTI 2 UTI Value 123 UTI asignado al envío 3 Primary Asset Class Equity Clase de activo del envío 4 Product ID Prefix 1 ISDA Identifica la taxonomía que clasifica el producto

(preferentemente ISDA) 5 Product ID Value 1 Equity:Swap:Pri

ceReturnBasicPerformance:SingleName

Identificación del producto según la taxonomía anterior (preferentemente ISDA)

6 Product ID Prefix 2 7 Product ID Value 2 8 Data Submitter Prefix LEI Prefijo de la entidad que sube el archivo 9 Data Submitter Value 5678 Valor identificativo de la entidad que sube el archivo

10 Submitted For Prefix LEI Prefijo que identifica la entidad por la que se realiza el envío. 11 Submitted For Value 5678 Valor identificativo de la entidad por la que se realiza el envío. 12 Submission Date/Time 2012-03-

26T09:10:10Z Cuando el envío ha sido procesado por GTR

13 Trade Party 1 Prefix LEI Prefijo que identifica la Party 1 como una de las contrapartes del acuerdo

14 Trade Party 1 Value 5678 Valor que identifica la Party 1 como una de las contrapartes del acuerdo

15 Trade Party 1 Name Bank A Nombre de la entidad. Valor extraído a través de la combinación de los dos campos anteriores.

16 Trade Party 1 Notional 100000 Valor nocional correspondiente a Party 1 17 Trade Party 1 Notional

Currency/Units USD Divisa correspondiente a “Trade Party 1 Notional”

18 Trade Party 2 Prefix LEI Prefijo que identifica la Party 2 como una de las contrapartes del acuerdo

19 Trade Party 2 Value 3214 Valor que identifica la Party 2 como una de las contrapartes del acuerdo

20 Trade Party 2 Name Bank B Nombre de la entidad. Valor extraído a través de la combinación de los dos campos anteriores.

21 Trade Party 2 Notional 100000 Valor nocional correspondiente a Party 2 22 Trade Party 2 Notional

Currency/Units USD Divisa correspondiente a “Trade Party 2 Notional”




No. Nombre del campo Ejemplo Descripción

23 Transaction Reference Number

1323423 Campo específico de EMIR

24 Internal Trade Reference T98765 25 Data Submitter Message

ID CSV789 Referencia proporcionada por la entidad que sube el

archivo. Tiene que ser único por cada acuerdo. 26 Warning Reason Code 12 Código que advierte de un error 27 Warning Description Unknown

Counterparty Descripción de las razones del error

En la siguiente tabla aparece la lista de errores con su correspondiente descripción.

Código de error

Descripción del error

OTLW1001 “Reporting Obligation Party 2” es obligatorio cuando se informa en nombre de ambas contrapartes OTLW1002 “Trade Party 2 Domicile” es obligatorio cuando se informa en nombre de ambas contrapartes

OTLW1003 “Trading capacity Party 2” es obligatorio cuando se informa en nombre de ambas contrapartes OTLW1004 “Buyer Value Party 2” es obligatorio cuando se informa en nombre de ambas contrapartes OTLW1005 “Trade Party 2 Financial Entity Jurisdiction” o “Trade Party 2 Non-financial Entity Jurisdiction” es

obligatorio cuando se informa en nombre de ambas contrapartes OTLW1006 “MTM Currency Party 2” es obligatorio cuando se informa en nombre de ambas contrapartes OTLW1007 “Valuation Datetime Party 2” es obligatorio cuando se informa en nombre de ambas contrapartes OTLW1008 “Valuation Type Party 2” es obligatorio cuando se informa en nombre de ambas contrapartes OTLW1009 “Trade Party 2 Corporate Sector” es obligatorio cuando “Trade Party 2 Financial Entity Jurisdiction”

está en blanco y “Trade Party 2 Non-financial Entity Jurisdiction” está en blanco OTLW1010 “Trade Party 2 Corporate Sector” es obligatorio cuando ”Trade Party 2 Financial Entity Jurisdiction” es

"ESMA" OTLW1011 “Directly l inked to commercial activity or treasury financing Party 2” es obligatorio si Party 2 no es una

entidad financiera OTLW1012 “Clearing Broker Party 2 Value” es obligatorio cuando el acuerdo está compensado por una cámara OTLW1013 “Beneficiary ID Party 2 Value” es obligatorio por Party 2 cuando se informa en nombre de ambas

entidades y además se rellena el campo “Agent” OTLW1014 “Clearing Threshold Party 2” es obligatorio cuando “Trade Party 2 Non-financial Entity Jurisdiction” es

"ESMA" OTLW1015 UTI contiene más de 52 caracteres OTLW1016 “Counterparty Region” es obligatorio para ESMA (Transacción realizada con una contraparte “non-

EEA”) OTLW1017 “Clearing Broker Party 1” es obligatorio cuando el acuerdo utiliza una Cámara de Compensación OTLW1018 “Settlement Currency“ es obligatorio según especificaciones de ESMA OTLW1019 “Execution Venue Value” es obligatorio según especificaciones de ESMA OTLW1020 “Price Notation – Price” es obligatorio según especificaciones de ESMA OTLW1021 “Price Notation - Price Type” es obligatorio según especificaciones de ESMA OTLW1022 “Delivery type” es obligatorio según especificaciones de ESMA OTLW1023 “Execution Timestamp” es obligatorio según especificaciones de ESMA OTLW1024 “Effective Date” es obligatorio según especificaciones de ESMA OTLW1025 “Date of Settlement” es obligatorio según especificaciones de ESMA OTLW1026 “Clearing Timestamp” es obligatorio según especificaciones de ESMA




Código de error

Descripción del error

OTLW1027 “Clearing DCO Value” es obligatorio según especificaciones de ESMA OTLW1028 “Clearing Threshold Party 1” es obligatorio según especificaciones de ESMA OTLW1029 “MTM Currency CCP” es obligatorio OTLW1030 “Valuation Datetime CCP” es obligatorio OTLW1031 “Valuation Type CCP” es obligatorio

GTR ESMA OTC Position Report 7.2.3En la notificación aparecerán todas las posiciones del participante que están abiertas en el Repositorio de datos Europeo. Aquellas posiciones con “Reporting Obligation” ESMA son enviadas a ESMA. El formato del informe indicará los campos de ESMA y los datos que se envían hacia cada uno de estos campos. Todos los datos se reflejarán en la notificación (donde el participante ha sido nombrado como una parte del acuerdo con un UTI notificado por otra contraparte). No se proporcionará ninguna información adicional en la notificación.

El ESMA Position Report incluye aquellos acuerdos en los que el receptor de la notificación es nombrado como una contraparte al acuerdo o como agente de ejecución.

Lista de campos: ESMA Table #

Campo EMIR Referencia de ESMA Table Asignación de campos en GTR

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

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

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

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

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

Broker Id Party 1 Value Party 1 Reporting Obligation GTR Control field Reporting Jurisdiction GTR Control field




ESMA Table #


Data Submitter Prefix GTR Control field Data Submitter Value GTR Control field 9 Reporting entity ID Table 1 - Counterparty Data Data Submitter Prefix,

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

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

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

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

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

MTM Value CCP 18 Currency of mark to market value of

the contract Table 1 - Counterparty Data MTM Currency party 1

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

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

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

Valuation Type CCP 22 Collateralisation Table 1 - Counterparty Data Collateralized Party 1 23 Collateral portfolio Table 1 - Counterparty Data Collateral portfolio code Party 1 24 Collateral portfolio code Table 1 - Counterparty Data Collateral portfolio code Party 1 25 Value of the collateral Table 1 - Counterparty Data Value of the collateral Party 1 26 Currency of the collateral value Table 1 - Counterparty Data Currency of the collateral value Party 1 Primary Asset Class GTR Control field Secondary Asset Class GTR Control field Product ID Prefix GTR Control field Product ID Value GTR Control field 1 Taxonomy used Table 2 - Common Data Product ID Prefix 2 Product ID 1 Table 2 - Common Data Product ID value 1 3 Product ID 2 Table 2 - Common Data Product ID Value 2 4 Underlying leg 1 Table 2 - Common Data Underlying Asset leg 1 4a Underlying leg 2 Table 2 - Common Data Underlying Asset leg 2 5 Notional currency 1 Table 2 - Common Data Notional Currency 6 Notional currency 2 Table 2 - Common Data Notional Currency




ESMA Table #


7 Deliverable currency 1 Table 2 - Common Data Settlement Currency 7a Deliverable currency 2 Table 2 - Common Data Settlement Currency UTI Prefix GTR Control field UTI Value GTR Control field USI Prefix GTR Control field USI Value GTR Control field Trade Party 1 Transaction Id GTR Control field 8 Trade ID Table 2 - Common Data UTI Prefix, UTI Value Prior UTI Prefix GTR Control field Prior UTI Value GTR Control field Trade Link ID GTR Control field Exchange Traded Derivative

indicator GTR Control field

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




ESMA Table #


29 Cleared Table 2 - Common Data Cleared 30 Clearing timestamp Table 2 - Common Data Clearing Timestamp Clearing DCO Prefix GTR Control Field 31 CCP ID Table 2 - Common Data Clearing DCO Prefix

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

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

Action




ESMA Table #


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

Notar que los campos de control de GTR se utilizan en la Tabla 1 y la Tabla 2, pero no están incluidos en los informes de los reguladores.

GTR ESMA OTC Activity Report 7.2.4En esta notificación aparecerá toda la actividad desde el momento en que los participantes han recibido la notificación “Activity Report” anterior. El formato del informe indicará los campos de ESMA y los datos que se envían hacia cada uno de estos campos. El Activity Report tiene exactamente el mismo formato y mismos campos que el ESMA Position Report. Todos los datos se reflejarán en la notificación (donde el participante ha sido nombrado como una parte de la transacción con un UTI notificado por otra contraparte).

El formato de ESMA Activity Report y los campos incluidos en esta notificación son idénticos a los del ESMA Position Report, como se ha descrito en el capítulo anterior. Los campos Lifecycle Event, Lifecycle Event Effective Date, Action type y Details of action type se incluirán en el Activity Report pero se quedarán en blanco en el Position Report.

ESMA Match Status Report 7.2.5El Nuevo Matching Status report proporcionará a los participantes un resumen de diferencias entre la categoría 1 y la categoría 2 para facilitarles investigación y solución de discrepancias (Break). Véase más arriba el capítulo que trata sobre la reconciliación entre los repositorios para ver la definición de la categoría de “break”. El Matching Status report detallará el listado de campos que no coinciden. Sin embargo, solamente aparecerá el nombre del campo y no su contenido, y eso para los dos lados de la posición. La notificación contendrá los campos siguientes:

• UTI • Party 1 LEI • Party 2 LEI (u otro identificador) • Estado de la reconciliación del acuerdo • Campos no coincidentes • ID de la transacción de Parte 1




Los nombres de los campos no coincidentes se mostrarán horizontalmente y separados por un punto y coma

UTI LEI de Parte 1 LEI de Parte 2 Estatuto de reconciliación

del acuerdo Campos no

coincidentes

ID de la transacción de

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

ABC125 SAMPLE98765LEI7ABCD SAMPLE123LEI456ABCD Dual-sided, unmatched category 1

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

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

ABC127 SAMPLE98765LEI7ABCD SAMPLE789LEI456EFGH Dual-sided matched OUR127REF

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

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

Exchange Rate - 2; Execution Timestamp - 2 OUR129REF

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

ABC131 SAMPLE98765LEI7ABCD SAMPLE789LEI456EFGH Single-sided, paired, matched OUR131REF Como referencia, en la siguiente tabla se puede ver la descripción de los distintos estatus:

Trade Reconciliation Status Descripción

Single-sided, unpaired, non EEA

El acuerdo ha sido enviado pero la otra parte del acuerdo no es un acuerdo aplicable a la jurisdicción “ESMA”. No es necesaria la reconciliación.

Single-sided, unpaired, EEA

GTR tiene una parte del acuerdo. La otra parte del acuerdo pertenece al Espacio Económico Europeo (EEA) en base a la información del valor del contrato con contraparte NO-EEA (Table 1- Counterparty Data), estando definido como “Y”. No se sabe en que repositorio está almacenada dicha información.

Dual-sided, unmatched category 1

GTR tiene ambas partes del acuerdo. Los campos de la categoría 1 no concuerdan siguiendo la tolerancia definida en el apéndice A. Los campos no coincidentes serán enumerados en la reconciliación.

Dual-sided, unmatched category 2

GTR tiene ambas partes del acuerdo. Los campos de la categoría 2 no concuerdan siguiendo la tolerancia definida en el apéndice A. Los campos no coincidentes serán enumerados en la reconciliación.




Dual-sided matched GTR tiene ambas partes del acuerdo y todos los campos coinciden siguiendo la tolerancia definida en el Apéndice A

Single-sided, paired, unmatched category 1

GTR tiene una parte del acuerdo. Los detalles de la otra parte del acuerdo han sido obtenidos de otro repositorio. La reconciliación ha tenido lugar y no todos los campos coinciden con la tolerancia definida en el Apéndice A. Los campos no coincidentes serán enumerados en la reconciliación.

Single-sided, paired, unmatched category 2

GTR tiene una parte del acuerdo. Los detalles de la otra parte del acuerdo han sido obtenidos de otro repositorio. La reconciliación ha tenido lugar y no todos los campos coinciden con la tolerancia definida en el Apéndice A. Los campos no coincidentes serán enumerados en la reconciliación.

Single-sided, paired, match pending

GTR tiene una parte del acuerdo. Los detalles de la otra parte del acuerdo han sido obtenidos de otro repositorio. El proceso de reconciliación no ha tenido todavía lugar.

Single-sided, paired, matched

GTR tiene una parte del acuerdo. Los detalles de la otra parte del acuerdo han sido obtenidos de otro repositorio. La reconciliación ha tenido lugar y todos los campos coinciden con las tolerancias descritas en el Apéndice A.




ESMA UTI Conflict or Pair LEI Break Report 7.2.6Esta nueva notificación proporciona a las empresas información relativa a la inter-reconciliación entre los repositorios. Una notificación adicional contendrá los detalles de conflictos entre los UTIs o los LEI que han informado los participantes en sus envíos, informando de diversos problemas específicos. Desde la perspectiva de Party A, en la notificación “UTI Conflict & Pair Break LEI” aparecerán 4 columnas

1. Columna A = UTI 2. Columna B = Party A LEI (hipotetizamos que el envío lo ha realizado Party A) 3. Columna C = Party B LEI (hipotetizamos que el envío lo ha realizado Party A) 4. Columna D = Error Code [“UTI reported by other parties”, “UTI reported to GTR in error” o

“Mismatched LEI”]

No. Field Name Sample Data Description 1 UTI ABC123 2 Party 1 LEI SAMPLE98765LEI7ABCD 3 Party 2 LEI SAMPLE123LEI456ABCD 4 Error Code UTI informado por otras compañías

El error "UTI reported by other parties” se generará cuando:

Party A vs. Party B reports UTI 123 Party C vs. Party D reports UTI 123

El error “Mismatched LEI” se generará cuando:

Party A vs. Party B reports UTI 456 Party B vs. Party C reports UTI 456




8. Apéndice A – Enlaces útiles

Trasfondo de Regulaciones 8.1

Proyecto Final de Normas Técnicas de ESMA 8.1.1http://www.esma.europa.eu/system/files/2012-600_0.pdf

Extracto Final de Normas Técnicas de ESMA 8.1.2http://dtcc.com/~/media/Files/Downloads/Data-and-Repository-Services/GTR/GTR-Europe/Summary_ESMA_Technical_Standards.ashx

Comparación entre EMIR y DFA 8.1.3http://dtcc.com/~/media/Files/Downloads/Data-and-Repository-Services/GTR/GTR-Europe/EMIRvDFA-QandA.ashx

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

Nota: Asegúrense de descargar la versión actualizada de este documento.

Guía sobre Price Notation de ISDA 8.1.5http://www2.isda.org/attachment/NTQxMA==/ISDA%20PN-APN%20Approach%20Document%20v1.0%202013_03_15.xlsx

Business Requirements Document 8.2

Visite el Centro del Cliente de GTR (mencionado en el capítulo 1.2) y seleccione “Business Requirement Documentation” en el menú desplegable para conseguir la documentación.

CSV Upload Template 8.3

Visite el Centro del Cliente de GTR (mencionado en el capítulo 1.2) y seleccione “Supported – Spreadsheets and Messaging Specs” en el menú desplegable para conseguir la documentación.

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

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

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

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

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

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

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

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





Vídeos y presentaciones de OTC Lite 8.4

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

Taxonomía de ISDA 8.5

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

Guía Internacional de Transmisión de sFTP v1.0 8.6

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

Lista de contactos de OTC Lite 8.7

1. OTC Lite UAT [email protected]

2. Preguntas OTC Lite [email protected]

3. Onboarding [email protected]

4. Actualización de los datos de las contrapartes [email protected]

5. Grupo de Conectividad [email protected]

6. Centro de Atención al Cliente [email protected]





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












9. Apéndice B – Preguntas más frecuentes (FAQs)

¿Cuál es el alcance geográfico y jurisdiccional de OTCLite? 9.1

El servicio OTC Lite cubre las transacciones de derivados OTC que tienen que ser informadas bajo la normativa “European Market Infrastructure Regulation” (EMIR) SOLO a GTR. Una vez los requisitos adicionales de “EC” y ”ACER” estén concluidos, se publicará una documento actualizado que soportará estos requisitos.

¿Quién es capaz de usar el servicio OTCLite? 9.2

La tabla que aparece a continuación muestra los escenarios de los usuarios del servicio.

Escenario

CFTC

JFSA

MAS

ASIC

HKMA

Obligaci ó n informa r a:

ESMA (EMIR)

¿Puede el usuario “OnBoarded” usar OTC Lite?

Escenario 1

Ya “OnBoarded” para uno (o todos) de los escenarios que se muestran a continuación (nivel jurisdiccional )

Sí

Sí

Sí

Sí

Sí

Sí

Sí

Escenario 2

“OnBoarded” para todas las clases de activos para todas las jurisdicciones, pero quiere enviar notificaciones a ESMA usando la plantilla de OTCLite (la Plantilla Lite soporta todas clases de activos)

Credit, Interest

Rates, Equity, FX, Commodity

Credit, Interest


Credit, Interest


Credit, Interest


Credit, Interest


Sí

Sí

Escenario 3

“OnBoarded” para una combinación de algunas de las clases de activos (pero no todas) y para todas las jurisdicciones. Envío de los informes a ESMA usando la plantilla OTCLite para el resto de las clases de activos

Credit, Tipos de interés, Equity, FX, Commodity

Credit,

Tipos de interés,

Equity, FX



FX, Tipos de interés

Sí

Sí, ningún límite específico de notificar cualquier otra clase de activos




Escenario 4 Un usuario Nuevo con la obligación de enviar las notif icaciones solamente a ESMA

No No No No No Sí Sí

Escenario 5 Usuario actual o Nuevo que quiere

usar la plantilla OTCLite para notif icaciones multijurisdiccionales

No

No

No

No

No

Sí

No

Escenario 6

Un usuario actual o nuevo que quiere dividir sus informes dentro de una clase de activos para los propósitos de notif icación (por ejemplo. algunos “interest rates” se van a notif icar usando el sistema Core y otros con OTCLite)

Sí

No – Tanto el envío como y el informe son diferentes.

Escenario 7 Un usuario actual o nuevo sin la obligación de enviar las notif icaciones a ESMA

No No

Escenario 8 “Middle Market” incorporado via internet No No No No No Sí Sí – solamente buscar y descargar

Escenario 9

Un proveedor intermedio envía los informes

Sí Sí – pero solamente puede enviar los archivos .csv

Escenario 10 Un usuario nuevo o actual que quiere enviar las notif icaciones en lugar de sus clientes – onboarding completo directo con GTR onboarding

Sí Sí – permitido de notif icar, buscar y descargar

¿Es posible enviar múltiples archivos durante un día con una línea para cada uno de los acuerdo? 9.3

Es posible enviar múltiples archivos en un día usando el tipo de transacción “Position message”, informando sobre todos los eventos posteriores del acuerdo. Se añadirá la causa del evento posterior y los detalles relevantes de este evento. El último envío “Position message” representará la posición final del día. Si se envían múltiples “Position messages” el sistema ordenará el orden en que debe ser procesados según el campo ““As of Date/Time””




¿Cuáles campos opcionales necesitan estar rellenados? 9.4

Las compañías deben mirar la condicionalidad dentro de cada tipo de mensaje donde se representa claramente cuáles de los campos son requeridos, opcionales o condicionales. Después se debe mirar la columna “EMIR field” (la columna J) para entender cuáles de los campos son adicionalmente requeridos por EMIR (refiriéndose al tipo de la transacción y del mensaje) para asegurarse que dichas notificaciones cumplan totalmente con las directrices proporcionadas por ESMA.




¿Es necesario rellenar el campo ‘Trade Party 2’ si una parte envía 9.5informes de manera de delegación independiente?

La parte que envía el informe necesita notificar como mínimo los campos Trade Party 2 Prefix & Value (y el nombre de la contraparte cuando “SWIFTBIC”, “Internal” o “Freeformattext” ha sido usado como prefijo). Son requerimientos de Emir. El otro campo relativo a Party 2 que es obligatorio según EMIR es “Counterparty Region” (para identificar si la contraparte es una contraparte dentro del Espacio Economico Europeo) y aunque el campo es Optional en el mensaje, es necesario proporcionarlo para cumplir completamente con las normativas. La razón de que el campo es opcional se debe a comunicaciones que hemos recibido de varias empresas, indicando que esta información no siempre es conocida en el momento de enviar los informes. El Warning report nos indicará si este campo está vacío. En este caso, la empresa deberá de enviar un “Position message” para añadir información en cuanto este disponible para cumplir completamente con las normativas.

¿Cómo puedo enviar productos estructurados o exóticos? 9.6

La naturaleza de los productos estructurados y exóticos no es “estándar” y es posible que no haya una guía acordada por la industria financiera de las mejores prácticas a la hora de notificar este tipo de productos. Por tanto, GTR proporciona los campos requeridos por ESMA y se deja a las empresas la decisión de como rellenar dichos valores

¿Cuál es el horario de funcionamiento del sistema de DTCC? 9.7

DTCC procesa datos para notificar cada día a las horas de corte especificadas desde la medianoche del domingo hasta la medianoche de viernes. DTCC tiene un periodo de mantenimiento semanal, que comienza el sábado a las 22, tiempo EST (Eastern Standard Time) hasta el domingo a las 6 de la mañana, tiempo EST. Durante este tiempo los mensajes recibidos se pondrán a la cola y se procesarán después de este periodo de mantenimiento.




10. Apéndice C – Mejores prácticas para el envío de archivos El siguiente apartado tratará las mejores prácticas recomendadas por DTCC para la subida de archivos. No se tiene que entender como una guía de carácter legal para informar a ESMA. Por favor, consulte con su departamento legal para asegurarse de la exactitud y precisión de la información enviada a GTR. Además, las empresas deberán de seguir las directrices proporcionadas por el documento “OTC Lite Message Template” a la hora de rellenar los distintos valores de forma correcta.

Guía de activos cruzados 10.1

Una misma UTI debe subirse únicamente a UNA aplicación (Core o OTC Lite). En el caso de que se recibiera tanto en Core como en OTC Lite una misma UTI, podría causar una duplicación de la información en la base de datos que disponen las instituciones reguladoras.

Guía de la plantilla

• Los informes deben usar la Taxonomia proporcionada por ISDA (International Swaps and Derivatives Association)

• Se puede encontrar información relativa a esta taxonomía en el siguiente enlace • http://www2.isda.org/attachment/NTQxMA==/ISDA%20PN-

APN%20Approach%20Document%20v1.0%202013_03_15.xlsx • El campo “Underlying Asset” (activo subyacente) no se utiliza para “FX” o “Commodity”, o la

mayoría de “Interest Rates” • Cuando existe un ISIN disponible, debe ser informado

• El campo “Price Multiplier” solo debe ser utilizado para informar “Equity Products” • ‘Quantity’ será ‘1’ para los productos Credit, Interest Rates, y FX, pero en el caso de Commodity

y Equity, será el numero de contratos de los que se notifica en el envío. • Cuando haya que informar de múltiples valores se escribirán de forma secuencial separados por

el carácter “;”. Por ejemplo: Notional Amount = 110; 120; 130; Notional Currency = USD; GBP; EUR será informado como 110 USD; 120 GBP; 130 EUR)

• Los campos en los que los valores permitidos son “texto”, se puede escribir el carácter (“,”) siempre que este entre comillas. Ejemplo: “Beneficiary ID Party 1 Value” es un valor que admite texto. Para que sea aceptado el texto deberá estar entre comillas. “Fund A LTD.” Los valores catalogados como “Enumeration” son sensibles a Mayúsculas y Minúsculas.

• Todas las fechas tienen que tener el formato YYYY-MM-DD. Los valores que incluyen también las horas: YYYY-MM-DDTHH:MM:SSZ, y en Tiempo Universal Coordinado (UTC).

• DTCC no proporciona mejores prácticas para informar a ESMA productos exóticos. Queda a criterio de las empresas.

• Las distintas estrategias disponibles para informar, deberán seguir el registro de confirmación







Guía Lifecycle Event

• Cuando se informa del campo “Notional Amount” como consecuencia de un “LifeCycle Event”, el valor tiene que ser siempre la posición final de la transacción.

o A continuación se puede ver un ejemplo:

UTI Lifecycle Event Notional Amount Notional Currency Notas UTI123 Trade 1,000,000.00 EUR UTI123 Increase 1,500,000.00 EUR Se incrementa la posición anterior en

500.000 EUR

Guía técnica 10.2

• Aquellas filas que no están destinadas para ser procesadas en GTR deben tener un asterisco “*” al principio de la fila.

• El “footer” es obligatorio. Tiene que estar en la última línea de la plantilla. Tiene el siguiente formato: *<4 CHAR OCODE>-END<8DIGIT # OF TRADE ROWS>

• Ejemplo: *8TY6-END00000280 • Todos los archivos tienen que encontrarse en formato CSV • Todos los campos cuyos únicos valores permitidos son una enumeración, son sensibles a letras

Mayúsculas y Minúsculas. El sistema no reconoce de la misma forma “TRUE” y “true” • Los campos en los que los valores permitidos son “texto”, se puede escribir el carácter (“,”)

siempre que este entre comillas. • Ejemplo: “Beneficiary ID Party 1 Value” es un valor que admite texto. Para que sea

aceptado el texto deberá estar entre comillas. “Fund A LTD.” • Todas las fechas tienen que tener el formato YYYY-MM-DD. Los valores que incluyen también las

horas: YYYY-MM-DDTHH:MM:SSZ, y en Tiempo Universal Coordinado (UTC o GMT).

Valid Values 10.3

Aunque OTC Lite no permite FpML, a continuación se muestran diversos link que derivan de la terminología usada por ISDA. Los participantes los pueden usarlos como valores validos. Combinaciones FpML

• 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, D = Day, Y =Year, W= Week, T=Term

http://www.fpml.org/coding-scheme/day-count-fraction



http://www.fpml.org/coding-scheme/floating-rate-index



http://www.fpml.org/coding-scheme/price-quote-units



http://www.fpml.org/coding-scheme/product-taxonomy






• Los usuarios deben rellenar la frecuencia con el siguiente formato: número + frecuencia (es decir: 3M, 4Y, 3W, 1T)

Interest Rates 10.4

Product Specific • El tipo de “Debt Option Strike Price” se debe de rellenar con un porcentaje • La amortización de cantidades nocionales marcadas con un calendario deben de ser actualizadas

con cada movimiento. Los usuarios indicarán el resultado final, sin ser un “LifeCycle Event”. Esto es un contrato intrínseco.

• El tipo de interés variable debe seguir el formato “tenor + floating rate” • Las empresas deberán rellenar los valores “leg1/2 payer” • Para el la operatión “cap floor”, ”Option Strike Price Type” debería tener el formato Cap;basis • La fecha de vencimiento de un FRA es la fecha efectiva

• Por ejemplo: • Si se abre la posición el día 2014-01-07, este valor debería ser considerado como

‘Execution Timestamp’ • Si la fecha valor es 2014-03-19 será considerada como ‘Effective Date’ • Si la fecha de vencimiento es 2014-06-18 será considerará como ‘Scheduled

Termination Date’ • Si el cliente usa la estrategia Collar, será necesario enviar dos acuerdos a ESMA. Uno por el Cap y

otro por el Flor, con dos UTIs diferentes. También está la posibilidad de informar dicha transacción como un “Exotic”.

• Para informar de Rate Resets, el índice subyacente (cualquier tipo de interés) será armonizado como parte del proceso Inter/Intra TR. Eso deberá estar acordado con su contraparty

Elección de la parte compradora (buyer)

• Para opciones financieras, el comprador de dicha opción se considerara el “buyer” • Para productos con un interés fijo, el comprador de la parte fija es considerado el “buyer” • Para otro tipo de productos no hay mejores prácticas definidas.

Commodities 10.5

Especificaciones del producto • Load Type solo se utiliza en taxonomías “Electric” • Fechas de inicio y final no se aplican con taxonomía “Cash” • “Delivery Point” y “Interconnection point” solo se aplican para la siguiente taxonomia Eng:Elec

taxonomies




• El campo “Price/Time“ solo se aplica para Elec. El tipo estará seguido de las horas. (Por ejemplo: 14;15;16 = Rate for hour 1 =14, Rate for hour 2 =15, Rate for hour 3 =16)

Foreign Exchange 10.6

Especificaciones del producto • Cuando se informa de Swap FX, los usuarios deberán realizar dos envíos. Uno por el FX Spot y

otro por el FX Forward., con UTIs distintas. Se deberá usar el campo “Link ID“ para vincular ambos envíos.

• El link ID debe ser único y compartido por ambas transacciones • Los usuarios también pueden informar de un FX Swap con dos acuerdos FX Spot o dos acuerdos

FX Forward • Para informar de FX Forward, el valor del campo “Exchange rate 1 (Foreign exchange only)”

debe ser el mismo que “Forward exchange rate (Foreign exchange only)” • La divisa numero 1 deberá ser rellenado en el campo “Notional Currency/Units” • La divisa número 2deberá ser rellenado en el campo “Currency 2” • Para FX Swaps, “Effective Date” es la fecha efectiva del Swap. Para FX Forwards, la fecha efectiva

es la fecha del acuerdo. • Los NDFs suelen cerrarse un día diferente del día de vencimiento. Todos los demás productos se

cierran el día de vencimiento.

La determinación del “Buyer” • El comprador de una opción es considerado el “buyer” de la operación • Para productos diferentes de las opciones, es posible que no haya un comprador definido. En

este caso no hay “mejores prácticas”. Queda a elección de las empresas. Ejemplo de un FX Forward Party 1 compra 1000EUR a Party 2. Precio: 80 = £800 .Fecha: 2014-06-20 * A continuación se muestra una versión reducida con el fin de i lustrar el escenario anterior. Por favor, consulte la plantilla para asegurarse de rellenar todos los campos requeridos por GTR y ESMA.

Nom b r e del cam p o en GTR Val o r Notas Version Lite1.0 Message Type Position Action New Transaction Type Trade UTI Prefix UTIPREFIX UTI Value TRANSACTID007 Primary Asset Class ForeignExchange Product ID Prefix 1 ISDA




Product ID Value 1 ForeignExchange:Forward Underlying Asset (repeatable up to 2 times semi-colon separated) N/A no valido para FX Notional Currency/Units (repeatable up to 2 times semi-colon separated) EUR

La primera divisa en la base de cotización del tipo de cambio debe ser rellenada. Ejemplo EUR/GBP

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

Solamente se puede aplicar en “Non Deliverable Forwards” y “Non Deliverable Options”. En todos los otros casos tiene que quedarse en blanco.

Price Notation - Price 0.8

La guía de las mejores prácticas para rellenar este campo se encuentra en este enlace.

Price Notation - Price Type Rate

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

1000;800

El Notional 1 se aplica a la primera moneda en el campo "Notional Currency/Units (repeatable up to 2 times semi-colon separated)", “Notional Amount” se aplica a la moneda 2

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

Aplicable a “Non Deliverable Options” y Non Deliverable Forwards”

Lifecycle Event New

Currency 2 (Foreign exchange only) GBP

En el campo "Currency 2 (Foreign exchange only), el valor debería siempre reflejar el pagador de la segunda divisa expresado en la base de cotización del tipo de cambio.

Exchange rate 1 (Foreign exchange only)

0.8

Para Forwards, el campo "Exchange rate 1 (Foreign exchange only)" será el mismo que el campo "Forward exchange rate (Foreign exchange only)"

Forward exchange rate (Foreign exchange only)

0.8

Para Forwards, el campo "Exchange rate 1 (Foreign exchange only)" será el mismo que el campo "Forward exchange rate (Foreign exchange only)"

Exchange rate basis (Foreign exchange only)

EUR/GBP

La base del tipo de cambio (applicable solo a FX) seguirá la siguiente sucesión lógica: • Notional Currency/Units • Notional Amount (repeatable up to 2 times semi-colon

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

Leg/Currency 1 Payer

Trade Party 2

El campo Leg/Currency 1 Payer estará relacionado con "Notional Currency and Notional Amount 1". Para FX, Leg 1 deberá siempre reflejar el pagador de la primera moneda expresada en la base de la cotización del tipo de cambio.

Leg/Currency 2 Payer

Trade Party 1

El campo Leg/Currency 2 Payer estará relacionado con "Notional Currency and Notional Amount 2". Para FX, Leg 2 deberá siempre reflejar el pagador de la primera moneda expresada en la base de la cotización del tipo de cambio.



Guı́a de usuario. DTCC GTR “OTC Lite”

Documents

Transcript of Guı́a de usuario. DTCC GTR “OTC Lite”