Hello! I build and maintain ffiec-data-connect, a Python library for retrieving FFIEC bank regulatory data (Call Reports, UBPR, institution attributes) from the CDR REST API. I also maintain the documentation at call.report.

Why are libraries and software needed to access regulatory data, if already available on a website?

Regulatory filings are distributed as XBRL (an XML dialect), not spreadsheets. Each institution's return is a separate file tagged with thousands of machine-oriented codes rather than human-readable field names. Values arrive as strings, dates in U.S. format, monetary amounts in thousands; the same logical figure appears under different codes across different schedules; and joining to FDIC or OCC sources requires crosswalking identifiers (RSSD, FDIC certificate number, OCC charter number) that don't match by default. A library handles the parsing, typing, code lookup, and identifier mapping, so you get a table ready for analysis instead of a multi-day (or week!) integration project.

Sponsorship funds the ongoing maintenance: monitoring for API drift, adjusting the library when a schema field changes, maintaining comprehensive test coverage, responding to issues, and revising documentation when an example stops working. I currently do this outside of regular work hours. Sponsorship allows me to sustain this pace, and to expand the scope over time.

The library is MPL-2.0 licensed. There are no paid tiers, license keys, or premium branches. Sponsorship funds work that ships to every user.

If your organization requires a formal vendor relationship — priority response times, custom integration work, or a service-level agreement — that is offered separately through Civic Forge Solutions LLC. See COMMERCIAL.md in the library repository. GitHub sponsorship is distinct from a commercial support contract.

For teams using the library professionally, monthly contributions make a meaningful difference. For students and independent researchers, a one-time contribution is equally appreciated.