Guía de usuario - Anexo

Guía de usuario Guía de usuario - Anexo Iniciativa: Global Trade Repository European Markets Infrastructure Regulation ( EMIR ) Requirements OTC Lite Service - Descripción campo por campo Fecha: 23 de diciembre. 2013 Versión: v1 Estado: Borrador 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 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 OTC Lite Service Descri pción Campo por Campo v1.0 Página 1 de 31

Guía de usuario Document Revision History Date By Version Description 23 December Peter Garratt 1.0 First publication of field by field description OTC Lite Service Descri pción Campo por Campo v1.0 Página 2 de 31

Guía de usuario Tabla de contenidos OTCLite Descripción Campo por Campo. 1.1 Introducción... 4 1.2 Campos de control GTR... 5 1.3 Campos EMIR RTS... 9 1.4 Campos de control GTR & Campos EMIR RTS... 27 OTC Lite Service Descri pción Campo por Campo v1.0 Página 3 de 31

1 OTC Lite Descripción campo por campo 1.1 Introducción El objetivo de este suplemento es describir el propósito y uso de cada uno de los campos que se encuentran en "OTC Lite message template". Nota: Este documento no se considera un asesoramiento legal. Consulte con su departamento legal para consultas específicas relacionadas con el cumplimiento de la normativa. Esto debería ser leído junto con los siguientes documentos. 1. OTC Lite message template (última versión publicada en Document Portal ) 2. OTC Lite User Guide (última versión publicada en Document Portal. Disponible en español) 3. EMIR Draft technical standards (Final Report) - Proyectos de normas técnicas en el marco del Reglamento Europeo n º 648/2012 del Parlamento Europeo y del Consejo, de 4 de julio de 2012 sobre derivados OTC, las Cámaras de Compensación y Repositorios de Datos (publicado en el sitio web de ESMA) 4. ESMA. Preguntas y respuestas - Aplicación del Reglamento Europeo n º 648/2012 relativo a los derivados OTC, las Cámaras de Compensación y Repositorios de Datos (EMIR) (publicado en el sitio web de ESMA) Principios básicos de validación (Explicación más detallada en la guía de usuario) Required field Deben ser rellenados obligatoriamente para que el mensaje sea aceptado por GTR Optional field Si son dejados en blanco, GTR aceptará el mensaje. Sin embargo, puede suceder que algunos campos sean Obligatorios según la normativa de EMIR, y deberán ser rellenados para cumplir completamente dichos requerimientos Conditional field Estos campos se convierten en obligatorios cuando se rellenan otros campos dependientes de estos. Datos generales sobre los campos: 1.2 GTR Control fields Estos campos no son obligatorios según los reguladores, pero muchos de estos campos están catalogados como Required y son necesarios para que GTR procese correctamente el mensaje. 1.3 EMIR RTS fields Estos campos están destacados en la plantilla (columna J ) e indica la referencia dentro de los estándares técnicos de EMIR con el anexo de los campos que son requeridos y relacionados con los números de referencia de la Tabla 1 (Counterparty Data) o la tabla 2 (Common Data.) 1.4 GTR Control Fields & EMIR RTS fields Estos campos se utilizan para mostrar información adicional de los campos que han sido identificados como EMIR RTS Page 4 of 31

1.2 Campos de control GTR 1 Comment Si es rellenado con un asterisco ( * ) al principio, toda la línea será tratada como un comentario. Puede utilizar un asterisco ( * ) en este campo si quiere que toda la línea sea considerada como un comentario. Las líneas consideradas como comentarios en cualquier archivo serán ignoradas y por tanto no serán procesadas por GTR. 2 Version Indica la versión del mensaje sobre la que se ha realizado el envío. GTR soporta únicamente una versión de OTC Lite en el entorno de producción, pero puede darse el caso de que se realicen cambios con el objetivo de soportar otras regulaciones usando la plantilla de OTC Lite. Esto dotará flexibilidad a la plantilla para soportar más de un mensaje (no previsto en el corto plazo) 3 Message Type Indica el tipo de mensaje entrante a GTR. Describe el tipo de mensaje con el que informamos a GTR, necesario para la correcta validación de la plantilla 4 Action Describe el tipo de acción. Requerido por GTR. "New" o "Cancel". Describe la acción que GTR debería tomar en el informe. La única acción en la plantilla soportada en este momento es New 5 Transaction Type Tipo de Transacción Trade, Exit, Backload, PositionCancel. Describe el tipo de mensaje que se envía a GTR. Trade será utilizado en la mayoría de las ocasiones y representa tanto las notificaciones de nuevas transacciones como los eventos LifecycleEvent posteriores. Backload será utilizado para identificar aquellos acuerdos históricos que están todavía abiertos y fueron firmados antes de la fecha de inicio. Exit será utilizado para indicar a GTR que la posición ha sido cerrada completamente, novada, ejercitada o simplemente tiene que ser extraída del sistema para el propósito de información. PositionCancel deberá ser utilizado para eliminar o cancelar la posición del repositorio, incluyendo todos los eventos LifeCycle event con el mismo UTI. Este tipo de transacción solo debe ser usado cuando un UTI ha sido notificado con un error. Page 5 of 31

