Security for banks and co-operative banks

What banks need to protect

• Public websites and customer portals.
• Login and OTP endpoints targeted by password guessing and credential stuffing.
• APIs and partner interfaces.
• Servers holding statements, exports and backups with card and PAN numbers.

How Guardian helps

• The human check and per-path rate limits slow down credential stuffing and OTP abuse, while customers sign in as usual.
• Managed rules refuse common web attacks before they reach your applications.
• Network and country rules let you block or challenge sources during an attack.
• Client certificates can restrict partner and internal interfaces to devices you have issued certificates to. You can also use your own certificates on public sites.
• Connections are protected by Guardian Protocol, including post-quantum encryption with browsers that support it.
• The read-only server agent reports suspicious sign-ins and unexpected changes, and data protection scans find card and PAN numbers left in files, without the values leaving your servers.

Evidence for audits and reporting

Banks answer to auditors, regulators and boards. Guardian keeps a timestamped record of what it observed, an audit log of every change in the console and a monthly report per site. Under CERT-In directions, many incidents must be reported within six hours of being noticed; email alerts help your team notice early. Guardian supports your security programme but does not replace your own controls, audits or regulatory reporting.

For co-operative banks

Smaller banks often rely on a technology service provider for their core systems and a web vendor for their website. Guardian is designed to fit that: website protection is a DNS change, the server agent is read-only and installs with one command, and team roles let your vendor see what they need. The console explains findings in plain language.

Start with a free check

Run the free security check on your bank's website to see its grade today, then request protection.

Credential stuffing and OTP abuse

Credential stuffing uses passwords leaked from other services to try to sign in at scale. OTP abuse floods SMS endpoints to run up costs or harass customers. Both rely on automation. Guardian's human check tells real customers apart from automated tools, and per-path rate limits cap how often any one source can call a login or OTP endpoint. Blocked attempts are recorded, so your team can see when a campaign starts and how it changes over time.

Protecting data in transit

Every protected site gets a certificate automatically, or you can upload the bank's own. Guardian Protocol protects connections, including post-quantum encryption with browsers that support it, so traffic recorded today stays protected against future decryption attempts. Internal and partner interfaces can require client certificates, so only devices you have issued certificates to can connect.

Getting started

Request access and tell us what you need protected. Our team verifies your organisation and the people who will hold access. Once approved, a website can be protected the same day through a DNS change, and server and data protection start as soon as your administrator installs the agent. You can leave at any time by pointing DNS back and uninstalling the agent.

Questions

Will customers notice anything when signing in?

No noticeable change. Occasionally a new visitor may see a brief check before the page opens, which completes on its own.

Can Guardian protect our core banking system?

Guardian protects websites, portals and APIs that you route through it, and watches Linux servers with its agent. Tell us about your environment when you request access.

Does Guardian see customer card numbers?

No. Data protection scans run on your server and report counts and locations, never the values.

Is Guardian a replacement for our regulatory controls?

No. It supports your security programme with protection, alerts and evidence. Your bank remains responsible for its controls and reporting.