They should compare the active consent state, policy decision logs, and revocation events against the current business relationship. If a cancelled mandate still shows usable API access, the control is failing. Effective delegated access means the technical policy state and the legal authority state always match.
What “working” means for delegated access in banking
delegated access is working only when the permissioned action matches the current business authority. In practice, that means the bank can prove the consent is still active, the policy engine is making the expected decision, and any revocation or expiry has removed the access path. If the legal mandate has ended but technical access still succeeds, delegation has drifted out of control.
That distinction matters because delegated access is not just an application feature. It is a controls chain that links customer authority, policy enforcement, and revocation. Banks should expect the technical state to reflect the legal state continuously, not eventually.
How banks should test delegated access state
The most reliable test is state reconciliation. Compare the active consent record, the policy decision log, and the revocation event history against the underlying business relationship. If those three views disagree, the bank should treat the delegation as untrusted until it is explained.
This check is stronger than a simple login test. A login can succeed even when the authority is stale, inherited incorrectly, or only partially revoked. The control is healthy only when the system can show who authorised access, what scope was granted, when it should end, and whether the enforcement layer actually stopped it.
- Confirm the delegated relationship is still valid in the source of truth.
- Confirm the policy engine issued the expected allow or deny decision.
- Confirm revocation, expiry, or mandate cancellation removes access immediately.
- Confirm the user or third party can no longer call the API or retrieve data once authority ends.
What breaks when delegated access is out of sync
Breakage usually appears as a mismatch between relationship state and access state. The most common failure is orphaned access, where a cancelled mandate or expired consent still leaves usable API permissions in place. Another failure is scope creep, where the bank revokes one path but leaves a broader token, permission set, or downstream entitlement active.
For banks, the operational impact is not just overexposure. It also undermines auditability, because the institution can no longer demonstrate that every successful action was backed by current authority. Once that chain is broken, incident handling becomes slower because teams must separately determine whether the access was legitimate, stale, or abused.
Risk and Threat Considerations
Delegated access failures create direct exposure to unauthorized data use and payment or account actions after the underlying business relationship has changed. The risk is highest when cancellation, expiry, or customer withdrawal of consent is not enforced across every access path, especially APIs and long-lived tokens.
Failure mechanism: The consent record, policy decision, and revocation state diverge, so a previously valid grant continues to authorize calls after the mandate has ended.
Impact: Customers or third parties can retain access beyond authority, which can cause privacy breaches, transaction misuse, audit findings, and control failures that are difficult to detect from the application layer alone.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Delegated access must stay limited to the authority actually granted. |
| AU-2 — Event Logging | Decision and revocation logs are needed to reconcile access state. | |
| IA-5 — Authenticator Management | Delegated access often depends on tokens or credentials that must expire or be revoked. | |
| Recommendation — Limit delegated permissions to the minimum scope and remove them when authority ends. Log consent, policy, and revocation events so delegated access can be verified. Manage delegated credentials and tokens so expired authority cannot keep working. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Delegated access requires access rules to match current authority. |
| A.5.18 — Access rights | Banks must review and remove rights when consent or mandates end. | |
| Recommendation — Align access decisions to the current business relationship and revoke stale rights. Review and withdraw access rights when the underlying relationship changes. | ||
Practitioner Guidance
What to verify: Test delegated access from the business event backwards. For each cancellation, expiry, or mandate change, verify the bank can show the revocation event, the denied policy decision, and the disappearance of usable access within the expected service window.
Decision rule: If the platform can still execute actions after consent has ended, treat that as a control failure even if no abuse is visible. Do not wait for an incident to prove the gap.
Practitioner takeaway: Effective delegated access is measured by revocation fidelity, not by whether an initial grant worked.