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 |
Contents
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 |
- 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.