Skip to main content
This document provides an overview of what you need to do to integrate with Fiskil’s Data Provider platform and build a compliant Consumer Data Right (CDR) integration.

What You’re Building

When you integrate with Fiskil as a CDR Data Holder, you’re building a Resource Server — your API that exposes customer data according to CDR standards.

Responsibility Split

Fiskil handles:
  • Authorization server and consent management
  • Token issuance and validation
  • Compliance reporting and monitoring
  • Data recipient onboarding
  • CDR-compliant consent flow UI
You build:
  • Resource Server with data endpoints
  • Authentication between Fiskil and your systems
  • Performant APIs with reliable data quality

Prerequisites

Before beginning your integration, ensure you have:
You need access to Fiskil’s platform with both Staging and Production instances provisioned. Each instance is isolated with separate keys, logs, and configuration.Contact Fiskil to provision your environments if you haven’t already.
As a CDR Data Holder, you have specific regulatory obligations beyond the technical integration. Review the CDR FAQs to understand:
  • Your responsibilities as a Data Holder
  • Consumer rights and consent management
  • Dispute resolution requirements
  • Reporting obligations
  • Privacy safeguards
Your Resource Server will need:
  • HTTPS endpoints accessible by Fiskil
  • Infrastructure capable of meeting CDR performance and availability requirements
  • Monitoring and alerting systems
  • Stable customer and account identifier systems

Functional Requirements

Resource Server Overview

Your Resource Server is an HTTPS API that Fiskil calls after a customer authorizes data sharing. It must:
  • Accept and validate Bearer tokens issued by Fiskil
  • Return data in CDR-compliant JSON format
  • Implement proper error handling with standard HTTP status codes
  • Support pagination for list endpoints
These endpoints are called during the user consent flow to identify customers and display their accounts.
These endpoints are critical for the consent flow. They must return stable customer and account identifiers that never change.

CDR Data Endpoints

After consent is granted, Fiskil calls your Resource Server to retrieve customer data. The specific endpoints you need to implement depend on your industry.
Required endpoints:
CategoryEndpoints
AccountsGet Accounts, Get Account Detail
BalancesGet Balances, Get Bulk Balances, Get Balances For Specific Accounts
TransactionsGet Transactions For Account, Get Transaction Detail
PayeesGet Payees, Get Payee Detail
Direct DebitsGet Direct Debits For Account, Get Bulk Direct Debits, Get Direct Debits For Specific Accounts
Scheduled PaymentsGet Scheduled Payments For Account, Get Scheduled Payments Bulk, Get Scheduled Payments For Specific Accounts
See the complete CDR Banking API Reference for detailed specifications.

API Standards & Patterns

Authentication Your Resource Server must validate Bearer tokens issued by Fiskil. See Authentication for complete details on token validation and JWKS configuration.
Authorization: Bearer eyJhbGciOiJQUzI1NiIsInR5cCI6IkpXVCJ9...
Error Handling Return standard HTTP status codes and structured error responses. See Error Handling for complete specifications. Pagination Support pagination for list endpoints using page and page-size query parameters. Return LinksPaginated in responses.

Non-Functional Requirements

These technical requirements are mandatory for CDR compliance and critical for integration success.
These requirements are mandated by CDR standards and monitored by regulators. Fiskil provides tooling to help you meet them, but your Resource Server must be designed with these constraints in mind.

Identity Stability

Critical Requirement: Customer IDs and Account IDs must be permanent and stable. Changing these identifiers will break consents and violate CDR compliance.
Customer IDs:
  • Must remain stable across all sessions and interactions
  • Must be unique within your organization
  • Must never be reused for different customers
  • Must not encode temporary or session-specific information
Account IDs:
  • Must remain stable over the lifetime of the account
  • Must be unique within your organization
  • Must persist even if the account is closed or reopened
  • Must not change when account details are updated
Impact of unstable IDs:
  • Active consents will break, requiring customers to re-authorize
  • Data recipients will receive inconsistent data
  • CDR compliance violations and potential regulatory action
  • Poor customer experience and support burden
Use your system’s internal primary keys or generate stable UUIDs. Avoid using account numbers or other customer-facing identifiers that might change.

