How to test corporate bank mandate expiry

Corporate bank mandate expiry testing checks that a corporate account's payment authority stops working when its configured mandate expires, and that valid authority remains available up to the correct point. It verifies date and time rules, authorised signatories, approval workflows and connected channels, using the requirements that define how expiry affects payments already in progress.

Define what expiry means

A mandate records who can approve or sign payments for a corporate customer, often with conditions such as account scope, payment limits or required combinations of signatories. Expiry testing verifies the system's treatment of that authority after its configured end point. The rule may apply to a mandate, an individual signatory, or both, so test design should distinguish these cases.

First, confirm the expected expiry semantics with the approved requirements. Establish whether the expiry date is inclusive, which time zone applies, whether the rule runs at a scheduled processing time, and what happens to payments awaiting approval. Requirements also need to say whether expiry blocks new instructions only or affects an existing payment workflow. Do not assume every bank implements the same policy.

Mandate expiry is different from a user's login or general entitlement expiry. A user may still be able to access the corporate portal while losing authority to approve payments under an expired mandate. Test access and payment authority separately so a successful login does not count as proof that signing permission remains valid.

Prepare test data and dependencies

Use controlled test entities with known account-to-mandate and signatory-to-mandate relationships. Include a valid mandate, one approaching expiry, an expired mandate and, where supported, a mandate with different expiry dates for different signatories or accounts. Record the expected authority for each user and account before execution.

Check dependencies that can affect the result: the system clock and time zone, expiry batch or event processing, caches, replicated entitlement data, corporate portal permissions and payment approval services. Environment drift can make a boundary test misleading if one component uses a different date or has stale authority data. Use a controlled test clock or approved test records where available, and verify when expiry changes become effective across connected systems.

Test the boundary and payment workflow

Use boundary cases immediately before, at and after the configured expiry point. For each case, check both the user interface and the outcome recorded by the service or downstream workflow. A button disappearing is insufficient evidence if an API or another channel still accepts the approval.

A practical test case might use a mandate that expires at the end of a specified business date. Before that point, an authorised signatory submits an approval and the system records it against the correct mandate. At the expiry point, attempt the same action again. The expected result should follow the agreed rule: for example, reject the new approval, identify the mandate as expired, and leave the payment in the defined state without recording an approval. After expiry, also test a user who remains entitled to access the portal but is no longer authorised to sign.

Cover these workflow variations where they apply:

• A payment awaiting a second signatory when the mandate expires.
• An instruction created before expiry but submitted or approved afterwards.
• A payment below and above a mandate limit, to separate expiry behaviour from limit enforcement.
• A payment requiring multiple signatories, with one or all signatories affected by expiry.
• Attempts through the corporate portal, API or host-to-host channel, if those channels use the mandate.

For pending payments, assert the required state transition explicitly. Depending on the requirement, the payment may remain pending, require a replacement approval, or be rejected. Check that expiry does not silently complete an approval or bypass maker-checker controls.

Verify results and common failure modes

Assert the decision, payment status, reason code or message, audit record and any notification required by the workflow. Confirm that a rejected approval does not create an approval event, alter the payment amount, or trigger downstream submission. Where events or replicated permissions are involved, check that changes reach each relevant component within the specified processing window.

Common defects include an off-by-one-day error, inconsistent time-zone handling, expiry applied to the wrong account, stale signatory permissions in one channel, and pending transactions treated differently from the documented rule. Also check that reprocessing or retrying an action after expiry cannot create a duplicate or bypass the decision. Record the requirement linked to each expected result and retain enough execution evidence to reproduce failures.

Automated checks can cover fixed date boundaries and repeated channel-level assertions, while exploratory testing can help expose inconsistent behaviour across unusual approval paths. Keep test data deterministic and resettable so the same mandate state can be reproduced in regression runs.