The bank's ATM Switch provider: PCI DSS and PCI SSF as contractual controls

If you run an ATM Switch on shared infrastructure for an Indian bank, PCI DSS and PCI SSF stopped being a commercial preference on 31 July 2026. RBI's new cyber security Directions give the bank a fixed list of baseline controls it "shall ensure to mandate … in their contractual agreements" with the Application Service Provider. The last item on that list (Commercial Banks ¶138(24); Urban Cooperative Banks ¶85(37)) reads:

"The ASP shall comply with the relevant standards including Payment Card Industry Data Security Standard (PCI-DSS) and Payment Card Industry - Software Security Framework (PCI-SSF), as applicable to the IT ecosystem."

The obligation runs to the bank, not to you. It is discharged through your contract, so it lands on your desk at the next renewal.

Which instruments carry it, and where

RBI issued six entity-specific Directions on 31 July 2026, all commencing immediately. Four carry the ATM Switch ASP chapter, each built the same way — controls imported from elsewhere in the instrument, a paragraph putting them into the contract, then the enumerated baseline list.

The NBFC (/461) and Credit Information Company (/470) Directions have no ASP chapter at all — the phrase "Application Service Provider" does not occur in either.

The trigger is shared services: the chapter addresses ASPs "where the bank manages its ATM Switch ecosystem through their shared services". The perimeter is wider than the switch — Commercial Banks ¶137 reaches the whole "IT ecosystem" of infrastructure, software, reconciliation systems, network interfaces, hardware security modules, middleware and associated people and data, providing switch services "as well as any other type of payment system related services to the bank".

In the UCB instrument, ¶¶83–86 sit inside Chapter III — the Level I baseline, applicable to every UCB "irrespective of digital services / products offered by it". A co-operative bank with no internet banking, no CSOC and no penetration testing obligation of its own must still write PCI DSS, PCI SSF, ASP-conducted VA/PT (¶85(34)) and an ASP-operated CSOC (¶85(36)) into its switch contract. A small number of switch ASPs carry that clause for hundreds of banks each.

Note the object precisely: this is the ATM Switch ASP. Core banking is handled separately and only for UCBs, at ¶117, which requires a UCB running its CBS on an ASP's shared infrastructure to get that application and its hosting subjected to VA/PT through the CBS-ASP — and says nothing about PCI.

PCI DSS and PCI SSF validate different objects

The clause names two standards because neither answers for the other. PCI DSS applies to an environment — the systems that store, process or transmit account data, and anything that could affect their security. The Software Security Framework applies to software and to the people who build it: v4.0.1 defines it as "the Secure Software Standard and the Secure Software Lifecycle (Secure SLC) Standard". Software assessed against the first is listed as Validated Payment Software; a vendor assessed against the second as a Secure SLC Qualified Vendor — a product listing and a vendor listing.

• An Attestation of Compliance covering your environment says nothing about the second half of the clause, and a Secure SLC listing says nothing about the first.
• PA-DSS is not an answer. The standard records that "PA-DSS and the related program were retired in October 2022", and that past a listing's expiry the application shows as "Acceptable only for Pre-Existing Deployments".
• SSF alignment buys something concrete inside a DSS assessment, and it is bounded. Per Appendix F, software built under the Secure Software Standard lets Requirement 6.2.4 be considered in place; under the Secure SLC Standard, Requirement 6.2. It reaches no further, and validated software "does not by itself make an entity PCI DSS compliant".

"Comply" — on what evidence?

The clause says comply. It does not say certify, and there is no PCI DSS certificate for anyone to hold: validation is a Report on Compliance or a Self-Assessment Questionnaire, with an Attestation of Compliance attached.

RBI's posture on the wider PCI family points the same way. The parallel Digital Payment Security Controls Directions, 2026 (RBI/DoS/2026-27/411) list PCI-PIN, PCI-PTS, PCI-HSM and PCI-P2PE at ¶69(1) as standards "over and above" PCI-DSS and PCI-SSF, and say of those at ¶69(2) that "though formal certification may not be mandatory", the bank "shall obtain appropriate confirmation from the relevant third parties regarding compliance", with a status report to the IT Strategy Committee.

PCI DSS supplies the shape of that trail, and it is more specific than most contracts:

• 12.8.2 — the bank holds a written agreement carrying your acknowledgment that you are responsible for the security of the account data you hold or could affect. The applicability note catches people out: "a PCI DSS Attestation of Compliance (AOC), a declaration on a company's website, a policy statement, a responsibility matrix, or other evidence not included in a written agreement is not a written acknowledgment." 12.9.1 is the same duty from your side.
• 12.8.4 — the bank monitors your compliance status "at least once every 12 months"; 12.8.5 records which requirements you manage, which it manages and which are shared; 12.9.2 obliges you to supply both on request.
• Two ways to be able to answer: your own annual assessment with the evidence shared, or "multiple, on-demand assessments" at each customer's request. An ASP with two hundred downstream banks has an obvious reason to prefer the first.
• And 12.8.1, for the bank that treats the contract as the end of it: "The use of a PCI DSS compliant TPSP does not make an entity PCI DSS compliant."

Where the clause is vaguer than the standard it names

The testing control sits a few items above the PCI one and reads, in full: "The ASP shall periodically conduct Vulnerability Assessment / Penetration Testing (VA / PT) of applications, servers, and network components" (CB ¶138(19), UCB ¶85(34)). "Periodically" is the entire cadence. Invoking PCI DSS in the same list imports the numbers RBI left out:

• 11.4.3 — external penetration testing at least once every 12 months and after any significant infrastructure or application upgrade or change. 11.4.2 is the internal counterpart.
• 11.4.6 — for service providers, penetration testing of segmentation controls at least once every six months and after any changes to those controls. A switch ASP is a service provider; six months is the floor, not twelve.
• 11.4.1 — the documented methodology all of it is performed against, and the artefact a bank's procurement team can actually read.

Each names who may do the work in the same breath: "by a qualified internal resource or qualified external third party", with organisational independence of the tester, "(not required to be a QSA or ASV)". Segmentation is where the switch environment's scope argument stands or falls — segmentation is a claim until 11.4.5 tests it.

The same asymmetry shows in scope. Commercial Banks ¶136(5) imports the bank's application security lifecycle controls onto the ASP by listing paragraphs 79, 80, 82, 83, 84 and 88 — omitting ¶85, which requires assessment scope "not restricted to testing solely against the OWASP top 10 vulnerabilities".

If the switch is multi-tenant, Requirement 11.4.7 applies too, mandatory since 31 March 2025: multi-tenant service providers must support their customers' external penetration testing. The guidance is blunt — they "cannot forbid penetration testing".

What to do with it

Read your own contracts before the bank's compliance team reads them to you: all four instruments are in force with no transition period. The work the clause generates is scoping the switch ecosystem as a cardholder data environment, testing it and its segmentation on the standard's cadence rather than "periodically", and holding the status and responsibility information 12.9.2 says you hand over on request. Security Brigade performs the network and segmentation penetration testing that 11.4.2, 11.4.3 and 11.4.6 place with a qualified independent third party. Banks under the RBI Payment Aggregator Directions meet the same problem from the other side.