Forordning om verdipapirfinansierings-transaksjoner (SFTR)

EU har vedtatt forordningen om verdipapirfinansieringstransaksjoner (Securities Finance Transaction Regulation, SFTR) for å bedre gjennomsiktighet og oversikt over markedet for verdipapirfinansiering. Forordningen inneholder krav om rapportering for motparter i forbindelse med:

• gjenkjøpsavtaler
• kjøp-tilbakesalg eller salg-tilbakekjøp
• verdipapirutlån og verdipapirlån
• marginutlån (prime brokerage)

SFTR-forordningen tilsvarer i stor grad EMIR-forordningen for derivatmarkedet og gir Den europeiske verdipapir- og markedstilsynsmyndigheten (ESMA) fullmakt til å godkjenne og regulere transaksjonsregistre og introduserer dobbelt rapporteringskrav for parter som inngår avtaler om ovennevnte transaksjonstyper.

Rapportering har oppstart 11. april 2020 for verdipapirforetak og kredittinstitusjoner (se mer under Tidslinje).

På denne siden finner du en kort beskrivelse av hva Nordea og du som kunde må gjøre for å oppfylle kravene. Du finner også informasjon om Nordeas status i forhold til SFTR..

Bruksområde og omfang

SFTR er en EU-forordning. Transaksjoner som utføres mellom parter stiftet i EU, må derfor oppfylle kravene i forordningen. SFTR går imidlertid utover EU-territoriet gjennom å omfatte transaksjoner utført av en EU-filial med en motpart i et tredje land.
Unntaket er transaksjoner med medlemmer i det europeiske sentralbanksystemet (ESCB), som er unntatt SFTR-rapportering siden de omfattes av MIFID II-kravene og ikke skal dobbeltrapportere.

SFTR er i hovedsak et rapporteringssystem. Forordningen pålegger partene i en transaksjon å rapportere opplysninger om transaksjonen til et transaksjonsregister på T+1 (T=transaksjonsdag) og deretter daglig rapportere eventuelle endringer samt sikkerheter og verdsettelse i transaksjonens løpetid. Regelverket omfatter et sett tabeller som spesifiserer hvilke opplysninger som må rapporteres (se Regelverk for mer informasjon). Forordningen er mer omfattende enn EMIR siden den i tillegg foreskriver et standardformat for kommunikasjon med transaksjonsregistrene, nemlig ISO20022-standarden for transaksjonsregistrering.

Rapporteringen omfatter fem avgrensede områder:

• transaksjons- og transaksjonsrelaterte sikkerheter
• sikkerhet (EOD)
• verdsettelse
• margindatarapportering for sentral motpart (CCP) i forhold til clearede verdipapirfinansieringstransaksjoner (SFT-er)
• gjenbruk av sikkerhet, reinvesterte kontanter og rapporter om finansieringskilder

Kundetyper

I likhet med EMIR og MiFID opererer SFTR med ulike typer parter i en transaksjon. Partene klassifiseres som finansielle (FC) eller ikke-finansielle (NFC). NFC-kategorien deles deretter inn i NFC-er og små NFC-er.
I henhold til ESMAs endelige tekniske standardrapport for SFTR er en liten NFC en som ikke overskrider grenseverdiene for minst to av tre kriterier:

• balanseregnskap på EUR 20 millioner
• nettoomsetning på EUR 40 millioner
• gjennomsnittlig 250 ansatte i regnskapsåret

Videre anses sentrale motparter (CCP-er) som en spesiell type motpart og har andre rapporteringskrav.

Tidslinje

ESMA har besluttet en gradvis implementering av SFTR i fire faser.
Den 11. april 2020 starter fase 1, som omfatter EU-baserte verdipapirforetak og kredittinstitusjoner.

Fase 2, som starter 11. juli 2020, omfatter sentrale motparter (CCP-er) og verdipapirsentraler (CSD) og verdipapirforetak og kredittinstitusjoner utenfor EU.

