Fed Nic

@pipeworx/fed-nic

美国银行及银行／金融控股公司的机构搜索、公司所有权层级以及并购历史，数据来自美联储系统的国家信息中心（NIC，ffiec.gov/npw）。

这是 Pipeworx 的一部分——一个将 AI Agent 连接到 1879+ 个实时数据源的 MCP 网关。此集成为独立的非官方集成，与上游提供方无关联，未获其认可，也非其发布。

工具

• nic_search_institutions(query, status?, state?, limit?) — 按名称查找机构。 返回 RSSD ID、FDIC 证书编号、LEI、机构类型、所在地以及活跃／已关闭状态。通过 nic_search_ranked 排序（迁移 212）：完全匹配优先，其次是活跃 FDIC 证书机构的前缀匹配，再其次是任意前缀匹配，然后是其他活跃 FDIC 证书机构，最后是其余结果——并非按字母顺序排列（参见“覆盖范围／准确性说明”）。
• nic_get_institution(rssd_id? | fdic_cert? | lei?) — 查询单个机构的完整 NIC 记录，必须且只能使用 RSSD ID、FDIC 证书编号（关联到 fdic pack）或 LEI（关联到 gleif pack）中的一个。
• nic_get_hierarchy(rssd_id, direction?, limit?, offset?) — direction="up" （默认值）沿所有权链向上追溯至顶层持有者（“哪家控股公司拥有这家银行？”）；direction="down" 列出给定 RSSD ID 所拥有的实体，可通过 limit/offset 分页，并在 SQL 中通过 DISTINCT 计数计算 total_subsidiary_count（迁移 212 中的 nic_descendant_count）——关于之前的计数为何有误，请参见“覆盖范围／准确性说明”。
• nic_get_history(rssd_id) — 该机构参与的合并、收购、倒闭和转型事件（“哪些前身机构合并成了这家银行？”）。

身份验证

无需密钥——调用方无需提供凭据。网关会自动提供存储凭据。

数据来源

• https://www.ffiec.gov/npw/FinancialReport/DataDownload — NIC 的公开批量 CSV 文件：Attributes-Active、Attributes-Closed、Relationships、Transformations。美国联邦政府数据；下载页面和 NPW 网站上均未发现复用限制（联邦数据默认属于公有领域——参见下文“复用条款”）。

为什么这个 pack 从镜像读取，而不是通过实时代理获取

www.ffiec.gov 受 Cloudflare Managed Challenge （cf-mitigated: challenge）保护，会向所有非浏览器 HTTP 客户端返回 403“CAPTCHA Error”页面。以下端点均已确认会出现此问题：

• 实时网站每次查询所使用的交互式 NPW 页面 （Institution/Profile/{rssd_id}、POST Institution/BuildTier、POST Institution/LoadHistory），以及
• 批量 CSV 下载端点（FinancialReport/Return*ZipFileCSV）本身，

即使使用完整的 Chrome 请求头（User-Agent、Accept、Accept-Language、sec-ch-ua*）也无济于事。Cloudflare Worker 的 fetch() 遇到的也是同一阻碍——没有可修复问题的请求头或 Cookie；这是 JS/TLS 指纹质询，不是 UA 检查，因此此网关无法通过任何实时的逐查询途径访问数据。根据 Bruce 在 2026-09-23 的决定（“实时服务无法提供时，就创建副本”），此 pack 改为使用 NIC 自己的公开批量文件的定期更新副本（迁移 supabase/migrations/209_fed_nic.sql），并由 scripts/ingest-fed-nic.mjs 更新——有关为何无法通过 Worker cron 更新，以及手动运行需要满足什么条件，请参见该脚本开头的说明。此 pack 在 workers/data-pipeline/src/datasets/fed-nic.ts 中注册，仅用于显示数据新鲜度（不安排定时运行），与 workers/data-pipeline/src/datasets/ffiec.ts 对 cdr.ffiec.gov 使用的模式相同。

复用条款

NIC 的数据下载页面（/npw/FinancialReport/DataDownload，“文件说明”）介绍了文件内容及其使用方法，但未声明版权、许可证或复用限制。NIC 数据字典 PDF（该页面链接的文件）与 ffiec.gov 的其他内容一样，位于 Cloudflare 防护墙之后，因此无法直接查看。这些数据由美国联邦机构（Federal Reserve System）针对一项监管职能制作；美国联邦政府作品默认属于公有领域（17 U.S.C. § 105），除非另有具体声明，而这里未发现此类声明。

覆盖范围 / 准确性说明

