Open Banking & APIs
Open Banking lets a customer tell a third party “you may see my account” or “you may make this payment for me.” The consent the customer gave is the contract, and testing it is the job.
1 The Hook
A fictional NZ budgeting app, Pātaka, helped people see all their accounts in one place. With the customer’s permission, it connected to their bank through an Open Banking API and pulled account balances and transactions. A customer granted Pātaka access to a single everyday account, for 90 days, to read transactions only.
A tester checked that Pātaka could read the consented account. It could. The data came back, the screens populated, the demo looked great. What no one tested was the boundary of the consent. When the team later probed it, they found that the same access token could also fetch the customer’s other accounts at that bank — a savings account and a joint account the customer had never agreed to share. The consent said one account; the API honoured the token but ignored the scope.
This is the defining risk of Open Banking. The danger is rarely that the happy path fails — the data usually comes back fine. The danger is that the API returns more than the customer consented to, or keeps working after consent should have ended, or lets one customer’s token reach another customer’s data. The failure is a silent over-grant, and a passing happy-path test never sees it.
Here is the lesson hidden in that story. The team tested that consent let data through. They never tested that the absence of consent kept data out. In Open Banking, the negative tests — what must be refused — matter more than the positive ones, because consent is the contract and a breach of it is a privacy breach under the Privacy Act 2020.
2 The Rule
In Open Banking the customer’s consent is the contract, and the API must honour it exactly — no more data, no longer, no broader than was agreed. Testing that consent grants access is the easy half. The half that matters is testing that everything outside the consent is refused: other accounts, expired consent, revoked consent, and another customer’s data.
3 The Analogy
Giving a house-sitter a key while you tramp the Routeburn.
You hand the house-sitter a key so they can feed the cat for two weeks. The key opens the front door — that is the access you meant to give. But a tester does not just check the key works on the front door. They check it does not open the neighbour’s house, that it stops working when you get back, and that it cannot also unlock the safe in the bedroom you never mentioned. A key that opens more than you intended, or keeps working after you are home, is the real problem — not a key that fails to open the door it was cut for.
An Open Banking consent is that key. It is scoped to certain accounts, certain data, and a certain time. The Pātaka bug was a key that opened the whole house when it was cut for one room. Testing Open Banking is testing the limits of the key far more than the door it is meant to open.
4 What Open Banking Is in NZ
Open Banking lets a customer authorise a third party — an app, a fintech, another bank — to access their bank data or to initiate payments on their behalf, through a standardised API rather than by handing over their login. The customer stays in control: they grant a specific consent, and they can revoke it.
In NZ this is coordinated through Payments NZ and its API Centre, which publishes standardised API specifications so that a third party can connect to participating banks in a consistent way rather than building a different integration for each one. The point of a standard is consistency: the same request shape, the same consent model, the same error structure across providers. For a tester, the standard is your specification — the contract you test the implementation against.
There is also a regulatory layer. NZ has a consumer data right framework taking shape that will set rules for how accredited parties access designated data, with banking among the first sectors. A tester does not need to recite the legislation, but you do need to understand the principle it enforces: a customer’s data may only be shared with their informed consent, only for what they agreed to, and they must be able to withdraw it. That principle is what your tests verify.
5 The Two API Families
Open Banking APIs fall into two families that carry very different risk, and a tester treats them differently.
Account information APIs (read). These let a consented third party read account data — balances, transactions, account details. Pātaka used these. The risk is over-disclosure: returning accounts, fields, or history the consent did not cover, or exposing one customer’s data to another’s token. Because the action is read-only, the harm is a privacy breach rather than lost money, but under the Privacy Act 2020 that is serious in its own right.
Payment initiation APIs (write). These let a consented third party start a payment from the customer’s account — a customer pays a merchant directly from their bank account through the merchant’s app, with no card involved. The risk is everything from Lesson 2 plus a consent layer: a payment for the wrong amount, to the wrong payee, initiated without valid consent, or initiated more than once from a single consent. Because this moves real money, it combines the payment-lifecycle risks with the consent risks.
The shared spine is consent. A read API must only read what was consented; a payment API must only pay what was consented — the agreed amount, to the agreed payee, once. In both families the question a tester keeps asking is: does this request fall inside the consent, and if not, is it refused?
6 Consent Is the Contract
A consent in Open Banking is a structured agreement with several dimensions, and each is a test surface.
- Scope — which accounts and which data. The Pātaka consent was one account, transactions only. The test: a request for any other account, or for data outside the agreed types, is refused.
- Duration — how long. A 90-day consent must stop working on day 91. The test: an access attempt after expiry is refused, not quietly honoured.
- Revocation — the customer can withdraw. When the customer revokes consent, access must stop immediately. The test: an attempt with a revoked consent is refused at once, not after a delay.
- Purpose and one-time use — for payments. A single-payment consent authorises one payment of an agreed amount to an agreed payee. The test: it cannot be replayed to make a second payment, and the amount and payee cannot be changed.
The consent flow itself is also a test target. The customer is redirected to their bank to authenticate and approve, then back to the third party. A tester checks that the third party cannot fabricate or alter a consent, that the customer genuinely authenticated at their own bank, and that the consent the third party ends up holding matches exactly what the customer approved — not a broader one substituted along the way.
Above all, the negative tests dominate. For every “consent allows X” test, write the matching “no consent, or different consent, refuses X” test. The Pātaka failure was an entire missing category of negative tests.
7 What to Test in an Open Banking API
The practical checklist:
- Consent scope enforcement: a token for one account cannot read another; data outside the agreed types is not returned.
- Consent expiry and revocation: access stops exactly when the consent ends or is revoked, with no grace window.
- Cross-customer isolation: one customer’s token can never reach another customer’s data — the classic broken-object-level-authorisation flaw, tested deliberately.
- Standard conformance: request and response shapes, field names, status codes, and error structures match the API Centre specification.
- Payment-initiation correctness: the initiated payment matches the consented amount and payee, cannot be replayed, and follows the payment-lifecycle rules from Lesson 2.
- Error handling: a refused request returns the correct, specified error — not a 500, not a leak of internal detail, and not data.
- Security basics: the API rejects malformed or tampered tokens, enforces transport security, and does not expose data through error messages.
8 Building API Test Cases
An Open Banking test case names the consent it operates under and, for the cases that matter most, asserts on a refusal — a specific error and the absence of data — rather than on success.
Here is the negative test case that would have caught the Pātaka bug:
API family: Account information (read)
Risk category: Consent over-grant (Privacy Act 2020 breach)
Consent under test: Customer consented to ONE everyday account, transactions only,
90 days.
Action: Using the token for that consent, request a DIFFERENT account the
customer did NOT consent to (their savings account).
Expected result: Request is refused with the standard’s “not authorised” error.
No account data of any kind is returned.
Negative assert: Response body contains zero transaction or balance data for the
non-consented account.
Evidence required: The request with the consented token; the response status and body;
the consent record showing scope = one account.
Traceability: Risk R-08 (token honoured beyond its consented scope).
Result: [Pass / Fail]
Notice the inversion from a normal test. The expected result is a refusal, and the strongest assertion is a negative one: that no data came back. The consent under test is stated explicitly, so the reviewer can see exactly what should and should not be reachable. This is the test the Pātaka team never wrote.
9 Common Mistakes
🚫 Only testing that consent grants access
Why it happens: The happy path is what the product demo needs, and the data comes back fine.
The fix: The Pātaka trap. For every “consent allows X” test, write the “no consent refuses X” test — other accounts, expired consent, revoked consent, another customer’s token. The negative tests are where the privacy breaches hide.
🚫 Not testing cross-customer isolation deliberately
Why it happens: With one test user, you never see another user’s data leak.
The fix: Set up two customers and deliberately use customer A’s token to request customer B’s account. It must be refused. This broken-object-level-authorisation flaw is one of the most common and serious API defects, and it only shows up if you test for it on purpose.
🚫 Treating a working app as proof the API conforms to the standard
Why it happens: If the screen populates, the integration feels correct.
The fix: An app can paper over a non-conformant API — wrong field names, missing error codes, undefined statuses. Test the API against the API Centre specification directly. Conformance is a requirement in its own right, independent of whether the app on top happens to cope.
🚫 Letting a single-payment consent be replayed
Why it happens: The first payment works, and replay is not part of the happy path.
The fix: A single-payment consent authorises exactly one payment, of one amount, to one payee. Test that the same consent cannot initiate a second payment, and that the amount and payee cannot be altered after the customer approved them. Combine this with the idempotency tests from Lesson 2.
10 Now You Try
Three graded exercises on consent and conformance. Write your answer, run it for AI feedback, then compare to the model answer.
Read the description of a fictional Open Banking account-aggregation feature below. Identify 3 consent or authorisation risks and explain the harm each could cause.
A customer consents to share one transaction account for 60 days. The app stores the access token and, on each refresh, requests every account the bank returns for that customer rather than only the consented one. When a consent reaches its 60-day limit the app keeps using the stored token until the next scheduled clean-up job runs, which is weekly. The app identifies customers by an internal ID passed in the request, and the API trusts whatever ID the app sends to decide whose accounts to return.
List 3 consent/authorisation risks and the harm of each:
Show model answer
There are at least three serious risks here; all three are strong. 1. Consent scope over-grant — The app requests every account the bank returns, not only the one consented account. If the API honours the token beyond its scope, the customer's other accounts are exposed without consent. Harm: a privacy breach under the Privacy Act 2020 — data shared the customer never agreed to. This is the Pātaka failure. 2. Consent expiry not enforced in real time — Access continues past the 60-day limit until a weekly clean-up job runs, so there is a window of up to a week where an expired consent still works. Harm: data accessed after the customer's consent has lawfully ended. The API itself must refuse an expired consent at the moment of the request, not rely on a downstream job. 3. Trusting a client-supplied customer ID (broken object-level authorisation) — The API returns accounts based on whatever internal ID the app sends. A bug or a malicious actor could pass a different customer's ID and receive that customer's accounts. Harm: one customer's data exposed to another — one of the most serious API authorisation flaws. Authorisation must be derived from the consent/token, never from a client-supplied identifier. The trap: all three pass a happy-path "the consented account's data comes back" test. Only deliberate negative and isolation tests catch them.
The Open Banking test case below only checks the happy path. Rewrite it as a negative consent-scope test, with these fields: Test ID, API family, Risk category, Consent under test, Action, Expected result, Negative assert, Evidence required, Traceability. Use a fictional BNZ account-information API as the context.
“Call the accounts endpoint with the token. Check the account data comes back. Pass if data is returned.”
Rewrite as a negative consent-scope test case:
Show model answer
Test ID: OB-CONSENT-011 API family: Account information (read) Risk category: Consent over-grant / scope enforcement (Privacy Act 2020 breach) Consent under test: Customer consented to one nominated everyday account, balances and transactions, 60 days. Action: Using the token issued for that consent, call the accounts endpoint requesting a different account the customer did not consent to (their joint account). Expected result: The request is refused with the API Centre standard's "not authorised / out of scope" error code. The consented account remains reachable in a separate positive test, but the non-consented account is not. Negative assert: The response body contains zero balance or transaction data for the non-consented account; no account identifiers for it leak in the error. Evidence required: The request showing the consented token and the non-consented account ID; the response status code and full body; the consent record showing scope = the one nominated account. Traceability: Risk register R-08 (token honoured beyond consented scope). What makes it strong: the expected result is a refusal with a specific standard error; the strongest assertion is the negative one (no data returned, nothing leaked); the consent under test is stated so the reviewer knows exactly what is and is not in scope; and it traces to a numbered risk. The original tested only that consent grants access — never that the absence of consent denies it.
Design a payment-initiation test plan of 5 test cases for a fictional Kiwibank payment-initiation API used by a merchant’s checkout. Each case needs at least: an ID, what it verifies, an acceptance criterion, and the evidence required. Cover correct payment, wrong amount/payee, consent replay, revoked consent, and standard error conformance.
Show model answer
PI-01 | Verifies: a consented payment is initiated for the exact agreed amount and payee | Acceptance criteria: payment posts for the consented amount to the consented payee, exactly once; settled funds reconcile | Evidence required: consent record (amount, payee); initiation response; settled payment; reconciliation PI-02 | Verifies: a payment with an amount or payee that differs from the consent is refused | Acceptance criteria: an altered amount or payee is rejected with the standard error; 0 funds move | Evidence required: consent terms; the altered request; rejection response; balance unchanged PI-03 | Verifies: a single-payment consent cannot be replayed | Acceptance criteria: a second initiation against the same one-time consent is refused; only one payment exists | Evidence required: the two initiation attempts; the refusal of the second; proof of exactly one settled payment PI-04 | Verifies: a revoked consent cannot initiate a payment | Acceptance criteria: an initiation after revocation is refused immediately; 0 funds move | Evidence required: revocation record with timestamp; the post-revocation request; rejection response; balance unchanged PI-05 | Verifies: refused requests return the API Centre standard's defined error structure | Acceptance criteria: each refusal returns the specified status code and error body; no 500s, no internal detail or data leaked | Evidence required: response bodies for each refusal compared against the standard's error schema Strong plans: each case is specific, has a measurable criterion, names concrete evidence, and together they cover a correct payment (PI-01), wrong amount/payee (PI-02), replay (PI-03), revoked consent (PI-04), and error conformance (PI-05). Note that several of these reuse the payment-lifecycle and idempotency thinking from Lesson 2. Weak plans say "check the payment goes through" five times — that is the difference being marked.
11 Self-Check
Click each question to reveal the answer.
Q1: In Open Banking, why do the negative tests matter more than the positive ones?
Because consent is the contract, and the dangerous failure is the API returning more than was consented — other accounts, data after expiry, another customer’s data. The happy path usually works; the harm is a silent over-grant. For every “consent allows X” test you need the matching “no consent refuses X” test, which is exactly what the Pātaka team missed.
Q2: What are the two families of Open Banking API and how do their risks differ?
Account information (read) and payment initiation (write). Read APIs risk over-disclosure — returning data outside the consent — which is a privacy breach. Payment APIs carry all the payment-lifecycle risks from Lesson 2 plus a consent layer: wrong amount, wrong payee, no consent, or a consent replayed for a second payment. Write APIs move money, so they combine both kinds of risk.
Q3: What are the dimensions of an Open Banking consent that each need testing?
Scope (which accounts and which data), duration (how long, with access stopping at expiry), revocation (the customer can withdraw and access stops immediately), and for payments, purpose and one-time use (one payment, one amount, one payee, no replay). Each dimension is a separate test surface, and each needs its negative case.
Q4: Why test the API against the API Centre standard even when the app works?
Because an app can paper over a non-conformant API — wrong field names, missing error codes, undefined statuses — while still appearing to work. Conformance to the published standard is a requirement in its own right. The standard is your test oracle, and a deviation from it is a defect regardless of whether the app on top happens to cope.
Q5: How do you test that one customer’s token cannot reach another customer’s data?
Deliberately, with two customers. Use customer A’s token to request customer B’s account and assert it is refused with no data returned. Authorisation must come from the consent/token itself, never from a client-supplied identifier. This broken-object-level-authorisation flaw only surfaces if you test for it on purpose, with more than one user.
12 Interview Prep
Real questions asked in NZ QA interviews for Open Banking roles. Read the model answers, then practise your own version.
“How would you test an Open Banking account-information API?”
I’d start from the consent, because consent is the contract. The positive test — the consented account’s data comes back — is the easy part. The work is the negative tests: a token for one account cannot read another, an expired consent is refused with no grace window, a revoked consent stops working immediately, and one customer’s token can never reach another customer’s data. I’d set up two customers specifically to test that isolation. I’d also test conformance to the API Centre standard — field names, status codes, and the defined error structure — because the app working does not prove the API conforms. The strongest assertions are negative ones: that no data came back.
“A consent expires at 90 days. The cleanup job runs weekly. What is the bug and how do you prove it?”
The bug is that expiry is enforced by a downstream job rather than by the API at request time, so for up to a week an expired consent still works — data accessed after the customer’s consent has lawfully ended. I’d prove it by advancing the consent past day 90 and making a request before the cleanup job runs, and showing data still comes back. The fix is that the API itself refuses an expired consent at the moment of the request. The acceptance criterion is no grace window at all: day 91 is refused, full stop.
“Why is a client-supplied customer ID dangerous in an Open Banking API?”
Because if the API decides whose data to return based on an identifier the client sends, then a bug or a malicious caller can pass a different customer’s ID and receive that customer’s data — broken object-level authorisation, one of the most serious API flaws. Authorisation must be derived from the consent or token, which is tied to a verified customer, never from anything the client supplies. I’d test it by taking a valid token and swapping the customer ID to another customer’s, and asserting it is refused with no data returned.