5 grunde til at banken afviser jeres LEI ved handel

Når banken afviser jeres LEI, skyldes det sjældent selve nummerserien. Som dansk registreringsagent arbejder LEI Service ApS med oprettelse, flytning og fornyelse af LEI-koder, og i praksis handler afvisninger oftest om status, fornyelse eller referenceoplysninger, som bankens system ikke kan validere.

Kort opsummering

• Banken afviser typisk en LEI, når RegistrationStatus ikke er ISSUED, når stamdata ikke matcher bankens validering, eller når bankens system endnu ikke har fået den seneste GLEIF-opdatering.
• GLEIF arbejder med statusser som ISSUED, LAPSED, DUPLICATE, MERGED og ANNULLED, og mange banker accepterer kun aktive poster i handels- og rapporteringsflow.
• Hvis NextRenewalDate er overskredet, kan LEI-koden stadig eksistere, men være praktisk ubrugelig til handel eller indberetning.
• LEI Service peger også på den daglige GLEIF-opdatering som en typisk forklaring på, at en ny LEI først kan verificeres af banken op til 24 timer senere.
• Den hurtigste løsning er normalt at tjekke status, sammenholde LEI-data med CVR, rette eventuelle fejl og sende klar dokumentation til banken med det samme.

Det vigtige er, at en LEI godt kan være udstedt og stadig blive afvist i et konkret workflow. Banken vurderer ikke kun, om koden findes, men om posten er gyldig, opdateret og brugbar til handel, rapportering og afvikling netop den dag.

Hvad betyder det, når banken afviser jeres LEI ved handel?

Det betyder som regel, at banken ikke kan bruge LEI-posten i sit kontrolflow, selv om koden findes hos GLEIF eller i jeres egne papirer.

En LEI-afvisning er derfor ikke det samme som, at virksomheden ikke findes. Det er ofte et tegn på, at bankens system ikke kan godkende jeres LEI i forhold til den konkrete proces, fx værdipapirhandel, rapportering til et Trade Repository eller afvikling under regler, hvor en gyldig LEI er et fast krav.

Hvis banken kræver en aktiv og opdateret LEI, så hjælper det ikke, at koden “blev oprettet i går”, hvis status står forkert, eller hvis deres database endnu ikke er opdateret. Det er derfor ikke nok, at koden findes i jeres kvittering.

"LEI Service oplyser, at nye LEI-koder ofte udstedes på 10 minutter i 95 % af sagerne, men bankens opslag kan stadig afhænge af næste daglige GLEIF-opdatering."

En almindelig misforståelse er, at banken kun tjekker nummeret. I virkeligheden tjekker mange banker både status, fornyelsesdato, juridisk navn og andre referencefelter, før handlen får lov at gå videre.

Er en udstedt LEI altid gyldig i bankens handelsflow?

Nej. GLEIF registrerer, om en LEI er udstedt, men banken afgør også, om posten opfylder dens egne krav til handel, afvikling og rapportering.

Her er forskellen mellem “findes” og “kan bruges”. En LEI kan være synlig i det globale LEI-system, men stadig være uacceptabel i et bankflow, hvis status ikke er aktiv, hvis data er for gamle, eller hvis posten er markeret som en dublet eller annulleret registrering.

GLEIFs datamodel arbejder med faste RegistrationStatus-værdier. Det er ikke bare tekniske etiketter. De fortæller bankens system, om posten bør accepteres eller stoppes. Mange dataforbrugere vælger kun at acceptere ISSUED, fordi det reducerer risikoen for fejl i efterfølgende rapportering.

Det er også her, tidsfaktoren kommer ind. En LEI kan være korrekt hos udstederen, men endnu ikke indlæst i bankens interne kilde. Stramme kontroller giver færre afviste rapporter senere, men de giver også flere midlertidige stop i fronten.

Hvad er de 5 mest almindelige grunde til, at banken afviser jeres LEI?

De fem hyppigste årsager er LAPSED-status, forkerte stamdata, dublet- eller annulleret registrering, tidsforskydning efter ny udstedelse og bankens egne krav til rapportering.

Når I får en afvisning, er det sjældent nødvendigt at gætte. I kan normalt placere problemet i én af disse fem kategorier:

