Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

India’s largest bank confirmed a data loss incident in a 21 October 2026 filing with the BSE and NSE. The alert came five days earlier, on 16 October, through SBI’s threat intelligence channels, which its filing names alongside the Defence Cyber Agency, and from CERT-In. Both flagged suspected customer data on the dark web.

PCI DSS 4.0.1 is the first major standard to name API business logic as an attack type you must address. Requirement 6.2.4 lists attacks on business logic, including attempts to abuse or bypass application features through the manipulation of APIs, alongside injection and access control flaws. The timing matters. All requirements, including the ones that were future-dated, have been mandatory since 31 March 2025. Your next assessment will test controls that were optional a year ago. The reason is simple.

If your team already runs API security tooling, you have probably answered the board’s question with a list: API discovery, testing, runtime protection, bot defense, perhaps a WAF or API gateway in front of it all. Every box is ticked. Yet the honest question every security leader still carries is harder to answer. Is anything getting through? That question has a specific answer, and it rarely comes from the tool inventory.

Every automated red-teaming vendor finds the planted flaw in its own demo app. That tells you very little about how the tool will behave on your APIs, with your login flows, your token lifetimes and your developers. The programs we see struggle usually stall on the work around detection: writing auth scripts, keeping tokens alive, arguing over whether a finding is real, and re-testing fixes by hand. That work lands on a small number of senior security engineers.