Skip to main content

Data Compliance Validation concepts​

Wych Compliance Validation supports conformance and implementation validation for Data Holder APIs and associated security and interoperability requirements.

This page explains the key testing concepts across:

  • AU CDR
  • NZ PNZ

What is being tested​

A Data Holder Tester validates that a Data Holder implementation behaves as expected for:

  • API behaviour (endpoints, payloads, headers, pagination, error handling)
  • security requirements (authorisation, token handling, client authentication patterns)
  • standards alignment (version support, mandatory vs optional fields)
  • operational behaviours (rate limiting behaviour, idempotency where applicable, eventing or notifications where applicable)

Key terms​

Target​

The system under test. This includes:

  • base URL for the Data Holder implementation
  • environment and version information
  • any required configuration for test execution

AU CDR Target typically maps to a CDR Data Holder environment (for example a bank sandbox).
NZ PNZ Target typically maps to a PNZ Data Holder environment supporting PNZ endpoints and security profiles.

Test suite​

A grouped collection of tests aligned to a standard area (for example accounts, balances, transactions, security, or consent).

Test suites normally contain:

  • preconditions
  • request definitions (method, path, headers, bodies)
  • assertions on responses (status, schema, business rules, headers)
  • negative testing (authorisation failures, invalid parameters)

Test case​

A single executable validation with expected outcomes, including:

  • steps
  • expected result
  • pass or fail criteria
  • evidence captured during execution

Evidence​

Artefacts captured during test execution to support traceability and defect resolution, typically including:

  • request and response metadata
  • timestamps and correlation identifiers
  • assertion results
  • logs and error details where available

:::info Evidence expectations Many customers use the tester’s evidence outputs to support internal assurance, vendor management, and delivery sign-off. :::

Defect​

A recorded failure or deviation from expected behaviour. Defects should be actionable and include:

  • failing test case reference
  • observed behaviour
  • expected behaviour
  • reproducible steps
  • supporting evidence

Certification and conformance context​

The tester supports technical validation. Whether that validation is used for certification or formal conformance depends on the ecosystem, programme, and engagement.

AU CDR Testing can support CDR conformance expectations and internal readiness checks.
NZ PNZ Testing can support PNZ-aligned implementation validation and programme readiness.

Common validation areas​

API behaviour​

  • correct endpoint availability and version routing
  • schema correctness and required fields
  • pagination consistency
  • deterministic error handling

Security behaviour​

  • correct enforcement of authorisation
  • token audience and scope handling
  • client authentication mechanisms where applicable
  • headers and caching controls where required

Operational behaviours​

  • handling of timeouts and retry patterns
  • rate limiting responses and backoff behaviour
  • consistency across environments

Outcomes​

A typical output of Data Holder testing includes:

  • pass or fail summary by suite
  • detailed results by test case
  • evidence bundle to support remediation
  • defect list and prioritisation guidance
  • Guides: Running tests, interpreting results, reporting and evidence
  • API Spec: If you integrate the tester into CI pipelines or internal tools