Standardi RA5.1 Liite. Standardin RA5.1 mukaisen kaupparaportoinnin konekielisen tietojenvälityksen

Standardi RA5.1 Liite Standardin RA5.1 mukaisen kaupparaportoinnin konekielisen tietojenvälityksen ohjeet

OHJE 2 (29) Sisällysluettelo 1 Johdanto...3 2 Tietojen toimittaminen Rahoitustarkastukselle...3 3 Raportointitavat...3 3.1 Valmiin kaupparaportin toimittaminen tiedostolatauksena...4 3.2 Tietojen syöttö web-lomakkeella...4 3.3 FTP-tiedostosiirto...4 4 Kaupparaportin kuvaus...4 4.1 Tapahtumien (transaction) tyypit...5 4.2 XML-skeema...5 4.3 Kaupparaportin nimi...5 4.4 Pakatut tiedostot...6 4.5 Tiedoston koko...6 4.6 Tietuemuoto...6 4.7 Tiedoston tarkistussäännöt...15 5 Kuittaustiedoston kuvaus...15 5.1 Kuittaustiedoston nimi...16 5.2 Kuittaustiedoston otsikko...16 5.3 Kuittaustiedoston runko...18 6 Esimerkkejä...19 6.1 Kauppatapahtuma...19 6.2 Peruutustapahtuma...19 6.3 Kaupparaportti...20 7 Yhteyshenkilöt...20 7.1 Rahoitustarkastuksen yhteyshenkilöt...20 7.2 TYVI-operaattorin yhteyshenkilöt...21 8 Kaupparaportin skeemakuvaus...22

OHJE 3 (29) 1 Johdanto Tätä ohjetta sovelletaan raportointistandardiin RA5.1 Kaupparaportointi liittyvän kaupparaporttitiedoston tuottamiseen ja toimittamiseen Rahoitustarkastukselle, alkaen 1.11.2007 tilannetta koskevasta raportoinnista. 2 Tietojen toimittaminen Rahoitustarkastukselle Rahoitustarkastus 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". Rahoitustarkastuksen käyttämä TYVI-operaattori on Itella Information Oy. TYVI-operaattorin tarjoamaa raportointipalvelua kutsutaan jatkossa TYVI-palveluksi. Raportoija toimittaa TYVI-operaattorille kutakin pörssipäivää kohti yhden tai useamman tiedoston (kaupparaportti) raportoitavista kaupoista. TYVIoperaattori tarkistaa raportoijan lähettämien tiedostojen teknisen eheyden ja tietuemuodon oikeellisuuden ja välittää virheettömät kaupparaportit Rahoitustarkastukselle. Kaupparaporteilla havaituista virheistä annetaan välitön palaute raportoijalle, joka voi ryhtyä toimenpiteisiin virheiden korjaamiseksi ja kaupparaportin uudelleen lähettämiseksi. Kaupparaportit tulee muodostaa tämän ohjeen mukaisen tietuekuvauksen mukaisesti. Jokaisesta vastaanotetusta kaupparaportista Rahoitustarkastus lähettää raportoijalle kuittaustiedoston TYVI-palvelun kautta. Raportoinnissa tarvittavan yrityskohtaisen BIC-koodin saa kuluitta SWIFTiltä. Sen voi tilata täyttämällä SWIFTin www-sivuilla olevan lomakkeen osoitteessa https://www2.swift.com/formz/public/index.cfm?form_config=public_bic1 request&form_title= Request an 8 characters BIC for a non SWIFT User&form_roadmap= http://www.swift.com/index.cfm?item_id=43685 3 Raportointitavat Raportoijalle on kaupparaportointia varten tarjolla kolme raportointitapaa. Tavat ovat Valmiin tiedoston toimittaminen tiedostolatauksena (http upload) Tietojen syöttö web-lomakkeella (http-protokolla) ftp-tiedostosiirto (file transfer protocol)

