System Access Controls and Entitlements

Overview
Within the CTP body of knowledge, Technology in the Treasury Function covers how treasury uses treasury management systems (TMS), ERP modules, bank portals and connectivity channels such as SWIFT, host-to-host and APIs. System access controls and entitlements are the controls that determine who can enter these systems, what they are allowed to see or do once inside, and how those permissions are granted, monitored, reviewed and removed. Because treasury systems can move cash out of the company in seconds, this topic sits at the intersection of technology, internal control, fraud prevention and regulatory compliance.

Why System Access Controls and Entitlements Are Important
1. Fraud prevention. Most payment fraud, whether internal embezzlement or external business email compromise (BEC), ultimately requires someone with the ability to initiate, approve or release a payment. Properly designed entitlements make it impossible for one compromised or dishonest person to complete a transaction alone.
2. Segregation of duties (SoD). Access controls are the technical enforcement of the classic control principle that no single person should control a transaction from start to finish. Without system-enforced SoD, written policies are only aspirational.
3. Regulatory and audit compliance. Sarbanes-Oxley (SOX) Section 404 requires management to assess internal control over financial reporting, and IT general controls (ITGCs) over access are among the first items external auditors test. Weak access controls are a frequent source of material weaknesses and significant deficiencies.
4. Operational risk reduction. Limiting access reduces the chance of accidental errors, such as an untrained user releasing a duplicate wire or changing a bank account master record.
5. Protection of sensitive data. Treasury systems contain bank account numbers, forecasts, debt covenants and hedging positions. Confidentiality depends on restricting access.
6. Bank and counterparty requirements. Banks require companies to designate security administrators and define entitlements for each user on their portals; SWIFT's Customer Security Programme (CSP) mandates access controls for connected institutions and corporates.

What System Access Controls Are
System access controls are the policies, procedures and technical mechanisms that restrict access to systems and data to authorized individuals performing authorized functions. They are typically grouped into three layers:
a) Authentication - verifying that a user is who he or she claims to be. Factors include something you know (password, PIN), something you have (hardware token, smart card, mobile authenticator, digital certificate) and something you are (fingerprint, facial recognition). Multi-factor authentication (MFA) combines at least two different factor types and is now considered a baseline expectation for any system that can move money.
b) Authorization - defining what an authenticated user may do. This is where entitlements live.
c) Accountability - logging and audit trails that record who did what and when, so that activity can be monitored, investigated and attributed to a specific individual (which is why shared user IDs are prohibited).

What Entitlements Are
Entitlements (also called permissions, privileges or user rights) are the specific capabilities assigned to a user ID within a system. In a treasury or bank portal context, entitlements are typically defined along several dimensions:
- Function: view/inquiry only, create or initiate, modify, approve, release/transmit, administer users.
- Product or service: wires, ACH, book transfers, positive pay decisions, account reporting, FX dealing, investment trades, debt drawdowns.
- Account scope: which legal entities, bank accounts, currencies or cost centers the user may touch.
- Monetary limits: per-transaction and daily aggregate limits for initiation and approval, often with tiered approval (for example, payments above a threshold require a second or senior approver).
- Time or location: some systems restrict access to business hours, approved IP addresses or company devices.
Entitlements are usually bundled into roles (a practice called role-based access control, or RBAC), such as Cash Analyst, Payment Initiator, Payment Approver, Treasury Manager and Security Administrator. Assigning roles rather than individual permissions improves consistency and simplifies review.

Key Principles Behind Effective Access Control
- Least privilege: grant only the minimum access necessary to perform the job. A cash analyst who only needs to view balances should not have payment initiation rights.
- Need to know: restrict data visibility to those who require it.
- Segregation of duties: separate incompatible functions, most critically initiation, approval and release of payments, as well as maintenance of vendor or beneficiary master data from payment processing, and user administration from transaction processing.
- Dual control / four-eyes principle / maker-checker: at least two people must participate in a sensitive action. This applies not only to payments but also to changes in entitlements themselves.
- Dual administration: adding a user, changing a limit or granting a new entitlement on a bank portal should require one administrator to initiate and a second to approve. A single security administrator who can grant himself payment release rights is a classic control gap.
- Unique user IDs and non-repudiation: every action must be traceable to one person; generic or shared logins defeat the audit trail.
- Defense in depth: access controls work alongside encryption, firewalls, callbacks, payment file integrity checks and transaction monitoring; no single control is relied on alone.