8 Primary Asset Class Indica cual de las 5 clases de activos estamos notificando. Describe la clasificación del producto que estamos enviando al repositorio. Los únicos valores permitidos serán los 5 activos primarios: Credit, InterestRate, "ForeignExchange", "Equity" o "Commodity 9 Data Submitter Message ID Las empresas que envían los informes deben rellenar un valor diferente en cada mensaje (cada línea en el envío CSV), creada para el correcto seguimiento de los envíos. repetirá este valor en los mensajes de salida, pero no se utilizarán para otro propósito. Este valor tiene que ser único en cada transacción que queremos notificar en el archivo CSV. Sin embargo, pueden repetirse dichos valores con otros de archivos CSV que se envíen al repositorio. 10 As of Date/Time Indica a partir de qué fecha se considerará efectivo el mensaje en el repositorio. Cuando se envía un mensaje "Exit" en un acuerdo, indicará a partir de qué fecha se tiene que procesar dicho cierre. Todas las posiciones enviadas al repositorio con un UTI en particular, incluyendo los LifeCycle Events confirmados en el mismo día se ordenarán según la información rellenada en este campo. El envío con el último valor se considerará la posición resultante al final del día. Page 6 of 31

11 Event ID Party 1 12 Event ID Party 2 13 Additional Repository 1 Prefix 14 Additional Repository 1 Value 15 Reporting Obligation Party 1 16 Reporting Obligation Party 2 37 Submitted For Prefix Un único identificador usado para identificar LifeCycle Events enviados por Trade Party 1. Cuando se utiliza la delegación completa, Trade Party 1 enviará dicha información, al formar parte de los "common data" Por ejemplo, si se realizan 5 terminaciones para una UTI específica, y dichos eventos son enviados al repositorio, cada uno de ellos deberá ser identificado con un único EID. Esto permitirá la identificación de cada evento de forma separada. Un único identificador que será enviado para todos los eventos Lifecycle aplicables por Party 2. Si un UTI ha sido informado en otro repositorio, el LEI u otro valor alternativo de ID del otro repositorio (u otro identificador relevante si se conoce) Usado para enumerar una o más jurisdicciones donde la transacción es notificable. Usado para enumerar una o más jurisdicciones donde la transacción es notificable. Actualmente no es usado en OTC-Lite. Podrá ser usado en un futuro para identificar eventos Lifecycle específicos notificados por Trade Party 1 Actualmente no es usado en OTC-Lite. Podrá usado en un futuro para identificar eventos Lifecycle específicos notificados por Trade Party 2 (bajo el modelo de delegación completa) Identifica el valor cuando se rellena el campo Additional Repository 1 Value" (en la plantilla se encuentran todos los valores aceptados) Un valor opcional que podrá usarse en un futuro para identificar donde la otra parte del acuerdo ha reportado en aquellos casos en los que su contraparte no sea usuario de. Identifica la jurisdicción bajo la que esta obligada a informar Party 1 los distintos acuerdos. Identifica la jurisdicción bajo la que Party 2 está informando sus operaciones (en el caso de que en en el mismo informe se esté informando en nombre de Party 1 y Party 2. "Submitted For Value" = "Both") Identifica el valor del campo Submitted For Value" cuando este es rellenado con un identificador específico de Trade Party 1 (ver Message Template para comprobar los valores aceptados) 38 Submitted For Value Indica en nombre de qué empresa (identificada por el LEI o un DTTC Participant ID válido) se realiza el envío, o BOTH si el envío se realiza por ambas contrapartes. Si no se rellena por defecto será el valor del campo Data Submitter Identifica en nombre de qué empresa se realiza el envío. Puede ser tanto Trade Party 1 como Both ( Both deberá ser rellenado en caso de que Trade Party 1 no tenga obligaciones bajo ESMA pero esté informando en nombre de Trade Party 2) Page 7 of 31

39 Reporting Delegation Model Identifica el modelo de informe que se está utilizando. Identifica el modelo de informe usado para realizar el envío. Independent La empresa envía los Counterparty data y los Common Data en nombre de Trade Party 1. Full Una empresa envía los Counterparty Data y los Common Data de ambas empresas. 44 Execution Agent Party 1 Prefix Identifica el valor en el campo Execution Agent Party 1 Value cuando es rellenado. (Ver Message Template para comprobar los valores soportados) 45 Execution Agent Party 1 Value LEI del agente de ejecución (Gestor de Activos) vinculado a Party 1. Identifica al gestor de activos que tiene el derecho de ver un UTI específico de Trade Party 1. 46 Execution Agent Party 2 Prefix 47 Execution Agent Party 2 Value LEI del agente de ejecución (Gestor de Activos) vinculado a Party 2. Identifica el valor en el campo Execution Agent Party 2 Value cuando es rellenado. (Ver Message Template para comprobar los valores soportados) Identifica al gestor de activos que tiene el derecho de ver un UTI específico de Trade Party 2. 58 Party Region Identifica si Trade Party 1 está domiciliada en el Espacio Economico Común (EEA) o se encuentra fuera. 89 Prior UTI Prefix (repeatable) Identificación de prefijo asociado con cada "prior UTI Value" para asegurar que dicha combinación es única en el repositorio. El campo Prior UTI Prefix & Value se usa cuando se quiere mantener un control para propósitos de auditoría con el UTI notificado anteriormente y que ha sido cerrado (Exit), por ejemplo, un UTI fue notificado y posteriormente se descubre que el UTI es incorrecto: Se cierra la posición original (Exit) y se envía nueva posición del nuevo UTI. En este escenario habrá que rellenar estos campos (89,90) con el UTI anterior. 90 Prior UTI Value (repeatable) Indica el UTI anterior relacionado con la posición actual. Ver Prior UTI Prefix 92 Internal Trade reference Este es un campo opcional que puede ser usado para indicar la referencia interna de la empresa que esta enviando los Common Data Este campo puede ser utilizado para reflejar en GTR una referencia interna del acuerdo, tal como puede estar representada en sus propias anotaciones contables. Este campo no será enviado a los reguladores, pero puede ser usado para propósitos de auditoría interna. Page 8 of 31

