SEC EDGAR for Bank Analysis: Linking Regulatory Data
Anyone who has spent time in a bank's finance or risk function knows the fundamental tension in financial analysis: the data you need lives in at least two places that …
Anyone who has spent time in a bank’s finance or risk function knows the fundamental tension in financial analysis: the data you need lives in at least two places that were never designed to talk to each other. The regulatory filings (Call Reports, Y-9C, UBPR) live in FFIEC systems built for examiners. The securities disclosures (10-K, 10-Q, 8-K, proxy statements) live in SEC EDGAR, built for investors. If you want to understand a bank completely, you need both. And historically, getting both into a single, clean, analysis-ready dataset has required either an expensive enterprise data platform subscription or weeks of raw data wrangling.
This post is about how to do it properly, what the pitfalls are in raw EDGAR data for banks specifically, and how BankRegReports handles the reconciliation work so you can skip straight to the analysis.
Why Does SEC EDGAR Matter for Bank Analysis?
The regulatory filing stack (FFIEC Call Reports, UBPR ratios, FDIC call data, Federal Reserve NIC and Y-9C for holding companies, NCUA 5300 for credit unions) is where you find the granular balance sheet detail. Loan-level segmentation, deposit composition, capital ratios under Basel III, and off-balance-sheet exposures are all reported there with a level of granularity that EDGAR simply does not replicate.
But EDGAR fills critical gaps that regulatory filings leave open.
What EDGAR Adds That Call Reports Do Not
Management narrative. The MD&A section of a 10-K or 10-Q contains forward-looking interest rate sensitivity disclosures, ALCO commentary, and qualitative explanations of deposit repricing behavior that have no equivalent in the structured data fields of a Call Report. If you are building a deposit beta model or trying to understand how management thinks about NIM compression, you need the 10-K, not just the RC-K schedule.
Holding company consolidation. Many bank holding companies consolidate non-bank subsidiaries (insurance, brokerage, asset management, fintech ventures) that never appear in the bank-level Call Report. The consolidated 10-K is the only place where the full economic picture of the enterprise shows up in a standardized format.
Equity and compensation structure. Proxy statements (DEF 14A) contain executive compensation structures, ownership concentration, and related-party transactions. None of that is in the regulatory stack. In a credit analysis or M&A context, the proxy is often as important as the income statement.
XBRL-tagged financial statements. Starting with larger filers and now broadly required, SEC EDGAR filings include XBRL-tagged inline financials. In theory, this gives you machine-readable income statements, balance sheets, and cash flow statements. In practice, bank XBRL is messy; banks use a mix of standard US-GAAP taxonomy tags and custom company-extension tags, and the units handling changed materially in 2023, introducing silent scaling errors in raw data pulls for anyone who was not paying close attention.
That last point is worth dwelling on. If you have ever pulled company_facts from the SEC EDGAR API and trusted the val field directly, you have probably encountered values that are off by a factor of 1,000, because the SEC changed how it reports units in the XBRL data, and scripts written before that change produce wrong answers quietly. This is exactly the kind of data engineering problem that looks trivial until you are presenting numbers to an executive or an examiner and someone asks why your total assets figure is $4 billion instead of $4 trillion. The official source for these securities filings is the SEC.
The Reconciliation Problem
Even setting aside the XBRL units issue, linking EDGAR to regulatory data is non-trivial for banks specifically because the entity identifiers are different.
Regulatory data uses the RSSD ID (Federal Reserve), CERT number (FDIC), and charter number as the primary keys. EDGAR uses the CIK, a Central Index Key assigned by the SEC that has no direct relationship to any regulatory identifier. A bank holding company has a CIK. Its lead bank subsidiary has an RSSD ID and a CERT number. They are related, but the mapping is not published in any single authoritative place. You have to build it yourself, or trust someone who has built it correctly.
The mapping also has to handle corporate events. After a merger, the surviving entity’s CIK continues. But the regulatory filings for the acquired institution stop, and the acquirer’s regulatory filings expand. If you are building a time series that spans an acquisition, you need to handle the regulatory filing discontinuity explicitly; otherwise you get artificial jumps in your data that look like a sudden change in balance sheet composition.
BankRegReports maintains this crosswalk as part of the platform’s entity graph, linking RSSD IDs, FDIC cert numbers, NIC parent chains, and SEC CIKs into a unified entity identifier (the BRR-E- system) that is stable across corporate events.
What This Replaces
Legacy financial data providers charge substantial per-seat fees for pre-linked bank data at this level of detail, and even then the XBRL handling tends to lag when the SEC changes taxonomy conventions. The alternative (pulling directly from FFIEC CDR, the FDIC BankFind API, the SEC EDGAR company facts endpoint, and Federal Reserve data systems separately and building your own entity linker) is a multi-week engineering project that has to be maintained every quarter as source schemas evolve.
BankRegReports was built specifically to solve this for practitioners who need regulatory-grade accuracy without a data engineering team. The full source stack (FFIEC Call Reports, UBPR, FDIC, Federal Reserve NIC and Y-9C, NCUA 5300, and SEC EDGAR) is normalized, entity-linked, and surfaced through a single API with consistent period identifiers and units handling.
Getting Started
The free tier covers meaningful analytical use, enough to validate the data quality against your existing sources and decide whether it replaces the spreadsheet pipeline you have been maintaining by hand for the last several years. For most practitioners, it does.