Disclaimer: This article is general information, not professional security, legal, compliance or financial advice. arjankc.com.np is not a security vendor, reseller or consultancy, does not receive payments from vendors and does not rank vendors or products. Standards and regulations change; verify requirements with the standards bodies, your regulators, your qualified assessor and your vendors.

Last reviewed: 13 October 2026

Fintech APIs move money, expose account data and connect to partners you do not control, so they attract both technical attacks and fraud through working features. A sound design treats both together. This guide sets out a vendor-neutral reference architecture, maps it to recognised standards, and explains how fraud controls fit into the request path.

The reference architecture at a glance

A useful way to think about fintech API security is as a set of layers. Each layer has one job, and no single layer is trusted to stop everything. This matches the zero trust idea in NIST SP 800-207 that no implicit trust is granted to a request based on its network location, and that authentication and authorisation happen before a session to a resource is established.

Layered diagram of a fintech API platform with edge, gateway, identity, service mesh and fraud-scoring layers
Layer Main job Typical controls Main standards and guidance
Edge Absorb and filter hostile traffic TLS termination, DDoS protection, web application firewall (WAF), bot management OWASP API Top 10 2023 (API4, API6, API8)
API gateway Single front door for every API Token validation, schema validation, rate limits and quotas, routing, request logging OWASP API Top 10 (API2, API4, API9)
Identity provider Authenticate people and client apps; issue tokens OAuth 2.0 / OpenID Connect, phishing-resistant MFA, sender-constrained tokens RFC 6749, RFC 9700, FAPI 2.0
Service mesh Authenticate and encrypt service-to-service calls Mutual TLS (mTLS) between workloads, workload identity, service-level policy Istio security concepts, NIST SP 800-207
Secrets management Keep keys and credentials out of code Central vault, short-lived credentials, rotation, audit trails NIST CSF 2.0 (Protect)
Data tokenization Remove sensitive data from most systems Card-number (PAN) tokenization, field-level encryption, segmented token vault PCI SSC tokenization guidelines
Fraud and risk Decide whether a valid request should be honoured Device signals, velocity rules, behavioural analytics, risk scoring, step-up auth FFIEC authentication guidance
Logging and response Detect, investigate and recover Centralised logs, alerting, playbooks, post-incident review NIST SP 800-61 Rev. 3

Edge and API gateway

The edge

The edge terminates TLS, filters obviously malicious traffic and absorbs volumetric attacks. A WAF helps with known attack patterns, but it cannot understand business logic — it does not know that user 123 should never see account 456.

The gateway

The gateway is where policy becomes consistent. Every external call should pass through it so that you can:

  • Validate tokens — signature, issuer, audience, expiry and, for sender-constrained tokens, the proof of possession.
  • Validate requests against a schema — reject unexpected fields early, which reduces mass-assignment problems covered by OWASP API3:2023 (Broken Object Property Level Authorization).
  • Apply rate limits and quotas — per client, per user and per endpoint (see below).
  • Keep an inventory — the OWASP list includes API9:2023 Improper Inventory Management because forgotten API versions and debug endpoints are common entry points. If an endpoint is not registered at the gateway, it should not be reachable.

The gateway should not be the only place authorisation happens. It can confirm that a token carries the right scope for “read accounts”, but only the service that owns the data can confirm that this account belongs to this customer.

Authentication and authorisation for financial APIs

OAuth 2.0 and OpenID Connect

Most financial APIs use OAuth 2.0 (RFC 6749) for delegated authorisation and OpenID Connect for user identity. The IETF’s Best Current Practice for OAuth 2.0 Security (RFC 9700) updates the original threat model. Two points matter for fintech teams:

  • Clients should not use the implicit grant (tokens returned in the browser redirect) unless token leakage and injection are prevented.
  • The resource owner password credentials grant must not be used, because it exposes the user’s password to the client application.

In practice, this means the authorization code flow with PKCE for user-facing apps, and strong client authentication for server-to-server integrations.

FAPI 2.0 Security Profile

The OpenID Foundation approved the FAPI 2.0 Security Profile and Attacker Model as Final Specifications in February 2025. FAPI 2.0 is a hardened profile of OAuth for high-value APIs, and it is widely referenced in open banking. Among its requirements, authorization servers:

  • only support confidential clients;
  • only issue sender-constrained access tokens, using either mTLS or DPoP;
  • require pushed authorization requests (PAR, RFC 9126) and reject authorization requests sent without them;
  • require PKCE with the S256 method;
  • issue authorization codes with a maximum lifetime of 60 seconds.

Read the specification itself for the full list, including client authentication and TLS requirements. The OpenID Foundation also runs conformance tests that let you check an implementation.

