ALCO Data Requirements for Asset-Liability Management

Every ALCO meeting eventually hits the same wall: someone pulls a number from a spreadsheet, someone else pulls a different number from the core system, and twenty minutes of the meeting evaporate arguing about which one is right. If you have sat through enough of those meetings, you know that the data problem is not peripheral to asset-liability management; it is the problem.

This post is about the regulatory data layer specifically: what an ALCO actually needs from public filings, where those filings live, what shape they are in when you get them, and how to stop rebuilding the same data pipeline every eighteen months.

What Does ALCO Actually Need From Regulatory Data?

Asset-liability committees manage interest rate risk, liquidity risk, and funding composition. The regulatory data that matters for those functions falls into a few distinct buckets.

Rate-Sensitive Asset and Liability Composition

The core of any ALCO model is the repricing schedule: what matures or reprices when, and at what rate. The FFIEC Call Report RC-E (deposit composition), RC-C (loan portfolio detail), and RC-K (average balance and interest data) schedules are the primary public sources for this. RC-K gives you average balances and interest income/expense for the period, which lets you back into average yields and costs with reasonable precision.

The problem is that these schedules are not delivered in a format that drops cleanly into a model. The FFIEC bulk download is ZIP files of text, organized by period and report type. Column names are MDRM codes: four-letter prefixes followed by four-digit item numbers, like RCON2948. Without the MDRM data dictionary cross-referenced to a human-readable label, you are reading hieroglyphics.

Peer Benchmarking and Industry Context

No ALCO runs in isolation. Examiners compare your NIM, your deposit beta, your loan-to-deposit ratio, and your cost of funds to peer institutions. That means you need peer data, and peer data means you need to pull, clean, and normalize the same regulatory schedules across potentially hundreds of institutions.

The UBPR (Uniform Bank Performance Report) is the classic tool for this. It is pre-calculated ratios built from Call Report data, published by the FFIEC. The problem: the raw UBPR data files are wide, poorly documented, and require their own translation layer. The FFIEC publishes a data dictionary, but mapping UBPR item codes to meaningful labels and matching them to Call Report source items is a project in itself.

For holding company analysis, you are working with the Federal Reserve’s Y-9C (FR Y-9C Consolidated Financial Statements for Holding Companies), which follows similar logic but covers consolidated holding company financials. NIC (National Information Center) data from the Fed provides entity relationships: who owns what, which charter rolls up into which holding company.

Credit Union Data

If your ALCO process involves competitive deposit pricing or market share analysis, NCUA 5300 Call Report data matters. Credit unions price aggressively on deposits in many markets and they do not show up in FFIEC filings. The NCUA publishes 5300 data quarterly, but it uses its own item code system and its own schedule layout.

Capital Market Disclosures

For publicly traded banks and their holding companies, SEC EDGAR provides 10-K, 10-Q, and 8-K filings with interest rate sensitivity disclosures, rate shock tables, and management discussion of NIM drivers. These are qualitative supplements to the quantitative regulatory data, but they are useful context for peer analysis.

The Data Acquisition Problem

Here is what the raw acquisition pipeline actually looks like if you build it yourself: FFIEC bulk files from CDR for Call Reports, a separate download path for Y-9C and other FR forms, UBPR files from FFIEC via a different endpoint, FDIC BankFind Suite API for institution-level data, NCUA’s own download portal for 5300 data, and SEC EDGAR’s EDGAR Full-Text Search or XBRL viewer for company facts.

Each source has different update cadences, different file formats, different encoding quirks, and different handling of restatements and amendments. The FFIEC CDR has changed its bulk file structure over the years, so a pipeline you built for 2018 data will not necessarily work on 2024 data without modification. NCUA 5300 rates and ratios are stored as integers scaled by 100: a rate of 4.25% is stored as 425. The SEC changed how it reports investment values in 13F filings in 2023, introducing a units ambiguity that silently corrupts values if you do not handle it.

None of this is insurmountable, but it represents weeks of work to build correctly and ongoing maintenance burden as sources evolve. For most bank treasury teams, that is not where analytical capacity should be spent.

What This Looks Like in an ALCO Workflow

A realistic ALCO data workflow built on regulatory sources looks something like this:

Monthly or quarterly data pull: Automate the fetch of Call Report metrics and UBPR ratios for your institution and peer group as new quarters are published. BankRegReports handles the publication lag and restatement propagation, so you are not chasing stale numbers.

Rate sensitivity context: Pull Federal Reserve H.15 or Fed Funds target rate history alongside your repricing data to build the deposit beta and NIM sensitivity charts your ALCO package requires.

Peer comparison tables: Use industry aggregate data from BankRegReports alongside peer-institution pulls to build the percentile rankings your board and examiners expect.

Examiner preparation: When exam season approaches, having clean, source-traceable regulatory data with clear provenance (this number came from RC-K line item RIAD4010, period 2025Q4, as filed) is a material advantage. Examiners can and do cross-reference your internal reports against the regulatory filings. If your numbers diverge from the filing, you need to know why before they ask.

Avoiding Common ALCO Data Errors

A few issues come up repeatedly when banks try to build this data layer themselves:

Consolidated vs. bank-only reporting: Call Reports are filed at the bank charter level. Y-9C is filed at the holding company level. These are not the same entity, and for large institutions the numbers diverge materially. Make sure you are comparing like to like when you build peer groups.

Rate and ratio unit scaling: As mentioned, NCUA 5300 stores rates as integers scaled by 100. Some legacy financial data providers carry this through without correction, producing obviously wrong numbers that are easy to miss if you are not looking for them.

Restatements and amendments: Banks restate Call Report data. The most current filing for a given period is what matters, but raw data files do not always make it easy to identify which version is current. BankRegReports resolves this in the data layer so you are always working with the most current filed values.

Dead codes and discontinued items: MDRM codes are retired and replaced over time. A metric you have been tracking for five years may have migrated to a different item code. Pipeline breakages from this are quiet (the data just stops updating) and they are easy to miss.

Getting Started

The ALCO data requirements regulatory bank teams face are not going to simplify on their own. The regulatory filing ecosystem is large, fragmented, and maintained by multiple agencies with different priorities. Building and maintaining a reliable pipeline into that ecosystem is expensive.

BankRegReports was built specifically to absorb that complexity. The platform ingests, normalizes, and serves the full stack of public regulatory data (FFIEC, FDIC, Federal Reserve, NCUA, SEC EDGAR) through a clean API that lets your team focus on analysis rather than data plumbing.

The Call Report and UBPR data is there, clean, and ready to use.