Access evidence for a covered commercial bank
The companion governance article examines RBI’s 2026 Commercial Banks directions. This piece focuses on access and evidence decisions for covered banks. NBFC and fintech leaders can use the governance questions as a planning aid, but should check their own applicable directions rather than assume the commercial-bank framework applies to them. RBI applicability and Chapter V
Build an access map that can be tested
A bank’s product launches, integrations and staff changes can alter access requirements. Test whether live permissions still match current duties instead of assuming that the original approval remains appropriate.
Use the access and third-party sections of the directions as the obligation register. The review workflow below is a practical evidence approach; it is not a prescribed RBI template.
What a defensible position looks like before a review, not during one
Build the access map before a review is scheduled, not in response to one. Reconstructing who can touch what under time pressure produces worse decisions than doing it as a standing discipline.
Keep the approved policy and the operating evidence connected. A control statement should identify its scope and verification record; policy approval alone does not demonstrate that every permission is implemented correctly.
Where a partner or another reviewer requests related evidence, confirm the request’s scope and confidentiality conditions before reusing the pack. A regulatory evidence set should not be assumed to satisfy every external diligence request.
Where Bravewall’s role sits
A control and ownership map can connect the bank’s priority requirements to accountable teams. Scope the review to the actual service, applicable direction and unresolved decision.
A review pack for one critical banking service
Start with a bounded service, such as a payment interface, rather than an unverified enterprise-wide assertion. RBI Chapter V covers user access and third-party arrangements; read the full requirements and paragraph 4’s foreign-branch treatment before asserting compliance.
- Inventory the service’s human accounts, service identities, emergency accounts and supplier connections. Include production, administration and recovery paths. Record the inventory date and which sources were reconciled; an identity-provider export may omit local application accounts.
- Ask each business owner to confirm the continuing need for access and each technical owner to validate the actual permission. Track privileged and dormant accounts separately. Do not treat a manager’s approval as proof that the implemented role matches it.
- Sample a joiner, role change and leaver through the complete workflow. Preserve the request, approval, implemented state and completion time. Record any account that remained usable after the intended removal.
- For third parties, map the contracted service to data access, remote administration, subcontractors and exit dependencies. Paragraphs 126–129 address risk assessment, accountability and due diligence. A provider’s assurance report does not transfer the bank’s accountability.
- Reconcile exceptions to an owner, expiry and compensating control. For a shared support account, for example, demonstrate how individual activity remains attributable and how emergency access is removed after use.
End the pack with decisions: revoke, reduce, remediate, accept under delegated authority, or investigate further. Give the reviewer enough evidence to distinguish a documentation gap from an active access exposure. Retest changed permissions and show residual limitations instead of closing the exercise when signatures are collected.