Fase 3, som starter 11. oktober 2020, omfatter UCITS-fond og AIF-fond, forsikringsselskaper og pensjonsforetak.

Fase 4, siste fase, omfatter ikke-finansielle foretak (NFC-er), der rapporteringen starter 11. januar 2021.

For Nordea starter rapporteringskravene i fase 1, mens mange av kundene våre ikke skal begynne å rapportere før om tre, seks eller ni måneder.

Retroaktivitet

De tekniske reguleringsstandardene inneholder et krav om retroaktivitet for SFTR-transaksjoner som gjennomføres før oppstarten (11. april), og som fremdeles er i kraft 180 dager etter oppstartsdato, som skal rapporteres 180–190 dager etter oppstart. I rådgivningsfasen var ESMA åpne for forskjellige tilnærminger, og det ventes en klargjøring samtidig med publiseringen av sluttrapporten i desember 2019. Transaksjoner som innledes før oppstartsdatoen og avsluttes før det har gått 180 dager, skal ikke rapporteres.

Nordea regner med å retroaktivt rapportere i henhold til den tekniske standarden for tilsyn (RTS) (180 dager etter oppstart) for å kunne fokusere på nye transaksjoner i startfasen, og fordi mange av partene i transaksjonene først begynner å rapportere tre eller seks måneder etter oppstartsdatoen. Hvis kunder har et sterkt ønske om tidligere retroaktiv rapportering, håndterer Nordea det fra sak til sak.

LEI-koder blir obligatorisk

Fra og med april 2020 blir identifiseringskoder for juridiske enheter (Legal Entity Identifier, LEI) obligatorisk hvis du som kunde ønsker å gjøre en transaksjon for verdipapirfinansiering. Uten en LEI-kode vil det ikke være mulig å rapportere din side av en transaksjon i et transaksjonsregister. Gå til avsnittet om LEI for mer informasjon.

Utsteder-LEI blir obligatorisk

EMSA har spesifisert i sine valideringsregler at verdipapirutsteders LEI er en obligatorisk opplysning for alle verdipapirer plassert som et lån, og for verdipapirer som er stilt som sikkerhet. Dette er sannsynligvis ikke et stort problem for europeiske instrumenter med høy kredittrating. For enkelte emisjoner med høyrisikoinstrument samt emisjoner utenfor EU kan imidlertid LEI være av dårlig kvalitet. Dermed kan SFTR indirekte begrense listen med ISIN-er som kan brukes til verdipapirfinansieringstransaksjoner eller som sikkerhet for en slik transaksjon.

Obligatoriske faste data

Kundeklassifisering (kundetype), sektorkode, ytterligere sektorkoder er viktige i SFTR-rapportering og må oppgis til den rapporterende parten hvis du velger å delegere rapporteringen.

Kundetypen er spesielt viktig siden den styrer startdatoen for når du må rapportere.

Unike transaksjonskoder (UTI) blir obligatoriske

Hver verdipapirfinansieringstransaksjon skal tildeles en global unik transaksjonskode – en UTI. Koden skal kommuniseres mellom partene i transaksjonen, og partene må komme overens om hvem som skal generere den. Hvis det ikke finnes en slik avtale, beskriver forordningen en kaskademodell som brukes til å bestemme hvilken part som skal generere koden. Parten som genererer koden, er pålagt å dele den med motparten via «et elektronisk format innen rimelig tid slik at begge parter kan oppfylle sine rapporteringskrav på T+1». Nordeas tilnærming til generering av UIT-kode beskrives i delen om UTI-utvekslingsprosesser.

For transaksjoner på elektroniske markeder og ved handel med sentral clearing og sentral bekreftelse er det systemleverandøren som tildeler og deler UTI-koden.

Obligatorisk og frivillig delegering

Delegert rapportering innebærer at den rapporterende parten (vanligvis den finansielle motparten i en transaksjon) utfører rapporteringen til transaksjonsregisteret for begge parter.