OHJE 4 (29) Kahdessa ensin mainitussa tavassa kaupparaportit toimitetaan TYVIoperaattorin tarjoaman web-palvelun avulla ja siirtotapana käytetään httpsprotokollaa. Mahdollisista muista tiedonvälitystavoista raportoijan tulee sopia TYVIoperaattorin kanssa. Tällöin raportoija vastaa itse syntyvistä kustannuksista. 3.1 Valmiin kaupparaportin toimittaminen tiedostolatauksena 3.2 Tietojen syöttö web-lomakkeella Raportoija voi toimittaa valmiin kaupparaportin Rahoitustarkastukselle kirjautumalla TYVI-web-palveluun ja lähettämällä tiedoston palvelun kautta tiedostolatauksena (http upload). TYVI-palveluun kirjautuminen vaatii käyttäjätunnuksen ja salasanan, jotka raportoija tilaa TYVI-palvelun kautta osoitteesta https://sol.itella.net/ec/rata-tunnustilaus/. Siirtoyhteyden suojaamiseksi käytetään SSL-protokollaa. Yksittäiset kaupat voidaan raportoida syöttämällä ne web-lomakkeelle TYVI-palvelussa. TYVI-palveluun kirjautuminen vaatii käyttäjätunnuksen ja salasanan, jotka raportoija tilaa TYVI-palvelun kautta osoitteesta https://sol.itella.net/ec/rata-tunnustilaus/. Siirtoyhteyden suojaamiseksi käytetään SSL-protokollaa. 3.3 FTP-tiedostosiirto 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 kaupparaportin siirto suoritetaan FTP protokollalla. TYVI-operaattori antaa ns. ftp-tunnuksen (käyttäjänimi ja salasana) raportoijalle palvelun käyttöä varten. Ftp-tunnukset tilataan Itellan yhteyshenkilöltä (Luku 7.2). 4 Kaupparaportin kuvaus Tarkemmat ohjeet tiedonsiirtoon on kuvattu TYVI-operaattorin antamassa ohjeessa "RAJAPINTAKUVAUS, Itella Customer Connection, Rahoitustarkastus". Kaupparaportit ovat XML-tiedostoja ja koostuvat kauppatapahtumista ja kaupan peruutustapahtumista. Kaupparaportin on noudatettava annettuja vaatimuksia koskien Tiedostomuotoa Tiedostonimeä Tiedostotyyppiä (XML tai ZIP) ja

OHJE 5 (29) 4.1 Tapahtumien (transaction) tyypit Tiedostokokoa. Kaupparaportissa voi olla kahden tyyppisiä tapahtumia: 1. Transaction Record Info kauppatapahtuma 2. Cancellation Transaction Type kaupan peruutustapahtuma "Transaction reference number" ja "Transaction record info type" (tapahtuman tyyppi) yksilöivät tapahtuman. Samassa tiedostossa voi olla kaksi tapahtumaa, joilla on sama Transaction reference number -kentän arvo, jos toisen tapahtuman tyyppi on "Transaction" ja toisen "CancellationTransaction". Jos samassa kaupparaportissa raportoidaan sekä kauppa että sen peruutus, tulee peruutustapahtuman olla peruutustapahtumassa viitatun kauppatapahtuman jälkeen. 4.2 XML-skeema Kaupparaportin XML-skeema on kuvattu tiedostossa http://www.rahoitustarkastus.fi/rataweb/taxonomy/intrans/transactionrep ort.xsd. 4.3 Kaupparaportin nimi Raportoijan on nimettävä kaupparaportti seuraavan ohjeen mukaisesti: Tiedostonimi on muotoa "TR_"<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 kaupparaporttitiedosto TRFID Raportoijan BIC-koodi 11 merkkinen ISO 9362 SWIFT (8 merkkisen BIC-koodin loppuun täytetään XXX) YYYYMMDD Raportointipäivä SEQ Järjestysnumero 4 numeroinen sarjanumero [0000-9999]. Yksilöllinen per päivä. TYPE Tiedostotyyppi XML tai ZIP

