---
title: "FDIC BankFind API vs BankRegAPI: Which Data Source to Use"
description: "A practitioner's comparison of the FDIC BankFind API Python workflow versus BankRegAPI for bank regulatory data, covering coverage gaps and when each fits."
canonical_url: https://www.bankregreports.com/blog/fdic-bankfind-api-vs-bankregapi/
source: BankRegReports
published: "2026-09-24"
updated: "2026-10-16"
---

If you have spent any time pulling bank financial data programmatically, you have most likely started with the FDIC BankFind Suite API. It is free, it is public, and it covers a meaningful slice of U.S. depository institution data. For certain use cases it is exactly what you need. For others it will quietly mislead you, and by the time you find the gap, you have already built a model on it.

This post is a practitioner's comparison. Not a feature matrix. A real accounting of what each source covers, where each breaks down, and how to decide which one belongs in your workflow.

## What Does the FDIC BankFind API Actually Give You?

The FDIC BankFind API exposes summary financial data derived from [Call Report](/blog/what-is-a-bank-call-report/) filings (FFIEC 031/041/051) plus FDIC institutional metadata: charter class, supervisory region, failure history, branch counts, and so on. The institutions endpoint is genuinely useful for building a screener or pulling basic identification data. The financials endpoint returns a broad set of FDIC-computed balance sheet and income statement fields per institution per quarter, keyed on the FDIC certificate number (CERT). The official source for this data is the [FDIC](https://www.fdic.gov).

For a rough competitive analysis or a quick market-sizing exercise, that is often enough. Here is the standard Python workflow:

```python
import requests
import pandas as pd

resp = requests.get(
    "https://api.fdic.gov/banks/financials",
    params={
        "filters": "REPDTE:20240930 AND ASSET:[10000000 TO 100000000000]",
        "fields": "CERT,REPDTE,ASSET,LNLSNET,DEP,NETINC,RBCT1",
        "limit": 500,
        "offset": 0,
        "output": "json",
    }
)
data = resp.json()["data"]
df = pd.DataFrame([r["data"] for r in data])
print(df.head())
```

This works. Pull it into a DataFrame, do some ratio math, ship it. The problem surfaces when you start asking harder questions.

### Where BankFind Runs Out of Road

**Coverage is summary-level.** The FDIC financials endpoint exposes several hundred FDIC-computed financial fields, a substantial set, but derived summary items rather than the full Call Report. The FFIEC Call Report contains thousands of line items across dozens of schedules. RC-K (average balance sheet), RI-B (charge-off detail), RC-N (past-due and nonaccrual by loan category), RC-C loan classifications: that schedule-level granularity is not in BankFind. If you are building a model that touches credit quality beyond the headline ratios, or yield analysis that requires average balances, you are already outside what BankFind exposes.

**No holding company data.** BankFind covers bank-level (charter-level) financials. If your counterparty is a bank holding company, which it most likely is if you are doing ALCO benchmarking, M&A diligence, or investor reporting, you need the Federal Reserve's Y-9C filings. BankFind does not have them. You would need to layer in NIC data separately, figure out the RSSD-to-FDIC cert crosswalk yourself, and reconcile two different filing methodologies.

**No [UBPR](/blog/how-to-read-ubpr-report/) ratios.** The Uniform Bank Performance Report is the regulatory-grade ratio set that examiners actually use. Peer comparisons in bank exams reference UBPR peers. If your internal analysis diverges from UBPR methodology and an examiner asks about it, you have a documentation problem. BankFind does not expose UBPR data.

**No credit union coverage.** NCUA 5300 data is completely outside BankFind's scope. If your peer group includes credit unions, as it should for deposit market analysis in many markets, you need a separate data pipeline.

**No SEC EDGAR integration.** For publicly traded banks, EDGAR XBRL filings contain disclosures and data items that do not appear anywhere in the regulatory filing stack. BankFind has no connection to it.

**Pagination and rate limits at scale.** Pulling a full multi-quarter, multi-institution dataset through the BankFind REST API requires careful pagination, retry logic, and enough patience to wait through rate limiting. At scale it is a real engineering lift.


<figure>
  <img src="/static/blog/figures/fdic_total_deposits.svg"
       alt="Line chart of total deposits of the U.S. banking industry over time"
       loading="lazy">
  <figcaption>FDIC BankFind and BankRegAPI draw on the same regulatory universe (total deposits of the U.S. banking industry) but differ in how much history and structure they hand back. <em>BankRegReports analysis.</em></figcaption>
</figure>

## What BankRegAPI Adds

[BankRegReports](https://www.bankregreports.com) was built to solve exactly the gaps described above. The BankRegAPI consolidates FFIEC Call Report and UBPR data, Federal Reserve NIC and Y-9C, NCUA 5300, FDIC institutional data, and SEC EDGAR into a single normalized API with a consistent identifier system and a consistent units convention.

Install the SDK:

```bash
pip install bankregreports
```

Then pull data with the same ergonomics as any other Python data library:

```python
import bankregreports

brr = bankregreports.BankReg("brr_xxx")  # or set BANKREG_API_TOKEN env var

# Pull normalized Call Report / UBPR detail (about 150 fields) for one bank, last 8 quarters
df = brr.bank_deep_dive(852218, periods=8)  # 852218 = JPMorgan Chase Bank, N.A.
print(df.head())
```

The SDK returns a pandas DataFrame. Column names are consistent across sources. Units are documented and uniform, with no hunting through data dictionaries to figure out whether a field is in thousands or whole dollars. If you have ever pulled raw FFIEC bulk data and discovered mid-model that your deposit figures were off by a factor of 1,000, you understand why that matters.

### Cross-Source Identifiers

One of the most underappreciated problems in bank data is entity resolution. The FDIC uses FDIC certificate numbers. The Federal Reserve uses [RSSD](/blog/how-to-look-up-a-bank/) IDs. NCUA uses credit union charter numbers. SEC EDGAR uses CIK. These do not map cleanly to each other, and the crosswalks that do exist require ongoing maintenance as banks merge, change charters, or restructure their holding company trees.

[BankRegReports](https://www.bankregreports.com) maintains a canonical entity identifier (BRR-E-) that resolves across all of these source systems. When you pull data through the BankRegAPI, you get a consistent entity reference regardless of which underlying source the data came from. That sounds like a small thing until you have spent a week debugging a peer group analysis where the same bank appeared under three different identifiers depending on which data pull you were looking at.

### UBPR-Methodology Ratios

For ALCO reporting and regulatory exam preparation, UBPR peer ratios are the standard. The UBPR methodology defines specific calculation conventions: how NIM is computed using average earning assets, how efficiency ratio handles certain nonrecurring items, how capital ratios flow from the RC-R schedule. BankRegReports implements these calculations against the underlying MDRM data items, so the ratios you get out match what examiners see in their peer comparison tools. If you are building an internal benchmarking dashboard for your board or presenting to your primary regulator, that alignment matters.

### Full Schedule Depth

The FFIEC 041 and 031 contain schedules that are invisible to BankFind but critical for credit analysis. RC-N past-due and nonaccrual stratified by loan type. RC-C loan classifications. RI-B charge-off and recovery detail. RC-K average balance data that lets you compute actual yields rather than approximating them from period-end balances. BankRegAPI exposes this depth through the same consistent SDK interface, with the same units normalization applied.

You can explore the full endpoint catalog in the [Swagger UI at api.bankregreports.com](https://api.bankregreports.com/api/v1/docs/).

## Choosing Between Them

This is not a situation where one source is right and the other is wrong. They serve different jobs.

**Use the FDIC BankFind API when:**
- You need quick institutional metadata: charter class, location, failure status
- You are doing a rough market-sizing or screening exercise where FDIC's summary financial fields are sufficient
- You are building a lightweight public-facing tool and want to avoid API key management
- Your scope is limited to bank-level (not holding company) data

**Use BankRegAPI when:**
- You need full Call Report schedule depth: RC-N, RC-C, RI-B, RC-K
- You need holding company financials from Y-9C alongside bank-level data
- Your peer group includes credit unions (NCUA 5300)
- You need UBPR-methodology ratios for regulatory exam prep or board reporting
- You need SEC EDGAR integration for public company coverage
- You are building a production system and need consistent identifiers, documented units, and a maintained API rather than a raw government data endpoint

For most serious bank analysis workflows, the FDIC BankFind API is a reasonable starting point for institutional lookup, but it is not a substitute for access to the full regulatory filing stack. The deeper your analysis goes, whether credit quality modeling, ALCO benchmarking, M&A diligence, or stress testing, the faster you hit BankFind's ceiling.

## Getting Started with BankRegAPI

If your current workflow involves stitching together FDIC BankFind, raw FFIEC bulk downloads, and manual UBPR lookups, there is a better path. BankRegReports gives you a single authenticated API that covers the full regulatory data stack, with a Python SDK that returns clean DataFrames with documented columns and units.

The full endpoint reference is at the [Swagger UI](https://api.bankregreports.com/api/v1/docs/). You can get a free API key and start pulling data in minutes at [bankregreports.com/api/](https://www.bankregreports.com/api/). If you have been building bank models on raw government data sources and absorbing the normalization cost yourself, the time you get back on the first serious analysis will make the case.

## 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