Open Banking API Design Template (PSD2, FAPI 2.0)

Open banking dedicated interface: PSD2/RTS, PSR and PSD3, FiDA and CFPB 1033 status, API standard choice, FAPI 2.0 controls, consent life cycle, SCA, TPP certificates, dashboards, reporting

Industry ArchitectureFullPSD2 and RTS (EU) 2018/389; FAPI 2.0 Security Profile (Final 2025); NextGenPSD2 1.3.16; UK Open Banking 4.0.1open banking api designUpdated Oct 22, 2026

Open in editorDownload .md

How to use: Use it when a bank designs or renews the APIs through which licensed third parties access accounts and initiate payments. Fill the regulatory scope, the API standard decision and the consent model first. The main pitfall is treating the dedicated interface as a side project, so its availability, SCA journeys and revocation fall below the bank's own channels.

Preview

Open Banking API Design: [Bank or ASPSP name]

Solution design for the interfaces through which licensed third parties access customer accounts and initiate payments with the customer's consent. It covers the regulatory scope (PSD2 and its regulatory technical standards in the EU and EEA, the UK regime, the pending EU Payment Services Regulation and PSD3, the proposed EU financial data access framework and the US personal financial data rights rule), the choice of API standard (UK Open Banking Standard, Berlin Group NextGenPSD2 or a national standard), the security profile (FAPI 2.0 Security Profile, approved as Final on 19 February 2025, specification dated 22 February 2025), consent life cycle, strong customer authentication, third-party onboarding and certificates, dashboards and revocation, performance and availability reporting, fraud controls and conformance testing. Replace every [bracketed] value and every row marked Example. Legal obligations are summarised for design only: check the consolidated texts and your regulator's guidance. This is a documentation format, not legal advice.

Document control

Field	Value
Document ID	[OBA-001]
Regulated entity and role	[Legal name], [ASPSP / TPP / both]
Competent authority	[Regulator name, country]
Markets in scope	[EU/EEA countries / UK / US / other]
API standard and version	[Example: Berlin Group NextGenPSD2 1.3.16 / UK Open Banking Read/Write API 4.0.1]
Security profile	[Example: FAPI 2.0 Security Profile (Final)]
Version	[0.1]
Status	[Draft / In review / Approved / Superseded]
Owner	[@open-banking-architect]
Approvers/reviewers	[@head-of-digital], [@ciso], [@compliance-lead], [@dpo], [@payments-architect]
Classification	[Internal / Confidential]
Last updated	YYYY-MM-DD

Approvals

Role	Name	Decision	Date
Product owner, open banking	[@name]	[Approve / Approve with conditions / Reject]	YYYY-MM-DD
Security	[@name]	[Decision]	YYYY-MM-DD
Compliance	[@name]	[Decision]	YYYY-MM-DD
Data protection officer	[@name]	[Opinion]	YYYY-MM-DD
Architecture review board	[@name]	[Decision]	YYYY-MM-DD

Revision history

Version	Date	Author	Change summary
0.1	YYYY-MM-DD	[@name]	First draft
0.2	YYYY-MM-DD	[@name]	Example: Moved from FAPI 1.0 Advanced to FAPI 2.0 Security Profile
1.0	YYYY-MM-DD	[@name]	Example: Approved for production launch

Regulatory scope
Roles and ecosystem
API standard selection
API product catalogue
Security profile
Consent life cycle
Strong customer authentication
Third-party onboarding and certificates
Dashboards and revocation
Platform architecture
Performance, availability and reporting
Fraud, abuse and rate limiting
Testing and conformance
Operations and incident handling
Traceability matrix
Glossary and references

1. Regulatory scope

1.1 Applicable rules