OHJE 6 (29) Esimerkki Kaupparaportti TR_TESTFIHHXXX_20070918_0001.XML Jos kaupparaportin nimi on virheellinen, tiedoston käsittely lopetetaan ja virheestä lähetetään ilmoitus (kuittaustiedosto) lähettäjälle. 4.4 Pakatut tiedostot Kaupparaportit voidaan pakata. Pakatun kaupparaportin 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 kaupparaportin kokorajoitukset ovat: Siirtotapa Tiedostotyyppi HTTP FTP XML 35 Mb Ei rajoitusta ZIP 200 Kb Ei rajoitusta Jos raportoitava tiedosto on liian suuri, tiedoston käsittely lopetetaan ja raportoijalle lähetetään kuittaustiedosto. 4.6 Tietuemuoto Seuraavassa taulukossa on kuvattu kaupparaporttiin liittyvän tietueen kenttien tietosisältö. Kustakin tiedosta 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 Rata on the behalf of a MiFID investment firm or itself.

OHJE 7 (29) <TechnicalReportingFirm Identification= XXXXXXXXXXX /> String Input is mandatory. 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 the transaction. <ReportingFirm Identification= XXXXXXXXXXX /> String Input is mandatory. Must be a valid 11characters 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> s 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. 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.

OHJE 8 (29) s s s s maxlength 40. Input is mandatory. This field will be used as a reference to the transaction in all communication between Rata and the reporting firm. How to populate the field is free as long as the number will stay unique per ReportingFirm. 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 Input is mandatory. 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 principal, or of the client if acting as agent. <BuySellIndicator> Input is mandatory. B = buy. S = sell. Trading capacity The trading capacity of the MiFID investment firm reporting the transaction. <TradingCapacity> Input is mandatory. On its own account (either on its own behalf or on a behalf

OHJE 9 (29) 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. s Must be a valid ISO 6166 ISIN code. If ISIN code of traded instrument is not available at the time of reporting use FI0008902937. Unit price The price per security or derivative contract excluding commission. In the case of a debt instrument, the price may be expressed in terms of currency or as a percentage, when using currency price is expressed excluding accrued interest (clean price). <UnitPrice> UnitPrice is a choice between PriceCurrency and PricePercentage. Decimal. Point is used, not comma. totaldigits 19. fractiondigits 5. Input is mandatory. s It express whether : - The price in percentage in case of a debt instrument or - the unit price of a security or - the price of one derivative contract Negative as well as positive values are allowed. 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>

OHJE 10 (29) s s minlength 3. maxlength 3. Input is mandatory. Must be a valid ISO 4217 currency value. 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. mininclusive 0. totaldigits 19. fractiondigits 5. Input is mandatory. 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 or an entity acting as its central counterparty, the field should be populated with the MIC code of the trading venue. - 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. In this case this field should be flagged as customer/client. The table below summarizes these standards: Counterparty Standard ISO Investment Firm 11 character BIC Code 9362 Regulated Market MIC Code 10383 MTF MIC Code 10383 Central counterparty MIC Code 10383 Other Has to be flagged as C' <CounterParty CodeType= B >NNNN</CounterParty> CounterParty is a complex element. It has an attribute code followed by the actual counterparty.

OHJE 11 (29) s s minlength 1. maxlength 40. Input is mandatory. 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 parent company. Where the counterparty is a branch, the BIC code of the branch must be used. Venue identification Identification of the venue where the transaction was executed. A trading venue is an MTF or a regulated market, the four character SWIFT MIC code (ISO 10383) should be used to identify the execution venue. 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 4. Input is mandatory. Attribute CodeType: M = must be a valid ISO 10383 Market Identifier Code (MIC). O = must be XOFF. This to indicate a off market transaction. The MIC shall 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>

OHJE 12 (29) s 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. Optional if the venue reference transaction number is not yet known because the transaction is subject to rules of the marketplace and subsequently reported after the closing of the marketplace. For other regulated marketplaces within EU this field is optional. For OMX cash use trade number. For OMX derivatives use deal number. 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. s Input is mandatory if trading capacity "A" is used Cancellation transaction info type Use the cancellation transaction type to cancel or delete a previous sent transaction. <CancellationTransaction> 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

OHJE 13 (29) s s transactions sent by this reporting MiFID investment firm. <CancelledTransactionUniqueIdentifier> minlength 1. maxlength 40. Input is mandatory. The Transaction reference number of the previous sent transaction should be sent. Cancellation indicator Indicates the cancellation type. <CancellationIndicator> Input is optional. C = Cancel the previously submitted transaction. This field is also used in the exchange of transaction files between Competent Authorities. More possible values will be added in the future. No obligation to report the following fields automatically. s s Client name Customer name. <Client> minlength 0. maxlength 70. Input is optional. Client identifier local Client firm or personal identifier number. <ClientIdentificationLocal> minlength 0. maxlength 20. Input is optional.

OHJE 14 (29) s s s s Client street Street. <ClientStreet> minlength 0. maxlength 70. Input is optional. Client zip code ZipCode <ClientZipCode> minlength 0. maxlength 20. Input is optional. Client City Client City <ClientCity> minlength 0. maxlength 70. Input is optional. Client country Country. <ClientCountry> minlength 0. maxlength 70. Input is optional.

OHJE 15 (29) s Proxy holder The person-/org. number of the power of attorney. <ProxyHolder> minlength 0. maxlength 11. Input is optional. 4.7 Tiedoston tarkistussäännöt 5 Kuittaustiedoston kuvaus Kaupparaportin tietojen oikeellisuuden tarkistaminen on kaksiosainen prosessi. Ensimmäisessä vaiheessa TYVI-palvelu tekee kaupparaportille joukon teknisiä tarkistuksia XML-skeemaan perustuen. Kaupparaportin saavuttua Rahoitustarkastuksen 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). Kaupparaportti 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 kaupparaportista. Kaupparaportissa peruutustapahtuma sijaitsee peruutustapahtumassa viitatun kauppatapahtuman jälkeen Kuittaustiedosto on XML-muotoinen tiedosto, joka lähetetään raportoijalle, kun kaupparaportti on siirretty Rahoitustarkastuksen tietojärjestelmään ja tarkistettu. Kuittaustiedosto koostuu otsikosta ja rungosta. Runko sisältää kutakin raportoitua tapahtumaa kohti kuittaustietueen. Kuittaustiedoston XML-skeema on ladattavissa osoitteesta