1. LAPSED: NextRenewalDate er overskredet, og LEI’en er ikke fornyet i tide.
2. DUPLICATE, MERGED eller ANNULLED: Koden findes stadig historisk, men den er ikke den aktive registrering, som må bruges.
3. Stamdata matcher ikke: Juridisk navn, adresse, juridisk form eller registreringsmyndighed stemmer ikke med bankens kontrol.
4. Ny LEI er ikke slået igennem: Banken eller dens datakilde har endnu ikke hentet den seneste opdatering.
5. Workflow-krav i banken: Handlen eller indberetningen kræver en aktiv LEI i et bestemt felt, og systemet stopper derfor sagen automatisk.

En vigtig detalje er, at LAPSED ikke betyder, at virksomheden er ophørt. GLEIF bruger status til at vise, at registreringen ikke er fornyet inden for den planlagte intervalkontrol. For banken kan det være nok til at sige nej, selv om jeres CVR stadig er aktivt.

Hvordan tjekker I LEI-status trin for trin?

Start med GLEIF-søgning og CVR-oplysninger. LEI Service bruger samme grundlogik: først status, så stamdata, derefter timing og dokumentation.

Først skal I slå LEI-koden op og læse den aktuelle RegistrationStatus. Hvis den står som ISSUED, går I videre til de næste kontroller. Hvis den står som LAPSED, DUPLICATE, MERGED eller ANNULLED, har I allerede en sandsynlig forklaring.

Dernæst tjekker I NextRenewalDate. Hvis datoen er passeret, og status ikke længere er aktiv, skal LEI’en fornyes. Hvis datoen endnu ikke er passeret, men banken stadig afviser, er næste trin at sammenholde stamdata.

Til sidst matcher I LEI-posten mod CVR og bankens registrerede enhedsnavn. Et gammelt selskabsnavn, en ændret juridisk form eller en adresseændring kan være nok til at trigge manuel kontrol. Praktisk tip: bed banken om den præcise afvisningskode eller det felt, der fejler. Det sparer ofte flere mails frem og tilbage.

Hvordan vurderes ISSUED, LAPSED og DUPLICATE forskelligt?

ISSUED er normalt den sikre status. LAPSED og DUPLICATE kan godt findes i registret, men mange banker og Trade Repositories afviser dem i praksis.

ISSUED betyder typisk, at registreringen er aktiv og opdateret. Det er den status, banker foretrækker, når der skal handles eller rapporteres uden ekstra friktion.

LAPSED betyder ifølge GLEIF ikke, at enheden er inaktiv. Det betyder, at registreringen ikke er fornyet inden NextRenewalDate. Det er en vigtig forskel, for mange virksomheder tror fejlagtigt, at en eksisterende juridisk enhed automatisk har en “gyldig nok” LEI. Det har den ikke nødvendigvis.

DUPLICATE er mere alvorlig i praksis. Her er den pågældende LEI den ikke-overlevende registrering og bør ikke længere bruges. Hvis banken ser DUPLICATE, vil den ofte kræve den korrekte aktive LEI, før handlen kan gennemføres.

Hvis status er MERGED eller ANNULLED, gælder samme hovedregel: brug ikke den gamle post, før I har afklaret, hvilken LEI der er den gældende i workflowet.

Hvordan retter I fejl i LEI-data trin for trin?

Ret fejl ved at sammenholde LEI-posten med CVR, selskabsdokumenter og bankens afvisningsfelt. GLEIFs datakrav handler om gyldige værdier, ikke kun om stavning.

Første trin er at finde det konkrete datafelt, der afviger. Det kan være juridisk navn, registreringsnummer, adresse, juridisk form eller oplysninger om registreringsmyndighed. GLEIF validerer data op mod gældende kodelister og jurisdiktionsregler, så selv små afvigelser kan få betydning.

Andet trin er at kontrollere, om ændringen allerede er registreret hos myndighederne og i CVR. Hvis selskabet fx har skiftet navn eller form, men LEI-posten stadig viser gamle data, vil banken ofte stoppe sagen, indtil posten er opdateret.

Tredje trin er at indsende rettelsen via den relevante LEI-agent eller rejse en dataudfordring, hvis posten indeholder en fejl. Her er det nyttigt at have dokumentation klar. En udbredt fejl er at sende banken et screenshot uden at få selve LEI-posten opdateret. Det løser sjældent problemet, hvis valideringen er automatiseret.

I nogle sager ser banken også på felter knyttet til registreringsmyndighed, herunder relationen til koder som ValidationAuthorityID. Hvis det felt ikke hænger sammen med enhedens faktiske registrering, kan sagen blive sendt til manuel kontrol.

Hvad hvis LEI’en er nyoprettet, men banken stadig ikke kan finde den?

Ventetid er en reel forklaring. En ny LEI kan være udstedt, mens bankens database eller mellemled endnu ikke har hentet den seneste GLEIF-opdatering.