SFTR-forordningen opererer med obligatorisk delegering for små NFC-er. Dette betyr at hvis en part i en transaksjon klassifiseres som en liten NFC, er det FC som blir ansvarlig for SFTR-rapporteringen. NFC skal forsyne FC med de faste dataene som FC trenger til rapporteringen. Dette omfatter å skaffe og opprettholde en gyldig LEI-kode, men ansvaret (og ansvarligheten) for rapporteringen ligger hos den finansielle motparten. Obligatorisk delegert rapportering begynner å gjelde samtidig som fase 4 i januar 2021 (Tidslinje)

Frivillig delegert rapportering er også tillatt i henhold til SFTR. I slike tilfeller blir partene i en transaksjon enige om at den ene parten skal ta seg av rapporteringen av samtlige transaksjoner mellom partene. Det er annerledes enn obligatorisk delegering fordi det er den delegerende parten som har ansvaret og er ansvarlig for at rapporteringen er riktig og fullstendig, ikke den rapporterende parten.

Nordea vil støtte både obligatorisk og frivillig rapportering fra april 2020. Rapporteringen skjer etter beste evne (gitt den høye graden av paring og matching som er spesifisert i forordningen, er det i den finansielle motpartens interesse at begge sidene av en transaksjon rapporteres så riktig og fullstendig som mulig). Både obligatorisk og frivillig delegert rapportering vil være kostnadsfritt, og det forventes at de økte reguleringskostnadene gjenspeiles i prisen på underliggende transaksjoner.

Rapporteringsfragmentering

Kunder med verdipapirfinansieringstransaksjoner med flere finansielle motparter kommer til å merke en viss fragmentering i rapporteringen. Dette kan, selv om ulike motparter rapporterer til ulike transaksjonsregistre, være tilfellet for rapporteringen av både transaksjoner og sikkerheter. Hvis kunden utfører clearing via sentrale motparter, må imidlertid marginrapporteringen utføres av en av de finansielle motpartene som assistert rapportering, eller av den sentrale motparten. Likeledes, hvis kunden gjenbruker en stilt sikkerhet, må gjenbruksrapporteringen utføres av en av de finansielle motpartene. Ved delegert rapportering ville derfor en kunde daglig måtte informere om gjenbruk og, hvis relevant, den sentrale motpartens margininformasjon til en av sine finansielle motparter.

Assistert rapportering

Ved assistert rapportering tilbyr den rapporterende parten, vanligvis en finansinstitusjon eller en leverandør av finansielle tjenester, å bygge ISO20022-strukturen for meldinger ved hjelp av informasjonen som er tilgjengelig for den rapporterende parten. Deretter gjøres filene tilgjengelig for kunden, som kan legge til opplysningene den rapporterende parten mangler. Assistert rapportering kan omfatte støtte for levering av de fullførte filene til et transaksjonsregister. Dette er imidlertid mindre trolig siden kunder som velger assistert rapportering, gjør det for å ha kontroll over rapporteringsprosessen og muligens for å unngå å måtte dele informasjon som for eksempel gjenbruksprosent, hvilke instrumenter kunden har osv., til en finansiell motpart.

Nordea vil ikke tilby assistert rapportering for SFTR ved oppstart i april 2020.

Prosesser for paring og matching i transaksjonsregister (TR)

SFTR har i høy grad fokus på en god og konsekvent kvalitet på opplysningene som skal rapporteres til transaksjonsregistrene. Forordningen er tydelig på at man ikke ønsker overrapportering, og at partene skal bli enige om hvem som skal generere UTI-koden. Hvis du mangler en UTI fra motparten og dere ble enige om at denne skulle generere koder, har du ikke tillatelse til å generere din egen for å overholde rapporteringsfristene, da dette er å betrakte som overrapportering.
På samme måte som EMIR kommer transaksjonsregistrene til å prøve å pare de to sidene i en transaksjon ved hjelp av de angitte UTI-kodene. Transaksjonsregistre tar seg av paring både i sitt eget register og med andre transaksjonsregistre. Transaksjonsregistrene vil utveksle informasjon om transaksjoner for verdipapirfinansiering som ikke er paret, mellom transaksjonsregistrene, for å tillate paring og matching mellom transaksjonsregistrene.

