CDR representative arrangements: a responsibility checklist for fintechs

A CDR representative arrangement can let a fintech access CDR data through an accredited principal without becoming accredited itself. Before integrating with Fiskil, confirm who provides the data, how your service may use it and which responsibilities your business retains.

Ask Fiskil how your proposed service would work under a representative arrangement before connecting real customer data. Review the Banking API alongside those requirements.

What to request when evaluating a principal

Start with the OAIC's CDR representative guidance. Then ask the proposed provider to identify the legal entities, supported access model, applicable registration, permitted service and written allocation of responsibilities for your case.

Bring a simple data-flow diagram, the intended customer journey, the information your service needs and the systems that will process it. Ask who approves the consent wording, operates customer controls, handles access changes and investigates complaints or incidents. Record the response and responsible role rather than assuming these tasks disappear when an API is purchased.

For Fiskil, discuss that pack with the team alongside the Banking API and production checklist. Keep a sandbox demonstration, a commercial proposal and approval of the live participation arrangement as separate milestones.

Identify the parties before assigning the workflow

The OAIC's representative guidance explains that an unaccredited representative operates under a written arrangement with an unrestricted accredited principal. The principal supplies the relevant CDR data; the representative uses it to provide the agreed service.

Confirm the actual legal entities and required registration. A sandbox credential or an API subscription is not the representative arrangement.

Ask who seeks the customer's consents, who operates each interface and how the responsibilities appear in the product. Keep the answer connected to the written arrangement rather than a generic diagram.

Turn the contract into an implementation checklist

The following is a proposed workshop checklist. The applicable contract and requirements determine the final allocation.

Workstream	Question to resolve
Customer explanation	Which entity and service does the customer understand they are authorising?
Consent journey	Who implements the approved purposes, data selection and customer controls?
Data receipt and use	Which systems receive the data and what processing is permitted?
Access changes	How are expiry, withdrawal and other scope changes communicated?
Retention and disposal	Which process applies to source data and derived information?
Support and complaints	Who responds, investigates and records the outcome?
Suppliers	Which additional services or recipients need review?

Name an owner and evidence for each answer. An undocumented expectation that “the provider handles it” is difficult to test.

Rehearse a permission change

Consider a synthetic case where a sharing change is recorded while the fintech has a pending background job. The integration needs a dependable way to learn the new state before performing work that depends on it.

Fiskil's consent guide and webhook guidance describe lifecycle notifications. Decide how your application will respond to each notification and who will maintain those controls.

Test repeat and delayed notifications, worker retries and an unavailable dependency. A customer-facing dashboard should agree with backend behaviour.

Review new processing before adding it

A spending dashboard, an income analysis and an export to another service can involve different processing and disclosures. Review changes with the responsible parties rather than treating the first approved connection as permission for every later feature.

Document the proposed data flow, purpose, systems and retention approach. Establish which updates or approvals are required for that change in the actual arrangement.

Keep launch evidence together

Combine the agreed arrangement, customer experience, data map and technical tests in one review pack. Use Fiskil's production checklist to identify implementation questions alongside the participation work.

Talk to Fiskil with the service you intend to deliver. The practical objective is an access model whose responsibilities remain clear when the application changes or a customer ends sharing.