Does Your Collections Operation Know What It Needs to Declare?
- closefamily
- Jun 18
- 13 min read
The questions we put to the OAIC on behalf of the collections and hardship industry. And the ones you should be asking yourselves now.
On 15 June 2026, the OAIC closed its consultation on automated decision-making transparency. Guidance lands before 10 December 2026. From that date, organisations using personal information in automated systems to make or substantially contribute to decisions affecting individuals will need to disclose this in their privacy policy.
We submitted. Not because we had all the answers. Because collections and financial hardship felt were largely absent from the conversation, and we had questions the OAIC needed to hear.
We have spent a long time inside collections and hardship operations. We know how these systems are actually built. We know what the policy documents say, and we know what happens on the floor. And when we read the OAIC's issues paper, we kept seeing the same gap: the questions being asked were designed for recruitment algorithms and insurance pricing models. Nobody was asking what any of this means for a collections operation running STP engines, bureau triggers, NPV models, and vulnerability scoring across millions of accounts every day.
So we asked.
This is not a compliance checklist. It is an account of what we put on the record, why we put it there, and the questions that the industry now needs to work through before December arrives. Some of these questions have answers we are confident about. Some of them genuinely do not yet. The OAIC guidance will resolve some of them. Others will require organisations to make judgment calls.
We are not here to tell you if your segmentation model is ADM and therefore in scope. We are here to say the question is more complicated than it looks, and the industry deserves clarity before December 2026.
WHY WE SUBMITTED
Collections needed to be in the room
The OAIC received submissions from insurers, aged care providers, recruiters, and technology companies. All legitimate. All important. But collections and financial hardship, which sits at the intersection of some of the most consequential automated decisions made about individuals in financial stress, felt largely absent.
Think about what collections and hardship systems actually do. They determine whether a customer in arrears is contacted today or next week. They assess whether a hardship application is approved or declined. They decide what treatment options are presented and which ones are not. They calculate whether the expected net value of retaining a debt internally exceeds that of selling it. They route customers to channels, pathways, and solutions based on data the customer cannot see and logic they have no visibility into.
Are all of these ADM? Are they in scope? We think some clearly are. We think others are much less clear. And we think the collections and hardship industry needed someone to put these specific questions on the record, rather than leave practitioners to work it out themselves in November.
Why it matters
The OAIC consultation attracted responses from sectors that have been thinking about algorithmic accountability for years. Collections is a sector that has been running sophisticated automated decisioning for decades. The two conversations had not connected. We tried to connect them.
THE QUESTIONS WE ASKED
Where does the obligation actually start and end?
The obligation applies where a computer program substantially facilitates and is directly connected to a decision that could reasonably be expected to significantly affect an individual's rights or interests. That is the test. It sounds clear. In collections and hardship, it is not.
Here are the specific questions we put to the OAIC.
Question 1
What is the difference between rule-based automation and genuine ADM?
This is the foundational question and the OAIC's answer to it will determine whether the obligation applies to the vast majority of what collections systems do or only to a subset.
Most collections operations run a combination of two things. The first is rule-based automation: a system that executes a predefined action when a defined threshold is crossed. A card block at day 90. A default listing at day 60 after a failed payment arrangement. A demand letter issued when certain conditions are met. The output is identical for every similar customer who reaches that state. There is no inference, no scoring, no individual analysis.
The second is genuine ADM: a system that produces a different output for different customers based on analysis of their specific data. A risk model that scores customer A as high risk and customer B as low risk and routes them to different treatment paths. A propensity model that predicts customer C is likely to self-cure and customer D is not. A channel model that predicts customer E will respond to SMS and customer F will not.
We asked: does the obligation draw a meaningful line between these two types of automation? And if so, where does that line sit? Because if every automated step in a collections workflow is potentially in scope, the disclosure obligation becomes unworkable. But if rule-based automation is entirely excluded, the most consequential decisions in some operations may fall outside the obligation entirely.
The other question is ‘impact’. Yes a RTC (right time to call) is usually a model but does it’s decision significantly impact the customer. What is the threshold or definition?
The practical question for practitioners
Look at your collections workflow. For each automated step, ask: does this produce the same output for every customer in a defined state, or does it assess this individual customer's data and produce a variable output? Does the variation create a significant impact to the customer? The answer to that question is the starting point for your ADM scope assessment.
Question 2
What about segmentation?
This is where we expect practitioners to push back. And they should, because the answer is genuinely not obvious.
Simple segmentation puts customers into groups based on defined criteria. Customers more than 60 days past due go into one bucket. Customers less than 30 days past due go into another. Within each bucket, every customer is treated the same way. Is that ADM?
Our view is that simple rule-based segmentation is probably not ADM in the same sense as a scoring model. But the line gets complicated quickly.
What about a segmentation model that uses multiple variables including risk grade, arrears stage, payment history, product type, and bureau score to assign customers to segments? What if the segment assignment changes the treatment path, the contact frequency, the solutions offered, and the escalation timeline? At what point does segmentation become decisioning? At what point is it in scope? What do we need to disclose?
We asked: where does segmentation end and ADM begin? Is it about the complexity of the inputs? The variability of the output? The consequence of the decision? The degree of human involvement in the segment design? The OAIC guidance needs to address this because it directly determines whether standard collections segmentation practice is in scope.
The practical question for practitioners
If your segmentation model produces different treatment paths for customers with similar profiles, ask whether a customer could reasonably expect to understand why they were placed in that segment. If the answer is no, the segmentation is probably doing more than simple bucketing.
Question 3
Does the exceptions framework change anything?
Most collections operations have a policy framework that says something like: follow the system recommendation unless you invoke an exceptions process. That exceptions process typically involves documentation, supervisor approval, and some form of oversight or audit. It is not called a controlled deviation in every organisation. Sometimes it is an exceptions framework. Sometimes it is an override process. The label varies. The pattern is similar.
The question we put to the OAIC was direct: if policy requires staff to follow the system output and any departure requires invoking a defined exceptions process with documented approvals, has the system made the decision or has a human made the decision?
Our view is that the answer depends on two things. First, how the exceptions process actually works in practice. A genuinely open exceptions process where staff exercise independent judgment and departures are common is different from an exceptions process that exists on paper but is practically never used. Second, the rate at which exceptions are actually invoked.
We asked: if an organisation's exceptions rate from the system recommendation is 5-10%, is that a human decision or a system decision? We think the OAIC should have a clear view on this. A 3% exception rate means the system output is followed 97 times out of 100. In what sense is the human making the decision in that environment?
The practical question for practitioners
Pull your exceptions data. Not just the policy. The data. How often do staff actually depart from the system recommendation? What triggers those departures? Is the exceptions process genuinely open or is it designed to be used only in clearly defined edge cases? The answers to those questions will matter more as much as what your policy document says.
Question 4
What about straight through processing?
STP is common in collections for lower-risk or lower-balance accounts. A hardship application is submitted, assessed, and approved or declined without any human intervention. The system made every decision. There was no exceptions process because there was no human in the loop at any point.
We think STP is unambiguously in scope for the ADM transparency obligation. The system substantially facilitated and was directly connected to a decision that affected the customer's rights. There is no argument about whether the human was genuinely exercising judgment. There was no human.
We asked: does the OAIC agree that STP in collections and hardship is clearly in scope? And if so, what does appropriate disclosure look like when the customer has had a fully automated decision made about their hardship application? What can they contest and how?
THE HARDER QUESTIONS
The decisions customers were never offered
There is a category of ADM in collections that is harder to think about than auto-approvals and auto-declines. It is the decision about what the customer is never shown.
The OAIC legislation expressly includes refusing or failing to make a decision or do a thing as a decision. We think this has significant implications for collections and hardship because some of the most consequential algorithmic outputs in this domain are not what happens to a customer. They are what the customer was never offered, never routed toward, never shown.
Does a portal visibility model count?
Many lenders use models to determine what options appear in a customer's self-service portal. The model might consider arrears stage, payment history, product type, and predicted behaviour to determine whether the customer sees a payment extension, a hardship application option, a settlement offer, or just a full payment button.
A customer who does not see a hardship application option in their portal may not know they are entitled to one. The system decided not to surface it. Is that a decision that significantly affects their rights or interests?
We asked: if a customer's hardship eligibility was effectively assessed by a model that determined they should not be shown the hardship application option, does the organisation have an obligation to disclose that this assessment occurred?
What about propensity-to-pay models?
A common collections model predicts how likely a customer is to pay without intervention. High-propensity customers get a light-touch contact strategy.
Low-propensity customers get a more intensive approach. Settlement offers and fee waivers are typically reserved for accounts where the model predicts the customer will not pay without an incentive.
A customer predicted to pay without incentive may not be offered a settlement or waiver option that would have been available to them if the model had assessed them differently. They pay in full, believing that was their only option.
We asked: is withholding a settlement offer from a customer because the model predicted they would pay without one a decision that needs to be disclosed? Is this meaningfully different from the price discrimination examples the OAIC used in its issues paper?
NPV pathway allocation: the question nobody wants to ask
NPV-based pathway allocation is standard practice in mature collections operations. A model calculates the expected net value of retaining an account internally, placing it with a DCA, selling the debt, or writing it off, and routes the account to the highest-value pathway. Two customers with identical debt balances may end up with entirely different outcomes because the model assessed their expected recovery values differently.
This is not a fringe practice. It is how large collections operations manage portfolio strategy. And it is, on its face, a system that produces variable outputs based on customer data and determines an outcome that significantly affects the customer's financial circumstances.
We asked: Are NPV-based pathway allocations ADM in scope? If it is, what does meaningful disclosure look like? We are not suggesting the model weights or commercial logic need to be disclosed. But the existence of a model that routes customers to different debt resolution pathways based on expected commercial value arguably should be.
The question for practitioners
Review your NPV and pathway allocation models. If two customers with the same debt balance could receive different outcomes because of what the model expects from each of them, ask: does our privacy policy describe this in any meaningful way? The answer in most operations is no.
THE THIRD-PARTY PROBLEM
Where does your disclosure obligation end?
One of the questions we put most directly to the OAIC was about the third-party chain in collections. This is genuinely complex, and the guidance needs to resolve it. At what level of specificity will you need to describe your ADM?
Bureau scores and bureau triggers
Most Australian collections operations use bureau scores from Equifax, Experian, or illion as inputs into treatment decisions. The score is produced by the bureau using the bureau's model and data. The lender then uses it as a significant input into segmentation and treatment selection.
The lender did not build the scoring model. But the lender arranged for the score to be used in decisions about their customers. Does that mean the lender needs to disclose that bureau scores are used in treatment decisions? Does the bureau have any disclosure obligation? Neither party currently discloses this meaningfully to customers.
We asked: how does the obligation apply where a third-party bureau score is a substantial input into collections ADM?
Bureau triggers
This is the scenario that surprised people when we described it in our submission. A lender arranges for a credit bureau to monitor a customer's credit file in real time and fire an automated trigger when a defined event occurs. A new default listing elsewhere.
A significant score movement. A new credit application. That trigger then initiates an automated action in the lender's collections system, perhaps accelerating a timeline or initiating contact.
The customer has no visibility that their credit file is being monitored in real time or that specific events are automatically triggering collections actions against them.
We asked: is this ADM in scope? And if it is, whose obligation is it to disclose it? The lender's, because they arranged for the monitoring? The bureau because they executed it? Both?
Platform execution versus internal scoring
Major collections platforms are execution environments. They run the logic the lender or their implementation partner has configured. The scoring and segmentation intelligence sits in the lender's decisioning layer, not in the platform itself.
This matters because some organisations may assume that using a well-known third-party platform transfers or dilutes their ADM disclosure obligation. We think it does not. The lender arranged for their own ADM to be executed through the platform. The obligation sits with the lender.
We asked: does the OAIC agree that the arranged for obligation sits with the entity that configured the decisioning logic, regardless of which platform executes it?
ON DISCLOSURE DESIGN
How disclosure should work in collections and hardship
We also addressed something the OAIC's issues paper did not focus on directly: how ADM disclosure should actually be designed for customers in financial stress.
Our view on this was clear and possibly counterintuitive.
Do not add ADM disclosure to the real-time customer interaction. Customers experiencing financial stress are operating with severely reduced cognitive and emotional capacity. Collections interactions already carry an extremely high disclosure burden. Adding more does not help. It makes everything worse.
This does not mean disclosure is less important. It means it needs to be designed differently. Disclosure should be accessible when a customer needs it, not injected into a moment when they are least able to absorb it. Linked from decline letters and treatment notifications. Available in plain language. Connected clearly to existing review rights under the NCCP, AFCA, and internal dispute resolution frameworks.
We also want to say something that is easy to lose in a conversation about compliance obligations: ADM and STP are often genuinely good for collections customers. Automation that removes friction, speeds up access to hardship arrangements, and enables self-service resolution at any hour is frequently exactly what customers want. Many customers in financial stress actively prefer automated and digital pathways because they find direct human conversations difficult or distressing.
The goal is not to make customers suspicious of automated systems. It is to ensure that when something goes wrong, they can understand what happened and know where to go.
The four questions we asked the OAIC about disclosure design
Specificity. At what level of specificity must organisations describe the categories of automated decisions and the personal information used in them? Generic language such as 'we use automated systems to manage customer accounts' does not differentiate between workflow automation and model-driven decisioning. What is the minimum standard? Does it differ between the two?
Existing review rights. Customers in hardship already have review rights under the NCCP, AFCA, and IDR frameworks. How should ADM disclosures connect to those existing rights? Should ADM disclosures direct customers to existing review mechanisms or create separate review pathways?
Point of disclosure. Is disclosure in the privacy policy sufficient? Or should ADM disclosures also be accessible at points of impact, for example in decline letters or treatment notifications, without being added to the verbal disclosure stack at point of contact?
Plain language standard. What is the appropriate benchmark? This cohort includes customers with limited financial literacy, limited English, and reduced cognitive capacity due to financial stress. The gap between adequate disclosure for a moderately informed consumer and disclosure that actually reaches a customer in hardship is significant.
THE CHECKLIST
What we put on the record and what practitioners should be asking about their own operations
Below is a working list of the collections and hardship systems and practices we addressed in our submission. For each, the question is not whether it is definitively in scope. The question is whether you know enough about what it does to have that conversation.
For each item, ask: does this system produce variable outputs based on customer-specific data analysis? Does my privacy policy describe it in any meaningful way? If I had to explain to a customer why they received the outcome they received, could I?
WHERE THIS LEAVES THE INDUSTRY
What December 2026 actually requires
We submitted to the OAIC because collections and hardship needed someone in the room asking these questions. We are not claiming to have all the answers. We are claiming the questions matter and the industry deserves guidance that addresses them specifically.
When the OAIC releases its guidance, some of these questions will be resolved. Others will require interpretation. And some will require organisations to make genuine judgment calls about what their systems actually do and how much of it is meaningfully describable in a privacy policy without exposing commercially sensitive model logic.
The organisations that will be in the best position in December are not the ones that wait for the guidance and then do a privacy policy update. They are the ones that have already worked through these questions, mapped what their systems do, and thought carefully about what meaningful disclosure looks like for their customers.
Most collections operations have significant automated decisioning in scope, limited internal documentation of it, and a privacy policy that says essentially nothing specific about it. That is the starting point for almost every organisation we work with. The question is how much ground to cover before December.
Qurioux Solutions submitted to the OAIC consultation on automated decision making transparency in June 2026. Dowload the full submission
Qurioux Solutions works with collections and hardship operations across Australia and New Zealand on regulatory compliance, operational design, and technology architecture.
sacha@qurioux.com | kris@qurioux.com | qurioux.com | ABN 81 682 026 615
Comments