In fintech, securing an API endpoint is about much more than an auth layer. Regulation (PSD2, local banking rules, data protection law), fraud, and scale all talk to each other — and a wrong decision in one area ripples into the others. The notes below are distilled from projects we've delivered in regulated sectors; not a theoretical list, but lessons that came out of audits and real incidents.
OAuth 2.1 and PKCE
Implicit flow is history for mobile apps; authorization code flow with PKCE is now the mandatory standard. Three practices complete the picture: keep access token lifetimes short (5–15 minutes), implement refresh token rotation (a stolen token, once replayed, invalidates the whole session family), and always store tokens on mobile in hardware-backed secure storage like Keychain/Keystore. Issuing the token correctly isn't enough — you also have to manage its lifecycle.
mTLS for Server-to-Server
For critical server-to-server endpoints we use mutual TLS: no connection is established until both sides prove their identity with certificates. Certificate management is painful, true — but the pain comes from trying to manage it without automation. mTLS isn't sustainable until certificate issuance and rotation are automated with cert-manager or Vault. One of the most common outage causes we still see in the field is an expired certificate; monitoring and auto-renewal should be non-negotiable.
Rate Limiting + Anomaly Detection
We build this defence in two layers. The first layer is deterministic: token bucket based rate limiting, with separate thresholds per IP, per user, and per endpoint. This layer cuts off brute force attempts, credential stuffing, and scraping cheaply and predictably.
The second layer is probabilistic: ML-based anomaly detection learns normal usage patterns and flags traffic that stays under the limits but is still suspicious — say, sequential account verification attempts crawling along slowly at 3 a.m. The first layer catches the noisy attacks, the second catches the sophisticated ones; they don't replace each other, they complement each other.
Audit Logs
Every PII access must be logged: who accessed what, when, and on what grounds. For regulatory compliance, we keep these records in WORM (write-once, read-many) storage for 7 years — the logs cannot be altered after the fact, which is what gives them evidential value in an audit. A frequently missed detail: the audit log itself must not become a leak vector. PII inside log entries must be masked; otherwise the thing you keep as a "security record" becomes the least protected copy of the data.
Tokenization
Never keep sensitive data (card numbers, national IDs) in your own database — tokenize it. The data lives in a vault service on a separate network segment, while your applications only ever carry meaningless tokens. Beyond security, this has a real commercial upside: your PCI DSS scope shrinks, and audit cost and duration drop significantly. Even if your database leaks, the attacker walks away with nothing usable.
Closing
API security in fintech is not a one-off project but an operated process: a regular pentest calendar, dependency scanning, and a design-stage security review for every new endpoint. If you'd like a review of your API security architecture in a regulated product, talk to the Avva Mobile team — we've earned these notes in the field.
