Methodology
The Rate Ledger is a historical archive of the product data Australian lenders publish under the Consumer Data Right. Lenders with CDR obligations must publish their advertised rates, fees and product terms through public, standardised APIs. We collect those payloads every day, keep every version, and show how they change over time. Nothing on this site is a recommendation. It is a record.
Sources and coverage
Rates come from each lender's own Product Reference Data endpoints (Get Products and Get Product Detail, as defined in the Consumer Data Standards). Our collector has archived every banking and non-bank-lending data holder daily since 17 July 2026. Earlier history is incorporated from two archived open-source projects, with provenance recorded payload by payload: the open-banking-tracker archive (25 May 2022 to 27 October 2024) and the ratecheck-au archive (29 March to 19 May 2026, six-hourly, mortgages only). Both are MIT licensed. The cash rate series is taken from the RBA's published cash rate target decisions, at effective-date precision.
The record has holes, and we show them rather than paper over them. Two windows have no product-level data from any source: 28 October 2024 to 28 March 2026, and 20 May to 16 July 2026. They appear as grey bands on every timeline. Between March and October 2023 the open-banking-tracker collector requested a retired API version, so a growing share of product detail was lost in that window, peaking around a third of products in August and September 2023. Changes first observed after such windows are marked as spanning a data gap rather than dated to a day on which nobody saw them. We never interpolate across missing data.
How rates are read
Every payload is canonicalised (volatile timestamp fields are separated from content) and stored once, addressed by the SHA-256 hash of its content. The rate shown for any date is the most recently observed value at that date. Comparison tables show standalone advertised rate types only: variable, fixed, introductory, floating and market-linked, plus purchase, cash advance and balance transfer for cards. Discount, penalty and package-discount entries are adjustments relative to a reference rate, and lenders encode them inconsistently; some publish negative numbers, some positive discount sizes, some absolute package rates. We exclude them from comparison tables rather than guess. Rates implausibly below the RBA cash rate of the selected day are greyed and flagged as likely adjustments-published-as-rates. Loan-to-valuation bands are normalised to percentages; a few lenders publish ratios while declaring percentages, which we detect by value.
About half of all mortgage rate entries carry no machine-readable loan-to-valuation band at all. Many of those products do state an LVR range in their name or description, but not in the structured field the standard provides for it, which is why the data quality score counts LVR published only as free text. Filtering by LVR band therefore uses the published bands and lists products with no band of their own separately, under "not published", rather than assuming an unstated band is a high one. The bands themselves are treated as ranges: a product offered from 80 to 90 per cent appears under 80–90 and not under 70–80, and lenders' inconsistent boundaries, some writing 80.01, some 80.1, some 80, are handled as the same edge.
What is and is not shown
The Consumer Data Standards define thirteen product categories. This site publishes rate history for eight of them: home loans, personal loans, business loans, overdrafts, leases, credit and charge cards, transaction and savings accounts, and term deposits. Together these hold 5,475 of the 5,523 products we currently collect.
Leases appear on the commercial lending page. The standards separate them from business loans by legal structure rather than by purpose — business loans cover equipment finance that is not a lease, while a finance lease over the same equipment is filed separately — so a business comparing equipment finance would otherwise see only half the market. Novated leases sit in the same category but are consumer motor vehicle finance arranged through an employer's salary packaging; they are tagged so a reader can tell them apart rather than being hidden.
The remaining five hold 48 products between them, under one per cent, and each is left out for its own reason rather than for being small. They are still collected, archived and included in the data quality measures.
- Regulated trust accounts (29) are statutory accounts for solicitors, conveyancers and real estate agents. Where interest is paid, it is often directed by statute to a law society or fidelity fund rather than to the account holder, so a rate shown beside ordinary savings accounts would invite a comparison that does not hold.
- Margin loans (8) are investment lending, and every one publishes a rate. They are absent because we have no page where a margin rate can be compared against anything meaningful, not because the data is missing.
- Buy now pay later (8) mostly charges fixed fees instead of interest, and three of the eight are zero-interest government-backed loans for household energy efficiency. A rate table over products that are largely interest-free would mislead more than it informs.
- Trade finance (2) and travel cards (1) publish no rates at all. The trade finance products are bank guarantees and the travel card is prepaid, so there is nothing for a rate history to record.
Rules that changed over time
The standards are versioned, and what they require has changed. Loan purpose is the clearest case: it is a mandatory field in the current version of the lending rate schema, but under the earlier version an absent loan purpose was expressly permitted and meant the rate applied to every purpose. Marking an institution down today for a record published when omission was allowed would be unfair.
Our archive cannot resolve this retrospectively. Most of it was collected before we existed, by a third party who did not record which version each institution was serving, so for those records the question of which rule applied has no answer. We do not guess at one.
So the loan purpose measure now applies only where the obligation can be shown: to records from our own collection, published by an institution serving the endpoint version whose schema makes the field mandatory. Everything else is excluded from the measure entirely — neither counted against an institution nor counted in its favour. Institutions serving an older endpoint version are not assessed on this at all; they are already assessed on the version itself.
Endpoint versions
The Consumer Data Standards publish an endpoint version schedule: a dated list of the versions each
API must implement, and the dates from which the previous version may be withdrawn. Version 7 of Get
Product Detail had to be implemented by 13 July 2026, version 6 by 16 March 2026, version 5 by 14 July
2025. Every response an institution sends states the version it served, in an x-v header.
This is the one measure on this site where neither side of the comparison is ours. The version comes from the institution's own response; the deadline comes from the published standard. We are not reading a product description, inferring a category, or judging whether a rate looks plausible.
An institution is counted as behind from the date it missed, but only penalised once the version it is still serving may be retired. The standards deliberately leave a gap between the two dates so an old and a new version can coexist while implementations catch up, and it would be unfair to mark an institution down during a window the standard itself grants. Lateness is measured from the first deadline missed rather than the most recent one, so an institution three versions behind is not described the same way as one that has just missed the latest.
Corrected rate encodings
A rate in the standard is a decimal proportion, not a percentage figure: the published examples give "0.2" for 20 per cent, so 4.25 per cent is written "0.0425". A handful of institutions publish the percentage instead, so a savings account has appeared in our data at 425 per cent and a personal loan at 1,495 per cent. The only sensible reading of "4.25" in a rate field is 4.25 per cent, so we divide by 100 and mark the rate as corrected wherever we show it. Hovering the marker gives the value the institution actually published.
To be exact about the basis for this, because it is a correction to someone else's published figure: the standard sets no upper limit on a rate and does not forbid the value 4.25, so this is not a breach of the technical schema. It is an accuracy problem. The standard separately obliges an institution to take reasonable steps to keep its product data accurate, and a rate field reading 425 per cent is not accurate about a product priced at 4.25. Every institution corrected here also publishes the same product correctly encoded elsewhere in its own data, which is what makes the reading a matter of record rather than of opinion.
Two guards keep this from becoming guesswork. We only correct when the result lands under a generous ceiling for that product type, set well above the highest legitimate rate we observe in it; anything still absurd after the division is withheld from the comparison table rather than displayed. And we never correct in the ambiguous range: a rate published as 0.5 could be 50 per cent or a mis-encoded 0.5 per cent, so it is flagged and withheld, not adjusted. What supports the correction beyond arithmetic is that every affected product in our archive has published the same rate both ways at different times, so the corrected value can be checked against the institution's own history of the same product.
Correcting the display does not soften the grade. The data quality score reads the value as published, so an encoding fault costs the institution exactly what it did before, and the archive itself is never altered.
The data quality score
Each lender's A to E badge scores the quality of what that lender publishes. It is computed only from observed, countable behaviour, never from reputation, size or our opinion of the lender. Every metric can be traced to specific payloads on specific dates in the archive. Where a metric cannot be measured for a lender it is shown as not measurable and carries no penalty. When lenders merge, quality history stays with the brand that published the data; a merger never launders a scorecard.
| Metric | What it measures | Penalty | Cap |
|---|---|---|---|
| Endpoint failures | Share of our own collection attempts that fail in a way attributable to the lender: server errors (5xx), advertised products whose detail endpoint is dead (404), or a success response carrying malformed data. Access blocks and timeouts are excluded. | 0.5 × % | 20 |
| Stale lastUpdated | Content changed but the lender's lastUpdated timestamp did not, measured against content hashes | 0.3 × % | 25 |
| Noisy lastUpdated | lastUpdated bumped with no content change, making the freshness signal meaningless | 0.1 × % | 10 |
| Missing lastUpdated | lastUpdated never published at all (a conformance gap, scored separately from dishonesty) | 0.1 × % | 5 |
| Missing descriptions | Products published without a description | 0.1 × % | 5 |
| Blank loan purpose | Mortgage rates published without a loan purpose, where the standard version the institution serves makes that field mandatory | 0.15 × % | 15 |
| Implausible rate encoding | Rates stating a figure above 100 per cent, which the institution's own history of the same product contradicts | flat 10 if any | 10 |
| Fixed without a term | Fixed rates whose term cannot be parsed from the standard duration field | 0.1 × % | 10 |
| LVR in free text | LVR bands published only as prose instead of structured tiers | 0.05 × % | 5 |
| Endpoint version not implemented | Required versions of the Get Product Detail endpoint the institution has not implemented, counted only once the version it still serves may be retired | 5 × count | 15 |
The composite starts at 100, subtracts the capped penalties, and maps to grades: 90 or above is an A, 75 a B, 60 a C, 45 a D, and below that an E.
How endpoint reliability is scored
An endpoint that fails deprives everyone who relies on the data, visibly, so it earns a penalty. But only a failure the lender can answer for counts. We score an error against a lender when its server returns a 5xx, when a product it advertises in its list has a detail endpoint that returns 404, or when it returns a success response carrying data that will not parse. Those are the lender's to fix.
Two kinds of error are deliberately left out. Access blocks and rate limits, where a shared hosting firewall rejects our collector's requests or throttles them, describe the path between us and the lender, not the quality of what the lender publishes. And errors from the two archived open-source collections that make up our pre-2026 history are not scored at all: one of them suffered a version-negotiation fault through much of 2023 that put dozens of unrelated institutions at high error rates in the same months, which is a fact about that collector, not about the lenders. We score only the observations we collected ourselves, and only the failures that are the lender's own. The full error rate, including the excluded kinds, is still shown on each scorecard and in the month-by-month coverage table as context.
Why some lenders are not graded
Two separate things have to be true before a lender carries a grade, and at the moment the second is not. The first is evidence: we grade a lender only once we have observed it on at least 28 separate days. The second is publication: whether we publish letter grades on named institutions at all. That is a decision, not a measurement, and it is one we are still reviewing — so no grade is published yet, for any lender, however long we have watched it. We have kept the two apart deliberately rather than quietly raising the 28-day threshold to the same effect, because that would have disguised a decision of ours as a fact about the data on the one page whose purpose is to tell you which is which. Where no grade is shown, the structural checks are still reported and are current.
On the evidence half of that test, the reason for the 28 days is that the freshness checks are differential: they compare one day's payload against the next, so a lender we have only just begun watching cannot fail them. It would score well for the sole reason that we had not yet had the chance to catch it, and it would then sit above established lenders with years of history and a handful of real defects. Without the rule, brands observed for three days score in the nineties and outrank major banks measured across tens of thousands of observations, which is precisely backwards. Twenty-eight days spans a full monthly repricing cycle, so a lender that maintains its timestamps has had at least one opportunity to demonstrate it. Withholding a grade says nothing about the lender; it is a statement about the limits of our evidence, and that half of the test resolves by itself as the archive lengthens. The publication half does not, and is not meant to.
Why these weights
The weights implement one principle: penalties are ordered by the harm the behaviour does to anyone relying on the data. Dishonest freshness signals rank worst. When content changes without a lastUpdated bump, every consumer, comparison service and researcher relying on that timestamp is silently misled, and nothing in the payload reveals it; only an archive that hashes content day after day can detect it. It therefore carries the largest weight and the largest cap. Attributable endpoint failures rank next, because an endpoint that fails deprives everyone equally and visibly, scored on the narrow, lender-owned definition set out above. Conformance gaps such as missing descriptions or blank loan purposes rank lower because a reader can at least see that the information is absent. Implausible rate encodings attract a flat penalty because their presence, not their volume, indicates the defect: an institution either validates its rate encodings or it does not. Caps exist so that no single dimension can dominate the grade, and so a lender weak in one respect is not painted as weak in all.
Three facts constrain any suspicion that the scale is tilted. Every change to the weights is dated and set out in the rule history below, including the changes made while the site was being built and before anything was published; nothing is altered silently. The letter grade is the only place judgement enters: every underlying percentage is displayed ungraded on each lender's scorecard, so a reader who disagrees with our weighting can discard it and apply their own. And the counts beneath those percentages are not a matter of judgement at all; they resolve to content-addressed payloads on dated observations that either exist in the archive or do not.
That last point is worth stating as a distinction rather than leaving implied. The counts and percentages are statements of fact about what an institution published and when, and we will correct any that are wrong. The letter grade, and the weights that produce it, are our opinion — a considered view of which defects matter more, drawn from those facts and honestly held, but not itself a fact. A reader who weighted the same figures differently would reach a different grade, legitimately. We publish the figures unweighted for exactly that reason.
Rule history
What changed in the scoring, when, and why. Scores either side of a change are not directly comparable, and we would rather say so than present a moving measure as a fixed one.
| Date | Change | Reason |
|---|---|---|
| 18 July 2026 | Initial weights set | Fixed before any institution's results had been computed, so no weight was chosen knowing who it would favour. |
| 20 July 2026 | Grading withheld below 28 days of observation | A grade computed on a few days of data says more about our collection window than about the institution. |
| 20 July 2026 | Reliability measure suspended | It was measuring our own collection failures, not the institutions'. A measure that moves a grade must resolve to something about the institution. |
| 22 July 2026 | Reliability measure reinstated, narrowed | Our collection fault was fixed and the measure now counts only failures attributable to the institution — server errors, missing endpoints, malformed payloads — observed by our own collection. |
| 26 July 2026 | Negative rates no longer penalised | They are expressly valid. The standard's own examples include negative rates, so treating them as a fault was our error, not the institutions'. |
| 26 July 2026 | Rate encoding measure renamed and re-based | Publishing a rate above 100 per cent does not breach the technical schema, which sets no upper bound. The measure now rests on the accuracy obligation and on the institution's own contradicting records. |
| 26 July 2026 | Loan purpose narrowed to where it is mandatory | The field became mandatory only in the current schema version. Records published when omission was permitted, and records whose governing version cannot be established, are excluded entirely. |
| 26 July 2026 | Grading now requires 28 days of our own observation | The threshold had been met by archived records collected by others years earlier, so an institution could be graded on data we had not seen ourselves and which no longer described it. |
| 26 July 2026 | Rate encoding measure widened to all products | It had only ever examined home loan rates, while this page described it without that limit. A rate stating a hundred times its true value is no less wrong on a savings account. |
| 26 July 2026 | Endpoint version compliance added | Whether an institution has implemented the endpoint versions the standards require by their published dates. Counted only once the version it still serves may be retired. |
| 5 August 2026 | Publication of grades separated from the evidence threshold | Our collection began on 17 July 2026, so the 28-day threshold would have been met by every lender on 13 August, and the nightly build writes to this site with no step in between. Publishing letter grades on named institutions would therefore have started on a date rather than on a decision. Publication is now its own switch, currently off. It was kept separate from the 28-day threshold on purpose: raising that number instead would have produced the same silence while presenting a decision of ours as a property of the data. |
Classifications
Tags such as SMSF, non-conforming, bridging and first-home are assigned by dated, published pattern rules over each product's own name, description and eligibility text, scoped to the product categories where they make sense; a mortgage advertising "help your kids buy their first home" is not a youth product. Every match records the exact text that triggered it. Products matching no rule stay unclassified. Most products are unclassified, and that is honest. Prime is only ever tagged on an explicit marker; the absence of non-conforming markers never implies prime.
Pass-through timing
Where a rate change is observed within 60 days after an RBA cash rate decision, we report the lag in days between the decision's effective date and the first observation of the changed rate. Collection is daily, so a lag is precise to about a day during continuously observed periods. Changes first seen after a data gap are flagged and excluded from lag statistics.
Limitations
We archive what lenders publish, which is not always what they charge; advertised rates exclude negotiated discounts. Observation grain is daily (six-hourly in parts of 2026), so same-day repricing sequences collapse to one change. Roughly nine per cent of recorded changes span a data gap and carry that flag. A small cohort of lenders blocks our collector's infrastructure; we collect them via an alternative route and disclose per-lender coverage on their scorecards. Product identity across lender rebrands, mergers and identifier churn is resolved by published, dated mapping rules; unresolved cases remain split rather than being force-merged.
Corrections
If you are a lender and believe a score or record is wrong, email admin@therateledger.com with the product and date. The archive is content-addressed, so any dispute resolves to specific payloads. Collector details for endpoint operators are at /bot.