K aupparaportoinnin konekielisen tietojenvälityksen kuvaus

1 (43) K aupparaportoinnin konekielisen tietojenvälityksen kuvaus

2 (43) Sisällysluettelo 1 Johdanto... 3 2 Tietojen toimittaminen Finanssivalvonnalle... 3 2.1 Kaupparaporttitiedostojen toimittaminen... 3 3 Raportointitavat... 4 3.1 Valmiin tiedoston toimittaminen tiedostolatauksena... 4 3.2 Tietojen syöttö web-lomakkeella... 4 3.3 FTP-tiedostosiirto... 5 4 Kaupparaporttitiedoston kuvaus... 5 4.1 Tapahtumien (transaction) tyypit... 5 4.2 XML-skeema... 6 4.2.1 Isin tai AII-kaupat... 6 4.2.2 OTC -johdannaiskaupat... 6 4.3 Kaupparaporttitiedoston nimi... 6 4.4 Pakatut tiedostot... 7 4.5 Tiedoston koko... 7 4.6 Tietuemuoto... 8 4.6.1 ISIN ja AII -kaupat... 8 4.6.2 OTC johdannaiskaupat... 20 4.7 Tiedoston tarkistussäännöt... 33 5 Kuittaustiedoston kuvaus... 33 5.1 Kuittaustiedoston nimi... 2 5.2 Kuittaustiedoston otsikko... 2 5.3 Kuittaustiedoston runko... 4 6 Esimerkkejä... 6 6.1 Kauppatapahtuma... 6 6.2 Peruutustapahtuma... 6 6.3 Kaupparaporttitiedosto... 7 6.4 OTC -johdannaiskauppatiedosto... 10 6.5 Kuittaustiedosto... 11

3 (43) 1 Johdanto 2 Tietojen toimittaminen Finanssivalvonnalle Kaupparaportoinnin konekielisen tiedonvälityksen kuvausta sovelletaan kaupparaportointia koskeviin määräyksiin ja ohjeisiin liittyvän kaupparaporttitiedoston tuottamiseen ja toimittamiseen Finanssivalvonnalle. Kaupparaportointia koskevien määräyksien ja ohjeiden soveltamiseen liittyviä raportointiesimerkkejä löytyy osoitteesta http://www.finanssivalvonta.fi/fi/raportointi/raportointisovellukset/kauppar aportointi/pages/default.aspx Finanssivalvonta käyttää kaupparaportointiin liittyvien tietojen keruussa apuna ns. TYVI-operaattoria. TYVI-operaattori on yritysten ja viranomaisten välillä toimiva operaattori, joka on erikoistunut teknisten tiedonkeruuja muunnostehtävien toteuttamiseen. TYVI tulee sanoista "Tietovirrat Yrityksiltä VIranomaisille". Finanssivalvonnan käyttämä TYVI-operaattori on Itella Information Oy. TYVI-operaattorin tarjoamaa raportointipalvelua kutsutaan jatkossa TYVI-palveluksi. Raportoija voi olla itse raportointivelvollinen yritys tai tämän puolesta toimiva ns. tekninen raportoija. Raportoijaksi kutsutaan tässä dokumentissa sitä tahoa, joka toimittaa raportin Finanssivalvonnalle. Raportoinnissa tarvittavan yrityskohtaisen BIC-koodin saa kuluitta SWIF- Tiltä. Sen voi tilata täyttämällä SWIFTin www-sivuilla olevan lomakkeen osoitteessa https://www2.swift.com/formz/public/index.cfm?form_config=public_bic1re quest&form_title= Request an 8 characters BIC for a non SWIFT User&form_roadmap= http://www.swift.com/index.cfm?item_id=43685 2.1 Kaupparaporttitiedostojen toimittaminen Kaupparaportointiin liittyvät tiedostot tulee muodostaa tämän dokumentin mukaisten tietuekuvausten mukaisesti. Jokaisesta vastaanotetusta tiedostosta TYVI-operaattori tai Finanssivalvonta lähettää raportoijalle kuittaustiedoston TYVI-palvelun kautta. Raportoija toimittaa TYVI-operaattorille kutakin pörssipäivää kohti yhden tai useamman kaupparaporttitiedoston raportoitavista tapahtumista. TYVIoperaattori tarkistaa raportoijan lähettämien tiedostojen teknisen eheyden ja tietuemuodon oikeellisuuden ja välittää eheäksi todetut kaupparaporttitiedostot Finanssivalvonnalle. Kaupparaporttitiedostoissa tässä vaiheessa havaituista virheistä annetaan välitön palaute raportoijalle, joka voi ryhtyä toimenpiteisiin virheiden korjaamiseksi ja kaupparaporttitiedoston uudelleen lähettämiseksi.

4 (43) 3 Raportointitavat Raportoijalle on kaupparaportointiin liittyvien tietojen raportointia varten tarjolla kolme raportointitapaa Tavat ovat Tiedoston toimittaminen tiedostolatauksena (http upload) Tietojen syöttö web-lomakkeella (http-protokolla) ftp-tiedostosiirto (file transfer protocol) Kahdessa ensin mainitussa tavassa tiedostot toimitetaan TYVIoperaattorin tarjoaman web-palvelun avulla ja siirtotapana käytetään https-protokollaa. Edellä mainittujen raportointitapojen lisäksi mahdollisista muista tiedonvälitystavoista raportoijan tulee sopia TYVI-operaattorin kanssa. Tällöin raportoija vastaa itse syntyvistä kustannuksista. 3.1 Valmiin tiedoston toimittaminen tiedostolatauksena 3.2 Tietojen syöttö web-lomakkeella Raportoija voi toimittaa valmiin kaupparaporttitiedoston kirjautumalla TYVI-operaattorin webpalveluun ja lähettämällä tiedoston palvelun kautta tiedostolatauksena (http upload). Web-palveluun kirjautuminen vaatii käyttäjätunnuksen ja salasanan, jotka raportoija tilaa täyttämällä AKVAraportoijaksi rekisteröitymisilmoituksen ja lähettämällä sen Finanssivalvontaan sähköpostitse lomakkeessa mainittuun sähköpostiosoitteeseen. Finanssivalvonta rekisteröi raportointivelvollisen tiedot ja välittää ne edelleen TYVI-operaattorille, joka ottaa yhteyttä ilmoituksen lähettäjään ja sopii raportointia varten tarvittavien tunnusten muodostamisesta ja toimittamisesta. Rekisteröitymisilmoituslomake löytyy osoitteesta http://www.finanssivalvonta.fi/fi/raportointi/raportointisovellukset/kauppar aportointi/pages/default.aspx Siirtoyhteyden suojaamiseksi käytetään SSL-protokollaa. Yksittäiset kauppatapahtumat tai kauppatapahtumien peruutustapahtumat voidaan raportoida syöttämällä ne web-lomakkeelle TYVI-operaattorin web-palvelussa. Web-palveluun kirjautuminen vaatii käyttäjätunnuksen ja salasanan, jotka raportoija tilaa täyttämällä AKVA-raportoijaksi rekisteröitymisilmoituksen ja lähettämällä sen sähköpostitse lomakkeessa mainittuun sähköpostiosoitteeseen. Finanssivalvonta rekisteröi raportointivelvollisen tiedot ja välittää ne edelleen TYVI-operaattorille, joka ottaa yhteyttä ilmoituksen lähettäjään ja sopii raportointia varten tarvittavien tunnusten muodostamisesta ja toimittamisesta. Rekisteröitymisilmoituslomake löytyy osoitteesta http://www.finanssivalvonta.fi/fi/raportointi/raportointisovellukset/kauppar aportointi/pages/default.aspx

