Home/Specialised/Banking QA
New · Specialised Track

Banking & Payments QA — testing money in NZ

The NZ-localised guide to testing the systems that move money.

Banking and payments software is where a defect is not a cosmetic glitch — it is someone’s rent paid twice, a settlement that never lands, or a fraud alert that fires on the wrong customer. This track teaches you to test core banking ledgers, the NZ payment rails, Open Banking APIs, PCI-DSS scope, and AML/CFT fraud workflows with the precision the domain demands.

Start with Lesson 1 → Back to Specialised

This track covers

Core Banking & Ledgers Payments & Settlement Open Banking APIs PCI-DSS for Testers AML/CFT & Fraud

NZ context

Grounded in the NZ landscape — the RBNZ, Payments NZ and the API Centre, the AML/CFT Act 2009, EFTPOS, and the major banks. Every example is a system you might actually test here, not a generic overseas case.

Who this is for

Testers and Test Leads moving into banking, fintech, or payments work in NZ. Assumes ISTQB Foundation Level or equivalent. No prior finance background required — the domain is taught from first principles.

The 5 lessons

From the ledger to the fraud queue

Lesson 1

Core Banking & Ledger Testing

Accounts, balances, and postings. Double-entry, settlement, and reconciliation. Why the ledger must always balance, and how to test it when it must.

~30 min read · ~70 min with exercises · Banking QA

 Lesson 2

Payments Testing

Card, EFTPOS, direct debit, and bill payment. Authorisation versus settlement, 7-day and real-time rails, reconciliation, and chargebacks.

~30 min read · ~70 min with exercises · Banking QA

 Lesson 3

Open Banking & APIs

The Payments NZ API Centre standards. Testing account-information and payment-initiation APIs. Consent flows, and what breaks when consent is the contract.

~30 min read · ~75 min with exercises · Banking QA

 Lesson 4

PCI-DSS for Testers

Cardholder data, tokenisation, and scope reduction. What a tester actually verifies under PCI-DSS — and how to test that card data never goes where it should not.

~30 min read · ~70 min with exercises · Banking QA

 Lesson 5

AML/CFT & Fraud Testing

The NZ AML/CFT Act 2009. KYC, transaction monitoring, and suspicious-activity flows. Testing fraud detection — and handling the false positives that hit real customers.

~30 min read · ~75 min with exercises · Banking QA
Why this track

A domain that does not forgive defects

Most software fails softly. A broken button frustrates a user, who tries again. Banking software fails hard. A rounding error repeated across a million accounts is real money gone. A direct debit that posts twice empties someone’s account before payday. A settlement file that misses the cut-off leaves a merchant short for a day. The cost of a defect here is measured in dollars and trust, and the trust does not come back easily.

The good news for a tester is that the domain is deeply logical. The ledger must balance. Debits must equal credits. A payment is either authorised or it is not. Reconciliation either matches or it does not. Once you understand the rules, banking gives you something rare — clear, checkable acceptance criteria where a result is right or it is wrong.

This track teaches those rules in the NZ context. By the end you will be able to test a core banking ledger, a payment from authorisation to settlement, an Open Banking API consent flow, the boundaries of PCI-DSS scope, and an AML/CFT transaction-monitoring rule — and write the evidence that shows you did.

Related

Other specialised tracks

Specialised

API Testing

Contract testing, status codes, and idempotency — the foundation under every payments API.

 Specialised

Security Testing

OWASP, NZISM, and the threat models that matter when the system holds money.

 Specialised

Privacy Testing

The NZ Privacy Act 2020 in practice — consent, data minimisation, and breach response.