LEI og EMIR Refit: Rapportering uden fejl

EMIR Refit har gjort én ting meget tydelig: rapportering skal ikke bare være rettidig, den skal også være ensartet, validerbar og let at sammenkoble på tværs af modparter og trade repositories (TR). Mange virksomheder oplever, at det ikke er de store systemfejl, der vælter læsset, men små datamangler, en udløbet LEI eller en UTI, der ikke matcher modpartens.

Fejlfri EMIR-rapportering handler derfor lige så meget om datadisciplin som om selve indberetningen.

Hvad EMIR Refit ændrer i praksis

EMIR (artikel 9) kræver fortsat, at derivatkontrakter rapporteres senest den efterfølgende arbejdsdag, og at ændringer og afslutninger også rapporteres. Refit-delen strammer især op på standardisering og datakvalitet.

Det mest mærkbare skifte er, at rapporteringsformatet er harmoniseret med et ISO 20022 XML-format, som skal bruges end-to-end i indberetningen til TR’er. Når alle rapporterer i samme skema, bliver der mindre plads til “lokale fortolkninger”, men også mindre plads til kreative workarounds.

Samtidig er datamængden vokset markant. Mange omtaler det som omkring 200 felter pr. rapport, og det er netop her, kompleksiteten rammer: Flere felter betyder flere steder, hvor et enkelt “blankt” felt, en forkert kode eller en ulogisk kombination kan udløse afvisninger, advarsler eller dårlig match-rate mellem modparter.

Og så er der et ansvarsspor, som flere undervurderer: Refit har tydeliggjort rapporteringsansvaret, blandt andet ved at finansielle modparter (FC) i mange tilfælde får et tungere ansvar for rapportering ved handler med NFC- (små ikke-finansielle modparter).

LEI som grundsten, og typisk fejlårsag

LEI (Legal Entity Identifier) er et simpelt datapunkt i rapporten, 20 tegn, fast format. Alligevel er det et af de felter, der oftest skaber problemer i praksis, fordi LEI både skal være korrekt og aktiv.

Det er ikke nok, at en LEI “findes”. Hvis den er udløbet, kan modparten i værste fald ikke rapportere konsistent, og TR’ens validering kan give fejl eller advarsler. Og når EMIR Refit lægger op til mere stringent kontrol og genafstemning, bliver udløb og uoverensstemmelser synlige hurtigere.

Et andet klassisk problem er, at der rapporteres med interne modpartskoder, navnetekst eller en “næsten rigtig” LEI, fx en koncernforbundet enhed i stedet for den juridiske modpart. Tilsynsmyndigheder i EU har gentagne gange peget på netop LEI-felter og matchningen mellem modparter som et område med mange datakvalitetsbrister.

UTI, UPI og matchning: hvor rapportering ofte knækker

To rapporter om samme handel skal kunne matches. Det kræver især en fælles UTI (Unique Transaction Identifier), og at de centrale felter i øvrigt er udfyldt på en måde, der er logisk ens på begge sider.

Hvis UTI ikke deles korrekt, eller hvis den ene part genererer en ny UTI ved en ændring, mens den anden part fortsætter med den gamle, ender TR’en med uparrede handler. Det skaber oprydningsarbejde og øger risikoen for, at fejl bliver “permanente” i rapporteringshistorikken.

UPI (Unique Product Identifier) spiller også ind, især på OTC-derivater, hvor produktklassifikationen skal være entydig. Mange virksomheder løser dette via leverandører eller rapporteringsgateways, fordi man sjældent ønsker at vedligeholde produkt- og referencekoder manuelt.

Her giver EMIR Refit en ret klar besked: rapportering er ikke længere et sted, hvor man kan “taste sig igennem”.

Et pragmatisk kontrolsetup, der reducerer fejl

Det mest effektive setup er ofte et, der kombinerer klare roller med automatiserede kontroller og en fast fejlrettelsesproces. Kontrollerne behøver ikke være tunge, men de skal være konsekvente og dokumenterede.

En praktisk måde at tænke det på er at definere få, men hårde stopklodser før indsendelse til TR, og derefter en rutine for genafstemning efter indsendelse, så uparrede eller afviste handler fanges hurtigt.

Mange virksomheder får ekstra stabilitet ved at indføre følgende arbejdsgange efter en indledende afklaring af ejerskab mellem front office, back office, treasury, compliance og IT:

  • Datagovernance: rollefordeling, tjekpunkter, godkendelsesflow
  • Validering: formatkontrol af LEI, UTI og obligatoriske felter
  • Genafstemning: match af rapporter mod interne handler og porteføljer
  • Fejlrettelse: faste tidsfrister, ansvar og dokumentation

Når det er sat rigtigt op, bliver EMIR-rapportering mere en daglig drift end et tilbagevendende brandberedskab.

Tabel: Kontrolpunkter der typisk fanger flest fejl

Tabellen her kan bruges som en enkel “pre-flight check” før indsendelse og som fokusliste i data quality reviews.

KontrolpunktTypisk fejlKontrol der virker i praksis
LEI (egen og modpart)Udløbet LEI, forkert juridisk enhedAutomatisk opslag mod GLEIF og stop ved “Lapsed”
“Entity responsible for reporting”Forkert LEI i ansvarsfeltRegelbaseret udfyldning ud fra aftaler og modpartstype
UTIUens UTI mellem modparterProces for UTI-deling, plus match-kontrol dagen efter
Produkt- og referencefelter (fx UPI/ISIN hvor relevant)Forkert format eller manglende kodeSkemavalidering og reference-data fra leverandør
Tidsfrister (T+1)Forsinket indsendelse ved manuelle ledAutomatiske kørsler og monitorering af indsendelsesstatus

