Building a fintech app in Canada means operating under some of the strictest data protection regulations in North America. PIPEDA at the federal level, Quebec's Law 25, and industry-specific requirements from OSFI all shape how personal financial data must be handled on mobile devices.
At DEVSFLOW, we have built mobile apps for Canadian financial services clients where a single security incident could mean regulatory action, loss of customer trust, or both. Here is the security stack we implement and why each layer matters.
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 with kSecAttrAccessibleWhenUnlockedThisDeviceOnly: Sensitive tokens and credentials are stored in the Secure Enclave. This flag ensures data is only accessible when the device is unlocked and never backed up to iCloud.
- Android EncryptedSharedPreferences with KeyStore: All key-value data is encrypted using AES-256 with keys stored in the hardware-backed Android Keystore. The keys never leave the 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.
The principle is straightforward: every piece of sensitive data on the device is encrypted with keys that are hardware-bound and inaccessible to other apps or processes.
Data in Transit: Certificate Pinning
HTTPS is the baseline, not the solution. A fintech app must go further to prevent man-in-the-middle attacks.
Certificate pinning ensures the app only communicates with your specific server, not any server presenting a valid TLS certificate. We pin the public key of the server's certificate, not the certificate itself, so that certificate rotation does not require an app update.
A standard TLS connection trusts any certificate authority on the device. Certificate pinning narrows that trust to your server and your server alone.
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
Passwords alone are insufficient for financial apps. Our standard authentication stack includes:
Biometric authentication. Face ID and Touch ID on iOS, fingerprint and face unlock on Android. Biometrics provide a strong second factor without friction. We use the platform's LocalAuthentication (iOS) and BiometricPrompt (Android) APIs to ensure biometric data never leaves the device.
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
A well-built app can still be compromised on a rooted or jailbroken device. We implement runtime checks to detect and respond to hostile environments:
- Jailbreak/root detection: We check for common indicators (Cydia, su binary, system partition modifications) and restrict functionality on compromised devices. For high-security apps, we block access entirely.
- Debugger detection: The app detects if a debugger is attached and terminates the session. This prevents runtime memory inspection.
- Screen capture prevention: We disable screenshots and screen recording on screens displaying sensitive financial data. On iOS, this uses the hidden text field technique. On Android, FLAG_SECURE handles it.
- Code obfuscation: ProGuard/R8 on Android and symbol stripping on iOS make reverse engineering significantly harder.
PIPEDA and Law 25 Compliance
Canadian privacy law requires explicit consent for data collection, the right to access and delete personal data, and breach notification within 72 hours. 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, requiring privacy impact assessments for any system processing personal information. We document our security architecture decisions as part of the privacy impact assessment to satisfy this requirement.
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
If you are building a fintech app for the Canadian market and need a team that understands both the technical and regulatory landscape, let us talk.
Afroz Zaheer
Senior iOS Developer at DEVSFLOW Technologies