[ blog · use-case ]8 min read

用 LEI 做实体解析：面向交易对手 KYC 与股权结构的 GLEIF 查询 API

Sarah Choy发布于 2026年9月1日约 8 分钟阅读

「Apple Inc.」「Apple, Inc.」和「APPLE INC」是三个字符串、一家公司。LEI 是一个 20 位代码，它在任何司法辖区都能毫不含糊地说清这一点，而且数据属于公共领域。

一句话总结

•LEI 是一个 20 位的 ISO 17442 代码，在全球范围内唯一标识一个法人实体。它不像公司名称那样有歧义，也不像本国登记号那样会跨辖区重号。
•GLEIF 以 CC0 发布整个注册库——公共领域，无需署名，对下游使用没有任何限制。这在实体数据领域相当罕见，也正是这个接口能够存在的原因。
•已知 LEI 代码时可精确查询；只有一串杂乱的 CRM 名称时，可按法定名称搜索。名称搜索是按相关性排序而非精确匹配，因此 total_matches 可能很大。
•registered_as 携带该实体在本国工商登记机关的编号——这是从全球标识符通往当地法定备案的桥梁。
•二级数据提供直接母公司、最终母公司与子公司数量，且每个母公司都以自己的 LEI 标识，便于你沿股权树向上或向下遍历。

关联主键这个老问题

任何试图打通两套系统的公司都遇到过这一幕。你的 CRM 写着 Apple Inc.，发票上是 Apple, Inc.，制裁名单筛查里是 APPLE INC，而合同上写的是 Apple Operations Europe——那完全是另一个法人实体。模糊匹配能带你走完大半程，然后在关键处给你一个误报。

法人识别编码就是为了终结这件事而存在的。它是 ISO 17442 定义的 20 位代码，在全球范围内精确标识唯一一个法人实体。凡在受监管金融市场交易者均须持有，这意味着重要交易对手的覆盖率很高。

真正让它对我们其余人也可用的，是这一点：GLEIF 以 CC0 发布整个注册库——公共领域、无需署名、对下游使用没有任何限制。这在实体数据领域几乎闻所未闻。

两种查法

你已经有代码

curl "https://www.apipick.com/api/lei-lookup?lei=HWUPKR0MPOU8FGXBT394" \
  -H "x-api-key: $APIPICK_KEY"

{
  "mode": "lei",
  "found": true,
  "record": {
    "lei": "HWUPKR0MPOU8FGXBT394",
    "legal_name": "Apple Inc.",
    "other_names": ["Apple Computer, Inc."],
    "jurisdiction": "US-CA",
    "legal_form": "H1UM",
    "entity_status": "ACTIVE",
    "registered_as": "806592",
    "bic": ["APLEUS66XXX"],
    "registration_status": "ISSUED",
    "next_renewal_date": "2027-03-08T17:27:20Z",
    "headquarters_address": { "city": "Cupertino", "region": "US-CA", ... }
  }
}

有两个字段值得留意。other_names 携带曾用法定名称，这是你把一份以公司早已弃用的旧名签署的合同对上号的办法。registered_as 是该实体在本国工商登记机关的编号——这是从全球标识符通往当地法定备案的桥梁。

你只有一串杂乱的名字

改传 name，并可选按国家收窄。

GET /api/lei-lookup?name=Tesla,%20Inc.&country=US&limit=3

{
  "mode": "search",
  "total_matches": 43128,
  "returned": 3,
  "records": [
    { "lei": "54930043XZGB27CTOV49", "legal_name": "TESLA, INC.", ... },
    { "lei": "549300LFXY1VG8DI7B68", "legal_name": "Tesla General Insurance, Inc.", ... },
    ...
  ]
}

沿股权树往上走

加上 include_relationships=true，你会拿到 GLEIF 的二级数据：直接母公司、最终母公司，以及直接子公司数量。由于每个母公司都带着自己的 LEI 返回，向上遍历不过是再发一次调用。

import httpx, os
H = {"x-api-key": os.environ["APIPICK_KEY"]}
URL = "https://www.apipick.com/api/lei-lookup"

