Entity Resolution in Financial Data: The Hard Problem

What entity resolution means in financial data

Take three strings from real 13F information tables: APPLE INC, Apple Inc., and APPLE INC COM. A human reads one company. A database reads three. Entity resolution is the layer that collapses them into one canonical issuer, and it has to hold up at scale. Arkolith's Q1 2026 13F dataset alone covers 1,824 institutional filers reporting 1.87 million long positions worth $53.7 trillion, plus more than 51,000 tracked insider transactions. At that volume, "mostly matches" means "wrong somewhere on every page."

The problem surfaces the moment you join two datasets. Want to know which institutions hold a stock and whether its executives are buying? You are joining 13F holdings (keyed by CUSIP plus a free-text issuer name) against Form 4 filings (keyed by the issuer's CIK and the insider's personal CIK) against a price series (keyed by ticker). Three datasets, three identity systems, zero shared keys. The join only works if something maps all three onto the same entity, and that something is the resolution layer.

Both failure modes are expensive. Merging two distinct companies fabricates a position that never existed. Failing to merge two spellings of one company splits a large position into two small ones, silently changing every concentration and flow number downstream. Both errors produce plausible-looking output, which is what makes them dangerous, especially when an AI agent reads the result and confidently narrates it.

Name strings lie: the variant problem

The nameOfIssuer field in a 13F information table is typed by the filer and is not validated against any registry. The same company appears under different capitalizations, punctuation, abbreviations, legal suffixes, and occasionally outright misspellings. The recurring variant classes:

Fuzzy string matching alone is a trap: edit distance happily merges legitimately distinct companies (regional banks are full of near-identical names) while missing true variants that differ by a whole word. The robust pattern is the reverse order: resolve on an identifier first (CUSIP for the security, CIK for the filer), then treat the name as a display label, not a key.

Even the display name is a decision. Naive aggregation, such as taking the byte-wise greatest name per CUSIP group, surfaces an arbitrary filer's spelling, sometimes a stale or mangled one. Resolution quality is a large part of why accuracy varies between 13F data providers: the raw documents are identical, the entity layer is not.

CIK, CUSIP, ticker, LEI: four identifiers, four jobs

None of the common identifiers does the whole job, because each names a different kind of thing:

A single large company is simultaneously a CIK (as an EDGAR filer), one or more CUSIPs (its share issues), a ticker on its listing venue, and usually an LEI, and nothing in the filings ties these together for you. You can see the raw fragmentation yourself in EDGAR full-text search. A resolved entity record is what lets an ownership page like NVDA's holder view aggregate hundreds of filers' positions, each reported under its own spelling, into one coherent table.

Identifiers also cross-reference at different grains. A CUSIP rolls up to its issuer only through its first six characters, and even that heuristic breaks across reorganizations (the anatomy is covered in what a CUSIP is). ISINs wrap CUSIPs for US securities, adding a country prefix without adding identity information. The durable design: key entities on an internal surrogate ID and attach every external identifier as a dated attribute, never as the primary key.

Manager vs fund: the 13F trap

A 13F is filed by an institutional investment manager exercising investment discretion over $100 million or more in covered US equities, due 45 days after quarter end (for 2026: February 17, May 15, August 14, and November 16). The filer is the management company, and it is usually not the fund you have in mind. One adviser CIK can aggregate many funds, separate accounts, and sub-advised mandates into a single report. The SEC's own Form 13F FAQ spends much of its length on who must file and for whose positions; investor.gov's overview is the gentler read.

This is the most common identity error in ownership data. "Warren Buffett's portfolio" is, in filing terms, Berkshire Hathaway reporting as a manager: the searched-for entity is a person, the filer is a conglomerate, and a useful product has to model that relationship explicitly, which is why a profile like Warren Buffett's fund page is a resolved entity rather than a raw filer record. Well-known investors also move between vehicles over a career; stitching that history together is resolution work, not a lookup.