5 (43) Siirtoyhteyden suojaamiseksi käytetään SSL-protokollaa. 3.3 FTP-tiedostosiirto 4 Kaupparaporttitiedoston kuvaus 4.1 Tapahtumien (transaction) tyypit FTP-tiedonsiirtoa käytettäessä raportoija ja TYVI-operaattori muodostavat TYVI-palvelun ja raportoijan oman järjestelmän välille VPN (Virtual Private Network) yhteyden, jota pitkin kaupparaporttitiedoston siirto suoritetaan FTP protokollalla. TYVI-operaattori antaa raportoijalle palvelun käyttöä varten ns. ftp-tunnuksen (käyttäjätunnus ja salasana). Raportoija tilaa tunnuksen täyttämällä AKVA-raportoijaksi rekisteröitymisilmoituksen ja lähettämällä sen sähköpostitse lomakkeessa mainittuun sähköpostiosoitteeseen. Finanssivalvonta rekisteröi raportointivelvollisen tiedot ja välittää ne edelleen TYVI-operaattorille, joka ottaa yhteyttä ilmoituksen lähettäjään ja sopii raportointia varten tarvittavien tunnusten muodostamisesta ja toimittamisesta. Rekisteröitymisilmoituslomake löytyy osoitteesta http://www.finanssivalvonta.fi/fi/raportointi/raportointisovellukset/kauppar aportointi/pages/default.aspx Tarkemmat ohjeet tiedonsiirtoon on kuvattu dokumentissa "RAJAPINTAKUVAUS, Itella Customer Connection, Rahoitustarkastus", jonka raportoija saa TYVI-operaattorilta. Kaupparaporttitiedostot ovat XML-tiedostoja ja koostuvat kauppatapahtumista ja peruutustapahtumista. OTC -johdannaiskauppatapahtumia sisältävät tiedostot noudattavat tiedostomuodon, tiedostonimen, tiedostotyypin ja tiedostokoon suhteen seuraavia yleisperiaatteita mutta niillä on oma skeema ja tietuemuoto. Kaupparaporttitiedoston on noudatettava annettuja vaatimuksia koskien Tiedostomuotoa Tiedostonimeä Tiedostotyyppiä (XML tai ZIP) ja Tiedostokokoa. Kaupparaporttitiedoston merkistö on UTF-8. Kaupparaportissa voi olla kahden tyyppisiä tapahtumia: 1. Transaction Record Info kauppatapahtuma 2. Cancellation Transaction Type peruutustapahtuma "Transaction reference number" ja "Transaction record info type" (tapahtuman tyyppi) yksilöivät tapahtuman. Samassa tiedostossa voi olla kaksi

6 (43) tapahtumaa, joilla on sama Transaction reference number -kentän arvo, jos toisen tapahtuman tyyppi on "Transaction" ja toisen "Cancellation- Transaction". Jos samassa kaupparaporttitiedostossa raportoidaan sekä kauppatapahtuma että sen peruutus, tulee peruutustapahtuman olla peruutustapahtumassa viitatun kauppatapahtuman jälkeen. 4.2 XML-skeema 4.2.1 Isin tai AII-kaupat 4.2.2 OTC -johdannaiskaupat 4.3 Kaupparaporttitiedoston nimi Kaupparaporttitiedoston XML-skeema on kuvattu tiedostossa http://www.finanssivalvonta.fi/fi/saantely/maarayskokoelma/rahoitussekto ri/ra_raportointi/documents/transactionreport.xml. OTC -johdannaiskaupparaporttitiedoston skeema muodostuu seuraavista toisiinsa liittyvistä skeematiedostoista: http://www.finanssivalvonta.fi/fi/saantely/maarayskokoelma/rahoitussekto ri/ra_raportointi/documents/otctransactionreport.xml http://www.finanssivalvonta.fi/fi/saantely/maarayskokoelma/rahoitussekto ri/ra_raportointi/documents/trsdatatypes.xml http://www.finanssivalvonta.fi/fi/saantely/maarayskokoelma/rahoitussekto ri/ra_raportointi/documents/trem_transactionrecordtypes3.0.xml http://www.finanssivalvonta.fi/fi/saantely/maarayskokoelma/rahoitussekto ri/ra_raportointi/documents/standarddatatypes1.0.xml Raportoijan on nimettävä kaupparaporttitiedosto seuraavan säännön mukaisesti: Tiedostonimi on muotoa "TR_"<TRFID>"_"<YYYYMMDD>"_"<SEQ>"."<TYPE>, tai "OT_"<TRFID>"_"<YYYYMMDD>"_"<SEQ>"."<TYPE>, jossa lainausmerkkien sisällä olevat merkkijonot ovat vakioita ja kulmasulkujen sisällä olevat osat muuttujia seuraavasti: Osio Selitys Huomautus TR Vakio "TR" ilmoittaa, että kyseessä on kaupparaporttitiedos-

