Open Banking APIs for Analysts: Consents, SCA, FAPI 2.0, and the Rules by Market in 2026

Open banking APIs let an authorised third party read a customer’s account data (account information) or initiate a payment from it (payment initiation), under a consent the customer grants with strong customer authentication and can revoke. For an analyst at a bank, the work is the consent lifecycle, the security profile (increasingly FAPI 2.0, with pushed authorization requests and sender-constrained tokens), and a regulatory picture that in October 2026 is moving in every market at once: PSD3 agreed but not adopted in the EU, commercial VRP live in the UK, the US rule enjoined, and Canada in draft regulations.

I have worked on the bank side of these interfaces, the account servicing side that has to expose them, and the gap between “we have a PSD2 API” and “our PSD2 API behaves correctly when a consent expires on a Sunday” is where most of the defects live. This guide sits in the advanced part of APIs for Analysts, and it assumes you already read the basics of API keys and tokens.

What is the difference between account information and payment initiation?

They are different products that happen to share an authorization server.

	Account information (AIS)	Payment initiation (PIS)
Third party role	AISP (account information service provider)	PISP (payment initiation service provider)
What it does	Reads balances, transactions, account details	Instructs a payment from the customer’s account
Consent lifetime	Months, refreshed by re-authentication	One payment, or a mandate with limits for VRP
SCA	At consent, then periodically	For each payment, except within an authorised mandate
Main risk	Data exposure over time	Moving the wrong money once
Typical defect	Consent outlives its validity	Payment differs from what was consented

The bank holding the account is the ASPSP (account servicing payment service provider). A third variant, confirmation of funds, answers yes or no to “does this account have 120 EUR available” without exposing the balance.

The UK’s variable recurring payments (VRP) blur the line: one consent authorises a series of payments within control parameters such as a maximum individual amount and periodic limits. Sweeping between a customer’s own accounts was mandated first; commercial VRP, for paying merchants, launched through the UK Payments Initiative (UKPI) scheme on 2 June 2026.

What does the consent lifecycle look like?

The consent is a state machine, and it deserves the same rigour as the payment state machine. Here is a Berlin Group NextGenPSD2 account information consent request:

POST /v1/consents HTTP/1.1
X-Request-ID: 99391c7e-ad88-49ec-a2ad-99ddcb1f7721
TPP-Redirect-URI: https://tpp.example/callback
Content-Type: application/json

{
  "access": {
    "accounts":     [{ "iban": "FR7630006000011234567890189" }],
    "balances":     [{ "iban": "FR7630006000011234567890189" }],
    "transactions": [{ "iban": "FR7630006000011234567890189" }]
  },
  "recurringIndicator": true,
  "validUntil": "2027-04-07",
  "frequencyPerDay": 4,
  "combinedServiceIndicator": false
}

The response returns a consentId, a consentStatus of received, and a link to start strong customer authentication (SCA). After the customer authenticates, the status becomes valid. Then the consent can end four ways: expired (past validUntil), revokedByPsu (the customer withdrew it at the bank), terminatedByTpp (the TPP called DELETE /v1/consents/{consentId}), or it was rejected at authorisation.

The UK Open Banking Read/Write standard models the same thing as POST /account-access-consents, with permissions such as ReadAccountsDetail, ReadBalances, and ReadTransactionsDetail, and an ExpirationDateTime. Version 4.0 moved the consent statuses to ISO-style codes: AWAU (awaiting authorisation), AUTH, RJCT, CANC, and EXPD. If your integration was written against v3.1, where the values were AwaitingAuthorisation, Authorised, and so on, that mapping is a migration task, and an easy one to miss in a status-driven UI.

Three lifecycle rules to write down explicitly, because each has a regulatory number behind it:

• Re-authentication. In the EU, since the amendment to the SCA technical standards (Delegated Regulation 2022/2360) began to apply in July 2023, a bank must not demand SCA when a customer’s balance or last 90 days of transactions are accessed through an AISP, except at first access and when more than 180 days have passed since the last SCA.
• Unattended access. The PSD2 technical standards let an AISP refresh data without the customer present up to four times in 24 hours. That is what frequencyPerDay: 4 encodes, and a fifth call should be refused.
• The customer’s view. The agreed EU Payment Services Regulation adds a permission dashboard in the bank’s own channel, listing each provider, account, purpose, validity, and data categories, with the ability to withdraw access and re-establish it within 48 hours. That is a new screen, a new revocation path, and a new source of revokedByPsu.

Where does strong customer authentication fit?

