Article map
Treasury access is distributed across the TMS, bank portals, SWIFT or file channels, ERP roles, market-data services, integration platforms, identity systems and administrative consoles. Reviewing only the TMS user list can therefore certify a person while leaving a powerful bank entitlement or service credential untouched.
A meaningful recertification asks whether access is still required, whether the role and limits are appropriate, whether combinations create conflict, and whether actual use supports the entitlement. Privileged and emergency access require additional evidence because they can alter configuration, users, interfaces or payment pathways.
This article explains how to run access recertification as an end-to-end treasury control rather than a periodic email asking managers to click approve.
1. Build a complete entitlement population
The review should inventory human and machine access across every system that can view, change, approve or transmit treasury data and transactions.
The operating boundary should define:
- TMS business, approval and administrative roles
- bank portal, mobile token and signing entitlements
- SWIFT, API, SFTP and integration service accounts
- ERP payment, bank-master and journal roles
- market data, valuation, reporting and support access
Each entitlement should link to a person, owner or service purpose. Orphaned technical accounts are not outside the control simply because no employee logs in interactively.
2. Evaluate role need, authority and actual use
Managers should receive enough context to make a decision: job role, entity, account, transaction type, limit, last use and previous exception. A role name alone is rarely sufficient.
The governed data record should capture:
- current employment and organisational role
- entity, account and currency scope
- prepare, approve, release and administer authority
- transaction and daily limits
- last login, last approval and usage frequency
Dormancy is an indicator, not automatic proof of redundancy. Contingency roles may be legitimate but require explicit rationale and testing.
3. Analyse segregation and toxic combinations
Conflict analysis should operate across systems. A user may create a beneficiary in the ERP, approve in the TMS and release in a bank portal even though no single system shows incompatible permissions.
The end-to-end workflow should make visible:
- beneficiary or bank-master maintenance plus payment release
- payment preparation plus final approval
- deal entry plus confirmation or independent valuation
- user administration plus transaction approval
- interface mapping change plus exception closure
Where a conflict is unavoidable, the compensating control should be specific, evidenced and reviewed, not a generic statement that management monitors activity.
4. Apply stronger governance to privilege and emergency access
Administrative, database, integration and break-glass access can bypass ordinary workflow. It should be limited, time-bound where possible, monitored and independently reviewed after use.
The control architecture should address:
- named privileged owner and approved purpose
- just-in-time or time-limited activation
- strong authentication and session logging
- prohibition or heightened control over direct financial-data change
- post-use review and credential rotation
Emergency access should be tested before an incident but should not remain permanently active for convenience.
5. Orchestrate decisions and revocation through the TMS control layer
The recertification platform should present joined entitlements, route decisions to accountable owners and verify that rejected access is actually removed at the source.
The TMS configuration should support:
- campaign scope, reviewer and due date
- approve, modify, revoke and exception decisions
- supporting rationale and conflict treatment
- source-system removal status and evidence
- escalation for non-response and failed revocation
Campaign completion should be based on implemented outcomes, not manager response alone.
6. Measure exposure and control performance
Metrics should show high-risk access, decision quality and whether revocations are timely.
Management reporting should measure:
- users and service accounts by risk tier
- dormant, orphaned and excessive entitlements
- segregation conflicts and compensating controls
- privileged and emergency access events
- revocations overdue, failed or reopened
A campaign with one hundred per cent approval may indicate poor challenge. Management should analyse approval patterns and reviewer behaviour.
7. Move from periodic review to event-driven governance
Quarterly or annual recertification should be supplemented by joiner, mover, leaver and material-role events. Bank and application changes should trigger targeted review.
The implementation plan should sequence:
- HR termination and role-change integration
- new bank, account, entity or payment service
- limit increase and privileged-role assignment
- extended inactivity or unusual use
- control incident, audit finding or organisational restructuring
Event-driven removal reduces the period of inappropriate access and makes the periodic campaign a validation of a living control rather than the only line of defence.
Management questions before approval
Before management approves treasury access recertification, the discussion should test the boundary described by build a complete entitlement population, the reliability of current employment and organisational role, and whether named privileged owner and approved purpose remains effective when an exception occurs. It should also ask how users and service accounts by risk tier will reveal whether the decision delivered its intended treasury result.
- Are human and machine entitlements in scope?
- Does access include banks and integration platforms?
- Can reviewers see account, entity, limit and last use?
- Are cross-system segregation conflicts analysed?
- Are compensating controls specific and evidenced?
- Is privileged access time-bound and logged?
The TMS record should connect those answers to analyse segregation and toxic combinations and to the action 'HR termination and role-change integration'. Where judgement changes the normal route for treasury access recertification, the evidence, approver, effective date and next review should remain visible beside campaign scope, reviewer and due date.
Evidence a controlled TMS should retain
The operating record for treasury access recertification should show how current employment and organisational role became an approved action under apply stronger governance to privilege and emergency access. It should retain source identity, calculation or transformation, workflow status, exception treatment and approval, together with the downstream result represented by campaign scope, reviewer and due date.
- named privileged owner and approved purpose
- just-in-time or time-limited activation
- strong authentication and session logging
- campaign scope, reviewer and due date
- approve, modify, revoke and exception decisions
- supporting rationale and conflict treatment
Version history for current employment and organisational role should preserve the information used when the decision was taken, even if later correction changes the current view. Comparing that history with users and service accounts by risk tier and the practical outcome in 'a former approver removed from the TMS but active at the bank' allows management to evaluate process discipline and decision quality without hindsight rewriting.
Operating decision record
The decision record for treasury access recertification should identify the event, the data cut supporting evaluate role need, authority and actual use, the assumptions applied and the policy or mandate that governed the choice. It should compare the selected action with a realistic alternative, identify the accountable owner and approver, and state when 'control incident, audit finding or organisational restructuring' or another change will require reassessment. A decision not to proceed with 'HR termination and role-change integration' should document the tolerance relied upon with the same discipline as an executed treasury action.
Continuity depends on linking that conclusion to escalation for non-response and failed revocation and to later evidence of revocations overdue, failed or reopened. Reviewers can then distinguish whether the original decision was reasonable on the information available from whether the eventual outcome in 'a former approver removed from the TMS but active at the bank' happened to be favourable or adverse.
Review cadence and change triggers
Routine review of treasury access recertification should follow the cadence implied by beneficiary or bank-master maintenance plus payment release, while an immediate refresh should occur when last login, last approval and usage frequency, market data, valuation, reporting and support access or a material system configuration changes. The reviewer should compare the current position with the last approved analysis and test whether post-use review and credential rotation and related limits remain valid.
A trigger may confirm that the existing build a complete entitlement population design remains suitable; it does not always require a new transaction or configuration change. Continued reliance should nevertheless become a dated conclusion, supported by approve, modify, revoke and exception decisions and reported through dormant, orphaned and excessive entitlements. Any treasury access recertification exception should carry an owner, interim treatment, escalation point and evidence of closure within the same TMS process.
Practical illustration: a former approver removed from the TMS but active at the bank
A manager transfers from treasury to a commercial role. HR workflow removes the person’s TMS approval role, and the quarterly application review shows no treasury access. The bank portal entitlement remains active because it is maintained by a different local administrator.
The joined recertification view identifies the bank role, its signing limit and six months of inactivity. The manager’s new supervisor rejects it, and the system tracks bank-side revocation to confirmation. Cross-system conflict analysis also identifies another user who can create beneficiaries in the ERP and release through the portal.
The control succeeds because it certifies the treasury capability across systems, not the contents of one application.
Implementation checklist
A treasury team preparing to operationalise this topic should be able to answer yes to the following questions:
- Are human and machine entitlements in scope?
- Does access include banks and integration platforms?
- Can reviewers see account, entity, limit and last use?
- Are cross-system segregation conflicts analysed?
- Are compensating controls specific and evidenced?
- Is privileged access time-bound and logged?
- Does rejected access trigger verified source removal?
- Are non-responses escalated?
- Are approval patterns reviewed for challenge quality?
- Do joiner, mover and leaver events trigger immediate action?
Common design failures
Access reviews become ceremonial when reviewers receive incomplete context or when decisions are not implemented in the source system.
- reviewing only TMS roles and ignoring bank entitlements
- sending technical role names without transaction authority
- analysing segregation within one application only
- leaving shared service accounts without named ownership
- treating manager approval as proof that access was removed or changed
- keeping break-glass access permanently enabled
The objective is to prove that every route to treasury data and value remains necessary, proportionate, segregated and under accountable ownership.
Closing perspective
Treasury access is an end-to-end capability that crosses applications, banks, channels and administration. Recertification must follow that capability rather than one user list.
A joined, evidence-based review gives management a defensible view of who can do what, where conflicts exist and whether rejected access has truly been removed.
Frequently asked questions
How often should treasury access be recertified?
Frequency should be risk-based. High-risk and privileged access may require more frequent review, while joiner, mover, leaver and material-change events should trigger immediate action between campaigns.
Should service accounts be included in access review?
Yes. Machine identities can transmit files, call APIs or alter data. Each needs an owner, purpose, scopes, credential lifecycle, usage monitoring and review.
What is a toxic access combination in treasury?
It is a combination of permissions that allows one person or identity to perform incompatible steps, such as beneficiary maintenance and payment release, without effective independent control.