Joining Korean company data: DART codes, LEIs and the limits of name matching

By the FinBridge team at GRONOX Corp.

An identifier-matching note from the Korea Rosetta build, 22 September 2026.

A Korean filing, a trading system and a counterparty database can describe the same company using different keys. Before comparing their numbers, you need to establish that they refer to the same legal entity.

OpenDART distinguishes its eight-character corp_code from the six-character stock_code. Its company profile supplies two more fields: a business registration number and a corporate registry number. A global dataset may instead identify the entity by its LEI. Those fields are useful bridges, but they are not interchangeable. OpenDART's identifier specification documents the first two; GLEIF provides LEI reference data.

Korea Rosetta puts these identifiers alongside one another. It is an entity crosswalk, not a price feed or a table of individual securities.

A match rate needs a denominator

The 22 September snapshot contains 3,991 DART records with stock codes. Of these, 2,753 have a KOSPI, KOSDAQ or KONEX classification in the snapshot. There are 337 populated LEIs, or 8.4% of all 3,991 rows.

That is the registration-number match coverage of this build. It does not establish the LEI adoption rate of all Korean companies, or prove that every unmatched company lacks an LEI. Source coverage, identifier availability and the join rules all affect the result.

The downloadable sample tells a different-looking story: 118 of its 200 rows have an LEI, or 59%. The sample was selected from large companies by reported revenue. It is suitable for inspecting columns and trying a join; it is not a representative sample for estimating coverage.

Snapshot	Rows	Rows with LEI	Coverage
Full member dataset	3,991	337	8.4%
Public sample	200	118	59.0%

These counts were recalculated from the CSV files on 26 September. The underlying snapshot remains dated 22 September.

Names are evidence, not keys

Spaces, abbreviations and spelling variations complicate English-name comparisons. Removing punctuation can recover a candidate; it can also make distinct names look identical.

The build therefore separates two outputs. lei contains registration-number joins. lei_candidate holds unconfirmed name-based candidates. A downstream system should not fill missing LEIs from the candidate column without review.

A registration-number match is still something to audit. Preserve the matching method and source date. Check the registration authority and investigate duplicate identifiers or disagreements between sources before accepting a join. The current CSV has no repeated populated LEI, but that check alone does not prove every match correct.

Keep codes as text

An identifier is not a quantity. Converting a stock code to an integer removes leading zeroes. Keep the original strings when loading the CSV, and validate uniqueness before using a lookup:

import csv

with open("korea_rosetta_sample.csv", encoding="utf-8-sig", newline="") as f:
    rows = list(csv.DictReader(f))

by_corp = {}
for row in rows:
    code = row["corp_code"]
    if code in by_corp:
        raise ValueError(f"Duplicate corp_code: {code}")
    by_corp[code] = row

lei_by_corp = {
    code: row["lei"]
    for code, row in by_corp.items()
    if row["lei"]
    and row["lei_match_method"] in {"bizr_no", "jurir_no"}
}
print(f"Rows: {len(by_corp)}; registration-number LEI matches: {len(lei_by_corp)}")

For this sample, the output is Rows: 200; registration-number LEI matches: 118. The lookup deliberately excludes name-based candidates. Use the DART corp_code from a filing to look up its entity; if it is absent from this 200-row sample, that is a sample coverage gap, not proof that the issuer or its LEI does not exist.

This preserves strings and detects duplicate entity keys. It does not turn the entity table into a security master: different share classes require a separate security-to-issuer mapping.

A snapshot cannot answer a historical question

The file records a source snapshot. Its FORMER label is derived from a stock code combined with the OTHER market classification; it is not a verified delisting date. Do not treat it as a complete history of exchange membership.

Historical research needs dated observations and evidence for changes. Renames, transfers and delistings should be retained as events rather than silently overwritten. We have started recording snapshots, but this release does not reconstruct earlier listing events or provide verified delisting dates. A company that is listed in today's snapshot should not automatically enter a universe for an earlier year.

The public repository contains the 200-company sample and the build script under CC BY 4.0. The full member dataset is offered separately through Korea Rosetta; the sample's licence should not be assumed to apply to it. No ISIN column or filing text is included in this crosswalk.