Open Banking is about two related forms of openness.
The first is an open catalogue of a bank’s products. Banks publish standardised information about their accounts, loans, credit cards and other products so that consumers, comparison services and other businesses can see what is available, compare products across banks and monitor how those products change over time.
The second is the ability for a customer’s data to move securely between banks and approved third-party services when the customer authorises it. Instead of a customer’s transaction history, account details and financial information being locked inside one bank’s systems, the customer can choose to share that information with another provider.
In Australia, this system is regulated through the Consumer Data Right, or CDR.
How does Open Banking help consumers?
Open Banking enables two key capabilities:
-
Product Reference Data, or PRD, makes the market easier to see and compare.
-
Consumer-directed data sharing makes it easier for customers to use their own information when choosing or using financial services.
Together, they can make banking more competitive and less dependent on customers staying with a single provider simply because changing is difficult.
For example, a customer might use a comparison service to find a savings account with a higher interest rate, lower fees or fewer conditions. Someone applying for a home loan might compare the total cost and eligibility requirements of products across several lenders rather than relying on the information presented by their existing bank. A customer considering a switch could use their transaction history to help a new bank understand their financial circumstances, reducing the need to gather and upload documents manually. A budgeting or financial-management service could analyse accounts held across multiple banks, giving the customer a more complete view of their spending instead of forcing them to check each bank separately.
These examples are not the point of Open Banking by themselves but they illustrate the broader objective: customers should be able to see more of the market, make better-informed choices and use their own data without being permanently tied to the organisation that first collected it.
The Consumer Data Right
In 2017, the Productivity Commission’s Data Availability and Use inquiry recommended the creation of an economy-wide right giving consumers greater control over data held about them. Later that year, the Australian Government commissioned the Farrell Review into Open Banking, asking how that principle could first be applied to the banking system. The Government accepted the Review’s recommendations in May 2018.
Businesses accumulate enormous amounts of information about their customers, products and markets, but historically that information has been difficult for consumers to access, move and use. Australia’s Consumer Data Right was created to address that broader problem.
The objective was not simply to make banks publish data about their customers and products. It was to give consumers more choice, improve price transparency, encourage competition and make it possible for new services to emerge around data that had previously been difficult to access or compare. The original Open Banking terms of reference explicitly anticipated comparison services being able to assess products more accurately and help consumers find products better suited to their circumstances.
In practical terms, that could mean making it easier to move to a better account, compare the real cost of a loan, manage finances across multiple banks or discover that a supposedly competitive product is not competitive at all.
Banking became the first implementation of the broader Consumer Data Right and one of the first things CDR opened was not customer data at all, it was the banking market itself.
A right that is easy to overlook
The Consumer Data Right is not necessarily well known outside the organisations that implement it.
It has not been promoted like a consumer brand or a major public service. Instead, much of its value has been left to the market to discover. The expectation is that banks, fintechs, comparison services and other businesses will build useful products on top of the standard, and that consumers will experience the benefits through those products.
That approach has an important advantage: it allows innovation to emerge from many different organisations rather than prescribing a single way for consumers to use their data, but it also creates a visibility problem. If the market does not build a service that makes the underlying system understandable, most people will never see what CDR makes possible. They may benefit indirectly from better comparison, easier switching or more useful financial-management tools without knowing that a common data standard made those services possible.
Product Reference Data: the public side of Open Banking
In July 2019, the major banks began making standardised Product Reference Data, or PRD, available in machine-readable form. Consumer-directed sharing of personal banking data followed with the formal launch of CDR on 1 July 2020.
PRD is an important but sometimes overlooked part of Open Banking. Unlike consumer banking data, it contains no personal information and does not require authentication. More importantly, its publication is not voluntary.
Under the Consumer Data Right, organisations with Product Reference Data obligations (known as Data Holders) are required to provide a machine-readable representation of the financial products they offer and to keep that information aligned with the information they publish to the market. For banking, this effectively creates a mandated, openly accessible product catalogue. It can describe the characteristics of a product, including its rates and fees, eligibility criteria, terms and conditions, features, benefits, availability and other information contained on the Data Holder’s website or in relevant disclosure documents.
The significance of this is easy to underestimate. Before PRD, understanding the Australian banking market meant navigating individual bank websites, product pages and disclosure documents, each organised and expressed differently. Keeping a consolidated view current was a substantial data-collection problem in its own right.
CDR changes that model. Data Holders must expose this information through standard CDR-compliant APIs, using a common structure that software can retrieve and interpret consistently. The result is not simply another way to access a bank’s website content. It is a regulated, machine-readable representation of the products being offered across the market.
In practical terms, a Data Holder is the organisation responsible for the product and for meeting these disclosure obligations. A single Data Holder may operate multiple consumer-facing brands, and each brand may offer a different range of products.
That creates an interesting possibility. Instead of visiting hundreds of banking websites, interpreting differently structured product pages and periodically trying to determine what has changed, we can observe a large part of the Australian banking product market through a common interface; and that was the starting point for our own PRD application.
The Product Ledger
The Product Ledger is our way of turning Product Reference Data into something that feels like a view of the market rather than a collection of records. At a glance, it gives you a sense of what is happening in Australian banking today: the scale of the market, where the strongest offers are appearing, which products stand out and how different parts of the market compare. From there, you can move progressively deeper.
You might begin with a broad market view and notice that a particular savings rate, term deposit or home loan is materially different from the rest of the market. You can then look across the leading products in that category, search the wider catalogue, or drill into an individual product to understand the rates, fees, conditions and features that sit behind the headline offer.
That progression is important because it shows what Open Banking can enable when the underlying data is standardised and kept current. Instead of approaching the market one institution at a time, you can start with a question:
-
What are the strongest offers available today?
-
How large is this part of the market?
-
Which products are leading their category?
-
How does a particular product compare with the alternatives around it; and
-
Once something catches your attention, what are the conditions behind the headline number?
The Product Ledger is not intended to be a full commercial comparison service. It is a showcase of the information and knowledge that can be derived from Open Banking when product data from across the market can be brought together, compared and explored consistently.
CDR provides the underlying openness. The Product Ledger demonstrates what can be built on top of it.
From availability to ecosystem health
There is another question that matters just as much: Is everyone publishing it correctly?
Making product information available is only part of the story. For Product Reference Data to be genuinely useful, every Data Holder needs to publish that information consistently and in accordance with the Consumer Data Standards. That consistency is what makes the market comparable. If every bank interpreted the specification differently, any service built on top of PRD would need to understand dozens of variations and exceptions and the value of having a common standard would quickly disappear.
The Consumer Data Standards therefore define not just what information should be made available, but how that information should be structured and delivered.
This gives us another useful way to look at the banking ecosystem. As we collect Product Reference Data, we can also test each Data Holder’s responses against the specification and identify where they do not conform. Those issues are recorded as validation findings and can be examined over time. This is important because even relatively small inconsistencies can affect the usefulness of the data. A missing field, an unexpected value or an incorrectly structured response can make it harder for comparison tools and other services to interpret products reliably across the market.
So while the Product Ledger asks:
What does the banking product market look like?
the Ecosystem Health dashboard asks:
How consistently are Data Holders implementing the standard that makes that market possible?
That is the second side of the PRD story.
Open access makes the market visible. Standards make it comparable.
Measuring compliance tells us how well that standard is working across the ecosystem.
Why we chose a treemap to view compliance
Product Reference Data responses can be thought of as structured documents. They contain many different pieces of information: product details, rates, fees, features, eligibility requirements and other terms, all arranged according to an agreed specification.
When we test that response for compliance, we are effectively checking every part of that document to see whether it has been provided in the expected form. The challenge is: how do we show the result in a way that provides clarity to the viewer? A list of errors can tell us what went wrong, but it does not give us a sense of the response as a whole.
We wanted to be able to see the entire compliance state of a response laid out in front of us which is why we chose a treemap. The treemap turns the response into a visual landscape. Its composition reflects the structure of the information, the size of each area reflects the number of observed node instances, and colour shows the percentage of validation checks that pass, including checks that raise warnings.
This means the eye can interpret several things almost immediately. Large areas show parts of the response observed more frequently; they do not imply greater business importance. Colour draws attention to non-compliance. And the way the areas are grouped helps show where those issues sit within the overall structure of the product information. A small problem in an obscure part of a response therefore looks very different from a recurring problem in information that appears across thousands of products.
Instead of reducing compliance to a score or a list of failures, the treemap lets us see the shape of the response, where validation findings occur and how widely those parts of the structure are observed, all in a single view.
Measuring health at different levels
The dashboard separates successful API access from the quality of the responses returned. It shows four measures, each answering a different question.
API availability asks whether the endpoints we attempted to poll responded successfully. It is the percentage of attempted endpoint target-days that succeeded. A retry that recovers on the same day counts as a success, so this is a measure of our collection results rather than continuous uptime.
Material conformance measures the percentage of response assessments with no partial or fatal schema findings. Warning-only responses pass this measure.
Strict schema pass measures the percentage of response assessments with no schema findings at all. A warning therefore prevents a strict pass, even when that response passes material conformance.
Strict node validity looks within those responses. It is the percentage of individual schema-node validation checks that pass, with warnings counted as findings. This is the measure shown by the treemap's colours.
These measures explain why a single malformed field can cause a response to fail strict schema validation while most of its individual node checks still pass. A high node-validity percentage does not mean that every response can be used without handling exceptions.
The response selector lets the reader examine Brands, Product summaries or Product details. The data-holder filter and brand ranking let them compare participants. These are ways of selecting and comparing the observations, rather than separate headline health measures.
The Latest view uses the current assessment state. When a successful poll confirms that a document has not changed, its last assessment is carried forward. Over a selected period, the dashboard aggregates those daily carried assessments. Its findings count is then labelled finding-days: an outstanding finding carried across several days is counted once on each day, rather than being presented as a newly discovered issue each time.
We deliberately did not combine these different questions into a single CDR health score.
The problem with a healthy dashboard
Viewing the health of the CDR ecosystem created an interesting visualisation problem — most of the ecosystem is compliant. That is obviously a good result operationally. Visually, however, it is not particularly interesting.
A conventional compliance palette produces a very large field of green with a handful of small yellow, orange or red regions embedded within it. The reader learns very quickly that the ecosystem is predominantly healthy, but the things that actually require investigation are visually overwhelmed by everything that is working correctly.
So we added a second rendering mode: Rising Intensity. The idea came from visualisation work we had previously done with our visualisation palette generator, Spectra. Rather than treating every state as equally visually prominent, we increase visual intensity as something becomes more significant. Healthy observations remain deliberately restrained. As compliance deteriorates, saturation and intensity progressively increase through the warning states towards the most serious failures. In other words, visual prominence begins to represent the need for attention which changes the experience considerably.
The dashboard still shows the complete ecosystem, but the reader’s eye is naturally drawn towards the relatively small areas in which something is going wrong.
Instead of asking, "How healthy is CDR?", the reader can ask "Show me where it isn't".
The data plane underneath it
There is a considerable amount happening underneath these two pages, but the objective was to keep that complexity hidden (i.e. it just works).
Behind the scenes a data plane continuously collects Product Reference Data from the banking ecosystem, validates the responses and maintains the analytical structures required by the application. New observations are streamed into the platform and aggregated into structures designed for interactive analysis.
The information quoted in these pages is refreshed daily, giving us a current view of the ecosystem while retaining the performance characteristics of a purpose-built analytical application.