ATM Switch and CBS Providers: The Controls Your Bank Customers Must Now Impose on You

Every bank and urban co-operative bank that runs its ATM Switch through a shared service now carries a written instruction to impose a named list of cybersecurity controls on the provider running it. The instruction is addressed to the bank. The work lands on you.

The Reserve Bank of India issued six entity-specific Cybersecurity, Technology: Risk, Resilience and Assurance Framework Directions on 31 July 2026, all in force on issuance with no glide path. Four of them speak directly about Application Service Providers: the Commercial Banks instrument (RBI/DoS/2026-27/410) at paragraphs 136 to 139, and the Urban Co-operative Banks instrument (RBI/DoS/2026-27/437) at paragraphs 83 to 86. Between them they enumerate 24 and 37 baseline controls respectively, and both require the bank to put them in the contract.

If you provide ATM Switch or core banking services on shared infrastructure to Indian banks, your customers are now obliged to demand evidence from you. The only question is whether you answer once, properly, or forty times in forty different spreadsheets.

What paragraph 136 actually does

CB para 136 opens the chain. The bank "shall ensure that the following cybersecurity controls are implemented and maintained by third-party Automated Teller Machine (ATM) Switch Application Service Providers (ASPs) where the bank manages its ATM Switch ecosystem through their shared services." What follows is twelve control areas, each cross-referenced to the paragraphs of the Directions that define them for the bank itself: preventing access of unauthorised software (paras 57 to 59), environmental controls (paras 60 to 61), network management and security (paras 69 to 71, 73-77), secure configuration (paras 66 to 67), application security life cycle (para 79, 80, 82, 83, 84, 88), patch, vulnerability and change management (para 86, 99, 101-103), user access control (para 106, 107, 112, 113), data leak prevention (para 51), audit logs (para 94, 96), incident response and management (para 164), advanced real-time threat defence (paras 144 to 145), and forensics (para 211).

Read that list again with your own estimate in front of you. RBI has taken the bank's own control catalogue and pushed it, by reference, onto your estate.

CB para 137 closes the loop: those controls "shall be suitably factored in the contract agreement signed with the third-party Switch ASPs." It also draws the boundary, and the boundary is wide — the controls apply to the ASP "limited to the IT ecosystem (such as physical infrastructure, hardware, software, reconciliation system, network interfaces, security solutions, hardware security module, middleware, associated people, processes, systems, data, and information) providing ATM switch services as well as any other type of payment system related services to the bank."

Associated people are inside the perimeter. So is the reconciliation system, and the HSM, and any other payment-system service you happen to provide on the same footprint.

The 24 baseline controls at paragraph 138

CB para 138 is the operative list: "The bank shall ensure to mandate the following baseline cybersecurity controls in their contractual agreements with these ASPs," followed by sub-clauses (1) through (24). Most are configuration and access hygiene — default passwords changed after installation (1), "centralised IAM with two-factor or multi-factor authentication depending on risk assessment, least privilege and separation of duties (3)"., privileged access through a PUM/IAM system (4), network segregation (5), firewall rules blocking unidentified outbound connections and reverse TCP shells (6), remote connections into the ATM Switch network disabled (7), IP tables restricting SWIFT and ATM Switch access to authorised systems (8), software integrity of Switch applications (9), masked data in development and test (10).

Six of the twenty-four require something you cannot self-assert in a meeting:

• (11) — you shall certify new products, updates and upgrades as developed following secure coding practices, and the application architecture "shall be tested"; the assurance "shall be shared with the bank / RBI as and when requested."
• (12) — for critical business applications you shall conduct source code audits "by professionally competent personnel / service providers" and give the bank assurance the application is free from embedded malicious or fraudulent code.
• (19) — you shall periodically conduct VA/PT of applications, servers and network components.
• (20) — you shall share the VA/PT reports and compliance to the findings with the bank or RBI on request.
• (23) — you shall set up a Cyber Security Operations Centre that collects the relevant logs, correlates them through a SIEM for continuous surveillance, and keeps current on emerging threats.
• (24) — you shall comply with PCI-DSS and PCI Software Security Framework as applicable to the IT ecosystem.

And para 139 keeps the pipe open: the bank shall pass on RBI circulars, advisories and alerts applicable to the ATM Switch ecosystem to you "for necessary compliance."

The UCB mirror, and where it goes further

UCB para 83 does the same job with twelve cross-referenced areas, and the differences are worth noting. Gloss it once: "— para 83(11), Vulnerability Assessment and Penetration Test, which the instrument cross-refers to UCB para 118 (the remediation clause; the conduct requirement itself is at para 116)." para 84 requires contract incorporation on identical terms. Para 86 is the circular pass-through.

Para 85 is the long one: 37 enumerated controls, and it goes deeper into the software estate than the CB list does — an emergency patch process tracking OEM and CERT-In advisories (1), "a documented exception framework covering justification, duration, the grant process and an approving authority, with periodic review by officers preferably at senior levels (2)"., development based on threat modelling with security testing against global standards (12), certification of new products and updates with assurance shared with the UCB or RBI (14), source code audits by professionally competent personnel for critical business applications (15), OWASP-informed development practice with defence in depth (16), and at (18) periodic application security testing of web and mobile applications across the lifecycle — pre-implementation, post-implementation and after changes — "in an environment closely resembling or a replica of the production environment."