117 Lifecycle event Effective Date La fecha efectiva del evento Lifecycle que ha provocado un cambio en una posición abierta. Actualmente este campo es opcional. Aunque no es un campo obligatorio para ESMA, este campo se pueda usar para informar de la fecha efectiva de un evento post trade que ha sido notificado. (en algunas clases de activos esto también es conocido como Agreement Date") 147 Placeholder Campo utilizado como placeholder Ningún dato debe ser rellenado en este campo. Se espera utilizar en un futuro. 156 Trade Link ID Vincula dos acuerdos notificados con diferentes UTIs. Este campo permite a las empresas vincular dos UTIs que han sido notificados a ESMA de forma separada. Por ejemplo, un FX Swap puede notificarse utilizando dos FX Forwards. La industria ha acordado que puede ser notificado utilizando dos UTIs diferentes. El Trade Link ID puede ser rellenado con un identificador interno de la empresa. Este campo no será enviado a los reguladores por el momento. 1.3 Campos EMIR RTS 7 UTI Value 18 Trade Party 1 Value 20 Trade Party 2 Value EMIR FIELD = Trade ID. Este EMIR field es la identificación del acuerdo. Resultará de la combinación Un único UTI (Unique Trade ID) acordado a nivel del Prefix + Value. Este valor será único para cada Europeo, que será proporcionado por las contrapartes. acuerdo y debe ser acordado por las contrapartes antes Este código debe ser generado y acordado con la otra contraparte. de informar a ESMA y usar la metodología acordada por el sector referente a la creación del código UTI (ver la pag. web de ISDA para descargar el documento técnico) LEI (o cualquier account ID proporcionado a SDO) de la primera compañía que realiza la transacción. LEI (o cualquier account ID proporcionado a SDO) de la segunda compañía que realiza la transacción. EMIR field = Counterparty ID. Identifica a "Trade Party 1" en la transacción y deberá ser representado con el LEI de Trade Party 1, aunque otros valores también son aceptados. EMIR field =ID of the other Counterparty ID. Identifica Trade Party 2 en la transacción y deberá ser representado con el LEI de Trade Party 2, aunque otros valores también son aceptados. Page 9 of 31

21 Trade Party 1 Domicile Informa del domicilio de Trade Party 1. EMIR field = Domicilio de la contraparte. Detalla la información de la sede social. Dirección completa, ciudad y país de la empresa (Trade Party 1) 22 Trade Party 2 Domicile Informa del domicilio de Trade Party 2. Únicamente se rellena cuando se notifica en nombre de ambas entidades. EMIR field = Domicilio de la contraparte. Detalla la información de la sede social. Dirección completa, ciudad y país de la empresa (Trade Party 2) 25 Trade Party 1 Corporate Sector Sector empresarial de Trade Party 1. EMIR field = Sector empresarial de la empresa. Describe la naturaleza de las actividades de la contraparte (Trade Party 1). EMIR permite una lista enumerada de valores (ver message template ). Este campo puede ser dejado en blanco cuando Trade Party 1 es una entidad no financiera bajo EMIR. 26 Trade Party 2 Corporate Sector Sector empresarial de Trade Party 2. Aplicable cuándo se informa en nombre de ambas contrapartes. EMIR field = Sector empresarial de la empresa. Describe la naturaleza de las actividades de la contraparte (Trade Party 2). EMIR permite una lista enumerada de valores (ver message template ). Este campo puede ser dejado en blanco cuando Trade Party 2 es una entidad no financiera bajo EMIR. 27 Trade Party 1 Financial Entity Jurisdiction 28 Trade Party 1 Non-financial Entity Jurisdiction Indica si la empresa es una contraparte financiera según el Articulo 2(8,9) de la Regulación Europea (EU) Nº 648/2012 EMIR field = Naturaleza financiera o no financiera de la contraparte. Cuando Party 1 es una entidad financiera, este campo se aplica y debe ser enviado a ESMA según la normativa EMIR. EMIR field = Naturaleza financiera o no financiera de la EMIR field - Indica si la empresa es una contraparte NO contraparte. financiera según el Articulo 2(8,9) de la Regulación Cuando Party 1 es una entidad NO financiera, este Europea (EU) Nº 648/2012 campo se aplica y debe ser enviado a ESMA según la normativa EMIR Page 10 of 31

29 Trade Party 2 Financial Entity Jurisdiction EMIR field - Indica si la empresa (Trade Party 2) es una contraparte financiera o NO financiera según el Articulo 2(8,9) de la Regulación Europea (EU) Nº 648/2012 Aplicable cuando se informa en nombre de ambas contrapartes. EMIR field = Naturaleza financiera o no financiera de la contraparte. Cuando Party 2 es una entidad financiera, este campo se aplica y debe ser enviado a ESMA según la normativa EMIR 30 Trade Party 2 Non-financial Entity Jurisdiction 32 Broker Id Party 1 Value 34 Broker Id Party 2 Value 36 Data Submitter Value Aplicable cuando se informa en nombre de ambas Indica si la empresa (Trade Party 2) es una contraparte contrapartes. financiera o NO financiera según el Articulo 2(8,9) de la EMIR field = Naturaleza financiera o no financiera de la Regulación Europea (EU) Nº 648/2012 contraparte. Cuando Party 2 es una entidad NO financiera, este campo se aplica y debe ser enviado a ESMA según la normativa EMIR Indica el Broker que ha utilizado Trade Party 1 (si corresponde) Conditional: Si "Trading capacity Party 1"es "Agent" entonces Required. En caso contrario Optional Indica el Broker que ha utilizado Trade Party 2 (si corresponde) Identifica la empresa que envía los datos. Puede ser la empresa que ha realizado la transacción, una cámara de compensación, u otro agente legítimo en su nombre. EMIR field = Broker ID. Si Trade Party 1 usa un bróker que actúa como un intermediario entonces tiene que ser rellenado con la identificación de dicho bróker, usando un LEI, pre-lei, SwiftBIC o en el caso de uno individual, el código de cliente. Aplicable en el caso de informar en nombre de ambas contrapartes. EMIR field = Broker ID. Si Trade Party 2 usa un bróker que actúa como un intermediario entonces tiene que ser rellenado con la identificación de dicho bróker, usando un LEI, pre-lei, SwiftBIC o en el caso de uno individual, el código de cliente. Este código puede ser el mismo u otro diferente del bróker usado por Trade Party 1. EMIR field = Reporting entity ID. Identifica la entidad que está enviando los datos del acuerdo. Puede ser Trade Party 1, Trade Party 2, o una third party que esta registrada como participante en. 41 Clearing Broker Party 1 Value 43 Clearing Broker Party 2 Value LEI del Clearing Broker / Compensación de Futuros usado por Party 1 (si corresponde) LEI del Clearing Broker / Compensación de Futuros usado por Party 2 (si corresponde) Page 11 of 31 EMIR Field = Clearing member ID. Si el acuerdo ha sido compensado por el Clearing Broker para Trade Party 1, tiene que ser identificado. Aplicable en el caso de informar en nombre de ambas contrapartes. EMIR Field = Clearing member ID. Si el acuerdo ha sido compensado por el Clearing Broker para Trade Party 2, tiene que ser identificado.

49 Beneficiary ID Party 1 Value Este valor, combinado con el prefijo identificará la empresa beneficiaria del acuerdo (ej. LEI, DTTC ID) Conditional: Si "Trading capacity Party 1"es "Agent" entonces Required. En caso contrario Optional Descripción: EMIR field = Beneficiary ID. La parte que sustenta los derechos y obligaciones derivadas del contrato. Donde la transacción es ejecutada por medio de otra estructura, como un fideicomiso (Trust) o un fondo, que representa a un número de beneficiarios, debiendo el beneficiario estar identificado como parte de esta estructura. Si el beneficiario del contrato no es una contraparte en la transacción, Trade Party 1 tiene que identificar al beneficiario usando su LEI, pre-lei, SwiftBic o en el caso de un individuo su código de cliente. Si el beneficiario es el mismo que Trade Party 1 entonces habrá que rellenar este campo con los detalles de Trade Party 1. 51 Beneficiary ID Party 2 Value Este valor, combinado con el prefijo identificará la empresa beneficiaria del acuerdo (ej. LEI, DTTC ID) Solo aplicable cuando se informa en nombre de ambas contrapartes. EMIR field = Beneficiary ID. La parte que sustenta los derechos y obligaciones derivadas del contrato. Donde la transacción es ejecutada por medio de otra estructura, como un fideicomiso (Trust) o un fondo, que representa a un número de beneficiarios, debiendo el beneficiario estar identificado como parte de esta estructura. Si el beneficiario del contrato no es una contraparte en la transacción, Trade Party 2 tiene que identificar al beneficiario usando su LEI, pre-lei, SwiftBic o en el caso de un individuo su código de cliente. Si el beneficiario es el mismo que Trade Party 1 entonces habrá que rellenar este campo con los detalles de Trade Party 2. 52 Trading capacity Party 1 Identifica si Party 1 ha celebrado un contrato en calidad de principal por cuenta propia (en nombre propio o en nombre de un cliente) o como un agente para la cuenta y en nombre del cliente. Aplicable cuando se informa en nombre de ambas contrapartes. EMIR field = Capacidad comercial. Identifica si Trade Party 1 ha celebrado el contrato en calidad de principal en su propia cuenta (en nombre propio o en nombre de un cliente) o como un agente para la cuenta y en nombre de un cliente. Page 12 of 31

53 Trading capacity Party 2 Identifica si Party 2 ha celebrado un contrato en calidad de principal por cuenta propia (en nombre propio o en nombre de un cliente) o como un agente para la cuenta y en nombre del cliente. Aplicable cuando se informa en nombre de ambas contrapartes. EMIR field = Capacidad comercial. Identifica si Trade Party 2 ha celebrado el contrato en calidad de principal en su propia cuenta (en nombre propio o en nombre de un cliente) o como un agente para la cuenta y en nombre de un cliente. 55 Buyer Value (Party 1) Este valor junto con el prefijo identifica el comprador de un acuerdo o posición desde la perspectiva de Trade Party 1 (ej. LEI, ID). Conditional: Si Leg 1 Payer o Leg 2 Payer es rellenado entonces es un campo Optional. En caso contrario, es Required EMIR field = Counterparty side. GTR derivará las posiciones de las contrapartes a partir de este campo. Siempre debe ser rellenado desde la perspectiva de Trade Party1. Por ejemplo, si Trade Party 1 está comprando una opción call a Trade Party 2, entonces este campo deberá ser rellenado con los datos de Trade Party 1 (al ser el comprador). En algunos acuerdos de tipos de interés y FX el comprador no está determinado. La mejor práctica en este escenario será rellenar los campos Leg 1 Payer y Leg 2 Payer 57 Buyer Value (Party 2) El valor combinado con el prefijo identificará el comprador del acuerdo o posición desde la perpectiva de Trade Party 2 (Ej. LEI, ID) cuando la entidad que envía la información ( Data Submitter ) no es una de las contrapartes del acuerdo y se está informando en nombre de ambas contrapartes ( Submitted for = Both ) Aplicable cuando se informa en nombre de ambas contrapartes. EMIR = Counterparty Side. GTR derivará las posiciones de las contrapartes a partir de este campo. Siempre debe ser rellenado desde la perspectiva de Trade Party 2. Ejemplo, Trade Party 1 está comprando una opción Call a Trade Party 2. Entonces este campo debe identificar a Trade Party 1 como el comprador. Si este campo está rellenado, siempre debe tener el mismo valor que Buyer Value (Party 1) 59 Counterparty Region Para Emir: Indica si la otra entidad está domiciliada fuera del Espacio Económico Europeo (EEA. Economic European Area) EMIR field = Contrato with non-eea counterparty. Identifica si la contraparte en el acuerdo (Trade Party 2) se encuentra en el Espacio Económico Europeo o se encuentra fuera. Page 13 of 31

60 Directly linked to commercial activity or treasury financing Party 1 61 Directly linked to commercial activity or treasury financing Party 2 EMIR field = Directly linked to commercial activity or Informa si el contrato es objetivamente cuantificable treasury financing. Información si el contrato es como consecuencia directa de una actividad comercial objetivamente cuantificable como consecuencia directa o actividades relacionadas con la financiación de la de una actividad comercial o actividades relacionadas actividad comercial, según lo dispuesto en el artículo con la financiación de la actividad comercial (Trade 10(3) de la regulación (EU) Nº 648/2012. Este campo Party 1), según lo dispuesto en el artículo 10(3) de la deberá ser dejado en blanco en caso de que la regulación (EU) Nº 648/2012. Este campo deberá ser contraparte que informa de la transacción sea una dejado en blanco en caso de que la contraparte (Trade contraparte financiera, según lo dispuesto en el Art. 2 Party 1) que informa de la transacción sea una (8) de la Regulación (EU) No 648/2012 contraparte financiera, según lo dispuesto en el Art. 2 (8) de la Regulación (EU) No 648/2012 Informa si el contrato es objetivamente cuantificable como consecuencia directa de una actividad comercial o actividades relacionadas con la financiación de la actividad comercial, según lo dispuesto en el artículo 10(3) de la regulación (EU) Nº 648/2012. Este campo deberá ser dejado en blanco en caso de que la contraparte que informa de la transacción sea una contraparte financiera, según lo dispuesto en el Art. 2 (8) de la Regulación (EU) No 648/2012 Aplicable en el caso de informar en nombre de ambas contrapartes. EMIR field = Directly linked to commercial activity or treasury financing. Información si el contrato es objetivamente cuantificable como consecuencia directa de una actividad comercial o actividades relacionadas con la financiación de la actividad comercial (Trade Party 2), según lo dispuesto en el artículo 10(3) de la regulación (EU) Nº 648/2012. Este campo deberá ser dejado en blanco en caso de que la contraparte (Trade Party 2) que informa de la transacción sea una contraparte financiera, según lo dispuesto en el Art. 2 (8) de la Regulación (EU) No 648/2012 62 MTM Value Party 1 Valor calculado de MTM. EMIR field = Market to market value of contract. Valoración Mark to Market o valoración mark to model, aplicable bajo el Art. 11(2) de la regulación (EC) Nº 648/2012. Esta es la valoración referente a Trade Party 1 por su posición en el acuerdo 63 MTM Value Party 2 Valor MTM generado por Party 2 Aplicable cuando se informa en nombre de ambas contrapartes. : EMIR field = Market to market value of contract. Valoración Mark to Market o valoración mark to model, aplicable bajo el Art. 11(2) de la regulación (EC) Nº 648/2012. Esta es la valoración referente a Trade Party 2 por su posición en el acuerdo. Page 14 of 31

64 MTM Value CCP Para distinguir cuando una contraparte esta enviando los datos de valoración usando una Cámara de Compensación EMIR field = Mark to market value of contract. Valoración mark to market o Valoración mark to model aplicable bajo el Art. 11(2) de la regulación (EC) Nº 648/2012. Esta es la valoración proporcionada por la Cámara de Compensación cuando un acuerdo ha sido compensado. Puede ser enviado por la contraparte del acuerdo Trade Party 1 y tendrá preferencia cuando ha sido completado 65 MTM Currency Party 1 Divisa local del valor MTM 66 MTM Currency Party 2 Divisa en la que el valor MTM es enviado por Party 2 EMIR field = Divisa del valor mark to market que aparece en el contrato. Divisa de valoración rellenada por Trade Party 1. Aplicable cuando se informa en nombre de ambas contrapartes. EMIR field = Currency of the mark to market value of contract. La divisa de valoración rellenada por Trade Party 1. 67 MTM Currency CCP 68 Valuation Datetime Party 1 Divisa en la que el valor MTM es enviado por la Cámara de Compensación. Fecha y hora de la valoración. Tiempo UTC (Tiempo Universal Coordinado) EMIR field = Divisa de la valoración mark to market en el contrato. La divisa de la valoración rellenada en el campo MTM Value CCP EMIR field = Valuation Date and Valuation Time. Identifica la fecha y hora de la valoración proporcionada por Trade Party 1. Esta fecha/hora se utiliza para los dos campos separados descritos en EMIR RTS. Tiene que seguir el formato UTC. 69 Valuation Datetime Party 2 Fecha y hora de la valoración generada por Party 2. Tiempo UTC (Tiempo Universal Coordinado) Aplicable cuando se informa en nombre de ambas contrapartes. EMIR field = Valuation Date and Valuation Time. Identifica la fecha y hora de la valoración proporcionada por Trade Party 2. Esta fecha/hora se utiliza para los dos campos separados descritos en EMIR RTS. Tiene que seguir el formato UTC. 70 Valuation Datetime CCP Fecha y hora de la valoración generada por la Cámara de Compensación. Tiempo UTC. EMIR field = Valuation Date and Valuation Time. Identifica la Fecha y Hora de la valoración proporcionada en MTM Value CCP. Esta fecha/hora se utiliza para los dos campos separados descritos en EMIR RTS. Tiene que seguir el formato UTC. Page 15 of 31

71 Valuation Type Party 1 Referencia del modelo utilizado para calcular la valoración diaria por PARTY 1 EMIR field = Valuation type. Identifica si la valoración proporcionada por Trade Party 1 se realiza mark to market o mark to model 72 Valuation Type Party 2 Referencia del modelo utilizado para calcular la valoración diaria por PARTY 2 Aplicable cuando se informa en nombre de ambas contrapartes. EMIR field = Valuation type. Identifica si la valoración proporcionada por Trade Party 2 se realiza mark to market o mark to model 73 Valuation Type CCP Referencia del modelo utilizado por la Cámara de Compensación para calcular la valoración diaria. EMIR field = Valuation type. Identifica si la valoración proporcionada en MTM Value CCP ha sido realizada por medio de mark o market o mark to model 74 Collateralized Party 1 Indica si el contrato ha sido colateralizado y cómo. 75 Collateralized Party 2 Indica si el contrato ha sido colateralizado y cómo, desde la perspectiva de Trade Party 2. EMIR field = Collateralisation. Identifica si el acuerdo esta colateralizado y en que media desde la perspectiva de Trade Party 1. Aplicable cuando se informa en nombre de ambas contrapartes. EMIR field = Collateralisation. Identifica si el acuerdo está colateralizado y en que medida desde la perspectiva de Trade Party 2. 76 Collateral portfolio code Party 1 Si la garantía ha sido enviada sobre una base de cartera, dicha cartera debe estar identificada bajo un código único determinado por la contraparte EMIR field = Collateral portfolio code. Si la garantía ha sido enviada sobre una base de cartera, dicha cartera debe estar identificada bajo un único código terminado por la contraparte (Trade Party 1). La indicación del código de la cartera de garantía indica que la colateralización se ha realizado en base a la cartera 77 Collateral portfolio code Party 2 Si la garantía ha sido enviada sobre una base de cartera, dicha cartera debe estar identificada bajo un código único determinado por Party 2. Aplicable cuando se informa en nombre de ambas contrapartes. EMIR field = Collateral portfolio code. Si la garantía ha sido enviada sobre una base de cartera, dicha cartera debe estar identificada bajo un único código terminado por la contraparte (Trade Party 2). La indicación del código de la cartera de garantía indica que la colateralización se ha realizado en base a la cartera. Page 16 of 31

78 Value of the collateral Party 1 (repeatable values) Valor de la garantía que recibe Party 1 de la otra contraparte. Cuando la garantía es recibida en base a una cartera, este campo deberá incluir el valor de la todas las garantías que incluye la cartera. EMIR field = value of the colateral. Valor de la garantía recibida por Trade Party 1 por la otra contraparte. Cuando la garantía es recibida en base a la cartera, este valor deberá incluir el valor de toda la garantía recibida por la cartera. Esta campo se podrá repetir para indicar valores múltiples cuando la garantía esta reflejada en más de una moneda 79 Value of the collateral Party 2 (repeatable values) Valor de la garantía que recibe Party 2 de la otra contraparte. Cuando la garantía es recibida en base a una cartera, este campo deberá incluir el valor de la todas las garantías que incluye la cartera. Aplicable cuando se informa en nombre de ambas contrapartes. EMIR field = value of the collateral. Valor de la garantía recibida por Trade Party 2 por la otra contraparte. Cuando la garantía es recibida en base a cartera, este valor deberá incluir el valor de toda la garantía recibida por la cartera. Esta campo se podrá repetir para indicar valores múltiples cuando la garantía esta reflejada en más de una moneda. 80 Currency of the collateral value Party 1 (repeatable values) Especifica la divisa del valor de la garantía de Party 1. Para adaptarse a la posibilidad de que una empresa envíe la información al repositorio en nombre de ambas contrapartes, los campos relacionados con "Counterparty Data" están incluidos dos veces. Una para para Party 1 y la segunda para Party 2. Consulte el campo relacionado con "Party 2" cuando quiera reportar en nombre de ambas compañías. EMIR field = Currency of the collateral value. Especifica la divisa del campo "Value of the Collateral" de Trade Party 1. Este campo acepta varios valores para que sea posible incluir varias divisas. Todos los valores estarán asociados con el valor rellenado en el campo "Value of the collateral Party 1" 81 Currency of the collateral value Party 2 (repeatable values) Especifica la divisa en la que se encuentra la garantía por Party 2 EMIR field = Currency of the collateral value. Especifica la divisa del campo "Value of the Collateral" de Trade Party 2. Este campo acepta varios valores para que sea posible incluir varias divisas. Todos los valores estarán asociados con el valor rellenado en el campo "Value of the collateral Party 2" Page 17 of 31

82 Product ID Prefix 1 Indicación de la taxonomía usada EMIR field = Taxonomy used. Indica cuál taxonomía se ha utilizado para reportar los datos de acuerdo. El GTR acepta la taxonomía ISDA, por lo que el valor ISDA debe ser rellenado en este campo. El GTR derivará los valores de taxonomía provisional para ser reportados a los reguladores, basándose en el valor de la taxonomía ISDA, rellenado en el siguiente campo "Product ID Value 1". 83 Product ID Value 1 Especifica el valor de la taxonomía usada. EMIR field = Product ID 1. Indica el valor de la taxonomía ISDA. Antes que sea apoyada otra identificación de los derivados OTC, el GTR derivará los valores de taxonomía interna ( E ) para ser reportados a los reguladores basándose en el valor de la taxonomía ISDA rellenado en este campo (consulten la plantilla para ver la lista completa de los valores aceptados de la taxonomía ISDA). 84 Product ID Prefix 2 Indica la taxonomía utilizada 85 Product ID Value 2 Especifica el segundo valor de la taxonomía utilizada. EMIR field = Taxonomy used. Cuando la taxonomía ISDA es utilizada en el campo "Product ID value 1" o una UPI ha sido rellenada en los campos anteriores, este campo puede quedar en blanco. Sin embargo, cuando en los campos de Product ID 1 se ha rellenado una taxonomía interna (es decir, el valor en Product ID Prefix 1 es "E"), este campo tiene que ser rellenado con "E" y el campo "Product ID Value 2" tiene que rellenarse con un valor relevante prescrito por EMIR. EMIR field = Product ID 2. Cuando la taxonomía ISDA es utilizada en el campo "Product ID value 1" o una UPI ha sido rellenada en los campos anteriores, este campo puede quedar en blanco. Sin embargo, cuando en los campos de Product ID 1 se ha rellenado una taxonomía interna (es decir, el valor en Product ID Prefix 1 es "E"), este campo tiene que ser rellenado con un valor relevante prescrito por EMIR (véanse la plantilla para la lista de valores apoyados). La mejor práctica para los acuerdos OTC es usar la taxonomía ISDA, como se ha descrito más arriba. Page 18 of 31

86 Underlying Asset (repeatable up to 2 times semi-colon separated) EMIR field = Underlying. El activo subyacente puede estar identificado por un único identificador que este El activo subyacente, activo de referencia u obligación asociado a dicho activo subtacente. En el caso de cestas de referencia de pagos de las obligaciones de una o índices, se deberá utilizar una referencia de dicha Trade Party bajo la transacción reportable. El activo cesta o índice cuando un identificador único no pueda subyacente puede ser una referencia al precio, índice, ser proporcionado. EL GTR puede aceptar más tipos obligación, una mercancía o producto básico identificadores de los descritos en EMIR, sin embargo, el (commodities) con entrega a término, contratos repositorio únicamente reportará un valor en este futuros o cualquier otro instrumento acordado por las campo si es uno de los siguientes: ISIN, UPI, LEI o precontrapartes a una transacción reportable. LEI, Basket Index. El identificador en este campo está descrito en el campo 150 "Underlying Assest Identifier (EMIR - El activo subyacente puede estar identificado Type". Cuando se proporciona un RED ID (Credit por un único identificador que esté asociado a dicho derivatives) or un RIC (Equity derivatives) y el activo subtacente. En el caso de cestar o índices, se Repositorio puede derivar el ISIN a partir de la deberá utilizar una referencia de dicha cesta o índice información que se ha proporcionado, entonces se cuando un identificador único no pueda ser reportará el ISIN. La mejor práctica siempre será proporcionado.) proporcionar el ISIN en caso de que sea posible. El consenso general del sector indica que contratos Interest Rate Swap - el activo subyacente puede estar de"rates" (con la excepción de las opciones de Deuda y asociado con leg 1 y leg 2 (separado por punto y coma) activos subyacentes de bonos), "Forex" y "Commodities" no tienen un activo subyacente apropiado en este campo. 87 Notional Currency/Units (repeatable up to 2 times semi-colon separated) Indicación del tipo de la divisa del importe nocional (notional amount). El campo puede contener dos valores: uno por cada de los Legs. EMIR field = Notional currency 1 y Notional currency 2. Identifica la divisa del importe nocional (campo Notional Amount); donde hay dos legs de un acuerdo (en particular para "Rates"), hay que rellenar los dos legs. En caso de Forex, hay que rellenar una divisa que describa el importe nocional, siendo la segunda divisa rellenada en el campo 127 "Currency 2". Para acuerdos de Commodities hay que rellenar la unidad que describe el importe nocional indicado. 88 Settlement Currency (repeatable up to 2 times semi-colon separated) La moneda utilizada para la transacción. EMIR field = Deliverable currency. Indica la divisa utilizada para la transacción. Se puede proporcionar para los dos legs 1 y 2, en casos relevantes. Page 19 of 31

