RateAPI Data Methodology

RateAPI aggregates financial rate data from credit union websites across America. We focus on the data points that matter for rate comparison and financial planning across 11 product categories.

Products

• Mortgages: 30-year fixed, 15-year fixed, 20-year fixed, 10-year fixed, adjustable-rate mortgages (5/1, 7/1, 10/1 ARMs)
• Auto Loans: New vehicles, used vehicles, certified pre-owned, refinancing
• HELOCs: Home equity lines of credit with fixed and variable rates
• Personal Loans: Secured and unsecured personal loans
• Credit Cards: Rewards, cash back, balance transfer, secured, business, student, and low-rate cards

Fields Captured

• rate — Base interest rate before fees
• apr — Annual Percentage Rate including fees and points
• points — Discount points as a percentage of loan amount
• term — Loan term in months
• productType — Canonical product category
• productName — Original product name from source
• display_name — Readable product label (e.g. "48-Month Certificate"); product_name is the raw source name
• institution — Credit union or lender name
• url — Source URL where rate was observed
• loan_program — Mortgage loan program classification: conventional, FHA, VA, USDA, or jumbo (96.7% accuracy)
• is_promotional — Flag for promotional/teaser rates detected via text patterns and statistical analysis

Source Types

• HTML pages: Standard rate tables and product pages
• PDFs: Rate sheets published as downloadable documents
• Embedded widgets: Third-party mortgage calculators

We maintain two distinct timestamp concepts to provide maximum transparency about data freshness.

Observed vs Effective

• observed_at — When RateAPI retrieved and parsed the source page
• effective_at — When the lender states the rate is effective (if disclosed)

When a source doesn't disclose an effective date, we only provide observed_at. We never invent timestamps.

Credit unions name their products inconsistently. We normalize to canonical categories so you can compare apples to apples.

Product Type Mapping

• "30 Year Fixed Rate", "30-Yr Fixed", "Thirty Year Mortgage" → 30-year-fixed
• "15 Year Fixed", "15-Year Fixed Rate" → 15-year-fixed
• "5/1 ARM", "5-Year Adjustable" → 5-1-arm
• "5/5 ARM" → 5-5-arm; a name that says adjustable without naming a schedule → arm. A product whose name contains "ARM" or "adjustable" can never normalize to a -fixed type, whatever an extractor proposes.

Term Normalization

All terms are converted to months. "30 years" becomes 360 months.

APR Handling

• When APR is provided by the source, we use it directly
• When APR is missing, we mark the field as null — we don't calculate or estimate
• We preserve the original productName alongside our normalized productType

Data quality matters. When we find errors, we fix them transparently.

We do not silently overwrite historical observations. If a parsing error is detected, we append a correction record with a reason code. This preserves full audit history.

Correction Reason Codes

Not all data points are equally trustworthy. We provide confidence signals at two levels.

Offer Ranking

We built this algorithm because we've been burned too many times by "low rates" that came with thousands in hidden fees. A 6.25% APR sounds great—until you discover the 2.5 points and $3,000 in origination fees that make it more expensive than a 6.75% rate with zero points.

So we rank offers the way we wish every rate site did: by what you'll actually pay, not what looks best in a headline. Every offer gets scored on APR, points, fees, data freshness, and source reliability. The lowest advertised rate doesn't always rank first—and that's intentional.

We also penalize lenders who exhibit deceptive bait-and-switch behavior—like advertising ultra-low rates that are rarely available or burying qualification requirements. Unlike affiliate-driven comparison sites that profit from promoting specific lenders, we have no financial incentive to rank any offer higher than it deserves.

Automated checks flag suspicious data before it reaches the API.

Flagged records enter a review queue before publication. We'd rather delay than publish bad data.

Quarantine & independent confirmation

A rate that moves more than 150 basis points day-over-day versus the currently published value is quarantined at ingest — held out of every API surface, ranking, and benchmark. It publishes only after an independent re-scrape on a later day reproduces the value within 12.5 bps. Real market moves confirm and publish within about a day; extraction glitches never reproduce and stay held for review. The bias is deliberate: hold data rather than publish a wrong rate.

End-to-end pipeline canaries

• Synthetic canary institution. Every day we scrape a rates page we control — with known exact rates, APRs, and points — through the identical production pipeline (queueing, browser, extraction, classification, ingest), then assert every value landed byte-for-byte. Any missing or mutated value pages the team with the exact field that broke. Canary data never enters customer results.
• Dependency canary. Every extraction model and service we rely on is health-checked daily with minimal live calls, so a silently degraded dependency is same-day news, not a slow data-quality leak.
• Provenance on every row. Each rate carries its observed timestamp (as_of), source institution, and extraction confidence — you can always answer "when and where did this number come from?"

RateAPI is built toward a fiduciary standard: neutral ordering, transparent methodology, and no pay-to-rank.

• We don't sell leads. Your users' data stays yours.
• We don't accept placement fees. Ordering is by APR (or your chosen sort), not by who paid more.
• We don't have affiliate relationships with the credit unions we track.

