Imagine an ASIC review arrives. Or a borrower lodges a complaint with AFCA. The regulator wants to see how the credit assessment was conducted, what information was gathered, what was verified, and why the loan was approved.
If the answer depends on what an assessor remembers, or what they happened to write in a file note, or what the system might still have if records were not archived, the lender has a problem. Not necessarily because the lending decision was wrong, but because they cannot demonstrate that it was right.
This is the compliance gap that well-designed lending software is supposed to close. Responsible lending obligations under Australian law are not just about what a lender does. They are about what a lender can prove they did, years later, with a complete and auditable record.
What the Law Actually Requires
Australia’s responsible lending framework sits primarily in Chapter 3 of the National Consumer Credit Protection Act 2009. ASIC’s Regulatory Guide 209 sets out what the obligations mean in practice and what steps lenders and credit assistance providers should take to meet them.
The core requirement is straightforward in principle. A lender must not enter into a credit contract that is unsuitable for the consumer. A broker must not suggest or assist a consumer to apply for credit that is unsuitable. To meet this requirement, both lenders and brokers must follow a defined assessment process before credit is provided.
The Four Elements of a Compliant Assessment
RG 209 describes four elements that together make up a compliant responsible lending process:
Making reasonable inquiries about the consumer’s requirements and objectives:
This means understanding why the consumer wants the credit, what they intend to do with it, and what features are important to them. General descriptions like “personal expenses” are not sufficient. The inquiry needs to produce enough information to assess whether a particular product actually suits what the consumer is trying to achieve.
Making reasonable inquiries about the consumer’s financial situation:
This covers income sources and amounts, living expenses, existing debts and repayment history, assets, and any special circumstances like variable employment or impending retirement. The depth of inquiry should be proportionate to the loan size, product type, and the consumer’s apparent risk profile.
Taking reasonable steps to verify the financial information provided:
Verification means checking that the information the consumer has given is accurate. This typically involves payslips, bank statements, tax returns, and other supporting documents. What counts as reasonable verification depends on the context, and ASIC’s guidance explicitly acknowledges that digital data capture tools and open banking connections are now appropriate verification mechanisms.
Assessing suitability and not proceeding if the contract is unsuitable:
Once inquiries and verification are complete, the lender must assess whether the proposed credit contract is suitable for the consumer. If it is not, the lender must decline or recommend an alternative.
Each of these four elements must be documented. The documentation is not just internal housekeeping. It is the legal record that demonstrates the obligation was met.
Suitability Assessment – What Software Needs to Support
A suitability assessment is more than a pass or fail decision. It is an analytical process that looks at whether the borrower can meet the repayment obligations of the proposed contract without substantial hardship, and whether the contract meets their stated requirements and objectives.
In practice, a software-supported suitability assessment involves several components working together.
The system needs to model repayments against realistic expense assumptions rather than theoretical minimums. It needs to apply stress scenarios, asking what happens to the borrower’s capacity to repay if interest rates rise by a percentage point or if their income falls by a meaningful amount. It needs to flag situations where the product features themselves may make it unsuitable, such as balloon payments, high establishment fees, or revolving credit structures with terms that may not suit the borrower’s objectives.
For asset finance specifically, the assessment also needs to consider the nature of the asset being financed, the loan-to-value ratio, and whether the loan term and structure are appropriate for the asset’s expected useful life.
How Automated Decisioning Must Still Meet the Standard
Automated credit decisioning has introduced a specific compliance challenge that ASIC has addressed directly.
In 2016, ASIC investigated lender Nimble Australia after finding that their automated online assessment software did not properly account for consumers’ financial information. In some cases, relevant data from bank statements was not factored into the final assessment. ASIC’s enforcement action resulted in Nimble refunding over $1.5 million to affected borrowers.
ASIC’s position from this and subsequent guidance is clear: using automated software to conduct credit assessments does not reduce a lender’s responsible lending obligations. The software must properly capture, process, and account for the consumer’s financial information. If the algorithm does not do this, the lender is not compliant regardless of how fast the decision was made.
ASIC’s expectations for automated decisioning systems include documented system design that clearly sets out the purpose and logic of the algorithms, a test strategy with documented test cases and results, processes for managing algorithm changes, and the ability to reconstruct any version of the algorithm over a seven-year period.
This last requirement is particularly significant. It means a lender must be able to show, years after a loan was assessed, exactly what rules and logic the system was applying at the time of that assessment.
Evidence Storage and the 7-Year Requirement
The NCCP Act requires lenders to keep records of their responsible lending assessments for a minimum of seven years. This is not a soft expectation. It is a statutory obligation, and the records must be complete enough to allow the lender to provide a written copy of the assessment to the consumer on request.
The records that need to be retained include:
- Inquiry notes capturing the questions asked and the answers received
- Copies of verification documents submitted by the borrower
- The affordability calculations and the assumptions used in those calculations
- The decision rationale explains why the credit was assessed as suitable or unsuitable
- All communications with the borrower or broker relating to the assessment
- The credit contract and any subsequent variations
Seven years is a long time in technology terms. Software systems change. Data gets migrated. Lenders are acquired, merged, or restructured. The obligation to retain and be able to produce these records survives all of that. Compliance evidence storage is therefore not just about capturing records in real time. It is about ensuring those records remain accessible, intact, and searchable over the full retention period.
What Counts as Compliance Evidence
The format and accessibility of records matters as much as whether they exist. ASIC expects records to be stored in a secure, searchable system with auditable access logs and proper backup arrangements. Digital copies stored in a system that can be searched and retrieved on request satisfy the requirement far more effectively than physical files or unstructured document folders.
The key test is whether the lender can, at any point within the seven-year period, produce a complete picture of how a specific credit assessment was conducted. That means every piece of evidence, every calculation, every document, and every communication associated with that assessment needs to be linked together and retrievable as a coherent record.
Audit Logs: The Technical Backbone of Compliance
An audit log is a chronological record of every action taken in a system, by whom, at what time, and on what data. In the context of responsible lending, an audit log is what turns a collection of records into a demonstrably compliant process.
Without an audit log, a lender can show that a loan file contains certain documents. They cannot necessarily show when those documents were received, who reviewed them, what the reviewer did with them, or whether the assessment was conducted before or after any of those documents arrived.
With a proper audit log, the entire sequence of events is recorded automatically. The borrower submitted documents at a particular time. An assessor opened the file at a particular time. The affordability calculation was run with specific inputs at a specific time. A condition was placed on the approval, the condition was cleared, and the settlement was authorised, all with timestamps and assessor identity attached.
Linking Decisions to Assessors and Timestamps
The Emu Money responsible lending guidance specifically calls out the need for audit trail records to link each decision to the responsible assessor’s identity and time-stamped actions. This matters because it allows a lender to demonstrate not just that a process was followed, but who followed it, when, and in what order.
This level of specificity becomes important in enforcement scenarios. When ASIC reviews a lender’s practices following a complaint, the question is often not just whether the right process existed but whether the right process was actually applied to the specific application in question. An audit log that records each assessor action and timestamp answers that question definitively.
Audit logs should also capture changes to application data, recording what the original submitted figures were, whether any data was amended, who amended it, and when. In cases where borrower-provided information turns out to be inaccurate or fraudulent, the audit log demonstrates that the lender’s process was not the source of the inaccuracy.
Algorithm and System Change Management
For lenders using automated decisioning, audit logs serve an additional function. They need to capture not just what decisions were made, but what version of the decisioning logic was in use when each decision was made.
ASIC’s guidance on automated systems requires lenders to be able to reconstruct any changes to their algorithms over a seven-year timeframe. This means the audit log must include records of when algorithm or rule changes were made, what the change was, who authorised it, and when it took effect. Every loan assessed after a rule change needs to be traceable to the version of the rules that was active at the time of assessment.
For lenders who update their credit policy rules regularly, whether in response to market changes, regulatory updates, or portfolio performance insights, this creates a meaningful technical requirement. The system needs to version-control the rules and attach the correct version to each assessment record.
What Software Must Do at Each Stage of the Lending Process
Mapping responsible lending obligations to software requirements stage by stage makes it easier to assess whether a system actually supports compliance.
Pre-Application and Inquiry Stage
At this stage, the software needs to support structured inquiry capture rather than free-text fields that produce inconsistent, unsearchable records. The system should prompt assessors or digital application forms to gather specific information about the borrower’s requirements and objectives, income, expenses, existing debts, and circumstances. It should be configurable to ask additional questions when certain triggers are present, for example when the borrower indicates variable income or when the loan amount exceeds a certain threshold.
Application and Verification Stage
When the borrower submits supporting documents, the system needs to log the receipt of each document with a timestamp and link it to the application. As discussed in the context of income verification, automated bank statement analysis and OCR-powered document parsing are appropriate and efficient mechanisms for verification. The system should also record when and how each verification step was completed.
If a verification step is not completed, for example if a document was not available and an alternative check was used instead, the system should record that too along with the reason. ASIC’s guidance explicitly addresses situations where verification is limited: the lender needs to document why limited verification was reasonable in the specific circumstances.
Assessment and Decision Stage
This is the stage where suitability is determined and the decision record is created. The system needs to capture the inputs to the affordability calculation, the assumptions used, the stress-test scenarios applied, and the output. It needs to record the assessor’s identity and the time of the decision. And it needs to attach the decision rationale — the reasoning that connects the gathered information to the assessment outcome.
For automated decisions, the system needs to log which version of the decisioning rules was applied and what the rule outputs were for the specific application.
Post-Decision and Conditions Management
When conditions are placed on an approval, the system needs to track each condition, record when it was satisfied, and link that clearance to the document or action that satisfied it. Settlement should be prevented until all conditions are cleared, and the clearing of each condition should be timestamped and attributed to the assessor who verified it.
For variations to existing credit contracts such as limit increases, refinancing, and hardship arrangements, the system needs to trigger a fresh suitability assessment rather than treating the variation as a simple administrative change. Responsible lending obligations apply to significant contract variations in the same way they apply to new credit.
The Ongoing Obligations Most Software Misses
Responsible lending does not end when a loan settles. This is an area where many systems fall short because they are designed primarily for origination rather than the full contract lifecycle.
The NCCP Act and RG 209 are clear that significant variations to a credit contract require reassessment of suitability. A borrower who requests a credit limit increase on an existing facility needs to go through a suitability assessment for the increased limit. A borrower who enters a hardship arrangement needs their changed financial circumstances to be assessed and documented. A refinancing that consolidates existing debts needs to be assessed not just for serviceability but for whether the consolidated structure improves or worsens the borrower’s financial position.
Software that handles origination well but does not support these ongoing obligations leaves a lender with a compliance gap in their contract management process. The evidence requirements for post-origination assessments are the same as for initial assessments: inquiries, verification, suitability determination, and a documented decision record that must be retained for seven years.
What to Look for in Lending Software Built for Compliance
Not all lending platforms treat compliance evidence as a core design requirement. For Australian lenders operating under the NCCP Act, here is what genuinely matters:
| Capability | Why It Matters for Compliance |
| Structured inquiry capture | Produces consistent, searchable records of what was asked and what was answered |
| Automated verification logging | Records when documents were received, what was verified, and how |
| Affordability modelling with stored inputs | Captures the calculation assumptions as well as the output |
| Audit log with assessor identity and timestamps | Links every action to the person who took it and when |
| Algorithm version control | Allows reconstruction of the decisioning rules applied to any historical assessment |
| 7-year record retention with searchable access | Satisfies the statutory retention requirement and supports on-demand evidence production |
| Conditions tracking linked to settlement | Ensures conditions are documented, cleared, and recorded before disbursement |
| Post-origination reassessment triggers | Supports compliance for variations, limit increases, and hardship arrangements |
| Role-based access controls | Limits who can view or amend sensitive assessment records |
For Australian asset finance lenders looking for a platform built with these requirements in mind, the Lender Platform by Credit Objects covers the full lending lifecycle from initial inquiry through settlement and contract management.
Its lending management software supports structured inquiry workflows, automated credit policy verification, supporting document management with timestamped logging, AI-assisted assessment with anomaly detection, conditions management linked to settlement eligibility, and comprehensive audit trail generation across every stage of the process.
Frequently Asked Questions
What are responsible lending obligations in Australia?
Responsible lending obligations are requirements under the National Consumer Credit Protection Act 2009 that apply to credit licenses and credit assistance providers. They require lenders and brokers to make reasonable inquiries about a consumer’s financial situation and objectives, take reasonable steps to verify that information, assess whether a proposed credit contract is suitable for the consumer, and not proceed if the contract is unsuitable. ASIC’s Regulatory Guide 209 sets out what these obligations mean in practice.
What is a suitability assessment?
A suitability assessment is the analysis a lender must complete to determine whether a proposed credit contract is appropriate for a specific consumer. It involves modelling whether the consumer can meet the repayment obligations without substantial hardship, testing what happens under adverse scenarios, and considering whether the contract’s features match the consumer’s stated requirements and objectives. The assessment must be documented and retained for seven years.
How long must compliance records be kept under Australian law?
The NCCP Act requires lenders to retain records of responsible lending assessments for a minimum of seven years from the date of the loan. This includes inquiry notes, verification documents, affordability calculations, the decision rationale, all communications, and a copy of the credit contract. The records must be complete enough to allow the lender to provide a written copy of the assessment to the consumer on request within the retention period.
What should an audit log capture in a lending system?
A compliant audit log should capture the identity of every person who accessed or took action on an application, the timestamp of each action, what data was reviewed or changed, which version of any automated decisioning rules was applied, when verification documents were received, when conditions were placed and cleared, and who authorised each decision. For automated systems, the audit log also needs to record algorithm changes with sufficient detail to allow the system’s logic to be reconstructed at any point over the seven-year retention period.
Does automated decisioning satisfy responsible lending requirements?
Automated decisioning can satisfy responsible lending requirements, but only if the system properly accounts for all relevant financial information in its assessment. ASIC’s enforcement action against Nimble established that using automated software does not reduce a lender’s obligations. The software must capture and apply the relevant financial data correctly, and the lender must be able to demonstrate this through documented system design, test records, and an audit log that allows the assessment logic to be reconstructed years later.
What happens if a lender’s software does not support compliance evidence?
The consequences range from regulatory action to civil penalties under the NCCP Act. ASIC can issue enforceable undertakings, directions requiring remediation, or pursue civil penalty proceedings. AFCA can award compensation and vary contracts in favour of consumers where unsuitable lending is established. Where records are insufficient to demonstrate that the responsible lending process was followed, the lender is in a weaker position to defend against both regulatory and consumer complaints, regardless of whether the underlying assessment was sound.
