API Rate Limiting and Throttling for Financial and Health APIs

API rate limiting for regulated industries is mandated by specific framework provisions and driven by operational resilience requirements. PSD2 RTS on Strong Customer Authentication Article 33 requires that Open Banking APIs do not put "obstacles" in the path of third-party providers (TPPs), which the EBA and FCA have interpreted to mean that rate limits applied to TPP access must be equivalent to those applied to first-party access — overly aggressive rate limiting of Open Banking APIs is treated as a regulatory barrier to competition. Conversely, DORA Article 12 and the EBA/GL/2019/04 ICT operations chapter require that APIs supporting critical financial functions maintain availability and performance under load — without rate limiting, abusive clients or DDoS attacks can exhaust server resources and cause availability failures. In healthcare, HIPAA-covered EHR APIs providing access to ePHI must rate-limit to prevent unauthorized bulk enumeration of patient records, which is a recognized vector for large-scale HIPAA breaches. The 21st Century Cures Act (US) requires certified health IT to support FHIR R4 APIs with reasonable rate limiting that does not unduly impede information blocking regulations.

The technical implementation of API rate limiting requires decisions across four dimensions. First, limiting algorithm: token bucket (allows burst up to bucket capacity, refills at defined rate) versus leaky bucket (smooths bursty traffic, constant output rate) versus fixed window counter (simple, but allows double the limit at window boundaries) versus sliding window log (accurate but memory-intensive). Token bucket is the most common choice for financial APIs as it accommodates expected transaction bursts. Second, limiting granularity: per-IP, per-authenticated-user, per-API-key, per-organization (TPP-level for Open Banking), or per-endpoint. Regulated APIs typically implement layered granularity: global limits per endpoint prevent resource exhaustion; per-client limits enforce fair use; per-endpoint-per-client limits prevent a single noisy client from degrading service for others. Third, API gateway enforcement: Apigee, Kong, AWS API Gateway, and Azure API Management all provide rate limiting policies with configurable algorithms and granularity — implementation at the gateway layer ensures consistent enforcement regardless of backend application logic. Fourth, response headers: RFC 6585 (429 Too Many Requests) and standard Retry-After headers must be implemented to allow legitimate clients to back off and retry within limits.

A nuanced requirement for regulated API rate limiting is the handling of idempotent retry patterns. Financial transaction APIs must support safe retries for failed requests (network timeouts, server errors) without double-processing — idempotency keys (UUID per transaction, validated server-side) allow clients to retry safely. Rate limits must not penalize well-behaved clients retrying idempotent requests on the same key — the rate limiting logic must count unique transactions (unique idempotency keys) rather than raw request counts. Open Banking APIs under UK Open Banking Standards v3.1.11 require specific rate limit tiers per endpoint class (Account Information: 50 calls per 5 minutes per user; Payment Initiation: transaction-based limits) that must be disclosed in the API provider's documentation. The FHIR Bulk Data Access IG (HL7 FHIR R4) specifies async pattern for bulk data requests specifically to avoid rate limit constraints on large data exports for payer/provider analytics.

We design API rate limiting architectures for financial and health APIs covering token bucket algorithm implementation at the API gateway layer, per-client and per-endpoint limit configuration aligned to PSD2 and FHIR requirements, idempotency key handling for transaction APIs, 429 response patterns, and monitoring dashboards tracking throttling events for abuse pattern detection.

Compliance-Native Architecture Guide

Design principles and a structured checklist for building software that is compliant by default — not compliant by retrofit. Covers data architecture, access controls, audit trails, and vendor due diligence.