OHJE 16 (29) http://www.rahoitustarkastus.fi/rataweb/taxonomy/outtrans/transactionfe edback.xsd. Järjestelmä muodostaa kuittaustiedoston nimen ohjelmallisesti ja se viittaa siirrettävän kaupparaportin nimeen. 5.1 Kuittaustiedoston nimi Kun kaupparaportti on siirretty virheettömällä nimellä, kuittaustiedosto lähetetään raportoijalle pakattuna samalla nimellä, mutta FB-etuliitteellä TRetuliitteen sijasta. Esimerkki Kaupparaportin nimi Kaupparaporttiin liittyvän kuittaustiedoston nimi Pakatun kuittaustiedoston nimi TR_TESTFIHHXXX_20070918_0001.XML FB_TESTFIHHXXX_20070918_0001_0001.XML FB_TESTFIHHXXX_20070918_0001_0001.ZIP Jos siirretyn kaupparaportin nimi on ollut virheellinen, kaupparaportin käsittely lopetetaan ja järjestelmä lähettää seuraavasti nimetyn kuittaustiedoston raportoijalle: "FB_"<UlkoinenTiedostoNimi>"_"<SEQ>"."<TYPE> Osio FB UlkoinenTiedostoNimi SEQ TYPE Esimerkki Kaupparaportin nimi: Kuittaustiedoston nimi: Selitys Vakio ilmoittaa, että kyseessä on kuittaustiedosto Siirretyn kaupparaportin nimi 4-numeroinen sarjanumero Kuittaustiedoston tyyppi on aina XML TR_ UlkoinenTiedostoNimi.XML FB_ UlkoinenTiedostoNimi _0001.XML 5.2 Kuittaustiedoston otsikko Kuittaustiedoston otsikko sisältää tietoa siirretyn kaupparaportin oikeellisuudesta raporttitasolla. Otsikko sisältää seuraavat tiedot: TransactionReport ReceivedTimestamp FeedbackReport FileStatus Siirretyn kaupparaportin nimi Aika, jolloin siirretty kaupparaportti on otettu vastaan Palautetun kuittaustiedoston nimi (Siirretyn) tiedoston tila