Then the three that decide your budget: Para 85(34) periodic VA/PT of applications, servers and network components; Para 85(35) sharing those reports and the compliance to their findings with the UCB or RBI on request; and Para 85(36), which requires constant and continuous monitoring "by technically competent and capable manpower" and then states it plainly — "The ASP shall setup a Cyber Security Operations Centre (CSOC)" — with log collection, SIEM correlation for continuous surveillance and current threat awareness. Para 85(37) closes on PCI-DSS and PCI-SSF.

The point that catches most providers off guard

UCB para 4 sorts every urban co-operative bank into four Levels by digital depth and payment-system interconnectedness. Level I is defined as applying "to the UCB irrespective of digital services / products offered by it" and attracts Chapter II and Chapter III only. VA/PT for the UCB's own systems sits at para 116, in Chapter IV — Level II and above.

Paragraphs 83 to 86 sit in Chapter III.

Replace the parenthetical: "— one that never reaches the para 116 periodic VA/PT obligation, because para 116 sits in Chapter IV and Chapter IV starts at Level II —". If a clause on what Level I does owe is wanted, it is accurate and useful to add: "Chapter III still puts a qualified IS auditor over its CBS servers and network perimeter at para 96." The obligation flows down even where it does not sit at the top. If you have been sizing this by asking which of your customers are large, you have the wrong variable.

UCB para 117 makes the same move for core banking, from Level II upward: a UCB with its CBS on an ASP's shared infrastructure "shall get its CBS application including the infrastructure hosting it subjected to VA / PT through the CBS-ASP." Not alongside. Through. You are the party who commissions the testing, holds the report and answers for the scope — for every UCB on that platform.

Answer it once: the control-by-control evidence pack

The predictable failure mode is the questionnaire. Forty banks, forty formats, forty deadlines, each asking the same question about para 138(19) or para 85(34) in different words, each answered by whoever on your team is free that week. The answers drift, and the drift is discoverable — because para 138(20) and para 85(35) mean your reports go to the bank and to RBI.

Build the pack instead. One document, structured against the enumerated clauses rather than against any customer's template: CB para 138(1) to (24) and UCB para 85(1) to (37), each mapped to your control statement, the owning team and the evidence artefact. Attach current VA/PT reports scoped exactly as paras 137 and 84 define the ecosystem — physical infrastructure, hardware, software, reconciliation system, network interfaces, security solutions, HSM, middleware, and the associated people and processes. Attach source-code audit coverage for critical business applications against para 138(12) and para 85(15), and your secure-coding attestation for new releases against para 138(11) and para 85(14), worded to be handed over on request. State your PCI-DSS and PCI-SSF position against para 138(24) and para 85(37).

Prefix every one of these with the instrument and give the siblings. "Choose your testers with CB para 156 in view (PB para 155, SFB para 155)." And: "CB para 159 (PB para 158, SFB para 158) tells the bank that where a CERT-In empanelled auditor is engaged it 'shall be guided by CERT-In's Comprehensive Cyber Security Audit Policy Guidelines.'" The UCB instrument has no auditor-credentialing counterpart — its nearest provision is para 119, "penetration testing of public facing systems as well as other critical applications are carried out by professionally qualified teams" — so say so rather than letting the reader assume the CB numbers travel. It requires the bank, at every selection, appointment, engagement or renewal, to consider "requisite qualification, professional expertise (of the firm or company as well as the audit personnel engaged by the entity), appropriate credentials, and suitable competency." Firm-level and personnel-level, both, every renewal. CERT-In empanelment is how that gets evidenced, and para 159 tells the bank that where a CERT-In empanelled auditor is engaged it "shall be guided by CERT-In's Comprehensive Cyber Security Audit Policy Guidelines." Close it harder: "A report from an empanelled firm arrives at your customer already inside the regime their supervisor recognises, and CB para 159 tells the bank to read it against CERT-In's own audit policy guidelines. Empanelment is the standard the supervisor expects, and it is the only clean way a bank evidences firm-level and personnel-level competency at every renewal."

Set the report format in your testing contract while you are at it. Change to "CB para 157 (PB para 156, SFB para 156) requires the bank to review…", and note the UCB instrument carries no counterpart. Then re-point the advice at the reader's own contracting rather than at ours: "Write per-area explicit assurance into the scope you agree with your tester, so the report your commercial-bank, payments-bank and small-finance-bank customers receive already answers CB para 157 in the form their supervisor expects." Do not phrase it as something we hand over today. Your customers will be asking for per-area explicit assurance. Specify it upfront rather than discovering the gap when a bank's internal audit team reads your report.

One boundary, stated plainly: the CSOC at para 138(23) and para 85(36) is yours to build or to source..

Security Brigade has been CERT-In empanelled continuously since 2008, across 6,700+ assessments for 1,000+ clients. If you run an ATM Switch or a shared CBS platform for Indian banks, we will build the control-by-control evidence pack with you and run the VA/PT, source-code review and application security testing that populates it — scoped to the ecosystem your customers' contracts now define.