Mobile Banking Security Tips

What are mobile banking security tips for a product team?

Mobile banking security tips for product teams are the engineering controls that protect a banking app: device binding with hardware-backed keys, step-up authentication matched to the risk of each action, a certificate pinning decision with a rotation plan, short-lived tokens, and logs that never hold a full card number. A banking chatbot uses the same controls.

Which standards set the bar for a banking app?

Authentication guidance from NIST and the FFIEC, plus PCI DSS for card data, set most of the requirements. OWASP's mobile standard turns them into testable checks.

• NIST SP 800-63B-4: Verifiers must offer at least one phishing-resistant authentication option at AAL2. At AAL3 the authenticator must provide phishing resistance and use a non-exportable private key, so syncable passkeys cannot be used at that level.
• SMS codes: SP 800-63B-4 classifies out-of-band verification over the public telephone network, such as SMS or voice, as a restricted authenticator.
• FFIEC: The 2021 interagency guidance on authentication and access to financial institution services and systems asks institutions to base authentication on risk assessments, and covers customers using digital banking.
• PCI DSS: Sensitive authentication data, such as the card verification code, must not be kept after authorization, and a displayed card number must be masked so no more than the BIN and last four digits show unless there is a documented business need.
• Tokenization: PCI SSC's tokenization guidance says tokenization can reduce the number of systems in the cardholder data environment. It does not remove the need to validate PCI DSS compliance.

How should a banking app bind sessions to a device?

A banking app binds a session to a device by holding a private key in the phone's secure hardware and proving possession of it on every token refresh. A stolen refresh token is then useless on another device.

• 1. Generate the key on the device: Create a key pair in the iOS Secure Enclave or the Android Keystore, backed by StrongBox where the phone has it, marked non-exportable.
• 2. Register the public key: Send the public key to the bank during enrollment, after the customer has passed identity checks and a strong sign-in.
• 3. Sign refresh requests: Each token refresh carries a signature over a server nonce. The server rejects refreshes that are unsigned or signed by an unknown key.
• 4. Add integrity signals: Apple App Attest and the Google Play Integrity API report whether requests come from a genuine app build on a genuine device. Treat them as risk signals, not as the only control.
• 5. Treat a new device as an event: Enrolling a new phone requires step-up authentication and notifies the customer through an existing channel.

Protecting data that stays on the phone

• No secrets in the build: API keys and signing secrets in the app bundle can be extracted, so the server issues per-device credentials instead.
• Keychain and Keystore settings: Store tokens with this-device-only access that requires the passcode-protected phone to be in use, so they are not restored to another phone from a backup.
• Screen protection: On Android, mark sensitive screens as secure to block screenshots and screen recording. On iOS, cover the window when the app moves to the background.
• Clipboard and keyboard: Disable copy on full account numbers and turn off autocorrect and suggestions on sensitive fields.
• Notifications: Push text says that a payment or sign-in happened, without full amounts, account numbers or one-time codes.

When should the app ask for step-up authentication?

The app should ask for step-up authentication when an action could move money, expose credentials or let an attacker take over the account. Map every screen and chatbot intent to a risk level before building the UI.

• Viewing balances and recent activity: The session's normal sign-in, with a short idle timeout.
• Adding a payee or raising a transfer limit: Step-up with a phishing-resistant factor, plus a cooling-off period or notification before first use.
• Sending a payment above a set threshold: Step-up, with the amount and payee shown inside the confirmation so the customer approves what is actually sent.
• Viewing full card or account numbers: Step-up and a time-limited reveal, never left on screen.
• Changing phone number, email or password: Step-up, plus a notice to the old contact details, since attackers use these changes to take over accounts.
• Enrolling a new device: Full authentication and a notice to existing devices.

Rules for a banking chatbot

A banking chatbot is another channel into the same account, so it inherits the app's session and step-up rules. It never resets credentials or sends money from an unauthenticated thread, and an intent that needs step-up hands off to the app's own authentication screen instead of asking for codes in the chat.