Etter paring vil transaksjonsregistrene utføre matchingen i henhold til spesifikasjonene angitt av ESMA i de tekniske standardene for tilsyn og for implementering (hhv. RTS og ITS) i SFTR. Opptil 100 av de 155 rapporterbare feltene er markert som matchingsfelt med begrenset toleranse. Implementeringen av matching skjer i faser, og det startes med grunnleggende informasjon. Matchingen strekker seg over flere år.

 

Førmatching

Førmatching er ikke et krav i SFTR, men med tanke på de stramme tidsfristene for rapportering på T+1, antallet matchingsfelt og de begrensede matchingtersklene i ESMA åpner det seg et marked for løsninger som gjør at parter kan håndtere matchingsavvik allerede på transaksjonsdato (T) for å løse så mange avvik som mulig før rapporteringsfristen.

Flere tjenesteleverandører tilbyr førmatchingstjenester som gir partene mulighet til å rapportere transaksjonsopplysningene til en sentral enhet, som deretter utfører matching, UTI-tildeling og eventuelt også håndterer rapporteringen for transaksjonsregisteret. Siden det finnes flere tjenesteleverandører, er markedet fragmentert, og noen motparter vil være på én plattform, andre på en annen, noen vil støtte flere, og noen vil velge å ikke utføre førmatching i det hele tatt. Jo større fragmentering, jo mindre verdt er førmatchingsløsningene.

Nordea har valgt å slutte seg til IHS Markit/Pirums førmatchingsplattform for sin intradagrapportering av alle transaksjoner for verdipapirfinansiering der vi er motpart på transaksjonsdagen (T) med periodiske overføringer (hver eller annenhver time i arbeidstiden + overføring av sikkerhet- og transaksjonsstatus ved slutten av dagen). Dette betyr også at vi kommer til å sette opp prosesser for intradagførmatching for å rydde ut så mange førmatchingsavvik som mulig før rapporteringsfristen, T+1.

 

UTI-utvekslingsprosesser

En av de viktigste erfaringene fra EMIR var at utvekslingen av UTI-er på muntlig formidlede transaksjoner og andre bilaterale transaksjoner utenfor handelsplasser, var den viktigste årsaken til manglende eller feil rapportering. Med utgangspunkt i dette har SFTR lagt større vekt på ansvaret for å generere og utveksle UTI-er. Det finnes imidlertid ingen globalt støttet «mal» som ville gitt partene i en transaksjon mulighet til å uavhengig av hverandre tildeles samme UTI, derav behovet for å utveksle UTI-en.
Her ser vi flere løsninger og tjenesteleverandører – og førmatchingen vi beskriver ovenfor, er en av dem. Men der det finnes mange løsninger, blir markedet fragmentert, og vi får se om noen av disse løsningene utvikles til standarder på globalt eller regionalt/lokalt nivå eller innenfor visse motpartsnettverk.

Begge parter i en transaksjon må vurdere hvordan de ønsker å støtte UTI-prosessen: om de ønsker å alltid være den som skal generere UTI-en (og ha «privilegiet» med å dele UTI-en innen rimelig tid i et elektronisk format), om de vil innhente UTI-en fra motparten eller bruke en førmatchingsplattform til å generere og utveksle UTI-en, eller om de ønsker å gjøre utvekslingen bilateralt med partene i transaksjonene.

Nordea skal bruke IHSMarkit/Pirums løsning for å tildele og dele UTI-koder med de andre deltakerne på plattformen. I tillegg kommer plattformen, via en kundeportal eller et SFTP-grensesnitt, til å gi ikke-rapporterende parter muligheten til å få UTI-koder tildelt sine LEI-koder. Før dette vil rapporteringsløsningen vår hente UTI-er som genereres på elektroniske handelsplasser, utføringstjenester og tilpasningsplattformer. Ved delegert rapportering påtar Nordea seg automatisk oppgaven med å generere UTI-kode.

