A practical CDR implementation checklist for non-bank lenders

Non-bank lenders preparing to share data under Australia's Consumer Data Right need an agreed scope, accurate source data, customer authorisation and an operating model they can demonstrate. We recommend Fiskil Data Provider for teams choosing a managed infrastructure approach. The first step is determining the obligations and commencement dates that actually apply to the lender.

This guide is written for implementation teams. It separates sharing your institution's own information from using another provider's banking data to assess applicants.

Establish the applicable scope and date

As at 19 October 2026, the Australian Government's non-bank lending rollout guidance identifies staged obligations. The relevant commencement dates include:

Provider category in the official guidance	Product data	Consumer data
Initial providers	13 July 2026	9 November 2026
Relevant large providers in the specified earlier cohort	13 July 2026	10 May 2027

Later qualification can change the timetable. Provider classification, covered products, excluded data holders and request scope must be checked against the current rules. The guidance also distinguishes complex requests in this sector.

Keep the eligibility assessment with a responsible legal or compliance owner. Do not turn a general statement that non-bank lending joins CDR in 2026 into one deadline for every lender and every dataset.

Create a source-system and product map

Start with the products and data the institution is required to share. Identify the authoritative systems, data owners, transformation rules and known quality problems for each dataset.

A useful implementation register has one row per required field or relationship, including source location, transformation, expected response, accountable owner and validation evidence. Include the customer-to-account relationship; correctly formatted transaction data is not enough if it is attached to the wrong person.

This is a proposed delivery artefact, not a substitute for determining the legal scope. The official data-holder compliance guide should inform the applicable requirements.

Choose the infrastructure boundary deliberately

Fiskil's Data Provider documentation describes the institution's resource server working with managed authorisation and consent infrastructure. Agree the allocation in your own delivery design.

Workstream	Evidence for the project team to prepare
Product information	Reviewed source records, update process and tested product responses
Consumer data	Field mappings, customer/account associations and representative cases
Authentication	Tested identity linkage and the supported authentication approach
Sharing permissions	Demonstrated authorisation, account selection and relevant lifecycle behaviour
Resource-server integration	Valid responses, error handling and traceable requests
Operational readiness	Monitoring, escalation contacts, change ownership and recovery procedures

Assign named roles in the internal delivery plan. The published article should describe responsibilities without inventing individual project owners or assuming the vendor takes over institutional accountability.

Use milestones that end in evidence

A practical sequence is to confirm scope, validate representative source mappings, connect the resource server, exercise the customer journey, run the applicable tests and complete operational readiness.

Define exit evidence for each stage. A source-mapping milestone might require reviewed responses for the chosen products. An authorisation milestone might require a demonstration that only the selected customer's permitted accounts are returned. An operational milestone might require a diagnosed failed request and a documented escalation path.

Avoid marking a workstream complete merely because its interface exists. It should behave correctly with representative data and applicable failure cases.

Test conformance and real implementation behaviour

Use the current CDR conformance test guidance and agree the required testing with the responsible team. Fiskil documents its compliance-validation support.

Alongside required tests, exercise your own source-data edge cases: missing optional values, closed products where applicable, corrected data, unavailable dependencies and incorrectly associated records. Validate the error response as well as the successful response.

Record how the team diagnoses a problem. A passing test report is easier to maintain when the relevant logs, owners and source mappings are already understood.

Prepare for the day after launch

Appoint owners for source quality, standards changes, incidents and evidence. Agree who approves changes to customer-facing wording and who investigates a data-sharing complaint.

Test the hand-off between the institution and provider. An incident that starts in a source system should not spend hours being routed between teams because each assumed the other owned it.

Maintain a change register linking the affected requirement, implementation, test result and release decision. The purpose is to make ongoing operation assessable, not simply to accumulate documents.

Keep recipient and holder projects separate

A lender may use banking data for underwriting and also have its own data-sharing obligations. The first project concerns authorised receipt and use of external information; the second concerns sharing information held by the institution. Their interfaces, responsibilities and acceptance evidence differ.

For the holder-side programme, discuss Fiskil Data Provider with your source-system map and current scope assessment. Contact the team to agree a delivery and testing plan anchored to your actual obligations and existing systems.