Mobile fintech
Self-custody without sacrificing the mobile experience.
I engineered the mobile and security layers of a non-custodial wallet, where key management, device protection, and a fluid interface had to coexist across more than 50 production screens.
Technology
The device was the custody boundary
A self-custody wallet has no support-led recovery path for a compromised seed phrase. Security requirements therefore shape the product architecture, not just the authentication screen.
The application combined BIP-39 and BIP-44 key derivation, encrypted local storage, biometric access, certificate-pinned network calls, real-time prices, interactive portfolio charts, and an in-app token swap.
Owned the mobile security boundary
I owned work across the React Native application, secure key lifecycle, native platform behaviour, and the interaction problems created by screenshot protection.
The hardest part was not implementing each requirement independently. It was resolving cases where a security control changed the rendering or gesture behaviour of otherwise stable UI code.
Architecture
Security controls had to survive real interaction
Each control was evaluated as part of the product experience, including the rendering, gesture, recovery, and device-specific behaviour it changed.
- 01
Constraint
Applying Android FLAG_SECURE to the root window caused Reanimated chart gestures to stutter on Samsung and Xiaomi devices.
Decision
Move secure-window activation into a native module and enable it only on screens that display sensitive information.
Impact
Sensitive screens remain protected while animation-heavy portfolio views keep their expected interaction performance.
- 02
Constraint
iOS has no direct equivalent to Android's screenshot-blocking API, and the secure text overlay interfered with repeated chart gestures.
Decision
Prioritise protection on sensitive screens and replace the drag scrubber there with a simpler tap interaction.
Impact
The security boundary remains clear without pretending the platform can provide behaviour it does not support safely.
- 03
Constraint
A technically correct seed backup flow can still fail if people skip or misunderstand it.
Decision
Use a three-stage reveal, record, and ordered-word verification flow before unlocking the wallet.
Impact
More than 90% of users who started seed backup completed it.
- 04
Constraint
Private keys and seed material could not remain available in plaintext between sessions.
Decision
Use hardware-backed biometric access to unlock an AES-256 encrypted local keystore and derive individual keys only when needed.
Impact
Key material stays device-bound, encrypted at rest, and absent from remote infrastructure.
Outcome
A secure wallet that still behaved like a consumer app
- Production releases for both iOS and Android.
- Self-custody support for BTC, ETH, and ERC-20 assets.
- Real-time portfolio updates, interactive performance views, and token-swap confirmation with slippage visibility.
- A documented security and interaction model tested across OEM-specific Android behaviour.
Cryptozilla reinforced a practical rule: a security control is not finished until it has been tested against the interactions people need to complete.
Abrar
Start a project
Building a mobile product with a hard security boundary?
I can help design the native architecture, sensitive-data lifecycle, and interaction model together.
Discuss your mobile product