What this means for your test
An authenticated API call can still be unauthorised. Compare customer, staff and service identities against the same synthetic account or instruction. Check read, update and approval operations separately, and verify downstream state rather than relying on a response code.
The boundary worth testing
Account ownership, delegated authority and transaction state create a richer permission model than login alone. Alternate APIs, exports and back-office functions need the same business rules.
A support application can become an entry point to CI credentials and an overprivileged payment identity. A separate signing service may still prevent release. A useful assessment explains each transition instead of turning one vulnerable host into a claim that the entire bank was compromised.
What the scope can include
- Account and customer object-level authorisation
- Session lifecycle, recovery and staff role transitions
- Payment drafts, beneficiary changes and approval boundaries
- Exports, file processing and back-office API operations
The final proposal identifies the specific applications, accounts, environments and interfaces included. It also states which prerequisites your team or a supplier must provide.
If the assessment also needs to cover the customer’s device or browser, include a banking app pentest. It adds the agreed iOS, Android or web client, local data handling and device-enrolment journeys to the supporting API scope.
What useful proof looks like
Use synthetic customers with controlled relationships and a seeded transaction. Verify state-changing requests through independent read-back and audit records, including the principal responsible for the operation.
Preserve UTC time, asset identifier, requesting principal, expected decision and observed response. State-changing tests need confirmation from the resulting object or a trusted audit record. Denied operations and effective controls remain part of the outcome.
Safety and assessment limits
The test does not release real funds by default. SWIFT, card networks, clearing services and shared providers require explicit scope and permission.
Use seeded payments and synthetic customers with settlement disabled. Agree independent stop authority, transaction reconciliation, named system owners and permission for third-party services. Separate demonstrated draft changes from unperformed fund transfers.
Close the loop
Connect each weakness to a named owner, immediate safeguard and durable correction. Define positive and negative retest cases so the change restores the intended boundary while preserving legitimate use. Open items retain their dependencies and deadlines.
Preview the sector sample report to see the evidence and treatment-plan format.
