Officer opens the app
A branch officer opens the loan origination application from a bank-issued laptop at the branch.
How it works in Banking and Financial Services
MicroZAccess checks
- →Bank's identity provider
- →Certificate identity and posture
- →Per application, deny by default
Loan app only
The officer reaches the loan application and nothing else.
Why it matters
Benefits for banks and NBFCs
Contained blast radius
A compromised branch login or laptop reaches only the applications in that employee’s policy, which limits how far an intruder can move inside the bank.
Follows the person
When an employee transfers from a branch to head office or leaves the bank, access changes through the identity provider instead of through firewall rules.
Audit-ready access
Access is written as users, groups and banking applications, so internal audit can see who can reach the core-banking system and from which device.
One policy everywhere
Branch, regional-office and work-from-home staff follow the same policy, without separate access arrangements for each location.
Use cases
Three access problems. One Zero Trust policy model.
Branch Staff
Branch staff and the core-banking system
Scenario
Tellers, branch managers, and loan officers in a network of bank or NBFC branches need the core-banking and loan applications hosted in the head-office data centre.
What the solution does
MicroZAccess verifies each user through the identity provider and checks the device's identity and posture before access. Policy grants each role its named applications and everything else is denied.
Outcome
Branch staff work in the applications they need, and a phished branch credential does not open a path to the rest of the bank's network.
Team Separation
Separating credit, treasury, and HR teams in one data centre
Scenario
Credit, treasury, and HR teams at head office all use applications that sit in the same data centre, on the same network ranges.
What the solution does
Per-application policy lets the credit team reach the loan management system, treasury reach its dealing applications, and HR reach the payroll portal. Applications outside a team's policy are not reachable from its devices.
Outcome
Each function's systems stay separate without a firewall or VLAN project, and the bank can answer "who can reach the treasury application?" from one policy.
Legacy Applications
Older banking applications that cannot be changed
Scenario
An older back-office or reporting application runs on a server where the bank cannot install an agent, but operations staff in several offices still depend on it.
What the solution does
A MicroZAccess App Connector placed beside the application brings it under the same per-application policy. Users reach that one application, not the subnet around it.
Outcome
The bank applies role-based access to legacy systems without modifying them, and moves staff off broad network-level access one application at a time.
Keep Exploring
Go Deeper
See how application-level access works
Give employees, auditors, and vendors access to specific banking applications only, not the whole network, with MicroZAccess enforcing every session.
Read the full solution →IT / ITES
See how COSGrid provides solutions for IT / ITES
Let’s see how COSGrid brings secure access, web protection, and zero trust together in one SASE platform for distributed teams and client environments.
Explore the Industry →The Next Solution
See how API Protection works
Protect internet banking portals and lending APIs from bots, credential stuffing and abuse, with API QShield inspecting every request.
Read the full solution →How it works in Banking and Financial Services
Request reaches the API
A bot replays stolen customer credentials against the internet banking login API, while a partner fintech calls the bank's lending API.
API QShield inspects
- →Scores login traffic for automation
- →Validates partner certificates and tokens
- →Enforces API specifications and policies
Approved traffic reaches the service
Credential stuffing is reduced, and only partners presenting valid credentials reach internal banking services.
Why it matters
Benefits for banks and NBFCs
Reduce automated abuse
Customer-facing banking APIs carry less exposure to credential stuffing, injection attacks, and automated abuse of login and account flows.
Validate API requests
Lending and payment APIs can reject requests that do not match their specifications, stopping unexpected endpoints, parameters, and payloads at the edge.
Secure partner access
Partner and co-lending integrations must present valid certificates and tokens before reaching internal systems.
Deploy where required
Banks can run API QShield in their own environment as a self-hosted appliance or VM, at Kubernetes ingress, or as a sidecar.
Use cases
Three API exposure problems. One application-layer protection model.
Internet Banking
Internet and mobile banking login
Scenario
Retail customers sign in to the bank's mobile and web banking channels, while attackers run bots that try leaked username and password pairs against the login API.
What the solution does
API QShield scores requests for signs of automation and applies policy-based actions such as allow, rate-limit, or block. Schema enforcement and token validation also apply to the requests.
Outcome
Automated login abuse against customer accounts is reduced without the bank changing the banking application itself.
Loan APIs
Loan app APIs and customer data
Scenario
A digital lending app calls the NBFC's APIs to submit applications and fetch loan status, while a caller tries changing account or application IDs to read other borrowers' records.
What the solution does
API QShield checks each request against the API specification and detects attempts to access objects belonging to other users. Sensitive fields in responses can also be masked.
Outcome
Borrower data is harder to harvest through the lending API, alongside the authorisation checks maintained by the application team.
Partner Integrations
Partner fintech and co-lending integrations
Scenario
Fintech partners, co-lending partners, and payment aggregators call the bank's APIs machine to machine from their own infrastructure.
What the solution does
API QShield validates each partner's client certificate and JSON Web Token before requests reach internal services. It also applies rate limits per endpoint or client so one partner's traffic surge does not slow services for others.
Outcome
Only authorised partner systems reach the bank's lending and payment services, while application-layer floods are kept in check.
Keep Exploring
Go Deeper
See how API Protection works
Read how MicroZAccess gives each employee access to named applications instead of the network, with identity, device and policy checks on every request.
Read the full solution →IT / ITES
See how COSGrid provides solutions for IT / ITES
Let’s see how COSGrid brings secure access, web protection, and zero trust together in one SASE platform for distributed teams and client environments.
Explore the Industry →The Next Solution
See how In country security control works
Keep security functions, access logs, and traffic data inside the bank’s own environment and national borders, with deployment records ready for auditors.
Read the full solution →How it works in Banking and Financial Services
Define what stays under your control
The bank's risk and audit team decides which security functions, access logs, and traffic logs must stay inside its own environment.
Deploy where required
- →Deploy components in the bank's data centre or private cloud
- →Keep self-hosted components under the bank's control
- →Use managed services where the bank allows them
Maintain governance and visibility
The bank maintains governance over its security tooling and uses its own deployment records to show auditors where infrastructure runs and where data is kept.
Why it matters
Benefits for banks and NBFCs
Control where security data runs
Access logs and policy decisions about core-banking and customer systems stay in the environment the bank chooses for the components it self-hosts.
Operate on your infrastructure
The bank's IT team decides upgrade timing, configuration changes, and monitoring for self-hosted security components.
Simplify risk and audit reviews
Risk and outsourcing reviews get clear answers on where security infrastructure runs because the bank chooses and operates the deployment location.
Support different deployment needs
Institutions can self-host the components that handle their most sensitive data and consume other components as a managed service.
Use cases
Three deployment concerns. One flexible security model.
On-Premises Security
Security tooling inside the bank's own data centre
Scenario
A bank's CISO wants the platform that controls staff access and branch security to run in the bank's own data centre, operated by the bank's team.
What the solution does
Z3 SASE is deployed on-premises in the bank's environment, so the components installed there and the data they produce stay under the bank's control.
Outcome
The bank operates its security platform on infrastructure it controls instead of depending on a vendor-hosted region it did not choose.
Hybrid Deployment
Hybrid adoption at a growing NBFC
Scenario
A fast-growing NBFC wants to self-host the components that touch borrower and access data but has a small infrastructure team for everything else.
What the solution does
Z3 SASE supports hybrid deployment, allowing the NBFC to run sensitive components in its own environment and consume others as a service.
Outcome
The NBFC keeps control where its board and auditors expect it without taking on the full operating effort of every component.
Audit and Governance
Answering outsourcing and audit questions
Scenario
Internal auditors and the risk committee ask where the bank's security infrastructure runs, who operates it, and whether any part of it still connects outside the bank.
What the solution does
Because the bank chooses the deployment model for each component, it documents where each one runs using its own deployment records.
Outcome
The bank answers location and operator questions with evidence it owns. Meeting each regulatory requirement remains the bank's own responsibility.
Keep Exploring
Go Deeper
See how In Country Security Control works
Keep security functions, access logs, and traffic data inside the bank’s own environment and national borders, with deployment records ready for auditors.
Read the full solution →IT / ITES
See how COSGrid provides solutions for IT / ITES
Let’s see how COSGrid brings secure access, web protection, and zero trust together in one SASE platform for distributed teams and client environments.
Explore the Industry →The Next Solution
See how application-level access works
Give employees, auditors, and vendors access to specific banking applications only, not the whole network, with MicroZAccess enforcing every session.
Read the full solution →
