Australian Fintech QA: CDR, NPP & APRA CPS 234

Australian banking and financial services technology has undergone a fundamental shift in the past five years. The Consumer Data Right (CDR) and Open Banking framework, introduced by the Australian Competition and Consumer Commission (ACCC) and Treasury, has mandated that the Big 4 banks — and now a rapidly expanding list of data holders — expose customer data through regulated APIs accessible to accredited third parties. The New Payments Platform (NPP) has moved retail payment infrastructure to real-time settlement, raising the stakes of any payment processing defect from 'transaction delayed' to 'funds irreversibly transferred incorrectly'. And APRA CPS 234, the prudential standard for information security in APRA-regulated entities, has established enforceable requirements for software testing, vulnerability management, and incident response. For QA engineers, test managers, and technology leaders in Australian financial services, these three frameworks collectively define a testing environment unlike any other industry.

What Is Open Banking CDR Testing?

The Consumer Data Right (CDR) framework requires accredited data holders — currently banks, energy retailers, and (soon) telecommunications providers — to expose standardised APIs that allow customers to share their data with accredited third parties (called Accredited Data Recipients, or ADRs). For banks, this means implementing and maintaining the Consumer Data Standards (CDS) API specifications published by Data61, covering account information, transaction history, and product reference data. CDR testing is the process of verifying that these APIs conform to the Consumer Data Standards specification, meet the ACCC's conformance requirements, and operate securely and reliably in production. Conformance testing verifies API responses match the exact field names, data types, formats, and error codes specified in the CDS. Security testing verifies that the CDR consent model is correctly implemented — customers can only share data they have explicitly authorised, and ADRs cannot access data beyond the authorised scope. Performance testing verifies that APIs meet the response time SLAs specified in the CDR standards — typically sub-500ms for data queries. Integration testing verifies that the full consent flow — from customer authorisation through to data sharing and consent withdrawal — operates correctly end-to-end across the Data Holder's CDR ecosystem.

What Does NPP (New Payments Platform) Testing Involve?

The New Payments Platform (NPP) is Australia's real-time payments infrastructure, operated by NPP Australia Limited and accessible through its Overlay Services including Osko (BPAY Group) for PayID and real-time account-to-account payments. Unlike traditional batch payment systems where errors can be caught and corrected before overnight settlement, NPP payments are irrevocable and settle in under 60 seconds. This characteristic fundamentally changes the risk profile of payment processing defects and the rigour required for QA. NPP testing for financial institutions and fintechs building on NPP infrastructure includes: PayID registration and lookup testing — verifying that PayIDs (mobile numbers, email addresses, ABNs, ORGs) can be registered, updated, and resolved correctly; Real-time payment processing testing — validating that payment initiation, processing, settlement, and notification flows complete within NPP's sub-60-second SLA; Edge case and negative testing — testing payment failure scenarios, duplicate transaction handling, insufficient funds processing, and incorrect BSB/account number handling; Reconciliation testing — verifying that real-time payment records reconcile accurately with ledger systems and downstream reporting; and Fraud pattern testing — verifying that fraud detection rules operate correctly for high-value, unusual, or first-time payment patterns.

In NPP payments, a defect is not a bug report — it is a customer's money sent to the wrong account with no reversal pathway. The testing standards required for real-time payment systems are categorically different from those applied to traditional batch-processing financial applications.

What Is APRA CPS 234 and What Does It Require for Software Testing?

APRA Prudential Standard CPS 234 — Information Security — is the primary cyber security standard for APRA-regulated entities, covering banks (ADIs), insurers, and superannuation funds. CPS 234 came into force in July 2019 and requires regulated entities to: maintain an information security capability commensurate with the size and extent of threats to their information assets; implement controls to protect information assets and test the effectiveness of those controls; notify APRA within 72 hours of material information security incidents; and ensure third-party service providers managing information assets on behalf of APRA entities meet the same security standards. For software testing and quality engineering teams, CPS 234's key requirements translate to: Systematic vulnerability testing of internet-facing and internal applications on a defined cadence; Penetration testing of critical systems at least annually; Control effectiveness testing — not merely implementing security controls, but formally testing that they operate as intended; Third-party assurance — requiring that software vendors and cloud providers demonstrate equivalent security testing of systems processing APRA-entity data; and Incident response testing — exercising incident detection, containment, and recovery procedures to verify documented RTO/RPO objectives are achievable.

