LEI-API og integration: Synkroniser stamdata med jeres systemer

Når LEI-data kun ligger i et regneark, en mailtråd eller et separat compliance-værktøj, opstår der hurtigt forskelle mellem systemerne. Det koster tid, giver unødige kontroller og kan skabe fejl i både onboarding, rapportering og handel med værdipapirer.

En LEI-API integration løser det problem ved at lade jeres systemer hente og opdatere virksomhedsdata direkte fra en pålidelig kilde. Det gør især en forskel, hvis I arbejder med ERP, CRM, KYC, treasury, investor administration eller andre platforme, hvor juridiske enheder skal identificeres korrekt og ensartet.

Hvad en LEI-API integration betyder for stamdata

LEI står for Legal Entity Identifier og bruges til entydig identifikation af juridiske enheder. Når LEI kobles sammen med stamdata, får I ikke kun et nummer. I får også adgang til oplysninger om navn, registreringsstatus, adresse og i mange tilfælde relationer til moderselskaber og ejerstruktur.

Det praktiske udbytte er enkelt: samme referencepunkt på tværs af systemer. Når et kundekort i CRM, en leverandørprofil i ERP og et compliance-flow i KYC henter ud fra samme LEI, falder antallet af manuelle rettelser markant.

Mange vælger at bruge GLEIFs åbne LEI API til opslag og validering. Det offentlige API er gratis og kræver normalt ikke konto eller API-nøgle. Hvis I også vil automatisere oprettelse, flytning eller fornyelse af LEI-koder, vil en registreringspartners API typisk kræve adgangskontrol, ofte via OAuth 2.0 eller tilsvarende token-baseret login.

Tekniske krav til LEI-API integration i eksisterende systemer

De fleste integrationer er teknisk overkommelige, hvis jeres systemer allerede kan kalde eksterne webservices. GLEIFs API er REST-baseret over HTTPS og leverer svar i JSON. Det betyder, at opgaven sjældent handler om tung infrastruktur. Den handler mere om korrekt mapping, drift og opdateringslogik.

Jeres løsning skal kunne sende HTTP-kald, modtage JSON, validere feltværdier og skrive data tilbage til masterdata-tabeller eller integrationslag. Har I mange opslag, bør der også være caching, overvågning og en plan for, hvad systemet gør, hvis API’et er utilgængeligt i en periode.

Typiske tekniske forudsætninger er:

• HTTPS-adgang ud af jeres netværk
• JSON-parsing i applikation eller integrationsmotor
• planlagte job eller event-baserede triggere
• logning af kald og fejl
• lokal cache til hyppige opslag
• validering af LEI-status før gemning

Et simpelt opslag kan se sådan ud:

GET https://api.gleif.org/api/v1/lei-records?filter[lei]=529900T8BM49AURSDO55

Eller som navnesøgning:

GET https://api.gleif.org/api/v1/lei-records?filter[entity.legalName]=virksomhedsnavn

Det vigtigste er ikke selve kaldet. Det vigtigste er, at jeres system ved, hvilke felter der er autoritative, hvilke der kun er informative, og hvornår data skal overskrive eksisterende stamdata.

Dataformater og protokoller i LEI-API arbejde

I praksis møder de fleste to arbejdsmåder: direkte API-opslag og bulkfiler. API’et bruges, når I vil hente få eller mellemstore mængder data løbende. Bulkfiler bruges, når I vil opdatere store datamængder samlet.

SOAP er normalt ikke en del af LEI-økosystemet. Hvis jeres integrationsplatform primært er bygget til ældre SOAP-services, skal der ofte laves et mindre adapterlag.

Real-time LEI-opslag eller batchsynkronisering af LEI-data

Valget mellem real-time og batch afhænger af jeres risiko, volumen og svartidskrav. Der findes ikke én model, som passer alle.

Real-time er oplagt, når en LEI skal kontrolleres på et kritisk tidspunkt. Det kan være ved kundeoprettelse, ved handel eller ved generering af dokumenter, hvor en ugyldig eller udløbet LEI ikke må slippe igennem. I får de mest aktuelle data, men sender også flere kald ud af huset.

Batch er stærkt, når I arbejder med mange modparter eller vil opdatere et centralt masterdataregister hver nat. Her kan I hente ændringer i større mængder og bearbejde dem lokalt uden at belaste API’et hele dagen.

Når valget skal træffes, er disse kriterier ofte de vigtigste:

• Hastighed: Real-time passer til onboarding og transaktioner, hvor svaret skal bruges med det samme
• Volumen: Batch passer til store kundelister, porteføljer og daglige datakørsler
• Stabilitet: Batch er mere robust, hvis eksterne kald skal minimeres i driftstiden
• Datakrav: Real-time er bedst, hvis status og stamdata skal være helt opdaterede på beslutningstidspunktet

Mange ender med en kombinationsmodel. Et natligt batchjob holder databasen ajour, mens enkelte real-time opslag bruges som ekstra kontrol i kritiske processer.

Workflow for LEI-API integration og datasynkronisering

Et godt integrationsflow er sjældent kompliceret, men det skal være disciplineret. Fejl opstår typisk ikke i API-kaldet. De opstår i det, der sker bagefter.

En typisk implementering kan bygges i disse trin:

1. Definér de felter, I vil eje lokalt, og de felter, der altid skal opdateres fra LEI-kilden.
2. Opret opslagspunktet i jeres system, enten ved LEI, virksomhedsnavn eller en anden nøgle.
3. Parse JSON-svaret og map felter til jeres stamdatamodel.
4. Validér LEI-status, udløb, navn og adresse før data gemmes.
5. Log ændringer, så compliance og support kan se, hvad der er opdateret og hvornår.
6. Planlæg løbende synk, enten som batch, real-time eller en kombination.
7. Tilføj fallback, så systemet ikke stopper helt ved midlertidige API-fejl.

