This Repository provides references to
- Open Banking API-Standards
- European PSD2 Standards
- Non-Europen PSD2 Standards adoptions
- Industrie Standards and as well a
- References to API frameworks.
Open Banking API standards should cover all or most aspects within the normal (average) banking world, it its retail and capital markets alike.
An Open Banking API Standard could, therefore, include some or all of the following aspects
- Account Information Services
- Payment Initiation Services
- Customer Authentication & Security
- Access to accounts (XS2A)
- Generation
- Request
- Trade or Sale
- Active Initiation
- Passive Initiation
- Financial
- Regulatory
- Investor
- Customer
- Branches
- Public Market Data
- Open Bank Project API (OBP API, openbankproject.com)
- Open ID Financial Grade API (FAPI, openid.com)
PSD2 should cover Accounts and Payment related services within the retail bank environment, and security aspects. It does not cover additional retail or capital market products or provides a mechanism to include these at a later stage. The interpretation of the outlined requirements of the EU legislation varies in the EU countries.
- Account Information Services
- Payment Initiation Services
- Customer Authentication & Security
- Access to accounts (XS2A)
In some EU countries this is understood as a separate topic.
- W3C Payments
- STET
- POLAND API
- UK Open Banking API
- Slovak Banking API
- Berlin Group NG
Both global standards are Open Source Open Banking API Standards, and actively work with the industry and regulator alike but are not defined by the regulator, as it is the case with the current PSD2 standards.
One Standard (W3C Payments) is a pure (nonfinancial) and specialist industry payment standard, and has a narrow scope - Web Payments.
The mentioned Payment & Accounts Framework is a (non-public) private club of financial market participants with the objective to find an acceptable and common ground between all parties. Communication is limited to closed circle dialogs, publications are limited to one webpage. As the word framework suggests, it has interpretation room, and so fare provided API information (e.g. YAML v1.3.2) provides interpretation room.
Please, be aware that each standard mentioned above and framework has an individual Copyright, and should be applied accordingly. All other information provided as stated within the repository is AGPL 2018, 2019.
Peter Rosemann, January 2019