SCA means two independent elements from knowledge (something the customer knows), possession (something they have), and inherence (something they are). In open banking it happens at the bank, never at the third party, and the API standard decides how the customer gets there. Berlin Group supports redirect, OAuth-based redirect, decoupled (the customer approves in the bank’s app on another device), and embedded approaches. UK Open Banking is mainly redirect-based, with app-to-app redirection common, and also defines a decoupled flow.

For an analyst, the SCA approach changes the test environment more than anything else. A redirect flow needs a test customer who can actually authenticate in the bank’s test channel. A decoupled flow needs a test device that receives the push. Plan both before the sprint where testing starts.

What does FAPI 2.0 require?

FAPI (Financial-grade API) is the OpenID Foundation’s OAuth security profile for high-value APIs. The FAPI 2.0 Security Profile was approved as a final specification in February 2025, and FAPI 2.0 Message Signing followed in September 2025. The security profile requires:

1. Authorization code flow only (response_type=code), with PKCE using S256.
2. Pushed authorization requests (PAR, RFC 9126). The client sends the authorization parameters to the server over an authenticated back channel first, and the browser carries only a short-lived reference.
3. Confidential clients, authenticating with mutual TLS or private_key_jwt.
4. Sender-constrained access tokens, through mutual TLS certificate binding (RFC 8705) or DPoP (RFC 9449, Demonstrating Proof of Possession). A stolen token without the matching key is useless.
5. The iss parameter in the authorization response (RFC 9207), to defeat mix-up attacks.
6. Authorization codes valid for at most 60 seconds.

PAR is easiest to understand as two requests:

POST /as/par HTTP/1.1
Content-Type: application/x-www-form-urlencoded

response_type=code&client_id=tpp-4471&redirect_uri=https%3A%2F%2Ftpp.example%2Fcb
&scope=accounts&code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
&code_challenge_method=S256&state=af0ifjsldkj
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=eyJhbGciOiJQUzI1NiIs...

HTTP/1.1 201 Created
{"request_uri":"urn:ietf:params:oauth:request_uri:6esc_11ACC5bwc014ltc14eY22c","expires_in":60}

Then the browser goes to /authorize?client_id=tpp-4471&request_uri=urn:ietf:.... With DPoP, every API call carries Authorization: DPoP <token> plus a DPoP header holding a signed proof JWT bound to the HTTP method, the URL, and a hash of the token.

Not every ecosystem is on FAPI 2.0 yet. UK Open Banking v4.0 and Australia’s Consumer Data Right still build on FAPI 1.0 Advanced, while the UAE’s open finance framework states FAPI 2.0. Check which profile your market and your bank’s authorization server actually certify, because “FAPI compliant” without a version number is not a requirement.

What is the regulatory state by market in October 2026?

Market	Framework	Status as of October 2026
EU	PSD2	In force; SCA technical standards amended, 180 day re-authentication since July 2023
EU	PSD3 and PSR	Provisionally agreed 27 November 2025; ECON approved 5 May 2026; awaiting Council first-reading position; not in the Official Journal
EU	FIDA (Financial Data Access)	Not withdrawn; no trilogue agreement; marked blocked in Council on Parliament’s legislative train
UK	Open Banking, VRP	FCA lead regulator; future entity being designed; commercial VRP launched via UKPI on 2 June 2026
US	CFPB section 1033 rule	Final rule October 2024; enforcement enjoined since 29 October 2025 pending reconsideration
Canada	Consumer-driven banking	Act passed June 2024; draft regulations published 27 June 2026; read-only first phase

EU. The Payment Services Regulation keeps the dedicated interface obligation and tightens it: data parity with the customer channel, a presumption that the interface is unavailable after five consecutive errors or no response within 30 seconds, a list of prohibited obstacles (such as extra registrations or forcing the customer to type an IBAN), and the permission dashboard. It also extends the payee name and IBAN check, which verification of payee covers. Under the agreed text the regulation applies 21 months after it enters into force, so budget your 2027 and 2028 roadmap now, but quote the dates only once the Official Journal publishes them.

UK. The Joint Regulatory Oversight Committee has wound down and the FCA leads. The FCA’s August 2025 feedback statement describes a future entity for standards, directory, and certification, a not-for-profit company to be regulated under the Data (Use and Access) Act 2025. It has no name yet: a design steering group appointed an independent chair in September 2026, with a blueprint due by the end of 2026.

US. The rule required data providers to make covered data available through a developer interface and recognised the Financial Data Exchange (FDX) as a standard setter in January 2025. A reconsideration proposal reached the White House Office of Information and Regulatory Affairs in August 2026 and had not been published by early October. If you work at a US bank, treat FDX as the practical API standard and the compliance dates as unknown.