ISO 20022 og valideringsregler: derfor bliver “næsten rigtigt” til “forkert”

ISO 20022 XML gør rapporteringen mere maskinlæsbar, men også mindre tolerant. Når TR’er anvender harmoniserede valideringsregler, bliver fejl ens behandlet på tværs af EU, og fejlretning kan i højere grad standardiseres.

Det ændrer også samarbejdet mellem forretning og IT. Det er ikke længere nok at sige “vi sender filen”. Man skal vide, hvad der blev accepteret, hvad der gav advarsler, og hvad der blev afvist.

En god vane er at gemme TR-feedback som en del af audit trail, og at måle på faste indikatorer: antal afvisninger, antal advarsler, antal uparrede handler og gennemsnitlig tid til rettelse.

Sanktioner og tilsyn: hvorfor datakvalitet er en økonomisk disciplin

EMIR stiller krav om nationale sanktioner ved brud. Bødeniveauer varierer, men i flere EU-lande kan de være i millionklassen ved alvorlige eller gentagne overtrædelser, og datakvalitet er et område, myndighederne aktivt følger op på.

For mange virksomheder er den mest mærkbare omkostning dog ikke bøden, men driftstiden: timer brugt på fejlretning, ekstra afstemninger, dialog med modparter, og interne eskalationer fordi rapporteringen ikke matcher.

Når man regner det sammen, bliver det ofte billigere at investere i kontroller og vedligehold, end at betale for gentagne oprydninger.

LEI-livscyklus: opret, vedligehold, forny, flyt

LEI er ikke en engangsøvelse. Den skal vedligeholdes og fornyes, og stamdata skal være korrekte. I praksis betyder det, at man bør have en “LEI-ejer” internt, som sikrer at udløbsdatoer ikke overses, og at virksomhedens registrerede oplysninger følger virkeligheden, fx ved navneændring eller adresseændring.

For koncerner og grupper med mange juridiske enheder er det oplagt at standardisere LEI-håndteringen, både for at spare tid og for at sikre ensartethed. Der kan også være situationer, hvor man vil flytte en eksisterende LEI til en anden udbyder, hvis man ønsker bedre pris, hurtigere service eller mere automatisering.

Det er her, en dansk registreringsagent som LEI Service ApS typisk bruges som praktisk driftspartner, fordi det kan gøres CVR-baseret med færre manuelle trin, og fordi fornyelser kan sættes til at køre automatisk. Hos LEI Service ApS er GLEIF-gebyret inkluderet i prisen, og der tilbydes dansk kundeservice på telefon og e-mail samt mulighed for EAN-faktura og mængderabat ved mange LEI’er.

Mange vælger også en agent af en mere lavpraktisk grund: risikoen for, at en LEI udløber, falder, når der ligger en aktiv påmindelses- og fornyelsesproces.

Tre steder hvor fejl typisk starter

De fleste fejl kan spores tilbage til få kilder: manglende dataejerskab, manuel indtastning og utilstrækkelig genafstemning. Hvis man vil bruge kræfterne rigtigt, giver det mening at starte dér.

  • Manuelle felter: LEI, UTI og modpartsrolle tastes eller kopieres forkert
  • Stamdata: NFC-status, enhedsnavn eller enhedstype er ikke opdateret
  • Koordinering: modparter bruger ikke samme UTI eller samme fortolkning af hændelser

Hvad automatisering realistisk kan tage væk fra bordet

Automatisering behøver ikke betyde et stort systemskifte. Selv små greb kan reducere fejlrate markant, især når de lægges på de felter, der oftest giver afvisninger.

Der er tre typer automatik, som typisk giver hurtig effekt:

  • Opslag og validering: LEI tjekkes automatisk mod GLEIF, og formatfejl stoppes før indsendelse
  • Skemavalidering: ISO 20022-filen kontrolleres mod valideringsregler, før TR’en ser den
  • Overvågning: dashboards der viser afvisninger, advarsler og uparrede handler pr. dag

Når det kører stabilt, frigør det tid til det svære: fortolkning af forretningsregler, håndtering af undtagelser og dialog med modparter.

En prisbevidst plan for de næste 30 dage

Hvis målet er færre EMIR-fejl og mindre efterarbejde, kan en kort og stram plan give mere effekt end en lang analyse.

Start med at kortlægge, hvilke LEI’er I bruger i rapporteringen (egen, modparter, CCP’er, eventuelle “responsible for reporting”-felter), og kontroller status på dem. Sæt derefter et fast “cut-off” for, hvornår data skal være klar til T+1, og hvem der ejer hvad.

Mange virksomheder får hurtig værdi ved at samle LEI-administration ét sted, især hvis der i dag er spredt ansvar. Her kan en agent med automatisk fornyelse og gratis stamdataopdateringer være en enkel måde at mindske risikoen for udløb, uden at det kræver interne udviklingsprojekter.

Når LEI-delen er stabil, bliver næste trin at få UTI-delingen til at sidde fast i processen, og at måle på match-rate og afvisninger uge for uge. Det er ofte dér, de største forbedringer kan ses i praksis.

back to top