7 (43) to OT Vakio "OT" ilmoittaa, että kyseessä OTC -johdannaisilla käytyjä kauppoja sisältävä tiedosto. TRFID Raportoijan BIC-koodi Jos raportointivelvollinen sijoituspalvelun tarjoaja toimii itse raportoijana, raportointivelvollisen BIC-koodi Jos raportoijana toimii raportointivelvollisen sijoistuspalvelun tarjoajan puolesta toimiva muu taho, tämän ns. teknisen raportoijan BIC-koodi YYYYMMDD Raportointipäivä 11 merkkinen ISO 9362 SWIFT (8 merkkisen BIC-koodin loppuun täytetään XXX) SEQ Järjestysnumero 4 numeroinen sarjanumero [0000-9999]. Yksilöllinen per päivä. TYPE Tiedostotyyppi XML tai ZIP Esimerkki Kaupparaporttitiedosto TR_TESTFIHHXXX_20070918_0001.XML OT_TESTFIHHXXX_20110903_0001.ZIP Jos kaupparaporttitiedoston nimi on virheellinen, tiedoston käsittely lopetetaan ja virheestä lähetetään ilmoitus (kuittaustiedosto) lähettäjälle. 4.4 Pakatut tiedostot Kaupparaporttitiedostot voidaan pakata. Pakatun kaupparaporttitiedoston on noudatettava seuraavia sääntöjä: Tiedoston on oltava ZIP-muotoa ja se saa sisältää vain yhden pakatun tiedoston eikä yhtään kansiota Pakattu tiedosto on oltava XML-tiedosto Pakatulla tiedostolla on oltava sama nimi kuin XML-tiedostolla, mutta ZIP-päätteellä. 4.5 Tiedoston koko Siirtotavasta riippuen kaupparaporttitiedoston kokorajoitukset ovat: Siirtotapa Tiedostotyyppi HTTP FTP XML 35 Mb Ei rajoitusta ZIP 200 Kb Ei rajoitusta

8 (43) Jos raportoitava tiedosto on liian suuri, tiedoston käsittely lopetetaan ja raportoijalle lähetetään kuittaustiedosto. 4.6 Tietuemuoto 4.6.1 ISIN ja AII -kaupat Seuraavassa taulukossa on kuvattu kaupparaporttitiedostoon liittyvän tietueen kenttien tietosisältö. Kustakin tietokentästä on esitetty seuraavat tiedot: Tiedon nimi () Tiedon kuvaus () Tietoa vastaavan XML-elementin nimi (XML-element/Tag) Tiedon tyyppi () Tiedon oikeellisuusvaatimukset () Tiedon mahdolliset arvot (s) Kommentit () Technical reporting firm identification A technical reporting firm is an organisation which is approved to send transaction reports to Finanssivalvonta on the behalf of a MiFID investment firm or itself. <TechnicalReportingFirm Identification= XXXXXXXXXXX /> String Must be a valid 11characters ISO 9362 SWIFT/ Bank identifier code (BIC). s ISO 9362 [A-Z0-9]{11} Reporting firm identification BIC code of the MiFID investment firm which executed or transmitted the transaction. <ReportingFirm Identification= XXXXXXXXXXX /> String Must be a valid 11 characters ISO 9362 SWIFT/ Bankidentifier code(bic). s ISO 9362 [A-Z0-9]{11} Transaction record info type Contains data related to the transactions associated to a financial instrument. <Transaction>

9 (43) s s s A single transaction, identified by the same Transaction reference number, may only occur once per transaction record type (TransactionRecordInfo or Cancellation Transaction type). Transaction reference number A unique identification number for the transaction provided by the MiFID investment firm or a third party reporting on its behalf. An alphanumeric field up to 40 characters for the unique transaction reference number for each transaction reported by a particular firm. The value must be unique per ReportingFirm. <TransactionReferenceNumber> minlength 1. maxlength 40. This field will be used as a reference to the transaction in all communication between Finanssivalvonta and the reporting firm. How to populate the field is free as long as the number will stay unique per Reporting Firm. One way of populating the field could be to use the date combined with a sequence number. Trading date time The date, time and time zone when the trade was executed. <TradingTimestamp> DateTime Must be a valid ISO 8601 DateTime value. Must consist of date, time and time zone. Format: YYYY-MM-DDTHH:mm:SS+hh:mm YYYY = Year; MM = Month; DD = Day; HH = Hour; mm = minute; SS = second; hh=time zone hour(+/-); mm=time Zone minutes. Populate the field with your local time and time zone. As time offset is based on UTC time, you should adjust it for summer/winter time. Summertime +3, wintertime +2 in Finland. Buy/Sell indicator Identifies whether the transaction was a buy or sell from the perspective of the reporting investment firm acting as princi-

10 (43) s s s s pal, or of the client if acting as agent. <BuySellIndicator> B = buy. S = sell. Trading capacity The trading capacity of the MiFID investment firm reporting the transaction. <TradingCapacity> On its own account (either on its own behalf or on a behalf of a client): P = Own account / portfolio. For the account, and on behalf, of a client: A = Agent Instrument identification The ISIN code that uniquely identifies the financial instrument which is the subject of the transaction. <Instrument> minlength 12. maxlength 12. Input is mandatory if the XML node <AIIInstrumentIdentification> is missing. Must be a valid ISO 6166 ISIN code. This element should not be submitted if the transaction is for an AII-instrument Alternative instrument identification Identifier for Alternative Instrument Identifier (AII) code. Composed by 6 mandatory fields. <AIIInstrumentIdentification> AIIInstrumentIdentification is a complex element. The element is composed by 6 mandatory fields. Input is mandatory if the XML element <Instrument> is missing. This XML-node should only be submitted when the transaction is for an AII-instrument. Exchange Code The identification of the regulated market that admits the derivative to trading.

11 (43) s s s <AIIExchangeCode> minlength 4. maxlength 4. must be a valid ISO 10383 Market Identifier ([A-Z] [0-9]){4} Exchange Product Code A code that is uniquely associated with a particular underlying instrument and settlement type and other characteristics of the contract. <AIIExchangeProductCode> minlength 1. maxlength 12. ([A-Z] [0-9] \+ &)* The code is maintained by the derivative exchanges and is freely and generally available to all parties. The Exchange Product Code can be up to 12 alphanumeric chars with no space padding. The + symbol is also accepted. Note: the & symbol is also accepted. As the & symbol (ampersand) is a XML special character, it should be reported as &. Derivative type Single character identifying whether the instrument is an option or a future. <AIIDerivativeType> minlength 1. maxlength 1. O = Option. F = Futures. Put/Call identifier Single character identifying whether the option is a put, call or a future. <AIIPutCallIdentifier> minlength 1. maxlength 1.