def climb(lei, depth=5):
    """Walk from an entity up to its ultimate parent."""
    chain = []
    for _ in range(depth):
        r = httpx.get(URL, params={"lei": lei, "include_relationships": "true"},
                      headers=H).json()
        if not r["found"]:
            break
        chain.append(r["record"]["legal_name"])
        parent = r.get("relationships", {}).get("direct_parent")
        if not parent:
            break
        lei = parent["lei"]
    return chain

# ['APPLE OPERATIONS INDIA PRIVATE LIMITED', 'Apple Inc.']

这才是授信或签约之前真正要紧的问题：不是「我在和谁签合同」，而是「我签约的这个实体最终受谁控制」。一家资产负债表单薄的子公司背后站着一个实力雄厚的母公司，与这家子公司孤零零地站着，是完全不同的两笔生意。

它在开户体系中的位置

这三者回答的是不同问题，值得组合使用而不是二选一：

LEI——这个实体在官方意义上是谁、由谁拥有。覆盖全球，CC0。
欧盟 VAT——这家企业是否已注册可在欧盟做跨境贸易。权威，但仅限欧盟，且除名称外不涉及身份。
公司数据——美国上市公司的 SEC 备案与财务数据。

一个合理的开户流程是：先用 LEI 锁定身份，再校验 VAT 号以确定税务处理，若交易对手是上市公司则再拉取财务数据。

容易被忽略的信号

registration_status 不是装饰。LEI 必须每年续期，而 LAPSED 状态通常意味着该实体已停止在受监管市场交易，或者已无人打理——签大单之前，这两点都值得知道。entity_status: INACTIVE 的信号更强：该实体已解散或被吸收合并，而 successorEntity 往往会指明它变成了什么。

自己接，还是直接调

	直连 GLEIF API	商业数据商	API Pick
数据授权	CC0 公共领域	附带再分发条款	CC0 公共领域
响应结构	JSON:API，嵌套三层	各家不一	扁平对象
记录不存在	以 HTML 页面形式返回 404	各家不一	200 且 found:false
股权关系	每种关系一个独立端点	通常在付费档	一个开关
成本	免费 + 你要写的管道代码	按席位或按次计费	3 积分/次

GLEIF 自己的 API 是免费的，数据也完全一致——两条路走的都是同一个注册库。直连时你要额外承担的是 JSON:API 的层层嵌套、以 HTML 错误页而非 JSON 形式返回的 404，以及每种关系各自独立的端点。

数据来源与授权

记录来自全球法人识别编码基金会 GLEIF，该机构受监管监督委员会委托维护 LEI 注册库。一级参考数据与二级股权数据均以 CC0 发布。每次调用 3 积分，只在成功时计费；免费 key 附带 100 积分，无需绑卡。

常见问题

LEI 是什么，为什么适合当关联主键？

法人识别编码是 ISO 17442 定义的 20 位代码，在全球范围内标识唯一一个法人实体。凡在受监管金融市场交易者均须持有。它优于公司名称，因为名称有歧义、会变更、还会重名；它也优于本国登记号，因为后者会跨辖区重复——特拉华州的一个公司编号和爱尔兰的一个编号可能是同一串数字，指的却是完全不同的公司。LEI 是全球唯一的，而这正是关联主键必须具备的属性。

只有公司名称也能查吗？

可以。用 name 代替 lei 即可按法定名称搜索注册库，还能用国家代码进一步收窄。请注意 GLEIF 的名称过滤是相关性匹配而非精确匹配，因此对一个常见词而言 total_matches 可能高达数万。返回的记录是该排序列表的靠前部分，所以应把首条结果当作有待确认的候选，而不是定论。

怎么获取集团股权结构？

在按 LEI 查询时加上 include_relationships=true。你会拿到直接母公司、最终母公司以及直接子公司数量。每个母公司都以自己的 LEI 标识，因此可以再发起调用沿树向任一方向遍历。这属于 GLEIF 的二级数据，由实体依据「谁拥有谁」的申报义务自行申报。

注册库有多新？

GLEIF 每日发布一份新的黄金副本，而本接口查询的是他们的在线 API，而非本地快照。实体必须每年续期 LEI，因此 registration_status 与 next_renewal_date 能告诉你某条记录是仍在积极维护，还是已经失效。LAPSED 状态本身就是有用信号——它往往意味着该实体已停止在受监管市场交易，或者已无人打理。