Other ownership forms name different entity types again. Schedule 13D (due within 5 business days) and 13G are filed by beneficial owners. Form 3 (within 10 days of becoming an insider), Form 4 (within 2 business days of the trade), and Form 5 (within 45 days of fiscal year end) are filed by individual insiders carrying their own personal CIKs, which is what lets an insider feed like TSM's insider page follow an officer across roles. The distinctions are worth internalizing: see 13F vs 13D vs 13G vs Form 4.

Entities drift: time makes everything harder

Even a perfect mapping is only perfect as of a date. Companies merge, rename, spin off divisions, redomicile, and reissue securities, and each of these events can change the CUSIP, the ticker, the name, or all three, while the CIK usually persists. Tickers are the worst offenders: exchanges recycle symbols, so the ticker that meant one company in an old filing can mean an unrelated company today. Identifier drift and survivorship bias are first-order error sources in any historical securities database, and filings data is no exception.

Managers drift too. Advisers reorganize, funds wind down and relaunch under new legal entities, and a firm can stop filing 13Fs because it no longer meets the institutional-investment-manager definition. A filer going quiet is therefore ambiguous between "stopped managing money," "now files under a new CIK," and "no longer required to file." Resolving that ambiguity takes evidence from successor filings and cross-references, not string similarity.

The engineering conclusion is blunt: an entity mapping without effective dates silently corrupts history. The useful key is not (CUSIP maps to ticker) but (CUSIP, as-of date, maps to ticker). Point-in-time resolution is what lets you read a 2019 filing with 2019 identities and a 2026 filing with 2026 identities, without inventing trades that never happened.

Resolving entities through one API

Arkolith's approach is to do this work once, behind the API: securities are resolved by CUSIP to canonical issuers with ticker mappings, filers are resolved by CIK to canonical fund and manager entities, and every datapoint keeps provenance back to the SEC accession number of the filing it came from. The provenance is the anti-hallucination layer. An agent can cite the exact source document instead of asserting from memory.

In practice you resolve by searching, then key everything on the stable identifier:

# Step 1: resolve a messy name to a canonical entity
curl -H "Authorization: Bearer YOUR_KEY" \
  "https://arkolith.com/api/v1/search?q=berkshire"

# Step 2: browse resolved filers, or pull holdings by the CIK from step 1
curl -H "Authorization: Bearer YOUR_KEY" \
  "https://arkolith.com/api/v1/funds"

curl -H "Authorization: Bearer YOUR_KEY" \
  "https://arkolith.com/api/v1/funds/<cik>/holdings"

The same surface is exposed as MCP tools for agents, and the docs cover both transports. Search results carry the canonical keys (CIK for filers, CUSIP and ticker for securities), so an agent can chain from a fuzzy name to exact holdings without ever string-matching names itself. Building your own resolver instead? The checklist is short but unforgiving: key entities on internal surrogate IDs, attach every external identifier with effective dates, resolve on identifiers before names, record the source accession number behind every mapping decision, and re-verify mappings whenever corporate actions land. Most of the difficulty in financial data is not fetching it. It is knowing what the records refer to.

Frequently asked questions about entity resolution in financial data

Is a CIK the same as a company?

No. A CIK identifies an EDGAR filer: a company, a fund manager, or a person. One organization can hold multiple CIKs across subsidiaries and filing roles, and an individual insider has a personal CIK separate from any company they work for.

Why not just use tickers as the primary key?

Tickers are mutable and recycled: companies change symbols, delist, and exchanges reassign old symbols to new companies. Use CIK and CUSIP for identity and attach the ticker as a dated display attribute.

What is the difference between a 13F manager and a fund?

The 13F filer is the institutional investment manager, the adviser entity exercising discretion over $100M or more in covered US equities. A single manager's report can aggregate many underlying funds and accounts, so the "fund portfolio" you see in 13F data is really the manager's aggregate. Mapping named investors and funds onto filer CIKs is itself resolution work.

Can an LEI replace CUSIP and CIK?

Not today. The LEI is a well-designed global legal-entity identifier, but coverage is incomplete, registrations lapse, and SEC ownership filings like 13F and Form 4 do not key on it. It also names legal entities rather than securities, so holdings data still needs CUSIP-level resolution. Treat LEI as one more attribute on a canonical entity, not as the master key.

This article explains public filings and data concepts. It is not investment advice.