91 Transaction Reference Number Un número único de identificación de la transacción proporcionado por la entidad que envía los datos o por una third party que reporta en nombre de la entidad. EMIR field = Transaction reference number. Puede consultar las preguntas frecuentes de ESMA (el documento ESMA Q&A) para una descripción de valor supuesto de este campo. EMIR describe este campo como un número único de identificación de la transacción proporcionado por la entidad que envía los datos o por una third party que reporta en nombre de la entidad. 94 Execution Venue Value 95 Price Notation - Price 96 Price Notation - Price Type Indica el lugar de la ejecución de una transación swap con obligación de ser reportada. EMIR field = Venue of execution. Una indicación del lugar de la ejecución de una transación swap con obligación de ser reportada. Para los derivativos OTC este campo debe ser rellenado con "XXXX". El precio, el rendimiento, spread o ratio, dependiendo EMIR field = Price / rate. El precio del acuerdo OTC y del tipo de producto. El precio debe excluir comisiones debe excluir comisiones e intereses devengados, si e intereses devengados, si son presentes. están presentes. EMIR field = Price notation. Describe la manera en la Describe cómo interpretar el precio rellenado en "Price que el precio es representado. Es decir, describe el valor Notation - Price" rellenado en el campo 95 "Price Notation - Price". 97 Notional Amount (repeatable up to 2 times semi-colon separated) 98 Price Multiplier El valor original del contrato (es posible incluir más de un importe nocional en un acuerdo) El número de unidades del instrumento financiero que están incluidas en un lote ejecutado; por ejemplo, el número de derivados representado por un contrato. EMIR field = Notional amount. El valor original del contrato. Puede ser rellenado con los dos valores del leg 1 y leg 2 cuando sea aplicable. El GTR requiere que este campo sea actualizado con el importe nocional resultante que sigue cada evento posterior a la operación (evento lifecycle). EMIR field = Price Multiplier. El número de unidades del instrumento financiero que están incluidas en un lote ejecutado; por ejemplo, el número de derivados representados en el contrato. 99 Quantity El número de contratos en el reporte cuando más de un contrato derivativo sea reportado. EMIR field = Quantity. El número de contratos incluidos en el acuerdo en aquellos casos en los que más de un contrato derivativo es adquirido. La mejor práctica para derivados OTC de Rates, Credit y Forex en este campo es 1. Para Equities y Commodities lo recomendado es rellenar el número de Acciones subyacentes / Opciones financieras / unidades que han sido fijadas en el contrato. Page 20 of 31