This quickstart helps you prepare a Wych Data Holder implementation.

It is intended for product, technology, security, compliance, and delivery teams onboarding to Wych Data Holder.

By the end of this guide, you should understand the main steps required to move from initial configuration to a working sandbox integration.

Before you start​

Before starting your Wych Data Holder implementation, confirm:

• the region or standard you need to support
• the brands that will participate
• the product types and data clusters in scope
• the source systems that hold the required data
• the identity and customer authentication model
• the environments required for development, testing, and production
• the technical and operational contacts for onboarding
• the expected go-live timeline

Step 1: Confirm your Data Holder scope​

Start by confirming what your organisation needs to expose through Wych Data Holder.

Typical scope areas include:

• customer data
• account data
• balance data
• transaction data
• product reference data
• scheduled payments
• direct debits
• energy data, where applicable
• payment initiation, where enabled

You should also confirm whether the implementation applies to:

• a single brand
• multiple brands
• a single product line
• multiple product lines
• retail customers
• business customers
• nominated representatives or delegated authority models

Step 2: Choose your implementation model​

Wych supports different Data Holder implementation models.

Wych-managed Data Holder platform​

Use this model when Wych provides the main open data infrastructure and your organisation integrates source systems and operational processes into the Wych platform.

This is usually the fastest path to production.

Integrated Data Holder services​

Use this model when your organisation already has mature internal platforms and Wych provides the standards, security, API, consent validation, and orchestration layer.

This is common where identity, customer records, product systems, or consent-related processes already exist internally.

Data Holder testing and assurance​

Use this model when you need to test or validate an existing Data Holder implementation using Wych Data Holder Tester.

This can be used before launch, during regression testing, or as part of compliance assurance.

Step 3: Set up environments​

Wych Data Holder implementations usually use separate environments for testing and production.

Common environments include:

Environment	Purpose
Sandbox	Development, early integration, and test data validation
Test or UAT	End-to-end validation with controlled scenarios
Production	Live customer and participant traffic

For each environment, confirm:

• base URLs
• API endpoints
• certificates
• client credentials
• allowed redirect URLs
• network access controls
• logging and monitoring requirements
• operational contacts

Step 4: Configure your Data Holder profile​

Your Data Holder profile defines how your organisation appears and operates within the Wych platform.

Configuration may include:

• organisation name
• brands
• product categories
• supported data clusters
• supported standards
• environment details
• certificates and security credentials
• operational contacts
• support contacts
• incident contacts
• participant access rules

This information is used to configure the Data Holder API layer, participant access, operational controls, and compliance evidence.

Step 5: Configure brands​

Each brand represents a customer-facing Data Holder identity.

For each brand, confirm:

• brand name
• logo and presentation requirements
• supported products
• supported data clusters
• customer support details
• customer-facing URLs
• consent and authorisation requirements
• production readiness contacts

Brands may share the same underlying systems or use different source systems depending on your organisation’s architecture.

Step 6: Connect source systems​

Wych Data Holder needs access to the systems that hold the data required for open data responses.

Common source systems include:

• customer information systems
• core banking systems
• loan origination or servicing systems
• card systems
• transaction stores
• product catalogues
• payment platforms
• CRM systems
• data warehouses
• existing internal APIs

For each source system, confirm:

• the data it provides
• the integration method
• the authentication model
• availability and performance expectations
• error handling behaviour
• data freshness
• field mapping requirements
• ownership and support contacts

Step 7: Map data to the supported standard​

Wych works with your team to map internal data to the required standards-aligned API responses.

Data mapping usually includes:

• account identifiers
• product identifiers
• customer identifiers
• account names and display names
• balances
• transaction descriptions
• transaction dates and amounts
• product reference data
• fees, rates, features, and constraints
• payment data, where applicable

Step 8: Configure participant access​

Wych Data Holder must know which Data Recipients, third-party providers, or ecosystem participants are allowed to access the APIs.

Depending on the implementation, participant access may include:

• participant registration
• accreditation or registry checks
• client identifiers
• software product identifiers
• certificate validation
• access enablement
• access suspension
• access revocation

Participant access controls help ensure that only authorised parties can request protected data.

Step 9: Validate consent and authorisation​

Before data can be shared, Wych Data Holder must be able to validate that a request is covered by a valid consent and authorisation context.

Validation may include checking:

• the requesting participant
• the customer
• the authorised accounts or products
• the approved data clusters
• the consent duration
• token validity
• scopes
• certificate status
• request purpose
• consent status

If a request is not valid, the Data Holder API should return an appropriate error response instead of returning protected data.

Step 10: Run your first sandbox API flow​

Once your initial configuration is complete, run a sandbox flow.

A basic test flow usually includes:

1. Configure a test participant or client application.
2. Create or simulate a customer consent.
3. Authenticate the customer in the test environment.
4. Request access to an approved data cluster.
5. Validate the access token and request context.
6. Retrieve data from the source system or test data service.
7. Return a standards-aligned API response.
8. Confirm that the request, response, and operational events are logged.

Step 11: Test expected and error scenarios​

A production-ready Data Holder implementation must handle both successful and unsuccessful requests.

Test scenarios should include:

• valid consent
• expired consent
• revoked consent
• invalid token
• expired token
• invalid certificate
• unsupported scope
• unavailable account
• unavailable source system
• invalid participant
• disabled participant
• malformed request
• missing required data
• timeout or downstream system error

Testing these scenarios helps confirm that the platform behaves predictably and securely.

Step 12: Prepare for production readiness​

Before production release, confirm that the following areas are ready:

• API configuration
• certificates and key management
• source system connectivity
• data mapping
• consent validation
• participant access controls
• monitoring and alerting
• operational support processes
• incident response processes
• audit evidence
• customer support processes
• release and regression testing
• compliance sign-off

:::warning Production readiness Production access should only be enabled once technical, security, operational, and compliance readiness activities are complete. :::

Example implementation checklist​

Use this checklist as a starting point.

Area	Status
Data Holder scope confirmed	Not started
Brands configured	Not started
Products and data clusters confirmed	Not started
Environments configured	Not started
Certificates and credentials configured	Not started
Source systems connected	Not started
Data mappings completed	Not started
Participant access configured	Not started
Consent validation tested	Not started
Sandbox API flow completed	Not started
Error scenarios tested	Not started
Monitoring configured	Not started
Operational support model confirmed	Not started
Production readiness review completed	Not started