12 (43) s s s P = Put. C = Call. F = Futures. The field should be filled with F in case the derivative type is a future. Expiry/Delivery/Prompt date Exercise date/ maturity date of the derivative contract. <AIIMaturityDate> Date Must be a valid ISO 8601 extended Date value Format: YYYY-MM-DD YYYY = Year; MM = Month; DD = Day Strike price For those instruments admitted to trading in an AII market, it corresponds to the strike price in case of an option. There is no strike price for futures. <AIIStrikePrice> Decimal. Point is used, not comma. totaldigits 19. fractiondigits 5. mininclusive 0 It should be 0 in case of a future. Negative values are not allowed. The strike price should be expressed in the major currency. The strike price should be 0 if the derivative is a future. Unit price The price per security or derivative contract excluding commission. In the case of a debt instrument, the price should be expressed as a percentage and excluding accrued interest (clean price). s It express whether : <UnitPrice> UnitPrice is a choice between PriceCurrency and PricePercentage. Decimal. Point is used, not comma. totaldigits 19. fractiondigits 5. mininclusive 0.

13 (43) s s - The price in percentage in case of a debt instrument or - the unit price of a security or - the price of one derivative contract It should be positive value or zero. Negative values are not allowed. Percentage values populates the field with integers and decimals, e.g. 12,34% is populating the field with 12.34. For bonds, the unit price field should be populated with the relative price expressed as a percentage. Price notation The ISO code of the currency in which the price is expressed or the currency of the nominal value in case of a price expressed in percentage. <PriceNotation> minlength 3. maxlength 3. Must be a valid ISO 4217 currency value. (pre-euro ISO currency codes are also allowed for bonds). Quantity The number of units of the financial instrument, the nominal value of bonds, or the number of derivative contracts included in the transaction. <Quantity> Decimal. minexclusive 0 totaldigits 19. fractiondigits 5. Negative values or zero are not allowed. Counterparty code & Counterparty code type Identification of the counterparty of the transaction. Depending on the counterparty, this field contains: - where the counterparty is a MiFID investment firm, the full 11 character BIC code is used to identify the investment firm. - where the counterparty is a regulated market or MTF, the field should be populated with the MIC code of the trading venue. - where the counterparty is a central counterparty the field should be the BIC code of the central counterparty, - where the counterparty is not a MiFID investment firm, a

14 (43) regulated market, an MTF or entity acting as a central counterparty, the field should be populated with an internal code. In this case this field should be 'C' for customer/client. The table below summarizes these standards: s Counterparty Codetype ISO Investment Firm B 11 character 9362 BIC Code Regulated M MIC Code 10383 Market MTF M MIC Code 10383 Central B BIC code 9362 counterparty Other C Internal code up to 40 characters or code INTERNAL <CounterParty CodeType= B >NNNN</CounterParty> CounterParty is a complex element. It has an attribute code followed by the actual counterparty. minlength 1. maxlength 40. Attribute CodeType: B = must be a valid 11 characters ISO 9362 SWIFT/Bank identifier code (BIC). M = must be a valid ISO 10383 Market Identifier Code (MIC). C = Customer/Client. Use an internal code. Where the counterparty is not a MiFID investment firm, and the counterparty has no BIC-code, an internal code can be used. If the counterparty is a MiFID investment firm use the BIC code of the head office. Where the counterparty is a foreign branch of a MiFID investment firm, the BIC code of the branch must be used. The code INTERNAL is used as counterparty in client-side transactions in the following situations: an investment firm executes an order involving several clients and the order is executed in several transactions (reporting example 10) and an investment firm transmits an order and the executing firm reports (reporting example 13). Venue identification Identification of the venue where the transaction was executed. A trading venue is an MTF, regulated market (RM) or Sys-

15 (43) s s tematic Internalizer(SI). The four character SWIFT MIC code (ISO 10383) should be used when the venue is an MTF or a regulated market. If the venue is an SI the BIC code should be used. If the transaction is made off market, the 'XOFF' should be used. <Venue CodeType= M ></Venue> Venue is a complex element. It has an attribute code followed by the actual counterparty. minlength 4. maxlength 11. [A-Z 0-9] {4, 11} Attribute CodeType: M = must be a valid ISO 10383 Market Identifier Code (MIC). B = must be a valid 11characters ISO 9362 SWIFT/Bank identifier code (BIC). O = must be XOFF. This to indicate a off market transaction. The MIC should identify the actual venue and not the market operator. Venue reference transaction number The venue transaction reference number if the transaction is performed on a regulated market or MTF. <VenueReferenceNumber> minlength 0. maxlength 40. Input is optional, see comments. This field is mandatory only when the trading venue is a Finnish regulated market or MTF. For Nasdaq OMX and First North Finland INET trades use the Trade ID in private data. Valid from the start of INET, 8 th of February 2010. FIX: The Trade ID in tag 1003 is constructed as follows: - Auto-match trades Tag 1003=<9 char OUCH Match Number> - Routed trades Tag 1003=<1 char Host ID F ><9 char ID Number> - Reported trades Tag 1003=<1 char Host ID V ><9 char ID Number> OUCH: The Trade ID is populated in field Match Number

16 (43) For other regulated marketplaces within EU this field is optional. ClientCode If the client is a MiFID investment firm a BIC must be used otherwise use the internal code. <Client CodeType= B >NNNNN</Client> Client is a complex element. It has an attribute code followed by the customer identifier. minlength 1. maxlength 40. Input is optional, see comments below s B = BIC. Must be a valid 11characters ISO 9362 SWIFT/Bank identifier code (BIC). I = Internal. Input is mandatory if trading capacity A is used. Input is also required if any of the other client information fields are filled in. The code INTERNAL is used as client code in market-side transaction in the following situations: an investment firm executes an order involving several clients and the order is executed in several transactions (reporting example 10) and an investment firm transmits an order and the executing firm reports (reporting example 13). Client name Customer name. <Client> minlength 0. maxlength 70. Input is mandatory if trading capacity "A" is used. Input is also required if trading capacity "P" is used and counterparty code type is "C". s The official name of the client. Order: family name, given name. Client identifier local Client firm or personal identifier number. <ClientIdentificationLocal> minlength 0. maxlength 20. Input is mandatory if trading capacity "A" is used. Input is also required if trading capacity "P" is used and counterparty code type is "C".

17 (43) s Code Personal ID: Business ID: Date of birth: Artificial code assigned by Euroclear Finland Ltd (X- Business ID): 11 characters Finnish personal ID 9 characters Finnish business ID YYYY-MM-DD, where YYYY = Year, MM = Month, DD = Day (date in ISO 8601 format) XNNNNNNNT, where NNNNNNN is the unique ID and T is the check digit. s The client identifier field for a natural person should be populated with a Finnish personal ID. If the natural personal does not have a Finnish personal ID, the field should be populated with the date of birth. If the date of birth is not available, the field should be populated with an artificial code assigned by Euroclear Finland Ltd or an internal client code provided by the investment firm. The client identifier field for a corporation should be populated with a Finnish business ID. If the corporation does not have a Finnish business ID, the field should be populated with a national corporate identifier code of the home country of the client corresponding to the business ID, an artificial code assigned by Euroclear Finland Ltd or some other similar code. Client street Street address. <ClientStreet> minlength 0. maxlength 70. Input is mandatory if trading capacity "A" is used. Input is also required if trading capacity "P" is used and counterparty code type is "C". If foreign city doesn't have street addresses the Client street field is not populated. Client zip code

