Skip to main content

Data Recipient concepts

Wych Data Recipient helps you connect customers to their data providers, manage consent, and retrieve customer-consented data via Wych APIs.

This page explains the core concepts and how they map to the regulatory and standards context in:

  • AU CDR
  • NZ PNZ

Key terms​

Partner​

Your organisation profile within Wych. A Partner owns one or more Applications and controls branding and operational contact details.

AU CDR The Partner typically corresponds to the CDR Accredited Data Recipient (ADR) organisation or the operating entity under an ADR model.
NZ PNZ The Partner corresponds to the organisation acting as a participant in the open banking ecosystem (for example a third party provider integrating to data holders).

Application​

A registered product or use case. Applications define:

  • customer journey type (hosted or embedded)
  • consent copy presented to customers
  • redirect URLs and callback behaviour
  • data access settings and required scopes

AU CDR Applications commonly map to a product capability operating under the ADR’s governance and disclosure obligations.
NZ PNZ Applications map to the integrating product that will initiate consent and retrieve data under PNZ consent and security expectations.

Customer​

The end user who authorises access and authenticates directly with their data provider.

AU CDR The Customer is the CDR consumer who consents to sharing their CDR data.
NZ PNZ The Customer is the end user who authorises access under PNZ consent flows.

Data Provider​

The institution supplying data, such as a bank, credit union, or energy retailer (depending on the standard and use case).

AU CDR A CDR Data Holder (for example a bank, energy retailer) that exposes CDR APIs and authorisation flows.
NZ PNZ A PNZ Data Holder (bank) implementing the PNZ API Centre standard and authorisation flows.

Connection​

A Connection represents a customer’s active (or historical) consent relationship with a specific Data Provider for a given Application.

A Connection typically includes:

  • selected Data Provider
  • consent scopes granted (what data types are permitted)
  • consent duration or expiry
  • status (initiated, pending, active, expired, revoked)
  • audit and troubleshooting metadata

AU CDR A Connection aligns to an active consent arrangement and its associated authorisations and data sharing permissions.
NZ PNZ A Connection aligns to the consent record and the resulting authorisation state for retrieving data under PNZ requirements.

How data flows in Wych​

Wych separates provider-facing standards complexity from your application-facing integration.

  1. Your application authenticates to Wych APIs.
  2. The customer completes the consent journey (hosted by Wych or embedded into your UI).
  3. The customer authenticates with the Data Provider.
  4. The Data Provider authorises data sharing and responds to Wych.
  5. Your application retrieves the resulting data from Wych APIs.

:::info Key point Data provider responses are received by Wych first. Your application retrieves customer-consented data from Wych. :::

Consent defines:

  • what data types can be accessed (for example accounts, balances, transactions)
  • how long access is permitted
  • what disclosures and controls apply (view, manage, revoke)

AU CDR Consent is governed by CDR rules and must be presented with appropriate disclosures and customer controls.
NZ PNZ Consent aligns to PNZ requirements for customer authorisation and data access permissions.

Journey options​

Hosted journey​

Wych hosts a brandable customer journey that supports selecting a data provider, reviewing consent, and completing the provider authorisation.

Use when: you want the fastest path to production and minimal UI and compliance overhead.

Embedded journey​

You build the customer journey in your application and use Wych APIs to manage connection lifecycle.

Use when: you need full UX control and can support additional implementation and assurance requirements.

:::warning Advanced integration Embedded journeys often require additional review and testing before production enablement. :::

Environments​

Wych typically supports at least:

  • non-production for integration testing
  • production for live customer traffic

Environment behaviour and provider availability may differ between ecosystems and providers.

  • Guides: Configure your partner, register your application, authenticate, consent, retrieve data
  • API Spec: Endpoints for data holder selection, connection lifecycle, and data retrieval