Canada. I work from Montréal, so this is the one I watch closest. Budget 2025 moved oversight to the Bank of Canada and committed to legislating payment initiation by mid-2027, once Real-Time Rail is live. The June 2026 draft regulations make phase one read-only, mandate large banks above a retail volume threshold, cap consent at 12 months, require multi-factor authentication, and leave the technical standards body to a ministerial designation. The drafts do not name a standard such as FDX, so do not write any API standard into a requirement as the mandated one yet.

The domain context behind all four markets, from schemes to the roles of each bank in a payment, is in Break Into Banking, and the API mechanics are in API Fundamentals for Analysts.

How do Berlin Group NextGenPSD2 and the UK Open Banking standard differ?

They are the two API families most banks meet, and they solve the same problem differently.

	Berlin Group NextGenPSD2	UK Open Banking Read/Write
Current version	1.3.16 (December 2025); openFinance V2 suite alongside	v4.0, with v4.0.1 patch
AIS consent	POST /v1/consents	POST /account-access-consents
Consent statuses	received, valid, rejected, expired, revokedByPsu, terminatedByTpp	AWAU, AUTH, RJCT, CANC, EXPD
Request correlation	X-Request-ID (UUID, mandatory)	x-fapi-interaction-id
Security	eIDAS certificates, OAuth optional	FAPI 1.0 Advanced, Open Banking Directory
TPP certificates	QWAC (transport), QSealC (signing)	OBWAC (transport), OBSeal (signing), or eIDAS
Error example	CONSENT_EXPIRED (401), ACCESS_EXCEEDED (429)	401 expired token, 403 no permission, 429 with Retry-After

Berlin Group is a framework that national communities profile, so a French, German, and Nordic implementation of the same version can differ. Read the national profile before the core specification. How to analyze an API gives the fit-gap method for exactly that comparison.

The correlation header matters more than it looks. Log X-Request-ID or x-fapi-interaction-id on every hop, and a TPP complaint becomes a two minute search instead of a week of email.

What does an analyst test on an open banking API?

The happy path proves almost nothing. These are the cases I write first, using the two-identity technique from API security testing for analysts.

Id	Case	Expected
OB-01	Read transactions after validUntil has passed	401 CONSENT_EXPIRED (BG) or 401/403 (UK); no data returned
OB-02	Customer revokes in the bank’s channel, TPP reads immediately	Refused; consent status revokedByPsu
OB-03	TPP deletes consent, then reuses its access token	401; status terminatedByTpp
OB-04	Balances-only consent requests transactions	401 CONSENT_INVALID (BG) or 403 (UK)
OB-05	Consent for account A, request names account B	Refused, no data about B in the body
OB-06	Fifth unattended read within 24 hours	429 ACCESS_EXCEEDED
OB-07	Unattended read on day 181 without fresh SCA	Refused, re-authentication required
OB-08	PIS payment whose amount differs from the consented amount	Rejected as a consent mismatch
OB-09	Repeat payment submission with the same idempotency key	Same payment returned, no second debit
OB-10	Access token sent without its client certificate or DPoP proof	401
OB-11	TPP with an expired QWAC or an AIS-only role calls PIS	TLS failure or CERTIFICATE_EXPIRED / CERTIFICATE_INVALID
OB-12	PAR request_uri reused after first use or after expires_in	Authorization refused
OB-13	Consent expires at 00:00 on a Sunday	Expiry applied on time, not at the next batch run

OB-09 is ordinary idempotency testing with the UK x-idempotency-key header. OB-13 is the one that finds batch-driven consent expiry, and I have found it more than once. For TPP onboarding, add the directory side: a certificate revoked in the directory, a TPP whose authorisation the national competent authority withdrew, and a renewal where old and new certificates must both work during overlap, the same rotation problem API keys and tokens describes.

The free API analysis mission practises the contract-reading half of this on a payment API.

The takeaway

Open banking is two products on one authorization server: account information under a long-lived consent, and payment initiation under a per-payment or mandate authorisation. Model the consent as a state machine, with the status codes of whichever standard you implement (Berlin Group’s received to terminatedByTpp, or UK v4.0’s AWAU to EXPD), and test every transition, especially expiry, revocation, scope, and unattended frequency. Expect FAPI 2.0 to become the default security profile, with PAR and sender-constrained tokens, and check which version your market actually certifies.

Then keep a dated table of the rules, because in October 2026 every market is in motion: PSD3 and the PSR agreed but unpublished, FIDA blocked, UK commercial VRP live, the US rule enjoined, and Canada in draft read-only regulations. Quote the dates with their source, and revisit the table every quarter.

Ahmed is a Senior Technical Business Analyst with 10+ years in banking and payments. He builds practical guides and tools for analysts at The Tech BA Toolkit.

Tags: Open Banking, PSD2, APIs, API Security, Payments