A mobile banking app and the API behind it look similar from the compliance checklist, but they are not the same risk. The app has a limited UI, a single intended user flow, and controls that live mostly in one codebase. The API sits underneath, exposed to every third-party app, aggregator, and payment initiation service that wants account data or wants to move money. Each of those callers is a separate trust relationship, a separate set of credentials, and a separate way for something to go wrong.
This is the distinction regulators are actually working from. Open banking mandates exist because an API is not a convenience feature bolted onto a bank. It is a regulated access point into customer financial data, built for third parties the bank did not choose and often does not fully audit. PSD2’s Regulatory Technical Standards, the FDX framework, and the UK Open Banking standard all start from that premise, and they ask for proof, not intentions. Compliance officers and engineering leads building these APIs need to know what “proof” means in practice, because that is what an auditor or regulator will ask to see.
What PSD2’s RTS and FDX actually require from your API layer
PSD2’s RTS sets requirements for strong customer authentication, secure communication, and consent management on any interface that exposes payment accounts to third parties. It is specific about outcomes: authentication must use at least two independent factors, communication must be encrypted end to end, and third-party providers must be identified through qualified certificates before they get access. It does not mandate a particular architecture, which is why two banks can both claim compliance while running very different implementations.
FDX, used widely across US open finance, takes a similar approach but with more prescriptive technical detail around OAuth 2.0 and token-based access. It specifies how consent should be captured, how long tokens should live, and what data elements a given permission actually covers. The UK Open Banking standard sits closer to FDX in its specificity, with defined API profiles that banks must implement rather than general principles they can interpret.
What all three share is the expectation that consent, authentication, and access are enforced at the API layer itself, not somewhere upstream in a web form. An auditor working through any of these frameworks will trace a request from the moment a third party asks for access to the moment data leaves the system, checking that every control fires at the right point in that chain. If your API trusts a token without checking its scope, or accepts a request without verifying the certificate behind it, the control exists on paper and nowhere else.
Strong customer authentication: where implementations quietly fall short
Strong customer authentication sounds like a solved problem. Most teams have two-factor login, and many have biometric options built into their consumer apps already (a pattern covered in more depth in how biometric authentication in fintech is changing login flows). The gaps regulators find are rarely about whether SCA exists. They are about where it applies and where it quietly doesn’t.
Dynamic linking is one common failure point. SCA for a payment needs to be tied to the specific amount and payee of that transaction, not a generic login challenge reused across actions. A system that authenticates a user once at session start and then lets that session authorize multiple different payments without re-checking the transaction details does not meet the standard, even if the initial login was strong.
Exemptions are the other place implementations drift. The RTS allows reduced friction for low-risk transactions and recurring account access under defined conditions, but those exemptions have limits on frequency and amount that need to be enforced in code, not assumed by the product team. An auditor will ask for the logic that decides when an exemption applies and will test whether it can be bypassed by sequencing requests just inside the threshold. If that logic lives in a comment rather than an enforced rule, it will not hold up.
OAuth scopes and token mismanagement: the compliance failure auditors find first
OAuth is the mechanism nearly every open banking API uses to express consent as a technical object, and it is also where auditors find the most daylight between policy and implementation. A consent screen might say the user authorized read access to account balances. The token issued after that consent needs to carry exactly that scope, nothing wider, and the resource server needs to reject any request that asks for more.
The failure pattern auditors flag most often is scope creep: a token issued for one permission level that a later code change quietly lets access a broader set of endpoints, because a scope check was never added to a new route. This usually happens without anyone deciding it should. A new endpoint ships, the team reuses an existing authentication middleware for speed, and the middleware checks that a token is valid without checking what it’s valid for.
Token lifecycle is the second recurring issue. Tokens that don’t expire, refresh tokens that never rotate, and revoked consents that don’t actually invalidate the tokens issued under them are all things an auditor can demonstrate within minutes of API access. The fix is mechanical: short-lived access tokens, rotating refresh tokens, and a revocation check that runs against the token store on every request rather than relying on expiry alone. None of this is exotic engineering. It is the difference between having a token architecture and having token issuance.
Rate limiting and gateway controls that stop data scraping before it starts
An open banking API that authenticates and scopes correctly can still leak data through volume. A third party with legitimate, narrow access to one customer’s account data has no legitimate reason to query thousands of accounts per minute, and a gateway that doesn’t notice that pattern is a gateway that will eventually explain a large exposure after the fact rather than preventing it.
Rate limiting at the API gateway should be scoped per client and per credential, not applied as a single global ceiling. A payment initiation service and a budgeting app calling the same endpoints have different normal usage patterns, and limits set for the busier client will do nothing to stop abuse from the quieter one. Anomaly detection on request patterns, such as a sudden spike in account lookups from a single client ID, should trigger throttling or a manual review rather than waiting for a usage report weeks later.
This is also where API gateway architecture connects to the broader scaling work most fintechs are already doing. The same infrastructure decisions that let a platform handle growth without breaking reliability are the ones that make rate limiting and anomaly detection practical to run at scale, a connection covered in more detail in the piece on cloud architecture for fintech scalability. A gateway bolted on as an afterthought rarely has the visibility to catch scraping before it becomes a reportable incident.
Consent revocation and audit trails: proving access matched permission at every point
Consent is not a one-time event in open banking regulation. It is a state that can change, and the API has to reflect that change immediately, not on the next batch job. When a customer revokes access to a third party, every token issued under that consent needs to stop working at the moment of revocation, not at its next scheduled expiry.
The harder part is proving this after the fact. Regulators and auditors will ask for a record showing, for any given access event, which consent authorized it, what scope that consent covered, and whether the consent was active at the time. This means your audit trail needs to log consent state alongside every API call, not just the call itself. A log that shows a request succeeded without showing what permission justified it answers the wrong question.
Building this trail retroactively is painful, which is why it needs to be part of the API design from the start rather than added once an auditor asks for it. Every consent grant, modification, and revocation should write to an immutable log tied to the token lifecycle, and that log should be queryable by consent ID, not just by customer or by timestamp. When an auditor picks a random access event from six months earlier and asks you to justify it, the answer needs to come from a query, not from reconstructing context across three different systems.
Preparing for a regulator’s API security review, not just a penetration test
A penetration test checks whether your API can be broken into. A regulatory review checks whether your API enforces the rules it claims to enforce, which is a different and in some ways harder question to answer. Pen testers look for vulnerabilities. Regulators look for gaps between your documented controls and your running system.
The preparation that matters most is documentation that matches reality. If your policy states that tokens expire after a set period, your engineering team needs to be able to show the configuration that enforces that, not just the policy document. If your consent flow claims to capture granular, scope-specific authorization, someone needs to be able to pull a sample of real consent records and show the scopes actually issued match what the user saw on screen.
Reviews also tend to probe the handoff points: where authentication ends and authorization begins, where consent capture ends and token issuance begins, where your system trusts a third party’s certificate versus revalidating it on each call. These seams are where controls get duplicated, skipped, or contradicted between teams that built different parts of the stack at different times. Walking through your own architecture with that seam-by-seam view before a regulator does it is the most useful preparation available, and it tends to surface the same gaps a real review would find.
If you’re still mapping which compliance obligations apply at your company’s current stage, a founder’s roadmap to fintech compliance lays out what to prioritize and when.