Performance Requirements

CDR mandates specific response time requirements measured at the 95th percentile — meaning 95% of requests must respond within the specified time.
Key Response Time Thresholds:
PriorityResponse TimeExample Endpoints
High Priority1000msGet Accounts, Get Energy Accounts, Get Customer
Low Priority1500msGet Account Detail, Get Balances, Get Transactions
Unattended4000msUnattended calls to standard endpoints
Large Payload6000msBulk Direct Debits, Bulk Billing
These are mandatory CDR compliance requirements. Consistent failure to meet these thresholds will impact your regulatory standing.
For the complete breakdown of performance requirements by endpoint, see Non-Functional Requirements.

Availability Requirements

Required Availability: 99.5% per month (maximum 3.6 hours downtime)
Your Resource Server infrastructure must be designed for high availability:
  • Implement redundancy and failover mechanisms
  • Plan maintenance windows carefully to stay within limits
  • Monitor uptime continuously
  • Establish incident response procedures
Fiskil provides availability monitoring and alerting. Configure these tools during your initial setup to track your compliance with this requirement.

Data Quality Standards

You must take reasonable steps to ensure CDR data is accurate, up-to-date, and complete (CDR Privacy Safeguard 11).
Requirements:
  • Product data must be current and reflect your actual offerings
  • Customer data must be synchronized with your source systems
  • Historical data must be accurate and complete
  • Data quality processes must be documented and auditable for regulatory review
For more information on data quality obligations, see the OAIC’s CDR Privacy Safeguard Guidelines.

Implementation Checklist

Use this checklist to track your integration progress:
1

Set up Resource Server infrastructure

Provision HTTPS endpoints accessible by Fiskil with appropriate scaling and redundancy for availability requirements.
Start with your staging environment and validate before moving to production.
2

Implement consent flow endpoints

Build the three required endpoints for the consent flow:
  • Customer Search (email/phone lookup)
  • Customer Accounts (list accounts for selection)
  • Customer Details (identity information)
Ensure these endpoints return stable customer and account identifiers.
3

Implement CDR data endpoints

Build the required endpoints for your industry:
  • Banking: accounts, balances, transactions, payees, direct debits, scheduled payments
  • Energy: accounts, plans, billing, usage, service points, DER
Start with core endpoints (accounts, balances) before adding others.
4

Verify identifier stability

Confirm that customer IDs and account IDs are permanent and stable:
  • Review your ID generation strategy
  • Test that IDs persist across sessions and system updates
  • Document your identifier scheme
This is critical — unstable IDs will break active consents and cause compliance issues.
5

Implement error handling

Return proper HTTP status codes (403, 404, 422, 500) with structured error responses.Include X-Sharing-Refused header where required for CDR reporting.See Error Handling for specifications.
6

Optimize for performance

Test and optimize to meet CDR performance requirements:
  • Measure response times at 95th percentile
  • Optimize database queries and caching
  • Implement appropriate timeouts
  • Load test at expected traffic levels
Monitor high-priority endpoints (1000ms) and low-priority endpoints (1500ms) separately.
7

Set up monitoring and alerting

Configure monitoring and alerting to track the 99.5% availability requirement:
  • Uptime monitoring
  • Response time metrics
  • Error rate tracking
  • Incident alerting
Use Fiskil’s telemetry tools to track these metrics. See Logs and Metrics.
8

End-to-end testing

Test the complete consent and data sharing flow:
  • Use Fiskil’s testing tools to simulate real scenarios
  • Test all endpoints with various data scenarios
  • Validate error handling
  • Verify performance under load
See Testing & Compliance Tools for testing resources.
9

Complete compliance validation

Before going live, confirm:
  • All required endpoints are implemented and tested
  • Performance thresholds are consistently met
  • Availability monitoring is active and alerting
  • Error handling returns correct status codes and formats
  • Customer and account IDs are stable
Work with Fiskil to complete any required regulatory certification or audit processes.

Resources & Next Steps

Additional Resources


Need Help?

Fiskil provides comprehensive support throughout your integration. Contact your account team or reach out through the Fiskil Console for technical assistance.