ID	Rule (check the consolidated text)	Design-relevant provisions, in brief	Status when checked
REG-001	Directive (EU) 2015/2366 (PSD2)	Article 65: confirmation of availability of funds; Article 66: access for payment initiation; Article 67: access for account information; Article 97: strong customer authentication; Article 98: technical standards	In force, transposed nationally
REG-002	Delegated Regulation (EU) 2018/389 (RTS on SCA and common secure communication), as amended by Delegated Regulation (EU) 2022/2360	Articles 4 and 5: authentication code and dynamic linking; Articles 10 and 10a: account information exemption and 180-day renewal; Article 18: transaction risk analysis; Articles 30 to 36: access interfaces, dedicated interface obligations, contingency mechanism and its exemption, certificates and data exchange security	In force
REG-003	Payment Services Regulation (PSR) and Directive PSD3 (procedures 2023/0210(COD) and 2023/0209(COD))	Expected changes to interface requirements, permission dashboards, fraud and liability rules	Political agreement 27 November 2025; texts approved in Parliament committee 5 May 2026; plenary vote indicated for December 2026; not published in the Official Journal when checked in October 2026
REG-004	Proposed Regulation on a framework for financial data access (FiDA), COM(2023) 360	Wider data scope beyond payment accounts, data sharing schemes, permission dashboards	Proposal under negotiation; check the legislative observatory
REG-005	UK regime: Payment Services Regulations 2017 and the FCA's SCA and secure communication rules; Open Banking Standard	UK equivalents of REG-001 and REG-002	[Check FCA and the UK open banking body]
REG-006	US 12 CFR part 1033, personal financial data rights (CFPB final rule of 2024)	Data access obligations for covered providers	Compliance dates stayed by a federal court on 29 October 2025; CFPB reconsidering the rule after an advance notice of 22 August 2025
REG-007	Regulation (EU) 2016/679 (GDPR)	Lawful basis, transparency, data minimisation for shared data	In force
REG-008	Regulation (EU) 2022/2554 (DORA)	ICT risk, incident reporting and resilience testing for the interface	Applies from 17 January 2025

1.2 Scope decisions

ID	Decision	Reason
SCD-001 (Example)	Offer account information, payment initiation and funds confirmation for all online-accessible payment accounts	PSD2 Articles 65 to 67
SCD-002 (Example)	Build the consent model so it can show all active permissions in one dashboard	Expected under PSR and FiDA; good practice today
SCD-003 (Example)	Design the data layer so that savings and loan accounts can be added	FiDA scope and premium API products
SCD-004 (Example)	Do not serve US data recipients in this release	REG-006 status uncertain; revisit after final reconsidered rule

2. Roles and ecosystem

Role	Description	Trust anchor	Bank checks
ASPSP	Account servicing payment service provider: the bank holding the account	Own licence	Not applicable
AISP	Account information service provider	Licence or registration in the home register; qualified certificate	Role in certificate, registration status
PISP	Payment initiation service provider	Licence; qualified certificate	Role, licence status
CBPII	Card-based payment instrument issuer using funds confirmation	Licence; qualified certificate	Role, consent
Payment service user	The customer who gives consent	Bank authentication	Strong customer authentication
National register and EBA register	Public registers of licensed providers	Regulator	Lookup at onboarding and periodically
Qualified trust service provider	Issues qualified certificates with PSD2 roles	eIDAS trust list	Certificate chain and revocation
Directory (where a scheme runs one)	Ecosystem directory of participants and keys	Scheme operator	Software statement and keys

3. API standard selection

Option	Where it is used	Version checked	Notes
UK Open Banking Standard (Read/Write APIs, security profile, directory, dynamic client registration, customer experience guidelines)	UK	Read/Write API 4.0.1; Dynamic Client Registration 3.3; MI reporting 3.1.11	Includes customer experience guidelines that regulators treat as the benchmark
Berlin Group NextGenPSD2 (part of the openFinance API Framework)	Many EU and EEA markets	Implementation Guidelines 1.3.16, published 2 December 2025	Supports redirect, decoupled and embedded SCA approaches; national annexes for domestic payments
National standards (for example STET in France, Polish API)	Specific markets	[Check the current version]	Use where the national market expects it
FDX API	United States, market-driven	[Check the current version]	Relevant if REG-006 obligations resume

