Threat-modeling a Canadian fintech mobile app

A fintech security plan should start with the service, data, users, and regulated entity involved. PIPEDA, provincial privacy law, contractual obligations, and any applicable OSFI guidance do not collapse into one universal mobile checklist. Confirm the legal and regulatory scope with qualified specialists.

The engineering task is to turn that scope into threats and controls the team can test. The sections below cover the mobile side of that exercise without pretending that a library choice makes the product compliant.

Data at rest: secure local storage

Financial data stored on the device is a prime target. If a phone is lost or stolen, the data on it must be unreadable without proper authentication.

• iOS Keychain: Store small secrets with an accessibility class that matches when the app must use them. kSecAttrAccessibleWhenUnlockedThisDeviceOnly keeps an item device-only and available while unlocked. Ordinary Keychain items are not automatically Secure Enclave keys. The Secure Enclave supports specific cryptographic key types and use cases.
• Android Keystore: Generate non-exportable cryptographic keys with restrictions appropriate to the operation. Hardware backing varies by device and key configuration, so inspect KeyInfo or use attestation when hardware assurance is a requirement. Do not state that every Android Keystore key lives in a secure element.
• SQLCipher for local databases: When we need to store structured financial data locally (account balances, transaction history for offline access), we use SQLCipher for full-database encryption with a per-device key.

Minimize stored sensitive data first. Then document which values remain, how they are protected, when they are available, whether they survive backup or device migration, and what happens after sign-out or credential revocation.

Data in transit: begin with a correct trust model

Use platform TLS, valid server authentication, modern protocol configuration, and cleartext blocking. Certificate or public-key pinning can narrow trust, but it also creates an availability risk when keys rotate or an emergency certificate must be issued. Decide from the threat model, ship backup pins when appropriate, and rehearse recovery before enabling enforcement.

For additional protection, we implement:

• Mutual TLS (mTLS): For high-value operations like fund transfers, the server also verifies the client's certificate. Both sides authenticate each other.
• Request signing: Each API request includes an HMAC signature computed from the request body and a session-bound secret. The server rejects any request with an invalid signature.

Authentication: beyond passwords

Authentication and transaction authorization are server-side security decisions with a mobile interface. The application may use:

Biometric-gated local credentials. Face ID, Touch ID, and Android biometrics can authorize access to a locally protected key or credential. That is not automatically a remote second factor. Define what the server verifies and how account recovery, biometric changes, and device replacement affect trust.

Session management. Short-lived access tokens (15 minutes) with longer-lived refresh tokens stored in the Keychain/Keystore. Sensitive operations (transfers, profile changes) require re-authentication regardless of session status.

Device binding. We generate a device-specific keypair during onboarding and register the public key with the server. Each subsequent session is bound to that device. If a user tries to access their account from a new device, additional verification is required.

Runtime protection

Assume the client can be inspected and modified. Runtime signals may increase confidence or trigger additional verification, but none creates a trusted boundary on its own:

• Device integrity signals: Treat root, jailbreak, app-integrity, and attestation results as risk inputs. Decide server-side whether to allow, step up, limit, or deny an operation.
• Anti-debug and tamper signals: These raise effort but can be bypassed. Do not place reusable secrets or authorization decisions in the client because a check appears to protect them.
• Screen exposure: Android's FLAG_SECURE can limit screenshots on sensitive screens. iOS does not provide a general public API that prevents all screenshots. Detect capture where supported, obscure sensitive content when appropriate, and avoid unsupported hidden-view tricks.
• Obfuscation and symbol handling: Use them to reduce accidental disclosure and increase analysis cost, not as encryption or access control.

PIPEDA and Law 25 compliance

Canadian privacy law requires meaningful consent for collecting personal information, where the form of consent depends on how sensitive the data is and what a user would reasonably expect. It gives individuals a right to access their information, and it requires a breach of security safeguards that creates a real risk of significant harm to be reported to the Privacy Commissioner and to affected individuals as soon as feasible. There is no fixed 72-hour clock under PIPEDA. On mobile, this translates to:

• Clear consent flows before collecting any personal or financial data
• In-app data export and deletion functionality
• Granular privacy settings that respect user preferences
• Logging and audit trails for all data access events
• Incident response mechanisms that can trigger remote data wipe if needed

Quebec's Law 25 goes further. Among other obligations, it requires a privacy impact assessment for projects to acquire, develop, or redesign an information system or electronic service delivery involving personal information, rather than for every system that happens to process it. Where an assessment applies, we document our security architecture decisions so it has something concrete to work from.

Security as a continuous process

Security is not a feature you ship once. We integrate security into the development lifecycle:

• Static analysis (SAST) runs on every pull request
• Dependency scanning flags vulnerable libraries before they reach production
• Penetration testing before every major release
• Regular review of certificate pinning configurations and token expiry policies

A useful security review produces a threat model, named control owners, verification evidence, and residual risks. For review of the mobile implementation alongside that work, contact DEVSFLOW.

Afroz Zaheer

Senior iOS Developer at DEVSFLOW Technologies