Foundations and assumptions

Entities & Roles

Overview

1. Financial Institutions: Banks, investment firms, and other entities that offer financial services and use APIs to interact with TPPs and other financial entities.

2. Third-Party Providers (TPPs): Entities that consume APIs provided by financial institutions to offer innovative services like payment initiation, account aggregation, and financial planning.

3. Consumers: End-users who benefit from the services provided by financial institutions and TPPs through APIs.

4. Trusted Central Authority (TCA): An authoritative entity that oversees and ensures the security, authenticity, and integrity of the entities interacting within the financial ecosystem. To be discussed

5. Registration Authority (RA): An entity responsible for the registration and validation of entities (financial institutions and TPPs) before they are allowed to interact with the API ecosystem.

Trusted Central Authority (TCA)

A single TCA for the whole financial industry is probably not feasible in Switzerland without a legal mandate.

The existing and emerging API ecosystems will each have to provide a trusted central authority for their participants.

These "local" TCAs play a pivotal role in maintaining the integrity and security of their financial API ecosystem. The main responsibilities in their area of authority are:

• Trust Management:

  • Define admission criteria which must represent the financial and technical protection requirements of the respective applications demanded by regulation and the service providers.
  • Maintain a directory of trusted entities, their identification credentials (API keys, certificates, CNs, ...) and other required metadata.
  • Ensure that the entities comply with their admission criteria.
  • Must make their admission criteria publicly available.
  • "Local" TCAs can trust each other if they if they consider each other's admission criteria trustworthy.
  • Obligations and liability arising from mutual trust must be negotiated bilaterally. to be discussed

• Incident Response Coordination: Leading efforts in case of security breaches or incidents involving APIs.

Registration Authority (RA)

The RA is crucial for validating and registering entities before they can participate in the financial API ecosystem. Responsibilities include:

• Entity Validation: Verifying the identity and legitimacy of financial institutions and TPPs.
• Compliance Verification: Ensuring that entities meet regulatory, security and API requirements before granting access to production.
• Credential Issuance: Providing credentials such as API keys or tokens to registered entities.

Certification Authority (CA)

TCAs may decide to use an internal CA. Alternatively they also may rely on one or more external CAs.

A CA manages certificates needed for trusted, secure communication between FIs and TPPs. Responsibilities include:

CTA Using own PKI:

• Certificate Issuance: Issue trustworthy certificates that
• Certificate Life-cycle Management: Update revocation lists

Using public trusted commercial CA's PKIs:

• Certificate Issuance: Defining list of accepted (Swiss) commercial CAs.
• Certificate Life-cycle Management: Updating the identification credentials in the directory in accordance with the entity.

FAPI 2.0 Implementation in Switzerland vs. Other Regions

While FAPI 2.0 provides a global standard for financial-grade APIs, its implementation in Switzerland may differ from other countries or regions in several ways:

1. Regulatory landscape: Switzerland's unique position as a global financial hub, combined with its non-EU member status, may influence how FAPI 2.0 is adopted and implemented, particularly in the context of TPP-FI interactions.

2. Privacy focus: Given Switzerland's strong tradition of privacy protection, particularly in banking, the implementation of FAPI 2.0 may place additional emphasis on data protection measures for both FIs and TPPs.

3. Interoperability: The Swiss financial market may require specific considerations for interoperability between existing banking systems and innovative fintech solutions.

4. Multilingual support: As Switzerland has four national languages, API implementations may need to consider multilingual support more extensively than in some other countries, ensuring that TPPs can provide services in multiple languages.

5. Cryptocurrency and blockchain integration: Switzerland's progressive stance on cryptocurrencies and blockchain technology might influence how FAPI 2.0 is implemented, potentially requiring additional considerations for these technologies in TPP services.

By addressing these unique aspects, the Swiss implementation of FAPI 2.0 can ensure that it meets both global standards and local requirements, fostering a secure and efficient open banking ecosystem tailored to the needs of the Swiss financial market, its established institutions, and its innovative fintech sector.

---

To be worked out

User-based Security

Authentication and authorization of users against portals are not part of Common API’s standardization focus.

Possibilities / Variants to Authenticate:

Username & Pwd

2FA, MFA with e.g. PhotoTAN, SMS, Hardware Token, …

Passwordless with e.g. FIDO2

API Security

API Security consists of:

Security logic only:

• Foundation Standard: OAuth 2.0 / OIDC
• Hardening: FAPI Profile

Security & Business logic:

• Customizing: Common API Profile

As API Security relies on keys / certificates, a trusted Central Authority is needed (for Certification Handling and Request Authority).

Foundation: OAuth 2.0 / OIDC

Well known and used: https://oauth.net/2/. Is designed for a wide range of use cases and many security relevant attributes are marked as “could” or “should”.

Extract from the RFC 6749 The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.

List of (FAPI-relevant) OAuth 2.0 extensions (… and therefore “hardened” in the FAPI Security Profile)

• OAuth 2.0 Bearer Tokens (RFC6750)
• OAuth 2.0 PKCE (RFC7636)
• OAuth 2.0 Mutual-TLS Client Authentication (RFC8705)
• OAuth 2.0 Pushed Authorization Requests (PAR) (RFC draft ietf-oauth-par)
• OAuth 2.0 Rich Authorization Requests (RAR) (RFC draft ietf-oauth-rar)
• OAuth 2.0 Authorization Server Metadata (RFC8414)

Hardening: FAPI Security Profile

FAPI is an initiative of the OpenID foundation which is also responsible for OpenID Connect (OIDC).

FAPI is hardening the basic / regular OAuth standard to be suitable for high-risk use cases : Add restrictions, define “must” fields, parameters - e.g. always https.

Knowledge and protocols that are developed in the context of the FAPI initiative are already included as substandards in OAuth, e.g. OAuth Token Binding.

Customizing: Common API Profile

Customize to CH requirements (define values, add may be more restrictions).

Extend the FAPI profile to specific CH requirements. FAPI Breakdown

Trusted Central Authority

Discussion

To discuss: What role should the central authority have? As less as possible? Variants?

Variant A (minimal):

• RA: Processes & interfaces for registration, due diligence of participants (TPP, FI)
• CA: Directory of confirmed participants incl. their public certificates which can be used for secure communication

Variant B (Variant A plus …):

• tbd

RA - Registration Authority

Registration process to onboard new FIs and TPPs:

Due Diligence based on regulations: Who can participate in the CH financial oekosystem?

Processes to apply for certificates

CA - Certification Authority

Manage certificates needed for trusted, secure communication between FIs and TPPs:

Certificates creation, signing

Revocation

Provider interfaces for certification lookup.