When Australia's Consumer Data Right expanded from banking to energy and telecommunications, it created a class of API infrastructure that security testing programmes were not designed for. Banks became data holders under a mandatory government framework. Accredited Data Recipients gained API access to customer accounts. The attack surface between them, the consent management, token issuance, and data delivery layer that CDR requires, became a persistent target that standard API testing does not adequately cover.
New Zealand is converging toward the same model. Payments NZ has established API standards for open banking, and the RBNZ has introduced cyber resilience requirements for banks and insurers. In the USA, the CFPB's open banking rulemaking under Section 1033 is moving financial institutions toward similar API security obligations.
The shared problem is that generic API testing, even thorough generic API testing, does not test the things most likely to fail in a multi-party consent architecture. This is what open banking API penetration testing actually requires.
What Makes Open Banking APIs Structurally Different
Standard API testing validates authentication, cross-user authorisation, and input handling. Those tests are necessary and insufficient for open banking.
The structural difference is delegated authority. In a standard SaaS application, the user authenticates and the application responds. In open banking, a third-party provider authenticates on behalf of a customer using a scoped, time-limited consent. A vulnerability in that delegation model does not compromise one user session. It can compromise the trust boundary between the data holder and every accredited data recipient in the consent infrastructure.
The CDR framework requires data holders to validate ADR accreditation in real time against the ACCC Register and issue access tokens scoped exactly to what the customer consented to. Each requirement creates a distinct test case that does not appear in the OWASP API Top 10.
The Five Testing Areas Open Banking Requires
Consent and authorisation flow testing covers whether a consent scope can be escalated beyond what the customer granted, whether refresh tokens outlive their consent window, and whether revocation terminates API access or merely hides the connection from the customer's dashboard. In the CDR context, this also includes testing whether a data holder validates the consent's data cluster authorisation before returning data in each response, not only at token issuance. Consent logic changes with every product release. Testing it at launch and not again is the most common gap in open banking programmes.
FAPI profile validation is the second area. FAPI 1.0 Advanced and FAPI 2.0 require mutual TLS or private_key_jwt client authentication, signed request objects, and sender-constrained access tokens. Testing must confirm the API gateway rejects expired, self-signed, or revoked certificates rather than logging a warning and proceeding. Certificate validation bypass allows an attacker to impersonate a registered ADR without compromising a legitimate provider's private key. The foundational methodology is covered in the guide to API penetration testing and securing the backbone of modern applications, on which open banking testing builds.
Payment initiation API testing covers the highest-financial-impact surface. Amount tampering between consent creation and execution, currency manipulation, and race conditions allowing duplicate settlement require manual test cases with real payment flows. The NPP in Australia settles in seconds, compressing the window between a successful race condition and irreversible financial impact to near-zero.
Account information API testing extends beyond standard IDOR to cover whether a scope-limited token pulls data outside its consented account list through batch or aggregation endpoints. CDR data schema compliance adds a further dimension: payloads must return only the fields authorised by the consent type, not a superset of available customer data.
Webhook and callback integrity testing covers the notification layer that most REST-focused testing plans skip. CDR notification endpoints for consent events and error states carry unsigned payloads in many implementations, allowing a manipulated notification to trigger premature consent renewal.
Where ANZ Open Banking Testing Differs from PSD2 Scope
Most open banking security guidance is written for the European PSD2 environment. The CDR testing scope differs in two critical ways.
The first is the ACCC Register as the trust anchor. Data holders must validate ADR accreditation in real time against the ACCC Register, not a self-managed allowlist or cached certificate store. Testing must confirm the Register lookup cannot be bypassed or served from stale cache. A bypass here invalidates every downstream authorisation check.
The second is data minimisation at the schema level. CDR data clusters have defined fields. A data holder returning additional fields outside the consented cluster is non-compliant even if the excess data is partial. Testing CDR data schema against live API responses catches exposure that authentication tests alone will not flag.
For organisations preparing compliance evidence for APRA CPS 234, the RBNZ cyber resilience framework, or ACCC CDR audit expectations, the guide to continuous penetration testing for SOC 2 and ISO 27001 compliance covers how the ongoing testing programme connects to the evidence regulators expect.
Your Last Pentest Is Already Out of Date
Every week you ship without continuous testing is a week a vulnerability goes unseen. See what Capture The Bug finds in your first engagement.
Testing Cadence for Open Banking Platforms
Open banking platforms releasing API changes frequently cannot rely on annual testing. A consent flow tested before a CDR data schema update may behave differently after it. A FAPI configuration validated before an infrastructure migration may have been inadvertently weakened.
The practical cadence for most CDR-connected platforms is a full-scope engagement before any major CDR data cluster expansion, supplemented by targeted consent and token testing on every release touching the authorisation or token issuance service.
The guide to what happens after a penetration test covers re-testing steps that confirm a consent logic fix closed the vulnerability rather than addressed only its most visible symptom.
Choosing a Provider for Open Banking API Testing
Most publicly disclosed open banking incidents trace to authorisation logic, not cryptography. The FAPI handshake was compliant. The API trusted a scope claim it should have re-validated at data delivery. The question to ask any prospective testing provider is not "do you test APIs" but "have you tested delegated-consent architectures in the CDR regulatory environment, and what does a consent-scope escalation finding look like in your reports?"
A provider that cannot produce a sample finding involving consent-scope re-validation, ACCC Register bypass, or CDR data schema over-delivery has not tested this attack surface before. A generic API engagement built from the OWASP API Top 10 finds authentication and authorisation failures. It does not find the consent logic flaws where open banking's highest-severity vulnerabilities consistently live.
For ANZ organisations under APRA CPS 234 or RBNZ cyber resilience obligations, CREST certification is the baseline standard for testing providers. CREST-certified testers produce the evidence that APRA and RBNZ supervisory processes recognise as credible.
Book a consultation with Capture The Bug to scope an open banking API penetration test against your specific CDR data cluster configuration, FAPI profile, and regulatory compliance requirements.
Plan Your Annual Pentesting Strategy the Right Way
Learn how modern SaaS companies structure pentesting across the year to reduce risk, stay compliant, and avoid last-minute panic before audits.
FAQ
What is different about API penetration testing for open banking platforms?
Open banking API testing must validate delegated authority rather than only authenticated access. In a standard API, a user authenticates and the application responds. In an open banking platform, a third-party provider acts on a customer's behalf using a scoped, time-limited consent. Testing must validate that consent scope cannot be escalated, that tokens cannot outlive their consent window, that revocation terminates access rather than hiding the connection, and that FAPI-profile certificate validation cannot be bypassed. Standard API testing checklists do not include these test cases.
Does the Australian Consumer Data Right require API penetration testing?
The CDR rules require Data Holders and Accredited Data Recipients to maintain security controls consistent with their obligations under the CDR framework and the Privacy Act. APRA CPS 234, which applies to banks and other APRA-regulated entities, requires information security capabilities commensurate with threat exposure. Regular independent security testing is the standard way to evidence control effectiveness to the ACCC and APRA. The ACCC's CDR compliance assessment process treats untested API security controls as an evidence gap.
What is FAPI and why does open banking API testing need to cover it?
The Financial-grade API security profile (FAPI 1.0 Advanced and FAPI 2.0) defines mandatory security requirements for open banking implementations, including mutual TLS or private_key_jwt client authentication, signed request objects, and sender-constrained access tokens. Testing against FAPI requirements confirms that the platform's token issuance and client authentication cannot be downgraded, bypassed, or exploited through expired or spoofed certificates. A platform claiming FAPI conformance that has not been independently tested against the profile's attack scenarios cannot evidence that conformance to regulators or enterprise TPP onboarding partners.
How is open banking API testing in Australia different from PSD2 testing?
The Australian CDR framework uses the ACCC Register as the authoritative trust anchor for ADR accreditation. Data Holders must validate ADR status in real time against this Register. CDR testing must confirm this lookup cannot be bypassed or served from a stale cache. CDR also has specific data cluster schema requirements: testing must verify that API responses return only the fields authorised by the consented data cluster, not a superset of available customer data. Neither of these requirements exists in the PSD2 testing scope, making them ANZ-specific test cases not covered by guidance written for European open banking implementations.
How often should open banking APIs be penetration tested?
At minimum, before any major CDR data cluster expansion, after any change to the consent or token-issuance service, and before any significant infrastructure migration. Platforms shipping frequent API changes benefit from continuous or quarterly testing rather than annual engagements, because consent logic changes with every product release and a test performed before the last release tells you nothing about the current consent boundary enforcement.
