We archive about as much data as ASIC and other regulatory bodies or institutions make available. The API we make available to all clients by virtue of their assigned key provides access to a large number of resources and tools - most of which they'll never use. This article introduces the ASIC API in brief in order to support some scheduled articles that details our Broker Matrix API.
Note: The information in this article provides an understanding of how our finance marketing methodology is shaped. The mortgage broker website and digital platform we provide brokers are built on the back of intelligence gained from real-world research, and these insights are available via a number of always-updated APIs.
Background: I recently spoke to an aggregator about the performance of some of their tools. The individual I spoke to was 'confused' by our findings, and without knowing anything about our fintech roots, he questioned the validity and veracity of our data (he was likely fed information of the 'ruinous empathy' kind by his subordinates, as opposed to radical candor, with the latter used to established a shared objective truth). While my delivery of marketing insights might be 'colourful' in nature, the results of our assessments are made on the back of an extremely comprehensive AI-driven analysis of various financial resources. Designed to provides marketing insights, our toolkits provide an understanding of industry movements and trends that visualises the performance of aggregator groups when measured against the industry collective. Our claims (such as the performance of our website tools) are supported by what we believe is the only source of data that analyses cross-aggregation marketing strategies and advertising to a granular scale. The Matrix API - the backbone of our industry understanding - analyses well over 5000 broker websites, crawls every page, extracts, data, creates a duplicate score, assesses SEO compliance, measure linked social accounts (which includes the assessment of post activity and advertising), and the system creates a 'compliance score' based on required website inclusions. Matrix then assigns a marketing heat index and uses various AI tools in order to resolve the performance of each website based on website pathway activity (the AI will browse a website in the same way as a human in order to build what we call a 'Pathway Score'). What's listed is a seriously limited list of functions the system is capable of performing. We released the API to partners a few months back, and based on recent enquires, we'll soon make the data available to the entire industry.
The Matrix API: The Matrix API was first created back in 2018 to assess SEO compliance (returning what is now an irrelevant score from an SEO perspective), and the system was designed to prepare brokers for SSL certificate obligations. The system grew significantly over the years, with 2019 seeing the first system that included a crawler that literally evaluated millions of pages. In 2022 we introduced the first AI tool that'd emulate a human browsing a website, and a few months back we built the algorithm that linked aggregator performance directly to their digital footprint - an extremely revealing score that we'll publish to a module on our website.
Insights (Advertising) API: We use the Insights API (with support from our OCR tools) to identify non-compliance, read advertising creative and flag various types of malfeasance, and it's my rants on industry non-compliance that is often associated with my name. The aggregator I had a discussion with didn't give me a chance to brief them on their 2643 occurrences of marketing-related non-compliance - a staggering figure than only comes in second to a slightly larger group (the infractions were associated with a much smaller group of brokers as the same broker often engaged in the same offensive activity on multiple occasions and in differing formats).
Until a couple of years ago, Matrix was used to measure the performance of our product against others, and we sought to identify the practices that others might be using that returned good results. We've evolved to a point where it's generally unfair to include our own broker website in the search as our solution objectively exceeds the experience provided by others by a significant margin, but we still use the resolved data to shape the digital decisions we make every single day. As an indicating and forecasting tool that evaluates broker/aggregation performance, we'd argue that Matrix has evolved into the most powerful tool of its type in the industry.
Bottom line: the assessments and determinations we make are built on the back of quantifiable, measurable, and scientifically valid data. The results are very revealing, with certain aggregators exposing gaping holes in their digital solutions. The claims aggregators often make to brokers regarding their 'default' or in-house digital performance is rarely supported by the necessary empirical evidence to validate their fluffy claims, and the sales rhetoric they provide brokers is rarely rooted in anything that resembles fact. It's one thing to have data, and another thing entirely to actually ensure the decision-making culture and agile implementation framework makes solutions available to brokers.
The ASIC API
We've archived ASIC data for years. This trove of data allows us to visually and viscerally assess aggregation performance, growth, representative movements, and so on. In fact, there's barely any data we can't resolve on the basis of the archives. The API supports browsing, individual results, comparison data, migration data, forecasts, trends, and so on. Over 40 options apply to the returned data, and it filters paginated results in a manner that may be analysed with standard desktop tools.
The primary purpose of the ASIC API is to feed Matrix with information when indexing digital experiences of any type. The ASIC API is the first of a number of APIs we're releasing in an Open manner, and it's also the simplest in terms of the generic information it returns.
The Website ACL API
One of the simplest (but most useful) API endpoints will resolve the credit representative number and parent ACL based on providing a website address (this is data we require when Matrix indexes websites). While the simplest endpoint, it was likely the most useful when mapping businesses to aggregation groups. On the basis of this information, aggregator marketing scores were then used when comparing representative numbers and broker migration data.
The API action of website return a simple JSON response that unfolds with the found Credit Licences and Rep Details (it ignores details from ABN numbers, 13 numbers etc.). For example asic.json?action=website&website=https://www.mortgagechoice.com.au returns the following:
In this case, it's clear that Mortgage Choice operate under their ACL. In most cases, representative details are returned, and these details are measured against the current source of data in order to resolve the aggregation group. In some cases, a licence can't be found, either because the website doesn't include those details or the nature of the licence was 'non-conforming'.
Justin Doobov's Intelligent Finance website returns the following:
The information is compliant and valid, and we're able to map these integers to the applicable parent licence holder. These results may be used in another request to the licences endpoint (as a comma delimited string of licence data) to return all applicable licencing details.
Note: The remote website data is scraped for the applicable result. The regex we use to extract applicable data is prone to errors, but tends to work over 99.8% of the time (invalid results are ignored if not found in our archive). Those websites that don't return a result are reviewed manually. Results are cached only for a short time on our end since brokers will move from one licence holder to another.
Aggregation Graphing
The ASIC API includes around 40 actions to return data suitable for graphing. In most cases, the returned JSON unwraps into a single key/pair array suitable for inclusion in plug-and-play graphing libraries, but when comparison data is returned it unfolds as an multidimensional array which is indexed on various growth metrics in the nested arrays. The nested comparative data can be quite complex, so we expect to build documentation sometime soon.
A super-simple graph to return the number of licence representatives for each aggregator is shown below. It's the representative data we use (primarily) to assess growth. Some aggregation groups are taking on exponential growth while others are showing indicators that they're reducing in size (interestingly, those that leave 'certain' groups will almost always move to one of three groups).
An interesting graph is one that shows the number of credit reps aligned with an aggregator over time, with some groups showing clear decline (use the API action of aggregator, passing the parameter of licence - if multiple licences are passed in a comma-delimited string, we return data from all supplied groups for side-by-side comparison bar graphs). This data is obviously measured against Credit Licence holders to determine if the person simply obtained their own ACL rather than leave an aggregator (if a broker does move, that migration is mapped into a standalone table).
Ethical Snatching: We haven't held a 'BDM Accelerate' development day this year, and it's possible that we won't focus effort into this space in the future. However, one of the many key takeaways that BDM participants were encourage to consider was the migration of brokers to another aggregator at clearly identifiable points in their early career, and then again when their business was established and profitable. A quick query of the API identifies vulnerable groups, and one important 'opportunity'. Just like the post-settlement and repricing program we put in place for many brokers, we like to see a similar program implemented in aggregator groups, with the 'clawback' in this case being the loss of a broker. If we know which group is most vulnerable, we can apply pressure on that relationship and mitigate broker concerns with early intervention via a type of 'repricing' and solution-based remediation. The opportunity comes from identifying brokers in other groups during a 'vulnerable' phase, and thus improving the likelihood of poaching potential higher-performing candidates. Updated weekly, the API returns these two groups via the migration endpoint. The migration endpoint returns website details, phone numbers, and other information obtained via Matrix.
Industry Statistics
The stats action returns a large amount of statistical data, with counts returned for the previous two years. A large amount of this data may be returned to your website (not that you'd ever need or want to), such as the number of licence holders or credit representatives. For example, the shortcode of [asic type="credit_licences"] returns 0 and [asic type="credit_representatives"] returns 42738. Depending on whether the information comes from the MFAA or FBAA, we often hear that the number of brokers varies between 18000 and 40000, while the reality is that the number of active brokers tends to float above 32000 (the assumption is that anybody registered as a current credit rep is a qualified industry broker). A lot of what we see published by the MFAA tends to consider its own group so the numbers may be flawed, although the sample size tends to support general accuracy.
ASIC Statistics Shortcode: The shortcodes above were created simply for the purpose of this article. The stats endpoint itself is a key/value array with 72 data points. If querying this endpoint, cache the result for around a week, and return the value based on the shortcode shown above (the array key becomes the shortcode type attribute). If the stats value is an array, the results are returned in a list (with the key preceding the value).
Our mortgage broker website framework includes a ton of shortcodes for rendering figures and graphs, but you'll probably never use them. The statistics module is gargantuan in size.
The Matrix, Insights, and Sentiments API
It's the Matrix, Insights, and Sentiments APIs that we work with primarily, and all of these will be introduced over time (it's the Sentiments API that is a GPT-style AI API that is trained primarily on finance information). The Matrix API provides the most valuable finance marketing insights that you'll find anywhere, and it returns the most accurate and scientifically valid results availed to the industry. Guided by AI, the conclusions reached by the API are yet to be questioned by us as part of our operational day-to-day, and the results paint a very clear and indisputable distinction between the marketing presence used by some brokers when compared to others, and it certainly highlights the shortcomings with particular aggregation products, with one aggregator website representing over 70% of all assets in the lowest-performing 100 experiences.
Sentiments: The Sentiments API is an AI trained primarily on finance data. The API was initially designed as an engine to resolve lender policies and terms, although it is capable of far more (including basic tools such as website chatbots). As a service to the industry, this tool and API will be released as part of our Open project.
Once we've created documentation, we expect to release all research data to the industry as part of an Open project.
Lender API: At some point in the near future we'll release the Lender API as part of our Open project. Lender accepts a number of borrowing attributes and others we felt important (such as the DTI) in order to return comparison data. The Lender API also includes an endpoint to return stock pricing, institution history, and so on, with the latter endpoints created for one of our 'Saturn' projects. The API will be released primarily to ensure those that provide a service to the industry are integrating valid data into their funnels (we're hoping that those that provide an advertising or leadgen service of any kind will use the tools since the scope of non-compliance and illegal advertising introduced to broker businesses by way of fake qualification is staggering).
Conclusion
Our tools weren't developed to measure aggregation performance, but it was a by-product of the data we aggregate. Nor were the tools developed to identify lower-performing experiences. Our tools were designed to look at the highest-performing digital in order to identify trends and techniques that were retuning results. We're constantly looking at how to improve our own digital products, and if we find something that needs to be changed, we'll change it.
As mentioned, the ASIC API is actually quite extensive, and it includes over 70 action-based endpoints. However, it's the integration of the API into the Matrix API where we're exposed to more interesting data. Matrix returns actionable marketing-based data that can be directly linked to aggregator performance and churn, and it accurately returns data that is consistent with the quality of consumer-facing digital that represents any single ACL.
There's a bigger-picture discussion that needs to be had on the role of aggregation in a technologically-driven sector. Open Banking proved the viability and adoption of an Open standard that was was agreed upon and implemented by most ADIs. This cooperative solution potentially represented what might be the first step into a new era of aggregation processes.
The data we've described will be published to our website and another standalone domain sometime soon.
, and again in 1929 (sporting the additional two stories). The sandstone building was designed in the Corinthian manner, and it was a symbol of Sydney’s prosperity. It was the trailing end of the gold rush era and The Exchange quickly became the place for business. The first telegraphic message in New South Wales was sent from the Exchange. Then, the it became the first building in New South Wales to include a telephone system. On the 6th December 1882, the the first public demonstration of electric lighting took place in the Exchange dining room, with the room lit up with electric light. The Sydney Wool Exchange, The Fire Underwriters Association, The Coal Association and The Royal Humane Society of New South Wales can all trace their beginnings to The Exchange building at 56 Pitt Street. The Chamber of Commerce, founded in 1824, also took up residence in the Exchange Building. For 100 years, from 1864 to 1964, auction sales of wool were held at The Exchange, growing to be the world’s biggest wool selling centre. A change of ownership in the 60s saw the historic Corinthian sandstone building demolished. [ View Image ]