For resterende transaksjoner (muntlig formidlede transaksjoner med parter på ulike førmatchingsplattformer eller som ikke er på en førmatchingsplattform i det hele tatt) undersøker sektoren to alternativer som bygger på en minimumsfeltliste for utveksling av UTI- og transaksjonsopplysninger, slik at partene skal kunne gjennomføre transaksjonsmatching og utveksling av UTI. Slike minimumsfeltlister kan brukes mellom to forskjellige matchingsplattformer og bilateralt mellom de to partene.
Nordea skal etablere bilaterale UTI-utvekslings-/søkeprosesser som kjøres klokken 09:00 CET på T+1 og deretter gjentas med jevne mellomrom til alle UTI-kodene har blitt utvekslet/innhentet.

Transaksjonsregistre

SFTR-forordningen gir ESMA fullmakt til å godkjenne og overføre transaksjonsregistre. Et transaksjonsregister er en sentral database som gjør det mulig for oss som parter i en transaksjon for verdipapirfinansiering, å sende opplysninger om disse til en sentral datasentral. Transaksjonsregistret er deretter pålagt å gjøre disse opplysningene tilgjengelige for ulike tilsynsmyndigheter, inkludert lokale finanstilsyn og ESMA selv.
Det finnes flere transaksjonsregistre på markedet som har blitt godkjent, eller vil bli godkjent, som transaksjonsregistre i henhold til SFTR, blant annet:

• DTCC (EU og Storbritannia)
• Regis TR (EU og Storbritannia)
• UnaVista

Med SFTR blir valget av register noe enklere enn med EMIR på grunn av standarden for sending av data til og fra transaksjonsregistret (iso20022). Mange tjenesteleverandører påstår at de stiller seg uavhengig til valget av transaksjonsregister og kan overføre transaksjonene til transaksjonsregistret som er valgt av motparten.

Nordea har besluttet å bruke DTCC (EU) som sitt hovedtransaksjonsregister for SFTR. For delegert rapportering (se Obligatorisk og frivillig delegering) vil rapporteringen av kundesiden av transaksjonene også skje til DTCC (EU).
Som part i transaksjoner for verdipapirfinansiering bør du overveie ditt valg av transaksjonsregister. Av transparens- og avstemmingshensyn anbefaler vi at du bare bruker ett transaksjonsregister. Lokale finanstilsyn får data fra transaksjonsregistrene som du kan bli bedt om å verifisere og forklare. Vår anbefaling til alle kunder, med unntak av små NFC-er, er å slutte seg til et transaksjonsregister i forbindelse med SFTR og meddele denne informasjonen til finansielle motparter.

Regelverk

EU-forordningen SFTR stammer fra G20-toppmøtet i etterkant av finanskrisen, der det ble besluttet å etablere bedre tilsyn med finansmarkedene, og fra anbefalinger fra Financial Stability Board (FSB) om overvåkning og regulering av det som kalles «skyggebankvirksomhet». Den ble publisert i Official Journal of the European Union den 23. desember 2015. Last ned her.

I SFTR gir EU ESMA fullmakt til å utforme de tekniske standardene for tilsyn (RTS) og de tekniske standardene for implementering (ITS) for SFTR-forordningen. Detaljert informasjon fra ESMA om dette finner du her.

Informasjon til kunder og innsamling av opplysninger

Et viktig element for å få en så god oppstart av SFTR-rapportering som mulig, er at partene har avstemt forventninger og delt relevant statisk data før oppstartdatoen. For å oppnå dette, vil Nordea ta kontakt med kunder og be dem oppgi nødvendig informasjon, slik at vi kan starte opp med nøyaktig transaksjonsrapportering når det relevante kravet til transaksjonsrapportering i henhold til SFTR trer i kraft fra 11. april 2020.

Nordeas kommunikasjon med kundene tar sikte på å samle inn nødvendig statisk data, inkludert LEI-kode og type part samt preferanser i tilknytning til rapporteringsmodell, førmatching og generering av UTI.