OHJE 17 (29) Code Message Tilan tarkennne Viesti Seuraavassa taulukossa on lueteltu mahdolliset siirretyn tiedoston tilat (File- Status) 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 kauppatapahtumat ovat virheettömiä. Kauppatapahtumat on tallennettu vastaanottajan tietokantaan. OK Tiedosto on hyväksytty, mutta se sisältää virheellisiä kauppatapahtumia. Kauppatapahtumat on tallennettu vastaanottajan tietokantaan. Sisällön tarkastuksessa virheitä Tiedosto on hylätty. Yhtään kauppatapahtumaa 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 pakkausvirhe Tiedoston tilasta riippuen raportoijan on tehtävä seuraavat toimenpiteet: ACC AWE REJ Ei toimenpiteitä Korjattava virheelliset kauppatapahtumat ja lähetettävä korjatut kauppatapahtumat uudessa tiedostossa uudella järjestysnumerolla (Voi lähettää myös seuraavassa kaupparaportissa.) Korjattava virheet ja lähetettävä tiedosto samalla nimellä

OHJE 18 (29) 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 ICPC IISIN IPN ITD IVI MTI CIM ICC ICPC Kommentti Kauppataphtuma/peruutustapahtuma on virheetön. Ok Tapahtuma on ohitettu. Kaksi samaa kauppatapahtuman tunnistetta Kauppatapahtuma/peruutustapahtuma sisältää virheitä Virheellinen vastapuolitunnus Virheellinen ISIN-koodi Virheellinen valuuttakoodi Virheellinen kaupantekoaika Virheellinen kauppapaikan tunnus Puuttuva tapahtuman tunnus Puuttuva asiakastieto Puuttuva asiakastunnus Virheellinen asiakastunnus 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

OHJE 19 (29) 6 Esimerkkejä 6.1 Kauppatapahtuma 6.2 Peruutustapahtuma

OHJE 20 (29) 6.3 Kaupparaportti 7 Yhteyshenkilöt 7.1 Rahoitustarkastuksen yhteyshenkilöt Kaupparaportointivaatimukset Markkinavalvoja Ulla Larmi sähköposti ulla.larmi(at)rahoitustarkastus.fi puhelin 010 831 5268 Raportoinnin tekninen toteutus Suunnittelija Päivi Rissanen sähköposti paivi.rissanen(at)rahoitustarkastus.fi puhelin 010 831 5352 Suunnittelija Timo Lahtinen sähköposti timo.lahtinen(at)rahoitustarkastus.fi puhelin 010 831 5399

OHJE 21 (29) 7.2 TYVI-operaattorin yhteyshenkilöt Simo Kaartinen Itella Information Tietäjäntie 2 FI-02130 Espoo gsm +358 50 386 6258 faksi +358 9 478 55 660 sähköposti: simo.kaartinen(at)itella.net Kai-Jussi Ruuskanen Itella Information Tietäjäntie 2 FI-02130 Espoo puhelin +358 9 478 555 gsm +358 50 386 6273 faksi +358 9 478 55 660 sähköposti kai-jussi.ruuskanen(at)itella.net

