A digital bank needs strong authentication, strict API authorisation, a verification standard to test against, careful handling of card data and a fast way to fix vulnerabilities. The biggest failures in banking apps are rarely exotic. They are missing authorisation checks on API objects and weak control of sessions and secrets.
Why is banking different?
Money moves, regulators watch, and customers are targets for fraud. Mobile apps and web apps talk to the same APIs, third parties plug in, and releases ship often. Each of those facts raises the bar for how you build and verify.
This post covers engineering practice, not law. Which rules apply depends on your country and licence, so ask compliance counsel for that.
Which practices matter most?
Authentication. NIST SP 800-63B defines authenticator assurance levels. Higher levels call for stronger authenticators, such as phishing-resistant hardware or cryptographic methods. For money movement and account changes, step up authentication, not just at login.
Authorisation on every object. The OWASP API Security Top 10 puts broken object level authorisation first. In banking it looks like this: the app calls an account statement endpoint with an account ID, and the server fails to check that the logged-in customer owns that account. Check ownership on every request, on the server.
Verification standard. The OWASP Application Security Verification Standard defines three levels of verification. Level 3 is intended for applications that need the highest assurance, such as those handling high-value transactions. Choose a level on purpose and test against its requirements.
Card data. If you store, process or transmit cardholder data, the PCI Data Security Standard applies. The simplest control is reducing scope: use tokenisation or a payment processor so card numbers never touch most of your systems.
Secrets and sessions. Short session lifetimes, device binding where appropriate, and secrets in a vault rather than in the app package. Mobile binaries can be unpacked, so nothing sensitive belongs in them.
Third parties. Open banking style integrations and software development kits add dependency risk. Inventory them and scan them.
A constructed example
A bank adds a feature that lets customers download statements as PDFs. The endpoint takes a statement ID. In testing, a tester changes the ID in the request and receives another customer's statement. The fix is a server-side ownership check, plus a regression test that tries every ID in a range as the wrong user. The team adds that test pattern to all new object endpoints and raises the issue in design review so it is caught earlier next time.
How do you keep pace with release speed?
Automate checks that run on each change: static analysis, dependency scanning, secret scanning and API tests. Fail the build on agreed conditions, such as a known exploited vulnerability in a dependency. Use reachability analysis to keep alert volume workable. Keep an SBOM per release so you can answer "are we affected?" quickly.
Safeguard offers dependency and SBOM scanning, reachability analysis, pipeline policy gates and compliance automation that maps evidence to framework controls. It supports your control work. It does not make a bank compliant on its own.
How to check or apply this
- Pick an ASVS level per application and record the reason.
- Test every API endpoint for object level authorisation with a second user account.
- Define step-up authentication for sensitive actions.
- Reduce PCI scope with tokenisation where possible.
- Keep secrets out of mobile packages and move them to a vault.
- Scan dependencies and third party SDKs on every build.
- Rehearse a vulnerability response, including customer communication.
Quick check
Which ASVS level fits a bank?
Level 3 is aimed at applications needing the highest assurance, such as high-value transactions. Many banks apply different levels to different components. Decide and document.
What is the most common API flaw?
OWASP ranks broken object level authorisation first. It means the server does not check that the caller owns the requested object.
Sources
- OWASP API Security Project, OWASP
- Application Security Verification Standard, OWASP
- NIST SP 800-63B, Digital Identity Guidelines, Authentication and Lifecycle Management, NIST
- PCI Security Standards, PCI Security Standards Council
Last reviewed: 18 October 2026.