What Should a Comprehensive Fintech QA Programme Include?

• API conformance testing — automated validation of CDR API responses against the Consumer Data Standards specification, integrated into the CI/CD pipeline so every release is tested before deployment
• Security and penetration testing — OWASP API Top 10 testing for all financial APIs, including authorisation bypass testing, injection attacks, rate limiting verification, and token handling
• Payment flow integration testing — end-to-end testing of NPP, BPAY, and direct debit payment flows across all processing states, including failure, timeout, and retry scenarios
• Performance and load testing — validating payment API response times and throughput under peak transaction volumes, including Black Friday, EOFY, and tax time load profiles
• Fraud detection validation — testing that fraud rules fire correctly for known fraud patterns and that rule changes do not create false positives impacting legitimate customer transactions
• Regulatory reporting accuracy — testing that AUSTRAC, APRA, and ASX reporting outputs are accurate and complete, including reconciliation between source systems and report outputs
• Accessibility and UX testing — ensuring digital banking interfaces meet WCAG 2.1 Level AA under Australia's Disability Discrimination Act obligations
• Mobile banking testing — functional, performance, and security testing of iOS and Android banking applications across device types and OS versions in real-device environments

Common QA Failures in Australian Fintech That Lead to Regulatory Incidents

Regulatory enforcement actions and public incident reports from APRA, the ACCC, and ASIC reveal recurring QA failures in Australian financial services technology. CDR consent scope creep: APIs returning data fields beyond the scope of the customer's consent authorisation — most often caused by insufficient negative testing of authorisation boundaries. NPP duplicate payment processing: Retry logic in payment initiation systems triggering duplicate NPP submissions when original transaction status responses are delayed — requiring specific idempotency key testing. Authentication bypass in mobile banking: Session management vulnerabilities allowing authorised sessions to access accounts other than the authenticated user's — discovered in penetration testing but missed in standard functional test cycles. Backup restoration failure: Documented backup processes that cannot actually restore systems within the RTO specified in CPS 234 compliance submissions — because backup integrity testing has never been formally conducted. Third-party API failures: CDR data holder APIs that pass internal testing but fail ACCC conformance certification because internal test environments do not replicate production data volumes, latency, and error rates.

Building an APRA-Ready QA Programme: Key Principles

• Compliance evidence by design — structure test plans, results, and traceability matrices from the outset as evidence artefacts for APRA audits, not as an afterthought
• Shift-left security — integrate OWASP-aligned security testing into the development pipeline rather than relegating it to pre-release penetration tests
• Automated CDR conformance — implement automated CDR API conformance testing in CI/CD so every code change is validated against the Consumer Data Standards before it reaches a test environment
• Real-data-volume performance testing — test API performance at production-representative data volumes; small-dataset test environments systematically underestimate real-world response times
• Third-party testing requirements — include contractual testing evidence requirements in vendor agreements covering security testing, penetration testing cadence, and vulnerability management
• Independent assurance — separate internal QA (developers testing their own code) from independent assurance (external testing of production-ready releases) as CPS 234 implies

KiwiQA has deep experience across the Australian financial services technology landscape, with testing engagements covering Open Banking CDR implementations, NPP payment infrastructure, neobank product launches, superannuation platform migrations, and APRA CPS 234 compliance programmes. Our security-cleared engineers understand Australian regulatory requirements and have delivered testing that satisfies both internal quality standards and external regulatory obligations. Explore KiwiQA's financial services testing capability at kiwiqa.ai/security, kiwiqa.ai/automation, and kiwiqa.ai/performance, or speak with our team about your specific fintech or banking QA requirements.