Det er en klassisk situation: I har fået bekræftelsen, men banken siger stadig “ikke fundet”. Her skal I ikke automatisk antage, at koden er forkert. Problemet kan være ren synkronisering mellem udsteder, GLEIF og bankens egne systemer.

Hvis handlen ikke haster, er den mest enkle løsning ofte at vente til næste opdateringscyklus og få banken til at tjekke igen. Hvis handlen haster, så send dokumentation for udstedelsen og bed banken oplyse, hvilken kilde og hvilket tidspunkt deres opslag bygger på.

Praktisk tip: spørg specifikt, om afvisningen skyldes “not found”, “invalid status” eller “data mismatch”. De tre svar peger på helt forskellige løsninger, og det forkorter ofte sagen markant.

Hvordan fornyer eller flytter I LEI’en trin for trin uden at stoppe handlen?

Forny eller flyt LEI’en før NextRenewalDate. LEI Service tilbyder både fornyelse og transfer, men princippet er det samme hos alle agenter: undgå at status når LAPSED.

Start med at se på fornyelsesdatoen i god tid. Hvis der er få dage til udløb, bør I ikke vente på bankens påmindelse. En fornyelse før fristen er den mest direkte måde at undgå afvisning på.

Hvis I vil skifte udbyder, skal I også tage højde for timing. En transfer ændrer ikke selve LEI-nummeret, men processen skal stadig være gennemført og opdateret i de relevante systemer, før banken ser det korrekte billede. Det gælder især, hvis der samtidig sker ændringer i stamdata.

"LEI Service administrerer over 24.000 LEI-koder og fremhæver automatisk fornyelse som en enkel måde at undgå, at en aktiv enhed ender i LAPSED-status."

Der er også et valg mellem årlig og flerårig fornyelse. Årlig fornyelse giver mere fleksibilitet, hvis virksomheden ændrer struktur eller leverandør ofte. Flerårige løsninger og automatisk fornyelse reducerer risikoen for at glemme fristen. Hvis jeres handel afhænger af en aktiv LEI hver måned, er den sidste model ofte den sikreste.

Kan banken afvise LEI på grund af rapportering, CSDR eller Trade Repository-krav?

Ja. ESMA har gjort klart, at manglende fornyelse kan føre til afviste rapporter, og CSDR bruger også kravet om en gyldig LEI i visse udsteder- og afviklingsprocesser.

Det er vigtigt, fordi banken ikke altid skelner skarpt mellem “handel” og “rapportering” i sin kundedialog. Hvis banken ved, at en transaktion senere vil fejle i rapporteringen, kan den vælge at stoppe den allerede ved ordre- eller onboardingstadiet.

Under ESMA’s praksis kan en manglende fornyet LEI hos en modpart føre til, at rapporter indsendt på dennes vegne bliver afvist af et Trade Repository. Banken har derfor et driftsmæssigt incitament til at være mere streng end kunden måske forventer.

Tilsvarende peger CSDR-spørgsmål på kravet om, at udstedere i relevante sammenhænge skal have og videregive en gyldig LEI til CSD’er. Hvis jeres bank også håndterer afvikling eller depotnære processer, kan LEI-kontrollen derfor komme fra flere retninger på én gang.

Hvilke oplysninger bør I sende banken med det samme?

Send dokumentation, der gør bankens kontrol kortere: LEI-kode, status, NextRenewalDate, juridisk navn og forklaring på eventuelle nylige ændringer.

Når banken først har afvist LEI’en, handler det om at fjerne tvivl hurtigt. Send ikke kun “vi har en LEI”. Send det, bankens medarbejder eller system faktisk skal bruge for at kunne ændre status fra afvist til godkendt.

• LEI-kode: den fulde 20-cifrede kode uden mellemrum eller lokale variationer
• RegistrationStatus: fx ISSUED, eller en forklaring hvis sagen handler om nylig fornyelse eller transfer
• NextRenewalDate: datoen banken kan bruge til at se, om registreringen er aktuel
• Juridisk navn og CVR: præcis stavning, så bankens enhedsmatch ikke fejler
• Dokumentation: kvittering, opdateret opslag eller forklaring på navneændring, fusion eller anden selskabshændelse

Hvis banken stadig siger nej, så bed om den konkrete årsag på feltniveau. Hvis fejlen er status, skal I forny eller skifte til den korrekte LEI. Hvis fejlen er data, skal posten rettes. Hvis fejlen er timing, skal banken ofte blot validere igen efter næste opdatering.