Skip to main content
Manifesto

Fintech Security Deep-Dive

Non-negotiables: why they matter, how I implement them, and gotchas.

← Manifesto

Reduces risk of MITM when you control both client and server; required in many fintech/PCI contexts.

How I implement it

  • Pin to leaf and/or intermediate CA; rotate pins with app release and support overlap period.
  • Use platform APIs (Network Security Config on Android, ATS and pinning on iOS); avoid custom SSL sockets unless necessary.
  • Provide a kill switch or config to disable pinning for enterprise/corporate proxy scenarios where appropriate.
Gotcha / trade-off: Over-pinning or no overlap period can lock users on old builds if CA or cert changes; balance security with operational flexibility.

Rooted/jailbroken devices have weaker guarantees; detection helps decide whether to allow sensitive actions or step up auth.

How I implement it

  • Check for common root/jailbreak indicators; use a small, maintained library or minimal checks to reduce bypass surface.
  • Don’t rely solely on client-side checks for high-value decisions; treat as one signal and combine with server-side risk.
  • Graceful degradation: warn, restrict certain actions, or require step-up (e.g. re-auth) rather than hard block where UX allows.
Gotcha / trade-off: Determined attackers can bypass client checks; use for risk scoring and UX, not as sole gate for high-value operations.

Raises the bar for reverse engineering and tampering; required or expected in many fintech apps.

How I implement it

  • Enable R8 full mode with ProGuard rules; keep rules minimal and test thoroughly—optimize for size and obfuscation.
  • Keep reflection-based code in keep rules and document why; avoid broad keep that defeats obfuscation.
  • Consider DexGuard or similar for sensitive apps (e.g. integrity checks, anti-tamper) if budget and compliance justify.
Gotcha / trade-off: Aggressive obfuscation can break reflection, native calls, or serialization; test release builds and maintain rule set in version control.

Keys and secrets in hardware-backed storage are much harder to extract; foundation for auth and encryption.

How I implement it

  • Store auth tokens, API secrets, and encryption keys in Android Keystore or iOS Keychain/Secure Enclave; never in plain SharedPreferences or files.
  • Use Keychain access control (e.g. when-unlocked, when-unlocked-this-device-only) and biometric-bound keys where appropriate.
  • Plan for key rotation and multi-key support so you can rotate without breaking existing users.
Gotcha / trade-off: Keystore can be unavailable on some devices or after factory reset; have a fallback path and never log or backup keys.

All traffic should be encrypted and tokens should not leak; TLS and token handling are baseline.

How I implement it

  • TLS 1.2+ only; disable weak ciphers; use certificate pinning where required (see above).
  • Send tokens in headers only; never in URLs or logs; use short-lived access tokens and secure refresh flow.
  • Validate server certificates and hostname; fail closed on errors; use HSTS and secure cookie flags where applicable.
Gotcha / trade-off: Legacy or partner endpoints sometimes force temporary exceptions; document and time-box them and prefer pinning for your own APIs.

Prevents screenshots and overlay in app switcher; expected for payment and account screens.

How I implement it

  • Set FLAG_SECURE (Android) and equivalent on iOS for screens showing balances, card numbers, or PII.
  • Apply to all activities/views that render sensitive data; centralize in a base class or composable.
  • Consider blur or placeholder in recent apps; test that assistive technologies still work.
Gotcha / trade-off: Overuse can block legitimate accessibility or support tools; limit to truly sensitive screens and test with TalkBack/VoiceOver.

Logs and crash reports often end up in third-party systems; PII must not be present for compliance and safety.

How I implement it

  • Redact or hash PII (emails, IDs, tokens, card numbers) in all log statements and crash payloads.
  • Use a logging wrapper or interceptor that enforces redaction; code review for raw log calls.
  • Define a short allowlist of non-PII identifiers (e.g. request ID) for debugging; everything else redacted by default.
Gotcha / trade-off: Over-redaction can make debugging hard; balance with structured logs and server-side correlation IDs.

Structured threat modeling and pen tests catch design flaws before they become incidents; expected in fintech.

How I implement it

  • Run threat modeling for new features (data flow, trust boundaries, threats); document and track mitigations.
  • Maintain an asset and data flow diagram; update when architecture changes.
  • Schedule regular pen tests and fix findings; have a clear process for handling and prioritizing results.
Gotcha / trade-off: One-off pen tests can miss issues that appear later; combine with ongoing security review and automated checks.

Tech Radar

Adopt / Trial / Assess / Hold — how I think about tech choices.

View Tech Radar →