Certificate pinning as a tradeoff

Certificate pinning makes the app trust only specific keys for the bank's API, which blocks interception through a rogue certificate authority or a trusted proxy on the device. It also creates an outage risk: if the bank rotates its certificate without updating the pins, every installed app stops connecting.

• Pin keys, not leaf certificates: Pin the public key of an intermediate or of the bank's own key set, so a routine certificate renewal does not break the app.
• Ship a backup pin: Include at least one pin for a key that is not yet in use, ready for planned rotation.
• Keep a forced-update path: The app checks a minimum supported version at launch, so a bad pin set can be replaced quickly.
• Rehearse rotation: Run a rotation drill in a test environment before the first production certificate change.
• Decide explicitly: If the team chooses not to pin, record why and rely on the platform's TLS checks and certificate transparency monitoring.
• Watch for failures: Report pin validation failures to monitoring, since a spike can mean an interception attempt or a rotation mistake.

What should a banking app log, and what must it never log?

A banking app should log security events with enough detail to investigate fraud, and never log card data, credentials or full request bodies. Fraud and security teams need the trail; attackers want the payload.

• Log: Event type, time, customer ID, device key ID, app version, IP and integrity signal results for sign-ins, step-ups, payee changes and payments.
• Log: Failed attempts and lockouts, so credential stuffing and brute force show up in monitoring.
• Never log: Full card numbers, card verification codes, PINs, passwords, one-time codes or session tokens.
• Never log: Full request and response bodies from payment or card endpoints, even in debug builds that might reach testers.
• Mask on screen too: Card numbers are masked to the last four digits by default, and the app blurs its preview in the task switcher.

Using OWASP MASVS as the test plan

OWASP MASVS groups mobile controls into storage, cryptography, authentication, network, platform interaction, code quality, resilience and privacy. Mapping each control in this guide to a MASVS group gives the security testers a checklist and gives the bank's reviewers evidence that each control was tested, not only designed.

Where mobile banking app security breaks

These failure points defeat otherwise sound designs. Each one belongs in the test plan and the penetration test scope.

• Chatbot shortcut: A chatbot that resets a password or moves money after a name and the last four digits of a card, with no session.
• Debug logging in production: Request bodies with card or account data written to a log service or crash reporter.
• Single leaf pin: The app pins one certificate with no backup, and a renewal takes every customer offline.
• SMS as the strongest factor: High-risk actions rely on SMS codes, a restricted authenticator under NIST guidance.
• Tokens that never expire: Long-lived access tokens on a lost phone keep working until the customer calls the bank.
• Scope assumptions: The team treats tokenization as removing PCI DSS scope, while the card entry screen still handles the full number.
• Overlay and screen-reader abuse: Malware that draws over the app or misuses accessibility services can read or tap the screen. On Android, the app can detect obscured touches and refuse sensitive input while an overlay is present.
• Unverified claims: Marketing promises a fraud reduction figure before any control has been measured in production.

How Agnotic can help

Security in a banking app is mostly design work done early: the risk map, the key handling and the log schema. Agnotic Technologies builds mobile banking apps and banking chatbots for fintech founders and bank digital teams, with device binding, step-up flows, a pinning plan and logging designed before the first screen.

Agnotic works with the client's security team, processor and qualified assessor. The assessor decides PCI DSS scope; Agnotic builds the software so that card data stays where the agreed design says it should.

Sources

• NIST SP 800-63B-4: Authentication and Authenticator Management
• FFIEC: Authentication and Access to Financial Institution Services and Systems (interagency guidance)
• PCI Security Standards Council: PCI DSS
• PCI SSC: PCI DSS Tokenization Guidelines information supplement
• OWASP: Mobile Application Security Verification Standard (MASVS)
• Apple: Establishing your app's integrity (App Attest)
• Android Developers: Play Integrity API