OHJE 22 (29) 8 Kaupparaportin skeemakuvaus Oheisen skeemakuvauksen päiväys on 25.10.2007. Uusin versio skeemasta on saatavissa luvussa 4.2 mainitusta linkistä. <?xml version="1.0" encoding="utf-8"?> - <xs:schema xmlns:xs="http://www.w3.org/2001/xmlschema" targetspace="http://schemas.fi.se/trs/intrans" xmlns="http://schemas.fi.se/trs/intrans" elementformdefault="unqualified"> <xs:appinfo>trs - Transaction report</xs:appinfo> - <xs:documentation> - <Status> <Status>Production</Status> <>Production</> <Version>1.00</Version> - <Revisions> <Revision date="2007-01-31">currency code list complemented</revision> <Revision date="2007-02-15">new simple type, StringType40_noReq, assigned to element VenueReferenceNumber to allow empty element value.</revision> <Revision date="2007-02-15">new simple type, PriceAmount, assigned to elements PriceCurrency and PricePercentage. New type allows negative numbers. Previously assigned type was AmountType.</Revision> <Revision date="2007-02-15">simple types StringType20 and StringType70: for mininclusive changed from 1 to 0 (zero)</revision> <Revision date="2007-02-15">sequence restrictions for transaction record types removed.</revision> <Revision date="2007-03-05">new simple type: StringType11, sssigned to element ProxyHolder. Previously assigned type was StringType20.</Revision> <Revision date="2007-04-11">pricenotation/currency codelist changed to be of type string(3). VenueReferenceNumber and Client elements optional.</revision> <Revision date="2007-06-08">schema name convension changed and Fixed Version attibute added at root element</revision> <Revision date="2007-08-09">added unique to ReportingFirm Identification attribute and BICCodeType to upper case letters</revision> <Revision date="2007-08-15">changed the ClientCodeType to allow 70 chars</revision> <Revision date="2007-08-15">changed the Client to allow 70 chars</revision> <Revision date="2007-08-16">customerclient type 'C' added to CounterPartyCodeType</Revision> <Revision date="2007-08-16">internal type 'I' removed from CounterPartyCodeType</Revision> <Revision date="2007-08-16">counterpartycodetype use='required' removed</revision> <Revision date="2007-08-16">updatetransaction element removed</revision> <Revision date="2007-09-20">xs:choise changed to xs:sequence</revision> <Revision date="2007-09-20">schema harmonized with other TRS schemas</revision> <Revision date="2007-10-10">counterparty type changed to StringType40</Revision>

OHJE 23 (29) </Revisions> </Status> - <Subject> <Project>TRS</Project> <Category>Transaction</Category> </Subject> <Title>TRS - Transaction report format</title> <Type>Architectural</Type> <>Transaction report requested by the SE authority in accordance with then demands in MiFID</> <Language>English</Language> </xs:documentation> BIC code - <xs:simpletype name="biccodetype"> <xs:documentation>iso 9362 - SWIFT/Bank Identifier Code (BIC) - Format: 11(x)(A- Z 0-9)</xs:documentation> - <xs:restriction base="xs:token"> <xs:length value="11" /> <xs:pattern id="uppercaseletters11" value="[a-z 0-9]{0,11}" /> String with a max length of 11 - <xs:simpletype name="stringtype11"> <xs:documentation>format: max 11(x)</xs:documentation> - <xs:restriction base="xs:token"> <xs:minlength value="0" /> <xs:maxlength value="11" /> String with a max length of 20 - <xs:simpletype name="stringtype20"> <xs:documentation>format: max 20(x)</xs:documentation> - <xs:restriction base="xs:token"> <xs:minlength value="0" /> <xs:maxlength value="20" />

