--- title: "SEC EDGAR for Bank Analysis: Linking Regulatory Data" description: "Learn how to combine SEC EDGAR filings with FFIEC Call Report and FDIC data for deeper SEC EDGAR bank regulatory data analysis." canonical_url: https://www.bankregreports.com/blog/sec-edgar-bank-analysis/ source: BankRegReports published: "2026-10-15" updated: "2026-10-15" --- 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](https://www.bankregreports.com) 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](https://www.sec.gov).
Industry unrealized losses on held-to-maturity and available-for-sale securities over recent quarters
SEC filings and Call Reports describe the same securities book. Industry unrealized losses on held-to-maturity and available-for-sale portfolios are where the two views must reconcile. BankRegReports analysis.
## 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](https://www.bankregreports.com) 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. ## About this document This is the markdown twin of the page named in `canonical_url` above. Source filings are public record; the cleaning, normalization, cross-source linkage, and derived metrics are BankRegReports' own. Attribute with a link to the canonical URL. Markdown twins are published for editorial content only. Institution data pages do not have them. For data at scale use the API, which is documented at https://www.bankregreports.com/api/ and specified at https://www.bankregreports.com/openapi.json. It returns typed JSON with explicit units and periods, and one call replaces hundreds of page fetches. ## Sitemap - [Glossary](https://www.bankregreports.com/glossary/): every metric, with formula and thresholds - [Blog](https://www.bankregreports.com/blog/): analysis and explainers - [API documentation](https://www.bankregreports.com/api/): the programmatic way to get this data - [XML sitemap](https://www.bankregreports.com/sitemap.xml): the complete crawlable index