Our incentives are aligned with yours: accurate, timely data that you can trust to power your products.

This section provides detailed technical documentation for developers and AI agents who need to understand the exact structure and behavior of rate data.

Timestamp Fields

Canonical Product Types

Why ARMs share one benchmark bucket

The canonical types above record what a product actually is. Benchmark statistics are a separate question, and there every adjustable-rate mortgage is aggregated into a single mortgage_arm bucket regardless of its initial fixed period.

This is a sample-size decision, not a claim that a 5/1 and a 10/1 are the same product. Measured in July 2026, roughly 750 ARM offers were live across the whole country inside the freshness window. Split four ways by initial period and then across fifty states, most cells would hold a handful of rates — too few to support a percentile worth quoting. A median computed from three offers is a number, not a benchmark. If ARM coverage grows materially, the split becomes worth revisiting.

What matters more than the split is that ARMs are never counted inside the fixed-rate buckets. An ARM's introductory rate sits structurally below a comparable fixed rate, so mixing the two both depresses the published fixed-rate median and, for a borrower checking an ARM quote against the fixed distribution, makes an ordinary offer read as market-leading.

Correction Reason Codes

Confidence Score Ranges

• 0.9 - 1.0: Excellent — highly reliable data
• 0.7 - 0.9: Good — minor caveats possible
• 0.5 - 0.7: Fair — use with caution
• 0.0 - 0.5: Low — verify independently

API Query Examples

# Get personalized mortgage recommendations
curl -X POST "https://api.rateapi.dev/v1/decisions" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "decision_type": "financing",
    "context": { "geo": { "state": "CA" } },
    "product_request": {
      "product_type": "mortgage",
      "amount": 500000,
      "term_months": 360
    }
  }'

Credit unions have fields of membership — you may need to live in certain counties, work for certain employers, or join an association before you can open an account. Ranking an offer a user can't access erodes trust in every other recommendation, so we determine who can join each credit union and attach that verdict to ranked offers. This section explains how that data is collected, verified, and served.

Three Acquisition Layers

• NCUA charter data. The NCUA publishes machine-readable charter classifications (TOM codes) and branch locations for every federally insured credit union. This gives an authoritative baseline for the field-of-membership type — community, employer-based, associational — plus a geographic footprint proxy. It's refreshed quarterly when the NCUA publishes new data.
• The credit union's own membership page. The same scraping infrastructure that collects rates also reads each credit union's "who can join" page — the criteria the institution actually publishes, including join paths like "anyone can join through a one-time association donation." This is the primary source for join paths, employer lists, county footprints, and fees.
• Validation. Before eligibility data ships, extraction precision is measured against independently reviewed samples, and a synthetic canary page with known membership criteria runs through the full production pipeline daily — asserting value-by-value that extraction still works, forever.

Evidence-Quote Verification

Every claim we extract — each employer, county, association, fee, and join path — must be backed by a verbatim quote from the credit union's own page. A verifier then machine-checks that the quote actually appears in the captured page text. Claims whose evidence doesn't appear are dropped before they're ever stored, and each dropped claim lowers the record's confidence score. A fabricated membership claim is structurally detectable, not just unlikely.

Conservative by Design

• We say "unknown" rather than guess. When a membership page can't be found or parsed confidently, the status is unknown — never an inferred verdict.
• We never hide a credit union from results. Eligibility annotates and tie-breaks rankings. The eligible_only preference is in beta — gated behind our identity-verification threshold, it currently annotates without filtering — because wrongly hiding a credit union a user could join is a worse error than showing one they can't.
• Extracted values are sanity-checked against closed lists. Counties must exist in the Census county list for their state, fees are bounds-checked, and conflicts with NCUA charter data cap confidence and flag the record for review.

Guidance, Not a Guarantee

Eligibility data is presented as guidance. Every record links the credit union's own membership page as evidence_url so you can verify the criteria at the source, and the final membership determination is always made by the institution. See the Membership Eligibility API documentation for the response fields and endpoints.

Proper attribution helps users verify data sources and supports transparent financial journalism. Use the format appropriate for your context.

Academic & Journalistic Citation

For research papers, news articles, and formal publications:

API Partner Attribution

Attribution is not required when you display rates to your own users inside your own product. Build on the API under your own brand — that is what an embeddable rate feed is for.

If you would like to credit the source anyway, "Rates powered by RateAPI" near where rates are displayed is the form we suggest, optionally alongside a link to rateapi.dev/methodology so your users can check how the data is collected. Both are welcome, neither is a condition of use.

For term definitions used throughout this document, see the rate glossary, or review pricing and access tiers on the pricing page.

Widget Attribution

The RateAPI embed widget includes built-in attribution that must remain visible. See the Widget Documentation for complete requirements.

• "Source: RateAPI" link in the widget footer
• "Methodology" link for data transparency

LLM & AI Agent Citation

When AI agents or language models cite RateAPI data, include:

For MCP-connected agents, the lastUpdated timestamp is included in every API response. Always surface this timestamp when presenting rate data to users.