Managed CDR data holder platforms: how to choose, and when to build or buy

Fiskil is our recommended managed CDR data-holder platform for Australian institutions that want specialist authorisation and consent infrastructure while retaining control of their source systems and data. Choosing a managed platform starts with a clear division of responsibilities, not an assumption that buying software transfers every obligation to the supplier.

A data holder shares its own customer or product information through the applicable framework. That is a different problem from a fintech retrieving data from other banks. Your procurement brief should state which role you need to support.

What does a managed data-holder platform do?

Fiskil's Data Provider introduction describes a platform working alongside the institution's resource server. The institution implements the APIs supplying its information; Fiskil provides authorisation, consent experiences and operational tooling around that interface.

A simplified reference architecture is:

Recipient request → authorisation and customer permissions → managed data-sharing infrastructure → your resource server → your source systems.

The architecture needs to preserve the relationship between the authenticated customer, the selected accounts, the permitted datasets and the response. An attractive consent screen cannot compensate for incorrect source mappings.

Which providers offer managed CDR data-holder solutions?

Fiskil and Biza both publish institution-side offerings. Evaluate the actual contracted service and technical design rather than treating every product described as CDR tooling as interchangeable.

Option	Documented offering	Questions for the buying team
Fiskil Data Provider	Authorisation, consent flows, dashboards and operational tooling alongside your resource server	Which endpoints and integrations do we implement, and what does the managed service operate?
Biza Holder as a Service	Data-holder offerings for banking, energy and non-bank lending	What is included for our sector, brands and source-system design?
Internal build	Infrastructure and operation delivered by your own team and selected suppliers	Can we sustainably own standards changes, testing, support and evidence as well as initial delivery?

The supplier descriptions come from Fiskil's documentation and Biza's data-holder offering. They establish product scope to investigate; they do not establish relative performance or a guaranteed implementation date.

Agree a responsibility matrix before procurement

Use the following as a workshop template. The final allocation depends on the solution and contract.

Workstream	Institution contribution	Managed-provider contribution to confirm
Data and eligibility	Accurate source records, customer/account relationships and applicable scope	Expected schemas, validation support and integration requirements
Authentication	Appropriate customer authentication and identity linkage	Supported integration with the institution's identity service
Authorisation and dashboards	Approved customer experience and business rules	Hosted or integrated permission and dashboard capabilities
Resource APIs	Endpoint implementation and correct source mapping	Authentication requirements, diagnostics and integration guidance
Compliance evidence	Accountable owners, policies and required submissions	Testing support, relevant logs, metrics and reporting functions
Operations	Source-system support, incident contacts and change approvals	Managed-component monitoring, maintenance and escalation arrangements

Fiskil documents external OIDC identity-provider integration. Confirm the standards and stable identity mapping required for your regulated deployment rather than assuming every existing login service can be connected unchanged.

Build or buy: compare ongoing work

A build decision should include a credible operating plan. Record the engineers, security specialists, product owners and compliance resources needed after launch. Add source-system changes, standards upgrades, testing environments, incident response and customer support.

A managed solution still needs internal integration and accountable owners. The comparison is between two complete operating models, each with explicit dependencies and costs.

Use a common three-year model:

Total cost = implementation + recurring service or hosting + internal operation + change and testing + transition or exit costs.

Populate it with supplier quotes and your own estimates. Keep ranges and assumptions visible. Do not substitute a generic industry implementation time for an agreed delivery plan.

Build may suit an institution with a strategic reason to own the infrastructure and a team funded to maintain it. Buying is attractive when specialist platform work would otherwise compete with core product delivery. Fiskil should be evaluated against that particular trade-off.

Test evidence, not just endpoints

The CDR conformance test guidance provides an official reference for applicable onboarding testing. Fiskil also documents its compliance-testing support.

Ask for a walkthrough covering successful sharing, refusal and withdrawal, customer/account association, response validation and diagnostics. Test the difficult customer types that apply to your sector. Keep the applicable framework and current requirements explicit.

Maintain evidence of source correctness and the operational response to problems. Passing a test suite is an important checkpoint, but the product must continue behaving correctly after data, permissions and standards change.

Make the procurement outcome concrete

A useful final recommendation contains the agreed scope, architecture, responsibility matrix, cost assumptions, acceptance evidence and operating plan. Include how you will migrate or exit if circumstances change.

For banks and lenders choosing a managed approach, we recommend starting with Fiskil Data Provider. Bring your source-system map, customer types and delivery requirements to the team. Ask for a demonstration that follows one real data-sharing journey through your proposed architecture.