Sender-constrained tokens: mTLS and DPoP

A bearer token works for whoever holds it, so a leaked token can be replayed. Sender-constrained tokens close that gap:

  • mTLS certificate binding (RFC 8705) — the token is bound to the client’s TLS certificate. The resource server checks that the certificate presented on the connection matches the one in the token.
  • DPoP (RFC 9449) — the client signs a short proof for each request with a private key, and the token is bound to that key. DPoP works at the application layer, which can be easier when TLS is terminated before the API.

mTLS is usually simpler for business-to-business integrations where both sides manage certificates. DPoP is often a better fit for mobile or browser clients.

Customer authentication

For people logging in, phishing-resistant MFA is the strongest widely available option. NIST SP 800-63B-4, published in final form in July 2025, requires verifiers to offer a phishing-resistant option at authentication assurance level 2 and states that one-time codes and other manually entered outputs are not phishing-resistant. The FIDO Alliance’s passkey work is the most common way to deliver this to consumers.

Mapping controls to the OWASP API Security Top 10 (2023)

The OWASP API Security Top 10 (2023) is the most widely used checklist for API-specific risk. Here is how the layers above address each item.

OWASP risk What it looks like in fintech Where to control it
API1 Broken Object Level Authorization (BOLA) Changing an account ID in the URL returns someone else’s data Owning service checks the object belongs to the caller on every request
API2 Broken Authentication Weak token validation, long-lived bearer tokens Identity provider, gateway token checks, sender-constrained tokens
API3 Broken Object Property Level Authorization Response leaks internal fields; client can set limit Response filtering, schema validation, explicit allow-lists
API4 Unrestricted Resource Consumption Unlimited OTP or SMS sends, expensive queries Rate limits, quotas, pagination limits
API5 Broken Function Level Authorization Customer token can call an admin or partner endpoint Separate admin APIs, role checks in each service
API6 Unrestricted Access to Sensitive Business Flows Automated card testing, mass account opening Bot defences, velocity rules, fraud scoring
API7 Server Side Request Forgery Webhook URL field used to reach internal systems URL allow-lists, egress controls from services
API8 Security Misconfiguration Verbose errors, permissive CORS, old TLS Hardened baselines, configuration scanning
API9 Improper Inventory Management Old v1 endpoint still live without new controls Gateway-only exposure, API catalogue, retirement process
API10 Unsafe Consumption of APIs Trusting data from a partner or aggregator without checks Validate partner responses as untrusted input

BOLA deserves special attention. It cannot be fixed at the edge or gateway because those layers do not know who owns which record. Build an ownership check into the data-access layer of each service, and test it with automated cases that try to read and modify other users’ objects.

Data protection: tokenization and PCI DSS scope

If your platform touches payment card data, the PCI Data Security Standard applies. PCI DSS v4.0.1 was published in June 2024 as a limited revision with no new or deleted requirements, and v4.0 was retired on 31 December 2024. The PCI SSC also confirmed that the requirements marked as future-dated in v4.0 took effect on 31 March 2025.

Tokenization replaces a primary account number (PAN) with a surrogate value. The PCI SSC’s tokenization guidelines are clear about what this does and does not achieve:

  • The tokenization system — including de-tokenization and PAN storage — is part of the cardholder data environment and stays in scope.
  • Any system with access to the tokenization or de-tokenization process is also in scope.
  • Systems that only store, process or transmit tokens, are adequately segmented, and cannot be used to recover the PAN may be considered out of scope.

In practice, isolate the token vault, expose de-tokenization only to services that genuinely need the PAN, and let analytics, support tools and the fraud engine work with tokens. Your qualified security assessor makes the final scope decision.

Abuse controls: rate limits, webhooks and idempotency

Rate limiting

Rate limits protect against both denial of service and business-logic abuse. Apply them at several levels:

  • Per client application — protects capacity and spots a misbehaving partner.
  • Per user or account — limits damage from a single compromised login.
  • Per sensitive endpoint — login, OTP send, password reset, payee creation and payment initiation each deserve their own limits.

OWASP API4:2023 notes that some endpoints trigger paid third-party actions, such as SMS messages. Limit these tightly, because attackers can run up costs as well as cause harm.

Signing webhooks

Fintech platforms both send and receive webhooks for payment status, disputes and account events. Treat inbound webhooks as untrusted until verified. A common pattern, used for example in Stripe’s webhook documentation, is for the sender to sign each payload with a shared secret and include a timestamp in a signature header. The receiver recomputes the signature, compares it and rejects stale timestamps to limit replay. Stripe’s documentation also warns that the same event can be delivered more than once, and recommends logging processed event IDs so duplicates are ignored.