En god tommelfingerregel er at holde jeres interne datamodel enkel. Gem det, I faktisk bruger, og behold råsvaret eller udvalgte metadata i et separat lag til fejlsøgning og revision.

Typiske udfordringer ved LEI-API integration

Der er store gevinster ved automatisering, men der er også nogle klassiske faldgruber. Den første er at tro, at LEI-data alene kan bære hele jeres kundemaster. Det kan de ikke. LEI er stærk til identifikation og referenceoplysninger, men bør ses som et autoritativt supplement til egne forretningsdata.

Den næste udfordring er datamatch. Navne kan være stavet forskelligt, adresser kan være formateret forskelligt, og nogle enheder kan have historik, som kræver manuel afklaring. Derfor bør navnesøgning bruges med omtanke. Et opslag direkte på LEI er langt mere sikkert end et frit tekstmatch.

De mest almindelige problemer i drift er:

• Manglende rate control: For mange kald på kort tid kan give ustabil adfærd eller blokeringer
• For svag fejlbehandling: Timeouts, tomme svar og midlertidige netværksfejl skal håndteres pænt
• Dårlig mapping: Ét felt i API’et svarer ikke altid til ét felt i jeres ERP eller CRM
• Ingen fallback: Hvis eksternt opslag fejler, skal brugeren stadig kunne arbejde videre under kontrollerede rammer

Sikkerhed spiller også ind, selv om LEI-data ikke i sig selv er personfølsomme. Trafikken bør altid gå over HTTPS, og hvis I bruger en tredjeparts registrerings-API, skal tokens og nøgler opbevares sikkert. Samtidig bør interne roller styre, hvem der kan ændre masterdata på baggrund af eksterne opslag.

LEI-data i ERP, CRM, KYC og rapporteringssystemer

LEI giver mest værdi, når det ikke bliver et særskilt projekt. Det skal ind i de systemer, hvor medarbejderne allerede arbejder.

I ERP kan LEI bruges på kreditorer, debitorer, modparter og juridiske enheder. Det gør fakturering, dokumentation og sporbarhed mere ensartet. I CRM kan LEI styrke kundeprofiler og sikre, at salg, legal og compliance arbejder med samme reference. I KYC- og AML-flows kan LEI bruges som et fast kontrolpunkt ved onboarding og løbende due diligence.

Et andet vigtigt område er rapportering. Hvis jeres virksomhed rapporterer transaktioner eller arbejder tæt op mod regulerede finansielle processer, er det en klar fordel at kunne kontrollere LEI-status automatisk før afsendelse. Det reducerer manuelle afvisninger og efterarbejde.

Hvornår en registreringspartner giver mening i LEI-processen

Selve opslaget i GLEIFs åbne API kan mange teams håndtere selv. Det ændrer ikke ved, at der ofte er et praktisk behov for hjælp til oprettelse, flytning eller fornyelse af LEI-koder. Det gælder især, hvis I administrerer mange enheder eller vil undgå, at en LEI udløber midt i et forretningskritisk flow.

Her vælger nogle virksomheder en dansk registreringspartner som LEI Service ApS til den administrative del af processen. Det er relevant, hvis man ønsker hurtig udstedelse, tydelige priser, dansk support og mulighed for automatisk fornyelse, mens selve dataopslaget fortsat kan ske via GLEIF eller en anden integrationsløsning.

Det kan være en praktisk model, hvis jeres behov ser sådan ud:

• I vil selv styre opslag og synkronisering teknisk
• I vil have hjælp til registrering og årlige fornyelser
• I vil undgå manuelle opfølgningsrutiner på udløb
• I har flere LEI-koder og ønsker samlet administration

LEI Service ApS tilbyder ikke en offentlig udviklerplatform som et klassisk softwarehus, men kan være relevant som servicepartner omkring livscyklus, fornyelse, flytning og datakorrektur. For mange virksomheder er det en fornuftig arbejdsdeling: intern kontrol over integrationen, ekstern hjælp til den del, der handler om registrering og løbende vedligeholdelse.

Praktiske valg før I går i gang med en LEI-API integration

Et integrationsprojekt bliver hurtigere og billigere, når de rigtige beslutninger tages tidligt. Start med at afgrænse formålet. Skal I validere LEI ved onboarding? Holde et centralt register opdateret? Eller automatisere både opslag og fornyelsesflow?

Tag også stilling til datamodellen. Beslut præcist, hvilke LEI-felter der skal vises for brugerne, hvilke der kun er til maskinel kontrol, og hvilke ændringer der må opdatere stamdata automatisk. Den beslutning sparer mange timer senere.

Før udviklingen går i produktion, er disse spørgsmål værd at have afklaret:

• Kildevalg: Bruger I GLEIF API, bulkfiler eller en kombination?
• Opdateringsfrekvens: Skal data opdateres ved hændelser, dagligt eller begge dele?
• Ejerskab: Hvem i organisationen godkender ændringer i masterdata?
• Drift: Hvem overvåger fejl, timeouts og udløbne LEI-koder?

Det giver et langt mere stabilt setup end at bygge integrationen som et rent udviklingsprojekt uden forankring i forretning og drift. Når LEI-data bliver behandlet som en del af jeres masterdataarkitektur, får I bedre kvalitet, mindre manuelt arbejde og færre overraskelser i de processer, hvor præcis enhedsidentifikation faktisk er afgørende.