This page explains the core concepts used by Wych Data Holder.

Wych Data Holder helps organisations expose customer-permissioned data and, where enabled, payment initiation capabilities through secure, standards-aligned open data APIs.

Data Holder​

A Data Holder is an organisation that holds customer data and is responsible for making that data available to authorised third parties when a valid customer consent is in place.

Examples include:

• banks
• lenders
• energy retailers
• financial service providers
• other organisations participating in open data ecosystems

In the Wych platform, the Data Holder is the organisation that owns the customer relationship, authenticates the customer, and provides access to approved datasets through Wych Data Holder APIs.

Data Recipient​

A Data Recipient is an organisation that requests access to customer-permissioned data.

Depending on the region and standard, this may include:

• accredited data recipients
• authorised third parties
• registered third-party providers
• representatives or agents acting under an approved arrangement

Wych Data Holder validates that the requesting party is allowed to access the requested data before any Data Holder data is returned.

Customer​

A customer is the individual, business, or nominated representative who authorises access to their data.

In a typical open banking or open data flow, the customer:

1. starts a connection or sharing journey with a Data Recipient
2. is redirected to the Data Holder for authentication
3. reviews the requested data access
4. authorises or declines consent
5. may later amend or revoke consent

Brand​

A brand represents the customer-facing identity under which data sharing is made available.

A single Data Holder may operate one or more brands.

For example, a Data Holder group may have:

• a main banking brand
• a lending brand
• a white-label brand
• a subsidiary or acquired brand

Brands are used to control customer-facing presentation, endpoint configuration, operational contacts, and supported data sharing capabilities.

Product​

A product represents an account, facility, service, or offering made available by the Data Holder.

Products may include:

• transaction accounts
• savings accounts
• credit cards
• home loans
• personal loans
• asset finance products
• energy plans
• other supported product types

In open data ecosystems, Data Holders may need to expose both:

• Product reference data, which describes publicly available products
• Customer product data, which describes the customer’s specific accounts or services

Data cluster​

A data cluster is a logical group of data that may be requested under consent.

Examples include:

• customer profile data
• account data
• balance data
• transaction data
• direct debit data
• scheduled payment data
• product data
• energy usage data
• payment initiation data, where enabled

Data clusters help define what a customer is being asked to share and what a Data Recipient is allowed to access.

Consent​

Consent is the customer’s permission for a Data Recipient to access specific data for a specific purpose.

Consent typically includes:

• the Data Recipient requesting access
• the customer or account holder authorising access
• the requested data clusters
• the purpose of access
• the duration of access
• sharing frequency, such as once-off or ongoing access
• any account, product, or service selections

Wych Data Holder uses consent information to determine whether a data request should be allowed.

Authorisation​

Authorisation is the process of confirming that a customer has approved the requested access.

In a Data Holder flow, authorisation usually includes:

1. redirecting the customer to the Data Holder
2. authenticating the customer
3. presenting the consent request
4. capturing the customer’s approval or rejection
5. issuing or confirming the access context used by the Data Recipient

Consent and authorisation are closely related, but not identical. Consent describes what access has been granted. Authorisation is the process used to grant or confirm that access.

Access token​

An access token is used by an authorised party to call protected APIs.

Wych Data Holder validates access tokens to confirm that:

• the token is valid
• the token has not expired
• the token was issued to the correct party
• the requested scope is allowed
• the request is consistent with the customer’s consent

Scope​

A scope defines the category of access being requested.

Scopes are used to control which APIs and datasets a Data Recipient can access.

For example, one scope may allow access to account information, while another may allow access to transactions or balances.

The exact scope model depends on the region, standard, and implementation profile.

Standards-aligned APIs​

Wych Data Holder exposes APIs that are aligned to supported open data and open banking standards.

Depending on your implementation, this may include support for:

• Australian Consumer Data Right (CDR)
• New Zealand open banking standards
• product reference data
• customer data APIs
• account and transaction APIs
• payment initiation APIs, where enabled

Wych provides the standards, security, and API layer while integrating with your source systems for the underlying data.

Source systems​

A source system is an internal Data Holder system that contains the data required to respond to an open data request.

Source systems may include:

• core banking systems
• lending platforms
• customer information systems
• product catalogues
• transaction stores
• payment systems
• CRM systems
• data warehouses
• integration services or APIs

Wych Data Holder can integrate with source systems directly or through an existing enterprise integration layer.

Data mapping​

Data mapping is the process of transforming internal Data Holder data into the required standards-aligned response format.

This may involve:

• mapping internal product types to standard product categories
• transforming account identifiers
• formatting balances and transactions
• applying data masking or filtering rules
• ensuring required fields are populated
• excluding data that is not permitted under consent

Good data mapping is essential for compliance, interoperability, and consistent customer outcomes.

Participant registration​

Participant registration is the process of recognising and managing the third parties that may request access to Data Holder APIs.

Depending on the region and standard, participant registration may involve:

• checking accreditation or registration status
• validating software products or client applications
• managing certificates
• managing client identifiers
• enabling or disabling access
• maintaining participant metadata

Wych Data Holder supports controls for participant access and operational management.

Certificates and security credentials​

Open banking and open data ecosystems rely on strong security controls.

This may include:

• transport certificates
• signing certificates
• client credentials
• mutual TLS
• token validation
• key rotation
• certificate expiry monitoring

Wych Data Holder uses these controls to help ensure that only authorised and trusted parties can access protected APIs.

Sandbox environment​

The sandbox is a non-production environment used for development, testing, and integration validation.

Use the sandbox to:

• test API connectivity
• validate certificates and credentials
• test consent and authorisation flows
• confirm source system mappings
• run conformance and regression scenarios
• prepare for production readiness

Sandbox data should be test data only.

Production environment​

The production environment is used for live Data Holder traffic.

Before moving to production, you should confirm:

• standards coverage
• endpoint configuration
• certificate and key setup
• participant access controls
• source system connectivity
• data mapping quality
• monitoring and alerting
• operational support processes
• incident response processes
• audit and evidence requirements

Monitoring and audit evidence​

Data Holder implementations need strong operational visibility.

Wych Data Holder can support monitoring and evidence across:

• API traffic
• request and response outcomes
• consent validation
• participant access
• errors and exceptions
• system availability
• operational events
• compliance and support investigations

Audit evidence helps demonstrate how requests were handled and supports issue investigation.

Data Holder Tester​

Wych Data Holder Tester helps validate Data Holder implementations against supported standards, scenarios, and expected behaviours.

It can be used for:

• pre-production validation
• regression testing
• release testing
• implementation assurance
• evidence collection
• operational readiness checks

Open payments​

Where enabled, Wych can support open payments capabilities alongside data sharing.

Open payments may include payment initiation, payment consent, and secure integration with payment systems.

Payment initiation has different risk, operational, and customer experience considerations from data sharing, so it should be designed and tested carefully.