Decision: [Example: Berlin Group NextGenPSD2 1.3.16 for EU markets with the national payment annex for SEPA Instant; FAPI 2.0 Security Profile for authorisation; no embedded SCA approach. Reason: market expectation in the bank's countries and lower phishing exposure with redirect and decoupled approaches.]

ID	Deviation or extension	Reason	Published to TPPs
DEV-001 (Example)	Funds confirmation limited to accounts with an online channel	Matches the PSD2 scope	Yes, in developer portal
DEV-002 (Example)	Additional premium endpoint for transaction categorisation	Commercial product outside the regulated scope	Yes, under contract

4. API product catalogue

ID	API product	Regulated basis	Operations (summary)	Consumers
API-001 (Example)	Account information	PSD2 Article 67	Accounts, balances, transactions, consents	AISPs
API-002 (Example)	Payment initiation, single	PSD2 Article 66	Initiate, status, cancel where allowed	PISPs
API-003 (Example)	Payment initiation, instant	PSD2 Article 66	Initiate SEPA Instant, status	PISPs
API-004 (Example)	Periodic and future-dated payments	PSD2 Article 66	Create, status, delete	PISPs
API-005 (Example)	Signing baskets	Standard option	Group payments for one authorisation	PISPs, corporate TPPs
API-006 (Example)	Confirmation of funds	PSD2 Article 65	Yes or no answer for an amount	CBPIIs
API-007 (Example)	Premium data products	Contract	Categorised transactions, savings accounts	Contracted partners

Write the detailed specification of each product with the REST API specification template (architecture/rest-api-specification), keeping the standard's resource names.

5. Security profile

ID	Control (FAPI 2.0 Security Profile, in brief)	Enforced by	Test
SEC-001	Authorisation requests only through pushed authorisation requests (PAR)	Authorisation server	Conformance suite; negative test without PAR
SEC-002	PKCE with the S256 method on every request	Authorisation server	Conformance suite
SEC-003	Only the authorisation code flow; confidential clients only	Authorisation server	Conformance suite
SEC-004	Client authentication by mutual TLS or private_key_jwt	Authorisation server, gateway	Conformance suite
SEC-005	Sender-constrained access tokens by mutual TLS or DPoP	Authorisation server, gateway	Replay test with another key
SEC-006	Issuer identifier returned in the authorisation response (RFC 9207)	Authorisation server	Conformance suite
SEC-007	Short-lived authorisation codes (60 seconds at most) used once	Authorisation server	Reuse test
SEC-008	TLS 1.2 or later per current best practice; only PS256, ES256 or EdDSA for signatures	Gateway, authorisation server	TLS scan, key review
SEC-009	Tokens accepted only in the authorisation header, never in query strings	Gateway	Negative test
SEC-010	Signed requests and responses where non-repudiation is needed (FAPI 2.0 Message Signing, Final: signed authorisation requests and responses, signed introspection responses)	Authorisation server	Conformance suite where available

Notes:

The OpenID Foundation approved FAPI 2.0 Security Profile and Attacker Model as Final on 19 February 2025 (specification dated 22 February 2025), and FAPI 2.0 Message Signing as Final in September 2025 (specification dated 25 September 2025). HTTP signatures for resource requests are in a separate draft specification; check its status before relying on it.
The working group recommends FAPI 2.0 for new ecosystems and a planned transition for ecosystems on FAPI 1.0 Advanced. Record which markets still require FAPI 1.0 and run both profiles only as long as needed.
Customer identity, authenticators and session design come from the CIAM solution design (security/ciam-solution-design).

6. Consent life cycle

ID	Consent attribute	Rule
CON-001 (Example)	Scope	Accounts and data clusters chosen by the customer; never more than the TPP requested
CON-002 (Example)	Validity	End date as requested, within the limits the standard and the regulator allow
CON-003 (Example)	Access frequency without customer present	Limit per day as set by the RTS and the standard
CON-004 (Example)	Renewal	Renewal follows the current RTS rule for account information access; record which party performs SCA
CON-005 (Example)	Payment consent	Bound to the exact payee and amount through dynamic linking
CON-006 (Example)	Audit	Every state change logged with actor, time, channel and reason

Events: consent.created, consent.authorised, consent.revoked, consent.expired, consent.suspended. Consumers include the gateway (to stop access within seconds), the customer dashboard and the audit store.

7. Strong customer authentication

7.1 Approaches

ID	Approach	Description	Offered
SCA-001 (Example)	Redirect	TPP redirects the customer to the bank's authorisation pages or app (app-to-app on mobile)	Yes
SCA-002 (Example)	Decoupled	Customer approves in the bank app on another device; TPP polls or receives a notification	Yes
SCA-003 (Example)	Embedded	TPP collects credentials and passes them to the bank	No, phishing risk

7.2 Payment initiation flow

Example: a PISP initiates a SEPA Instant payment with the redirect approach and FAPI 2.0.

7.3 Exemptions

ID	Exemption (RTS article)	Applied	Monitoring
EXM-001 (Example)	Account information access within the renewal period (Articles 10 and 10a)	Yes	Count of access without SCA per TPP
EXM-002 (Example)	Trusted beneficiaries (Article 13)	Yes, for payees the customer listed with SCA	Changes to the list need SCA
EXM-003 (Example)	Transaction risk analysis (Article 18)	Yes, under the bank's reference fraud rate	Quarterly fraud rate reporting
EXM-004 (Example)	Low-value remote payments (Article 16)	No	Not applicable

8. Third-party onboarding and certificates

ID	Step	Control	System
ONB-001 (Example)	Registration	Dynamic client registration with a signed software statement or certificate	Authorisation server
ONB-002 (Example)	Identity check	Qualified website authentication certificate (QWAC) chain to an eIDAS trust list; PSD2 roles and authorisation number in the certificate	Gateway
ONB-003 (Example)	Licence check	Lookup in the home national register and the EBA register	Onboarding service, refreshed daily
ONB-004 (Example)	Signing certificate	Qualified electronic seal certificate (QSealC) where the standard requires signed requests	Gateway
ONB-005 (Example)	Revocation	OCSP or CRL checks with caching; deny when the status is unknown beyond a tolerance	Gateway
ONB-006 (Example)	Role change	Licence withdrawn or role removed leads to suspension of all clients of that TPP	Onboarding service

Note: certificate profiles for PSD2 roles follow ETSI TS 119 495; check the current version and the trust list rules of each qualified trust service provider.

9. Dashboards and revocation

ID	Requirement	Design	Target
DSH-001 (Example)	Customer sees all active consents per TPP	Dashboard in app and web, reading the consent service	All consents, including expired in the last 90 days
DSH-002 (Example)	Customer revokes access	Revoke action; consent.revoked event	Gateway blocks access within 5 seconds
DSH-003 (Example)	Customer understands what each TPP can see	Plain-language description per data cluster	Reviewed with customer experience team
DSH-004 (Example)	Bank informs TPP of revocation	Status visible through the consent status endpoint or event notification	Next call fails with a defined error

10. Platform architecture

ID	Component	Responsibility	Key property
CMP-001 (Example)	API gateway	mTLS termination, certificate validation, token validation, rate limits, routing	Low latency, high availability
CMP-002 (Example)	Authorisation server	PAR, authorisation, token issuance, client registry	FAPI 2.0 certified
CMP-003 (Example)	Consent service	Consent records, state machine, events, dashboard API	System of record for consents
CMP-004 (Example)	Account adapter	Maps standard resources to core account APIs	Read-heavy, cacheable within freshness limits
CMP-005 (Example)	Payment adapter	Maps payment resources to the payments hub canonical model	Idempotent, exactly-once submission
CMP-006 (Example)	Developer portal and sandbox	Documentation, test data, onboarding	Matches production behaviour
CMP-007 (Example)	Monitoring and reporting	Availability, performance and error statistics per interface	Comparable to own channels

The payment adapter maps to the ISO 20022 canonical model of the payments hub (industry/iso20022-payments-design); the gateway follows the API management platform design (architecture/api-management-platform-design).

11. Performance, availability and reporting

ID	Metric	Dedicated interface target	Own channel comparison	Reporting
PRF-001 (Example)	Availability per month	99.9 percent or better, and not lower than own channels	Same probes against own channel APIs	Quarterly statistics to the regulator and published as required
PRF-002 (Example)	Response time, account information	95th percentile under 750 ms	Same metric on mobile back end	Monthly
PRF-003 (Example)	Response time, payment initiation	95th percentile under 1 second excluding customer SCA time	Same metric on own payments	Monthly
PRF-004 (Example)	Error rate	Under 0.5 percent of calls	Same metric	Monthly
PRF-005 (Example)	Planned downtime notice	Communicated to TPPs in advance as the standard requires	Not applicable	Developer portal

Contingency: describe the fallback the RTS requires if the dedicated interface fails, or the exemption granted by the competent authority under Article 33(6), with its conditions and how they are monitored.

12. Fraud, abuse and rate limiting

ID	Threat	Control	Owner
FRD-001 (Example)	Scam payments initiated through a PISP	Same real-time fraud scoring as own channels, with TPP identity as a feature	Fraud team
FRD-002 (Example)	Excessive polling of account data without the customer present	Rate limit per consent and per day as allowed by the RTS; clear error codes	Gateway team
FRD-003 (Example)	Compromised TPP credentials	Sender-constrained tokens; anomaly detection per client; fast suspension	Security operations
FRD-004 (Example)	Consent phishing	Clear TPP name and data scope on the authorisation screen; no embedded approach	Customer experience
FRD-005 (Example)	Denial of service	Per-client quotas, WAF, autoscaling	Platform team

Blocking a TPP needs a documented reason and, where the rules require it, notification to the competent authority. Scoring design: fraud detection design (system-design/design-fraud-detection). Threat analysis: threat model (security/threat-model).

13. Testing and conformance

ID	Test	Scope	Evidence
TST-001 (Example)	OpenID Foundation FAPI 2.0 conformance tests	Authorisation server, all client authentication and sender-constraint options offered	Published certification or test logs
TST-002 (Example)	API standard conformance	All endpoints against the standard's schemas and rules	Conformance report
TST-003 (Example)	Customer journey tests	Redirect and decoupled SCA on iOS, Android and web, app-to-app	Recorded test runs
TST-004 (Example)	Negative security tests	Token replay, PAR bypass, code reuse, certificate with wrong role	Pen test report
TST-005 (Example)	Performance parity	PRF-001 to PRF-004 against own channels	Load test report
TST-006 (Example)	Market testing with TPPs	At least [number] TPPs per product before launch	Test feedback log

14. Operations and incident handling

ID	Process	Design	Owner
OPR-001 (Example)	TPP support	Ticketing through the developer portal; response times published	Open banking operations
OPR-002 (Example)	Incident communication	Status page for TPPs; notification on degradation	Service management
OPR-003 (Example)	Major ICT incident reporting	Classification against DORA criteria and reporting through the bank's incident process	Operational risk
OPR-004 (Example)	Change management	Advance notice of breaking changes; versioned endpoints; sandbox first	API product owner
OPR-005 (Example)	Certificate and key management	Expiry monitoring for gateway and signing keys	Security operations

15. Traceability matrix

Requirement	Design elements	Tests	Status
REG-001 Articles 65 to 67	API-001 to API-006	TST-002, TST-003	[Open / Passed]
REG-001 Article 97 and REG-002 Articles 4, 5	SCA-001, SCA-002, CON-005	TST-003, TST-004	[Open / Passed]
REG-002 Articles 10, 10a, 13, 18	EXM-001 to EXM-003, CON-004	TST-003	[Open / Passed]
REG-002 Articles 30 to 36	CMP-001, ONB-002 to ONB-005, PRF-001 to PRF-005	TST-005, TST-006	[Open / Passed]
Security profile	SEC-001 to SEC-010	TST-001, TST-004	[Open / Passed]
REG-007	CON-001, DSH-001 to DSH-003	Privacy review	[Open / Passed]
REG-008	OPR-002, OPR-003	Incident exercise	[Open / Passed]

16. Glossary and references

16.1 Glossary

Term	Meaning
ASPSP	Bank or provider that holds the customer's payment account
TPP	Third-party provider: an AISP, PISP or CBPII
SCA	Strong customer authentication with two independent factors
Dynamic linking	Binding the authentication code to the payee and amount of a payment
PAR	Pushed authorisation request: the client sends the request to the server before redirecting the user
DPoP	Demonstrating proof of possession: a method to bind tokens to a client key
QWAC, QSealC	Qualified certificates for website authentication and electronic seals under eIDAS
Dedicated interface	The API the bank provides to TPPs instead of screen access

16.2 References

Reference	Version or date	Use
FAPI 2.0 Security Profile and Attacker Model, OpenID Foundation, openid.net	Final; approved 19 February 2025, specification dated 22 February 2025	Section 5
FAPI 2.0 Message Signing, OpenID Foundation	Final; approved September 2025, specification dated 25 September 2025	SEC-010
Berlin Group NextGenPSD2 Implementation Guidelines, berlin-group.org	1.3.16, 2 December 2025	Section 3
UK Open Banking Standard, standards.openbanking.org.uk	Read/Write API 4.0.1	Section 3
Directive (EU) 2015/2366, Delegated Regulations (EU) 2018/389 and 2022/2360, EUR-Lex	Consolidated texts	Sections 1, 7, 11
PSR and PSD3 procedure files, European Parliament legislative observatory	Checked October 2026	REG-003
CFPB personal financial data rights page, consumerfinance.gov	Checked October 2026	REG-006

Standard and licence note

Based on Directive (EU) 2015/2366 (PSD2), Delegated Regulation (EU) 2018/389 as amended, the OpenID Foundation FAPI 2.0 Security Profile and Message Signing specifications, and the public UK Open Banking Standard and Berlin Group NextGenPSD2 documentation, with status notes on the EU Payment Services Regulation and PSD3, the proposed financial data access regulation and the US personal financial data rights rule. Legal provisions and specification requirements are summarised in original wording; no text of the laws or specifications is reproduced. Check the consolidated legal texts, the regulator's guidance and the current specification versions before use, because several of these regimes are changing. This is a documentation format, not legal advice. Open Banking, Berlin Group, FAPI and OpenID are trademarks of their owners; this template is not affiliated with or endorsed by them. Template licence: MIT.

Related templates

Industry Architecture