18 (43) s s s ZipCode <ClientZipCode> minlength 0. maxlength 20. Input is mandatory for Finnish address if trading capacity "A" is used. Input is also required if trading capacity "P" is used and counterparty code type is "C". If there is zip code in foreign address, zip code can be populated in Client zip code or Client city field Client City City or post office <ClientCity> minlength 0. maxlength 70. Input is mandatory if trading capacity "A" is used. Input is also required if trading capacity "P" is used and counterparty code type is "C". If foreign country has states, the state is entered in the Client City field. Client country Country of address. <ClientCountry> minlength 0. maxlength 70. Input is mandatory if trading capacity "A" is used. Input is also required if trading capacity "P" is used and counterparty code type is "C". 2-character ISO 3166-code Proxy holder The personal ID or date of birth of a holder of power of attorney or the business ID of an investment firm in pursuance of discretionary portfolio management. <ProxyHolder> minlength 0.

19 (43) maxlength 11. Input is mandatory in cases of power of attorney or discretionary portfolio management if trading capacity A is used. Input is also required if trading capacity P is used and the counterparty code type is C. s Date of birth: YYYY-MM-DD, where YYYY = Year, MM = Month, DD = Day (date in ISO 8601 format). Cancellation transaction info type Use the cancellation transaction type to cancel or delete a previous sent transaction. <CancellationTransaction> s A single transaction, identified by the same Transaction reference number, may only occur once per transaction record type (TransactionRecordInfo, Cancellation Transaction type ) within one transaction report file. Cancelled transaction unique identifier Univocally identifies the transaction to cancel among the transactions sent by this reporting MiFID investment firm. <CancelledTransactionUniqueIdentifier> minlength 1. maxlength 40. s The Transaction reference number of the previous sent transaction should be sent. Cancellation indicator Indicates the cancellation type. <CancellationIndicator> Input is optional. s C = Cancel the previously submitted transaction.

20 (43) This field is also used in the exchange of transaction files between Competent Authorities. More possible values will be added in the future. 4.6.2 OTC johdannaiskaupat XML element/tag Technical reporting party A technical reporting firm is an organisation which is approved to send transaction reports to the authority on the behalf of a MiFID investment firm or itself. <TechnicalReportingParty> String Input is mandatory and will be validated against reference data. Must be a valid 11characters ISO 9362 SWIFT/Bank identifier code (BIC). s ISO 9362 [A-Z 0-9]{11} Reporting parties Section for reporting parties, see below. XML element/tag <ReportingParties> s Reporting party BIC code of the MiFID investment firm which executed or transmitted the transaction. XML element/tag <ReportingParty> String Input is mandatory and will be validated against reference data. Must be a valid 11characters ISO 9362 SWIFT/Bank identifier code (BIC). s ISO 9362 [A-Z 0-9]{11}

21 (43) s XML element/tag s s OTC Transaction record info type Contains data related to the transactions associated to a financial instrument. <OTCTransactionRecordInfo> A single transaction, identified by the same Transaction reference number, may only occur once per transaction record type within one OTC transaction report file. Transaction reference number A unique identification number for the transaction provided by the MiFID investment firm or a third party reporting on its behalf. An alphanumeric field up to 40 characters for the unique transaction reference number for each transaction reported by a particular firm. The value must be unique per ReportingFirm. <TransactionReferenceNumber> minlength 1. maxlength 40. This field will be used as a reference to the transaction in all communication between the authority and the reporting firm. How to populate the field is free as long as the number will stay unique per Reporting Party. One way of populating the field could be to use the date combined with a sequence number. Trading date time The date, time and time zone when the trade was executed. <TradingTimestamp> DateTime Must be a valid ISO 8601 DateTime value. A valid ISO 8601 DateTime value. Must consist of date, time and time zone. Format: YYYY-MM-DDTHH:mm:SS+hh :mm YYYY = Year; MM = Month; DD = Day; HH = Hour; mm = minute; SS = second; hh=time zone hour(+/-) and minutes. Populate the field with your local time and time zone.

