Watch FDIC bank failures and assistance transactions

The problem

The FDIC publishes a historical dataset of bank failures and assistance transactions. Analysts, journalists and counterparties who follow bank resolutions want to know when a new transaction appears, and when figures already published, such as the estimated cost, are revised.

This guide monitors the complete dataset as one record per transaction, keyed by the FDIC's transaction identifier, so each run reports new transactions and field-level revisions.

What the source contains

Bank failures and assistance transactions · Federal Deposit Insurance Corporation

Monitor bank failures and assistance transactions with publisher identifiers, documented fields, retained source evidence and repeatable change detection.

11 typed fields · 4,117 records in SourceFinch's latest run on October 12, 2026 · publisher updates: publisher updates; monitor daily · full source page

What a change means

• A new transaction_id: a transaction that was not in the previous run. Check resolution_type before calling it a failure, because the dataset also holds assistance transactions.
• A change to cost, assets or deposits on an existing transaction: costs can be empty at first and revised later.

Set it up in the console

1. Open the Verified recipe. Open the Bank failures and assistance transactions recipe in the console. It keeps the reviewed URL, fields and record key (transaction_id), and shows the latest captured sample. Open in the console
2. Create the monitor. Name the monitor, keep the daily schedule or pick another (the console shows the monthly run cost), confirm that you have the right to monitor the source, and choose Create monitor.
3. Run the baseline. The first run is the baseline: every record is new. From the second run on, the monitor reports what was added, changed or removed, field by field, with the evidence behind each value.
4. Choose how you hear about changes. In Alerts, choose immediate change emails or a daily or weekly digest; each monitor can override that on its own page. For your own systems, add a signed webhook in Destinations. Alerts and team

The same through the REST API, CLI or MCP

Every surface creates the same monitor from the same Verified recipe. You confirm you have the right to collect the source (rights: true).

Bank failures and assistance transactions

# the Verified entry (fields, recipe, sample, terms) as JSON
curl https://sourcefinch.com/v1/catalog/fdic-bank-failures -H "Authorization: Bearer $SOURCEFINCH_API_KEY"

# create the monitor from source.json (below)
curl -X POST https://sourcefinch.com/v1/sources \
  -H "Authorization: Bearer $SOURCEFINCH_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d @source.json

# then run it now (later runs follow the schedule)
curl -X POST https://sourcefinch.com/v1/sources/$SOURCE_ID/runs \
  -H "Authorization: Bearer $SOURCEFINCH_API_KEY" \
  -H "Idempotency-Key: $(uuidgen)"

sourcefinch login
sourcefinch catalog get fdic-bank-failures --source-json > source.json
sourcefinch sources create --file source.json
sourcefinch runs create $SOURCE_ID --wait
sourcefinch records $SOURCE_ID

claude mcp add --transport http sourcefinch https://sourcefinch.com/mcp

# then ask your agent:
"Use SourceFinch to monitor Bank failures and assistance transactions: get_catalog_source fdic-bank-failures,
then create_source with its create_source_args (dry run first), then run_source."

{
  "name": "Bank failures and assistance transactions",
  "url": "https://api.fdic.gov/banks/failures?limit=10000",
  "recipe": {
    "mode": "http",
    "format": "json",
    "items": "$.data[*]",
    "fields": {
      "city": "data.CITY",
      "cost": "data.COST",
      "name": "data.NAME",
      "state": "data.PSTALP",
      "assets": "data.QBFASSET",
      "deposits": "data.QBFDEP",
      "certificate": "data.CERT",
      "failure_date": "data.FAILDATE",
      "failure_year": "data.FAILYR",
      "transaction_id": "data.ID",
      "resolution_type": "data.RESTYPE"
    },
    "required": [
      "transaction_id",
      "name"
    ],
    "types": {
      "city": "string",
      "cost": "number",
      "name": "string",
      "state": "string",
      "assets": "number",
      "deposits": "number",
      "certificate": "string",
      "failure_date": "string",
      "failure_year": "string",
      "transaction_id": "string",
      "resolution_type": "string"
    }
  },
  "key_field": "transaction_id",
  "schedule": "daily",
  "rights": true,
  "catalog": {
    "slug": "fdic-bank-failures",
    "version_id": "fb07ed99-b20a-4155-b3e4-3398b15ee1a5"
  }
}

Alerts and evidence

New transactions are rare, so an immediate change email is a good default: most days you hear nothing, and the email lists each changed field before and after.

Every run keeps the publisher's exact response with its SHA-256 hash and a signed manifest, and every value points back to where it was read. How that works is in the docs:

• Review changes and receipts
• Alerts: change emails and digests
• Evidence and export: what a run keeps, bundles, CSV/JSON/XLSX
• Checking an evidence bundle offline
• Verifying signed webhooks
• Rights and acceptable use

Limitations

• This is reported historical data, not a prediction of bank distress.
• Check the resolution type before describing a row as a failure.
• Costs may be empty or revised.
• Records include historical institutions without a certificate number.

Usage rights, terms posture and reliability for each source are on its source page. They are our documented understanding of each publisher's stated terms, not legal advice.

Related