Why it matters
No single product makes a bank secure. Each tool covers a different way an attacker could get in or a different stage of an attack: preventing, detecting or responding. Security architecture explains how the layers fit together; this page describes the technology families.
This page is conceptual. It does not describe any organisation’s tools or configuration.
The landscape
| Technology | What it does | Where it sits | Notes |
|---|---|---|---|
| Next-generation firewall | Filters network traffic by application, user and threat, not just address and port | Between network zones and at the perimeter | Rules need regular review; old rules pile up |
| Web application firewall (WAF) | Blocks common attacks on web traffic, such as injection | In front of websites and APIs | Tune it to the application, or it blocks customers |
| DDoS protection | Absorbs floods of traffic meant to take a service down | At the network edge, often a provider service | Test it before an attack does |
| Hardware security module (HSM) | Stores keys and performs cryptography without revealing keys | Payment, card and signing systems | Keys never leave the device in clear |
| Secrets vault | Issues and rotates passwords, keys and certificates at run time | Used by applications and pipelines | Removes secrets from code and configuration |
| Privileged access management (PAM) | Controls and records administrator access, ideally just in time | Between administrators and systems | Standing admin rights are the thing to eliminate |
| SIEM | Collects logs and raises alerts on suspicious patterns | Central, fed by every system | Only as good as the logs and the people reading alerts |
| SOAR | Automates responses to alerts | Alongside the SIEM | Automate the routine; keep people for judgement |
| Cloud security posture management (CSPM) | Finds risky settings in cloud accounts | Across cloud accounts | Catches exposed storage and open network rules |
| Data loss prevention (DLP) | Detects and blocks sensitive data leaving | Email, web, endpoints and cloud storage | Needs well-labelled data to work |
Families, not products. Product choices depend on each bank's estate.
Where banking adds requirements
- Cards and keys. Card numbers are replaced by tokens wherever possible, shrinking what must be protected: Since 1 October 2022, no entity in the card payment chain other than card issuers and card networks may store actual card data; merchants use tokens instead.3Reserve Bank of India. Restriction on Storage of Actual Card Data [i.e. Card-on-File (CoF)] (RBI/2022-2023/95). As of 28 July 2022. PINs and keys are handled inside HSMs.
- Customer authentication. RBI's Authentication Mechanisms for Digital Payment Transactions Directions, 2025, issued on 25 September 2025, require at least two factors of authentication for domestic digital payments, with compliance from 1 April 2026.5The Tribune. RBI unveils new directions to strengthen digital payment security. As of 25 September 2025.
- Digital certificates. IDRBT is the certifying authority for digital certificates in the Indian banking and financial sector under the IT Act, 2000.4Institute for Development and Research in Banking Technology. About IDRBT. As of 1 January 2025.
- Reporting clocks. Detection tools must feed a process fast enough to meet deadlines. CERT-In's directions of 28 April 2022 under section 70B(6) of the IT Act require reportable cyber incidents to be reported to CERT-In within 6 hours of noticing them; they took effect 60 days after issue.1CERT-In, Ministry of Electronics and Information Technology. Directions under sub-section (6) of section 70B of the IT Act, 2000 (28 April 2022). As of 28 April 2022. A service provider must report cyber incidents to the regulated entity without undue delay, so that the entity can report them to RBI within 6 hours of the provider detecting them.2Reserve Bank of India. Master Direction on Outsourcing of Information Technology Services (RBI/2023-24/102). As of 10 April 2023.
How to choose
Choose by the risk each tool reduces, in order of what would hurt most: money movement, keys, customer data and administrator access. Prefer fewer tools that are well integrated and fully used over many that are partly deployed. For each tool, decide in advance who owns it, who reads its alerts and what happens when it fires.
Trade-offs
| Choice | You gain | You give up |
|---|---|---|
| Best-of-breed tools | The strongest capability in each area | Integration work and more consoles to watch |
| One platform suite | Integration and a single view | Dependence on one vendor; weaker in some areas |
| Managed security service | Round-the-clock monitoring without building a team | Outsourcing obligations; less in-house knowledge |
| Strict blocking by default | Fewer successful attacks | More false positives affecting customers and staff |
Pitfalls
- Shelfware: tools bought, partly installed and never tuned.
- Alert fatigue, where so many alerts fire that real ones are missed.
- Blind spots, such as cloud accounts, supplier connections or new services not sending logs.
- Firewall rule sprawl, with thousands of rules nobody can explain.
- Secrets outside the vault, in scripts, tickets or chat.
Questions for a design review
- Which risk does each security tool here reduce, and who owns it?
- Does every system, including cloud and supplier connections, send logs to the SIEMSecurity information and event management. A system that collects security logs from many sources and raises alerts on suspicious patterns.?
- Who reads alerts at 3 a.m., and how fast can an incident reach the reporting deadline?
- Which administrator accounts have standing access, and why?
- Where are this system’s secrets, and when were they last rotated?