22 (43) s s s As time offset is based on UTC time, you should adjust it for summer/winter time. Summertime +2, wintertime +1 in Sweden, Denmark and Norway. For Finland it is +3 during summertime and +2 during winter. For Iceland it is 0 all year Buy/Sell indicator Identifies whether the transaction was a buy or sell from the perspective of the reporting investment firm if acting as principal, or of the client if acting as an agent. <BuySellIndicator> Valid values below. B = Buy. S = Sell. Trading capacity The trading capacity of the MiFID investment firm executing the transaction. <TradingCapacity> Valid values below. On its own account (either on its own behalf or on a behalf of a client: P = Own account / portfolio. For the account, and on behalf, of a client: A = Agent. The market transaction is performed as of: Own account (P), or agent for a client (A). OTC instrument identification Identifier for OTC Instruments. Composed by 8 fields. <OTCInstrumentIdentification> OTCInstrumentIdentification is a complex element. The element is composed by 8 fields. InstrumentIdentification The identification of the ISIN for the OTC Instrument.

23 (43) s s s s <InstrumentIdentification> minlength 12. maxlength 12. Input is optional. If given, valid values below. Must be a valid ISO 6166 ISIN code. UltimateUnderlyingIdentification A code that is uniquely associated with a particular underlying instrument and settlement type and other characteristics of the contract. <UltimateUnderlyingIdentification> minlength 12. maxlength 12. Valid values below. Must be a valid ISO 6166 ISIN code. MarkitClip <MarkitClip> AlphanumericType..{6}.{9} Input is optional. Identify the ultimate underlying when the OTC derivative instrument is a Credit Default Swap (CDS). DerivativeType Single character identifying derivative type <DerivativeType> minlength 1. maxlength 1. Valid values below. O = Options W=Warrants F = Future/forwards D = CfDs and TRS

24 (43) s s X = Spread bets S = Swaps other than CfDs, TRS and CDS Z = CDS K = Complex derivatives Put/Call identifier Single character identifying whether the option is a put or a call. <PutCallIdentifier> minlength 1. maxlength 1. Input is optional. For Derivative types O, W the field shall be populated. For Derivative types D, X, K the field may be populated. For Derivative types F, S, Z the field should not be populated. If given, valid values below. P = Put. C = Call. PriceMultiplier <PriceMultiplier> Decimal. Point is used, not comma. totaldigits 19. fractiondigits 5. mininclusive 0 Input is optional. For Derivative types O, W, F, S the field shall be populated. For Derivative types D, X, K the field may be populated. For Derivative types Z the field should not be populated. Negative values or zero are not allowed Strike price <StrikePrice> Decimal. Input is optional. For Derivative types O, W the field shall be populated.

25 (43) For Derivative types D, X, K the field may be populated. For Derivative types F, S, Z the field should not be populated. s The strike price should be expressed in the major currency. Expiration date Exercise date/ maturity date of the derivative contract. <ExpirationDate> Date Input is optional. For Derivative types O, W, F, S the field shall be populated. For Derivative types D, X, Z, K the field may be populated. s Must be a valid ISO 8601 extended Date value Format: YYYY-MM-DD YYYY = Year; MM = Month; DD = Day Instrument description A text field for instrument description. <Instrument> minlength 0. maxlength 90. Input is optional. s Unit price The price per security or derivative contract excluding commission. In the case of a debt instrument, the price should be expressed as a percentage and excluding accrued interest (clean price). <UnitPrice> UnitPrice is a choice between PriceCurrency and PricePercentage. Decimal. Point is used, not comma. totaldigits 19. fractiondigits 5. mininclusive 0 s Negative values are not allowed. It express whether :

26 (43) - The price in percentage in case of a debt instrument or - The unit price of a security or - The price of one derivative contract It should be a positive value or zero. Percentage values populates the field with integers and decimals, e.g. 12,34% is populating the field with 12.34. Price notation The ISO code of the currency in which the price is expressed or the currency of the nominal value in case of a price expressed in percentage. <PriceNotation> Input is mandatory and will be validated against reference data. Must be a valid ISO 4217 currency value. s ISO 4217. [A-Z]{3} Quantity The number of units of the financial instrument, or the number of derivative contracts included in the transaction. <Quantity> Decimal. minexclusive 0. totaldigits 19. fractiondigits 5. s Negative values or zero are not allowed. CounterParty Identification of the counterparty of the transaction. Depending on the counterparty, use tag and value as in table below. Counter party MiFID Investment Firm Use Tag ISO CounterpartyIdentficationBIC 11 character BIC Code 9362

27 (43) Regulated Market MTF Central counterparty Other CounterpartyIdentficationMIC CounterpartyIdentficationMIC CounterpartyIdentficationBIC CounterpartyIdentificationCustomer MIC Code 10383 MIC Code 10383 BIC code 9362 Internal code up to 40 characters s s <CounterParty> CounterParty is a choice between CounterPartyIdentification- BIC, CounterPartyIdentificationMIC and CounterpartyIdentificationCustomerInternal Either CounterPartyIdentificationBIC, CounterPartyIdentificationMIC or CounterpartyIdentificationCustomerInternal should be used. Described in following sections. Where the counterparty is not a MiFID investment firm, and the counterparty has no BIC-code, an internal code can be used. If the counterparty is a MiFID investment firm use the BIC code of the head office. Where the counterparty is a foreign branch of a MiFID investment firm, the BIC code of the branch must be used. Contact SWIFT for valid BIC codes. CounterpartyIdentificationBIC Identification of the counterparty of the transaction where the counterparty is a MiFID investment firm and the full 11 character BIC code is used to identify the investment firm or where the counterparty is a central counterparty the field should be the BIC code of the central counterparty. <CounterPartyIdentificationBIC> minlength 11. maxlength 11. must be a valid 11 characters ISO 9362 SWIFT/Bank identifier code(bic) and will be validated against reference data. Contact SWIFT for valid BIC codes.

28 (43) CounterpartyIdentficationMIC Identification of the counterparty of the transaction where the counterparty is a regulated market or MTF the field should be populated with the MIC code of the trading venue. <CounterPartyIdentificationMIC> minlength 4. maxlength 4. s must be a valid ISO 10383 Market Identifier Code (MIC) and will be validated against reference data. CounterpartyIdentificationCustomerInternal Identification of the counterparty of the transaction where the counterparty is not a MiFID investment firm, a regulated market, an MTF or entity acting as a central counterparty, the field should be populated with an internal code. <CounterpartyIdentificationCustomer> CounterpartyIdentificationCustomer has the sub element CounterpartyIdentificationCustomerInternal. minlength 1. maxlength 40. s s Customer/Client. Use an internal code. TradingVenueCode Identification of the venue where the transaction was executed. <TradingVenueCode> minlength 4. maxlength 4. must be XXXX. This to indicate an OTC transaction. Client Section for client data related to the transaction. <Client>

29 (43) s s s s Input is optional. But if trading capacity A is used it is required. Input is also required if any of the other client information fields are filled in. If Client information is not given, the Client element should be excluded. Client Code <ClientCode> ClientCode is a choice between ClientBIC and ClientInternal ClientBIC or ClientInternal should be used. ClientBIC If the client is a MiFID investment firm a ClientBIC must be used <ClientBIC> [A-Z 0-9]{11} Input is optional, client s BIC should be used. Must be a valid 11 characters ISO 9362 SWIFT/Bank identifier code (BIC) and will be validated against reference data. ClientInternal If the client is not a MiFID investment firm use the ClientInternal code. <ClientInternal> minlength 1. maxlength 40. Input is optional, Client s Internal code should be used. Client name Customer name. <Client>

30 (43) s s minlength 0. maxlength 70. Input is mandatory if trading capacity "A" is used. Input is also required if trading capacity "P" is used and "CounterpartyIdentificationCustomerInternal" is populated. The official name of the client. Order: family name, given name Client identifier local Client firm or personal identifier number. <ClientIdentificationLocal> minlength 0. maxlength 20. Input is mandatory if trading capacity "A" is used. Input is also required if trading capacity "P" is used and "CounterpartyIdentificationCustomerInternal" is populated. Code Personal ID: 11 characters Finnish personal ID Business ID: 9 characters Finnish business ID Date of birth: YYYY-MM-DD, where YYYY = Year, MM = Month, DD = Day (date in ISO 8601 format) Artificial code assigned by XNNNNNNNT Euroclear Finland Ltd (X-, where NNNNNNN is the Business ID): unique ID and T is the check digit. The client identifier field for a natural person should be populated with a Finnish personal ID. If the natural person does not have a Finnish personal ID, the field should be populated with the date of birth. If the date of birth is not available, the field should be populated with an artificial code assigned by Euroclear Finland Ltd or an internal client code provided by the investment firm. The client identifier field for a corporation should be populated with a Finnish business ID. If the corporation does not have a Finnish business ID, the field should be populated with a national corporate identifier code of the home country of the client corresponding to the business ID, an artificial code assigned by Euroclear Finland Ltd or another similar code.

31 (43) s s s Client street Street address. <ClientStreet> minlength 0. maxlength 70. Input is mandatory if trading capacity "A" is used. Input is also required if trading capacity "P" is used and "CounterpartyIdentificationCustomerInternal" is populated. Client street field is not reported, if foreign city doesn't have street addresses. Client zip code ZipCode <ClientZipCode> minlength 0. maxlength 20. Input is mandatory for Finnish address if trading capacity "A" is used. Input is also required if trading capacity "P" is used and "CounterpartyIdentificationCustomerInternal" is populated. If there is zip code in foreign address, zip code can be populated in Client zip code or Client city field Client City City or post office <ClientCity> minlength 0. maxlength 70. Input is mandatory if trading capacity "A" is used. Input is also required if trading capacity "P" is used and "CounterpartyIdentificationCustomerInternal" is populated. State is populated in Client City field, if foreign country has states. Client country Country of address.

32 (43) s <ClientCountry> minlength 0. maxlength 70. Input is mandatory if trading capacity "A" is used. Input is also required if trading capacity "P" is used and "CounterpartyIdentificationCustomerInternal" is populated. 2-character ISO 3166-code Proxy holder The personal ID or date of birth of the holder of power of attorney or the business ID of the investment firm in pursuance of discretionary portfolio management. <ProxyHolder> minlength 0. maxlength 11. Input is mandatory when power of attorney or discretionary portfolio management if trading capacity "A" is used. Input is also required if trading capacity "P" is used and counterparty code type is "C". s Date of birth: YYYY-MM-DD, where YYYY = Year, MM = Month, DD = Day (date in ISO 8601 format). Cancellation transaction info type Use the cancellation transaction type to cancel a previous sent transaction. <CancellationRecordInfo> Input is optional. s XML element/tag A single transaction, identified by the same Transaction reference number, may only occur once per transaction record type (TransactionRecordInfo or Cancellation Transaction type) within one transaction report file. Cancelled transaction unique identifier Univocally identifies the transaction to cancel among the transactions sent by this reporting MiFID investment firm. <CancelledTransactionUniqueIdentifier>

33 (43) s s minlength 1. maxlength 40. The Transaction reference number of the previous sent transaction should be sent. Cancelled Transaction Flag Indicates the cancellation type. <CancelledTransactionFlag> C = Cancel the previously submitted transaction. 4.7 Tiedoston tarkistussäännöt 5 Kuittaustiedoston kuvaus Kaupparaporttitiedoston tietojen oikeellisuuden tarkistaminen on kaksiosainen prosessi. Ensimmäisessä vaiheessa TYVI-palvelu tekee kaupparaporttitiedostolle joukon teknisiä tarkistuksia XML-skeemaan perustuen. Kaupparaporttitiedoston saavuttua Finanssivalvonnan järjestelmään tehdään sille vielä sellaisia sisällöllisiä tarkistuksia, joita ei TYVI-palvelussa voida tehdä. Tyvi-palvelun tekemät tarkistukset Tiedoston nimi on kuvauksen mukainen (Luku 4.3) Raportoitujen tapahtumien tietueen tietorakenne ja -sisältö vastaavat XML-skeemaa (Luvut 4.2 ja 4.6). Kaupparaporttitiedosto sisältää vain yksilöityjä kauppatapahtumia ja peruutustapahtumia Raportoitavaa kauppatapahtumaa ei löydy aiemmin toimitetusta aineistosta Peruutustapahtumassa viitattu kauppatapahtuma löytyy samasta tai aiemmin toimitetusta kaupparaporttitiedostosta. Kaupparaporttitiedostossa peruutustapahtuma sijaitsee peruutustapahtumassa viitatun kauppatapahtuman jälkeen Kuittaustiedosto on XML-muotoinen tiedosto, joka lähetetään raportoijalle, kun kaupparaporttitiedosto on siirretty Finanssivalvonnan tietojärjestelmään ja tarkistettu. Kuittaustiedosto koostuu otsikosta ja rungosta. Runko

2 (43) 5.1 Kuittaustiedoston nimi sisältää kutakin raportoitua tapahtumaa kohti kuittaustietueen. Kuittaustiedoston XML-skeema on ladattavissa osoitteesta http://www.finanssivalvonta.fi/fi/saantely/maarayskokoelma/rahoitussekto ri/ra_raportointi/documents/transactionfeedback.xml Järjestelmä muodostaa kuittaustiedoston nimen ohjelmallisesti ja se viittaa siirrettävän kaupparaporttitiedoston nimeen. Kun kaupparaporttitiedosto on siirretty virheettömällä nimellä, kuittaustiedosto lähetetään raportoijalle pakattuna samalla nimellä, mutta FBetuliitteellä täydennettynä. Esimerkki Kaupparaporttitiedoston nimi Kaupparaporttitiedostoon liittyvän kuittaustiedoston nimi Pakatun kuittaustiedoston nimi TR_TESTFIHHXXX_20070918_0001.XML tai OT_ TESTFIHHXXX_20070918_0001.XML FB_TR_TESTFIHHXXX_20070918_0001_0001. XML tai FB_OT_TESTFIHHXXX_20070918_0001_0001. XML FB_TR_TESTFIHHXXX_20070918_0001_0001. ZIP tai FB_OT_TESTFIHHXXX_20070918_0001_0001. ZIP Jos siirretyn kaupparaporttitiedoston nimi on ollut virheellinen, kaupparaporttitiedoston käsittely lopetetaan ja järjestelmä lähettää seuraavasti nimetyn kuittaustiedoston raportoijalle: "FB_<TR OT>_"<UlkoinenTiedostoNimi>"_"<SEQ>"."<TYPE> Osio FB UlkoinenTiedostoNimi SEQ TYPE Selitys Vakio ilmoittaa, että kyseessä on kuittaustiedosto Siirretyn kaupparaporttitiedoston nimi 4-numeroinen sarjanumero Kuittaustiedoston tyyppi on aina XML Esimerkki Kaupparaporttitiedostonnimi: TR_ UlkoinenTiedostoNimi.XML Kuittaustiedoston nimi: FB_ TR_UlkoinenTiedostoNimi _0001.XML 5.2 Kuittaustiedoston otsikko Kuittaustiedoston otsikko sisältää tietoa siirretyn kaupparaporttitiedoston oikeellisuudesta raporttitasolla. Otsikko sisältää seuraavat tiedot: TransactionReport Siirretyn kaupparaporttitiedoston nimi

3 (43) ReceivedTimestamp FeedbackReport FileStatus Code Message Aika, jolloin siirretty kaupparaporttitiedosto on otettu vastaan Palautetun kuittaustiedoston nimi (Siirretyn) tiedoston tila Tilan tarkennne Viesti Seuraavassa taulukossa on lueteltu mahdolliset siirretyn tiedoston tilat (FileStatus) ja tiedoston tilaan liittyvät tarkentavat koodit (Code). Tiedoston tila ACC AWE REJ Tarkenne OK DVE FEE GSE IDTI IFNF IRF ITF IXF SNF SNV UFAS UFSE XPE ZDCOE Kommentti Tiedosto on hyväksytty ja kaikki sen sisältämät tapahtumat ovat virheettömiä. Tapahtumat on tallennettu vastaanottajan tietokantaan. OK Tiedosto on hyväksytty, mutta se sisältää virheellisiä kauppatapahtumia. Virheettömät tapahtumat on tallennettu vastaanottajan tietokantaan. Sisällön tarkastuksessa virheitä Tiedosto on hylätty. Yhtään tapahtumaa ei ole tallennettu vastaanottajan tietokantaan. Tiedoston tarkenne virheellinen Yleinen järjestelmävirhe Kaksi samaa kauppatapahtuman tunnistetta Virheellinen tiedoston nimeämismuoto Virheellinen raportoija Virheellinen tekninen raportoija Virheellinen XML-muoto Skeemaa ei löydy Skeema virheellinen Siirretty tiedosto löytyy jo Siirretyn tiedoston koko virheellinen XML jäsennysvirhe ZIP pakkauksen purkuvirhe Tiedoston tilasta riippuen raportoijan on tehtävä seuraavat toimenpiteet: ACC AWE Ei toimenpiteitä Korjattava virheelliset tapahtumat ja lähetettävä korjatut tapahtumat uudessa tiedostossa uudella järjestysnumerolla (Voi lähettää myös seuraavassa kaupparaportissa.) Virheellisiä

4 (43) REJ tapahtumia ei tarvitse peruuttaa ennen korjattujen tapahtumien uudelleenlähetystä. Korjattava virheet ja lähetettävä tapahtumat uudessa tiedostossa uudella järjestysnumerolla. (Jos tiedetään, että TYVIoperaattori on hylännyt tiedoston, niin tiedosto voidaan lähettää samalla nimellä) 5.3 Kuittaustiedoston runko Kuittaustiedosto sisältää kutakin raportoitua tapahtumaa kohti kuittaustietueen. Kuittaustietue sisältää tiedon raportoidun tapahtuman oikeellisuudesta. Seuraavassa taulukossa on lueteltu tapahtumien mahdolliset tilat ja tilaan liittyvät tarkentavat koodit: Tapahtuman tila ACCEPTED IGNORED FAILED Tarkenne OK DTI AIIDT AIIMD AIIPC AIISP AIIXC AIIXPC ICPC IEXD_TD IISIN IPN IPNIT Kommentti Kauppataphtuma/peruutustapahtuma on virheetön. Ok Tapahtuma on ohitettu. Kaksi samaa kauppatapahtuman tunnistetta Kauppatapahtuma/peruutustapahtuma sisältää virheitä Johdannaistyypin (AIIDerivativeType) on oltava [O] tai [F] Eräpäivän (AIIMaturityDate) on oltava kelvollinen päiväys Indikaattorin (AIIPutCallIdentifier) on oltava [P],[C] tai [F] Lunastushinta (AIIStrikePrice) virheellinen Tuotekoodia (AIIExchangeCode) ei löydy tai se on virheellinen Tuotekoodin (AIIExchangeProductCode) oltava 1-12 merkkinen Vastapuolitunnus on virheellinen tai se ei ole voimassa kauppapäivänä Kauppatapahtuman kaupantekoaika pitää olla sama tai aikaisempi kuin instrumentin voimassaolon päättymispäivä Virheellinen ISIN-koodi Valuuttakoodi on virheellinen tai se ei ole voimassa kauppapäivänä Euroa edeltävää valuuttakoodia (ATS,BEF,CYP,DEM,ESP,FIM,FRF,GRD, IEP,ITL,LUF,MTL,NLG,PTE,SIT ja SKK) saa käyttää vain velkainstrumentille

5 (43) IRFTD ITD IVI MTI CIM ICC RTAC VII IUUISIN IPMV ISPV Raportoijan BIC-koodi on virheellinen tai se ei ole voimassa kauppapäivänä Virheellinen kaupantekoaika Kauppapaikan tunnus on virheellinen tai se ei ole voimassa kauppapäivänä Puuttuva tapahtuman tunnus Puuttuva asiakastieto Asiakastunnus on virheellinen tai se ei ole voimassa kauppapäivänä Viitattu kauppatapahtuma on jo peruttu AII-kauppapaikalla kauppatapahtuman instrumentti on yksilöitävä AII-tunnuksella, muilla kauppapaikoilla ISIN-koodilla Ultimate Underlying ISINCode on väärän muotoinen Price multiplier pitää olla positiivinen Strike price pitää olla positiivinen silloin kun tieto on annettu. Tapahtuman tilasta riippuen raportoijan on tehtävä seuraavat toimenpiteet: ACCEPTED FAILED IGNORED Ei toimenpiteitä Korjattava virheellinen tapahtuma ja lähetettävä se muiden mahdollisten korjattujen tapahtumien kanssa. Uusi tiedosto on numeroitava uudella, edellistä suuremmalla numerolla. Jos kauppatapahtuma on lähetetty jo aiemmin, muita toimenpiteitä ei tarvita. Muussa tapauksessa vaihdettava virheellisen tapahtuman TransactionReferenceNumber ja lähetettävä se uudessa tiedostossa muiden korjattujen tapahtumien kanssa. Uusi tiedosto on numeroitava järjestyksessä seuraavalla numerolla

6 (43) 6 Esimerkkejä 6.1 Kauppatapahtuma 6.2 Peruutustapahtuma

7 (43) 6.3 Kaupparaporttitiedosto

8 (43) Sijoituspalveluyritys toteuttaa toimeksiannon, jossa on monta asiakasta ja toimeksianto toteutuu useana transaktiona

9 (43)

10 (43) 6.4 OTC -johdannaiskauppatiedosto

11 (43) 6.5 Kuittaustiedosto