Nine CDR questions almost nobody's asking. Why CDR programmes typically over-run.

Your product data release is on track for July. The team's moving well. The natural assumption is that consumer data sharing is the next phase. It's just more of the same, just bigger. Isn't it?

It's not.

Consumer data sharing for non-bank lenders isn't "build some more APIs." It's 100+ CDR Rules, 19 API endpoints, 80+ data schemas, 30+ security standards, binding CX obligations, and 9 mandatory endpoint version upgrades. The Customer Data scope is an order of magnitude larger than Product Reference Data. The questions it raises cut across programme delivery, compliance, and technology architecture in ways most teams haven't mapped.

After working across 10+ CDR programmes at various stages of maturity, we find the same blind spots appearing. Not because teams are careless, but because the hardest questions cross traditional boundaries - and nobody owns the space between them. Considering these has saved our clients time and cost (up to 50%).

Here are nine worth asking before your next steering committee.

Programme Delivery and Operations

1. You're progressing well with your product data release for July. Is consumer data sharing that much harder?

It's 100+ CDR Rules, 19 endpoints, 80+ schemas, 30+ security standards, binding CX obligations, and 9 mandatory version upgrades. Mapping these into your delivery plan is the difference between efficiently delivering over 9 or 15 months and scrambling to catch up.

2. How will you test CDR data flows in production without exposing live customer data?

Testing strategy is often an afterthought. CDR's data-sharing model means your test environment needs to replicate real consent flows, API performance, and security controls — not just functional correctness.

3. How do you comply with CDR data correction and reporting requirements without significantly increasing effort and cost?

CDR regulations require you to notify consumers if you correct their personal or transactional data. This involves operational teams and processes that aren't handled by CDR vendors. Without considering these upfront, cost implications compound.

Compliance

4. If ACCC asked you today how you selected and maintained the completeness, accuracy and timeliness of your CDR products, what would you show them?

Not all products are covered by CDR. Not all product data is required to be disclosed. Embedding these decisions into your product reference data management is critical.

5. Who in your organisation is accountable for CDR data quality — and is that the same person who signs off on your AFSL obligations?

CDR creates a new data quality and privacy obligation that sits awkwardly alongside existing frameworks. If accountability isn't explicitly mapped, it defaults to nobody.

6. How does your current complaints process handle a CDR-specific data dispute?

If a consumer challenges the accuracy of data you've shared, the mandated response timeframe is days — not weeks. The people, process and technology changes required to meet that aren't provided by CDR vendors.

Technology Architecture

7. Can your current technology platforms handle CDR-mandated one-second response times under sustained load?

Under peak conditions — batch requests, concurrent consumers — most platform configurations haven't been stress-tested against CDR benchmarks. These are ACCC-reportable, and fixing performance typically requires re-architecture.

8. Where does CDR data sit in your architecture, and does that create an attack surface your current security model doesn't cover?

CDR introduces new data flows. If your security model was designed around your existing data architecture, you've likely got a gap. New data paths need new security management.

9. If you had to switch CDR middleware providers in 12 months, how much of your implementation is portable?

Vendor lock-in is a real risk in CDR. If your consent management, API gateway, or data-sharing layer is tightly coupled to a single provider, your options narrow quickly — and your costs compound.

The pattern is structural, not personal

These questions aren't theoretical. They're the ones that surface during remediation — after the compliance gap has been identified, after the programme has overrun, after the architecture decision has locked you in.

The reason most CDR programmes miss them is structural. Programme delivery doesn't own compliance interpretation. Compliance doesn't own technology architecture. Technology doesn't own operational process design. The questions that cross those boundaries get deferred, delegated, or simply never asked.

A CDR playbook that only covers one of these pillars leaves the other two exposed. Reducing risk and building certainty requires covering all three — programme delivery, compliance, and technology architecture — in a single, integrated view. Our CDR playbook does not.

If you'd like to walk through how these questions apply to your organisation, I'm happy to have that conversation.

Contact us today and get future-fit.

Find out more about our CDR expertise and consulting services.