Minor account permission testing verifies that access to a young customer’s account and actions is granted only to the people, roles and channels allowed by the bank’s documented product rules. It checks age-based access rules alongside account relationships, delegated authority and transaction limits, and confirms that unauthorised requests are rejected without exposing data or changing account state.
Define the permission rules before testing
Start with the approved requirements for each account type and jurisdiction. Record the applicable age thresholds, what happens when an account holder reaches a threshold, and which actions require a parent, guardian or other authorised adult. Rules can vary by product and location, so use the bank’s configured policy as the source of expected results rather than assuming a universal age or permission model.
Build a permission matrix covering account holder, parent or guardian, other linked adult, bank staff and unauthenticated user. For each role, list permitted actions such as viewing balances, changing contact details, setting up a payment or closing an account. Include limits, approval steps and any actions that must remain unavailable. Specify whether authority applies to one account or several, and how it can be added, changed or revoked.
Keep authentication and authorization separate in the test design. Authentication establishes who signed in. Authorization testing checks whether that identity can perform a particular action on a particular account. A correctly authenticated guardian should still be denied an action outside their recorded authority.
Design tests around identity, age and account state
Use synthetic test data with controlled dates of birth, account relationships and permissions. Cover ages immediately below, at and above each configured threshold. Check date handling around birthdays, leap days and relevant time-zone or processing-date boundaries where the system uses those values. Verify the source and refresh timing of age data, especially when customer records are updated through another system.
Include positive and negative cases for each role and action. Test direct navigation and API requests as well as the interface: a hidden button does not prove that the underlying operation is protected. Where an endpoint accepts an account identifier, attempt access to an account for which the test user has no authority. Assert that the response follows the API’s specified denial behaviour and returns no protected account data.
Test permission changes as state transitions. For example, after a guardian’s authority is revoked, check that subsequent requests across web, mobile and API channels use the updated permission. Check sessions or cached views where relevant, and confirm that a failed action leaves balances, payment instructions and account details unchanged. These cases form part of authorization testing and may also support Banking role-based access control testing and Banking API authorisation testing.
Worked example: guardian payment access
Assume the approved product rules allow a recorded guardian to view a minor’s savings account and create a payment up to a configured limit. A second approval is required above that limit. The account holder cannot change the guardian relationship themselves.
Create test accounts for a minor, a guardian linked to that minor, and an unrelated customer. Then verify the following:
| Actor and request | Expected result |
|---|---|
| Linked guardian views the account | Account data is returned |
| Unrelated customer requests the account by identifier | Access is denied and no account data is returned |
| Linked guardian creates a payment within the limit | Payment follows the permitted workflow |
| Linked guardian creates a payment above the limit | The required approval step is enforced |
| Minor attempts to change the guardian relationship | The request is denied under the stated rule |
For each request, assert both the response and the resulting state. A denied payment must create no pending or posted transaction. Where a request is accepted, verify the payment’s ownership, approval status and audit record against the expected workflow.
Verify the full permission path
Trace each rule from the requirement to the interface or service enforcing it, then to the test and its evidence. Check the user interface, service layer and any downstream account or payment system that can carry out the action. A screen-level restriction can be bypassed if a backend service accepts the same operation without checking authority.
Run the cases after changes to age rules, account relationships, identity data, API permissions or channel integrations. Environment drift can affect test outcomes when services use different policy versions or test data. Record the policy version, actor, account, request, response and relevant state changes so failures can be reproduced. Use Banking test data management practices to protect customer information and keep test relationships controlled.
Frequently asked questions
How should tests handle accounts with more than one guardian?
Represent each guardian relationship and its scope explicitly in test data. Verify whether each guardian can act independently, whether joint approval is required, and how one guardian’s removal affects the other guardian’s access, using the product’s documented rules.
How can a test detect insecure direct object reference issues?
Authenticate as a user who lacks authority, substitute another account’s identifier in the request and check that the service denies access without returning account data or changing state. Repeat the check for each relevant endpoint and object type.
What should happen to a test account when its holder reaches an age threshold?
The expected permission change should follow the bank’s configured transition rules. Test when the change takes effect, which existing authorities are retained or removed, and whether any customer action or review is required.