OHJE 24 (29) String with a max length of 40 - <xs:simpletype name="stringtype40"> <xs:documentation>format: max 40(x)</xs:documentation> - <xs:restriction base="xs:token"> <xs:minlength value="1" /> <xs:maxlength value="40" /> String with a max length of 40 - <xs:simpletype name="stringtype40_noreq"> <xs:documentation>format: max 40(x)</xs:documentation> - <xs:restriction base="xs:token"> <xs:minlength value="0" /> <xs:maxlength value="40" /> String with a max length of 70 - <xs:simpletype name="stringtype70"> <xs:documentation>format: max 70(x)</xs:documentation> - <xs:restriction base="xs:token"> <xs:minlength value="0" /> <xs:maxlength value="70" /> Date specified in the following form YYYY-MM-DDThh:mm:ss with optional timezone - <xs:simpletype name="datetimetype"> <xs:documentation>yyyy-mm-ddthh:mm:ss+/-hh:mm</xs:documentation> <xs:restriction base="xs:datetime" /> Buy / Sell indicator

OHJE 25 (29) - <xs:simpletype name="buyselltype"> <xs:documentation>buy / Sell indicator B = Buy, S = Sell</xs:documentation> - <xs:restriction base="xs:string"> <xs:pattern value="b S" /> Trading capacity - <xs:simpletype name="tradingcapacitytype"> <xs:documentation>p = Own account / portfolio. M = Market maker. C = Own account as agent for a customer. W = Warehousing. For the account, and on behalf, of a client: A = Customer / client (commissionaire).</xs:documentation> - <xs:restriction base="xs:string"> <xs:pattern value="p M C W A" /> String with a length of 12 - <xs:simpletype name="instrumenttype"> <xs:documentation>format: 12(x). Must be a valid ISO 6166 ISIN code.</xs:documentation> - <xs:restriction base="xs:token"> <xs:length value="12" /> Amount decimal - <xs:simpletype name="amounttype"> <xs:documentation>format: Max 19(d) and max 5 decimals numbers</xs:documentation> - <xs:restriction base="xs:decimal"> <xs:totaldigits value="19" /> <xs:fractiondigits value="5" /> <xs:mininclusive value="0" />

OHJE 26 (29) Price decimal - <xs:simpletype name="pricetype"> <xs:documentation>format: Max 19(d) and max 5 decimals numbers (can be negative)</xs:documentation> - <xs:restriction base="xs:decimal"> <xs:totaldigits value="19" /> <xs:fractiondigits value="5" /> Price notation - <xs:simpletype name="pricenotationtype"> <xs:documentation>must be a valid ISO 4217 currency code.</xs:documentation> - <xs:restriction base="xs:string"> <xs:pattern value="[a-z]{3,3}" /> Venue code - <xs:simpletype name="venuecodetype"> <xs:documentation>m = ISO 10383 Market Identifier Code(MIC). O = XOFF. Off market transaction</xs:documentation> - <xs:restriction base="xs:string"> <xs:pattern value="m O" /> Venue - <xs:simpletype name="venuetype"> <xs:documentation>must be a valid ISO 10383 Market Identifier Code(MIC) or 'XOFF' if off market transaction.</xs:documentation> - <xs:restriction base="xs:token"> <xs:length value="4" /> <xs:pattern id="uppercaseletters4" value="[a-z 0-9]{0,4}" />

OHJE 27 (29) Client code - <xs:simpletype name="clientcodetype"> <xs:documentation>b = BIC or I = Internal</xs:documentation> - <xs:restriction base="xs:string"> <xs:pattern value="b I" /> Counter party code - <xs:simpletype name="counterpartycodetype"> <xs:documentation>b = BIC, M = MIC, C = CustomerClient</xs:documentation> - <xs:restriction base="xs:string"> <xs:pattern value="b M C" /> Cancellation indicator - <xs:simpletype name="cancellationindicatortype"> <xs:documentation>c = Cancel the previously submitted transaction</xs:documentation> - <xs:restriction base="xs:string"> <xs:pattern value="c" /> Transaction definition - <xs:complextype name="transactionrecordinfocompletetype"> - <xs:sequence> <xs:element name="transactionreferencenumber" type="stringtype40" /> <xs:element name="tradingtimestamp" type="datetimetype" /> <xs:element name="buysellindicator" type="buyselltype" /> <xs:element name="tradingcapacity" type="tradingcapacitytype" /> <xs:element name="instrument" type="instrumenttype" /> <xs:element name="unitprice" type="unitpricecompletetype" /> <xs:element name="pricenotation" type="pricenotationtype" /> <xs:element name="quantity" type="amounttype" /> - <xs:element name="counterparty"> - <xs:complextype>

