Industry · Banking
Keep banking channels open to customers and closed to attackers
I assess the internet banking, mobile and API layers your customers rely on, then give you a ranked plan you can defend to the board and the regulator.
- Top priorityEdge & WAAPLogin, OTP and payment pages draw constant bot and injection traffic.
- Top priorityAPI securityMobile and partner APIs expose accounts when object-level checks are missing.
- Top priorityMobile appsThe app is the branch, so hooking and cloned apps lead straight to fraud.
- ElevatedVulnerabilities & exposure
- ElevatedMonitoring & visibility
- ElevatedGovernance & maturity
In short
Application security for banks covers the internet banking site, the mobile app, the APIs (application programming interfaces) behind them and the controls at the edge. I assess each layer with evidence: WAF (web application firewall) coverage and blocking mode, API authorisation, runtime protection in the app, and whether attacks reach the SOC (security operations centre). You get a ranked plan, not a product list.
Where I usually start
- WAAP & API protection assessment
- Mobile app security assessment
- AppSec maturity assessment
The pressure
What banking security teams are up against.
- Regulators want evidenceTechnology risk rules ask banks to prove controls on digital channels work, not just describe them in policy.
- The app is the branchFor many customers the app is the bank, so a tampered or cloned app becomes a direct fraud channel.
- Bots on login and OTPCredential stuffing and OTP flooding hit login pages around the clock and blend in with real customers.
- Large, mixed estatesCore, cards, internet banking and partner systems come from different vendors, each with its own gaps.
Attack scenarios
The attacks I test your defences against.
Each scenario maps to one of the six areas, so you can see which layer should have stopped it.
Try the attack simulator- Scenario 01Credential stuffing on internet bankingBots replay leaked passwords against login and OTP pages and quietly take over accounts that reused them.Edge & WAAP
- Scenario 02Account number swapped in an API callA logged-in customer edits an account ID in a mobile API request and gets another customer’s statement.API security
- Scenario 03Transfer altered on a rooted phoneMalware hooks the banking app at runtime and changes the payee or amount before the request leaves the device.Mobile apps
- Scenario 04Seen by the WAF, missed by the SOCWAF logs stall in an overloaded pipeline, so a probing campaign runs for days without raising an alert.Monitoring & visibility
Recommended
Where I would start with you.
Three engagements that fit this sector best. Each ends in a prioritised plan; delivery is your call.
- 01WAAP & API protection assessmentFinds the gaps between your WAF, your bot controls and the APIs your apps actually call.2–4 weeksFixed feeSee the service
- 02Mobile app security assessmentTests whether the app holds up on rooted phones and against hooking, cloning and overlays.1–2 weeksFixed feeSee the service
- 03AppSec maturity assessmentA scored baseline and roadmap written in the language your board and regulator use.2–3 weeksFixed feeSee the service
Rules you work under
The frameworks I map findings to.
Findings are written so your risk, audit and compliance teams can use them directly. This is orientation, not legal advice.
- Central Bank of Sri LankaRegulatory Framework on Technology Risk Management and Resilience for Licensed BanksIssued as Banking Act Directions No. 16 of 2021. Sets technology and cyber risk expectations that reach customer-facing apps.
- PCI Security Standards CouncilPayment Card Industry Data Security Standard (PCI DSS) v4.0.1Covers card data wherever it flows, including payment pages, the scripts they load and the APIs behind them.
- SWIFTSWIFT Customer Security Controls Framework (CSCF)Annual attestation for SWIFT users. The payment interfaces and the systems that feed them need hardening and monitoring.
- Saudi Central Bank (SAMA)SAMA Cyber Security FrameworkApplies to banks SAMA regulates, with a maturity model that covers application security alongside governance.
- Australian Prudential Regulation AuthorityPrudential Standard CPS 234 Information SecurityExpects security capability to match the threats a bank faces, with controls tested, including those run by third parties.
Proof
Programmes I have led in banking.
Names stay under NDA. The scale and the work are real.
- 112applications migrated112 bank applications moved to cloud WAAP, wave by waveBanking · A leading Sri Lankan private bankF5 Distributed CloudRead the case
- T1bank vulnerability programmeTier-1 bank scanning upgraded and extended to web applicationsBanking · A Tier-1 Sri Lankan commercial bankTenable Security CenterRead the case
- RASPin-app protection liveIn-app runtime protection live in a customer banking appBanking · A leading private bank’s mobile appZimperiumRead the case
- SIEMtelemetry pipelineWAAP security events arriving in the bank’s SIEM, reliablyBanking · A leading Sri Lankan private bankF5 → Logstash → Trellix SIEMRead the case
Where I work with banking teams
What does an application security assessment for a bank cover?
It covers the internet banking site, the mobile apps, the APIs (application programming interfaces) behind them, the edge controls in front, and whether security events reach the SOC (security operations centre). I work from evidence such as WAF (web application firewall) policies, scan results and logs, not questionnaires. The output is a ranked list of what to fix first, with the effort and risk reduction for each item.
Does a bank need both a WAF and mobile app protection?
Usually, yes. A WAF (web application firewall) or a WAAP (web application and API protection) platform inspects requests arriving at your servers. In-app protection, often called RASP (runtime application self-protection), works inside the mobile app and detects rooting, hooking and tampering on the device. They protect opposite ends of the same transaction, and neither replaces authorisation checks on the server.
Can you assess a banking app without access to its source code?
Yes. Much of a mobile assessment works on the released app: how it behaves on rooted or jailbroken devices, whether hooking tools can change it at runtime, whether a modified copy still runs, and which secrets sit inside the package. Source code and build pipeline access add depth, especially for checking how protection is integrated, but they are not needed to start.
Which regulations shape application security work in banks?
It depends on the market. In Sri Lanka, the Central Bank’s technology risk management and resilience framework for licensed banks applies. In Saudi Arabia, it is the Saudi Central Bank (SAMA) Cyber Security Framework; in Australia, APRA (Australian Prudential Regulation Authority) Prudential Standard CPS 234. Card processing adds PCI DSS (Payment Card Industry Data Security Standard). I map findings to the rules that apply to you.
What banking work has Ravindu Fernando delivered?
Ravindu Fernando, a Colombo-based application security consultant, has delivered four banking programmes in Sri Lanka: about 112 applications moved to a cloud WAAP (web application and API protection) platform, vulnerability management upgraded with web application scanning at a Tier-1 bank, runtime protection rolled out in a mobile banking app, and WAAP logs fed into a bank’s SIEM (security information and event management) platform.