• 未纳入分支机构。 NIC 的 Attributes-Branches 文件（约 17.4 万行，95MB）不在此套件所支持的层级关系 / 历史记录用例范围内；NIC 界面自带的“分支机构”标签页涵盖此内容，之后也可以添加。
• nic_get_hierarchy 是我们自行计算的闭包，并非照搬 NIC 自己的分层算法。它会递归遍历 NIC 公开的 Relationships 文件中当前有效（dt_end IS NULL）的边。我们于 2026-09-23 对照 JPMorgan Chase Bank, N.A.（RSSD 852218）进行了实时抽查：direction="up" 与实时界面完全一致（顶级控股机构为 JPMorgan Chase & Co.，RSSD 1039502）；从顶层向下查询时，我们的闭包返回了 877 家子公司，而实时界面显示 1,025 家。仅凭公开的批量文件无法还原这一差异（实时界面的分层算法可能会应用一些规则，例如非股权控制依据、分支机构 / 代理关系，而公开的 Relationships 导出文件并未完整包含这些信息）。向下查询的数量应视为根据 NIC 自身发布的数据计算出的下限，而非 NIC 的官方数字。 Migration 212 修复了导致这 877 个结果进入工具的另一个独立缺陷。 Relationships 闭包按所有权路径输出行，而非按不同子公司输出行，因此，若某家子公司可通过多条母公司链到达，它就会出现多次（JPMorgan 有 1,672 条原始记录，对应 877 个不同的 RSSD id）。工具最初直接调用原始闭包 RPC，并将返回的行数用作 total_subsidiary_count；PostgREST 会将单次 RPC 响应限制在 1,000 行，因此只要原始闭包超过此上限，计数就会静默地变为 1,000，而不是 877。nic_descendant_count（单行标量，不受行数上限影响）和 nic_descendants_page（在 SQL 中去重并分页）解决了这个问题——参见 src/index.ts 文件顶部的注释和 supabase/migrations/212_fed_nic_hierarchy_and_search_fix.sql。
• nic_search_institutions 的排序（migration 212，nic_search_ranked）。 单纯按字母顺序排列会让同一企业集团的实体排在大多数调用方想找的机构之前——例如，查询“Wells Fargo Bank”时，“WELLS FARGO BANK INTERNATIONAL UNLIMITED COMPANY”（一家爱尔兰实体，没有 FDIC 证书）仅因 ASCII 中 ' ' 排在 ',' 前面，就排在“WELLS FARGO BANK, NATIONAL ASSOCIATION”（RSSD 451965）之前。现在的排序按以下层级排列：完全匹配、带 FDIC 证书的前缀匹配、任何前缀匹配、其他持证的活跃机构，最后是其余结果；同一层级内先按 legal_name 最短排序（与查询长度最接近），再按三元组相似度排序。
• entity_type_code 标签不完整。 src/index.ts 中的 ENTITY_TYPE_LABELS 仅包含已通过 NIC 界面实时验证的代码（NAT、FHD、EDI、IBK、INB、DEO）。其他代码会原样返回，不会猜测——可用于确认其余代码的 NIC 数据字典本身也位于 Cloudflare 防护墙之后。
• 出于同样原因，trnsfm_cd（转型类型）返回的是原始 NIC 代码，而非标签。 代码 50 已通过实时示例确认（First Republic Bank，RSSD 4114567 → JPMorgan Chase Bank N.A.，RSSD 852218，2023-05-01；NIC 实时“历史记录”标签页标注为“倒闭并停止运营”）。

快速开始

添加到你的 MCP 客户端（Claude Desktop、Cursor、Windsurf 等）：

{
  "mcpServers": {
    "fed-nic": {
      "url": "https://gateway.pipeworx.io/fed-nic/mcp"
    }
  }
}

此端点实际提供的内容

https://gateway.pipeworx.io/fed-nic/mcp 上的 tools/list 会返回上表中的工具，以及 Pipeworx 共享元工具——ask_pipeworx、discover_tools、search_within、remember/recall 和网关范围内的其他工具。因此，你看到的工具数量会多于此表：目前，单个工具包端点除了列出该工具包自己的工具，还会列出约 30 个共享工具。连接的 initialize 响应会说明其确切范围，是了解当天实际情况的权威依据。

这是有意为之，并非意外的多路复用。元工具能让限定范围的连接回答本工具包未涵盖的问题——通过可跨整个目录路由的 ask_pipeworx 实现——而无需添加第二个 MCP 服务。目前无法挂载不含这些元工具的工具包端点；如果额外的架构定义占用的上下文超过了路由带来的价值，请改为连接一次完整网关，而不是连接多个工具包端点。

也可以连接完整的 Pipeworx 网关，直接列出所有工具包的工具，而不只是此工具包的工具：

{
  "mcpServers": {
    "pipeworx": {
      "url": "https://gateway.pipeworx.io/mcp"
    }
  }
}

两个 URL 都会连接到同一个网关和相同的 1879+ 个数据源。唯一的区别是直接列出哪个工具包的工具；无论连接哪一个，ask_pipeworx 都能访问所有工具。

没有 MCP 客户端？通过 HTTP 调用

curl -X POST https://gateway.pipeworx.io/v1/tools/nic_search_institutions \
  -H 'Content-Type: application/json' \
  -d '{"query":"JPMorgan Chase Bank"}'

首次调用无需账号。检查任意工具：GET https://gateway.pipeworx.io/v1/tools/nic_search_institutions。查找工具包：使用 {"query":"..."} 调用 POST https://gateway.pipeworx.io/v1/tools/search_packs。

独立运行（无需网关账号）

此软件包也可以作为本地 stdio MCP 服务运行——无需 Pipeworx 账号，也无需经过网关：

{
  "mcpServers": {
    "fed-nic": {
      "command": "npx",
      "args": ["-y", "@pipeworx/mcp-fed-nic"]
    }
  }
}

也可以直接运行，确认服务能够启动：

npx -y @pipeworx/mcp-fed-nic

它通过 stdin/stdout 使用 MCP，并针对仅限此工具包的工具响应 initialize/tools/list/tools/call——不包含上述网关连接额外提供的任何共享元工具。使用相同的源代码和工具，不提供 ask_pipeworx 路由。

使用 ask_pipeworx

你可以用通俗的英语提问，而不是直接调用工具——这既适用于上面的工具包端点，也适用于完整网关：

ask_pipeworx({ question: "your question about Fed Nic data" })

网关会自动选择合适的工具并填写参数。

更多信息

• 文档和指南
• pipeworx.io

许可证

MIT