How System Access Controls and Entitlements Work in Practice
1. User provisioning (onboarding). A manager requests access for a new employee through a formal, documented process. The request specifies the role and justification. An independent security administrator (often IT or a designated treasury administrator, not the user's own manager acting alone) creates the ID. On bank portals, two administrators typically must act. Access is granted only after approval is evidenced, and the user receives training on the system and on policy.
2. Role and limit configuration. The treasury department, in consultation with internal audit or controllership, documents a segregation of duties matrix that identifies incompatible roles. The system is configured so that a user with initiation rights cannot approve his or her own transaction, and so that release requires a separate approver above specified thresholds. Limits align with the company's delegation of authority policy and board resolutions.
3. Authentication at login. The user presents credentials plus a second factor. Strong password policies (complexity, expiration, lockout after failed attempts) and session timeouts apply. Many bank portals also issue tokens or digital certificates, and some require token-based confirmation at the moment a payment is released, not just at login.
4. Transaction workflow. The TMS or portal enforces the workflow: Initiator creates the payment; the system checks the initiator's account scope and limits; an approver with the appropriate approval limit reviews and approves; for high-value or sensitive payments, a second approver or releaser transmits the file. The system logs each step with user ID and timestamp.
5. Monitoring and alerts. Automated alerts notify treasury management of new users, entitlement changes, limit changes, failed login attempts, after-hours activity or new beneficiaries. Audit logs are retained and are themselves protected from alteration.
6. Change management for entitlements. When an employee changes roles, access is modified promptly so that privileges do not accumulate over time (the problem known as privilege creep or access creep). Temporary elevated access for backups or projects should have an expiration date.
7. Periodic access reviews (recertification). At least annually, and commonly quarterly for payment systems, a listing of all users and their entitlements is pulled from each system and reviewed by an appropriate manager who confirms each user still requires each privilege. Exceptions are removed and evidence of the review is retained for auditors. Reviews should cover bank portals, the TMS, ERP payment modules, SWIFT service bureau access and any spreadsheet-based or email-based approval processes.
8. Deprovisioning (offboarding). When employees leave or are terminated, their access is removed immediately, ideally the same day and before the employee departs in the case of involuntary termination. HR termination feeds integrated with identity management systems help automate this. Bank portal access, tokens and signatory authority must also be revoked, and account signature cards updated. Failure to remove terminated users promptly is one of the most commonly cited audit findings.
9. Privileged and service accounts. Administrator (super-user) accounts, vendor support accounts and system-to-system accounts used for file transfers deserve special attention: they should be few in number, used only when needed, logged, and never used for routine transaction processing. Passwords for these accounts should be vaulted and rotated.
10. Third-party assurance. When treasury systems are cloud-hosted or outsourced, the company relies on the provider's controls. Treasury should obtain and review SOC 1 (SSAE 18) and SOC 2 reports, evaluate the complementary user entity controls the company itself must perform, and ensure contractual rights to audit or receive security notifications.

Bank Account Entitlements and eBAM
Entitlements on bank systems deserve separate mention because they exist outside the company's own IT environment. Each bank maintains its own user roster, token devices and limit structures. Treasury must maintain a centralized inventory of who has access to which bank, with what rights, and reconcile that inventory regularly against bank-provided user reports. Authorized signers (for checks and paper instructions) and electronic entitlements (for portal payments) are different and must both be managed. Electronic bank account management (eBAM) tools and treasury management systems can centralize this inventory and standardize the process of adding, changing and removing users across multiple banks, reducing the risk that a departed employee retains access at a bank the company rarely uses.

Common Weaknesses Exam Questions Target
- One person can initiate, approve and release payments.
- A single security administrator can create users and assign himself payment rights (no dual administration).
- Terminated employees still appear on bank portal user lists.
- Shared or generic user IDs are used for bank portals.
- No periodic review of user entitlements, or reviews performed by the users themselves.
- Payment limits in the system exceed the limits in the board-approved delegation of authority.
- Password-only authentication without MFA or tokens for payment release.
- The same person who maintains vendor bank account details can also release payments.
- Excessive accumulation of privileges after job changes.
- Audit logs not reviewed or not protected from modification.

Related Frameworks and Terminology to Recognize
- COSO Internal Control - Integrated Framework: control activities, including access controls, are one of five components.
- SOX Section 404 and ITGCs: logical access, change management and computer operations are the core ITGC domains.
- ISO/IEC 27001 and NIST Cybersecurity Framework: information security standards that include access control domains.
- SWIFT Customer Security Programme (CSP): mandatory controls for SWIFT users including restricted access, MFA and privilege management.
- Identity and Access Management (IAM) / Single Sign-On (SSO): enterprise tools that centralize authentication and provisioning.
- Compensating controls: when SoD cannot be achieved because of small staff, management review of transaction reports, independent reconciliation and bank-side dual approval can partially mitigate the risk, although they are generally considered weaker than preventive system-enforced controls.

Exam Tips: Answering Questions on System Access Controls and Entitlements
1. Look for the single-person vulnerability. If a scenario describes one individual who can perform two incompatible steps (initiate and approve, maintain beneficiary data and release payments, administer users and transact), the correct answer almost always involves separating those duties through entitlements or adding dual control.
2. Prefer preventive, system-enforced controls over detective, manual ones. When asked for the best or most effective control, choose the option that stops the problem before it occurs (system-enforced approval limits, MFA, dual administration) rather than one that detects it afterward (reviewing reports), unless the question specifically asks for a detective or compensating control.
3. Apply least privilege. If an answer choice grants broader access than the role requires, it is probably wrong. The right answer limits access to what is needed.
4. Watch for timing words. Terminated employee access should be removed immediately or promptly, not at the next quarterly review. Access reviews should be periodic and documented.
5. Know who should do what. User administration should be performed by an independent security administrator with dual approval, not by the treasurer alone, and not by the user's direct supervisor acting unilaterally. Reviews of entitlements should be done by someone other than the user.
6. Distinguish authentication from authorization. Questions about tokens, passwords, biometrics and MFA are about authentication (proving identity). Questions about limits, roles, approval rights and account scope are about authorization and entitlements.
7. Remember that bank portal controls are the company's responsibility too. A company cannot assume the bank manages entitlements for it; treasury must maintain the inventory, request changes and reconcile user lists.
8. Connect access controls to fraud scenarios. In a BEC or vendor impersonation question, system controls such as dual approval, callback verification of beneficiary changes and separation of master data maintenance from payment release are the relevant answers.
9. Recognize audit and compliance context. If the question references SOX, auditors or material weakness, think ITGCs: provisioning, deprovisioning, periodic review, privileged access and audit logging.
10. Eliminate answers that rely on trust or policy alone. Answers such as remind employees of the policy or require the treasurer to be trustworthy are distractors; the exam rewards structural, verifiable controls.
11. When small staff is mentioned, the expected answer usually involves compensating controls (independent management review of all payments, bank-side dual approval, reliance on a second approver outside treasury such as the controller) while acknowledging that full segregation is preferred.
12. Read for the question's level. Some questions ask what a control is (definition), some ask why (risk addressed) and some ask which action (remedy). Match your answer to the level asked and avoid choosing a correct-sounding statement that does not answer the actual question.

Quick Review Summary
- Access controls restrict who gets into treasury systems; entitlements define what they can do.
- Core principles: least privilege, segregation of duties, dual control, unique IDs, audit trails.
- Lifecycle: provision with approval, configure roles and limits, authenticate with MFA, enforce workflow, monitor, review periodically, deprovision immediately.
- Highest-risk entitlements: payment release, beneficiary/vendor master changes, user administration.
- Exam answers favor preventive, system-enforced, independently administered and regularly reviewed controls.