Bank-portal access is not the same control as payment approval. An approval rule decides whether a payment may proceed; portal entitlements decide who can view accounts, create payment instructions, release them, manage users, or change security settings. A recurring review reconciles those entitlements to current roles before stale access becomes a payment-control gap.
This checklist is for finance teams reviewing a business bank portal. It does not prescribe a bank’s security configuration or replace the organization’s policy. Set review frequency, retention, approvers, and escalation rules according to your risk assessment, bank agreements, and internal requirements.
Quick answer
Start with a bank-generated user-and-entitlement export, map every permission to a named business role and account scope, obtain a role-owner attestation, remove or correct exceptions through a separately authorized change, and retain the before/after evidence. The review is closed only when exceptions have an owner, a due date, and verified resolution—or an approved, time-bounded exception.
Set the control boundary before the review
Define what the review covers: every portal, legal entity, account, service, user type, and permission that can affect cash visibility or movement. Include administrator and security-administration rights, not just payment-release rights. The bank payment file controls guide addresses the integrity of a payment file once it is prepared; this checklist addresses the people and entitlements that can act in the bank environment.
For a useful baseline, NIST’s SP 800-53 AC-2 account-management control calls for account reviews at an organization-defined frequency and specifies attention to authorization, access, and inactivity. It is a control reference, not a universal legal schedule for every company.
Use a simple review state model
Track each review as Prepared → Extracted → Mapped → Attested → Exception Open → Changed → Verified → Closed. Never treat an attestation as proof that a change occurred. If a permission must change, log the request, obtain the required authorization, make the change in the bank portal, and collect evidence of the resulting state.
Bank portal access review checklist
| Check | Owner | Required evidence | Control and completion condition |
|---|---|---|---|
| Freeze the review population | Finance control owner | Review date, in-scope portals, entities, accounts, and services | Record the scope before evaluating individual users; changes after the cut-off are handled in the next review or a documented exception. |
| Export actual entitlements | Bank portal administrator | Dated bank-generated user, role, account, and permission export | Use the portal as the source of actual access. A spreadsheet of intended roles is not sufficient evidence. |
| Identify every privileged user | Portal administrator and security owner | List of administrators, user managers, token or MFA reset rights, and role-maintenance rights | Privileged permissions receive separate review because they can create or alter other users’ access. |
| Map permissions to business need | Role owner | Current job/engagement, role definition, entity/account scope, and approval limit where relevant | Each permission has a named purpose. Mark unmatched, excessive, or ambiguous rights as exceptions. |
| Test incompatible combinations | Finance control owner | Role-to-permission matrix and documented review decision | Check whether one person can create a payee, create a payment, and release it, or administer their own access. Use the organization’s approved segregation-of-duties policy—not a generic rule—to decide what is incompatible. |
| Confirm leavers and role changes | People/HR liaison and manager | Joiner-mover-leaver report or manager confirmation; last active date if available | Removed staff, ended contractors, and moved roles have no unjustified access. An unresolved identity match remains open, not assumed safe. |
| Obtain attestation | Role owner | Dated decision for each user/exception | Attest keep, change, remove, or investigate. The attestor must be able to judge the business need. |
| Authorize and execute changes | Authorized portal administrator | Approved change request, bank confirmation or post-change export | Do not use the review itself to bypass change authorization. Re-run the relevant extract or capture the bank confirmation after execution. |
| Close and retain evidence | Finance control owner | Completed checklist, exceptions, approvals, and final access evidence | Close only after every exception is resolved or formally accepted with an owner, expiry, and follow-up date. |
Review the entitlement, not just the user
For each user, evaluate the specific combination of portal, entity, account, service, action, limit, and administration privilege. “Payment user” is usually too broad to review. A user may be appropriate to initiate domestic payments for one operating account and inappropriate to release cross-border payments for another.
The finance team should compare these effective rights with its broader segregation-of-duties matrix. That matrix supplies the policy lens; the bank export supplies the evidence of what the portal currently permits.
Work a recoverable exception path
Illustrative example: a regional operations manager has kept a user-administration entitlement after moving out of finance. The role owner selects remove. The case remains Exception Open until an authorized administrator changes the entitlement and attaches a post-change export. If a critical payment window prevents immediate removal, the control owner records a temporary exception with compensating review, an expiry, and a specific revalidation date. A temporary exception is not a permanent approval.
Escalate cases where the owner is unknown, the bank export is incomplete, a departed user still has access, an administrator can alter their own privileges, or the organization cannot demonstrate the final state. Those are evidence failures, not clerical cleanup.
Keep payment approval and access recertification connected
A controlled payment process needs both a valid business authorization and appropriate bank access. The accounts payable controls checklist can help teams define evidence around invoice and payment controls; connect its approval records to the portal role review without assuming one proves the other. Payment authorization should not automatically grant bank entitlements, and a portal role should not substitute for approval of a particular payment.
Where Workhint fits
Workhint can help a finance team build the surrounding access-review workflow: assign scope and owners, request bank exports, route role-owner attestations, collect change evidence, track exceptions to closure, and preserve the audit trail. It does not operate the bank portal or determine a bank’s access policy. Book a demo to map a review process around your actual roles, evidence, and exception path.
Before closing the review
- Does the evidence show actual portal entitlements, not only intended roles?
- Does every privileged or payment-related right have an accountable business owner?
- Have incompatible combinations been evaluated against the organization’s own policy?
- Are change requests separately authorized and post-change access verified?
- Does every open exception have an owner, expiry, and next action?
Leave a Reply