OHJE 28 (29) - <xs:simplecontent> - <xs:extension base="stringtype40"> <xs:attribute name="codetype" type="counterpartycodetype" use="required" /> </xs:extension> </xs:simplecontent> </xs:complextype> </xs:element> - <xs:element name="venue"> - <xs:complextype> - <xs:simplecontent> - <xs:extension base="venuetype"> <xs:attribute name="codetype" type="venuecodetype" use="required" /> </xs:extension> </xs:simplecontent> </xs:complextype> </xs:element> <xs:element name="venuereferencenumber" type="stringtype40_noreq" minoccurs="0" maxoccurs="1" /> - <xs:element name="client" minoccurs="0" maxoccurs="1"> - <xs:complextype> - <xs:simplecontent> - <xs:extension base="stringtype70"> <xs:attribute name="codetype" type="clientcodetype" use="required" /> </xs:extension> </xs:simplecontent> </xs:complextype> </xs:element> <xs:element name="client" type="stringtype70" minoccurs="0" maxoccurs="1" /> <xs:element name="clientidentificationlocal" type="stringtype20" minoccurs="0" maxoccurs="1" /> <xs:element name="clientstreet" type="stringtype70" minoccurs="0" maxoccurs="1" /> <xs:element name="clientzipcode" type="stringtype70" minoccurs="0" maxoccurs="1" /> <xs:element name="clientcity" type="stringtype70" minoccurs="0" maxoccurs="1" /> <xs:element name="clientcountry" type="stringtype70" minoccurs="0" maxoccurs="1" /> <xs:element name="proxyholder" type="stringtype11" minoccurs="0" maxoccurs="1" /> </xs:sequence> </xs:complextype> Cancellation definition - <xs:complextype name="cancellationtransactiontype"> - <xs:sequence> <xs:element name="cancelledtransactionuniqueidentifier" type="stringtype40" /> <xs:element name="cancellationindicator" type="cancellationindicatortype" /> </xs:sequence> </xs:complextype>

OHJE 29 (29) Unit price complete description - <xs:complextype name="unitpricecompletetype"> - <xs:choice> <xs:element name="pricecurrency" type="pricetype" /> <xs:element name="pricepercentage" type="pricetype" /> </xs:choice> </xs:complextype> Transaction schema - <xs:element name="report"> - <xs:complextype> - <xs:sequence> - <xs:element name="technicalreportingfirm"> - <xs:complextype> <xs:attribute name="identification" type="biccodetype" use="required" /> </xs:complextype> </xs:element> - <xs:element name="reportingfirm" minoccurs="1" maxoccurs="unbounded"> - <xs:complextype> - <xs:sequence> <xs:element name="transaction" type="transactionrecordinfocompletetype" minoccurs="0" maxoccurs="unbounded" /> <xs:element name="cancellationtransaction" type="cancellationtransactiontype" minoccurs="0" maxoccurs="unbounded" /> </xs:sequence> <xs:attribute name="identification" type="biccodetype" use="required" /> </xs:complextype> </xs:element> </xs:sequence> <xs:attribute name="version" type="xs:decimal" use="required" fixed="1.00" /> </xs:complextype> - <xs:unique name="uniqueidreportingfirm"> <xs:selector xpath="reportingfirm" /> <xs:field xpath="@identification" /> </xs:unique> </xs:element> </xs:schema>