Idempotency keys

A client that retries a timed-out “send payment” request can pay twice. An idempotency key is a unique value sent with the request; the server stores the first result and returns it for any retry with the same key. Stripe’s idempotency documentation describes this pattern, suggests random values such as V4 UUIDs, and advises against using personal data as keys. For a payments API, require idempotency keys on every money-moving endpoint.

Fraud prevention in the request path

A perfectly authenticated request can still be fraudulent: the customer may have been tricked, or the account taken over. Interagency guidance from the FFIEC on authentication and access recommends layered security — combining preventive, detective and corrective controls — and applying stronger authentication as the risk of a transaction increases. It names transaction amount limits and monitoring among examples of layered controls.

Building blocks

  • Device signals. Whether the device has been seen before and shows signs of emulation or tampering. Use them as inputs to a decision, not a pass/fail gate.
  • Velocity rules. Counts over time, such as logins per hour or new payees per day. They are transparent and easy to explain to auditors.
  • Behavioural analytics. Comparing a session to the customer’s usual times, amounts and payees. Unusual behaviour raises risk rather than blocking outright.
  • Account takeover (ATO) defences. Phishing-resistant MFA, alerts to the customer when credentials, contact details or devices change, and a cooling-off period before newly added payees can receive large amounts.
  • Step-up authentication. Asking for a stronger factor only when risk is elevated. The FFIEC guidance specifically describes increasing authentication strength for higher-risk activity such as initiating a payment.

Transaction risk scoring

A risk engine combines these signals into a score and returns one of a small set of decisions: allow, allow with monitoring, step up, hold for review, or decline. Some practical design points:

  • Call it synchronously for money movement, with a strict timeout and a defined fallback. Decide in advance whether a timeout means “allow with monitoring” or “hold”.
  • Use tokens, not raw card numbers, so the fraud engine can stay out of the cardholder data environment where possible.
  • Record reason codes for each decision; people will ask why a payment was blocked.
  • Measure outcomes yourself. Track false declines and confirmed fraud on your own data. Vendor detection-rate claims do not transfer reliably, so this article quotes none.

Some identity platforms expose risk-based policy as a service. For example, Ping Identity’s documentation includes a dynamic authorization tutorial that uses a payment-amount rule as its example. Whether you buy or build, keep the decision logic versioned and testable.

Logging, monitoring and incident response

For each API call, log the client ID, a tokenized account reference, the endpoint, the gateway and risk decisions, and a correlation ID that follows the request across services. Never log access tokens, secrets or full card numbers.

For incident response, NIST SP 800-61 Revision 3, finalised in April 2025, supersedes the 2012 Revision 2. It reframes incident response as part of overall cybersecurity risk management and maps recommendations to the six functions of NIST CSF 2.0: Govern, Identify, Protect, Detect, Respond and Recover. For an API platform, prepare playbooks in advance for the most likely scenarios:

  1. A partner’s client credentials or certificate are compromised — revoke, rotate and review recent calls.
  2. A BOLA flaw is discovered — disable or patch the endpoint, then identify which records were accessed.
  3. A credential-stuffing wave hits the login API — tighten rate limits, force step-up and monitor for ATO.
  4. A webhook signing secret leaks — rotate it and replay-check recent events.

Open banking context in the United States

In the US, open banking rules come from Section 1033 of the Dodd-Frank Act. The CFPB’s rulemaking page records that the Bureau released a final Personal Financial Data Rights rule on 22 October 2024 and an Advance Notice of Proposed Rulemaking to reconsider it on 22 August 2025. That notice says the rule’s compliance dates were stayed by court order. Treat any published deadline as provisional and check the CFPB page for the latest position.

Whatever the final rule says, the architecture in this article applies: data access through documented APIs rather than screen scraping, strong client authentication, consent that is scoped and revocable, and full audit trails.

A short implementation checklist

  • Publish every external API through one gateway and keep an inventory.
  • Use the authorization code flow with PKCE; ban the password grant.
  • Adopt sender-constrained tokens (mTLS or DPoP) for partner and high-value APIs; consider FAPI 2.0 conformance.
  • Enforce object-level authorisation inside each service and test it.
  • Tokenize card numbers and segment the token vault.
  • Rate-limit per client, per user and per sensitive endpoint.
  • Sign and verify webhooks; require idempotency keys on payment endpoints.
  • Feed device, velocity and behavioural signals into a risk engine with clear decisions and reason codes.
  • Centralise logs with correlation IDs and rehearse incident playbooks.

Sources